前一阶段，我一直没有急着批量翻译 A Tour of Go。
原因很简单：这个项目真正困难的地方，从来不是“让大模型把英文翻译成中文”，而是如何在整页翻译的同时，严格保留 present 语法、行内代码、链接、.play 指令、强调结构以及其他不能被随意改写的内容。
在完成 7 个代表页面的翻译和校准之后，项目已经覆盖了泛型、行内代码、链接、预格式化代码、强调结构、练习页面、.play 等多种典型结构。
于是，我决定正式进入下一阶段：
不再专门挑选特殊页面，而是连续试跑 10 个普通
pending页面。
这一批选择的是：
basics/4
basics/5
basics/6
basics/7
basics/8
basics/9
basics/10
basics/11
basics/12
basics/13
原本以为这一轮主要是验证流程稳定性。
结果没想到，这 10 页反而又帮我发现并解决了几个非常有价值的流程问题。
一、第一轮结果：8 个 ready，2 个 blocked
第一次按照现有正式单页翻译流程顺序执行这 10 个页面后，结果如下：
| 页面 | 最终状态 | 尝试次数 |
|---|---|---|
basics/4 | blocked | 3 |
basics/5 | ready | 1 |
basics/6 | blocked | 3 |
basics/7 | ready | 1 |
basics/8 | ready | 1 |
basics/9 | ready | 1 |
basics/10 | ready | 1 |
basics/11 | ready | 1 |
basics/12 | ready | 2 |
basics/13 | ready | 1 |
也就是：
ready = 8
blocked = 2
pending = 0
表面上看，80% 的页面已经完成。
但两个 blocked 的原因完全不同。
其中 basics/4 的前三次失败甚至根本不是翻译失败。
二、网络错误也会耗尽三次正式翻译额度
basics/4 前三次尝试全部出现了类似错误：
network: Post https://open.bigmodel.cn/...
dial udp ...
socket: operation not permitted
也就是说，请求根本没有真正到达 GLM-5.2。
但是现有正式流程只看“已经执行了几次 attempt”，三次之后还是把页面标记成了：
blocked
attempts=3
这就暴露出一个问题。
正式生产环境里，DNS、网络连接、临时基础设施故障都是可能发生的。
如果三次网络失败就永久占满三次翻译额度，那么一个实际上从未被模型翻译过的页面，也会被误判成“模型翻译连续失败”。
因此，这次新增了一个正式的网络故障恢复命令：
translate recover-network
它不是简单地把 attempts 清零。
恢复必须能够从历史审计记录中证明：
- 页面当前确实为
blocked； - 最近一个三次重试窗口全部属于网络错误；
- 每次都没有获得有效模型响应；
- 不包含结构校验失败；
- 不包含已经取得 HTTP 200 以后发生的翻译失败。
满足这些条件后，才允许显式恢复。
历史记录则永久保留。
例如：
attempt-001
attempt-002
attempt-003
network-recovery-001.json
attempt-004
attempt-005
attempt-006
不会覆盖前面的失败记录。
三、又发现一个问题：不能把“每次 CLI 调用”当成新的三次额度
最初实现网络恢复机制时，还顺带发现了一个比较隐蔽的问题。
如果把逻辑写成：
每次执行
translate run，从下一个 attempt 开始，再允许最多三次。
那么就可能出现：
第一次运行：
attempt-001 失败
↓
程序中断
第二次运行：
attempt-002
attempt-003
attempt-004
这样即使没有执行任何恢复操作，页面实际上也获得了 4 次正式机会。
如果反复中断，甚至可能继续增加。
所以后来把“历史 attempt 编号”和“当前重试窗口”彻底区分开。
现在的规则是：
初始窗口：001–003
第一次合法恢复：
004–006
第二次合法恢复：
007–009
同一个窗口中，无论命令执行多少次，都只能使用这个窗口剩余的次数。
只有显式执行并通过资格检查的恢复操作，才能开启下一个窗口。
这部分虽然不是翻译质量问题，却是以后真正批量运行时非常重要的状态安全问题。
四、恢复 basics/4 后，才真正遇到翻译失败
网络恢复机制完成以后，我重新恢复并运行了 basics/4。
结果新的三次尝试全部真正取得了 GLM-5.2 的 HTTP 200 响应，但仍然失败：
attempt-004
受保护 token 缺失、重复
attempt-005
token 全部正确
但 font span 数量不一致
attempt-006
5 个受保护 token 全部丢失
这一次，basics/4 才算真正成为了一个翻译失败页面。
其中最值得分析的是 attempt-005。
原文有一句：
Notice that the type comes _after_ the variable name.
模型翻译成了类似：
注意，类型位于变量名_之后_。
看起来 _之后_ 仍然存在。
但 present 对强调语法的解析依赖边界。
由于 _之后_ 紧贴在中文“变量名”后面，最终并没有被正确解析成斜体。
也就是说：
结构字符还在，并不代表结构语义还在。
五、强调结构：不再让模型自己维护 _ 和 *
此前行内代码等危险结构已经有保护机制，但斜体、粗体仍然主要依赖模型自己维持：
_after_
这次开始调整为“保护结构边界，继续翻译内部文字”。
概念上相当于：
<斜体开始标记>after<斜体结束标记>
其中：
after
仍然可以被翻译成：
之后
但开闭边界由程序负责。
如果模型输出：
变量名<斜体开始标记>之后<斜体结束标记>。
恢复阶段会确定性生成：
变量名 _之后_。
同时补上 present 解析真正需要的边界空格。
改完后重新使用开发模式运行 basics/4。
新的 attempt-007 一次通过：
token_valid = true
present_valid = true
status = ready
这次是真实 GLM-5.2 输出验证，而不仅仅是单元测试通过。
六、接下来是更有意思的 basics/6
basics/6 的原文非常简单：
* Multiple results
A function can return any number of results.
The `swap` function returns two strings.
.play basics/multiple-results.go
但是前三次正式翻译却连续失败。
第一次，模型在原有受保护 token 之外，又自己写了一个：
`swap`
最终恢复后变成两个 swap。
第二、第三次更奇怪。
模型主动生成：
.play basics/multiple-results.go 7,9
而原文只有：
.play basics/multiple-results.go
7,9 恰好对应示例代码中 swap 函数所在的代码范围。
模型似乎是在“自作聪明”地帮我优化代码展示范围。
但对于这个翻译项目来说，这恰恰属于不能接受的结构修改。
七、重试反馈也不能把错误答案重新喂给模型
继续分析后，我发现此前的重试反馈还有一个问题。
例如第一次失败只是：
inline code count mismatch
但反馈里却会出现类似：
check the named directive or protected content near the first difference
明明是行内代码错误，却又提醒模型去检查 directive。
随后模型果然开始改 .play。
而在 .play 修改错误以后，下一次反馈还会把完整的：
expected ...
actual ...
重新发给模型。
这就可能变成：
模型刚刚生成了一个错误结构，下一轮我们又把这个错误结构原样展示给它。
因此后来将重试反馈改成按错误类别生成安全摘要。
例如行内代码错误只会告诉模型：
上一次输出自行新增、删除或改变了行内代码结构。不得在普通文本中自行添加反引号代码；所有已受保护的行内代码只能通过现有 token 表示。
而不会再提 .play。
指令错误也只告诉模型：
不得自行书写
.play、.image等 present 指令。
具体错误内容仍然完整保存在：
validation.json
中，方便后续调试，但不会再直接送回大模型。
八、最有意思的问题：GLM 到底从哪里知道 swap？
接下来发生了一件让我非常意外的事情。
当时行内代码采用的是“整体遮蔽”方式。
也就是说：
`swap`
发送给模型前会变成：
⟪GTI18N_..._000001⟫
模型实际看到的是：
The ⟪GTI18N_..._000001⟫ function returns two strings.
按理说，它根本不知道这个 token 里面是什么。
但 GLM-5.2 的输出却准确写出了：
`swap` ⟪GTI18N_..._000001⟫ 函数返回两个字符串。
我一开始甚至怀疑，是不是程序在请求中的其他地方泄露了 swap。
于是专门检查完整 API 请求：
swap 0 次
multiple-results.go 0 次
basics/multiple-results.go 0 次
token 到原文的映射只保存在本地恢复数据里，并没有发送给模型。
也就是说，可以确认：
GLM-5.2 在这次 API 请求中没有直接看到
swap。
至于它为什么能够恰好补出 swap，无法进一步证明究竟是：
- 根据“The ___ function returns two strings.”和 Go 教程上下文推断出来的；
- 训练数据里见过 A Tour of Go 原文；
- 或者两者共同作用。
但至少可以确定一件事：
把语义内容遮住，并不等于大模型就真的不知道那里应该是什么。
九、也许我们低估了大模型的“自作聪明”
这次让我重新思考了保护策略。
原来的想法是：
swap不能翻译，那就干脆不要让模型看到。
于是：
`swap`
整体变成一个不透明 token。
但对于现在的大模型来说，它看到：
The <token> function returns two strings.
很可能会觉得：
“这里明显缺了一个函数名，我知道它应该是什么。”
于是主动把 swap 补回来。
而 token 又必须保留。
最终就出现：
`swap` <token>
也就是说：
我们为了防止模型乱动而遮掉语义，反而制造了一个模型非常想主动补全的语义空洞。
十、从“隐藏内容”改成“只保护结构”
因此，行内代码的保护方案也进行了调整。
不再这样：
The <一个完整不透明 token> function returns two strings.
而是变成：
The <行内代码开始标记>swap<行内代码结束标记> function returns two strings.
这样：
swap仍然对模型可见；- 模型可以完整理解句子；
- 反引号结构由程序保护；
- 开闭标记之间的内容必须与源文逐字保持一致；
swap2、exchange、翻译成中文、修改空白等行为都会直接被拒绝。
这和前面的强调结构保护形成了一个很统一的思路。
强调结构：
<斜体开始>after<斜体结束>
中间的 after：
允许翻译。
行内代码：
<代码开始>swap<代码结束>
中间的 swap：
允许模型看见，但不允许修改。
十一、第一次真实验证仍然失败
修改完行内代码保护后，我重新运行 basics/6。
结果还是失败：
inline code sentinel 1 content changed
查看 GLM-5.2 原始输出后，发现它生成的是：
`swap` <行内代码开始标记><行内代码结束标记> 函数返回两个字符串。
也就是说，它没有把 swap 改成其他内容。
它做的是：
原输入：
<开始>swap<结束>
模型输出：
`swap` <开始><结束>
它把 swap 从两个标记中间搬了出去，然后又自行补上反引号。
这一次程序新的严格检查发挥了作用。
因为开闭标记之间原本应该是：
swap
现在却变成了空字符串，因此在 candidate 生成前直接拒绝。
十二、保护协议变了，提示词也必须跟着变
继续检查完整请求后，我才发现：
虽然程序已经改成了成对保护标记，但提示词仍然只告诉 GLM：
每个 token 必须原样出现一次。
甚至还写着：
可以为自然中文语序调整 token 位置。
却没有告诉模型：
- 哪两个 token 是一对；
swap必须一直留在两个 token 之间；swap不允许翻译或移动；- 不得自己增加反引号；
- 反引号会由程序恢复。
所以从模型的视角看，它并没有真正违反自己所理解的规则。
它保留了两个 token。
也保留了 swap。
只不过把三者重新组织成了它认为更合理的形式。
因此最后又补充了动态生成的结构协议。
对于行内代码，提示词现在会明确说明：
这是同一个行内代码结构的 opening token 和 closing token。
两者之间当前可见的代码内容必须逐字原样保留在同一 pair 内。
不得翻译、改写、增删、移动到 pair 外，也不得移入其他内容。
不得自行添加反引号。
反引号由程序恢复。
强调结构则明确告诉模型：
开闭标记之间的自然语言允许翻译，但翻译后的内容必须始终留在原来的结构内部。
这样模型终于知道：
行内代码内部：
可见，但不能改
强调结构内部：
可见，并且可以翻译
十三、basics/6 最终通过
更新完提示词协议后，我再次执行：
go run -mod=readonly ./cmd/tour-i18n translate run \
-dev \
--locale zh-CN \
--id basics/6
这一次：
attempts: 6
status: ready
token_valid: true
present_valid: true
failures: []
passed: true
最终译文是：
* 多返回值
函数可以返回任意数量的结果。
`swap` 函数返回两个字符串。
.play basics/multiple-results.go
结构正确，中文表达也很自然。
basics/6 最终通过校验并正常显示中文页面这张实际渲染页面也能看到，左侧中文正文中的 swap 已经正确显示为行内代码，右侧仍然使用官方原始的 multiple-results.go 示例代码。
这正是这一轮调整希望达到的效果：
中文可以自然翻译，技术内容保持原样，页面结构仍然由程序严格控制。
十四、最终 10 个普通页面全部 ready
至此，最初 10 个普通页面中的两个 blocked 页面都已经解决。
最终结果变成：
basics/4 ready
basics/5 ready
basics/6 ready
basics/7 ready
basics/8 ready
basics/9 ready
basics/10 ready
basics/11 ready
basics/12 ready
basics/13 ready
也就是：
ready = 10
blocked = 0
pending = 0
为了更直观地确认这一批页面的最终状态，我又从 status.tsv 中单独整理出了页面、状态和尝试次数：
ready从尝试次数也很容易看出这一轮的特点。
basics/4 最终记录了 7 次 attempt，basics/6 记录了 6 次。这并不意味着普通页面普遍需要这么多次翻译，而是因为这两个页面承担了开发阶段的流程校准任务。
相比之下：
basics/5 1
basics/7 1
basics/8 1
basics/9 1
basics/10 1
basics/11 1
basics/13 1
都只用了一次。
basics/12 也只用了两次。
换句话说，真正的普通页面通过率其实已经相当不错。
十五、提交前再看一遍中文质量
在正式提交之前，我又让 ChatGPT 快速审核了这 10 页中文。
结果没有发现必须修正的技术错误，只对 5 页做了少量中文润色。
例如：
接受了两个
调整为：
接受两个
还有：
var 声明可以包含初始化器，每个变量一个。
调整为：
var 声明可以为每个变量指定一个初始化器。
以及：
变量声明可以像导入语句一样被“打包”成块
调整为：
变量声明可以像导入语句一样分组写成块
这些都属于中文自然度上的最后微调，并不影响结构或技术含义。
修改后，10 个页面重新执行统一 candidate 校验：
candidate OK: locale=zh-CN page_id=basics/4
candidate OK: locale=zh-CN page_id=basics/5
candidate OK: locale=zh-CN page_id=basics/6
candidate OK: locale=zh-CN page_id=basics/7
candidate OK: locale=zh-CN page_id=basics/8
candidate OK: locale=zh-CN page_id=basics/9
candidate OK: locale=zh-CN page_id=basics/10
candidate OK: locale=zh-CN page_id=basics/11
candidate OK: locale=zh-CN page_id=basics/12
candidate OK: locale=zh-CN page_id=basics/13
全部通过。
不过，这次人工快速审核仍然只是开发校准阶段的一次质量观察。
项目的正式目标并没有改变：
不会把逐页人工校对设置成所有页面发布前必须经过的固定流程。
如果后续普通页面持续表现稳定，就应该逐步转为异常页面重点检查、普通页面抽样观察。
十六、这次形成了两个 Git 提交
为了避免把翻译引擎修改和翻译产物混在一起，这次拆成了两个提交。
第一部分是翻译流程和保护机制：
6a55d0c feat: 完善翻译结构保护与失败恢复流程
第二部分是 10 个普通页面的翻译结果与完整审计：
801db69 feat: 完成首批 10 个普通页面翻译
最终已经推送到：
origin/main
推送完成后，本地工作区也重新恢复到了干净状态。
十七、这次最大的收获不是“又翻译了 10 页”
如果只看数字，这一轮只是又完成了 10 个页面。
但我觉得真正重要的不是页面数量，而是对“大模型翻译 + 确定性结构保护”这套思路理解得更深了一层。
最开始，我的保护思路比较接近：
模型不能动的东西，就全部藏起来。
这次逐渐调整成：
尽量让模型看到理解语义所需要的内容，只把真正危险的结构边界交给程序保护。
现在可以初步归纳为几种情况。
普通自然语言
直接交给模型翻译。
强调文字
例如：
_after_
保护开闭结构，但允许中间内容翻译。
行内代码
例如：
`swap`
保护开闭结构，内部内容继续让模型看到，但严格禁止修改。
.play、链接目标等不可翻译结构
这些内容本身不需要模型理解或翻译，仍然可以整体隐藏，再由程序确定性恢复。
这比简单地说“全部 token 化”更加细致。
十八、越强的大模型，可能越不能把它当成普通字符串替换器
swap 这一段给我的印象尤其深。
程序已经确认：
API 请求中：
swap = 0 次
但模型还是准确补出了 swap。
这让我感觉，使用能力越来越强的大模型时，不能只考虑：
它会不会犯低级错误？
还要考虑：
它会不会过度理解，然后自作聪明地替你做一些根本没要求它做的事情？
它可能会：
- 根据上下文补回被隐藏的内容；
- 主动优化
.play的展示范围； - 自动给代码增加反引号；
- 尝试把它认为“不完整”的结构修复成更合理的形式。
对于普通聊天，这些能力可能很有帮助。
但对于要求结构严格保真的翻译流水线来说，这些“聪明”反而可能成为新的不确定性来源。
因此，程序不能试图让模型“变笨”。
更合适的方法可能是：
把结构协议说清楚，同时用确定性程序限制模型真正能够修改的范围。
十九、下一阶段：降低开发介入频率
这一轮虽然只翻译了 10 个普通页面，但开发成本其实并不低。
因为现在仍然处于流程校准阶段：
发现失败
→ 分析 request / response
→ 修改保护逻辑
→ 写测试
→ 真实回归
→ 再分析
这种模式不可能一直持续到全部页面完成。
否则无论是时间、GLM API Tokens，还是 Codex 使用额度，都会消耗得非常快。
尤其现在项目已经进入一个比较关键的阶段：
前面的代表页和首批普通页面，本质上是在帮助我把翻译工具本身调稳定。
后面的目标应该逐渐变成：
批量翻译一批普通页面
→ 自动校验
→ 大部分直接 ready
→ 只有异常页面才进入深入分析
而不是每翻译一个页面，就继续修改一次翻译框架。
所以接下来真正需要观察的是：
在这次强调结构、行内代码、重试反馈和网络恢复机制都完善以后，下一批普通页面还能不能保持高通过率。
如果后续连续批次大部分页面都能一次或少量重试进入 ready，而不再频繁暴露新的共性结构问题，就应该逐步停止“每遇到一个特殊输出就修改系统”的开发方式，正式进入批量翻译阶段。
毕竟，这个项目最终的目标不是打造一个无限复杂的翻译框架。
而是建立一套：
足够简单、足够严格、能够把 A Tour of Go 多语言翻译稳定完成并持续同步上游的工程流程。
这一轮的 10 个普通页面，至少让我觉得距离这个目标又近了一步。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复