在 Go Learning & Documentation v2 的翻译流程里，我一直非常重视一件事：
模型不能随便修改代码、URL、identifier、链接绑定和其他机器语义内容。
所以正式 TranslationUnit 在交给 Generation 之前，并不是把原始 Markdown 或 HTML 直接交给模型。
中间还有一层：
protected representation。
它会把不应该被语言模型修改的内容替换成受保护 token，只留下真正允许翻译或修订的自然语言部分。
这套机制解决了一个非常重要的问题。
例如原文里存在：
http.Client或者：
https://go.dev/doc/又或者 Markdown link、HTML attribute、Go identifier。
模型不应该因为觉得中文读起来更自然，就把这些内容一起改掉。
因此最安全的做法就是：
根本不给模型编辑它们的能力。
但后来我遇到了一种刚好相反的问题。
有一次独立 Reviewer 已经明确指出某个 Page 存在需要修订的语言问题。
Generation Bundle 也正常建立。
可真正准备执行 exact revision 时，却发现：
要改的那段普通自然语言，被当前 representation 当成 opaque protected content 保护起来了。
其中一个很直观的例子，就是类似：
Documentation这样的普通可见 label。
Reviewer 可以看见它。
人也很容易判断：
这是页面上的自然语言。
但 Generation 拿到的 protected baseline 里，它已经变成了不可编辑 token。
这时候问题就变得很有意思：
译文知道应该怎么改。
Reviewer 也已经正式授权修改。
但机器表示根本不允许 Generation 碰它。
最后甚至可能出现：
正式 revision batch
→ Generation 无法合法表达 finding
→ 0 output
→ FAILED这不是模型不会翻译。
也不是 Reviewer finding 错了。
而是：
当前 representation contract 没有能力表达这次本来合法的语言修改。
这篇就专门整理这个问题。
为什么翻译流程里需要 protected representation
先从最基本的问题开始。
为什么不直接把整个 Page 原文交给模型？
因为一个文档页面通常不只有自然语言。
里面还可能包含：
- Go identifier；
- API 名；
- URL；
- Markdown link destination；
- HTML tag；
- attribute；
- code block；
- directive；
- placeholder；
- template syntax；
- technical literal。
这些内容中，有些绝对不能翻译。
例如：
json.Marshal不能被改成中文。
URL：
https://go.dev/doc/也不能被模型随便重新拼写。
Markdown 链接：
[Documentation](/doc/)通常需要区分：
Documentation是可见语言。
而：
/doc/是机器绑定。
所以正式 protector 做的事情，本质上是：
把“语言”和“机器语义”拆开。
一个理想的 protected input 应该是什么样
例如原文：
Read the Documentation for more details.其中如果 Documentation 只是普通可见文本，理想情况下 Generation 应该可以看到并修改它。
而如果页面里有：
http.Clientprotector 可能将其变成类似：
Read the Documentation for more details about ⟦P17⟧.模型可以编辑：
普通英文 prose。
但是不能编辑：
⟦P17⟧restore 时：
⟦P17⟧重新恢复成：
http.Client这样既能允许自然语言翻译，又能保证技术 identity 不被破坏。
问题出现在“自然语言被错分成技术内容”
真正麻烦的情况是：
protector classification 错了。
例如页面某个 heading navigation label，本来是用户真实可见的普通文字。
但是 source tokenizer 在判断时，因为附近存在一个可能被识别成 symbol lead 的词，后续普通 label 被错误归入 opaque atom。
于是原本应该是：
可编辑自然语言：Documentation最终却变成：
不可编辑 protected atom：⟦P42⟧这时候 TranslationUnit 从机器角度看仍然完全合法。
token 也没有损坏。
restore 也可能完全成功。
但它隐藏了一个能力问题：
模型已经失去了修改这段自然语言的能力。
“保护得更多”并不一定更安全
最开始很容易产生一个直觉：
宁可多保护一点，也不要让模型误改技术内容。
对很多系统来说，这确实是一个合理的保守策略。
但正式翻译流程里还有另一面。
如果把普通自然语言错误保护起来，就会导致：
合法语言修订无法发生。
所以 protector 的正确目标不是：
尽可能多地保护内容。
而应该是：
精确保护真正不允许语言模型修改的内容。
少保护会有风险。
多保护同样会有风险。
Reviewer 为什么仍然能够发现问题
这里会出现一个有趣的分层差异。
Generation 接收到的是：
protected input。
而 Reviewer 审核的是：
restored candidate。
也就是最终读者实际会看到的完整目标语言内容。
所以 Reviewer 完全可能看到：
某个 label 翻译得不自然。
然后正常给出 B finding。
例如 Reviewer 的判断可能类似：
当前 visible navigation label 应采用更自然的中文表达。
这个 finding 本身没有任何问题。
因为从最终页面语义来看，它确实应该修。
真正的问题直到 revision export 或 Generation 阶段才暴露：
Reviewer 授权修改的那段文字，在 Generation representation 中根本不可编辑。
这不是普通的翻译 revision failure
如果只是 Generation 把一句话改错了，处理方式很简单：
Reviewer 判 B
→ exact revision
→ validation
→ successor re-QC但 representation capability failure 不一样。
因为 Generation 就算完全理解 Reviewer 的意思，也没有办法合法输出正确结果。
假设 protected baseline 是：
更多信息请参阅 ⟦P42⟧。而 ⟦P42⟧ 实际对应：
Documentation如果 Reviewer 要求调整这个 label，Generation 有三个选择。
第一个选择：
修改
⟦P42⟧token。
不允许。
第二个选择：
删除 token，然后手写中文。
仍然不允许。
第三个选择：
保持 token 不动。
那么 Reviewer finding 无法关闭。
所以：
不存在一个合法 ordinary revision output。
这也是为什么“让模型直接改 token”绝对不是解决办法
最危险的修法可能是：
既然模型知道
⟦P42⟧是 Documentation，那就允许它改吧。
这样等于彻底破坏 protected representation 的意义。
因为下一次同样的能力可能被用于修改：
- Go identifier；
- URL；
- code literal；
- link destination；
- template syntax。
token 本来就是机器边界。
Generation 不应该拥有：
自行判断哪个 token 可以破解。
这种权力。
否则 protector 就从：
machine-enforced safety boundary
退化成：
模型最好自觉一点。
这显然不够可靠。
也不能直接把 candidate 重新 Protect 一遍
另一个看起来很方便的办法是：
既然旧 protected baseline 不好用，那拿 Reviewer 审核过的 candidate，再用今天的 protector 重新保护一次不就好了？
这个方法也有很大问题。
因为 candidate 是：
target language。
而正式 token mapping 应该由：
canonical source-owned representation
决定。
如果从译文反向 Protect，很可能需要机器猜：
target 里的某个词到底对应 source 哪一个 atom？
当一个 technical literal 在 target 中出现多次时，这种 ambiguity 会更加明显。
所以正式规则一直强调：
不能从 target 猜 token mapping。
representation mapping 必须由 source authority 和历史正式表示确定。
“今天的 protector 更正确”也不能改写昨天的历史
假设后来修好了 tokenizer。
现在它能够正确判断：
Documentation属于：
普通可见自然语言。
新的 protected input 也变得合理了。
但这并不意味着可以回头修改旧 batch。
因为旧 batch 的：
- manifest；
- input SHA；
- Unit ID；
- raw response；
- candidate；
- validation；
- QC evidence；
已经形成历史。
如果把旧 input 原地换成新 representation，就会出现：
同一个 batch identity 在不同时间对应不同正式输入。
这会直接破坏 provenance。
所以旧失败必须保持原样。
0 output failure 也应该成为历史，而不是被“修掉”
这一点我觉得特别重要。
当时存在过一种正式失败状态：
Generation batch 已建立
→ representation 无法表达 finding
→ 0 output
→ no import
→ no process最容易产生的冲动是：
既然现在已经知道工程原因，那就重新导出这个 batch，把旧失败抹掉。
但这不应该做。
正确方式应该是：
旧失败 batch
→ immutable preserved
新的 representation authority
→ successor
新的 revision batch
→ 继续处理同一个 finding因为旧失败本身也是有价值的 evidence。
它真实记录了：
当时的正式 representation 没有能力完成这个任务。
修复 protector 和修复 TranslationUnit 不是同一件事
这个案例还有一个很容易混淆的地方。
工程上修好 tokenizer，例如：
heading navigation label 不再被错误识别为 opaque atom。
只能证明：
今后的 current representation 可以正确生成。
但已经存在的 TranslationUnit identity 可能依赖旧 protected input。
如果新的 protector 输出发生变化，那么：
old protected input
≠
current protected inputUnit identity 也可能随之变化。
所以不能简单说：
parser 修了，现在重新跑就行。
还需要解决：
old Unit 与 current Unit 之间是什么关系？
这就是 representation successor authority 存在的原因。
physical source 没变，formal Unit 仍然可能变
这一点和 books.yaml 那篇其实又有一点呼应。
普通直觉会认为：
Page source 一个字都没改，所以还是同一个 TranslationUnit。
但正式 Unit identity 不一定只取决于：
physical source bytes。
它还可能取决于：
protected representation。
所以可能出现：
physical Page source：完全没变
current parser：修正了 classification
protected input：发生变化
formal Unit ID：发生变化这不是 source content replacement。
而是：
representation replacement。
source replacement 和 representation replacement 必须分开
这两个词看起来很像，但问题完全不同。
Source replacement
canonical source 本身改变。
例如：
/translation/正文被重新组织。
这时候需要处理：
新 source authority。
Representation replacement
canonical source bytes 没有变化。
但 parser / protector 对同一 source 的正式表示发生变化。
例如：
原来把普通 visible label 当成 opaque atom，现在正确分类成自然语言。
这时候需要处理的是：
old representation → current representation。
不能把两种情况混成：
“文件变了”。
因为第一种真的改了 source。
第二种没有。
representation successor 的任务不是生成新译文
这一点同样非常关键。
建立 representation successor authority 的时候，系统做的不是：
帮 Generation 翻译。
而是证明：
旧 formal Unit 和当前 formal Unit 是同一个 physical Page 在两种正式 representation 下的合法 predecessor / successor。
它需要验证很多机器事实，例如：
- 同一个 package；
- 同一个 physical path；
- 同一份 source bytes；
- 同一个 route；
- 同一个 registry index；
- 同一 dependency identity；
- old representation 真实存在；
- current representation 可以由当前 parser 重建。
只有这些关系都成立，才能继续说：
这是 representation successor。
为什么不能只按 path 找“最新 candidate”
一个更危险的捷径是：
path 都是
/doc/，那就直接拿这个路径最新 candidate 用吧。
这会失去正式 lineage。
因为一个 physical path 可能经历：
- old Unit ID；
- representation successor；
- source successor；
- revision；
- 多个 Snapshot。
“latest”只能说明：
时间上比较新。
不能证明：
它是当前 finding 合法 predecessor。
所以正式流程必须绑定：
old Unit → current Unit 的明确 replacement relation。
而不能：
path-based latest candidate。
successor baseline 也不能从目标译文猜出来
representation reconciliation 的另一个关键任务，是为 Generation 建立：
current protected baseline。
理想情况是：
old passed raw response
+
source-owned deterministic mapping
→
current protected baseline然后这个新 baseline 必须 restore 为：
逐字节相同的 reviewed predecessor candidate。
如果 restore 后有任何差异，就说明：
bridge 不能证明自己是纯 representation transition。
这时候必须失败。
因为 successor 的目标是：
改变“怎么表示”。
不是：
偷偷改变“已经审核过的译文”。
为什么 baseline 必须恢复成完全相同的旧 candidate
假设旧 candidate 已经被 Reviewer 审过。
现在只是 representation 发生变化。
在 Generation 真正执行新的 revision 之前，新 baseline 应该仍然代表：
同一份旧译文。
所以必须满足：
restore(new protected baseline)
==
old reviewed candidate bytes只有这样才能说明：
新 baseline 只是把同一个 target 换成了新的可编辑表示。
如果 bytes 不同，那已经引入语言变化。
这种变化不能由工程 bridge 自动产生。
representation successor 也不会继承旧 A 或 B 为新结论
即使 old candidate 在历史上是 A，也不能因为 bridge 成功就说：
current successor Unit 自动 A。
同样，如果当前处理的是旧 QC B finding，successor 也不能自动把 B 带过来作为新语言结论。
representation authority 只证明：
predecessor 和 successor 的机器 lineage。
它不做：
新语言质量判断。
因此新的 candidate 在完成 revision 后仍然需要：
validation
→ new Snapshot
→ independent re-QC最终是否 A，仍然由独立 Reviewer 决定。
这次真正合法的链条是什么
对于这种“正式 B finding 存在，但旧 representation 无法表达 revision”的情况，正确链条更接近：
旧 QC B
→ ordinary revision capability failure
→ 保留旧失败 evidence
→ representation successor authority
→ current successor Unit
→ 使用同一个原 B finding 创建新的 exact revision
→ Generation
→ validation
→ successor Snapshot
→ independent re-QC
→ A-only finalization这里有两个重点。
第一：
原 finding 没有被改写。
第二：
中间增加的是 representation bridge，不是新的语言判断。
为什么必须继续使用原来的 finding
假设 Reviewer 原来已经正式判定：
某个 visible label 翻译需要修改。
后来工程发现：
protector 把它错误保护了。
不能因此新造一个语言 finding：
“因为 protector 有 bug，所以请翻译 Documentation。”
因为 protector bug 是：
engineering necessity。
不是：
新的 Reviewer language judgment。
所以 representation successor 建立以后，新的 revision 仍然应该消费：
原来那一个 B finding。
这样因果链才能保持完整。
engineering proof 也不能冒充 Reviewer finding
反过来也一样。
工程可以证明：
protected-natural-language-unrepresentable。
意思是：
当前正式 representation 无法表达已经授权的自然语言修订。
这个 proof 能授权：
建立 representation successor。
但不能授权：
语言应该改成什么。
它更不能替 Reviewer决定：
这是 B、C 还是 D。
所以必须严格区分：
engineering proof
和：
language finding。
一个证明：
工具能力不够。
另一个证明：
语言质量存在问题。
为什么这里仍然坚持 fail-closed
其实也可以设计一个更“智能”的系统。
例如机器发现：
token 里其实只是 Documentation。
然后自动判断：
这看起来不像 code，临时开放一下编辑能力。
这样用户体验可能会顺畅很多。
但问题是：
机器凭什么确定它不是某个必须保持 exact 的 identity？
又凭什么确定：
当前这一处可以开放，而同类 token 不能？
只要这个判断没有正式 source-owned proof，最安全的结果仍然是：
停止。
也就是：
representation 无法合法表达 revision，就 fail closed。
这虽然会增加一次工程处理。
但至少不会为了完成翻译而破坏机器安全边界。
保护机制真正需要的是分类正确，而不是绝对保守
这个案例让我重新理解了 protector。
它不是一个：
越严格越好的过滤器。
而更像是一个：
语言权限分配器。
它决定了：
模型可以编辑哪些 bytes。
所以 classification 错误有两个方向。
第一种：
把技术内容误判成自然语言。
风险是：
模型修改机器 identity。
第二种：
把自然语言误判成技术内容。
风险是：
合法语言修订永远无法完成。
两种都是 correctness bug。
protected token 本质上是一种 capability
如果从 capability 的角度理解，整个问题会更清楚。
Generation 能看到普通 prose，意味着：
它拥有修改这些 prose 的 capability。
Generation 只能看到 token：
⟦P42⟧意味着：
它没有修改 token 内部 bytes 的 capability。
所以当 Reviewer finding 指向 token 内部自然语言时，真正发生的是：
语言 authority 已经授权修改，但 transport capability 没有授权修改。
两层 authority 不一致。
这就是 ordinary revision 无法继续的根本原因。
所以 Bundle 完整也不代表任务一定“可执行”
以前我更容易把 Generation Bundle 理解成：
只要 bundle current、identity 正确、所有文件齐全，模型就可以开始工作。
这个案例让我意识到还要多问一个问题：
Bundle representation 是否真的拥有关闭 finding 所需的编辑能力？
Bundle 可以：
- SHA 正确；
- inventory 正确；
- current-check PASS；
- predecessor 正确；
- finding 正确；
但如果 required prose 被保护成 opaque token：
任务仍然无法执行。
这不是 Bundle transport corruption。
而是：
formal editing capability mismatch。
restricted transport 和 formal representation replacement 也不能混为一谈
项目里有些特殊修订会使用受限 transport。
例如：
只允许修改某些 teaching comment body。
这种 transport projection 可以暂时限制 Generation 的编辑区域。
但它只是：
internal revision transport。
它不一定等于：
formal Page representation。
所以不能因为某个 restricted decoder 曾经成功 restore candidate，就反过来声称：
它可以充当普通 QC revision 的正式 baseline。
如果 formal source/input/Unit identity 没有发生对应 replacement，就必须另行证明 transport bridge。
不能拼接几个 token，伪造一个新 representation。
same-unit bridge 解决的是另一类问题
还有一种情况是：
formal Unit ID 没变，source/input 也没变。
但是之前某个 restricted transport 产生的 raw response，普通 QC revision decoder 无法继续使用。
这种问题不是：
formal representation replacement。
因为 formal Unit 根本没有变化。
它更像：
同一个 Unit 内，不同 editing transport 之间的 capability bridge。
因此需要的是：
same-unit transport reconciliation。
而不是伪造：
old Unit → new Unit replacement。
这两个场景看起来都叫“旧 baseline 不能用”，但 authority 完全不同。
为什么要把这些 representation 问题分这么细
因为如果全部归为：
protector 有问题。
处理方式很容易变成：
修 protector
→ 重跑但这里其实至少有三种不同情况。
第一种：
current parser classification 错误，并造成正式 Unit representation drift。
需要：
representation successor。
第二种：
formal Unit 不变，但旧 restricted transport 无法执行 ordinary QC revision。
需要：
same-unit bridge。
第三种：
historical target 中某些 protected literal 的 source/target binding 本身无法唯一证明。
可能需要：
machine authority 或独立 semantic reconciliation。
它们不能互相借 authority。
为什么 machine 不能靠 occurrence 顺序猜 mapping
还有一种很典型的 ambiguity。
假设 source 中某个 technical literal 出现一次。
旧 target 中却出现两次。
如果旧 representation 没有保存足够的 binding evidence，机器可能无法确定：
source 的这一处到底对应 target 中第一次还是第二次出现。
最简单的算法当然是：
选第一个。
或者：
选离上下文最近的那个。
但这些都是 heuristic。
正式 workflow 不能因为：
两种选择最终看起来都能 restore。
就假设 binding 等价。
因为不同 binding 可能影响：
后续允许编辑的位置。
所以无法唯一证明时：
unknown。
而不是：
猜一个。
representation bug 和语言 bug 应该分开修
这一点对于恢复成本特别重要。
如果 Reviewer 已经给 B，后来发现 protector classification 错了。
不能把整个事件简单描述成：
翻译失败。
更准确的拆分是：
语言层：
Reviewer finding 有效
工程层：
current representation 无法执行该 finding所以先修：
representation capability。
然后继续消费：
原语言 finding。
这样不会重新要求 Reviewer：
再判一次同样的问题。
也不会要求 Generation：
在不合法的 baseline 上硬做。
这和上一篇 source replacement 又形成了一个很好的对照
上一篇 /translation/ 的情况是：
source 本身真的要变。
所以需要：
source replacement successor。
这一篇的情况则是：
source bytes 没有变。
变化的是：
我们今天如何正确识别和保护这份 source。
所以需要的是：
representation successor。
这两种 successor 都坚持同一个原则：
predecessor 保留。
但是保护的历史对象不同。
前者保护：
old canonical source。
后者保护：
old formal representation。
为什么历史 representation 也值得保留
可能会有人觉得：
旧 protector 明明有 bug，为什么还要保留那个错误 representation？
因为它解释了：
当时的正式 artifacts 是怎么产生的。
如果旧 Generation、raw response、candidate、QC 都绑定旧 token mapping，那么删除旧 representation 后，将来就无法重建：
那份 candidate 当时为什么合法。
所以：
错误的工程判断可以被后继修正，但历史事实不能被抹掉。
这和旧 source immutable 是同一个思想。
新 representation 不应该要求旧历史重新通过今天的 protector
这也是很重要的一点。
如果当前 protector 已经修正，那么历史 representation 很可能：
按今天的规则已经不会再生成。
但不能因此说：
历史 artifact 无效。
历史验证应该问的是：
当时保存的 old representation 是否与当时的 raw/candidate/evidence 自洽？
当前验证则问：
今天 current source 应该生成什么 representation？
这两个问题必须分开。
否则每次 parser 演进，都可能导致：
所有历史 evidence 全部失效。
那就无法真正维护长期 provenance。
successor 的价值就在于连接这两个时代
representation successor 本质上是在说：
我知道历史 formal Unit 是什么。
我也知道 current formal Unit 是什么。
我能用确定性的 source-owned evidence 证明，它们对应同一个 physical Page 和同一份 canonical source。
因此：
historical representation
→ explicit reconciliation
→ current representation而不是：
历史已经过时
→ 丢掉
→ 只认最新这就是 successor lineage 的意义。
修正 classification 时，也不能顺便扩大可编辑范围
假设这次真正的问题只在：
heading navigation label
Documentation被错误保护。
修复 parser 时，应该尽量做到：
只把这一类真实可见自然语言重新分类为 editable prose。
不能顺便把：
- URL；
- tag；
href；id；- code/API；
- link binding；
全部开放给模型。
也就是说：
修复 under-classification 和 over-protection 时，都应该保持最小边界。
这类问题为什么很适合机器 proof，而不是人工拍脑袋
representation 是否发生变化，本质上有很多可以机械证明的事实。
例如：
- source bytes 是否相同；
- physical path 是否相同；
- old/current input SHA 是否不同；
- Unit ID 是否发生变化；
- route 是否相同；
- package 是否相同；
- dependency identity 是否相同；
- rebase 后是否恢复成同一 reviewed candidate。
这些都应该交给机器。
Reviewer 不应该被要求判断：
两个 Unit ID 是不是“差不多就是同一个页面”。
Reviewer 应该继续专注于：
语言质量。
Reviewer 也不应该负责修 representation
同样，Reviewer 发现：
Documentation应该修。
就已经完成了语言职责。
不能要求 Reviewer：
顺便决定这个 token 应该怎么重新绑定。
那属于：
repository engineering / representation authority。
否则 Reviewer 会同时承担：
- language judgment；
- tokenizer semantics；
- token mapping；
- historical lineage。
角色会迅速失控。
Generation 更不应该自己创造 mapping
Generation 在这里的职责同样很简单。
如果 Bundle 给出的 baseline 合法可编辑：
按 finding 修改。
如果 required content 被保护、mapping 不可表达：
停止。
它不应该：
自己猜
⟦P42⟧是什么，再构造一份新的 token mapping。
因为那会让 language model 反过来定义：
machine authority。
这是最应该避免的事情之一。
“0 output”有时候反而是最正确的结果
从生产效率看：
0 output很让人挫败。
因为模型调用已经发生，却什么正式 candidate 都没得到。
但从 fail-closed 的角度，它可能反而说明：
safety boundary 正常工作了。
如果唯一能完成任务的方式是：
修改不允许修改的 protected token，
那么拒绝输出就是正确行为。
真正应该修的不是：
让模型更大胆一点。
而是：
修正正式 representation contract。
这类失败最大的价值是暴露“流程能力缺口”
普通语言 B 说明：
candidate 有质量问题。
representation capability failure 说明的是另一件事：
当前 workflow 没有能力执行已经合法授权的修订。
后者其实更接近：
infrastructure bug。
所以处理方式也应该完全不同。
不能通过：
多试几次 Generation。
来解决。
因为无论换多少次模型，只要 protected baseline 不变：
capability 仍然不存在。
重试不能解决 representation 不可表达
这也是 retry 和 revision 必须分开的原因。
如果失败是：
- token 丢失；
- restore malformed；
- Generation 偶然输出格式不对；
可以考虑：
retry。
但如果失败原因是：
Reviewer 要改的自然语言根本处于 opaque protected token 内，
那么 retry 一百次结果也一样。
因为问题不是：
模型这次没做好。
而是：
任务在当前 representation 中没有合法解。
所以失败诊断一定要先确定“问题在哪一层”
遇到 revision failure 时，至少应该区分：
Generation 输出错误。
validator 规则错误。
representation capability 不足。
historical binding 无法证明。
transport bridge 不兼容。
如果全部统一处理成：
retry。
不仅浪费额度，还可能产生越来越多没有意义的失败 artifacts。
representation successor 最终仍然不是 PASS
即使工程已经建立：
old Unit → current Unit 的合法 successor。
也只能说明：
现在终于具备执行原 finding 的能力了。
下一步仍然是：
new revision Generation
→ restore
→ validation
→ Snapshot
→ independent re-QCrepresentation reconciliation 本身不产生：
A。
这一点和 source replacement authority 非常相似。
它解决的是：
输入和 lineage。
不是：
语言质量。
我现在更认可的一条分层原则
走到这里，我越来越觉得正式翻译流程里至少应该明确区分三件事。
第一件：
语言有没有问题？
由 Reviewer 判断。
第二件：
Generation 有没有被授权修改这个范围？
由 finding 和 revision scope 决定。
第三件：
当前 representation 有没有能力表达这次修改？
由 machine contract 决定。
只有三者同时成立：
存在合法 finding
+
存在合法 revision authorization
+
存在可执行 editing representationGeneration 才真正有可能完成任务。
这次最值得保留的几条原则
经过这类 representation failure，我觉得可以把规则浓缩成下面几条。
第一：
protected representation 的目标不是保护越多越好，而是准确区分可编辑自然语言和不可修改机器语义。
第二：
把技术内容误放给模型是 bug；把普通自然语言错误保护起来，同样是 bug。
第三：
Reviewer 可以合法发现一个 Generation 当前没有能力修改的问题。语言 judgment 与 editing capability 是两层不同 authority。
第四：
如果正式 finding 指向 opaque protected content，不能让 Generation 修改 token、删除 token或自行重建 token mapping。
第五：
不能从 restored target 重新 Protect 来猜 current formal mapping；representation 必须由 canonical source authority 决定。
第六：
修正 parser / protector 以后，如果 protected input 或 Unit identity 真实变化，就必须建立 explicit representation successor，而不是改写旧 batch。
第七：
旧 zero-output failure、raw、candidate、QC 和其他历史 evidence 都应保持 immutable；后继能力通过 successor lineage 前进。
第八：
representation successor 只证明 old/current formal Unit 的机器关系，不生成新译文，也不继承新的语言 A。
第九：
新的 revision 仍然消费原 Reviewer finding，然后经过 validation 和 independent re-QC。
第十：
同一个 physical source 不代表永远是同一个 formal TranslationUnit；representation contract 的真实变化同样可能产生新的 Unit identity。
最终我觉得这次最值得记住的一句话是：
保护机制的价值，不在于让模型“什么都不能碰”，而在于让模型只碰它真正应该碰的东西。
保护不足，会让模型破坏机器语义。
保护过度，又会让合法语言修订无法发生。
而当这种边界真的发生变化时，正确处理方式也不是偷偷修历史。
而是明确承认：
旧 representation 曾经存在。
它今天已经不足以表达新的合法任务。
然后通过一个正式 successor，把工作流安全地带到新的表示上。
这才是真正能够长期演进的 protected translation workflow。
Go 学习与文档多语言本地化项目
本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步，逐步扩展到站点首页、项目说明页、学习内容、文档以及未来内容包的实际开发过程，包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、生产发布与长期维护。
项目源码：
✅ GitHub：shuijingwan/go-tour-i18n
语言版本：
当前跨项目目标语言池共包含 66 个语言版本。Go 项目本身目前提供 65 个社区 Production 语言版本，下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。
英语（美国）仅作为跨项目目标语言纳入列表，并不是单独的 Go Production 语言版本。当前 Go 的英文源内容仍为官方 generic English，因此英语（美国）链接到 Go 官方站点，而不是不存在的本地社区部署。
- 阿姆哈拉语
- 阿拉伯语
- 孟加拉语
- 葡萄牙语（巴西）
- 保加利亚语
- 加泰罗尼亚语
- 克罗地亚语
- 捷克语
- 丹麦语
- 荷兰语
- 英语（美国）（Go 官方英文站点）
- 英语（澳大利亚）
- 英语（加拿大）
- 英语（印度）
- 英语（新加坡）
- 英语（南非）
- 英语（英国）
- 爱沙尼亚语
- 菲律宾语
- 芬兰语
- 法语（法国）
- 法语（加拿大）
- 德语（德国）
- 德语（奥地利）
- 德语（瑞士）
- 希腊语
- 古吉拉特语
- 希伯来语
- 印地语
- 匈牙利语
- 印度尼西亚语
- 意大利语
- 日语
- 卡纳达语
- 哈萨克语
- 韩语
- 西班牙语（拉丁美洲）
- 拉脱维亚语
- 立陶宛语
- 马来语
- 马拉雅拉姆语
- 马拉地语
- 书面挪威语（Bokmål）
- 波斯语
- 波兰语
- 葡萄牙语（葡萄牙）
- 旁遮普语（果鲁穆奇文，印度）
- 罗马尼亚语
- 俄语
- 塞尔维亚语（西里尔文）
- 简体中文（中国大陆）
- 简体中文（新加坡）
- 斯洛伐克语
- 斯洛文尼亚语
- 西班牙语（西班牙）
- 斯瓦希里语（坦桑尼亚）
- 瑞典语
- 泰米尔语
- 泰卢固语
- 泰语
- 繁体中文（台湾）
- 繁体中文（香港）
- 土耳其语
- 乌克兰语
- 乌尔都语
- 越南语
项目正在持续扩展新的 Go 学习与文档内容，并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。
本项目属于非官方社区多语言本地化项目，与 Go 官方无隶属、授权或背书关系。