完成标准先行，且要机器可检查
「怎么算完成」要在动手前说清，且最好是机器能查的：测试绿、产物在、diff 空。
很多 vibe coding 翻车是这么翻的：AI 做完了说「做完了」，你一看发现差得远，于是改；改完再让 AI 做，它又「做完了」，你又发现差得远。反复下来，你成了测试员。解法只有一个：别等做完再定标准，先定义「完成」，让 AI 照着做。 anthropic-sdlc
读完你能回答：
- 为什么「做到什么程度算完」必须动手前说？
- 机器可检查的完成标准有哪些具体表现？
- 怎么避免被「做完了」糊弄？
完成标准要具体到什么程度
「做完」两个字没用，要具体到能验证：
- 这个功能打开长什么样，用户能做什么
- 哪些 case 必须对，写成测试
- 哪些边界先不管，写进不做清单
标准越具体，AI 跑偏的概率越低，你验收的时间越短。
机器可检查的完成标准
能写进测试、构建、脚本的，就不要靠嘴说：
| 标准 | 怎么检查 |
|---|---|
| 功能行为正确 | 测试通过 |
| 能构建、能跑 | 构建成功、产物在 |
| 没改坏别的东西 | 老测试还绿、diff 干净 |
| 没有明显问题 | review + 静态检查过 |
这些是「做过没做过」的证据，不是「AI 说做完了」的嘴。
怎么验收不糊弄
验收口诀：看证据，不看声明。 AI 说「完成了」只是它声明，你要的是证据——测试输出、构建日志、产物路径、diff 内容 vibe-report。
- 让 AI 把测试跑一遍，把输出贴给你
- 让 AI 把跑通的产物路径给你，你去确认存在
- diff 变化逐项过一遍，尤其 AI 偷偷改你不让动的文件
跨系统、跨团队的时候还有一层：「操作成功」只说明命令发出去了。验收证据要由拥有资源的系统出，按用户最终看到的结果算——谁来出证据、怎么算，见组织是人的 Harness。
「验收标准先行且机器可检查」，是 vibe coding 把「带实习生」真正落地的关键。标准定了，接着把规则固化进项目文件，让 AI 一直守：项目契约文件 AGENTS。