码海忠航

程序员用 AI 编程工具前，先准备这 5 个验收标准

别急着让 AI 写代码，先告诉它什么叫写对了。

AI 编程工具不是不能用，而是不能“直接放飞”。真正高效的用法，是先把验收标准写清楚，再让 AI 去执行。

昨天那篇文章我讲了一个判断：AI 编程工具真正拉开差距的，不是会不会写代码，而是会不会验收代码。

今天把这个判断落到更具体的动作上。

很多人用 AI 编程工具，第一句话就是：

这句话当然能用，但它太宽了。

AI 可能会很快给你一堆代码，也可能顺手改很多文件。问题是，你一开始没有告诉它什么算完成、什么不能碰、失败了怎么处理。

所以我建议，别急着让 AI 动手。先准备 5 个验收标准。

1. 需求边界：先说清楚“不做什么”

很多 AI 生成代码翻车，不是因为它不会写，而是因为它太会“顺手补全”。

你让它加一个收藏功能，它可能顺手改登录逻辑。你让它修一个样式问题，它可能重构一片组件。

所以第一个验收标准是：需求边界。

一个更好的指令是：只实现文章收藏按钮的前端交互，不改登录逻辑，不改数据库结构。如果你认为需要后端字段，请先列出原因，不要直接修改。

2. 输入输出：别让 AI 自己猜接口

第二个验收标准是输入输出。

AI 很擅长根据上下文猜，但真实项目里，很多坑都藏在输入输出里。

接口到底返回布尔值还是对象？失败时是错误码还是异常？列表为空时是空数组还是 null？用户没登录时跳登录页还是弹提示？

这些如果不说清楚，AI 就会按它觉得合理的方式写。结果可能能跑，但和你的项目约定不一致。

一句很有用的话是：如果接口字段或返回结构不明确，先列出你需要确认的问题，不要自行假设。

3. 失败回滚：错了能撤，才敢让它动

AI 编程工具最大的问题不是写错，而是写错以后你不知道它改了哪里。

所以第三个验收标准是失败回滚。

一次只让它做一个小任务。每次改动后先看 diff。不满意就整块撤回。不要让它连续改很多轮还不提交。

给 AI 的任务也可以加一句：请尽量保持改动集中，不要做无关重构。完成后总结改了哪些文件，以及每个文件为什么改。

4. 测试用例：别只看页面能不能跑

很多 AI 生成代码的问题是：它能跑通最开心的那条路径。

但真实项目里，问题往往出在边界路径：重复点击、接口失败、空数据、权限不足、老数据兼容。

你应该让 AI 在写实现之前，先列出测试场景。

可以这样说：在实现前，先列出这个功能至少 5 个测试场景，包含正常路径、失败路径、空状态和重复操作。

5. 代码审查：看 diff，不看态度

AI 很容易给你一段看起来很自信的解释。

但解释不能替代代码审查。你真正要看的是 diff。

如果你看不懂某一段，不要直接放过。可以追问：解释这段改动为什么必要，有没有更小的实现方式？

AI 可以加速执行，但交付航线要先由人画清楚。

AI 编程工具不是不能信。

但你不能把“能生成代码”当成“能交付功能”。

真正稳定的用法，是在让 AI 动手之前，先把验收标准准备好。

别急着让 AI 写代码。先告诉它，什么叫做写对了。