夜航工作流有一项不可绕过的交付条件：selftest 未全部通过时，本轮任务不得交付。
这项约束使 AI 辅助编码进一步成为可在无人值守时运行的开发流程。我将这套夜间执行、次日验收的循环称为“夜航”。
夜航工作流的组成
夜航是一套自主开发循环。执行前，我会提供包含任务目标与优先级的任务书；AI 按照以下步骤持续处理，直至任务完成、出现需人工裁决的问题，或收到停止指令：
- 任务读取：读取任务书并认领一个具体任务；
- 开发实现：编写代码或调整系统；
- L1 测试门禁：运行数百条断言；未全部通过时自动退回并修正；
- L2 对抗评审：测试通过后，由另一个 AI 以证伪为目标检查改动；
- 集成与报告：将改动落地，并保证新增内容可以在试玩中直接验证；随后发送交付报告；
- 进入下一轮：继续处理任务书中的下一项工作。
测试门禁的核心作用
无人值守开发的主要风险，是新改动在未被发现的情况下破坏既有规则。
测试门禁承担持续监督作用。数百条断言固定游戏中的关键行为，例如破防窗口、篝火存档和升级公式。任意断言失败，本轮任务都会自动退回，无法进入交付阶段。测试门禁并不提高模型本身的判断能力，而是限制未经验证的结果进入主流程。
自动测试之外的对抗评审
仅有测试仍不足以保证现象正确，因为**“断言通过”不等于“问题已经消失”**。项目中曾出现过断言为绿色、实际问题依然存在的情况。进一步检查后发现，该断言只验证了“没有发生任何事件”，而这一状态本身也会返回通过。
因此，测试之上还设置了对抗评审。改动集成前，由另一个 AI 假设方案存在错误，并主动寻找能够推翻它的反例。低风险任务使用一名评审者，高风险任务使用两名评审者进行独立检查。只有在问题无法被复现或方案无法被合理推翻后，改动才进入下一阶段。
夜间任务的交付结果
次日的夜航报告会列出当夜完成的任务、测试数量、已集成内容，以及等待人工裁决的问题。我的工作集中在复核结果、决定未决事项，并据此编写下一份任务书。
结论
“能够自动运行”与“适合在无人值守条件下运行”是两个不同标准。后者不依赖抽象的信任，而依赖明确的任务边界、测试门禁和对抗评审。自动测试控制回归风险，对抗评审补充判断盲区；只有两者同时成立，夜间自主开发才具有稳定的使用条件。