上一篇文章中，我继续评估了 A Tour of Go 简体中文翻译流程。
当时真正发生变化的，已经不是 Protection Policy，而是 Translation Engine。
经过代表页独立翻译和多模型匿名评审以后，ChatGPT 的整体表现最好，也因此成为最值得继续扩大验证的翻译来源。
上一篇记录：
不过上一篇结束时，我还没有决定立即重新翻译全部 103 个正式课程页面。
当时能够确定的只是：
ChatGPT 值得扩大样本继续验证。
如果扩大以后仍然保持优势，再判断是否值得替换现有正式 zh-CN。
真正继续推进以后，这个“扩大样本”最终没有停留在十几页。
而是一路走到了：
103 / 103A Tour of Go 当前全部 103 个正式课程页面，最终都重新生成了一份 ChatGPT 中文候选。
但这一阶段真正需要解决的，已经不再是：
“ChatGPT 能不能翻译一个 A Tour of Go 页面？”
真正的问题变成了：
没有 OpenAI API 的情况下，怎样把 ChatGPT 的高质量整页翻译能力真正接入现有工程流程，同时避免 103 页反复人工复制粘贴？
最终起到关键作用的，是：
ChatGPT
+
GitHub
+
现有本地翻译与校验工具一、这次没有改变整页翻译原则
首先需要明确一点。
这次重译并没有改变 A Tour of Go 原来的基本翻译单元。
原来的 GLM-5.2 工作流就已经坚持：
一个完整 present.Section
=
一个完整课程页面所以这次质量路线发生变化的根本原因，并不是从句子翻译改成了整页翻译。
两轮工作流本来都是整页翻译。
真正改变的是：
Translation Engine原有这些能力继续保留：
完整课程页面
↓
Default protection
↓
完整页面翻译
↓
restore
↓
candidate
↓
统一 validator也就是说，我并没有因为换成 ChatGPT，就再建设一套新的页面切分、结构保护和校验体系。
这次希望做到的是：
只更换真正负责生成中文的 Translation Engine，尽可能继续复用已经成熟的工程部分。
二、103 页不能继续靠人工复制粘贴
代表页实验阶段，人工复制几个完整页面还可以接受。
但如果真正扩大到 103 页，问题马上就不一样了。
最直接的人工流程会变成：
本地找到英文页面
↓
复制完整翻译输入
↓
切换到 ChatGPT
↓
粘贴
↓
等待翻译
↓
复制中文结果
↓
切回本地
↓
保存 raw response
↓
继续下一页如果 103 页全部这样处理，仅输入和输出就意味着两百多次机械性的复制粘贴。
而且还要不断确认：
当前是哪一个 Batch
当前是哪一个 page
输入有没有复制完整
输出有没有粘贴错文件
结构字符有没有在消息传递过程中发生变化上一篇代表页实验中，其实已经遇到过人工传递造成结构漂移的问题。
所以真正开始全量重译以前，我越来越明确一件事：
如果最后真的要重新翻译 103 页，就应该尽可能消除人工搬运文本。
但我当时又没有适合直接接入现有工具链的 OpenAI API 条件。
于是最终采用了另外一种方式。
三、先把 103 页整理成固定的重译批次
本地项目首先增加了专门的 retranslation input 导出能力。
不再临时打开某个 .article 文件，再人工整理需要交给模型的内容。
而是让项目按照现有 Default protection 规则生成固定的翻译输入。
之后逐渐形成：
chatgpt-zh-CN-001
chatgpt-zh-CN-002
chatgpt-zh-CN-003
...
chatgpt-zh-CN-011其中 Batch 001～008 完成 103 页第一次全量覆盖。
Batch 009～011 则不再增加新的课程页面，而是针对前面已经完成的页面继续产生 revision。
前几个批次主要按照每批 10 页推进。
等整个交接和校验方式稳定以后，部分批次扩大到了 20 页。
最终 Batch 008 完成时，第一次全量重译已经正式覆盖：
103 页这里也需要注意：
11 个 Batch 中的 candidate 数量不能直接相加理解为页面总数。
课程页面始终只有 103 个。
后面的 Batch 009～011 是对已有页面产生的新 revision。
四、GitHub 成了 ChatGPT 与本地工具之间的交接层
这一阶段真正大幅减少复制粘贴工作的，是 ChatGPT 的 GitHub 连接能力。
本地项目先生成并提交固定 Batch input。
例如：
data/retranslation-runs/zh-CN/chatgpt-zh-CN-008/inputs/之后 ChatGPT 可以直接通过 GitHub 读取已经提交的：
Batch input
glossary
翻译规则
必要的项目上下文这样我就不再需要把每一个完整页面从本地终端或者编辑器复制到 ChatGPT。
ChatGPT 完成整页翻译以后，原始译文同样通过 GitHub 写回对应 Batch：
raw-responses/于是原本需要大量剪贴板操作的过程，被改成了：
本地项目
↓
生成固定 Batch input
↓
GitHub
↓
ChatGPT 读取 Batch
↓
完成整页翻译
↓
GitHub 写回 raw response
↓
本地同步
↓
process / restore / validator
chatgpt-zh-CN-008 重译批次。一个 Batch 同时保存 inputs、raw-responses、candidates、validation 和 retry 记录，GitHub 成为 ChatGPT 与本地翻译流水线之间的数据交接层。这里 GitHub 本身当然不负责翻译。
它承担的是：
稳定、可追踪的数据交换。
ChatGPT 不需要直接访问我的本地电脑。
本地项目也不需要为了这次重译专门开发一个新的 ChatGPT API Translation Engine。
双方通过 GitHub 中已经提交的文件交接。
最终分工逐渐变成：
ChatGPT
→ 读取正式翻译输入
→ 完成高质量整页翻译
→ 写回原始译文
GitHub
→ 保存和交接输入、输出及历史证据
本地工具 / Codex
→ input export
→ restore
→ validator
→ retry
→ candidate
→ 测试这样一来，我实际需要人工关注的重点，也从：
不断复制和粘贴文本变成了：
检查批次状态
处理异常页面
判断 revision
审核阶段结果对于 103 页这种规模来说，这个区别非常明显。
五、每一批原始译文都单独进入 Git 历史
为了让 ChatGPT 的原始结果后续仍然能够追踪，这一阶段还坚持了一条比较简单的规则：
一批 ChatGPT raw response 对应一个独立 Git commit。
例如一个 Batch 会先有输入提交：
data: 添加第八批 ChatGPT 重译输入然后再有原始译文：
data: 添加第八批 ChatGPT 原始译文等本地 restore 和 validator 完成以后，再提交：
data: 添加第八批 ChatGPT 重译候选与校验结果这样每个阶段的职责比较清楚。
也就是说：
输入是什么
↓
ChatGPT 原始输出是什么
↓
本地处理以后生成了什么 candidate
↓
validator 最终得到什么结果不会混在同一次修改里。
对普通手工翻译来说，这可能显得有些繁琐。
但到了后面需要追查某一个页面为什么产生新 revision，或者某一次 retry 到底发生了什么时，这些 Git 历史会变得很有价值。
六、ChatGPT 原始回复不会直接成为正式 candidate
这次另一个很重要的原则，是：
ChatGPT 返回的中文，不会因为语言看起来很好，就直接进入正式 candidate。
每个正常页面至少会留下四层内容：
inputs
raw-responses
candidates
validation以 basics/1 为例：
basics/1 为例，一个正常页面分别保存实际翻译输入、ChatGPT 原始回复、restore 后的 candidate 和统一 validator 结果。ChatGPT 原始输出不会直接成为项目正式候选。它们承担的职责分别是：
inputs/basics-1.article记录真正交给 ChatGPT 的内容。
raw-responses/basics-1.article保存 ChatGPT 返回的原始译文。
candidates/basics-1.article保存经过确定性 restore 后，准备进入项目统一校验的候选。
最后：
validation/basics-1.json记录 validator 的结果。
这样一旦某个页面发生异常，就可以继续回答几个完全不同的问题：
原始 input 是否正确？
ChatGPT 是否改变了不该改变的内容？
restore 是否正确？
最终 candidate 是否符合结构要求？如果只保存最后一个 candidate，这些问题很容易混在一起。
七、ChatGPT 继续接受原来的统一 validator
换了 Translation Engine，不代表降低工程门槛。
这一点在这次重译过程中始终没有改变。
不管译文来自：
GLM-5.2
ChatGPT
未来其他 Translation Engine最终都应该回到同一套 validator。
换句话说：
Translation Engine 负责生成中文，validator 负责判断这个结果能不能继续进入项目。
ChatGPT 的语言质量再高，如果它破坏了：
present.Section
链接 target
代码
directive
不可翻译技术标识
其他必须保持的结构一样不能直接通过。
这也是这次没有单独建设所谓：
ChatGPT validator
ChatGPT publisher
ChatGPT production workflow的原因。
真正增加的是：
ChatGPT retranslation staging后面的确定性校验尽量继续复用现有能力。
八、103 页并不是全部第一次就通过
批量流程真正有价值的地方，通常不是所有页面顺利的时候。
而是出现失败以后，是否还能继续追踪。
103 页第一次全量重译过程中，有两个页面最终留下了正式 retry history：
moretypes/1
concurrency/1它们分别出现在：
chatgpt-zh-CN-004
chatgpt-zh-CN-008
moretypes/1 和 concurrency/1 在第一次处理后都留下 attempt-001-validation.json，随后重新生成 attempt-002.article。失败尝试没有被成功结果覆盖，而是作为独立 retry evidence 保留下来。例如：
retries/moretypes-1/attempt-001-validation.json
retries/moretypes-1/attempt-002.article第一次失败的校验结果会被保存。
第二次重新生成的译文同样作为新的 attempt 保存。
然后重新进入正常：
restore
↓
validator
↓
candidate而不是：
第一次失败
↓
删除
↓
再翻一次
↓
假装第一次没有发生最终全部 103 页中，需要这种正式第二次尝试的只有两个页面。
九、历史 Batch 开始成为不可随意修改的 evidence
随着 Batch 数量逐渐增加，我后来又明确了一条规则：
已经形成的历史 Batch 不再直接手工修改。
如果后面发现某个页面还需要调整，不回头修改旧 candidate。
而是产生新的 revision batch。
这也是 Batch 009～011 存在的主要原因。
普通翻译草稿通常可以反复覆盖同一个文件。
但这里更需要知道：
当时给 ChatGPT 的输入是什么
↓
ChatGPT 当时返回了什么
↓
当时 restore 出了什么
↓
validator 当时判断了什么
↓
为什么后来又需要 revision所以这些目录逐渐不再只是临时翻译文件。
它们开始承担：
历史 evidence
的角色。
后面真正把 ChatGPT 新译文提升成正式 canonical 时，这条原则尤其重要。
不过那已经属于下一篇文章的内容。
十、Batch 001～008 最终完整覆盖 103 页
第一次全量重译结束以后，最终统计为：
Initial full-translation batches : 8
Pages in initial full translation: 103也就是说：
Batch 001～008 已经让全部 103 个正式课程页面拥有新的 ChatGPT 候选。
之后：
Batch 009
Batch 010
Batch 011继续处理部分页面的 revision。
所以整个重译阶段最终可以概括成：
8 个首次全量翻译 Batch
+
3 个 revision Batch
=
11 个 ChatGPT Batch
moretypes/1 和 concurrency/1 留下 retry history。最终结果：
Initial full-translation batches : 8 (001-008)
Revision batches : 3 (009-011)
Total ChatGPT batches : 11
Pages in initial full translation:
103
Unique pages across all batches:
103
Retry pages:
moretypes-1
concurrency-1
Repository status:
clean到这里，上一篇文章中还只是“值得扩大样本”的实验方向，已经真正变成：
103 / 103的完整 ChatGPT 重译结果。
十一、这次真正解决的不是“ChatGPT 会不会翻译”
回头来看，这一阶段真正解决的问题，并不是：
ChatGPT 能不能翻译 A Tour of Go？
上一篇三个代表页实验以后，这个问题其实已经有了比较明确的答案。
更难的问题是：
没有 OpenAI API，又不希望人工复制粘贴 103 个完整页面时，怎样把 ChatGPT 真正变成一个可以规模化使用的 Translation Engine？
这次最终找到的办法并没有重新建设一个复杂翻译平台。
而是尽可能复用已有能力：
现有完整页面翻译单元
+
现有 Default protection
+
自动导出的固定 Batch input
+
GitHub 数据交接
+
ChatGPT 整页翻译
+
原始 response evidence
+
现有 restore
+
现有 validator
+
有限 retry其中 GitHub 的加入尤其关键。
它让 ChatGPT 和本地工程之间不再依赖大量剪贴板操作。
我不需要把 103 个页面逐个复制给 ChatGPT。
ChatGPT 也不需要直接控制我的本地电脑。
本地项目、GitHub 和 ChatGPT 各自负责自己最适合的部分。
最终，人的主要精力开始从：
搬运文本转向：
判断质量
处理异常
决定 revision
控制发布边界这才使 103 页全量重译真正变成了一件可以推进完的事情。
不过到这里仍然只能说明：
103 页新的 ChatGPT 候选已经完整生成。
它还不能自动推出另外一个结论：
这些新译文已经足够好，可以替换当前正式 zh-CN。
因为“翻译完成”和“允许成为正式 canonical”，本来就应该是两个不同阶段。
下一篇就继续记录这一部分。
到了那里，需要回答的将不再是：
103 页有没有翻完？而是：
103 页全部翻完以后，怎样进一步做完整语义质量审核，为什么最终能够把整体评价从原来的约 94 分提高到约 98 分，以及这些 ChatGPT 候选又是怎样安全提升成正式 canonical 的。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复