牛马复测

问题：交付报告不等于事实

典型的会后场景是这样的：决议记完，待办派出去，牛马（干活的 AI、另一个会话或接了活的同事）回了一句「已完成，请验收」。于是你点开报告，绿灯一片，看起来挺专业。

问题在于，报告是对方写的。测试数字是对方跑的，截图是对方截的，结论是对方下的。一旦实现者同时也是验收者，「通过」这个词就失去了全部语义——它只说明有人按了确认键。更糟的是，自测不可靠时，报告与现实的偏差比功能缺失更难发现：你以为修好了，实际上只是看起来修好了。

这个技能怎么补上这道缝

§0 会后闭环：纪要 → 派单 → 追踪 → 验收

• 纪要模板强制每条待办带 单一 owner + DDL + 可验证验收标准，三者缺一就不算待办。
• 任务状态机：待派单 → 进行中 → 待验收 → ✅通过 / ❌返工，到期未交直接升级给塔菲，不许静默顺延。
• 结论回填纪要待办表，纪要即档案，下次会议第一项议程就是过这张表。

§1 出方案：写自包含指令

给牛马的指令必须能被完整复制走，对方不看当前对话也能照做。五要素固定：背景与目标、锁死的技术栈与约束、分批拆解（每批交付后暂停等验收，不许连做）、带历史事故的铁律、逐条可验证的验收标准加 DDL。

§2 验收：四步独立复测

1. git diff --stat 加 grep 关键实现点，确认改动和声称一致。
2. 亲自重跑对方声称通过的测试、构建、lint、类型检查，用 -p no:cacheprovider 之类排除缓存假象。
3. 功能级证伪：安全类真喂攻击向量，状态机真跑到那个状态，UI 起服务截图读样式，别只读代码。
4. 出结论：通过或不通过，附逐条对照表。

重构与打磨类任务只有一条合格标准：行为零变更。改前拿基线数字（如 96 passed），改后必须原样复现，少一个都算改坏。

§3 诚实原则：区分「已验证事实」和「高把握推断」，够不到的验收条件（没真机、没真实凭据）如实标注「待真机验收」，绝不替对方宣称通过。

适用边界

• 适合：外包式实现、有明确验收标准的交付、改结构不改行为的重构。
• 不适合：三五行的小改动——自己改完顺手验证即可，走完整验收流程是纯开销；探索性原型本来就没有「不能改坏」的基线；纯咨询问答没有交付物。
• 验收的前提是你能亲手跑或亲眼查。 够不到的东西不构成验收证据，只构成误判。