用途：消除幻觉式完成。编码智能体是模式补全器，“任务成功”的模式包含自信的完成措辞，无论断言是否真实都会生成。实证证明是结构性防线：不先粘贴证明模式为真的证据，智能体就无法完成该模式。
主要规则：不要假设成功——写代码只占 10%，在当前环境验证其可用占 90%，未运行的命令输出只是猜测；逐字粘贴——不转述、不总结、不写“✅ 通过”，用围栏代码块粘贴，包含最后两行或更多（运行器摘要加计时/退出条件）；每条断言单独验证——“构建通过”“测试通过”“lint 干净”“无架构违规”“迁移覆盖所有调用点”各自粘贴一份验证；每次更改后重跑——验证会迅速过期，重构和迁移期间尤其要反复验证；自行运行，不信任上游——审查他人分支时在自己的工作树检出对方分支运行项目验证与测试命令，对方粘贴的输出是待审查的断言而非证据；粘贴而非引用——用原始围栏代码块，不改输出、不加引号、不做 Markdown 修饰、不在中间加注释。
使用方式：粘贴任何“验证输出”前，先从仓库贡献者文档（如 AGENTS.md、CONTRIBUTING.md 或清单的 scripts 块）解析本项目用于验证和测试的实际命令；有的项目在构建和测试之外还运行额外检查（依赖或架构规则校验）。找不到命令或不确定某断言对应哪条命令时，先询问用户再运行——猜命令产生的输出证明不了任何东西。
好的证明示例：npm test 最后两行粘贴为围栏代码块（如“✓ 247 files passed / Done in 12.4s”）；npx jest 最后两行（如“Tests: 189 passed, 189 total / Time: 4.832 s”）。坏的证明：转述为“验证（最后两行）：一切通过 ✅”或“测试：189 个全绿”——看似合理甚至可能为真，但视为未验证。
不应包含：无验证支撑的完成声明；‘should pass’/‘expected to work’/‘tests should be green’等预测性语言；一条“all good”覆盖多项验证。
反模式：只说“测试通过，信我”；粘贴前两行而非最后两行；复用过期验证输出；审查时信任对方粘贴的输出而不自行运行；因为“diff 显然正确”而跳过验证。
常见逃避与回应：‘我本会话早先已跑过’→每次更改后重跑，早先那次已过期；‘从 diff 明显看出测试会通过’→diff 不运行测试，去跑并粘贴；‘CI 会抓到’→该纪律是智能体的关卡，不是 CI 的。
按任务类型：重构——逐检查点粘贴验证输出；迁移——逐波次粘贴验证与测试输出；性能——同一协议下的基线加目标基准输出；缺陷报告——缺陷确实触发的复现输出；测试——测试通过与断言翻转证明；文档——每个代码示例都实际运行。
易错点：把编辑前的运行当作当前结果粘贴；用“全绿”总结代替逐字尾部；审查时接受作者粘贴的输出而不重跑；粘贴与断言不同命令或范围（如用单文件测试输出支撑“全测试套件通过”）。
捆绑资源：references/evasions.md 收录完整的常见逃避及回应目录，正文仅内嵌前三条。