最近几天，我一直在继续推进 A Tour of Go 多语言翻译项目。
前面的开发重点之一，是保护 .article 页面里那些不应该被大模型随意翻译或修改的结构，例如行内代码、链接目标、预格式化代码、强调结构以及 .play directive 等。
整体思路大致是：
完整课程页面
↓
识别需要保护的结构
↓
替换为 protected token / sentinel
↓
GLM-5.2 整页翻译
↓
恢复 protected token
↓
统一自动校验
↓
通过 → ready
失败 → 重试 / blocked
这套方案已经能够正常工作，而且前面经过多轮代表页校准以后，结构保护、恢复和校验能力也越来越完整。
但随着保护规则不断增加，我开始重新考虑一个更基础的问题：
输入给大模型之前，真的有必要对原始课程页面做这么多处理吗？
2026 年 8 月 10 日，我专门围绕这个问题做了一轮真实实验。
最后的结果并不是简单地证明“新方案更好”，而是让我对保护多少、在哪里保护，以及翻译质量和程序复杂度之间如何取舍有了更清晰的认识。
一、真正让我重新考虑输入架构的，是前一天的 swap 问题
此前遇到过行内代码因为中文语序调整而换位的问题。
不过，这个问题后来已经意识到，而且对应的校验规则也已经放宽。因此，它并不是这次重新考虑输入架构的直接原因。
真正让我开始认真怀疑“大量 Token 保护是否必要”的，是前一天遇到的 swap 问题。
为了确保某些原始内容绝对不被 GLM-5.2 修改，程序会先将它们替换成 protected token，让模型围绕这些占位符完成整页翻译。
这种做法在结构安全方面有很明显的优势，但同时也意味着：
模型真正看到的输入
≠
A Tour of Go 原始页面
当 swap 这样的真实标识符被替换成没有业务语义的占位符以后，模型无法再直接理解：
swap
究竟是函数名、代码标识符，还是普通英文单词。
保护层越复杂，模型实际能够看到的真实上下文就越少。
更麻烦的是，保护本身还会引入新的程序逻辑：
识别
→ Token 化
→ Token 完整性校验
→ 恢复
→ 边界处理
→ 顺序与数量比较
也就是说，我们原本是为了防止大模型犯错而增加保护，但保护系统本身也开始成为一个需要持续维护的复杂子系统。
swap 问题让我开始重新思考：
如果最终输出本来就必须经过严格自动校验，那么输入端是否真的需要保护这么多内容？
换一种思路：
是否可以尽量让 GLM-5.2 看到真实的英文原始页面，只保护极少数真正不能让模型碰的机器结构，然后把更多安全责任交给统一 validator？
这才是这次架构实验真正的起点。
二、先增加一个 --raw-input 实验模式
我没有直接删除已经成熟的默认保护流程，而是增加了一个专门用于实验的参数：
--raw-input
启用以后，程序仍然按照原有规则：
ReadCatalog
→ BuildSourceCatalog
→ HydrateCatalogSources
→ 根据 page_id 提取完整 production 页面
也就是说，一个浏览器课程页面对应的完整源内容仍然由程序正确提取。
改变的只是后面这一段。
默认模式：
Page.Source
↓
protectTranslation
↓
GLM-5.2
↓
restore
↓
ValidateCandidate
--raw-input：
Page.Source
↓
GLM-5.2
↓
ValidateCandidate
不再执行大规模 protected token 替换，也不再执行翻译后的 restore。
但有一点非常重要：
--raw-input并没有绕过任何输出校验。
GLM-5.2 的输出仍然必须继续通过现有：
present 单页解析
directive 校验
链接 target 校验
链接内代码校验
普通 inline code 校验
预格式化内容校验
emphasis/font span 校验
Section topology 校验
directive placement 校验
术语规则
也就是说，新实验并不是：
相信大模型不会犯错。
而是：
允许模型犯错，但程序必须发现错误。
三、flowcontrol/6：第一次 raw-input 真实请求直接通过
第一个真实测试页面选择了：
flowcontrol/6
执行：
go run ./cmd/tour-i18n translate run \
--locale zh-CN \
--id flowcontrol/6 \
--dev \
--raw-input
结果直接通过：
status: ready
token_valid: true
present_valid: true
passed: true
flowcontrol/6 首次原始输入实验直接通过统一自动校验这里终端显示：
attempts: 4
后来检查真实审计记录以后确认，这并不意味着 raw-input 连续尝试了 4 次。
attempt 1～3 是此前默认 protected-token 流程留下来的历史审计。
真正的 raw-input 只有：
attempt 4
而且一次通过。
这次调用的实际 Token 使用量为：
prompt: 1318
completion: 85
total: 1403
相比之前同页默认方案单次约 2300 多 Tokens，输入量明显减少。
不过，我现在并不会因为这一页就得出：
raw-input 的翻译质量一定比默认方案高。
更准确的结论应该是：
减少 protected token 后，GLM-5.2 能直接看到更多真实页面内容，同时至少在这一页上仍然可以一次通过现有统一校验。
这证明“大量 Token 化”并不是可靠翻译的唯一途径。
如果某些结构实际上可以直接暴露给模型，而 validator 又能够可靠检查，那么输入端确实存在明显简化的空间。
四、这里需要区分“首次机器翻译质量”和“最终发布质量”
raw-input 有一个很直观的潜在优势：
模型看到的原始上下文更多。
因此，模型第一次生成的中文可能更自然，语言组织也受到更少占位符干扰。
但这不意味着：
raw-input 最终一定比默认 protected-token 方案翻译得更好。
项目最终交付的并不是 GLM-5.2 第一次吐出来的 candidate。
即使继续使用当前默认方案，全部课程页面翻译完成以后，仍然可以统一进行人工润色和微调。
因此最终发布质量很可能是：
默认 protected-token
+ 完整自动校验
+ 发布前统一润色
与：
raw / minimal-protect
+ 完整自动校验
+ 发布前统一润色
达到相近水平。
甚至前者最终完全可能更好。
所以这次实验真正需要比较的，并不是简单的：
哪一种方案第一次翻译出来的中文更漂亮？
而是整体工程成本：
输入处理复杂度
模型能够看到的真实上下文
结构失败概率
重试次数
Token 消耗
restore 复杂度
validator 能否可靠发现错误
长期维护成本
最终发布质量
翻译质量当然非常重要，但它不是唯一指标。
五、methods/24 很快证明：完全 raw 同样有明显风险
如果只看 flowcontrol/6，很容易变得过于乐观：
那是不是干脆所有页面都直接发送原始内容？
所以第二个测试页面，我选择了结构明显复杂得多的：
methods/24
这一页包含：
.play methods/images.go
同时还有多个链接、链接 target、9 个行内代码、链接标签中的 image.Rectangle、静态预格式化 Go 代码块，以及 *Note* emphasis/font span。
第一次 raw-input 运行以后：
present_valid: false
报错：
methods/24: candidate present structure:
present parse:
methods.article:21: no match for zh-cn
methods/24 首次实验在 present 解析阶段失败进一步查看 GLM-5.2 的完整 response 后，原因非常明确。
原始页面是：
.play methods/images.go
模型却自行生成了：
.play methods/images.go /zh-cn/methods/24
也就是说，GLM-5.2 似乎认为自己是在“完善”这条内容，为它补充一个路径。
但是对于 Go present 来说，这不是自然语言。
这是机器指令。
于是 parser 将附加内容当成 directive 参数继续解析，最终报：
no match for zh-cn
我又做了一次独立 raw-input 实验。
这一次 GLM 没有追加：
/zh-cn/methods/24
而是换成：
.play methods/images.go /src/methods/images.go
两次独立请求都主动修改 .play，已经足以说明：
.play这种机器 directive 不适合完全交给模型自由生成。
六、GLM 还会主动“改善”链接显示格式
methods/24 的 raw-input 实验还发现了另外一个很有意思的问题。
4 个链接 target 始终都被正确保留。
已有的 9 个 inline code 也没有丢失。
静态 Go 代码块同样逐行保持正确。
但模型会主动调整链接显示文字的格式。
例如原始：
[[/pkg/image/#Image][Package image]]
GLM 会生成：
[[/pkg/image/#Image][`image` 包]]
最后一个链接中的：
image/color package
也被改成：
`image/color` 包
从普通技术中文的阅读习惯来看，这种排版甚至很合理。
但从这个项目的结构原则来看，模型凭空新增了源页面不存在的 inline code span。
因此 validator 仍然应该拒绝。
这说明完全 raw 的一个根本风险：
模型不仅会翻译，它偶尔还会主动“优化”它认为可以优化的结构。
对于普通文章，这可能是优点。
对于需要和上游 .article 保持结构对应关系的翻译项目，这有时候就是错误。
七、于是开始实验第三条路线：--minimal-protect
走到这里，两个极端都已经出现问题。
原方案：
大量 protected token
结构控制能力强，但输入和恢复逻辑越来越复杂。
完全 raw：
原始页面
→ GLM
程序明显简单，但机器结构可能被模型主动改写。
所以我开始测试第三条路线：
只保护已经有真实证据证明高风险的机器结构。
为此增加：
--minimal-protect
第一版没有重新保护 inline code、链接、emphasis 或静态代码块。
只保护完整的：
.play methods/images.go
它会被替换成唯一 Token，例如：
⟪GTI18N_d80f0d46_000001⟫
其余页面仍然几乎保持原始状态交给 GLM-5.2。
模型返回以后，这一个 Token 再恢复成：
.play methods/images.go
结果非常明确：
.play问题彻底消失。
GLM 原样、恰好一次保留了该 Token。
restore 也精确生成：
.play methods/images.go
没有再追加：
/zh-cn/...
或者：
/src/...
这说明最小保护这个方向确实是有效的。
至少对于 .play：
让模型完全没有修改权，比依靠提示词要求“请不要修改”更稳定。
八、只保护 .play 后，真正剩下的问题变得更清楚
.play 被稳定处理以后，再次运行 methods/24。
这一次不再出现 present directive 解析失败。
取而代之的是：
link inline code at link index 1 count mismatch:
expected 0, actual 1
.play directive 后，directive 问题消失，但链接标签被模型自行加上行内代码格式检查 response 后确认：
Package image
仍然被改成：
`image` 包
而：
image/color package
也再次变成：
`image/color` 包
也就是说，最小保护确实解决了第一类问题。
同时也把下一类真实风险暴露得更加清楚：
机器 directive
→ 应该直接保护
普通链接标签
→ 模型仍然需要翻译
→ 但不能自行改变 span 结构
此时最容易想到的是：
那就继续保护
image和image/color。
但仔细分析以后发现，这并没有真正解决问题。
假设：
Package image
变成：
Package ⟪TOKEN⟫
GLM 完全可能仍然生成：
`⟪TOKEN⟫` 包
Token 本身没有被改。
restore 以后仍然是：
`image` 包
所以：
保护一个字符串本身，并不等于保护这个字符串周围的结构边界。
如果沿着这种方向继续扩展，很容易重新出现越来越多的边界 Token。
九、再试一次：让 validator 的失败反馈真正进入下一次请求
项目正式翻译流程本来支持有限整页重试。
前一次 candidate 校验失败以后，可以生成 feedback，再交给下一次完整页面翻译。
但开发模式：
--dev
此前每运行一次命令，只执行一个 attempt。
这意味着前面的多个实验虽然连续执行，但实际上属于不同进程。
后一轮并没有真正收到上一轮 validation failure。
为了验证：
不增加新的保护，只告诉模型具体错在哪里，能不能自行纠正？
我又增加了：
--dev-attempts
例如：
--dev \
--dev-attempts 2
这样，同一个 TranslationRunner.Run 内就可以连续执行两个 attempt。
第一次失败后生成的 feedback，会真正加入第二次 user prompt。
针对链接标签新增 inline code 的情况，反馈也被改得更具体：
上一次输出在链接显示文本中新增了源页面不存在的行内代码格式。
不要给原本是普通文本的链接标签添加反引号或行内代码标记；
保留源页面已有的链接 target 和已有行内代码结构。
普通链接显示文字仍可正常翻译。
请重新翻译完整页面。
这里没有写死：
methods/24
image
image/color
因此仍然属于可以复用的通用反馈。
十、继续实验以后，又出现新的 font span 问题
最后一次真实实验使用：
go run -mod=readonly ./cmd/tour-i18n translate run \
--locale zh-CN \
--id methods/24 \
--dev \
--dev-attempts 2 \
--minimal-protect
最终 attempt 7 仍然没有通过：
font span count mismatch:
expected 10, actual 9
到这里，整个实验已经开始出现一条很有代表性的路径：
完全 raw
↓
.play 被改写
只保护 .play
↓
链接标签被主动新增 inline code
增加精确反馈和连续重试
↓
又出现新的 font span 结构问题
这并不能说明 minimal-protect 的方向是错的。
相反，它已经证明：
.play
这样的机器结构非常适合采用最小保护。
而很多其他结构实际上也比我最初预想的稳定。
真正需要警惕的是：
如果每发现一种新失败，就立即增加一种新的保护规则，最后很可能又重新走回“大量 Token 化”。
只不过重新实现了一遍。
十一、因此我决定在这里停止继续优化
理论上，接下来还可以继续。
看到：
font span count mismatch
以后，再增加 emphasis/font span 保护。
然后测试 .image。
再测试其他 directive。
继续验证更多预格式化内容和复杂链接。
从纯技术研究角度看，这些都有价值。
但项目真正的目标不是：
写出一个理论上最完美的翻译保护框架。
真正的目标还是：
完成 A Tour of Go 简体中文翻译，并建立一套以后能够扩展其他语言的稳定流程。
而且继续进行这种高频架构实验，还存在一个非常现实的问题：
每发现一个现象，都需要 Codex 读取仓库、分析审计、修改程序、补测试，然后再做 GLM 实验。
开发资源不是无限的。
如果继续追求理论上的完美，很可能反而拖慢真正的翻译工作。
所以这次我决定：
实验到这里暂时收口，不继续主动扩展 minimal-protect。
十二、现在应该怎样评价默认方案与 raw-input？
经过这轮实验以后，我反而不认为应该简单地说：
raw-input 更好。
或者：
默认 protected-token 更好。
两种方案解决的是不同问题。
默认方案的优势很明显：
结构控制更成熟
已经经过多轮代表页验证
自动校验体系已经适配
当前可以继续正式生产翻译
raw-input 或 minimal-protect 的潜在优势同样明显：
模型看到更多真实上下文
提示输入更短
protected token 数量更少
restore 逻辑可能明显简化
程序长期维护成本可能更低
至于翻译质量，也不能只比较第一次机器输出。
raw-input 因为上下文更加完整，有可能直接产生更加自然的初稿。
但当前默认方案完成全部页面以后，还可以统一进行人工润色、术语调整和细节微调。
因此最终结果完全可能是：
默认 protected-token 方案
+ 自动校验
+ 后期人工润色
最终质量与 raw-input 相当，甚至超过 raw-input。
所以这次实验真正让我感兴趣的，不只是译文质量。
更重要的是：
有没有办法在不牺牲结构安全的前提下，让输入处理和恢复程序变得更简单。
十三、我现在更看好的长期方向
如果以后继续简化当前架构，我现在更倾向于：
完整原始页面优先
↓
只保护少量真正高风险的机器结构
↓
GLM-5.2 整页翻译
↓
最小恢复
↓
严格统一 validator
↓
针对性 retry feedback
也可以概括成：
真实上下文尽量交给模型
机器控制结构尽量不给模型修改权
最终安全由统一 validator 保证
这比“所有危险内容全部 Token 化”更加轻量。
同时也比：
完全 raw
更加可靠。
不过，这只是这次实验留下的一个长期方向。
它还没有成熟到可以直接替换当前正式流程。
十四、保存实验成果，但恢复正式翻译现场
虽然这轮实验暂时停止了，但所有代码和真实审计都保留下来了。
最终形成两个提交：
62b1b1a feat: 增加翻译输入实验与最小保护能力
35259cf docs: 记录翻译输入架构实验结论
其中保存了：
--raw-input
--minimal-protect
--dev-attempts
针对性 retry feedback
真实 request / response / validation 审计
实验过程中，因为使用了 --dev，flowcontrol/6 和 methods/24 的状态曾临时发生变化。
结束实验后，我又把：
status.tsv
candidate
全部恢复到正式实验前状态。
最终检查：
flowcontrol/6 ready
methods/24 ready
Working tree clean
两个提交也已经同步到：
origin/main
这样，这轮实验既没有丢失，也没有污染目前已经确认的正式翻译结果。
以后如果重新研究输入架构，可以直接基于这些真实 attempt 继续，而不是重新从头开始。
十五、下一步：回到真正的课程翻译
实验结束以后，当前正式翻译路径暂时不变：
继续使用已经成熟的 protected-token 流程。
接下来重新回到此前已经确定的计划：
开始普通 pending 页面自动试跑。
不再主动枚举剩余几十个页面可能出现的所有结构风险。
如果普通页面大多数能够直接通过，那么就继续推进。
只有实际出现新的失败时，再分析：
是模型真正翻译错了
还是保护层的问题
还是 validator 仍有缺口
然后只解决真实出现的问题。
这比在正式翻译开始以前不断预测未来边界，要更符合项目现在的阶段。
总结
这轮实验最开始的问题其实很简单：
输入给 GLM-5.2 之前，真的有必要做这么多 Token 保护吗？
flowcontrol/6 证明：
不做大规模保护，完整原始页面也可以直接通过现有统一校验，而且输入更加简洁。
methods/24 又证明：
完全 raw 不足以稳定保护
.play这样的机器结构，大模型会主动“帮忙”修改它。
而 --minimal-protect 进一步证明：
少量、有明确证据支持的机器结构保护确实有效。
但继续实验以后又出现链接标签和 font span 等新问题，也提醒我：
如果每出现一种失败就继续增加一种保护规则，最终仍然可能回到复杂的 Token 系统。
因此，这次并没有得出“应该马上推翻现有方案”的结论。
当前默认方案已经成熟到足以继续完成剩余页面。
而且等所有页面翻译完成以后，还可以再统一做一次人工润色和微调，进一步提高最终译文质量。
这轮实验真正留下的价值，是让我更明确了以后可能的简化方向：
原始页面优先，减少不必要的 Token，只保护真正高风险的机器结构，再用严格 validator 和针对性重试反馈守住安全边界。
至于是否值得最终切换到这种架构，不需要现在急着决定。
先把真正的翻译项目继续做下去。
等第一阶段简体中文接近完成以后，再结合真实失败率、Token 消耗、程序复杂度和最终人工润色效果重新评估，可能会比现在继续追求一个理论上的最优方案更有价值。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复