Go 分类归档 - 永夜

命令明明失败了，为什么最后还是 PASS？一次 Shell 自动化的 fail-closed 教训

永夜 — Mon, 26 Oct 2026 03:48:46 +0000

一次 Generation Bundle 当前性检查中，我误用了不存在的 generation-bundle check 命令。脚本虽然检测到失败并打印了 RESULT=FAILED，却因为在顶层子 Shell 中错误使用 return，没有真正停止执行，最终又打印出了一个伪造的 RESULT=PASS。本文记录这次故障的发现、恢复和修正过程，并讨论为什么 FINAL 只是摘要而不是权威状态、为什么后续成功不能覆盖必要检查失败，以及正式工作流中的 Shell 控制流为什么同样必须遵循“无法确认时按失败处理”的原则。

命令明明失败了，为什么最后还是 PASS？一次 Shell 自动化的 fail-closed 教训最先出现在永夜。

一个候选快照为什么突然多出 122 个单元？从隐式范围到显式内容包契约

永夜 — Mon, 26 Oct 2026 03:09:06 +0000

在为 site-v2-shell 首页创建候选快照时，本应只有 1 个页面翻译单元，结果却意外生成了 122 个单元。问题并非数据损坏，而是命令没有显式绑定内容包，底层流程落入了 Tour 的默认范围。本文记录这次真实故障的发现与修复过程，以及为什么错误的正式产物不能直接删除、为什么内容包本身就是工作流的权威边界，以及正式命令为什么宁愿多写一个参数，也不应该依赖隐式范围猜测。

一个候选快照为什么突然多出 122 个单元？从隐式范围到显式内容包契约最先出现在永夜。

保护机制也会保护错东西：为什么一个 Documentation 能阻塞整页修订？

永夜 — Fri, 23 Oct 2026 10:52:50 +0000

在 Go Learning & Documentation v2 的翻译流程中，protected representation 用来防止 Generation 修改 Go identifier、URL、链接绑定和其他机器语义内容。但保护机制本身也可能出错：一次正式 QC 已经明确指出某个可见自然语言需要修订，可当前 protector 却把它错误分类成 opaque protected content，导致 Generation 即使完全理解 Reviewer finding，也没有合法方式修改它。本文介绍为什么“保护得更多”并不一定更安全，为什么不能让模型直接修改 protected token，也不能从目标译文重新 Protect 来猜 token mapping，以及为什么修正 parser 后仍不能改写旧 batch。文章进一步说明 representation successor 如何在保留历史 evidence 的同时，把同一个 physical Page 从旧 formal representation 安全衔接到新的可编辑表示。核心结论是：语言质量授权和编辑能力是两层不同的 authority；当 representation 无法表达一个合法修订时，应该修复表示能力，而不是放宽模型边界。

保护机制也会保护错东西：为什么一个 Documentation 能阻塞整页修订？最先出现在永夜。

页面明明是我自己的，为什么不能直接重写？从 /translation/ 改版看 immutable source 与 replacement successor

永夜 — Fri, 23 Oct 2026 09:03:30 +0000

在 Go Learning & Documentation v2 中，我准备重新整理项目自有的 /translation/ 页面时，发现一个看起来很反直觉的问题：页面明明是自己维护的，却不能像普通 HTML 一样直接重写。原因是旧正文已经被 corpus、Generation、Review、closure 和 Surface 等正式流程消费，过去的证据都绑定着当时的 exact source。本文介绍为什么 immutable 并不意味着内容永远不能更新，而是历史事实不能被原地覆盖；同时区分 append successor 与 consumed-source replacement successor，说明为什么追加新内容可以大量继承旧语言结果，而改写、删除、重排旧正文则必须建立新的 source authority。文章还讨论了为什么 renderer 不能绕过正式语言流程直接注入中文，以及为什么 source ownership 和 source lifecycle 是两回事。核心结论是：当一份内容已经进入正式多语言生命周期以后，修改它不再只是编辑文件，而是在执行一次内容版本迁移。

页面明明是我自己的，为什么不能直接重写？从 /translation/ 改版看 immutable source 与 replacement successor最先出现在永夜。

为什么修完 Reviewer 指出的所有例子，下一轮还是会失败？从 B→revision→B 看同类问题完整性

永夜 — Fri, 23 Oct 2026 03:42:07 +0000

在 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。核心结论是：真正需要关闭的是审核发现的问题类别，而不是几个碰巧被列出来的实例。

为什么修完 Reviewer 指出的所有例子，下一轮还是会失败？从 B→revision→B 看同类问题完整性最先出现在永夜。

更快不一定更好：为什么我主动撤销了一次已经明显变快的性能优化

永夜 — Wed, 21 Oct 2026 08:35:30 +0000

在 Go Learning & Documentation v2 的性能优化过程中，我曾把一条只读规划路径从约 164.03s 优化到 125.65s，后来又通过更激进的方案一度压到约 35.93s。但最终，更快的方案并没有被保留，因为对应的 correctness、freshness、stale detection 和 targeted tests 无法完整证明继续成立。本文整理这次性能优化过程，讨论为什么性能任务不能只看 benchmark，为什么 invocation-local reuse 通常比复杂 persistent cache、LRU 和多级 memoization 更适合这类强调 currentness 的工作流，以及什么时候应该停止继续优化。核心结论是：性能优化的目标不是把执行时间压到最低，而是在正确性、复杂度、验证成本和实际收益之间找到合理边界。

更快不一定更好：为什么我主动撤销了一次已经明显变快的性能优化最先出现在永夜。

Surface 已经 PASS，为什么 Preview 还是会失败？从一次 wrong renderer 看分层验证的价值

永夜 — Wed, 21 Oct 2026 07:22:45 +0000

Go Learning & Documentation v2 在 TranslationUnit、内容包封存和 Integrated Surface Review 全部通过以后，仍然需要执行独立的 Preview 验收。一次真实案例中，前面的语言内容和整合站点状态都已经通过，但 Preview 首页仍因 wrong renderer 直接失败。本文介绍 Surface 与 Preview 为什么不能互相替代，以及 Preview 如何验证从 activated authority 到 LoadContent、Compose、route resolver、renderer、HTTP、DOM 和浏览器行为的真实运行链。文章还讨论了为什么 HTTP 200 不能证明页面正确、runtime 工程错误为什么不应该重新打开可信翻译成果，以及修复后为什么必须重新启动 fresh Preview。核心结论是：内容正确，只能证明输入正确；Preview 还必须证明系统真正按照预期消费了这些输入。

Surface 已经 PASS，为什么 Preview 还是会失败？从一次 wrong renderer 看分层验证的价值最先出现在永夜。

审核都通过了，为什么上线前还要再检查一次？v2 的 Activation、prior SHA 与 CAS 设计

永夜 — Wed, 21 Oct 2026 04:12:00 +0000

Go Learning & Documentation v2 在内容生成、独立审核、内容包封存和整合站点审核全部通过以后，并不会直接修改当前激活状态。原因是从审核完成到真正写入之间，权威状态仍然可能被其他合法流程改变。本文介绍 v2 为什么将 Activation 拆成只读的 activation-preflight 和真正产生状态变更的 activation-apply，以及 prior_sha256、result_sha256 和 CAS 如何共同防止旧计划覆盖更新状态。文章还讨论了 prior mismatch、already_active=true、并发状态变化和 mutation=unknown 的处理原则。核心结论是：一次操作曾经合法，不代表它在真正提交时仍然安全。

审核都通过了，为什么上线前还要再检查一次？v2 的 Activation、prior SHA 与 CAS 设计最先出现在永夜。

原始文件一个字没变，为什么还要重新翻译？从 books.yaml 10→12 看语义输入扩展

永夜 — Wed, 21 Oct 2026 02:45:09 +0000

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

原始文件一个字没变，为什么还要重新翻译？从 books.yaml 10→12 看语义输入扩展最先出现在永夜。

代码块里的注释为什么不能只靠肉眼检查？v2 如何统计并验证代码注释翻译完整性

永夜 — Tue, 20 Oct 2026 09:23:28 +0000

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

代码块里的注释为什么不能只靠肉眼检查？v2 如何统计并验证代码注释翻译完整性最先出现在永夜。