它说「做完了」，你怎么确认
AI 会告诉你「已完成」「功能已实现」「测试通过」。
**它说这话的时候不是在骗你，是它真的这么认为。**问题在于它的判断标准和你的不一样——它看的是「我按你说的写了代码」，你要的是「这东西真的能用」。
这两件事经常不是一回事。
达标 ≠ 达到目的
Section titled “达标 ≠ 达到目的”这是本层最重要的一句话。
举个例子。你说：「做个上传功能，文件大小限制 10MB。」
它做完了，代码里确实写了 if (size > 10MB) reject。指标达标了。
但是：
- 用户传了个 9MB 的文件，页面卡死三分钟，没有任何提示 —— 达标了
- 限制写在前端，用工具绕过去直接传 500MB —— 达标了
- 超过 10MB 时报错信息是一串英文堆栈 —— 达标了
每一条都通过验收，每一条都没达到目的。
防线要修在对的那一层
Section titled “防线要修在对的那一层”上面那个例子暴露了一个高频错法：把约束放在了不该负责的那一层。
| 约束 | ❌ 放错地方 | ✅ 该放哪 |
|---|---|---|
| 文件大小限制 | 前端检查 | 服务端接收时 |
| 「每天最多 10 条」 | 展示的时候筛 | 写入数据库时 |
| 「只能是中文」 | 提示词里说一句 | 入库函数里校验 |
| 「只有管理员能删」 | 前端不显示删除按钮 | 接口里检查权限 |
通用判据：约束要守在「产生数据的那一层」，不是「消费数据的那一层」。
放在消费侧的约束，绕过去只需要换个入口——而前端的每一个入口，用户都能绕。
怎么写验收标准
Section titled “怎么写验收标准”弱标准会被绕过，强标准不会。区别在于：强标准能被一个具体动作证伪。
| ❌ 弱（禁用） | ✅ 强（照这个写） |
|---|---|
| 上传功能正常 | 传一个 11MB 的文件，返回明确的中文错误提示，服务器上没有产生文件 |
| 界面符合设计 | 在 375px 宽的屏幕上打开，没有横向滚动条，按钮不重叠 |
| 性能没问题 | 首页打开在 3 秒内出现内容（用浏览器 Network 面板的 Load 数字为准） |
| 测试通过 | 贴出测试命令的原始输出，显示 N passed, 0 failed |
| 安全没问题 | 用无痕窗口不登录访问 /admin，被挡住 |
**判据很简单：这条标准能不能用一个动作验证？**不能，就重写。
三件事，按性价比排序
Section titled “三件事，按性价比排序”1. 自己点一遍（永远第一位）
Section titled “1. 自己点一遍（永远第一位）”**AI 说做完了，你自己打开点一遍。**听起来蠢，但它抓到的问题比任何工具都多。
重点点这三类：
- 正常路径：按预期用一遍
- 空的情况：什么都不填就提交、列表里一条数据都没有
- 错的情况：填乱七八糟的东西、断网、点两下提交按钮
2. 让它写测试，然后你去读测试
Section titled “2. 让它写测试，然后你去读测试”让 AI 写测试很容易，但要读一眼测试到底测了什么。
常见的假测试：断言写成 expect(true).toBe(true)、把出错也当成通过、测了一个根本不会失败的东西。
3. 换一双眼睛审
Section titled “3. 换一双眼睛审”让写代码的那一方审查自己写的代码，等于没审。
它看不见自己的盲区——同一套判断逻辑，写的时候觉得对，审的时候还是觉得对。
低成本做法：开一个新的对话（不带之前的上下文），把代码贴进去，问：
这段代码有什么问题？特别看：安全、边界情况、错误处理。默认它有问题，请找出来。
「默认它有问题」这句话很重要——不加这句，它倾向于告诉你「看起来不错」。
学完这一节，你应该能做到
Section titled “学完这一节，你应该能做到”- 说得出「达标」和「达到目的」的区别，并举一个例子
- 判断一条约束该守在哪一层（产生数据侧 vs 消费数据侧）
- 把一条弱验收标准改写成能被动作证伪的强标准
- 看到「测试通过」时，会去要原始输出
- 用一个新对话审查代码，而不是问写它的那个
看看真实事故库——那些都是别人已经踩过的坑。