这条规则指出了 AI 编码里一个容易被“绿灯”掩盖的治理问题：如果实现者还能改验收标准，测试通过就不再是独立证据。agent 根据失败信息修改实现后，又把断… · @fireandstart · TwKit

@fireandstart

这条规则指出了 AI 编码里一个容易被“绿灯”掩盖的治理问题：如果实现者还能改验收标准，测试通过就不再是独立证据。agent 根据失败信息修改实现后，又把断言同步改成符合当前实现，表面上闭环了，实际上只是把答案和评分表写成一致。真正需要保护的，是测试对需求的独立表达，以及失败信号带来的约束力。 职责拆分是一个可执行的起点：builder 负责实现，reviewer 用新上下文独立审查，测试在行为契约未变时保持稳定，最终合并由人负责。若需求确实变化，更新测试当然合理；但 PR 应清楚说明契约为何改变，并让独立审查者判断新的预期是否来自需求，而不是为了让现有实现变绿。测试文件也不该被随手删除，再以“简化”为由隐藏失败。 这类边界需要落到权限和流程里：谁能改代码、谁能调整验证、谁批准结果，都应明确；触碰测试时保留可审查的理由，并把异常交给独立 reviewer。评价 agent 不应只看完成率或全绿，还要确认它是否尊重了验收规则。自动化越能高效改代码，越需要让验证证据不受同一执行者控制，才能让速度增长伴随可信度，而不是只得到更快的自我证明。

曝光 101 · 评论 0 · 点赞 1 · 书签 0