A Tour of Go 简体中文第一阶段完成以后，我一直没有马上把翻译流程视为已经定型。
当前 103 个课程页面已经全部进入 ready，公共 UI、文章元数据、生产发布、代码运行与格式化等环节也已经完成。现有中文版本本身已经可以正式使用。
但对于一个以翻译质量为核心价值之一的项目来说，“已经可以用”和“已经做到当前能够达到的最好水平”并不是同一件事。
过去两天，我实际上一直在追同一个问题：
现有中文还有没有可能从已经不错的水平继续向上提高？
8 月 16 日的第一篇记录：
8 月 17 日的后续实验：
一开始，我认为答案可能在 minimal-protect。
但经过后续实验以后，现在的方向已经发生了变化。
不是质量目标改变了。
而是：
原来希望通过 minimal-protect 达到的质量提升，没有在实验中兑现。真正值得继续研究的变量，开始从 Protection Policy 转向 Translation Engine 本身。
一、上一篇给出的约 94 分，到底代表什么
在 8 月 16 日的文章中，我曾经对当前正式 zh-CN 的翻译质量做过一次工程性估计。
当时给出的判断是：
当前正式 zh-CN：
约 94 分
合理范围：
约 93～95 分这里需要再次明确它的含义。
这不是专业翻译机构的正式评分，也不是把 103 个页面全部逐句人工审校、分别打分以后计算出来的数学平均值。
它是结合代表页、现有正式译文、英文原文以及整个第一阶段长期翻译过程中积累的观察，对完整 103 页正式 zh-CN 版本整体水平做出的工程性估计。上一篇文章对此也做了明确限定。
现有版本的主要特点已经比较稳定：
英文原意基本准确；
Go 技术术语比较统一；
明显机器翻译腔已经很少；
整页上下文总体连贯；
教程式中文表达已经比较自然；
103 个正式页面全部通过统一结构和页面验证。
所以后来重新研究翻译架构，并不是因为现在的中文版质量差。
恰恰相反。
正是因为已经到了大约 94 分这个区间，剩下那几分才开始变得更加难拿。
二、最开始，我把 96～97 分的希望放在 minimal-protect 上
上一篇文章里，我当时给成熟 minimal-protect 设定的目标大约是：
当前正式版：约 94
↓
成熟 minimal-protect：约 96～97这也是当时继续实验的最重要原因之一。
最初的假设很直观。
Default protected-token 会提前保护：
.play directive
链接 target
行内代码
预格式化代码
其他机器结构如果保护得太多，模型看到的页面就会包含越来越多占位符。
从模型视角来看，原始语义环境可能因此受到影响。
所以当时我认为：
如果减少保护，只拿走真正不能修改的机器结构，把更多真实页面上下文直接交给 GLM-5.2，也许可以继续提高语言质量。
这就是 minimal-protect 最初吸引我的地方。
而 96～97 分，就是希望这条路线最终能够达到的质量区间。
但是后续实验没有沿着这个预期发展。
三、157 个 protected token 审计后，第一个核心假设没有成立
后续我首先对 7 个代表页的 Default protected-token 做了实际信息损失审计。
7 页一共包含：
Protected tokens: 157
Replaced source bytes: 1,206进一步分类以后发现：
机器结构：761 bytes
代码 / 技术内容：419 bytes
固定自然语言：26 bytes
被隐藏的可翻译英文自然语言：
0比例：
0.00%这个结果非常关键。
此前担心的是：
Default 保护太多，可能把模型理解译文所需要的英文自然语言上下文一起藏起来了。
但实际检查后，并没有发现这种情况。
Default 虽然确实使用了大量 protected token，但保护的主要是机器结构、代码和链接 target。
真正需要翻译的页面级自然语言仍然完整存在。
于是“减少 protected token → 模型看到明显更多自然语言上下文 → 中文质量显著提高”这条推理链，第一环就开始失去依据。
四、继续补充 Static Context，同样没有带来稳定优势
我随后又换了一个方向。
既然 minimal 模式的优势可能来自模型看到更多原始代码和技术上下文，那么能不能：
继续使用 Default 的结构安全能力，同时额外把静态上下文提供给模型？
于是做了 Static Context 实验。
固定：
5 个页面
×
2 种模式
×
3 次运行
=
30 次计划实验最终结果：
Default
planned = 15
API success = 14
network failure = 1
validator pass = 12
validator fail = 2
usable/planned = 12/15Static Context：
planned = 15
API success = 13
network failure = 2
validator pass = 9
validator fail = 4
usable/planned = 9/15至少在这一轮实验里，增加更多静态上下文并没有表现出稳定优势。
反而是已经成熟的 Default，整体结构可用率更高。
这时候，继续把主要精力放在“到底再少保护几个 token”上，收益已经越来越可疑。
五、相同 Request 得到不同 Response，又暴露了另一个变量
实验继续以后，还发现了一个更重要的问题。
我固定了 5 个页面，保存并比较两次真实 API Request。
检查内容包括：
source
model
system message bytes
user message bytes
thinking
do_sample
max_tokens
实际 API payload结果是：
REQUEST_IDENTICAL : true
RESPONSE_IDENTICAL: false而且 5/5 页面都如此。
项目不去猜测 GLM-5.2 服务端内部到底发生了什么。
真正重要的是实际观察：
即使请求本身相同，最终译文仍然存在运行间波动。
有些波动甚至会改变 validator 的 pass / fail。
更有意思的是，同一种 Default 模式、同一个 methods/24 页面，在不同运行中曾经出现过匿名评审最好的候选，也出现过最差的候选。
到了这里，我越来越难继续支持最初的判断：
减少保护
↓
更多上下文
↓
GLM-5.2 稳定生成更好的中文
↓
约 94 → 96～97至少按照现在已经得到的实验结果，minimal-protect 没有表现出实现这个目标所需要的稳定质量提升。
所以这条路线没有继续成为下一阶段的主线。
96～97 分这个目标没有放弃。
放弃的是“主要依靠减少保护就能达到这个目标”的预期。
六、于是问题从 Protection Policy 转向了 Translation Engine
到了这里，我重新换了一个问题。
如果：
Default 本身没有隐藏需要翻译的自然语言；
minimal-protect 没有显示稳定质量优势；
额外 Static Context 也没有显示稳定优势；
GLM-5.2 本身又存在比较明显的运行间候选波动；
那么继续花大量时间优化 Protection Policy，可能已经不是提高翻译质量最有效的地方。
真正应该比较的也许是：
Translation Engine 本身。
也就是说：
同一份完整英文课程页面，如果分别交给：
GLM-5.2
ChatGPT
Codex Sol到底谁能够稳定生成质量更高的最终中文？
这就是今天这一轮实验的起点。
TRANSLATION_QUALITY_EXPERIMENTS.md，正式记录翻译输入方式、运行时波动和 Translation Engine 最终译文质量实验。七、三种候选全部独立生成
为了让比较尽可能公平，这一次没有让三个模型互相参考。
GLM-5.2 使用当前项目的 canonical ready candidate。
它代表的是现有正式工作流最后保留下来的译文。
这里也不能简单称为“某一次未经处理的原始 GLM Response”，因为部分历史 candidate 可能经历过必要修正或者人工润色。
ChatGPT 则在新的隔离对话中生成译文。
输入包括：
完整可见英文 Section；
术语要求；
必要的结构规则。
但不提供现有中文 candidate。
Codex Sol 同样使用新的独立上下文，读取英文 Section、glossary 和结构规则，在生成以前禁止查看现有中文候选。
选择了三个代表页：
methods/24
concurrency/7
concurrency/11它们分别覆盖：
短技术页；
并发练习页；
包含大量资料链接和长篇引导文字的课程尾页。
三种最终候选全部继续通过项目已有的统一 candidate validator。
八、结构可靠性和语言质量继续分开
这里还有一个实验过程中的小插曲。
ChatGPT 在 concurrency/7 和 concurrency/11 的原始回复中，第一页标题前面明确使用的是：
*但在人工复制到后续 Codex 验证流程时，一度变成：
-这不是 ChatGPT 把 present 结构翻译错了。
而是人工复制、Markdown 显示或者消息传递链路造成的数据漂移。
methods/24 中还出现过全角冒号、链接 label 中增加 inline-code 等 present 兼容问题。
这些问题需要修正，但它们和“中文翻得好不好”并不是一回事。
所以本轮实验继续坚持：
结构兼容性
≠
中文翻译质量所有三方最终译文都先通过统一 validator，再进入匿名语言评审。
这件事还给下一阶段留下了一个很直接的经验：
如果最后真的重新翻译 103 页，就应该尽量消除人工复制粘贴。
九、四个模型做匿名评审
每一页的三份译文都随机映射为：
候选甲
候选乙
候选丙在评分完成以前，不告诉评审模型候选来源。
然后分别交给：
ChatGPT
DeepSeek
GLM-5.2
豆包四个模型评审。
每一页、每一个 judge 都使用独立的新对话。
所以最终共有：
3 个页面
×
4 个评审模型
=
12 次匿名评审统一使用 100 分制：
技术准确性：30
原文忠实度：20
中文自然度：20
教学表达：15
术语一致性：10
可读性：5除了打分，还要求每个 judge 给出：
排名；
具体优点；
具体问题；
最值得修改的一处措辞。
最终分析时，我没有直接把不同 judge 的绝对分数简单平均。
因为不同模型的评分尺度并不相同。
相比“一个模型给 97，另一个模型给 93”，排名、具体错误以及跨模型的一致倾向更有意义。
十、12 次匿名评审：ChatGPT 得到 8/12 第一名
完整结果整理以后：
ChatGPT：8/12 第一名
Codex：2/12 第一名
GLM-5.2：2/12 第一名
单看这个结果，ChatGPT 的优势已经比较明显。
但这里马上会遇到一个必须处理的偏差：
ChatGPT 自己也是 judge。
而 ChatGPT judge 在三个页面里恰好都把 ChatGPT 候选排在第一。
所以不能只看 8/12。
我随后把 ChatGPT 自己作为 judge 的三次评审全部排除。
只剩：
DeepSeek
GLM-5.2
豆包共 9 次外部模型评审。
结果：
ChatGPT：5/9 第一名
Codex：2/9 第一名
GLM-5.2：2/9 第一名也就是说：
即使完全去掉 ChatGPT 自己给自己的三票，ChatGPT 仍然是第一名次数最多的翻译来源。
这使结果的说服力明显提高。
十一、平均名次同样是 ChatGPT 第一
继续看排名稳定性。
全部 12 次 judge：
ChatGPT：1.33
Codex：2.25
GLM-5.2：2.33只看 9 次外部 judge：
ChatGPT：1.44
GLM-5.2：2.11
Codex：2.33
这里我觉得比 8/12 更值得注意的是：
ChatGPT 的整体排名比较稳定。
它不是每一个页面、每一句话都压倒性领先。
不同 judge 对翻译的偏好明显不同。
例如有的 judge 更强调逐字忠实；
有的更看重自然中文；
有的特别关注教程场景；
有的接受一定程度的中文化重组。
所以 Codex 和 GLM-5.2 都有赢得第一名的页面。
但 ChatGPT 比较少明显掉到后面。
对于一个需要批量翻译上百个页面的项目来说，我认为这种稳定性很重要。
十二、这并不意味着现有 GLM-5.2 中文质量差
这次结果也不能被理解成：
ChatGPT 好
GLM-5.2 差四个 judge 对三种候选的评价其实反复出现同一个特点：
三者总体都已经属于高质量译文。
多数争议集中在：
一句话应该更忠实还是更自然；
某个标题应该保留英文隐喻还是中文化；
“simple”应该译成“简单”还是“简洁”；
“ignore”应该译成“不考虑”还是“暂不深入讨论”；
教程语言应该更正式还是更口语。
真正严重的技术错误非常少。
所以当前 103 页并不存在因为翻译质量不合格而必须立即废弃的问题。
现有正式 zh-CN 仍然保持：
ready=103
pending=0
blocked=0production 也不因为这轮实验发生变化。
十三、但现在终于找到了一条更可能接近 96～97 分的路线
这也是今天对我最重要的结果。
上一篇文章中的目标是：
当前正式版本：
约 94
希望达到：
约 96～97当时认为实现方法可能是：
GLM-5.2
+
minimal-protect现在经过保护范围审计、重复实验、Static Context 和运行间波动验证以后，这条路线没有表现出预期中的质量收益。
所以：
minimal-protect 并没有把约 94 分稳定推向 96～97 分。
继续围绕保护范围做细微调整，已经不是当前最有价值的投入方向。
但是今天的 Translation Engine 对比第一次给出了另一条比较明确的信号：
当前 GLM-5.2 正式译文
↓
更高质量 Translation Engine
↓
ChatGPT 在多模型匿名评审中明显领先
↓
值得扩大样本继续验证因此：
96～97 分这个目标没有改变，改变的是实现目标的技术路线。
原来希望：
优化 Protection Policy
→ 提高质量现在更倾向于：
更换 Translation Engine
+
继续复用成熟 validator
→ 提高质量十四、如果真的能从约 94 提升到 96～97，我认为值得重新翻译
这也回到了我现在真正纠结的问题。
现有正式 zh-CN 的工程性总体估计约为：
94 分合理范围约：
93～95如果后续扩大 ChatGPT 重译样本以后，能够证明：
它不是只在这三个页面偶尔更好；
而是在更多页面中仍然稳定受到多个独立 judge 的偏好；
技术准确性、忠实度、中文自然度和教学表达都能保持优势；
最终能够把整体质量稳定推向：
96～97甚至更高，那么我认为重新翻译 103 页是值得的。
对于一个普通软件项目来说，从 94 分提高两三分可能没有必要。
但这个项目本身的核心产品之一就是翻译。
翻译质量提高，本身就是产品升级。
十五、真正决定是否重翻的另一个因素，是能否把工作量压下来
103 页其实并不是特别大的数量。
真正让全量重翻变麻烦的，是这种流程：
打开英文页面
↓
复制
↓
打开 ChatGPT
↓
粘贴
↓
等待翻译
↓
复制中文
↓
再交给 Codex
↓
保存 candidate
↓
校验
↓
下一页如果 103 页全部手工重复，真正浪费时间的不是模型翻译，而是人与多个工具之间来回复制。
而且今天已经看到，人工传递本身还可能造成：
* → -这一类非模型产生的数据变化。
所以如果要重翻，我希望先解决流程问题。
我目前认为，103 页如果能做到足够自动化，整个重译、结构处理和自动验证过程，人工工作量有希望控制在大约 1～2 天量级。
如果真能做到这一点，那么：
较低的一次性迁移成本
+
明显更高的长期译文质量我认为是值得投入的。
十六、下一阶段不是直接覆盖 103 页，而是建立 retranslation staging
当前已经确定的原则仍然很保守。
不会执行：
ChatGPT 翻译
↓
直接覆盖现有 candidate
↓
上线更合理的流程应该是：
完整英文 Section
↓
ChatGPT 整页翻译
↓
原始响应直接保存
↓
Codex / 本地工具做必要结构适配
↓
统一 candidate validator
↓
render / page validation
↓
新的 retranslation candidate staging
↓
与现有 canonical candidate 比较
↓
达到替换标准
↓
才允许正式切换
这里有几个原则不会改变。
首先，尽可能不再要求我逐页复制粘贴。
其次，ChatGPT 原始输出应该直接、完整地保存下来。
第三，结构修正和语言质量必须分开。
第四，无论译文来自 GLM-5.2、ChatGPT 还是其他模型，都必须经过同一套 validator。
第五，新的 103 页重译结果首先进入独立 staging。
第六，在新版本没有证明自己更好以前，现有 103 个 canonical candidate 和 production 都保持不变。
十七、Codex 的角色也开始变得更清楚
这次实验里还有一个比较意外的结果。
Codex Sol 自己生成的中文其实也相当有竞争力。
12 次评审中，它获得了 2 次第一名。
但综合结果仍然没有支持它取代 ChatGPT 成为当前最高质量的翻译端。
反而让我更明确了一个很适合后续工程化的分工：
ChatGPT
→ 重点负责高质量整页翻译
Codex
→ 负责仓库读取
→ candidate 写入
→ present 结构适配
→ validator
→ render / test
→ 状态和 diff
现有本地工具
→ 提供确定性结构校验和发布门槛这种分工比要求一个模型同时负责所有事情更合理。
ChatGPT 做它目前表现最好的语言工作。
Codex 做它更擅长的仓库和工程工作。
而项目现有 validator 继续承担最终的确定性安全边界。
十八、这几天的实验实际上完成了一次方向切换
回头看这三轮实验，路线变化已经很清楚。
最初是：
现有中文约 94 分
↓
怀疑 protected-token 保护过多
↓
研究 minimal-protect
↓
希望达到 96～97随后实际得到：
Default 157 个 protected token
↓
隐藏可翻译自然语言 = 0
minimal-v1
↓
没有稳定质量优势
Static Context
↓
没有稳定优势
相同 Request
↓
Response 仍存在运行间变化于是原来的质量提升假设没有兑现。
研究重点开始变成：
Protection Policy
↓
Translation Engine再往后：
ChatGPT
Codex
GLM-5.2
↓ 三方独立候选
ChatGPT
DeepSeek
GLM-5.2
豆包
↓ 12 次匿名评审
ChatGPT：
8/12 第一名
排除 ChatGPT self-judge：
5/9 第一名这才形成现在的新方向。
十九、现阶段的结论
当前我不会因为这次实验立即重新翻译 103 页。
但现在已经有足够证据让我继续往前验证 ChatGPT。
现阶段可以确定的是：
第一，现有正式 zh-CN 本身已经是高质量版本，工程性总体估计约 94 分。
第二，原本希望依靠 minimal-protect 把质量稳定提升到 96～97 分，但后续实验没有显示出足够的质量收益，这条路线不再作为主要优化方向。
第三，ChatGPT、Codex、GLM-5.2 的三方匿名比较中，ChatGPT 当前表现最好。
第四，即使排除 ChatGPT 自己作为 judge，ChatGPT 仍然在外部模型评审中保持第一名次数和平均名次领先。
第五，96～97 分的质量目标仍然值得追求，但现在更值得尝试通过更高质量的 Translation Engine 来实现。
第六，如果 ChatGPT 在扩大样本后仍然能够稳定提高质量，同时 103 页重译流程可以高度自动化并把人工工作量压到约 1～2 天，那么我倾向于重新翻译整个 zh-CN。
对于这个项目来说，第一阶段解决的是：
能不能建立一个完整、可靠、可以持续发布的 A Tour of Go 中文版本？这个问题已经解决。
下一阶段真正要回答的开始变成：
在完整和可靠的基础上，
还能不能把翻译质量继续做到更高？前面我一度以为，答案可能是 minimal-protect。
现在实验让我转向了另一个答案：
也许真正需要升级的，不再是模型前面的保护规则，而是模型本身。
接下来就准备验证这件事。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复