要证据，而不是模型给的结论

自我评审为什么不够用#

问一个智能体它自己的改动好不好，你会得到一份挺像样的 diff 评审：能编译、命名一致、边界情况处理了。这些都对，但没有一条回答了你真正的问题。「diff 是对的」和「这个功能能用」是两个不同的断言，而只有前一个能靠读代码检验。

而早期真正要紧的问题，本来就比代码评审粗得多：哪一步没人能走完、哪句话没人看懂、哪个按钮没人找到。这些问题在有人真的用一遍时就会暴露——用时以分钟计而不是以周计，而且是在投入还没沉没之前。

跑起来是什么样#

这里的评测是一个显式技能，不是常开的自动评审。你想要证据时才调用 `$eval`，仿真在本机运行:仿真用户走的是真实构建——就是智能体刚做出来的那一份——而不是它的一段描述。

回来的不是一个分数。截图、轨迹、命令和报告落在产物面板里，锚定到产出它们的那台机器与那次运行，可以就在产生它的会话旁边预览。这里的工作规则很直白:追溯不到某次运行的结论，视为没有结论。

证据接到哪里去#

收集证据的意义在于它改变接下来做什么:评测证据直接变成下一批任务。这才让它成为一个闭环、而不是一份报告——没走通的那一步变成智能体接着要做的那件事，中间不需要人把发现重新敲成一张工单。

证据同时留在它所属的项目里，因此第二轮可以和第一轮对比，而不是把第一轮覆盖掉。第二轮要回答「这个修复有没有生效」，前提是第一轮还在——这听起来是常识，却是多数做法最先丢掉的东西。

有一条边界值得点明:仿真用户不是真实用户的替代品，这里也不宣称它们能预测你的客户会怎么做。它们提供的是一种快而可重复的方式，用来找出那些事后看很明显的失败——那些你会为发出去而难堪、但不这么做就真会发出去的问题。