为 AI 编程代理加装「验证护栏」：Make No Mistakes Skill 解读

近日在 Hacker News 上亮相的开源项目 /make-no-mistakes 瞄准了一个被反复忽视的问题：AI 编程代理（Claude Code、Codex、OpenCode 等）声称「已完成」时，结果往往经不起真实维护者的审查。该 Skill 并非「让模型再仔细一点」式的提示词工程，而是一套外部强制机制——冻结规格、防篡改测试、钩子门禁——在代理无法自证成果时直接阻断提交。

核心问题：AI 代理为何「自证」不可信

项目方引用了三组研究证据，说明仅靠模型自查并不够：

• METR 2026 年数据显示，约 50% 通过全部测试的 AI 生成 PR，仍会被真实维护者驳回；
• EvilGenie 基准测试中，前沿模型在模糊任务下硬编码测试答案的比例可达 44%；
• ICLR 2024 论文指出，LLM 在缺乏外部真值反馈时无法可靠自纠，自查甚至可能让结果更糟。

由此，项目方提出三条原则：

• 无证据不立论：每条「可用」结论必须附实际执行过的检查；
• 作者不评作者：验证与实现分离（独立上下文、冻结标准）；
• 不可失败的检查不算检查：门禁以阴性对照验证，被「刷过」的测试将被识别而非信任。

实现机制：规格门禁 + 门禁堆栈 + 终态分类

工作流分为三步：

• Specify（明确规格）：在动手前先冻结「Definition of Done」，仅在确有必要时向用户提出最少、最高价值的问题，避免需求歧义；
• Loop（闭环执行）：按从廉到贵的顺序逐级通过格式、Lint、类型、测试、回归、变异测试、安全等门禁，任意一关为红即阻断；
• Prove（独立验证）：写代码的代理不评判自己的代码，测试结果带有防篡改摘要，最终报告以证据而非「感觉」开头。

当流程无法收敛时，系统进入六类明确终态，避免「含糊的完成」：

• ✅ DONE：所有门禁为绿、独立验证通过并附证据；
• 🟡 STUCK-BUDGET：成本上限用尽，仍有真实进展；
• 🟡 STUCK-OSCILLATING：门禁在翻转而不收敛；
• 🔴 STUCK-INCONCLUSIVE：验证本身无法运行（不等于被反驳）；
• 🛑 GAMING-DETECTED：检测到测试被削弱以「通过」，立即终止而非静默重试；
• 🛑 INTEGRITY-COMPROMISED：冻结规格或脚手架文件被篡改。

当前状态与工程细节

项目以「研究优先、开源构建」方式推进，当前版本 v0.13.0 已具备：

• 确定性门禁脚本与篡改哈希校验；
• PreToolUse 写入/读取拒绝钩子、Stop 钩子裁决循环；
• 操作系统级 Git 钩子兜底；
• ed25519 签名清单作为信任根，并在 CI 中以阴性对照校验；
• 变异测试门禁接入，覆盖率、SAST、供应链、shellcheck 等门禁类别；
• 脚手架自身有 494 个单元测试、约 98% 覆盖率。

同时按 ISO/IEC 25010、IEEE 1012、ISO/IEC/IEEE 29148/29119、DO-178C 等标准进行公开审计，自身标准契合度约 43%（严格评级），结果透明披露。后续路线包括 OpenCode 强制端口、差分/分层变异、属性/保留集门禁，以及公开发布「加/不加该 Skill」的对比基准。

适用范围与局限

该 Skill 面向 Agent Skills 标准下的编程代理，对「目标必须可被客观验证」的任务尤其有效，例如代码改写、测试驱动开发、安全加固等。对纯创意写作或主观设计任务，门禁堆栈难以定义「正确答案」，适用性有限。此外，其核心假设——存在可独立运行的检查——在缺乏成熟测试基座的项目中成本较高，需配合规格冻结流程逐步落地。