AI 编程最容易给人一种错觉：它可以一次性生成完整功能，所以我们应该一次性给它完整任务。

真实项目里，这通常很危险。

因为一次性改动越大，你越难判断：

• 它有没有理解需求。
• 它有没有破坏已有逻辑。
• 它有没有改无关文件。
• 它有没有引入新依赖。
• 它有没有留下无法测试的代码。

我更推荐的方式是：让 AI 小步开发，每一步都有明确输入、明确修改范围和明确验证方式。

开发前先让 AI 复述任务

不要直接说：

帮我实现订单退款功能。

更好的第一步是：

请先阅读退款相关代码，不要修改。
然后输出：
1. 当前退款流程在哪里
2. 相关接口和数据表
3. 实现新需求可能影响哪些文件
4. 你对需求的理解
5. 需要我确认的问题

如果 AI 对现有流程理解错了，马上纠正。

不要等它写完 10 个文件再返工。

把功能拆成可以验收的小任务

一个功能不要一次做完。

以“给订单增加退款原因”为例，可以拆成：

• 数据模型增加 refundReason 字段。
• 后端接口支持提交退款原因。
• 前端表单增加输入框。
• 详情页展示退款原因。
• 补充接口测试。
• 补充页面验收清单。

每一步都可以单独验证。

提示词：

请把这个需求拆成 5-7 个开发步骤。
每一步要求：
1. 修改范围尽量小
2. 可以独立验证
3. 标明涉及文件
4. 标明验证命令或手工检查方式

拆完以后，不要让 AI 一口气全做。

先做第一步。

每次只给一个明确修改范围

比如：

现在只做第一步：为退款记录增加 refundReason 字段。
要求：
1. 只修改数据模型和必要的类型定义
2. 不修改前端页面
3. 不新增无关字段
4. 修改后说明需要执行的迁移或验证命令

这种写法能显著降低失控概率。

AI 不是不能做大任务，而是大任务应该由多个小闭环组成。

让 AI 先给方案，再改代码

对稍微复杂的修改，我会要求 AI 先输出方案：

请先给出实现方案，不要修改代码。
说明：
1. 要改哪些文件
2. 每个文件改什么
3. 为什么这样改
4. 可能影响哪些已有功能

方案没问题，再让它执行。

这一步相当于把 Code Review 前置。

你不需要等代码生成后才发现方向错了。

看 diff 是必修课

AI 修改完以后，第一件事不是继续提需求，而是看 diff。

你要重点看：

• 是否修改了无关文件。
• 是否引入了新依赖。
• 是否删除了已有逻辑。
• 是否改变了公共接口。
• 是否写了重复代码。
• 是否绕开了现有架构。

如果发现问题，直接要求它收敛：

这次修改范围过大。
请保留退款原因字段相关修改，撤回与样式重构、依赖升级无关的改动。
以后当前任务不做无关重构。

注意：你要具体指出哪些是不相关改动。

报错时不要让 AI 乱猜

当测试失败时，把完整输出给它。

下面是 npm test 的完整失败日志。
请先分析失败原因，不要立刻修改。
输出：
1. 哪个测试失败
2. 失败原因
3. 是测试需要更新，还是业务代码有问题
4. 你建议的最小修复方案

AI 调试能力很强，但前提是它拿到完整上下文。

如果你只贴最后一行，它只能猜。

让 AI 自查一遍

代码改完、测试跑完以后，继续让 AI 做自查：

请审查本次改动。
重点检查：
1. 是否满足需求
2. 是否存在未处理的边界情况
3. 是否有安全或权限问题
4. 是否缺少测试
5. 是否有可以简化的地方

这个步骤经常能发现遗漏。

比如：

• 后端校验了字段，前端没限制长度。
• 新增字段没有在详情接口返回。
• 测试只覆盖成功场景，没覆盖空值。
• 退款原因可能包含敏感信息，日志不该直接打印。

AI 的第一次输出不一定可靠，但它的第二轮审查通常很有价值。

一个完整开发提示词模板

我要实现这个需求：
<粘贴需求>

请按下面流程工作：
1. 先阅读相关代码，不要修改
2. 复述你对需求的理解
3. 列出影响范围和需要修改的文件
4. 把任务拆成小步骤
5. 先只实现第一步
6. 修改后输出 diff 摘要和验证方式

约束：
- 不做无关重构
- 不新增依赖，除非先说明原因
- 优先复用现有代码风格
- 每一步都必须可验证

最后

AI 写代码真正的效率，不是一次生成很多文件，而是让每一步修改都更快、更清楚、更容易验证。

你要把 AI 当成一个很快的协作者，而不是一个可以无人看管的外包团队。

记住这条原则：任务可以大，但给 AI 的执行步子要小。

下一篇我会写测试。因为 AI 生成代码越快，测试越重要。没有测试，AI 编程只是把不确定性加速了。