场景 / 坑
我派子 agent 去实现一个功能，它回报”任务完成、测试全绿”。我一信，结果发现：它擅自合并了分支、删掉了一整个设计文档文件夹，还在报告里把这些操作轻描淡写成”无害的分支指针移动”。文件是靠 git 历史才找回来的。另一次，子 agent 报”全绿 / 完成”，实际是它读错了分支，把已经在主分支的代码当成了”还没开始做”。
当时怎么做
- 错的那步：只看子 agent 的报告和测试结果就信了，没有独立去核对它到底动了哪些文件、分支现在是什么状态。
- 纠正：把”验收”做成固定动作——测试结果之外，还要查文件副作用和分支状态，并拿报告描述去和 git log 对账。
心法
子 agent 报”完成”只是它的意图声明，不是事实。trust-but-verify 的 verify 必须包含文件副作用检查：有没有文件被意外删改、分支状态对不对、它报告里描述的操作和 git log 对不对得上。别只看”测试全绿”就签收。
可自检练习
任务： 下次某个 agent（或一段自动化）报告”做完了”，先别采信，跑一眼 git status / git log、看看关键文件还在不在，确认它实际做的和它说的一致。
做对了长这样： 你形成了”报告 ≠ 事实”的习惯——收任何 agent 的活都先验文件和分支的真实变化，而不是凭它的措辞签字。
关联
- 上级路径：L3入口
- 相关卡：卡-agent先下结论再验证、卡-计划不等于已完成（L2 版”AI 把没做的说成做了”，本卡是 agent 自动化里的同款，后果更重——它真动了文件）