先说一个我最近遇到的事。一位做前端的朋友问我为什么他下载的Codex 汉化包替换进去之后界面一点变化都没有。我远程看了一眼发现他把桌面客户端版的汉化包塞进了 VSCode 插件的扩展目录里。这其实是 Codex 汉化需求里最常见的一个问题不是汉化包不对而是根本没分清自己装的是哪个客户端。Codex 这个词现在指的不再是某一个软件而是一整群东西有命令行下的 CLI 工具有 VSCode 里的 IDE 插件还有带独立窗口的桌面客户端。三者的入口长得不一样安装路径不一样连界面文字所在的文件格式都不一样。汉化包是按客户端形态分发的装错了地方替换得再认真也白搭。这篇文章我想把你应该知道的都理一遍三种客户端怎么一眼辨认各自的汉化原理是什么下载之后往哪个目录放以及汉化之后升级失效、文字乱码这些坑怎么处理。不管你手上是 CLI、VSCode 插件还是桌面客户端照着你的客户端类型做基本都能顺利跑起来。1. 先分清你手里是哪款 Codex三种形态的辨别方法先说结论下载汉化包之前先花 10 秒钟确认你装的是哪一种。很多人卡在这一步不是不会找文件而是连自己装的是什么都没搞清楚。1.1 CLI 命令行版在终端里敲 codex 的那个CLI 版是最早火起来的一版也是目前社区讨论里出现频率最高的形态。安装方式通常是npm install -g openai/codex这一类全局包管理命令装完之后你在任意终端窗口敲codex就能进到一个交互式命令行界面直接跟模型对话。判断你是不是 CLI 版最快的方法是打开终端执行codex --version能正常打印出版本号说明 CLI 装在 PATH 里了。再执行which codex这条命令会告诉你 codex 到底被安装在哪一个目录下。Windows 上对应的是where codex返回通常是一个.cmd或者.exe路径。这两个信息非常关键后文汉化时会用到。CLI 版的界面特征也很明显没有鼠标操作全靠方向键和 Enter整个界面在终端里渲染。如果你看到的Codex长成这个样那你的汉化对象就是 CLI。1.2 IDE 插件版VSCode 扩展面板里的那个第二种形态是在编辑器里使用的插件。最常见的场景是 VSCode 左侧扩展栏搜索OpenAI Codex或Codex点安装后右侧会多出一个聊天面板或者右键菜单里出现 Codex 相关命令。要验证你是不是插件版就看一点这个 Codex 是不是长在编辑器窗口内部。如果是那它就是扩展形式。它的安装位置也完全不同VSCode 在 Windows 上默认把扩展放在%USERPROFILE%\.vscode\extensionsmacOS/Linux 则通常在~/.vscode/extensions下。插件版的汉化几乎不影响你日常使用但如果你实在想汉化操作路径跟 CLI 完全不同下面我会单独讲。1.3 桌面客户端版独立窗口的图形界面第三种是带独立窗口的桌面应用很多刚接触 Codex 的人下的其实是这个。它的特征是打开之后是一个独立的应用程序窗口有顶栏、有菜单界面是典型的图形程序布局。桌面客户端在 Windows 上通常安装在%LOCALAPPDATA%\Programs\codex一类目录下macOS 则在/Applications/Codex.app里。注意桌面版安装时经常会有安装在当前用户目录下和全机安装两个选项个人目录和系统目录的汉化路径不一样这个细节后文会特别提醒。1.4 一张表帮你做最终确认客户端形态打开入口判别命令/位置汉化资源典型位置CLI 命令行版终端敲 codexcodex --versionwhich codex全局 node_modules 或安装目录内IDE 插件版编辑器侧边栏/右键菜单VSCode 扩展目录.vscode/extensions下的扩展包桌面客户端版独立应用窗口安装目录/程序文件夹resources 目录下的语言文件或 asar 包如果你对完这张表还是拿不准那就再简单一点你在哪里启动它它就属于哪一类。终端启动的是 CLI编辑器内激活的是插件双击图标准开的是桌面版。确认完形态我们才能聊下一步汉化包到底改的是什么。2. 汉化包本质上在改什么不同客户端的语言资源差异很多新手拿到汉化包后习惯性做的第一件事是把压缩包里的文件往外一拖覆盖到安装目录里。这个动作本身没有错但汉化包的设计逻辑不是所有文件随便覆盖而是针对特定客户端内的语言资源做替换。2.1 界面文案与逻辑代码是分开的先普及一个常识所有带界面的软件基本上都会把逻辑代码和显示文案分开存放。逻辑代码决定程序怎么跑显示文案决定你看到什么字。好的产品会再把文案按语言拆成独立的语言文件这样要多语言的时候不需要改代码只要加对应的语言资源文件即可。Codex 这类工具也不例外。CLI 版的文案藏在安装包内部的资源目录里IDE 插件的文案通常在扩展目录下的 nlsnative language support文件里桌面客户端的文案则在 resources 目录下的 locale 或 asar 包里。汉化包做的事说穿了只有一步用汉化过的语言资源替换掉原来的英文资源。2.2 官方为什么没有现成的中文包很多人会问为什么等社区做汉化官方不做据我了解核心原因是这类 AI 编程工具的主要使用界面本来就很极客向官方把产品重心放在功能迭代和模型能力上界面语言的优先级排得非常靠后。同时这类软件迭代极快平均一两周就会更新一次版本如果官方维护一套完整的中文界面文案等于每次发版都要同步翻译一份成本很高。所以中文界面这件事基本就是社区汉化包在做。这也就带来一个连锁反应汉化包通常落后于官方版本而且每次官方大版本更新汉化包很可能就失效。这个规律你要有心理准备。2.3 汉化包的三种发布形态社区汉化包在市面上主要有三种形态你下载的时候要先辨认清楚。第一种是绿色汉化版直接把整个客户端的汉化文件单独打一个包你按对应客户端版本号去下载覆盖后完成。这种方式最简单但对版本号的要求最严格跨版本覆盖很容易起不来。第二种是语言补丁包里面只有语言资源文件比如一个 zh-CN 的 json 文件或者 locale 文件。下载后你要手动把它放到指定目录。这个方式风险较低通常只影响显示文案不影响逻辑。第三种是配置式汉化不发文件而是教你修改配置文件、环境变量或者内置设置项让程序输出跟随你的系统语言或者指定的语言偏好。这个方式最干净但因为绕过了语言库本身覆盖率有限。这三种形态各有优劣。我个人的建议是能优先用配置式汉化就用配置式其次是语言补丁包最后才是整体绿色汉化版。原因很简单整体汉化版跟你本地的客户端版本一不匹配轻则汉化无效重则界面直接打不开。这也解释了为什么标题里强调先认清你装的是哪个客户端——因为每一种汉化包在发布时都是绑定客户端形态和版本号的。你拿 CLI 版的汉化包去替换桌面版文件路径对不上自然一点反应都没有。3. CLI 版汉化实操三处入手按顺序来接下来进入正题。我们先讲覆盖用户最多的 CLI 版。3.1 先定位安装目录前面提到过用which codexWindows 用where codex找到命令行入口然后往上一级就是程序本体所在目录。如果是 npm 全局安装通常在 Node.js 的全局node_modules下比如npm root -g这个命令会直接输出全局 node_modules 的绝对路径。你进去之后找到openai/codex或者名称类似的包目录这就是 CLI 版的根目录。3.2 方式一通过配置文件让会话输出走中文CLI 版最值得先尝试的其实是配置式的汉化。Codex CLI 本身保留了一些语言偏好相关的配置项虽然部分界面菜单还是英文但你可以在配置文件里把交互时默认使用的语言描述成中文。具体来说在用户目录下找到 Codex 的配置目录一般是~/.codex或者~/.config/codex在配置文件里做对应修改。有部分版本直接支持指定 locale 项设成 zh_CN 后部分内建提示文本就会切换成中文。打开配置文件后找到语言相关的字段修改成类似这样的形式{ language: zh-CN, preferred_locale: zh_CN }保存后重启终端重新进入codex你会发现在对话过程中模型默认使用中文回复的设定会生效。注意这里有个边界问题它主要影响的是会话默认语言和部分内建提示界面框架本身是否全中文化取决于该版本是否内置中文语言资源。没有内置的话你还需要配合第三种方式。3.3 方式二设置语言环境变量很多命令行程序在启动时都会读取系统的语言环境变量Codex CLI 也会读取。如果你系统界面本身就是中文一般环境变量LANG会带着zh_CN.UTF-8这样的值。在修改前你可以在终端里执行echo $LANG如果你看到输出是en_US.UTF-8说明当前终端强制走了英文。那么可以在启动 Codex 时临时用中文环境变量LANGzh_CN.UTF-8 codexWindows 的 PowerShell 里写法是$env:LANGzh_CN.UTF-8; codex这个方法的最大优点是零侵入不修改任何安装文件系统更新、卸载重装都不影响。但缺点也很明显如果程序的语言资源包本身没有中文环境变量只是让程序去加载中文资源而资源根本不存在那就不会真正生效。所以这种方式适合那些本身已经带中文资源、只是自动判定失效的情况。3.4 方式三替换 CLI 包内的语言资源文件如果前两种方式都搞不定确定你下的是 CLI 版汉化包那就只能动资源文件了。先备份原来的语言目录或文件然后找到汉化包里对应版本的语言资源按目录结构放回原位。具体来说进到openai/codex包目录之后先看一下内部有没有locales、messages或者i18n这一类目录。有的话打开看一眼里面文件的命名规则。以我见过的情况一般是每个语言一个文件或者一个子目录英文是en.json或者en-US文件夹中文就对应zh-CN.json或者zh-CN文件夹。替换的时候记住一个原则先备份再覆盖最后验证。备份命令很简单假设你当前在包目录下cp -r locales locales.bak然后把汉化包里对应语言资源复制到位cp -r /path/to/zh-CN locales/Windows 上用资源管理器拖放也是一样的逻辑。做完之后再执行codex看界面是否变化。如果没反应大概率是版本号对不上需要去重新找一个与你客户端版本匹配的汉化包。3.5 升级后怎么办CLI 版的更新频率很高今天汉化成功过两周npm update一下就又打回原形。我的习惯是每次升完级先不急着汉化等一两天看社区有没有对应新版本的汉化包避免自己手动改完又被版本校验拦下来。升级时也可以把语言资源改动记成一个批量脚本版本一变重新执行一次比每次手工复制省心得多。4. IDE 插件版汉化VSCode 扩展目录与 nls 文件先说明一点如果你平时主力工作台是 VSCode插件的汉化需求其实没那么强烈因为插件界面元素少主要交互都在聊天面板里而聊天面板里的回复内容本来就跟着模型走完全可以设置成中文回复。真正需要汉化的其实只是插件自身的菜单项、按钮文案这些零散组件。4.1 找到扩展的安装路径要让插件汉化第一步是找到这个扩展安装到了哪里。Windows 上是在%USERPROFILE%\.vscode\extensionsmacOS/Linux 是~/.vscode/extensions在这个目录下找到名字里带codex或者openai的文件夹进去之后看结构。4.2 搞清楚扩展的多语言机制VSCode 扩展有一套自己的国际化机制扩展开发者会在包里放一个package.nls.json作为英文默认文案然后在相同位置放package.nls.zh-cn.json放中文文案插件会按 VSCode 显示语言自动加载对应文件。如果你打开插件目录发现只有package.nls.json没有package.nls.zh-cn.json说明官方没做中文资源。这时候社区汉化的做法通常就是根据package.nls.json里的键值对照翻译补一个package.nls.zh-cn.json放进去。4.3 实操补一个中文语言文件先打开package.nls.json你可能会看到类似结构{ codex.command.start: Start Codex Session, codex.command.stop: Stop Codex Session, codex.view.title: Codex }不要动原始文件。把同样的这个 JSON 拷贝一份改名为package.nls.zh-cn.json然后把每个 value 翻译成中文{ codex.command.start: 开始 Codex 会话, codex.command.stop: 结束 Codex 会话, codex.view.title: Codex }保存之后重启 VSCode。重点来了VSCode 的界面语言本身必须是中文。如果你的 VSCode 界面还是英文的那它不会去加载 zh-cn 这个 nls 文件。要先把 VSCode 自身的显示语言切换成中文通过安装 Chinese Language Pack 扩展或修改 locale.json插件的中文资源才会被自动加载。如果嫌手动编辑太累直接找一个适配你插件版本号的汉化包把里面的package.nls.zh-cn.json复制进扩展根目录即可。注意扩展更新的时候目录会被整体替换汉化文件会丢需要重新补。4.4 为什么要保留英文原文件我给这个插件补中文文案的时候会保留package.nls.json原封不动。为什么因为 VSCode 的插件更新机制是整包覆盖如果我在英文原文件上直接改下次插件自检或更新时大概率会出现异常而且万一汉化包有翻译错误你想回退都没有干净的原文件可用。多留一份备份成本几乎为零但出问题时能救你一命。5. 桌面客户端版汉化资源目录和 asar 包桌面客户端是最接近普通用户认知的一种形态也是汉化包版本错配的重灾区。前面那位朋友的问题就出在这他把桌面版的汉化包放进了 VSCode 插件目录。5.1 定位主程序安装目录Windows 上桌面版 Codex 的默认安装位置一般在%LOCALAPPDATA%\Programs\Codex或%APPDATA%\Codex。你在桌面上右键图标选择打开文件所在位置就能定位到主程序 EXE 所在的目录。macOS 上则是/Applications/Codex.app右键点击选择显示包内容进入Contents/Resources。5.2 语言资源到底放在哪桌面版的语言资源常见存放位置有两个。一个是在resources目录下有个app.asar之类的压缩包程序的核心资源和文案都被打在里面要改它需要先用 asar 工具把包解开替换文本后再打包回去。另一个是独立的locales目录里面直接放着各种语言的.pak文件或 json 文件这种情况就简单很多找到en-US.pak对应的中文 pak 文件或者直接替换其中的字符串资源。不同版本的桌面客户端结构差异很大。建议你先用文件管理器进resources目录看一眼有app.asar就先走 asar 流程有locales就直接替换语言文件。5.3 asar 解包与回填如果你确定语言资源在 asar 包里需要先确保安装了 asar 工具。npm install -g electron/asar假设主程序目录是C:\Users\you\AppData\Local\Programs\Codex\resources先把包解开npx asar extract app.asar app.asar.extracted这会生成一个app.asar.extracted文件夹。进入解包后的目录找到对应的语言资源或界面文案文件把汉化包里同路径的文件替换进去然后再重新打包回 asarnpx asar pack app.asar.extracted app.asar打包完成后把新的app.asar放回原resources目录。注意操作前关闭正在运行的 Codex并且最好先把原app.asar复制一份为app.asar.bak万一打包出错还有回退的余地。5.4 目录权限与装了没生效的真相桌面版汉化踩坑最多的不是替换而是权限。很多 Windows 电脑上桌面版装到了用户目录权限自己控制还好办但如果你选择的是全机安装安装路径可能在C:\Program Files\Codex下这个目录普通用户只有读权限资源管理器直接拖文件进去经常会提示需要管理员权限你以为覆盖成功了实际上还是原文件。所以我建议桌面版用户汉化前先看一眼安装路径如果带Program Files前缀尽量用管理员权限的终端执行复制命令或者干脆避开全机安装重新装到用户目录下做汉化。6. 汉化完成后的三个高频问题都是实测过的到这里三种客户端的汉化路径都已经给出来了。最后我把实际用下来最容易踩的几个问题集中说一下。6.1 界面上出现方块或乱码替换完语言文件后如果界面出现了空心方块或乱码不要以为一定是汉化包的问题先想字体。中文字符集和英文字符集用的字体资源不一样桌面客户端如果在渲染文本时找不到合适的中文字体就会拿一个不支持 CJK 的字体来顶显示成一排空格或方块。解决思路有两个一是看看客户端设置里有没有字体选项手动指定一个常见中文字体比如微软雅黑或苹方二是如果你的汉化方式是替换 asar 里的文本检查一下是不是把 UTF-8 编码的 json 存成了其他编码编码错乱也会导致乱码重新存成 UTF-8 无 BOM 即可。6.2 汉化只生效了一半这种情况最常见的是 CLI 版。我见过很多用户把一个汉化包覆盖进去之后菜单栏变成中文了但命令输出、错误提示还是英文。原因很简单界面框架文案和运行时的日志输出是两套资源汉化包往往只覆盖前者后者走的是程序内部的字符串模板没在语言资源包里。遇到这种情况不用太纠结绝大多数汉化包应用的就是主界面中文化这个目标终端日志保持英文反而对排查问题更有帮助。如果你实在想让它也显示中文只能等该客户端版本更新语言资源或者去社区找完整覆盖的汉化包。6.3 官方一更新汉化全失效这是最让人头疼的事但其实有规律。我自己的处理原则是在汉化之前先去查看当前客户端的具体版本号然后找汉化包时优先选匹配该版本号的版本。安装完汉化之后把客户端的自动更新关掉或者至少不要一看到新版本提示就手快升级。等社区发布了适配新版的汉化包再手动升级并重新汉化这样能最大程度减少汉化失效的空窗期。6.4 多客户端并存时注意配置互相干扰如果你机器上同时装了 CLI、VSCode 插件和桌面版很多人确实这样至少我自己就是汉化时最容易出现的问题是配置互相影响。Codex 的几个客户端可能共享同一个用户目录下的配置文件。你汉化了桌面版结果 CLI 里的某个设置被桌面版启动过程悄悄改回去了或者你只是升级了插件却发现命令行里的登录态失效。我的建议是多客户端并存时先确认你平时用哪个作为主力汉化就只动那一个次要客户端保持原样。同时在升级版本前把用户目录下 Codex 的配置目录整体备份一次。这样即使汉化或升级出了问题一条命令就能把配置恢复原状不用重新登录、重新配置。我自己的习惯是每次拿到一个新版的 Codex先花半分钟确认形态再决定要不要汉化。因为用久了你会发现Codex 这类 AI 编程工具真正高频使用的部分其实是对话与生成模型输出本来就是中文能顺畅完成任务比菜单是中文还是英文重要得多。汉化只做锦上添花千万别让它变成负担。回到标题那句话先认清你装的是哪个客户端再谈汉化包怎么下载、怎么装——这一步想明白了后面基本不会再踩坑。