在 Go Learning & Documentation v2 的独立审核流程中，我遇到过一种反复出现的情况：Reviewer 首轮判定为 B，并列出了几个具体问题；Generation 按照这些 examples 完成修订，机器校验也通过，但 successor re-QC 仍然因为同一类别的残留再次判 B。问题并不一定是 Generation 没有修，而是工作流把“Reviewer 举出的例子”和“完整修订边界”混在了一起。本文介绍为什么 finding-anchored 不等于 example-anchored，以及 Reviewer 如何通过 defect category、exact predicate 和 bounded scope 做 same-class scan，Generation 又如何在不扩大修订范围、不进行无关润色的前提下完成 locally complete 的 same-class sweep。核心结论是：真正需要关闭的是审核发现的问题类别，而不是几个碰巧被列出来的实例。

Go Learning & Documentation v2 在处理结构化内容时发现，一个原始文件即使字节完全没有变化，也不代表旧翻译仍然完整有效。books.yaml 的实际案例中，旧 parser 只识别出 10 个可本地化语义单元，而当前 parser 识别出 12 个，并新增 PDF 和 GitHub。本文介绍 v2 如何区分 source 变化、普通 stale 和真正的 semantic input expansion，为什么旧 Generation 应保留为历史事实却不能继续冒充当前完整结果，以及为什么重新进入流程前必须证明旧单元全部精确保留、当前输入只是严格扩展。核心结论是：判断翻译能否复用，不能只比较源文件，还必须比较模型真正接收到的正式语义输入。

代码块中的注释并不都是不可翻译内容：教学性自然语言通常应该进入翻译，而机器指令、结构和技术语义必须保持不变。更难的问题是，怎样证明所有应该翻译的注释都已经被发现，而不是只检查已经进入流程的那一部分。本文介绍 Go Learning & Documentation v2 如何从规范源内容建立代码注释清单，区分教学注释、机器语义和不支持的未知内容，再与当前正式译文进行精确对应，检查 missing、extra、结构变化和受保护内容变化。核心目标是避免静默遗漏，让“翻译质量正确”和“翻译内容完整”同时成立。