最近接手一个跨端项目时，团队里一个新同学跑来找我，说他的 Codex 突然全变成英文了，菜单、提示、模型回复、代码注释，一个中文都没有，问我是不是要重装。我打开他机器看了两分钟就笑了——他前一天为了"清理项目"，把根目录下一个不起眼的.md文件删了。这个文件不是文档，是 Codex 读取的行为指令文件，里面写着一句"默认使用简体中文回复"。文件一没，模型就回到了默认语言。
这件事让我意识到，"Codex中文界面恢复"这个需求，网上的答案大多跑偏了。很多人第一反应是去改操作系统的区域设置、改编辑器的显示语言、甚至去语言包里找中文选项，折腾一晚上毫无效果。原因很简单：Codex 的"中文"不是一层东西，而是四层不同机制叠在一起，每一层的控制手段完全不一样。你把该改第三层的方法用在第一层上，当然没用。这篇就按我实际的排查顺序，把这件事从头到尾拆一遍——先分清层级，再定位配置，再处理编码乱码，最后讲改崩了怎么回滚，以及怎么把这套东西固化成团队资产。适合刚上手 Codex、被英文界面卡住的新人，也适合要给团队做统一配置的维护者。
1. 先分清"中文界面"的四个层级，别在错误的层上使劲
1.1 界面外壳、模型输出、运行日志、生成产物各自归谁管
把"中文界面"当成一个整体，是排查效率最低的做法。我习惯把它拆成四层，每一层的可控性天差地别。
第一层是应用程序外壳，也就是菜单栏、按钮、设置面板、状态栏上的固定文案。这一层是编译进程序里的字符串资源，有没有中文取决于程序本身有没有做多语言支持。绝大多数同类工具在这一层只提供英文，你翻遍设置也找不到语言选项——不是你没找到，是它压根没有。这一层基本属于"不可控"，认清这一点能省下大量时间。
第二层是模型输出的自然语言，也就是它回答你问题时用的语言、解释代码时用的语言。这一层是完全可控的，控制手段是行为指令文件和对话中的话术。绝大多数人抱怨的"界面是英文"，其实抱怨的是这一层——他看着一整屏英文解释不舒服，但按钮英文他根本不介意。
第三层是运行日志和错误提示，比如执行命令的输出、依赖缺失的报错、权限被拒的提示。这一层由底层工具链产生，Codex 只是原样透传，改不了。但你可以让模型在报错之后补一句中文解释，这是很实用的折中方案。
第四层是生成产物，包括代码注释、提交信息、README、变量命名风格。这一层同样走行为指令，但它比第二层更容易"翻车"，因为模型的默认习惯是用英文写注释，指令写得不够明确时它会在中英之间反复横跳。
这四层的关系可以用一个简单表格对照，我在团队内部就是用这张表给新人做科普的：
| 层级 | 典型表现 | 可控性 | 主要控制手段 |
|---|---|---|---|
| 外壳文案 | 菜单、按钮、设置项 | 基本不可控 | 无，接受现状 |
| 模型输出 | 回答、解释、方案说明 | 完全可控 | 行为指令文件、对话话术 |
| 运行日志 | 命令输出、报错堆栈 | 不可控（透传） | 让模型追加中文解读 |
| 生成产物 | 注释、提交信息、文档 | 可控但易漂移 | 指令文件中写明硬性规则 |
我见过太多人卡在第一层，反复重装、换版本、改系统语言，最后得出结论"这个工具不支持中文"。其实他真正想要的是第二层和第四层，而这两层十分钟就能配好。所以排查的第一步永远是问自己一句：我到底是被哪一层卡住了？如果只是看不懂它说的话，那问题在第二层；如果是看不懂按钮，那确实没办法，但按钮就那么几个，用两天就记住了。
提示：在动手改任何配置之前，先用一句话描述你遇到的问题属于哪一层。描述不出来的，说明还没定位到问题，这时候改配置纯属碰运气。
1.2 为什么"之前是中文，现在变英文了"是最有价值的线索
"恢复"这个词很关键，它意味着状态曾经是对的。这比"从来没中文过"好排查一百倍，因为存在一个已知可用的基线，你只需要找出两次状态之间的差异。
我把这类"突然变英文"的原因归成五类，按我遇到的频率排序：
第一类是指令文件丢失或被忽略。最常见。文件被误删、被移动、被改名，或者项目换了根目录导致程序在新目录里找不到它。更隐蔽的一种是文件被加进了忽略规则，本地还在但没被纳入版本管理，换台机器一拉代码就没了。
第二类是配置被覆盖。升级、重装、或者跑了某个初始化命令，把用户级配置文件整个重写了一遍。这种情况的典型特征是：你自己加的内容全没了，但程序自带的默认项都在。
第三类是多套配置互相打架。同时存在用户级配置、项目级配置和环境变量，三者对同一项给出不同值，最终生效的不是你以为的那个。表现是"我明明改了，怎么没反应"。
第四类是工作目录变了。指令文件的作用范围通常是从当前目录向上查找，你在子目录里启动和在项目根启动，读到的文件可能不一样。
第五类是编码问题伪装成语言问题。文件里确实是中文，但终端编码不对，显示成一堆问号或方块，看起来像"没生效"，其实是"显示了但显示错了"。这两者的排查方向完全不同。
知道这五类之后，"恢复"就变成一个差异比对问题：找到上一次正常时的配置快照，和现在的状态逐项比对。所以我强烈建议，配置改好之后立刻做一份快照，扔进版本库。这个动作只花三十秒，将来能救你一晚上。
2. 动手前的现场勘查：三分钟搞清楚当前生效的是什么
2.1 三条配置路径与它们的优先级关系
不勘查就改配置，是新手最容易犯的错。你得先知道程序从哪几个地方读配置，以及读的顺序。
按这类工具的通用惯例，配置一般来自三个地方，优先级从高到低大致是：
- 命令行参数：启动时临时传入的，只对本次运行有效，优先级最高。
- 环境变量：在当前 shell 会话里设置的，换一个终端窗口可能就没了。
- 项目级配置：放在项目根目录的指令文件，只对当前项目生效，通常会被纳入版本管理。
- 用户级配置：放在用户主目录下的配置文件，对当前用户的所有项目生效。
这个顺序意味着一个很反直觉的结论：你在用户级配置文件里写的东西，可能被项目级文件覆盖掉。我遇到过一位同学，他在全局配置里写了"始终用中文"，但项目根目录里有一份从别处拷来的指令文件，里面明确写着"用英文回答以匹配代码风格"，两者冲突，项目级赢，他改了半天全局配置毫无效果。
所以勘查的第一步是列清单。以类 Unix 系统为例，我会依次确认这几件事：
# 1. 确认版本，不同版本配置字段可能不同 codex --version # 2. 看帮助里有没有跟配置、语言相关的启动参数 codex --help # 3. 确认用户级配置目录是否存在、里面有什么 ls -la ~/.codex/ 2>/dev/null # 4. 确认当前工作目录以及向上查找能碰到哪些指令文件 pwd ls -la AGENTS.md 2>/dev/null ls -la ../AGENTS.md 2>/dev/null # 5. 看看有没有环境变量在捣乱 env | grep -i -E 'codex|lang|locale'这五条命令跑完，你手上就有了完整的现场信息：版本号、可用参数、用户级配置内容、项目级指令文件位置、环境变量干扰项。后面所有的判断都基于这份信息，而不是猜。
Windows 用户把路径换成%USERPROFILE%\.codex\即可，查询环境变量用set | findstr /i codex或者 PowerShell 的Get-ChildItem Env:。命令不同，逻辑一样。
注意：不要跳过
--help。我见过有人花两小时手写配置，结果发现这个版本根本不读那个文件，白忙一场。花十秒看一眼帮助，能避掉一半的无效劳动。
2.2 用最小改动法验证配置到底有没有被读到
知道配置在哪，不等于知道配置有没有生效。这两件事必须分开验证，否则后面所有排查都是空中楼阁。
我的做法是在指令文件最顶上加一条"哨兵规则"，内容必须是一眼能认出来的：
# 行为指令 <!-- 哨兵规则：验证本文件是否被读取 --> 每次回答的第一行，必须原样输出：`ZH-MODE-OK`保存，然后重新启动一次会话，随便问一个问题。如果回答第一行出现了ZH-MODE-OK，说明文件被读到了；如果没出现，说明压根没读到，问题在路径或者权限上，跟语言配置无关。
这个方法的妙处在于它把"配置是否加载"和"配置内容是否正确"两个问题彻底分开了。很多人一上来就怀疑自己指令写得不好，反复修改措辞，实际上文件根本没被加载。先确认加载，再优化内容，顺序不能反。
验证通过之后，把哨兵规则删掉或者注释掉，换成正式的语言规则。正式的规则我建议写成三到五条，明确到没有解释空间：
## 语言规则 1. 所有解释性文字一律使用简体中文。 2. 代码注释使用简体中文，变量名、函数名、文件名保持英文。 3. 报错信息原样保留英文原文，在其下方另起一行给出中文解读。 4. 提交信息使用中文描述，格式为：类型: 简述。 5. 专有技术名词首次出现时保留英文原词，可用括号补充中文。第 2 条和第 3 条是最容易被忽略、也最能提升实际体验的两条。不写第 2 条，模型会在注释语言上随机漂移；不写第 3 条，它会把报错信息也"翻译"一遍，导致你复制报错去搜索时搜不到原文——这个坑我踩过，后来把原文保留写进规则里才彻底解决。
3. 让中文稳定输出的三层控制：指令、配置、话术
3.1 项目级指令文件是主力，但它有两个隐蔽的适用范围问题
项目级指令文件是控制语言输出的主力手段，因为它跟着代码走，换机器、换人、换时间都能复现。但它有两个适用范围问题，不理解就会觉得"时灵时不灵"。
第一个是查找起点。这类文件通常从当前工作目录开始，逐级向上查找。你在项目根目录启动，能找到根目录的那份；你在三层深的子目录里启动，如果中间层没有同名文件，它还是会一路向上找到根目录那份——这没问题。但如果你在某个子目录里另放了一份指令文件，那份会优先生效，覆盖上级的规则。我就遇到过子目录里遗留的测试文件把整个项目的语言规则改掉的情况，排查了很久才发现。
第二个是纳入版本管理的方式。如果这份文件被写进忽略规则，那它只存在于你本地，团队里其他人拉代码是拿不到的，新人入职自然又是英文。更麻烦的是你自己换台机器也会丢。所以我坚持把这份文件当作项目资产提交上去，并且在 README 里写一句"本项目使用中文注释规范，指令文件见根目录"。
文件内容的组织我建议分块，别写成一大段散文。我常用的结构是这样：
# 项目行为指令 ## 语言 - 解释性文字：简体中文 - 代码注释：简体中文 - 变量/函数/文件命名：英文 - 报错原文：保留英文，下方补中文解读 ## 代码风格 - 缩进 2 空格 - 字符串统一双引号 - 提交信息格式：类型: 简述 ## 禁止事项 - 不要自动生成 README - 不要修改依赖锁文件分块的好处是，将来要调整某一块，直接改对应小节，不会牵一发动全身。而且新人一眼能看懂这个项目有哪些约定，比散落在聊天记录里的口头约定靠谱得多。
3.2 用户级配置：放什么、不放什么，边界要划清楚
用户级配置文件的定位是"个人偏好"，项目级指令文件的定位是"项目约定"。这两者的边界划不清楚，就会互相打架。
我的划分原则很简单：跟具体项目无关的放用户级，跟具体项目有关的放项目级。语言大方向属于前者，项目特有的代码风格、目录结构、禁用操作属于后者。
用户级配置里我通常只放这么几项：默认模型、审批策略、是否允许自动执行、以及一些连接相关的超时设置。语言相关我倾向于不在用户级配置里写死，原因是——如果用户级设定"永远中文"，而某个项目需要英文注释（比如对外开源仓库），项目级就要去覆盖它，多一层覆盖就多一个出问题的可能。
不过有一个场景用户级配置确实该管语言：新建的空项目。这时候还没有项目级指令文件，用户级配置就是唯一的兜底。我的做法是在用户级放一份最小化的语言规则，只写"解释用中文"这一条，其余全交给项目级细化。
配置文件一般长这样（字段名以你实际版本的帮助输出为准，不同版本可能有差异）：
# 用户级配置示例 model = "默认模型标识" approval_policy = "on-request" # 部分版本支持通过 profiles 区分不同场景 [profiles.zh] # 该 profile 下的模型与审批策略这里要特别提醒一句：不要凭想象填字段。配置文件里写了一个不存在的字段，有的版本会直接报错启动失败，有的版本会静默忽略。后者更坑，因为你以为生效了，其实没生效。改完配置一定重启一次，看有没有报错或警告输出。
3.3 话术兜底：临时需求和长期规则的互补
指令文件是长期规则，话术是临时补丁。两者不是替代关系，而是互补。
什么情况下用话术？三种典型场景。第一种是临时切换，比如你平时要中文，但这次要写一份英文 Release Note，直接在对话里说"这次用英文"，不用去改文件。第二种是规则失效时的应急，发现它又开始英文了，先甩一句"请用简体中文重新回答"，把手头事情做完，回头再排查根因。第三种是试探性验证，不确定是配置没生效还是规则不够强，先用话术试一下，如果能切回中文，说明模型层面没问题，问题在配置文件。
我这几年用下来最有效的一句兜底话术是：
从现在起，所有解释、方案说明、代码注释一律用简体中文；命令输出和报错保留英文原文，另起一行给中文解读；技术名词保留英文原词。
这句话之所以有效，是因为它同时覆盖了第二层和第四层，而且给出了例外规则（报错保留原文），模型不会因为"必须全中文"而把错误信息也翻译掉。只说"用中文"往往不够，模型会把它理解成"尽量"，遇到它认为"技术内容更适合英文"的场景就自动切回去了。
另一个实用技巧是把话术做成片段，存进编辑器的代码片段库，需要时两三个字符就能展开。我自己的片段库里存了六七条不同场景的语言话术，切换起来比改配置文件快得多。
4. 中文显示了但显示错了：编码链路上的四类故障
4.1 Windows 控制台：代码页、字体、重定向三个坑
Windows 上的中文显示问题，九成出在控制台。而且它特别容易伪装成"语言配置没生效"——你看到满屏问号或者方块，第一反应是配置错了，其实是编码错了。
第一个坑是代码页。传统控制台默认用本地代码页，UTF-8 内容进去就乱。临时解决办法是启动前切换一次：
chcp 65001但这是会话级的，关掉窗口就失效。长期方案是改注册表或者用新版终端工具把默认编码设成 UTF-8。我倾向于后者，因为注册表方案在系统更新后偶尔会被重置，得重新配一遍。
第二个坑是字体。代码页对了，但字体里没有中文字形，显示出来就是方块。这个问题在等宽字体上尤其常见，很多流行的编程字体为了字形一致性，压根没做中日韩字符集。解决办法是换成带中文支持的等宽字体，或者配置字体回退链，让主字体缺失的字符自动落到备选中文字体上。
第三个坑最隐蔽——输出重定向。你在终端里看是正常的，把输出重定向到文件再打开，中文全变成乱码。原因是程序检测到输出不是交互式终端时，可能改用了不同的编码。这种情况下的解决办法是显式指定编码环境变量，或者在读取文件时用正确的编码打开。
我做过一个简单的判断流程，遇到 Windows 中文乱码时按顺序走：
| 现象 | 优先怀疑 | 验证方法 |
|---|---|---|
全是问号??? | 代码页不对 | chcp看当前值，改成 65001 再试 |
全是方块□□□ | 字体缺字形 | 换成已知支持中文的字体 |
| 终端正常、文件乱码 | 重定向编码 | 用指定编码的方式读文件 |
| 部分字正常部分乱 | 编码混用 | 检查文件本身是不是 UTF-8 |
表格最后一行值得多说一句。"部分正常部分乱"几乎可以确定是编码混用——文件前面是 UTF-8，中间混进了别的编码的字节。这种文件用任何单一编码打开都会有一半错。解决办法是先用工具检测，统一转成 UTF-8，别指望靠改显示设置修好。
4.2 macOS 与 Linux：locale 设置和字体回退
类 Unix 系统上中文显示问题少一些，但也不是没有，主要出在 locale。
locale命令能看到当前的语言环境设置。如果输出里LANG是C或者POSIX，那程序会认为你只要 ASCII，中文自然显示不正常。临时改法是在当前 shell 里导出：
export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8但这里有个坑：LC_ALL的优先级最高，一旦设了它，其他所有LC_*变量都失效。有些人为了"确保生效"直接设LC_ALL，结果把排序规则、日期格式全改成了中文格式，导致脚本里的字符串比较出现意料之外的结果。我的建议是只设LANG，需要单独控制某一项时再设对应的LC_*，尽量别碰LC_ALL。
另一个坑是shell 启动脚本的加载顺序。你把export LANG=...写进了某个配置文件，但另一个配置文件在后面又把它改回去了。这类问题表现为"明明写了却不生效"，排查方法是按加载顺序逐个检查：登录 shell 读哪些、非登录 shell 读哪些、交互式和非交互式的区别。我一般的做法是把语言相关的导出语句放在最后加载的那个文件里，确保不会被覆盖。
字体回退在 Linux 上比 macOS 更需要关注。终端模拟器、编辑器、系统字体三层都可能缺中文字形，其中任意一层缺了，显示就会出问题。排查方法是逐层单独测试：先用系统自带的文本编辑器打开一个中文文件看是否正常，再看终端里echo一段中文是否正常，最后看目标程序里是否正常。哪一层开始出问题，就锁定在哪一层。
4.3 编辑器内嵌面板与外部终端表现不一致怎么判断
现在的开发工具大多把终端嵌在编辑器里，这就带来一个新问题：同一个命令，在编辑器内嵌终端里跑正常，在系统终端里跑乱码，或者在 A 编辑器里正常、在 B 编辑器里乱码。
这种不一致说明问题不在程序本身，而在宿主环境的编码设置。编辑器内嵌终端通常有自己的编码配置和字体配置，跟系统终端完全独立。所以判断方法很直接：如果两个宿主表现不同，就对比这两个宿主的编码和字体设置，而不是去怀疑程序。
我遇到过最典型的案例是：某同学在编辑器内嵌终端里一切正常，把同样的命令写进自动化脚本跑，输出全乱。原因是脚本执行时没有继承编辑器的环境变量，用的是系统默认 locale。这类问题的根因和程序无关，纯粹是执行环境不同。
判断这类问题的通用套路是三步：第一步，找出"正常的那个环境"和"异常的那个环境"；第二步，各打印一次编码相关变量做对比；第三步，把差异项在异常环境里补上，看是否恢复正常。这三步做完基本就能定位，比盲目改配置高效得多。
5. 改崩了怎么回滚：备份、最小复现、二分定位
5.1 改之前先备份，这不是废话
我见过太多人改配置改到程序起不来，又不记得原来写了什么，最后只能重装。重装本身不麻烦，麻烦的是之前积累的其他配置全没了。
备份这件事有个技巧：备份整个目录，而不是单个文件。因为配置之间往往有引用关系，你只备份config.toml，恢复时发现还有别的文件被改了，一样白搭。我习惯的做法是：
# 改配置前打一个快照，带上时间戳 cp -r ~/.codex ~/.codex.bak.$(date +%Y%m%d%H%M) # 确认快照存在且大小合理 du -sh ~/.codex.bak.*项目级的指令文件因为已经在版本库里，天然有备份，反而不用额外操心。真正需要备份的是用户级配置目录——它在主目录下，通常不在任何版本库的管辖范围内。
恢复的时候动作要干净：先把当前目录整体挪走（别删，留着对比），再把快照拷回来。挪而不是删，是因为有时候你需要对比改坏的那份和正常的那份，找出到底是哪一行的问题。
5.2 二分法定位：从一堆配置里找出致命那一行
配置改崩之后，直接全部回滚虽然能恢复，但下次你还会踩同一个坑。更彻底的做法是找出具体哪一行有问题。
方法就是把二分查找搬过来用。假设你改动了二十行配置，先注释掉后十行，重启看是否正常。正常说明问题在后十行，再把这十行对半分，继续测。二十行最多测五次就能定位到具体某行，比逐行试快得多。
实际操作中我建议用注释而不是删除，因为注释掉的配置随时能恢复，删除就得重新敲。而且注释本身形成了一份"改了什么"的记录，排查完直接看注释就知道全部改动点。
定位到具体那一行之后，常见的几类原因值得对照一下：
- 字段名拼错：少一个字母、多一个下划线，程序不报错但也不生效。
- 值类型不对：该写字符串的写成了裸值，该写布尔值的写成了字符串。
- 字段不存在：这个版本根本不支持这个字段，静默忽略。
- 层级放错：本该在某个分节下的字段写到了顶层，或者反过来。
- 冲突覆盖：这一行本身没错，但被优先级更高的配置覆盖了。
表格对照更清楚：
| 症状 | 可能原因 | 验证方式 |
|---|---|---|
| 启动即报错 | 语法错误、字段类型错 | 逐段注释，看哪段删掉能启动 |
| 启动正常但不生效 | 字段名错、字段不存在、被覆盖 | 加哨兵规则验证是否加载 |
| 部分生效部分不生效 | 层级放错、多处冲突 | 打印所有生效来源逐项对比 |
| 改完这次生效下次失效 | 被其他配置或更新覆盖 | 检查是否有初始化命令重写配置 |
最后一行特别值得警惕。有些工具在升级或者执行某个初始化命令时会重写用户级配置，把自定义内容冲掉。如果你发现"改一次好一次，过几天又不行"，八成是这个原因。对策是把关键配置单独存一份，写个小脚本在需要时一键恢复，别指望它一直待在那儿。
6. 把语言配置做成团队资产，而不是个人手艺
6.1 目录结构与文件职责怎么划分
一个人用，配置文件随便写。一个团队用，就得讲结构。我参与过的项目里，语言配置翻车基本都是因为职责不清——有人把项目规范写进了个人配置，有人把个人偏好写进了项目文件，结果互相打架。
我推荐的划分是这样：
| 文件位置 | 职责 | 是否入库 |
|---|---|---|
| 用户主目录下的配置文件 | 个人偏好：默认模型、审批策略、超时 | 否 |
| 项目根目录的指令文件 | 项目约定：语言、代码风格、禁用操作 | 是 |
| 子目录的指令文件 | 特定模块的额外约定 | 是 |
| 个人本地覆盖文件 | 临时实验、本机特有设置 | 否，写进忽略规则 |
这个结构的关键是个人本地覆盖文件这一层。有了它，个人想临时试验新规则，就写在本地覆盖里，不会污染项目约定，也不会因为提交上去影响别人。没有这一层，个人容易直接改项目文件，改完忘了改回来，就成了团队级的坑。
另外建议在项目根目录的 README 里加一小节，说明本项目的中文规范是什么、配置在哪个文件、新人需要注意什么。这段文字不长，但能让新人少走很多弯路。
6.2 新人接入的自查清单
最后给一份我实际在用的自查清单，新人接入项目时照着走一遍，基本不会在语言配置上卡住。
- 确认版本一致：
--version输出和团队约定的一致，版本差异可能导致配置字段不兼容。 - 确认指令文件存在：项目根目录下的指令文件在不在，内容是不是最新的。
- 跑一次哨兵验证：随便问一句，看回答里有没有约定好的标记，确认文件被加载。
- 检查编码：终端里
echo一段中文，看是否正常显示，不正常先修编码再谈配置。 - 检查 locale：
locale输出里LANG不为C或POSIX。 - 检查环境变量干扰：确认没有残留的、会覆盖配置的环境变量。
- 检查忽略规则：确认指令文件没有被误加进忽略列表。
这七步走完，绝大多数问题都能暴露出来。我在团队里把这套流程写成了一页文档，新人第一次配置基本十分钟搞定，比在群里问半天高效得多。
还有一个我自己踩过的坑值得单独提一句：不要指望配置文件能跨版本稳定。工具迭代快，字段增删改很常见，半年前写得好好的配置，新版本可能就有一个字段不认了。所以我养成了一个习惯——每次升级后第一件事不是干活，是跑一遍哨兵验证，确认配置还活着。这个动作只花一分钟，但能避免你在赶进度的时候突然发现工具行为变了却不知道为什么。
至于语言这件事本身，我的真实体会是：与其追求"界面全中文"，不如把精力放在让模型的解释和注释稳定输出中文上。外壳那几个英文单词，用两周就形成肌肉记忆了，根本不构成障碍；真正影响效率的是它用英文跟你解释一段复杂逻辑，你得在脑子里翻译一遍才能判断对不对。把这个环节解决了，体验的提升是实实在在的。
: Pangolin X11的问题)
