审计编程代理完工声明：测试证据要可追溯

给 AI 编程助手加一套验证插件，真的比写几条项目规则更有效吗？receipts 作者跑了 1,260 次 Claude Code 会话，发现跨包修改任务的成功率从 43% 升到 78%，但只把规则放进 CLAUDE.md，也能达到 76%。

这篇最有价值的地方，是作者把插件的收益拆开验证：哪些来自提示词，哪些来自独立审计，哪些暂时没有证据。对日常用 AI 改代码的人，这比再装一个工具更值得弄明白。

「测试通过」为什么还得追问证据

作者先回放了自己 4.6 GB 的 Claude Code 历史，找到 233 条成功声明，再逐一对照执行记录人工检查。其中 11 条没有有效证据支持，约占二十分之一。

问题不只是模型完全没跑测试。它可能先跑出绿灯，再修改文件；只验证一个文件，却声称整个测试集通过；也可能用 pytest | tail -5 截取输出，把失败命令的退出状态藏起来。

还有更直接的错报：某轮唯一一次测试记录是 114 个通过，Claude 却报告了 131 个。另一次，在已经宣布「9/9 tests pass」之后，它又修改了 C# 文件。

验证结果有范围，也有时效。

一次检查只能支持它实际检查过的代码状态。测试之后又发生相关修改，之前的绿灯就不能直接拿来证明当前版本正确。作者认为，模型难以可靠审计自己的行为，但执行记录提供了核查依据。

receipts 因此做了三件事：会话开始时注入验证规则和项目真实的全量测试命令；修改共享模块后识别可能受影响的文件或项目；结束时把成功声明与执行记录对照，检查相关命令是否运行、是否晚于最后一次相关修改。

影响分析覆盖 JavaScript、TypeScript、Python 和 .NET。插件还支持验证证据台账、历史会话扫描、测试弱化检查，以及中断重复失败命令。它在本地运行，要求 Node.js 18 或更新版本，没有外部包依赖，也不发起网络请求。

成功率涨了，但主要是谁的功劳

作者没有只展示几次成功演示。他围绕 Haiku、Sonnet 和 Opus，进行了共 1,260 次真实 Claude Code 会话，包括探索性实验和预注册 A/B 实验。

各实验组使用相同提示词、设置和全新的仓库副本。隐藏验收测试在会话结束后才加入，避免模型提前围绕验收条件作答；确认性实验预先确定假设、样本量和判定规则，并用 SHA-256 标识被测代码版本，保存会话记录和可复现报告。

在涉及跨包修改的任务中，发布版本将「最终留下可用仓库」的比例从 43% 提升到 78%，最终测试集失败的比例从 57% 降到 22%。差异达到统计显著，Holm 校正后的 p = 0.00007，四次独立的预注册实验复现了改善。

模型表现也有反差。最终实验中，每个模型在每种条件下各做 24 次试验：Opus 从不使用插件时成功 3/24，升到使用后的 19/24；Sonnet 没有额外帮助就已经成功 23/24。

这不能拿来给模型排总榜。它只说明，在这些特定任务中，模型能力和验证习惯没有呈现简单的一一对应关系。

真正改变结论的是下一组对照：作者把相同验证规则直接写进 CLAUDE.md，移除插件的额外执行约束，成功率仍有 76%，距离插件的 78% 只差两个百分点。两者没有检出统计显著差异，p = 1.0。

这组实验支持的判断是：任务成功率的主要收益来自规则，插件额外机制的收益尚未被分离证明。

这里还有一个原文缺口：作者反复提到「四句话」，但提供的正文没有完整列出四句可复制规则，只能看到「最后一次修改后，再运行对应检查」的要求，以及兼容 Bash 等 Shell 的 pipefail 提示。不能据此补出所谓原版四句话。

作者要求把 npm test 替换为项目实际的全量测试命令；PowerShell 或其他 Shell 则需要调整管道错误处理方式。

插件仍有价值，但审计并不等于准确

改善模型行为和独立记录执行证据，是两件不同的事。CLAUDE.md 可以要求模型认真验证，却不会自行生成独立于模型口头报告的证据台账。

receipts 留下的价值主要在这里：发现长会话中缺少支持的成功声明、识别代码修改后已经过期的验证、检查测试是否可能被削弱，以及为 pull request 生成验证摘要。

不过，审计本身也会误判。

作者在真实开发历史里检查了 35 条被标记的声明：11 条确有问题，19 条误报，5 条无法根据记录确定。在可以判定的 30 条里，只有 11 条标对。这个结果很难支持把每次告警都当成必须重试的依据，因此插件默认警告，而不是自动强迫 Claude 返工。

短任务实验则暴露了另一个边界：单独启用回合结束审计，没有带来可测量的改善。因为那些会话没有虚报成功，连最终测试失败的会话也如实报告了失败，审计没有问题可抓。

作者还选了五个开源项目的真实 bug 修复任务，所有实验组全部完成，同样无法测出额外收益。

改进后的最终审计，在留出的 216 次新的诚实会话中没有产生告警；504 次启用插件的会话里，hooks 没有崩溃。前者说明这批样本上的误报控制有所改善，后者支持运行稳定性，但都不能证明它能抓住所有错误声明。

需要试用时，原文给出的安装命令是：

/plugin marketplace add Furkiak/claude-receipts

/plugin install receipts@receipts

第一行添加 marketplace，第二行安装 receipts@receipts。原文还建议扫描自己的会话历史，但没有提供具体扫描命令。

我的判断

我赞同先写规则，再判断是否需要插件。对于目前连全量测试命令都没有明确告诉 AI 的项目，先把验证约定写清楚，是成本较低、也更容易检查的一步。

作者给出的对照数据支持这个顺序，但不能把 76% 和 78% 理解成两种方案已经被证明等效。没有检出差异，可能是差异很小，也可能是样本和任务不足以把差异测出来。

实验还有明确前提：受控失败场景相对较小，运行环境是 Windows。它没有证明大型仓库、其他操作系统和长时间开发会话能获得相同收益。五个真实 bug 任务全部通过，也只能说明这些任务没能拉开差距。

与 CI 相比，receipts 更贴近交互过程，能够解释某次成功声明为什么缺乏支持；CI 则能在明确的提交状态上运行团队认可的检查。两者可以配合。插件记录了命令执行，也不代表项目已有的测试足以覆盖需求错误。

「完成」需要证据，而证据能支持多大的结论，也要单独判断。

能拿来做什么

• 在 CLAUDE.md 中写清项目真实的全量测试命令，并要求 AI 在最后一次相关修改之后重新执行检查。测试、build、lint、typecheck 应分别报告结果，不要合并成一句「都通过了」。
• 做前端组件库或 Node 多包仓库的共享模块修改时，让 AI 明确列出受影响包和已执行的检查范围。单包测试通过，只支持对应范围内的结论。
• 检查 AI 生成的测试命令是否用管道截断输出。在 Bash 等兼容 Shell 中处理好 pipefail；其他 Shell 按自身语义配置，避免把最后一条管道命令成功当成测试成功。
• 如果需要回查长会话或整理 pull request 验证证据，可以试用 receipts，并先人工复核告警。判断它是否适合团队时，同时记录真实问题、误报和无法判定的情况。