别信“已经完成”：用测试和独立审查验收 Codex

“修改完成，检查通过。”

这句话最多说明执行者愿意结束当前阶段。它没有说明运行了什么检查，检查覆盖哪些文件，结果是否完整，也没有回答计划里的完成条件是否逐项满足。一次命令返回 0，甚至所有测试变绿，都可能与用户真正要交付的结果隔着一段距离。

小编现阶段的理解是：验收要从预先定义的完成条件出发，为每个结论寻找对应证据；模型的完成声明只能作为待核线索。 有一项关键条件缺少证据或检查失败，结论就应停在“未通过”，不能靠措辞放行。

上一篇留下了改动范围、实施记录和局部检查。本文继续组装验收矩阵和证据包，判断当前交付能否通过。任务中断后怎样重建现场，属于第 5 章。

一、先拆开几种经常混用的“通过”

工程现场里，“检查通过”可能指完全不同的事情。

• 静态检查读取代码或文件结构，发现格式、类型、语法、规则和已知模式问题；
• 测试执行预先定义的输入与断言，验证被覆盖行为是否符合预期；
• 构建证明当前配置下可以完成编译、打包或产物生成；
• 人工核验处理自动化难以判断的语义、交互、视觉、内容边界和业务取舍；
• 独立审查由实现责任之外的角色重新读取目标、差异与证据，判断范围、逻辑和风险是否可接受。

它们可以互相补充，不能互相冒充。构建成功不代表业务行为正确；测试通过不代表测试覆盖了需求；静态检查没有报错，也不能证明改动范围完整。人工核验能发现语义问题，却不适合代替可重复的类型检查。实现者自审则是交付前的必要清理，仍不具备独立审查的责任隔离。

并非每项任务都要机械跑齐五类验证。纯 Markdown 写作没有可执行程序，测试和构建可以标成“不适用”，同时写明原因。代码改动若有现成测试和构建入口，却在证据包里悄悄消失，才是未覆盖风险。

二、从完成条件反推验证矩阵

验证矩阵不从“仓库里有哪些命令”开始，而从“这项任务承诺了什么”开始。每个完成条件至少对应一项检查，并写清检查失败会阻断哪个结论。

以当前系列的单篇文章为例，计划要求正文回答指定核心问题、兑现内容要点和实践产物、保持系列边界、事实可信、Markdown 可用，并经过独立质检。可以据此得到下面这张矩阵。

完成条件	验证方式	检查对象与范围	通过证据	未覆盖项 / 阻断规则
目标文件和状态正确	静态检查	指定正文 Frontmatter、topic.md 对应条目、实际路径	编号、路径、正文状态和计划状态可对应	只能证明结构与状态；任一不一致即不交审
Markdown 结构可用	静态检查	目标正文标题、代码围栏、行尾空白	标题层级可解析、围栏成对、无目标格式错误	不证明内容和技术事实正确
规划承诺得到兑现	人工核验	核心问题、主要观点、内容要点、实践产物	逐项指出正文位置和缺口	关键内容缺失即要求修订
技术事实有依据	人工核验 + 来源复查	易变产品行为、配置、API 和引用	一手来源与正文表述一致	来源缺失或冲突时不得当作确定事实
修改范围工程上可接受	差异检查 + 人工核验	实际变更、未提交文件、授权边界	预期文件完整，未发现意外改动	发现范围外改动先解释或移除
文章可以进入下一状态	独立审查	正文、规划、风格规范和前述证据	审阅报告的结果、计数和问题清单一致	blocking 或 important 未解决时不能放行
可执行代码行为正确	测试 / 构建	本次变更涉及的代码和产物	记录实际命令、范围与结果	当前纯文章任务不适用；代码任务不得据此豁免

矩阵里的“通过证据”不能预写成“测试通过”。执行前只能填验证方法、范围和判断规则；运行后再记录实际命令、输出摘要、失败位置与未覆盖项。仓库没有某类检查时，也要留下 N/A 或“未执行”的真实原因。

完成条件与证据不是一对一关系。一个关键行为可能需要单元测试、集成测试和人工操作共同支持；一条静态检查也可能同时覆盖多项格式约束。最终要看证据能否支撑结论，不需要为了矩阵整齐强行凑数量。

三、证据包要让别人能重跑和反驳

只粘贴一屏绿色输出，接收者仍然不知道命令在哪个目录运行、覆盖了哪些对象，或者中间是否过滤掉错误。一个可复查的验证记录至少要说明：

一条 verification 只记录一个 method。矩阵中的“差异检查 + 人工核验”要拆成一条 diff 和一条 manual；“测试 / 构建”也应按实际执行情况分别记录，不能把组合名称写进枚举字段。这样每条结果都有独立范围、输出和未覆盖项。

命令、范围和结果要一起记录。npm test 失败与“没有运行测试”是两种状态；只运行某个测试文件，也不能写成“全量测试通过”。人工核验同样要说明检查了哪个页面、文章段落或业务路径，不能只写“看起来没问题”。

差异检查承担范围完整性。验收者需要看到本次预期修改是否都出现、是否遗漏配套文件、是否夹带范围外变化，以及工作区里有哪些内容无法归属于当前任务。当前 JVS 系列目录在仓库中仍表现为未跟踪目录，普通已跟踪差异无法单独还原每篇文章的修改历史；因此本文不把“差异干净”写成事实，而改用目标路径、文件成对关系和当前内容检查作为有限证据。这项限制应进入未覆盖项。

输出太长时可以保留摘要和报告路径，但失败信息不能被摘要掉。命令失败、测试跳过、构建警告或无法核验的事实，都可能改变最终结论。证据包首先服务判断，其次才是阅读体验。

四、用现有文章和审阅报告核对一次

当前系列已经留下两类真实审查记录。

03-02 的审阅报告保存了一个完整的失败—修订—复审过程。首次审阅发现正文把 config_file 错写成 custom agent 被识别的必要配置层，结论是“修改后通过”。报告没有因为文章结构完整、Markdown 正常就放行；正文完成最小修订后，复审重新核对官方机制，才把问题标成 RESOLVED IMPORTANT-01，最终计数归零并进入 reviewed。

04-01 则在首次独立审阅中通过。它的报告不仅给出 result: reviewed，还重新核对目标正文存在、正文与 topic.md 当时均为 drafted、前置 03-03 为 reviewed、代码围栏闭合且没有行尾空白。报告同时强调，这些局部证据只支持结构和状态结论；审阅者另行检查文章规划、边界、案例真实性和实践产物后，才形成内容结论。

本轮为写作 04-02 执行了一组只读检查，记录的是写后校验时的实际结果：

这组快照的价值在于暴露结构缺口：审阅报告找不到对应正文、报告标记 reviewed 却仍有未解决的重要问题、Markdown 围栏不闭合，都应阻止状态继续推进。它没有资格回答“文章整体是否通过”。

五、失败证据必须改变结论

验证最容易失效的地方，是检查已经报错，最终回复仍然写“整体完成”。有时失败被降格成“一个小问题”，有时未运行的检查被顺手省略，结果就变成了先决定放行，再挑选支持放行的输出。

验收结论应服从最高风险的未解决问题：

• 关键完成条件缺少证据，标记未完成或待验证；
• 静态检查、测试或构建失败，保留原始失败范围，不用其他绿色结果抵消；
• 人工核验发现行为、语义或范围错误，定位到最小修订对象；
• 独立审查存在未解决的 blocking 或 important，结论保持 revision_required；
• 修订完成后重新运行受影响检查，并由独立角色复审，不能只接受实现者的“已经修好”。

这条规则不要求所有警告都阻断交付。polish 类建议可以按项目标准决定是否处理，已知但不影响当前完成条件的风险也可以明确接受。关键是结论与证据一致：谁决定接受，接受的范围是什么，还剩什么没有覆盖，都应写出来。

最终交付可以很短，但至少要让接收者看到完成条件、验证范围、实际结果、未覆盖项和独立结论。模型说“完成”只是验收入口；静态检查、测试、构建和人工核验分别提供有限证据，独立审查再把这些证据与目标、差异和风险放在一起判断。任一关键失败没有解决，任务就还没有通过。