今天继续处理 A Tour of Go 多语言翻译项目时，我终于重新验证了一个已经影响实际翻译进度的问题：
Codex 的翻译质量，究竟是真的明显低于 ChatGPT，还是之前的实验条件本身存在一个没有被充分控制的变量？
真正推动我重新做这次实验的，并不是 Codex 最近才开始支持更高推理强度。
事实上，上一次进行 ChatGPT、Codex 与 GLM-5.2 翻译质量对比时，Codex 同样已经可以选择不同的推理强度，只是当时我沿用了默认的轻度推理；而 ChatGPT 使用的是高推理强度。
当时并没有特别把“推理强度”作为主要实验变量。
而现在之所以必须重新验证，是因为另一个更加现实的问题：
目前以 ChatGPT 作为主要 TranslationUnit 翻译引擎的方案，已经无法稳定地支撑实际翻译工作继续推进。
前一篇文章中，我刚刚记录了这段调整过程：
最初，我希望 ChatGPT 在读取 GitHub 中正式导出的 retranslation batch 以后，完成整个 TranslationUnit 翻译，并生成一个 raw-responses 压缩包供本地下载和导入。
这个流程以前已经验证可以执行。
但到了新的正式批次中，稳定性开始成为真正的问题。
有时 GitHub 中的 batch 和 inputs 已经读取完成，后面的 TranslationUnit 翻译却迟迟无法真正生成；有时翻译过程停在中间，需要不断继续；即使最终生成部分结果，继续生成完整 ZIP artifact 也可能再次卡住。
后来为了降低交付复杂度，我又把方案进一步简化：
不再要求生成 ZIP，改成只生成一个 translation-result.json。
本地项目再增加：
retranslation import --translation-result
负责把 JSON 导入 raw-responses/。
从流程设计上看，这已经比 ZIP 简单很多。
但实际继续测试以后，问题仍然没有消失。
即使只是要求生成 JSON，ChatGPT 仍然可能长时间停留在“准备生成”“继续生成”的状态，却没有真正产生完整 TranslationUnit 结果。
所以现在的问题已经不是：
这个方案的自动化程度还不够高。
而是：
这个方案本身无法稳定支撑批量翻译工作持续推进。
如果 ChatGPT 仍然可以稳定完成每一个 batch，那么即使需要下载一次 JSON、再本地 import 一次，我其实完全可以继续接受。
但当真正的翻译生成过程本身都会频繁卡住以后，我就必须重新回答一个更现实的问题：
Codex 的翻译质量，现在是否已经足够接近 ChatGPT，从而可以承担正式生产翻译任务？
而更早之前，我已经做过一次专门的翻译质量实验：
那一次实验中，ChatGPT 的整体表现明显更好。
所以即使 Codex 在工程执行层面一直更加方便，我此前仍然没有直接把默认翻译引擎切换到 Codex。
原因很简单：
这个项目中，我最看重的仍然是最终翻译质量。
如果只是为了执行方便，却明显降低最终译文质量，那么这种自动化没有太大意义。
上一次实验真正证明了什么
重新回头看上一篇质量实验时，我发现一个非常值得重新验证的变量。
当时：
ChatGPT 使用的是高推理强度。
Codex 使用的是默认的轻度推理强度。
也就是说，那次实验真正能够证明的更接近：
ChatGPT High > Codex 轻度
而不是：
ChatGPT High > Codex High
更不能直接推导出：
即使 Codex 同样使用高推理强度，翻译质量仍然一定明显低于 ChatGPT。
上一次实验时，Codex 并不是没有更高推理强度可以选择，只是当时没有把这一点作为主要变量单独控制。
而今天，ChatGPT 作为默认翻译引擎已经在实际工作中出现了持续的稳定性问题。
既然原来的方案已经影响正式翻译进度，那么以前因为“翻译质量明显不如 ChatGPT”而被排除的 Codex，就必须重新评估。
所以这一次我主动测试：
- ChatGPT GPT-5.6 High
- Codex GPT-5.6 Sol High
- Codex GPT-5.6 Sol Extra High
看看提高 Codex 推理强度以后，之前的质量差距究竟还剩多少。
这一次仍然选择简体中文，而不是直接拿正在推进的日语翻译测试。
原因是中文更容易进行多模型质量评审，同时也能尽量复用上一篇实验已经建立起来的评审方法。
重新选择 5 个 TranslationUnit
这次选择了 5 个完整 Page TranslationUnit：
methods/24concurrency/7concurrency/11generics/1flowcontrol/8
其中前三个：
methods/24concurrency/7concurrency/11
正好也是上一篇翻译质量实验使用过的代表页面。
另外增加：
generics/1flowcontrol/8
让样本覆盖接口、并发、泛型、控制流和练习页面。
三个候选分别为：
- ChatGPT GPT-5.6 High
- Codex GPT-5.6 Sol High
- Codex GPT-5.6 Sol Extra High
这里还有一个容易混淆的细节。
Codex 的推理强度并不是通过 Prompt 中写一句“High”或“Extra High”来控制，而是由我直接在 Codex 界面中选择。
所以这次 Codex High 和 Extra High 的区别，是实际模型运行配置不同，而不是 Prompt 中写了不同文字。
实验输入不再直接使用英文源文件
这一次，我也没有简单把原始 .article 文件交给三个模型翻译。
项目正式生产流程中的最小翻译单位已经确定为 TranslationUnit，因此实验也应该尽量模拟真实生产环境。
我先通过正式 retranslation export 流程导出一个 zh-CN 实验 batch：
chatgpt-zh-CN-quality-experiment-001
其中包含 5 个正式 TranslationUnit input。
这些 inputs 已经经过项目的 protected token 处理，可以看到类似：
GTI18N_*
这样的保护标记。
这一步的目的，是让三个模型面对与正式生产翻译尽可能一致的输入，而不是为了实验专门准备一套更简单的纯文本。
不过就在这里，我还是踩了一个很重要的坑。
第一轮实验必须作废：我漏掉了 glossary
最开始，我以为：
正式 TranslationUnit input + protected token
已经足够模拟生产翻译条件。
三个模型都顺利完成了翻译，protected token 的数量和顺序也完全一致。
随后我把 15 个候选送入正式 Engineering Gate。
结果：
- restore：15 / 15 成功
- validation：12 / 15 通过
三个失败项全部来自：
concurrency/11
而且错误完全相同：
candidate contains forbidden locale translation "幻灯片"
原因很快就找到了。
locales/zh-CN/glossary.yaml 中已经明确规定：
slide => 页面
slides => 页面
同时：
幻灯片
属于禁止使用的 zh-CN 译法。
三个模型却都很自然地把 slides 翻译成了“幻灯片”。
这并不是三个模型同时发生了什么奇怪故障。
真正的问题是：
我只给了它们正式 TranslationUnit input，却没有把完整目标语言 glossary 同时作为正式翻译条件提供。
换句话说，这一轮虽然结构输入已经接近生产环境，但翻译上下文仍然不完整。
所以 12 / 15 的 Engineering Gate 结果不能简单归咎于模型本身。
更不能为了让实验继续，直接手工把三个“幻灯片”替换成“页面”。
那样虽然可以让 validation 通过，却已经破坏了候选的独立性。
正确处理只能是：
废弃第一轮 A / B / C
↓
继续使用完全相同的 5 个正式 TranslationUnit inputs
↓
加入完整 locales/zh-CN/glossary.yaml
↓
重新生成三个候选
↓
重新随机匿名化
↓
重新执行 Engineering Gate
这意味着又要重新翻译一次 5 × 3。
不过这一轮重做是必须的。
因为我真正要验证的不是：
“模型随便翻译一下谁更好”。
而是：
哪个模型真正适合成为 go-tour-i18n 正式生产流程中的 TranslationUnit 翻译引擎。
Codex High 与 Extra High 分别重新生成
重新生成以后，我首先检查 Codex High。
5 个 TranslationUnit 全部完成，并通过了：
- JSON 解析
unit_id完整性检查- GTI18N protected token 数量、内容和顺序检查
- 链接与
.article结构检查 - glossary mandatory / preferred / forbidden 检查
slides => 页面检查- 禁止词检查
5 个 TranslationUnit 中一共包含 86 个 protected token，全部一致。
“幻灯片”出现次数变为：
0
随后用完全相同的 TranslationUnit、完全相同的 glossary 和完全相同的任务要求，再执行 Codex Extra High。
唯一主动改变的变量，就是我在 Codex 界面中把推理强度从：
High
改成：
Extra High
Extra High 同样完成 5 个 TranslationUnit，并通过全部前置检查。
至此三个新的 v2 候选才真正具备可比较性：
- ChatGPT GPT-5.6 High
- Codex GPT-5.6 Sol High
- Codex GPT-5.6 Sol Extra High
每个 TranslationUnit 独立随机匿名
下一步没有直接拿三个模型名字去评审。
我把三个 JSON 中的 15 个候选拆成：
5 个 TranslationUnit × 每页 3 个 candidate
然后进行匿名化。
这里没有简单设置：
A = ChatGPT
B = Codex High
C = Codex Extra High
并让这个映射贯穿全部 5 页。
而是对每一个 TranslationUnit 独立随机 A / B / C。
例如一页中的 A 可能来自 Codex High，下一页中的 A 又可能来自 Codex Extra High。
这样做可以降低评审者从前几页逐渐猜出某个 Candidate 风格以后，对后续页面产生先验判断的可能。
最终生成：
15 个匿名 .article 候选。
真实映射则单独保存在 secret key 中，在全部评审结束以前不读取。
第二次 Engineering Gate：15 / 15 全部通过
匿名化以后，又重新调用项目正式 retranslation process、restore 和 validator。
这一次：
- Protected token restore：15 / 15
- Validation：15 / 15
- restore failed：0
- validation failed：0
Engineering Gate：
15 / 15 PASSED
到这里，15 个候选正式冻结。
之后不再修改候选译文、不再改变匿名规则，也不再重新生成。
冻结语言评审 Prompt
为了避免不同评审模型收到不同上下文，我又生成了一份统一的冻结版匿名评审 Prompt。
其中包含：
- 5 个完整英文 TranslationUnit
- 每页对应的 Candidate A / B / C
- 完整 zh-CN glossary
- 相同的评分维度
- 相同的输出 JSON 格式
同时记录 SHA-256：
94a386eca3680a663409f3be4a7e770310189bb762733cd435ff40f7d91a2add
检查结果包括：
- TranslationUnit：5
- Candidate：15
- GTI18N 残留：0
- 匿名信息泄露检查：PASSED
- candidate 哈希生成前后一致
- secret key 未读取
- 仓库 tracked 文件未修改
从这一刻开始，各评审模型看到的是完全相同的一份材料。
四个独立模型参与匿名评审
最终实际使用了四个评审模型：
- DeepSeek
- 豆包 2.1
- GLM-5.3
- ChatGPT GPT-5.6 High
这里和上一篇实验略有不同。
上一篇使用的是 GLM-5.2，这一次实际评审时已经使用 GLM-5.3。
为了降低 ChatGPT 对自身候选潜在自评偏差的影响，我把：
DeepSeek + 豆包 2.1 + GLM-5.3
作为主要的外部评审结果。
ChatGPT GPT-5.6 High 的评审作为第四份辅助结果。
每个 TranslationUnit 的评分仍然是 100 分：
| 维度 | 分值 |
|---|---|
| 技术准确性 | 30 |
| 忠实原文 | 20 |
| 中文自然度 | 20 |
| 教学表达 | 15 |
| 术语一致性 | 10 |
| 可读性 | 5 |
| 总分 | 100 |
同时每个评审者还必须给三个候选做严格排名，并记录：
- critical
- major
- minor
三个等级的问题。
所有评审完成以前，我都没有读取 secret key。
先锁定评分，再揭盲
全部评分完成以后，才最终执行：
cat /tmp/tour-translation-quality-review-20260823-v2-key.json
这一步也再次说明为什么不能简单统计“A 平均多少分、B 平均多少分”。
因为每一个 TranslationUnit 都独立随机过。
例如：
methods/24
中：
- A = Codex High
- B = ChatGPT High
- C = Codex Extra High
但到了：
concurrency/7
又变成：
- A = Codex Extra High
- B = ChatGPT High
- C = Codex High
所以必须在全部评分锁定以后，根据 secret key 重新映射成真正的模型结果。
三个外部评审的最终结果
首先只统计：
- DeepSeek
- 豆包 2.1
- GLM-5.3
三个外部评审。
结果如下：
| 模型 | 平均分 | 平均排名 | 第一名次数 |
|---|---|---|---|
| ChatGPT GPT-5.6 High | 96.67 | 1.73 | 5 / 15 |
| Codex GPT-5.6 Sol High | 95.73 | 2.07 | 5 / 15 |
| Codex GPT-5.6 Sol Extra High | 95.87 | 2.20 | 5 / 15 |
这是一个让我有些意外的结果。
三个模型的第一名次数竟然全部都是：
5 / 15
ChatGPT High 的平均分仍然最高。
但是相对于 Codex High，只领先：
0.93 分
相对于 Codex Extra High，只领先：
0.80 分
这已经和上一篇实验中形成的直观印象有明显区别。
至少在当前 5 个正式 TranslationUnit 样本上，我已经很难再说：
ChatGPT 的翻译质量明显高于 Codex。
更准确的描述应该是：
三者已经处于同一个高质量梯队，ChatGPT High 在外部评审平均分上仍有小幅优势。
不同页面甚至出现了不同的胜者
逐页看更加明显。
三个外部评审中：
methods/24
Codex High 获得三个外部评审一致第一。
concurrency/7
ChatGPT High 获得三个外部评审一致第一。
concurrency/11
Codex High 获得 2 个外部评审第一，ChatGPT High 获得 1 个。
generics/1
Codex Extra High 获得三个外部评审一致第一。
flowcontrol/8
Codex Extra High 获得 2 个外部评审第一，ChatGPT High 获得 1 个。
也就是说，这不是一个：
ChatGPT > Codex High > Codex Extra High
这样非常整齐的关系。
实际情况更接近：
不同 TranslationUnit 上三个配置各有优势。
这也是我认为“已经进入同一质量梯队”的一个重要依据。
加入 ChatGPT 评审以后差距进一步缩小
把第四个 ChatGPT GPT-5.6 High 评审也加入以后：
| 模型 | 四评审平均分 | 平均排名 | 第一名次数 |
|---|---|---|---|
| ChatGPT High | 96.90 | 1.85 | 6 / 20 |
| Codex High | 96.50 | 1.85 | 9 / 20 |
| Codex Extra High | 96.15 | 2.30 | 5 / 20 |
这里出现了另一个很有意思的结果。
Codex High 的第一名次数反而变成最高：9 / 20。
而且 ChatGPT 评审本身并没有明显偏向 ChatGPT 候选。
在 5 个页面中，ChatGPT GPT-5.6 High 这个评审者有 4 页把：
Codex High
排在第一。
这至少说明，这一轮结果不能简单解释成：
“ChatGPT 自己给自己的译文打高分”。
Extra High 并没有带来稳定提升
开始实验之前，我其实很期待 Extra High。
如果 Codex High 已经可以靠近 ChatGPT，那么 Extra High 是否可能进一步缩小差距，甚至稳定超过 ChatGPT？
结果并没有支持这个假设。
三个外部评审：
- Codex High：95.73
- Codex Extra High：95.87
Extra High 只增加：
0.14 分
但平均排名：
- High：2.07
- Extra High：2.20
反而稍微下降。
加入全部四个评审以后：
- Codex High：96.50
- Codex Extra High：96.15
Extra High 又低了：
0.35 分
而且整个实验中唯一一个被外部评审判定为 major 的问题，也出现在 Codex Extra High 的 methods/24 候选中。
三个模型均没有 critical 问题。
所以目前我没有看到充分证据说明：
把 Codex 从 High 提升到 Extra High，可以稳定提高 A Tour of Go 的翻译质量。
这意味着后续默认使用 Extra High 的必要性并不强。
上一次实验并没有错，但结论需要加上条件
这一次结果并不意味着上一篇质量实验是错的。
上一篇实验实际回答的是：
在当时那组模型和推理配置下，哪个候选表现更好？
结果确实是 ChatGPT 明显占优。
但当时还有一个非常重要的条件：
ChatGPT 使用的是高推理强度。
Codex 虽然同样可以选择更高推理强度，但当时实际使用的是默认的轻度推理强度。
今天这一轮则主动把 Codex 提升到了 High 和 Extra High。
最终结果变成：
ChatGPT High ≈ Codex High
因此，现在看来，上一篇实验中 Codex 表现较弱，很可能至少有一部分原因并不是 Codex 这个执行环境本身，而是当时实际采用了较低的推理强度。
这也是我今天重新测试以后最大的收获之一。
翻译质量已经不再是阻止我使用 Codex 的主要原因
如果只比较三个外部评审的平均分：
ChatGPT High：
96.67
Codex High：
95.73
ChatGPT 仍然领先约：
0.93 分
但现在必须同时考虑工程执行能力。
ChatGPT 网页端目前的方案，即使已经从 ZIP 简化到 JSON，仍然没有真正解决稳定性问题。
真正影响生产的已经不是多一次下载或 import，而是：
一个正式 batch 的 TranslationUnit 翻译任务本身无法保证稳定完成。
相比之下，Codex 可以直接操作本地仓库。
如果把它作为正式翻译引擎，未来完全可以走：
retranslation export
↓
Codex 读取 manifest、inputs 和目标语言 glossary
↓
完整 TranslationUnit 翻译
↓
直接写入 raw-responses/
↓retranslation process
↓
正式 validation
实验阶段为了保持三个候选格式一致，我仍然让 Codex 生成了 JSON。
但如果后续正式生产改用 Codex，这个 JSON 中间层就没有继续保留的必要。
我决定把 Codex High 作为后续默认翻译方案
综合今天的结果，我目前的选择是：
第一选择：Codex GPT-5.6 Sol High
作为后续正式 TranslationUnit 翻译的默认方案。
它的语言质量已经和 ChatGPT High 非常接近，同时在本地批量执行、文件写入和自动化流程方面明显更加适合目前的项目。
第二选择：ChatGPT GPT-5.6 High
单看三个外部评审平均分，ChatGPT 仍然略占优势。
所以它依然会在这个项目中承担非常重要的质量控制角色。
只是以目前网页端实际表现来看，我已经不准备继续让它承担大批量 TranslationUnit 的默认生产翻译任务。
暂不默认使用：Codex GPT-5.6 Sol Extra High
这次没有发现 Extra High 相对于 High 的稳定质量提升。
在没有更多证据之前，没有必要为了更高推理强度增加额外成本。
接下来继续推进 ja-JP
这一次实验目标是简体中文，不是日语。
所以它不能直接证明：
Codex High 的日语翻译质量也一定和 ChatGPT High 完全一致。
但是它已经解决了当前最重要的生产决策问题：
Codex High 是否仍然因为翻译质量明显不足，而不适合作为项目默认翻译引擎？
至少根据今天这一轮受控实验，答案已经是否定的。
接下来继续推进 ja-JP 时，我准备把默认翻译阶段调整为：
Codex GPT-5.6 Sol High
↓
读取完整 TranslationUnit 与目标语言 glossary
↓
直接生成 raw-responses/
↓
正式 restore / validation
↓
继续下一批 TranslationUnit
等所有 Page 和 Example TranslationUnit 全部完成以后，再进入统一质量验收。
这里我目前仍然准备让 ChatGPT 参与 Quality Check。
也就是说，ChatGPT 不再承担前面大量重复的正式翻译生成工作，而是把它更擅长的语言质量判断能力放到后面的统一质量检查阶段。
Quality Check 会继续按照：
A / B / C / D
对完整 TranslationUnit 进行评级。
我的目标不是“大部分达到 A”。
而是：
所有 TranslationUnit 最终都必须达到 A。
如果某个 TranslationUnit 得到 B、C 或 D，就继续处理，直到全部达到 A，才算真正通过这一轮 Quality Check。
之后再进入：
Final Review
↓
promote
所以调整默认翻译引擎，并不意味着降低质量要求。
新的分工更接近：
Codex High 负责稳定地完成批量完整 TranslationUnit 翻译；ChatGPT 负责后续统一 Quality Check。
总结
今天重新实验的起点，其实不是为了单纯比较一次模型分数。
而是因为 ChatGPT 作为默认批量翻译引擎以后，实际工作已经无法稳定推进。
重新控制推理强度、正式 TranslationUnit input、glossary、匿名化和 Engineering Gate 以后，最终得到的结果是：
- ChatGPT High 外部评审平均分：96.67
- Codex High：95.73
- Codex Extra High：95.87
- 三者外部第一名次数均为 5 / 15
- Extra High 没有表现出稳定优于 High 的趋势
因此，我现在更倾向于把这次实验理解为：
Codex High 已经进入和 ChatGPT High 基本相同的翻译质量梯队。
这足以改变后续生产方案。
接下来，A Tour of Go 多语言 TranslationUnit 的默认翻译引擎准备改为：
Codex GPT-5.6 Sol High。
ChatGPT 则转到后面的统一 Quality Check。
最终质量门槛仍然保持不变：
所有 TranslationUnit 的 Quality Check 都达到 A，才真正通过质量验收。
这次调整的重点，不是谁在一次实验中绝对战胜了谁。
而是当翻译质量差距已经足够小时，稳定完成真实生产任务的能力，开始成为默认翻译引擎选择中更关键的因素。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。