在 Windows 上减少 Codex 乱码问题的指示规则

在 Windows 上让 Codex 处理含日文的文件时，最先见效的并不是把编辑器和 shell 的配置全部对齐，而是 向 Codex 明确说明“怎么读、怎么写、在哪里停下来”。

尤其容易出问题的是下面这些场景。

• UTF-8、CP932、UTF-16 系的文件混在一起
• 表面看起来能读，但实际字节的解释已经偏了
• 本以为只是稍微改了一下现有文件，保存时却用别的 encoding 重新写了一遍
• 在 CSV、TXT、日志、Markdown、配置文件这类“代码以外”的地方损坏
• 临时脚本或 shell 输出被直接保存下来，损坏就此固定

OpenAI 的 Codex 与其当成一次性的聊天对象，不如当成一位给了配置和作业规则、可以持续合作的队友来使用，会更稳定。特别是已经有让它读 AGENTS.md 的做法时，字符编码相关的规则与其每次口头重复，不如常设下来更有效。

本文从实务角度整理 为了让 Codex 在 Windows 上安全处理日文文件，最先给出就容易见效的指示。

flowchart TB
    accTitle: 先固定指示，再谈环境配置
    accDescr: 在Windows上让Codex处理日文文件时，最先见效的不是把编辑器和shell的配置对齐，而是明确说明怎么读、怎么写、在哪里停下来的示意图。
    a1["把编辑器和shell的配置对齐"] -.-> a2["最先见效的不是这一项"]
    a3["怎么读"] --> a6["向Codex明确说明"]
    a4["怎么写"] --> a6
    a5["在哪里停下来"] --> a6

图1：最先见效的不是环境配置，而是把读法、写法、停止方式说清楚。

前提：本文所设想的 Codex 与 AGENTS.md

为没有使用过 Codex 的读者，先把前提写在这里。

Codex 是一个会实际读写仓库文件的编码智能体。它有多个入口：在本地终端运行的 CLI、编辑器扩展、在云端运行的形态等等；而本文设想的是 让它直接编辑本地仓库文件的用法。乱码问题发生在“编辑并保存”的时刻，所以比起用哪个入口，如何约束对文件的写入路径 才是本质。

AGENTS.md 是一个 Markdown 文件，用来写下在该仓库中作业时的常设指示。它被读取的方式有几个记住之后很管用的性质。

• 位置不止一处。 主目录下的 ~/.codex/AGENTS.md 这样的全局配置，和仓库一侧的 AGENTS.md 都会被读取。
• 会从仓库根目录朝着工作目录依次拼接。 也就是说，放在子目录里的 AGENTS.md 因为是后拼接上去的，比上层的指示作用更强。
• 总大小有上限。 默认在 32 KiB 左右就会被截断，所以“先全部写上去再说”会让后面的内容掉光。字符编码的规则写得短一些、放在靠前的位置更安全。

正因为有这 3 点，字符编码规约在实务上应当 写进仓库根目录的 AGENTS.md，写得短，并且放在靠前的位置。如果子目录一侧还有另一套写入规约，那一套就会胜出。

flowchart TB
    accTitle: AGENTS.md的读取方式
    accDescr: AGENTS.md会同时读取主目录一侧和仓库一侧，并从根目录朝工作目录依次拼接，后拼接的下层作用更强，总大小默认在32KiB左右被截断，因此字符编码规约要短且靠前地写在根目录的示意图。
    b1["主目录一侧的AGENTS.md"] --> b3["从根目录朝工作目录拼接"]
    b2["仓库一侧的AGENTS.md"] --> b3
    b3 --> b4["后拼接的下层作用更强"]
    b3 -.-> b5["默认在约32KiB处截断"]
    b4 --> b6["规约写在根目录，短且靠前"]
    b5 -.-> b6

图2：AGENTS.md 有拼接顺序和大小上限，所以规约要短小地放在根目录靠前处。

1. 先下结论

在 Windows 环境下要减少 Codex 的乱码问题，最容易见效的是 先把字符编码的作业流程固定下来。

特别有效的大致是下面这些规则。

• 含日文的现有文件，读之前先确认 encoding 候选、有无 BOM、换行符
• 疑似乱码的文件，在有把握之前不允许保存
• 现有文件 维持原本的 encoding、BOM、换行
• 新建文件 依照仓库规约向 UTF-8 系靠拢
• 写入时 只允许使用能明确指定 encoding 的方法
• 保存后 重新读取并验证代表性的日文行

用实务上的简短说法，基本就是这几句。

• 读之前先确认
• 有疑虑就禁止保存
• 现有维持原状，只有新建用 UTF-8
• 禁止模糊的写入路径
• 最后重新读取确认

flowchart TB
    accTitle: 防止字符编码问题的5个步骤
    accDescr: 依次展示读之前先确认、有疑虑就禁止保存、现有维持原状只有新建用UTF-8、禁止模糊的写入路径、最后重新读取确认这一实务上的简短说法的示意图。
    c1["读之前先确认"] --> c2["有疑虑就禁止保存"]
    c2 --> c3["现有维持原状，只有新建用UTF-8"]
    c3 --> c4["禁止模糊的写入路径"]
    c4 --> c5["最后重新读取确认"]

图3：想要固定下来的作业流程，可以收敛成这 5 步。

反过来说，下面这些指示很危险。

• “帮我修一下乱码”
• “全部改成 UTF-8”
• “输出一份 CSV”
• “你看着办”
• “先存起来看看”

它们的共同点是 没有写明 Codex 应该在哪一步停下来。在乱码对策里，不能只指示做什么，还必须指示 在哪一步停止保存。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 22 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 为什么在 Windows 上容易出现乱码问题

真正的问题不是 Codex 不擅长处理日文，而是 Windows 一侧的现有资产里同时存在多种字符编码和多条写入路径。

在实务中，这样的混杂并不罕见。

• 较新的源代码和 Markdown 是 UTF-8
• 旧的 CSV、TXT、日志、配置是 CP932 系
• 一部分输出和工具产物是 UTF-16 系
• 编辑器、shell、Excel 产生的输出，保存路径各不相同
• 换行符也混用 LF 和 CRLF

在这种状态下，Codex 只要有 1 次解读错误，就可能 把没读懂的字符串当成“已经读懂的内容”继续进入下一步编辑。如果就这样保存，这次就不再是显示层面的问题，而会被固定为 文件本身的损坏。

所以乱码对策归根结底，就是 如何管理 I/O 流程 的问题。

flowchart TB
    accTitle: 问题如何被固定为损坏
    accDescr: 在多种字符编码和多条写入路径并存的资产里，Codex只要有一次解读错误，就会把没读懂的字符串当成读懂的内容继续下一步编辑，并在保存的那一刻从显示层面的问题被固定为文件本身损坏的示意图。
    d1["多种encoding与写入路径并存"] --> d2["一次错误的解读"]
    d2 --> d3["没读懂就进入下一步编辑"]
    d3 --> d4["保存后被固定为损坏"]
    d4 -.-> d5["对策的本体是I/O流程管理"]

图4：乱码始于显示问题，在保存的瞬间被固定为损坏。

2.1 先统一 4 个术语

把后面反复出现的词，在这里先统一一下。

要紧的是，CP932 和 UTF-8 都没有写在文件自身里。只要没有 BOM，文件就不会自报“应该怎么读”。所以读之前的确认是必要的。

flowchart TB
    accTitle: 文件不会自报encoding
    accDescr: 是CP932还是UTF-8并没有写在文件自身里，只要没有BOM，文件就不会说明该怎么读，因此需要在读之前先确认的示意图。
    e1["文件内容只是字节序列"] --> e2{"有没有BOM"}
    e2 -->|"有"| e3["可判断为Unicode系"]
    e2 -->|"没有"| e4["是UTF-8还是CP932要看内容判断"]
    e4 --> e5["所以读之前需要确认"]

图5：没有 BOM 的话，文件不会告诉你该怎么读。

3. 最先要向 Codex 固定下来的规则

3.1 读之前，先确认 encoding 候选、BOM 和换行

第一条规则是这个。

在读取含日文的现有文件之前，先确认当前的 encoding 候选、有无 BOM、换行符；如果可疑，就不要照原样进入内容解读。

关键在于把动作换成 “在读文本之前，先看清楚文件的前提”。

具体要怎样让它确认

只写一句“确认一下”，Codex 和人都会各做各的。把确认步骤也一并写进指示 会更稳定。下面的写法在 Windows PowerShell 5.1 和 PowerShell 7 上都能运行。

首先，用十六进制查看开头的字节。有没有 BOM 在这里就能定下来。

$path  = 'C:\work\orders.csv'
$bytes = [System.IO.File]::ReadAllBytes($path)

# 以十六进制显示开头 16 个字节
$head = $bytes[0..([Math]::Min(15, $bytes.Length - 1))]
($head | ForEach-Object { $_.ToString('X2') }) -join ' '

后面的代码块会直接沿用这里生成的 $path 和 $bytes。读法如下。

接下来统计换行符。“LF 和 CRLF 混在一起”在这里就能发现。

$crlf = 0; $loneLf = 0; $loneCr = 0
for ($i = 0; $i -lt $bytes.Length; $i++) {
    if ($bytes[$i] -eq 0x0A) {
        if ($i -gt 0 -and $bytes[$i - 1] -eq 0x0D) { $crlf++ } else { $loneLf++ }
    }
    elseif ($bytes[$i] -eq 0x0D -and ($i -eq $bytes.Length - 1 -or $bytes[$i + 1] -ne 0x0A)) {
        $loneCr++
    }
}
"CRLF=$crlf  LF=$loneLf  CR=$loneCr"

最后缩小 encoding 候选。没有 BOM 时，能否作为 UTF-8 被严格解码 是最快见效的判定材料。UTF-8 对字节序列有很强的约束，所以把 CP932 的文件按 UTF-8 严格读取，多半会在中途失败。

# 第 2 个参数的 $true 表示“遇到非法字节序列就抛出异常”
$strictUtf8 = New-Object System.Text.UTF8Encoding($false, $true)
try {
    $null = $strictUtf8.GetString($bytes)
    '可以作为 UTF-8 无矛盾地解码'
}
catch {
    '不是 UTF-8。请尝试 CP932 等候选'
}

想按 CP932 读一遍看看时，要明确写出代码页编号。

# PowerShell 6.2 及以后可以直接指定代码页编号
Get-Content -Path $path -Encoding 932 -TotalCount 3

# 在 Windows PowerShell 5.1 中，Default 是系统的 ANSI 代码页。日文 Windows 上就是 CP932
Get-Content -Path $path -Encoding Default -TotalCount 3

严格解码通过了，并不等于“确定是 UTF-8”。 只含 ASCII 的文件两边都能通过。最终还是要让它用眼睛确认代表性的日文行是否读得出来。

flowchart TB
    accTitle: 读之前的确认步骤
    accDescr: 先用十六进制查看开头字节判定有无BOM，再统计换行符，然后用严格UTF-8解码缩小encoding候选，最后用眼睛确认代表性的日文行是否读得出来的步骤示意图。
    f1["用十六进制查看开头字节"] --> f2["判定有无BOM"]
    f2 --> f3["统计换行符"]
    f3 --> f4["用严格UTF-8解码缩小候选"]
    f4 --> f5["目视确认代表性日文行"]
    f4 -.-> f6["只含ASCII时两边都能通过"]

图6：读之前的确认，按字节、换行、解码、目视的顺序推进。

3.2 疑似乱码的文件，不要在臆测的状态下保存

这一条尤其重要。

怀疑乱码时，调查阶段按 read-only 处理，在对解读有把握之前禁止覆盖写入。

人也是一样，不要保存一个自己还没读懂的文件。“看起来有点坏，但大概就是这样吧”就保存下去，损坏就成了定局。

3.3 现有文件维持原状，只有新建文件默认用 UTF-8

在乱码对策的语境里，出人意料地危险的是“全部统一成 UTF-8”。

最终把整个 repo 向 UTF-8 靠拢的判断是可能存在的，但那件事更适合当作 单独的任务，一边看 diff 和影响范围一边做。日常改动中，下面这套做法比较稳定。

• 编辑现有文件时，维持原本的 encoding
• 新增文件时，按 repo 规约用 UTF-8 系创建
• 如果现有文件确实需要转换，就和普通的功能修改分开

3.4 默认不允许使用模糊的写入路径

在 Windows 上最容易出问题的，是“反正只是随手输出一下，用 shell 随便写写”。

• 用重定向直接吐出去
• 用便捷命令直接保存
• 把临时产物直接升格为正式文件

这类路径 往往没有明确指定 encoding，是问题的温床。所以对 Codex 来说，把写入手段的选择方式也固定下来更安全。

“默认的 encoding”因 PowerShell 版本而异

这一点不知道就一定会踩。PowerShell 默认的写入 encoding 因版本而异。

也就是说，即使是同一个脚本，在 5.1 上跑还是在 7 上跑，会生成不同的文件。“在开发机上没问题，到了现场的服务器就坏了”，标准剧本就是这个。

此外 5.1 一侧还有一个性质：只要指定 Unicode 系的 encoding，就一定会加上 BOM。-Encoding UTF8 是带 BOM 的 UTF-8。

所以，写入要每次都明确指定。

# 为了让本节可以独立运行，先定义变量
$path    = 'C:\work\orders.csv'
$newPath = 'C:\work\orders-new.csv'
$lines   = @('顧客コード,顧客名', 'C0001,株式会社サンプル')

# 现有文件是 CP932 就仍按 CP932 写回去（PowerShell 6.2 及以后）
Set-Content -Path $path -Value $lines -Encoding 932

# 在 Windows PowerShell 5.1 上与系统的 ANSI 代码页保持一致
Set-Content -Path $path -Value $lines -Encoding Default

# 以无 BOM 的 UTF-8 创建新文件（PowerShell 7）
Set-Content -Path $newPath -Value $lines -Encoding utf8NoBOM

如果想让整个会话的默认值统一，也可以用 $PSDefaultParameterValues。不过这是 只对该会话生效的设置，所以以“我们的配置文件里已经写了”为前提的操作手册，在别人的环境里会坏掉。

$PSDefaultParameterValues['*:Encoding'] = 'utf8NoBOM'

用 > 代替 Out-File 的写法，在 5.1 及以后内部也只是调用 Out-File，所以默认 encoding 带着同样的问题。禁止重定向，只允许使用能写明 encoding 的 cmdlet 或 .NET API，才是最可靠的做法。

flowchart TB
    accTitle: 同一个脚本也会生成不同的文件
    accDescr: PowerShell默认的写入encoding因版本而异，所以同一个脚本在5.1上跑还是在7上跑会生成不同的文件，禁止重定向、只允许使用能写明encoding的cmdlet或.NET API才可靠的示意图。
    g0["同一个脚本"] --> g1["在Windows PowerShell 5.1上执行"]
    g0 --> g2["在PowerShell 7上执行"]
    g1 --> g3["生成encoding不同的文件"]
    g2 --> g3
    g3 -.-> g4["只允许使用能明确指定encoding的路径"]

图7：默认的 encoding 因版本而异，所以写入要每次明确指定。

3.5 保存后重新读取，确认代表性的日文行

“保存成功了”和“没有损坏”不是一回事。

要紧的是保存之后再读一遍代表性的日文行，确认下面这些点。

• 有没有混入替换字符 U+FFFD
• ? 有没有莫名增多
• 是不是变成了只有 BOM 或换行的巨大 diff
• 业务上没有改动的日文是否原样保留

3.6 出现异常迹象时，先汇报再修

在字符编码问题上，与其强行让它修，不如 让它停下来汇报，损失更小。

比如出现下面这些迹象时，先按异常处理更安全。

• U+FFFD 增多
• ? 增多
• 出现预期之外的 BOM 变化
• 只有换行的大量 diff
• 只有日文行发生了不自然的大幅变化

flowchart TB
    accTitle: 出现异常迹象就停下来汇报
    accDescr: 出现替换字符U+FFFD或问号增多、预期之外的BOM变化、只有换行的大量diff等迹象时，与其强行让它修，不如停下来汇报，损失会更小的示意图。
    h1["U+FFFD或?增多"] --> h4["先按异常处理"]
    h2["预期之外的BOM变化"] --> h4
    h3["只有换行的大量diff"] --> h4
    h4 --> h5["先停下来汇报，而不是先去修"]

图8：出现异常迹象时，不要让它去修，而要让它停下来汇报。

4. 如果要写成简短的指示文

作为每次任务附带的简短版本，下面这些分量就已经足够有效。

本次作业请把避免字符编码问题放在最优先。

- 含日文的现有文件，读之前先确认 encoding 候选、有无 BOM、换行符
- 疑似乱码的文件，不要在臆测的状态下保存
- 现有文件维持原本的 encoding / BOM / 换行
- 新建文件按 repo 规约用 UTF-8 系创建
- 写入只使用能明确指定 encoding 的方法
- 保存后重新读取，确认代表性的日文行没有损坏
- 如果出现 `U+FFFD`、`?` 增多、BOM / 换行异常、大量 diff，就作为异常汇报

如果目标文件已经确定，再加上这 1 行会相当稳定。

目标文件: <paths> / 代表性字符串: "<examples>"

给出代表性字符串 相当有效。因为这样可以让 Codex 持有“这段日文不能坏”的具体监视点。

flowchart TB
    accTitle: 用代表性字符串交出监视点
    accDescr: 给出目标文件和不能被破坏的代表性字符串，就能让Codex持有这段日文不能坏的具体监视点，指示会相当稳定的示意图。
    i1["指定目标文件"] --> i3["持有具体的监视点"]
    i2["不能被破坏的代表性字符串"] --> i3
    i3 --> i4["指示会相当稳定"]

图9：目标文件和代表性字符串这 1 行，把验证的着力点固定了下来。

5. 想常设在 AGENTS.md 里的模板

与其把同一条提醒说很多遍，不如放进 AGENTS.md。下面是面向在 Windows 上处理日文文件的 repo、偏实用的模板。

# Text Encoding Rules

## Scope
This repository may contain Japanese text and mixed legacy encodings.
Avoid mojibake and accidental re-encoding above all else.

## Mandatory Rules
- Before reading or editing an existing text file that may contain Japanese, first determine:
  - likely encoding
  - BOM presence
  - newline style
- If mojibake is suspected, do not save the file until the encoding interpretation is credible.
- Preserve the original encoding, BOM, and newline style for existing files.
- Treat "convert to UTF-8" as a separate, explicit task.
- New files should follow repository convention. If there is no clear rule, prefer UTF-8 and state whether BOM is used.
- Do not use ambiguous write paths by default, such as shell redirection or convenience commands without explicit encoding control.
- After writing, reopen the file and verify representative Japanese lines.
- If any of the following appears, stop and report:
  - replacement characters
  - unexpected `?`
  - unintended BOM change
  - unintended newline conversion
  - whole-file diffs without a business reason

## Reporting Format
For each changed text file, report:
- path
- detected or preserved encoding
- BOM presence
- newline style
- how verification was performed
- whether representative Japanese text remained intact

这份模板的好处在于，它固定下来的不只是 怎么编辑，还有 怎么才不弄坏。尤其是，

• If mojibake is suspected, do not save ...
• Treat "convert to UTF-8" as a separate, explicit task.

这 2 行相当有效。

5.1 日文版模板

如果团队的评审是用日文进行的，AGENTS.md 用日文有时更好运维。内容是一样的。

# 文字コードの取り扱い規約

## 適用範囲
このリポジトリには日本語テキストと、レガシーな文字コードのファイルが混在します。
文字化けと、意図しない再エンコードを、他の何よりも優先して避けてください。

## 必ず守ること
- 日本語を含む可能性がある既存テキストファイルは、読む前に次を確認する。
  - encoding の候補
  - BOM の有無
  - 改行コード
- 文字化けが疑われる間は、解釈に確信が持てるまでそのファイルを保存しない。
- 既存ファイルは、元の encoding、BOM、改行コードを維持する。
- 「UTF-8 に変換する」は、機能修正とは別の独立したタスクとして扱う。
- 新規ファイルはリポジトリ規約に従う。規約がなければ UTF-8 を選び、BOM の有無を明記する。
- encoding を明示できない書き込み経路を既定で使わない。
  シェルのリダイレクトや、encoding を指定できない便利コマンドが該当する。
- 書き込んだあとは開き直し、日本語の代表行が壊れていないことを確認する。
- 次のいずれかが出たら、修正しようとせず、いったん止めて報告する。
  - 置換文字 U+FFFD の増加
  - 想定していない `?` の増加
  - 意図しない BOM の変化
  - 意図しない改行コードの変換
  - 業務上の理由がないファイル全体の差分

## 報告のしかた
変更したテキストファイルごとに、次を報告する。
- パス
- 検出した、または維持した encoding
- BOM の有無
- 改行コード
- どうやって検証したか
- 日本語の代表文字列が無事だったか

英文版和日文版只放一份就够了。两份都放会消耗双倍的分量，考虑到 AGENTS.md 的读取大小上限，只定其中一份更安全。

6. NG 指示与 OK 指示

在乱码对策中，指示的粒度对结果影响相当大。

关键在于，必须把 动手之前的确认 和 保存之后的验证 都写出来。

flowchart TB
    accTitle: 把NG指示改成OK指示的模式
    accDescr: 像帮我修一下乱码这样的指示没有写明应该在哪里停下来，因此要补上动手之前的确认和保存之后的验证，改成包含在哪里停止保存的指示的示意图。
    j1["“帮我修一下乱码”"] --> j2["没有写明停在哪里"]
    j2 -.->|"补写"| j3["动手之前的确认"]
    j2 -.->|"补写"| j4["保存之后的验证"]
    j3 --> j5["包含在哪里停下来的指示"]
    j4 --> j5

图10：与 NG 指示的差别，在于有没有确认、验证，以及停下来的位置。

7. 评审时的检查清单

让 Codex 干完活之后，把人工一侧要看的检查点也固定下来，会更稳定。

• 每个变更文件的 encoding / BOM / 换行的处理方式是否有汇报
• 是不是只有日文行发生了不自然的大幅变化
• 有没有冒出只有换行的大量 diff
• U+FFFD 或 ? 有没有增多
• 有没有与业务变更无关的整文件 diff
• CSV 或日志有没有出现列错位、引号错乱

乱码对策中要紧的是，比起增加成功的 diff，更该尽早刹住可疑的 diff。

8. 总结

在 Windows 环境下让 Codex 处理日文文件时，最先见效的并不是把 PC 一侧配置到完美，而是 向 Codex 讲清楚字符编码的作业流程。

特别要记住的是这 5 点。

• 读之前先让它确认 encoding / BOM / 换行
• 疑似乱码时，不要让它在臆测的状态下保存
• 现有文件维持原状，只有新建文件向 UTF-8 系靠拢
• 禁止模糊的写入路径
• 保存后重新读取，确认代表性的日文行

然后，与其每次都说一遍，不如写进 AGENTS.md。这才是最贴合实务的做法。

乱码对策的核心，不在于拜托它“好好处理日文”，而在于 把可以保存的条件和必须停下的条件写成明文。写到这个程度，Codex 在 Windows 上也会变得相当好用。

flowchart TB
    accTitle: 核心是把条件写成明文
    accDescr: 乱码对策的核心不是拜托它好好处理日文，而是把可以保存的条件和必须停下的条件写成明文的示意图。
    k1["拜托它“好好处理日文”"] -.-> k2["这里不是核心"]
    k3["写明可以保存的条件"] --> k5["Codex在Windows上也会变得好用"]
    k4["写明必须停下的条件"] --> k5

图11：核心不在于怎么拜托，而在于把保存和停止的条件写成明文。

9. 参考资料

• OpenAI Codex docs, Best practices
• OpenAI Codex docs, Custom instructions with AGENTS.md
• OpenAI Codex docs, Windows
• Microsoft Learn, about_Character_Encoding
• Microsoft Learn, Code Page Identifiers
• Microsoft Learn, Byte order mark

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

在 Windows 上使用 Codex 时，日文为什么会乱码？

真正的原因不是 Codex 不擅长处理日文，而是 Windows 一侧的现有资产里同时存在 UTF-8、CP932、UTF-16 系等多种字符编码和多条写入路径。在这种状态下，Codex 只要有一次解读错误，就可能把没读懂的字符串当成“已经读懂的内容”继续进入下一步编辑。如果就这样保存，问题就不再是显示层面的，而会被固定为文件本身的损坏。所以归根结底，乱码对策就是如何管理 I/O 流程的问题。

要防止 Codex 产生乱码，应该给出什么样的指示？

最有效的是先把字符编码的作业流程固定下来。具体是这 5 点：含日文的现有文件在读之前先确认 encoding 候选、有无 BOM、换行符；疑似乱码的文件在有把握之前不允许保存；现有文件维持原本的 encoding，只有新建文件采用 UTF-8 系；只允许使用能明确指定 encoding 的写入方式；保存后重新读取并验证代表性的日文行。再把目标文件和“绝对不能被破坏的代表性字符串”一起交给它，会更加稳定。

为什么不能给出“帮我修一下乱码”“全部改成 UTF-8”这类指示？

这两种都是危险的指示。因为其中没有写明 Codex 应该在哪一步停止保存，很容易在臆测的状态下被保存，从而让损坏就此固定下来。“全部改成 UTF-8”尤其危险：编辑现有文件时应当维持原本的 encoding、BOM、换行，而把整个 repo 的 UTF-8 化拆成一个单独的任务，一边看 diff 和影响范围一边推进才安全。取而代之，应当像“先区分是文件损坏还是显示端的问题，不要在臆测的状态下保存”那样，把动手之前的确认和保存之后的验证一并写进指示。

字符编码的规则写进 AGENTS.md 会更好吗？

与其每个任务都重复同样的提醒，不如常设在 AGENTS.md 里更有效。可以把读之前的 encoding、BOM、换行确认，怀疑乱码期间禁止保存，现有文件维持原状，UTF-8 转换单独立项，禁止模糊的写入路径，保存后重新读取验证，以及出现异常时停下来汇报这些规则一并写进去。再进一步，把每个变更文件都要汇报 encoding、BOM、换行、验证方式的格式也固定下来，评审一侧的检查也会更稳定。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。