• 同样是“通过”，保证的事情可能不同
• 省下的调用费，会不会花在别处？
• 完成任务之后，人还剩多少工作？
• 让 Agent 互相检查，能替代外部判据吗？
• 少做一道题，与少做一份有用工作，不能混着衡量
• 任务做完了，判断是怎么学会的？
• 生成、审查和交付，需要三种不同的记录
• 少读上下文之后，能不能把需要的信息找回来？
• 准备训练环境，也是在选择 Agent 能学到什么
• 省下的推理费，需要和交付质量一起算
• 检查者拿到了什么，又替我们判断了什么
• 把失败留下来，还要让对照看得见退步
• 重建生成规则之后，选择历史仍可能不可见
• 让审查器见到干净改动，也量出停止修改的代价
• 先固定“做完”，再比较便宜
• 通信已经能替人传话，完成交接仍要有人定义
• 先确认任务发生了，再判断它做得对不对
• 省下的调用费，会不会花在别处？
• 漏洞更快出现，修复能力要沿着交付过程增长
• 检查开始了，还要知道它看到了什么、改好了什么
• 便宜的生成，建立在什么可以复用的工作上
• 扩大目标，也要扩大可检查的范围
• 保留稳定的上下文，也要能放下失效的假设
• 交接时要传递的，不只是一个成功标记
• 保留判断的过程，要比保留最后一次确认更具体
• 给临时规则一个退出的条件
• 验证环境本身，也需要被验证
• 把交接做好，需要看下一位参与者接到了什么
• 接口会把已有能力引向不同的行动
• 少打扰人的前提，是接手时有据可循
• 让“通过”指向一件可解释的事
• 更多真实发现，也会改变剩下的工作
• 把“通过”后允许相信的事写完整