empirical-proof

用途

empirical-proof 旨在消除编码智能体的“幻觉式完成”问题。资料指出，编码智能体本质上是模式补全器，而“任务成功”这一模式天然包含听起来自信的完成语句（例如“✅ 所有测试通过”），智能体会不加辨别地生成这类语句，无论其底层声明是否真实。经验证据（empirical proof）是一种结构性防御：智能体必须先粘贴出证据证明模式成立，才能完成该模式。

项目上下文（AGENTS.md 契约）

该技能通过消费方仓库的 AGENTS.md 解析项目命令，包括其 Commands 表中的 cmdValidate 和 cmdTest 槽位，以及一个可选的依赖校验命令（架构规则检查），后者不在标准契约内；若项目使用该命令，需向用户询问。如果 AGENTS.md 缺失或某项未定义，在粘贴任何“验证输出”之前必须询问用户应运行哪个命令，不得猜测。

核心规则

永不假设成功。编写代码只占工作的 10%，在当前环境中验证其可用性占 90%。智能体无权在不运行测试命令的情况下假设其输出。
逐字粘贴。在填写 ## Self-review 时，粘贴逐字输出。不得转述、概括或写成“✅ passing”。使用围栏代码块，包含最后两行（或被要求时的更多行）——即运行器的摘要加上其计时/退出条件。
每个声明一次验证。任务中的每个声明——“构建通过”“测试通过”“linter 干净”“无架构违规”“迁移覆盖所有调用点”——各自获得单独粘贴的验证。将多个声明打包成一个“一切正常”会掩盖实际运行了哪项检查。
每次改动后重跑。验证会很快过期。如果智能体在验证之后做了改动，该验证即失效，必须重跑并重新粘贴。这在重构和迁移任务中尤为关键，因为“每 N 个文件验证一次”的规则会反复触发。
自己运行，不信任上游。在审查另一个智能体的分支时，需在自己的工作树中、检出该工作分支的情况下，亲自运行项目的验证和测试命令。工作方粘贴的输出不满足审查关卡——只有你自己运行的结果才算数。
粘贴，不要引用。对输出使用原始围栏代码块。不得转换输出（不引用、不加 Markdown 样式、不在粘贴中间加注释）。把输出当作数据处理：原样复制进来，不要改动。

证明的样子

✅ 好——逐字粘贴的输出

npm test（最后 2 行）：
```
✓ 247 files passed
Done in 12.4s
```

npx jest（最后 2 行）：

Tests:       189 passed, 189 total
Time:        4.832 s

❌ 差——转述

验证（最后 2 行）：一切通过 ✅
测试（最后 2 行）：全部 189 个测试绿灯

转述看似合理，甚至可能为真，但应视为未验证——转述不满足关卡要求。

不属于该技能的内容

没有支撑验证的自审回答。关于行为的每个声明都必须追溯到一段粘贴的输出。
“应该通过”/“预期可用”/“测试应该绿灯”这类措辞。这些是预测，不是证明。
单条“一切正常”覆盖多个验证。每次验证都需要单独粘贴。

反模式

“测试通过；相信我”
粘贴前两行而非最后两行（关卡要求的是摘要）
复用陈旧的验证输出（改动前运行，改动后粘贴）
在审查任务中信任工作方粘贴的输出而不自己运行
因为“diff 显然正确”而跳过验证

常见规避与应对

资料正文中内联了三种最常见的规避；完整目录位于 references/evasions.md，若对话中出现其他规避行为可调取该文件。

🚩 规避：“我在本次会话早些时候已经运行过了。” 应对：每次改动后都要重跑，早前的运行已过期。
🚩 规避：“从 diff 看测试显然会通过。” 应对：diff 不会运行测试。运行测试并粘贴输出。
🚩 规避：“CI 会捕获它。” 应对：该纪律是智能体自身的关卡，不是 CI 的关卡。

按任务类型的应用

经验证据纪律是通用的，但每种任务类型侧重不同的证明：

重构：每个检查点（每 10 个文件）的依赖校验输出。
迁移：每一波的验证和测试输出。
性能：同一协议下的基线 + 目标基准输出。
Bug 报告：bug 确实触发的复现输出。
测试：测试通过 + 断言翻转证明。
文档：每个代码示例都实际运行过。

捆绑资源

references/evasions.md —— 常见规避及其应对的完整目录（正文保留前三个，其余位于该文件）。