今天继续推进 go-tour-i18n 项目的简体中文翻译。
在前面的代表页验证和第一批普通页面自动试跑完成之后，翻译、结构保护、自动校验这一整套流程已经逐渐稳定。因此，这次继续选择下一批 10 个普通 pending 页面进行正式翻译。
原本以为这一批应该会比较平稳，实际结果也确实不错：前面大部分页面都顺利进入了 ready。
不过，最后一个 flowcontrol/6 连续 3 次失败，最终进入 blocked。
继续分析以后，却发现一个很有意思的问题：
GLM-5.2 并没有丢失 Protected Token，也没有破坏行内代码。真正出问题的是项目自己的恢复规则。
这个问题最终不仅修复了，还促使项目补上了一项很有价值的新能力：
当保护、恢复或者校验逻辑修复以后，可以直接重新验证之前已经成功返回的模型响应，而不需要再次调用大模型 API。
这次排查过程比较完整，因此单独记录下来。
一、继续第二批 10 个普通页面
当前项目仍然按照“完整课程页面”作为最小翻译单元。
整体流程是：
完整课程页面
→ GLM-5.2 整页翻译
→ 保存 Candidate
→ 自动结构和页面校验
├─ 通过 → ready
└─ 失败 → 有限整页重试 → blocked
这次选择的 10 个页面分别是：
basics/14
basics/15
basics/16
basics/17
flowcontrol/1
flowcontrol/2
flowcontrol/3
flowcontrol/4
flowcontrol/5
flowcontrol/6
正式翻译通过：
go run -mod=readonly ./cmd/tour-i18n translate run \
--locale zh-CN \
--id <page_id>
当前 --id 一次只接受一个页面，因此批量执行时，在外层使用 Shell 循环逐页串行调用。
二、9 页进入 ready，flowcontrol/6 连续 3 次失败
第一轮执行完成以后，结果如下：
| 页面 | 状态 | Attempts |
|---|---|---|
basics/14 | ready | 1 |
basics/15 | ready | 1 |
basics/16 | ready | 1 |
basics/17 | ready | 1 |
flowcontrol/1 | ready | 1 |
flowcontrol/2 | ready | 1 |
flowcontrol/3 | ready | 3 |
flowcontrol/4 | ready | 1 |
flowcontrol/5 | ready | 1 |
flowcontrol/6 | blocked | 3 |
其中 flowcontrol/3 虽然使用了 3 次 Attempt，但最终正常进入 ready。
真正需要进一步分析的是 flowcontrol/6。
它在第 3 次正式 Attempt 后仍然失败：
status: blocked
attempts: 3
token_valid: false
present_valid: false
最终错误是：
inline code sentinel 5 opening marker missing
flowcontrol/6 连续 3 次翻译后因 Inline Code Sentinel 校验失败进入 blocked从这个错误名称来看，很容易首先产生一个判断：
GLM-5.2 是不是把第 5 个 Inline Code Opening Marker 删除了？
但进一步检查原始模型响应以后，发现事实并非如此。
三、flowcontrol/6 本身并没有复杂结构
flowcontrol/6 对应的上游课程页面是：
* If with a short statement
Like `for`, the `if` statement can start with a short statement to execute before the condition.
Variables declared by the statement are only in scope until the end of the `if`.
(Try using `v` in the last `return` statement.)
.play flowcontrol/if-with-a-short-statement.go
这个页面的 Present 结构其实很简单：
- 普通标题；
- 普通段落；
- 5 个行内代码（Inline Code）；
- 1 个
.playDirective。
5 个行内代码依次是：
for
if
if
v
return
真正触发问题的是最后一句：
(Try using `v` in the last `return` statement.)
按照英文源码出现顺序，其中两个行内代码是：
v → return
四、GLM-5.2 根本没有丢 Token
检查 attempt-001、attempt-002 和 attempt-003 后发现，三次模型输出的关键句基本一致。
自然的中文表达是：
（试着在最后一个
return语句中使用v。）
于是，两个完整 Inline Code Pair 的出现顺序变成了：
return → v
而英文原文是：
v → return
也就是说，模型做的是：
英文：
v → return
中文：
return → v
最重要的是，模型并没有：
- 删除
return的 Opening Marker； - 删除
return的 Closing Marker； - 修改
return； - 删除
v； - 修改
v； - 自行增加反引号代码。
两个 Inline Code Pair 都是完整的。
真正发生的仅仅是：
两个完整的 Inline Code Pair 为了适应自然中文语序，整体交换了位置。
五、浏览器中的中文结果反而证明这种换位是合理的
修复并恢复页面后，在浏览器中查看最终中文页面，可以非常直观地看到这句话：
（试着在最后一个
return语句中使用v。）
flowcontrol/6 最终中文页面，return 与 v 为适应自然中文语序发生整体换位这张截图其实非常能说明问题。
如果仅仅为了保持英文源码中的：
v → return
而强迫中文也使用相同顺序，就很可能需要把中文刻意改写成不自然的表达。
而：
在最后一个
return语句中使用v
显然才是正常的中文语序。
因此这次真正需要思考的并不是：
怎么让 GLM 永远不要调整 Token 顺序？
而是：
哪些顺序属于必须保护的结构，哪些顺序应该允许随着目标语言自然变化？
六、真正的问题出在 Restore 的 Source Order 假设
问题最终定位到 validateInlinePairs()。
旧实现按照源码中的 Inline Pair 顺序进行单向扫描。
原始顺序是：
for
→ if
→ if
→ v
→ return
模型输出则是：
for
→ if
→ if
→ return
→ v
旧逻辑按照源码顺序先寻找 v。
找到 v 后，再继续从后面的文本寻找 return。
问题是：
return 已经因为自然中文语序，被完整移动到了 v 前面。
所以程序在 v 后面当然找不到第 5 个 Pair 的 Opening Marker。
最终产生：
inline code sentinel 5 opening marker missing
事实上，这条错误信息也具有一定误导性。
Marker 并没有 Missing。
真正的问题只是：
旧恢复器默认不同 Inline Pair 必须继续维持 Source Order。
七、结构保护不能反过来破坏自然语言
这次最终没有选择继续强化 Prompt，要求 GLM-5.2：
所有 Inline Code Pair 必须严格保持英文原始顺序。
因为这样做虽然可能让旧校验器通过，却会引入另一个问题：
为了程序校验方便，牺牲目标语言自然表达。
这并不符合这个项目最开始确定的翻译目标。
结构保护真正应该严格保证的是：
- Opening Marker 不能缺失；
- Closing Marker 不能缺失；
- Pair 不能被拆散；
- Pair 内代码内容不能改变；
- Pair 不能重复；
- Pair 不能伪造；
- Pair 不能交叉；
- Pair 不能嵌套；
- 模型不能在 Token 外自行增加新的反引号代码。
但是：
两个各自完整、语义独立的 Inline Code Pair，没有必要因为英文出现顺序不同，就禁止它们随目标语言语序整体换位。
八、修改 Inline Pair 恢复规则
因此最终修正的是 Restore，而不是强迫模型改变中文。
新的 validateInlinePairs() 不再按照不同 Pair 的 Source Order 单向扫描。
现在会分别定位每一个 Pair 自己的：
Opening Marker
原始 Payload
Closing Marker
然后严格验证：
- Opening Marker 必须存在；
- Closing Marker 必须存在；
- Opening 必须位于对应的 Closing 前；
- Pair 内 Payload 必须逐字节一致；
- Pair 不能交叉；
- Pair 不能嵌套。
但是允许不同的完整 Pair 整体换位。
因此：
Source：
v → return
转换为：
Translation：
return → v
现在属于合法行为。
前提仍然是两个 Pair 本身都完全没有受到破坏。
九、最终 Validator 原本就允许这种换位
继续审阅以后，还发现一个很重要的问题。
最终的 Candidate Validator 对 Inline Code 原本使用的就是无序保护内容比较。
它严格验证：
- Inline Code 数量；
- Inline Code Payload；
- Inline Code Multiset。
但并不要求不同 Inline Code 始终保持 Source Order。
所以此前实际上存在一个内部规则冲突：
Restore：
要求不同 Inline Pair 保持 Source Order
最终 Validator：
允许完整 Inline Code 根据自然语言整体换位
flowcontrol/6 第一次稳定暴露出了这个矛盾。
修复以后，两层规则终于统一：
单个 Inline Code Pair 内部严格；不同完整 Pair 之间允许自然语序换位。
十、为什么没有修完以后再请求一次 GLM？
Restore 修好以后，又出现了另一个问题。
此时 flowcontrol/6 已经正式进入：
blocked
正式状态下，普通：
translate run
不会继续运行 Blocked 页面。
虽然开发模式可以继续请求模型，但那样会创建新的 Attempt，并再次消耗 GLM Token。
问题是，这次根本没有重新翻译的必要。
因为已经确认：
- 第 3 次 API 请求成功；
finish_reason=stop；- 模型 Content 完整；
- Protected Token 完整；
- Inline Code 内容没有修改；
- 真正失败的是旧 Restore。
所以如果修改完项目自己的 Bug，却要求模型重新翻译一次，实际上是在浪费已经获得的有效结果。
更合理的流程应该是：
修复 Restore
→ 读取已经保存的历史模型响应
→ 使用新 Restore 恢复
→ 使用当前 Validator 重新验证
而不是：
修复 Restore
→ 再次调用 GLM
十一、recover-network 不能解决这个问题
项目此前已经存在：
translate recover-network
但是它有非常明确的职责：
恢复真正因为网络故障而失败、实际上没有得到有效模型响应的 Attempt。
它要求历史 Attempt 属于：
api_success=false
network failure
没有有效模型 content
而 flowcontrol/6 完全相反：
api_success=true
有完整 response
有完整 content
失败的只是旧版 Restore。
因此不能为了方便，直接复用 recover-network。
不同类型的失败应该保留明确、独立的恢复语义。
十二、新增 translate revalidate-response
为了解决这类问题，这次新增了一个正式 CLI：
go run -mod=readonly ./cmd/tour-i18n translate revalidate-response \
--locale zh-CN \
--id flowcontrol/6 \
--attempt 3
它解决的是：
历史模型响应成功，但是因为后来修复了保护、恢复或者校验逻辑，需要按照当前规则重新验证。
整个流程是：
读取历史成功 Response
→ 使用当前 protectTranslation()
→ 使用当前 restore()
→ 使用当前 ValidateCandidate()
→ 全部通过
→ 写入正式 Candidate
→ blocked → ready
整个过程中不会：
- 调用 GLM；
- 创建新的 Translation Attempt；
- 增加 Retry Quota；
- 修改历史 Response；
- 修改历史 Request；
- 覆盖历史 Validation。
十三、Revalidation 仍然必须 Fail Closed
增加历史响应重新验证能力以后，也不能让它变成一个绕过正式状态机的后门。
因此 revalidate-response 会严格检查：
- Page ID 存在；
- Locale 有效；
- 当前 Source Hash 一致；
- 当前状态必须是
blocked； - 指定 Attempt 必须存在；
- Request、Response、Validation 审计必须完整；
- 历史 Request 的 Page ID、Locale 和 Source Hash 必须全部匹配；
- 历史 API 请求必须成功；
finish_reason必须是stop；- Content 不能为空。
之后仍然必须执行完整的：
protect
→ restore
→ ValidateCandidate
只要其中任何一步失败：
status
仍然保持：
blocked
绝不会因为历史 Response 曾经 HTTP 成功，就直接晋升到 ready。
十四、第一次真实历史响应重新验证成功
功能完成并通过测试以后，正式对 flowcontrol/6 的第 3 次历史响应执行：
go run -mod=readonly ./cmd/tour-i18n translate revalidate-response \
--locale zh-CN \
--id flowcontrol/6 \
--attempt 3
最终结果：
source_attempt: 3
attempts: 3
status: ready
token_valid: true
present_valid: true
passed: true
attempt-003 重新验证成功，flowcontrol/6 从 blocked 恢复为 ready这张截图中最值得注意的其实不是：
status: ready
而是：
source_attempt: 3
attempts: 3
也就是说，没有出现：
attempt-004
GLM-5.2 也没有再被调用一次。
这从真实数据层面证明：
第 3 次模型输出本身就是可以使用的。此前真正失败的是项目自己的 Restore 规则。
十五、历史 Attempt 不能因为后来成功就被改写
flowcontrol/6 已经存在：
attempt-001
attempt-002
attempt-003
这些历史 Attempt 全部继续保留，而且不会被修改。
重新验证会另外生成：
revalidation-001.json
因此最终审计链表达的是：
attempt-003：
按照当时的 Restore 规则验证失败
↓
修复 Restore
↓
revalidation-001：
使用同一个历史 Response，
按照新的 Restore + Validator 验证成功
而不是把过去的失败记录重新改写成成功。
这对于长期维护非常重要。
失败发生过，就应该保留当时真实的失败记录。
后来的代码修复和重新验证则作为新的审计事件继续追加。
十六、顺便修复审计文件里的绝对路径
第一次产生 revalidation-001.json 后，最终审阅时又发现了一个小问题。
审计数据中的：
response_path
validation_path
最初保存的是本机绝对路径。
例如：
/home/wangqiang/code/go-tour-i18n/...
功能上虽然没有问题，但如果这些数据长期进入 Git 仓库，就会绑定当前机器和当前目录结构。
如果以后：
- 换电脑；
- 换用户名；
- 换仓库目录；
这些绝对路径都会失去可移植性。
因此最终将 Revalidation 审计中的来源路径改为仓库相对路径：
data/translation-runs/zh-CN/flowcontrol/6/sources/.../attempt-003/response.json
并增加测试，确保以后不会再次将本机绝对路径写入这类审计字段。
十七、提交之后，又发现一个已经过时的 TestCommittedStatus
这一批翻译和 Revalidation 功能完成以后，首先创建了提交：
b7de0e0 feat(i18n): 支持历史响应复验并完成第二批页面翻译
但是提交后重新运行：
go test ./internal/i18n
go test ./...
仍然出现一个失败：
basics/4: ready, attempts=7
一开始看起来像是本次提交导致了某个状态异常。
但是继续分析以后发现：
这个测试在本次提交之前其实就已经失败了。
问题出在 TestCommittedStatus 本身已经跟不上当前项目工作流。
十八、旧 TestCommittedStatus 本质上是一份 Ready 页面白名单
旧测试除了运行基础的 CheckStatus() 外，还维护着一个 Page ID 白名单。
少数已经人工确认的历史页面允许：
ready
而没有进入这个 switch 白名单的页面，默认都被要求：
pending
attempts=0
CandidatePath=""
这种设计在项目早期很合理。
因为当时只有少数代表页面进入 ready，测试可以借此防止没有经过确认的运行期状态意外进入 Git。
但是项目现在已经进入正常批量翻译阶段。
每完成一批页面，就会自然出现新的：
ready
如果仍然沿用旧设计，那么以后每完成 10 页，都得再到测试文件里手工加入 10 个 Page ID。
这显然已经不再合理。
十九、为什么首先只报 basics/4？
目前整个项目已经有不少 ready 页面。
但是测试首先只显示：
basics/4: ready, attempts=7
这并不意味着只有 basics/4 有问题。
只是测试在遇到第一个失败以后就立即 Fatal。
basics/4 恰好是最早遇到的：
没有进入旧白名单，但已经合法成为
ready的页面。
后面的其他新 Ready 页面实际上也会遇到同样的问题。
二十、attempts=7 并不代表正式允许重试 7 次
basics/4 的另一个特殊点是：
attempts=7
这个数字乍看起来似乎超过了项目正式阶段的有限重试次数。
但这里实际上记录的是：
该页面整个开发历史中单调递增的 Attempt 编号。
basics/4 早期经历过：
- 基础设施网络失败；
- Network Recovery；
- 正式模型响应结构失败；
- 开发校准阶段继续验证；
- 最终生成合法 Candidate。
因此历史编号最终来到 7。
它并不等同于：
正式生产流程允许连续自动重试 7 次。
当前 Retry Window 和历史 Attempt 编号实际上已经是两个不同概念。
所以不能为了让测试变绿，就把：
attempts=7
强行改小。
这样反而会破坏真实审计历史。
二十一、把静态白名单改成通用状态不变量
最终没有继续扩大 Ready 页面白名单。
而是将 TestCommittedStatus 改为真正验证“一个已经提交的状态是否合法”。
对于 pending：
- Candidate Path 必须为空；
- 不强制要求
attempts=0，以兼容开发阶段已经发生 Attempt、但仍然保持 Pending 的合法情况。
对于 blocked：
attempts > 0；- Candidate Path 必须为空；
- 不使用
attempts <= 3这种错误限制。
对于：
ready
candidate
published
则要求：
attempts > 0；- Candidate Path 必须是根据 Page ID 推导出来的标准路径；
- Candidate 文件必须真实存在；
- Candidate 必须通过当前
ValidateCandidateForLocale()。
于是测试关注的问题变成：
这个状态是否满足状态机长期应该成立的不变量？
而不再是：
这个 Page ID 有没有提前写进测试白名单？
这样以后再增加新的 Ready 页面，就不需要不断修改测试里的 Page ID 列表。
二十二、真正有历史价值的精确断言仍然保留
原来的测试中，一些特殊历史页面还有针对：
- Attempts；
- Source Hash；
- Candidate Path；
- UpdatedAt；
- Note；
等字段的精确断言。
这些并没有简单全部删除。
如果某些页面确实承担历史迁移、恢复或者特殊校准行为的回归价值，继续锁定它们的元数据仍然有意义。
最终只是把两种职责拆开：
通用状态合法性
和：
个别重要历史行为回归
不再让一个历史白名单同时承担未来所有页面的状态合法性判断。
二十三、完整测试最终恢复通过
测试调整以后，重新执行：
go test ./internal/i18n
通过。
随后：
go test ./cmd/tour-i18n
go test ./...
也全部通过。
状态检查：
go run -mod=readonly ./cmd/tour-i18n status check \
--locale zh-CN
结果：
status OK: 103 pages for zh-CN
最后又建立一个独立提交：
13ec759 test(i18n): 修正已提交翻译状态校验
没有将它 Amend 到前一个功能提交中。
所以这次最终产生了两个职责非常清楚的提交：
b7de0e0
feat(i18n): 支持历史响应复验并完成第二批页面翻译
13ec759
test(i18n): 修正已提交翻译状态校验
随后两个提交一起推送到 origin/main。
最终本地和远程均为：
13ec759
工作树保持干净。
二十四、第二批最终结果是 10/10 Ready
刚刚结束自动翻译时，这一批一度是：
9 ready
1 blocked
但经过问题定位和 Restore 修复以后，flowcontrol/6 直接复用了之前的 attempt-003 原始模型响应，并成功重新验证。
所以第二批最终结果实际上是：
10 / 10 ready
截至这次提交完成，整个项目的状态已经来到：
ready=35
pending=68
blocked=0
总页面数：
103
状态检查和完整测试均已通过。
二十五、这次最大的收获并不是又翻译了 10 页
如果只看数字，这次只是新增了 10 个 Ready 页面。
但从工程角度看，我觉得这次更重要的是暴露并解决了三个问题。
第一个是：
Protected Token 的严格保护，不应该等同于严格维持英文语序。
只要一个 Inline Code Pair 本身保持完整，它完全可以随着目标语言的语义单元整体移动。
第二个是：
模型翻译失败与校验器错误拒绝必须严格区分。
如果历史 Response 本身没有问题，只是后来发现旧 Restore 或 Validator 存在缺陷，那么代码修好以后，应当优先复用已有模型响应，而不是重新花一次 API Token。
这也是这次新增：
translate revalidate-response
最大的价值。
第三个是：
测试本身也需要随着项目工作流演进。
项目早期：
只有少量指定页面允许 ready
可能是一条非常有价值的保护规则。
但当项目真正进入批量翻译以后，长期不变量应该变成：
任何 ready 页面，
都必须拥有合法 Candidate，
并通过统一 Validator。
而不是继续维护越来越长的 Page ID 白名单。
二十六、下一步继续小批量推进
目前还有：
pending=68
并且：
blocked=0
接下来仍然不会直接一次把剩余 68 页全部翻译完。
下一步继续采用：
10 页一批
的方式推进。
今天这次经历也再次证明，批量翻译阶段真正需要观察的不只是成功率。
更重要的是：
每一批新的课程页面，会不会出现此前代表页和已有批次没有覆盖到的结构组合？
如果后面继续稳定，再考虑是否扩大每批页面数量。
如果再次出现新的 blocked，则继续按照现在已经逐渐形成的流程处理：
保留完整 Attempt
→ 检查原始模型 Response
→ 判断模型问题还是工具链问题
→ 最小修复
→ 使用统一验证链重新验证
而不是单纯为了让页面通过，不断增加 Prompt 限制或者重复调用模型。
第二批 10 个普通页面，到这里算是正式完成。
相比单纯又增加了 10 个 Ready 页面，我觉得这一批真正留下来的成果其实是两项新的工程能力：
完整 Inline Code Pair 支持自然语序换位
以及：
历史成功模型响应可以重新验证
这两点对于后续剩余 68 页的自动翻译，应该都会比单纯的页面数量更有价值。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复