最近，我一直在推进 A Tour of Go 多语言翻译项目。
前一阶段已经完成了简体中文 zh-CN 的全部课程正文翻译。按照当前发布口径，一共有 103 个正式发布页面，并且全部通过了项目现有的自动结构和页面校验。
但“自动校验通过”并不等于“可以直接发布”。
自动校验更擅长确认：
present结构是否正确；.play等指令有没有丢失；- 链接目标有没有变化；
- 行内代码结构是否完整；
- 强调结构是否保留；
- 教学代码注释有没有破坏程序结构；
- candidate 与英文源页面的结构是否一致。
而它很难判断另一类问题：
这句话虽然技术上没错，但中文是不是太绕？
或者：
这个术语虽然能够理解，但是否符合中文 Go 社区更常见的表达？
所以，在 103 个页面全部进入 ready 之后，我没有马上开始发布，而是增加了一轮完整的发布前正文质量审计。
最终结果有点出乎我的预料：
103 页全部逐页审核，真正需要返修的只有 16 页。
一、为什么不让 ChatGPT 把 103 页重新翻译一遍
最简单粗暴的办法，其实是把 103 页全部重新交给 ChatGPT。
但我一开始就不太认可这种做法。
因为当前译文不是未经验证的草稿。
它们已经经过了：
GLM-5.2 整页翻译
→ candidate
→ present 解析
→ protected structure 校验
→ 页面结构比较
→ ready
如果发布前再把 103 页全部重写一次，就意味着：
为了改善少量真正存在问题的句子，把大量本来已经可以发布的内容重新制造一次变化。
而每一次变化，都会重新引入：
- 链接移动；
- 行内代码结构变化；
- 强调结构变化；
- 指令丢失；
- 技术含义漂移；
- 中文风格重新波动。
所以这次审核采用的原则不是：
ChatGPT 能不能写得更好？
而是：
当前页面是否已经足够好到可以发布？
这两个标准差别很大。
二、为 103 页建立 A / B / C / D 四级审核标准
为了避免审核过程中逐渐变成“看到一句话就想重新写一句话”，我先给所有页面设定了四个等级。
A：无需修改
译文：
- 技术准确；
- 中文自然；
- 术语合理；
- 阅读没有明显障碍。
即使 ChatGPT 能写出另一种表达，也不构成修改理由。
B：可选润色
存在能够明确指出的小优化，但当前版本已经完全可以发布。
这一类原则上不修改。
C：建议修改
存在比较明确的问题，例如：
- 翻译腔明显；
- 术语不统一；
- 英文残留；
- 表达绕到需要重新读一遍；
- 虽然技术含义基本正确，但已经影响阅读体验。
D：必须修改
这一类属于真正影响技术含义的问题，例如：
- 误译；
- 漏译；
- 技术概念发生变化；
- 中文表达容易让读者得到错误理解。
后来在实际审核过程中，我还进一步调整了一个标准：
“技术上没有错”并不能自动得到 A 或 B。
如果一句话已经明显像机器翻译，读者需要重新拆句才能理解，那么即使它最终表达的技术含义基本正确，也应该进入 C。
这个标准后来直接影响了一个很典型的页面。
三、C 类代表：技术没错，但“返回一个返回……”实在太绕
moretypes/26 是一个很有代表性的例子。
这是关于函数闭包和斐波那契数列的练习页面。
原来的译文是：
实现一个
fibonacci函数，它返回一个返回连续的斐波那契数（0, 1, 1, 2, 3, 5, …）的函数（闭包）。
严格来说，它不是技术误译。
读几遍之后，也能够理解它想表达什么。
问题在于：
“返回一个返回……”
这种嵌套结构非常明显地带有英文句法直接映射到中文后的痕迹。
所以它最终被列为 C，而不是 B。
最终改成：
实现一个
fibonacci函数，使其返回一个函数（闭包），该闭包会依次返回斐波那契数（0, 1, 1, 2, 3, 5, …）。
技术含义完全没有改变。
但是中文的主干一下就清楚了：
fibonacci
→ 返回一个闭包
→ 闭包依次返回斐波那契数
这也是我后来越来越明确的一点：
发布前质量审核不是为了重新翻译，而是为了把真正影响理解的表达修掉。
四、D 类代表：fmt.Println 被错误翻成了 main
相比 C 类，D 类的问题要少得多。
整个 103 页最终只有 2 页 D。
其中一个是 flowcontrol/7。
英文原文的意思是：
对
pow的两次调用都会在main中的fmt.Println调用开始之前返回结果。
原来的中文却变成：
在
main开始执行之前，对pow的两次调用都已返回结果……
这两个说法不是一回事。
因为 pow 本身就是在 main 执行过程中被调用的。
如果说：
main开始执行之前，pow已经返回。
那执行顺序就完全不成立。
flowcontrol/7 的技术误译——把 fmt.Println 调用开始之前错误翻成了 main 开始执行之前最终修订为：
在
main中调用fmt.Println之前，两次pow调用都会先返回结果。
这一处就属于非常明确的 D：
必须修改。
另一个 D 出现在 moretypes/7。
原来的中文把：
a[1:4]
描述成：
a的第 1 到第 3 个元素
但 Go 的这个切片实际包含的是：
索引 1、2、3 对应的元素
中文里的“第 1 个元素”通常会被理解成索引 0 的第一个元素。
所以最终统一改成：
a中索引 1 到 3 的元素
这两个 D 都不是所谓“写得更漂亮”。
而是真正可能影响初学者理解程序行为的问题。
五、审核中途还插入了一次 Go 中文术语校准
本来我以为这轮工作只需要审核 103 页正文。
结果检查到并发课程以后，又发现：
- 有页面写“信道”；
- 有页面写“通道”；
- 还有页面直接保留
channel。
这又引出了一个新问题：
到底应该根据什么决定 Go 中文术语？
后来我没有按照“项目里哪个词出现更多”来决定，而是重新参考中文 Go 社区长期存在的资料，最终冻结了一批项目术语。
例如：
channel→ 通道type inference→ 类型推断untyped constant→ 无类型常量untyped numeric constant→ 无类型数值常量built-in→ 内置
这部分我已经单独整理成上一篇文章，这里不再展开。
但这次术语校准也影响了最终审核统计。
例如 moretypes/15 原来同一个页面同时出现：
内建
内置
两种 built-in 译法。
虽然完全不影响技术理解，但既然发布前术语基线已经决定统一采用：
内置
那么这页也进入 C。
所以最终正式返修数量从最初的 15 页增加到了：
16 页
六、103 页最终到底有多少需要修改
全部页面审核完成，再加上术语校准之后，最终统计是：
A：87
B：0
C：14
D：2
总计：103
真正需要修改：
14 个 C
+
2 个 D
=
16 页
也就是说：
87 / 103 页保持原样。
没有因为 ChatGPT 能给出另一种中文表达，就把它们重新改写。
这其实是这次审核中我比较满意的一点。
如果一轮所谓“发布前人工审核”最终把 103 页中的八九十页都重新写了一遍，我反而会怀疑：
到底是在审核，还是重新翻译？
而现在的结果更接近我希望的状态：
模型负责生产大部分可发布译文，人工审核只找出真正值得干预的少量异常。
七、16 页不是重新调用 GLM，而是做最小精确修订
确定 16 页之后，我没有再调用 GLM-5.2。
而是把每一处修改先固定下来，包括：
- 当前文本；
- 最终建议文本；
- 修改理由；
- 是否涉及术语表；
- 是否会影响现有
present结构。
然后再统一交给 Codex 修改。
这一步有几个严格限制：
- 不修改另外 87 个 A 页面；
- 不做顺手润色；
- 不重新翻译整个页面；
- 不修改
.play； - 不改变链接目标；
- 不绕过现有 validator；
- 不处理公共 UI；
- 不更新项目状态文档。
最终只修改：
16 个 candidate +
glossary.yaml
这也是为什么这轮修改最终能够保持非常小的 diff。
八、一个特别有价值的意外：validator 拒绝了我的人工修订
methods/19 是这轮工作里我最喜欢的一个案例。
不是因为它的问题严重，而是因为它真正验证了项目架构。
这个页面原来有一句：
值为
error的 nil 表示成功；非 nil 的error表示失败。
中文明显比较别扭。
我最初给出的修订建议是：
error为 nil 表示成功；非 nil 则表示失败。
从中文来说，这句话没有任何问题。
甚至比最终采用的版本更简洁。
但 Codex 修改以后，validator 没有通过。
原因是：
英文源结构要求这一句话中保留两个
`error`行内代码结构，而我的人工建议只留下了一个。
也就是说，我为了让中文更自然，无意间把一个受保护的 inline-code span 删除了。
methods/19 因少保留一个行内代码结构被 validator 拒绝最后改成：
error为 nil 表示成功；非 nil 的error则表示失败。
再次运行 validator：
PASS
candidate OK: locale=zh-CN page_id=methods/19
这件事情特别能说明这个项目为什么坚持：
无论译文来自 GLM-5.2、ChatGPT 还是人工修改，都必须经过同一套自动校验。
如果因为一句话是我和 ChatGPT 人工确认的，就直接认为它“当然正确”，那么这次结构变化就不会被发现。
而 validator 不关心：
这句话是谁改的。
它只关心：
candidate 是否仍然满足源页面要求的结构约束。
这正是我希望整个流程具备的性质。
九、教学代码注释也重新经过了专项校验
这轮还有一个比较小但很有代表性的修改出现在 concurrency/6。
正文已经翻译成中文，但 select 示例里还残留两条英文教学注释：
select {
case i := <-c:
// use i
default:
// receiving from c would block
}
最终翻译成：
select {
case i := <-c:
// 使用 i
default:
// 从 c 接收会阻塞
}
项目之前已经专门实现了对可翻译教学代码注释的保护、恢复和验证。
所以这里也没有因为：
“只是两条注释”
就直接修改后放行。
它仍然完整走了一遍现有 teaching-comment 和结构 validator。
最终通过。
这也再次说明：
可翻译，并不等于可以绕过结构保护。
十、连文件末尾多出来的一个换行也清掉了
16 页全部修改完成以后，我又让 Codex 对 17 个文件做了一次只读 diff 审核。
语义修改都没有问题，但却发现：
有 10 个 candidate 原本文件末尾没有换行，人工编辑之后意外多出了一个
0a字节。
这当然不会影响 Go Tour 渲染。
也不会导致 validator 失败。
但是它属于纯粹的无意义 diff。
既然这次目标本来就是：
最小、精确修订
那就没有理由把这种变化带进最终提交。
所以又专门把这 10 个文件的 EOF 状态恢复为原始状态。
最终确认：
- 正文不变；
- 结构不变；
- 10 个 EOF 噪声消失；
- 其余文件没有额外变化。
这类细节本身不重要。
但它能够让最终提交更容易审计：
每一处 diff 都应该回答“为什么要改”。
十一、最终 16 / 16 全部重新通过校验
所有修订完成之后，16 个页面重新运行统一 validator。
最终：
16 / 16 PASS
然后执行完整 Go 测试：
go test ./...
全部通过。
继续检查：
git diff --check
同样通过。
最后这一轮的完整结果是：
5f77081最终摘要：
audited pages: 103 / 103
A: 87
C: 14
D: 2
revised pages: 16 / 16
validator: PASS
go test ./...: PASS
git diff --check: PASS
并提交：
5f77081 fix: 完成 zh-CN 课程正文质量审计修订
提交之后：
working tree: clean
十二、从 103 页 ready 到 103 页经过发布前质量审核
在这之前，项目已经有一个很重要的提交：
584ce7d feat: 完成 zh-CN 全部课程页面翻译
它代表：
103 个正式发布页面已经全部完成翻译，并通过自动校验进入 ready。
而这次新的：
5f77081 fix: 完成 zh-CN 课程正文质量审计修订
代表的是另一个阶段：
103 页全部经过发布前人工质量审计，需要调整的 16 页已经完成修订并重新通过相同的自动校验。
这两个节点的含义并不一样。
第一个回答：
翻译流程是否全部跑通？
第二个回答：
当前译文是否已经经过完整发布前质量检查？
现在，这两个问题都可以回答：
是。
十三、为什么最终“只修改 16 页”反而是一个不错的结果
这次审核之前，我其实不知道最后会改多少。
可能是 10 页，也可能是 50 页。
但最终：
103 页里只有 16 页需要明确修订。
我觉得这个比例反而能够说明前面的翻译流程已经比较稳定。
尤其是：
真正属于技术性错误的 D 类只有 2 页。
其余大部分需要修改的内容都是：
- 中文明显绕口；
- 术语不统一；
- 英文残留；
- 某个表达不够准确；
- 某句话虽然能理解，但不适合作为发布版教程正文。
这与项目最初想达到的方向比较接近：
不要求人工逐句重新翻译，但要有能力在发布前发现少量真正异常的页面。
如果以后扩展到其他语言，我也不希望流程变成：
模型翻译 100 页
→ 人工再重新翻译 100 页
那样自动化的意义就很有限。
我更希望它保持现在这种结构：
模型整页翻译
→ 自动结构校验
→ 全量质量审核
→ 只返修明确异常
→ 同一套自动校验
→ 发布
十四、总结
这轮 103 页正文质量审核，最后真正让我印象最深的并不是：
改了多少句话。
而是整个流程开始形成一个比较清楚的闭环。
模型生成译文之后，自动校验负责结构可靠性。
人工审核不负责把所有页面重新写一遍，而只负责判断：
哪些页面真的值得干预。
人工修改之后，也不会因为“这是人改的”就获得特殊待遇，而是重新进入同一个 validator。
最终：
103 页全部审计，87 页原样保留，14 页 C、2 页 D，共返修 16 页。
而那次 methods/19 的失败尤其让我确认：
人工判断和自动校验并不是互相替代，而是互相补充。
人工更擅长发现：
“这句话怎么这么绕？”
validator 更擅长发现：
“你刚才为了让它不绕，把一个必须保留的行内代码结构删掉了。”
两者同时存在，才更接近我希望这个项目最终具备的发布流程。
到这里，A Tour of Go 简体中文的课程正文基本可以认为完成了发布前收尾。
接下来剩下的重点，就不再是 103 个课程页面本身，而是浏览器里的另一层内容：
公共 UI 文案。
例如目前页面中仍然能看到的：
RunFormatResetSyntax- 上一页 / 下一页相关界面
- 其他公共交互文字
正文已经完成，下一阶段就轮到它们了。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ Brazilian Portuguese — Português (Brasil)
✅ Dutch — Nederlands
✅ French — Français
✅ German — Deutsch
✅ Italian — Italiano
✅ Japanese — 日本語
✅ Korean — 한국어
✅ Simplified Chinese — 简体中文
✅ Spanish — Español
✅ Turkish — Türkçe
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
项目正在持续扩展更多语言版本，并长期维护翻译质量、生产发布与后续更新。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。