前面的文章分别介绍了需求拆分、代码生成、测试、优化和代码审查。
但在真实开发中，我们很少只做其中一件事。一个功能通常要经历：
text
需求分析 → 编码实现 → 测试验证 → 代码审查 → 文档整理如果每一步都临时提问，AI 给出的内容可能互相矛盾，自己也容易忘记验证哪些地方。
因此，我们需要建立一套固定的 AI 编程工作流。
这篇文章不讨论复杂的自动化平台，只用一个小功能说明：
如何让 AI 参与开发全过程，同时把关键判断留在自己手中。
一、先明确 AI 在工作流中的位置
AI 更适合做以下工作：
- 整理信息。
- 发现遗漏。
- 生成代码草稿。
- 提供多种实现方案。
- 补充测试场景。
- 检查修改内容。
- 整理技术文档。
开发者仍然需要负责：
- 确认真实需求。
- 选择合适方案。
- 判断代码是否正确。
- 处理业务和安全问题。
- 在真实环境中运行验证。
可以把 AI 看成一名效率很高的助手，而不是自动交付系统。
二、用一个小功能贯穿全流程
假设我们要给商品列表增加"按关键词搜索"功能。
项目情况如下：
- 前端使用 Vue 3。
- 后端使用 Node.js 和 Express。
- 商品数据保存在 MySQL 中。
- 现有接口为
GET /api/products。 - 本次只搜索商品名称，不修改数据库表结构。
需求是：
text
用户在输入框中输入商品名称关键字，点击搜索后显示匹配的商品。
关键字为空时显示全部商品。
没有匹配结果时显示空状态。接下来把这个需求放进五个阶段。
三、第一阶段：让 AI 帮你确认需求
不要一开始就让 AI 写代码。
先让它检查需求是否完整，并指出还需要确认的问题。
可以这样提问：
text
请帮我分析下面的功能需求，暂时不要写代码。
项目背景：
- 前端：Vue 3
- 后端：Node.js + Express
- 数据库：MySQL
- 已有接口：GET /api/products
功能需求：
用户输入商品名称关键字后，查询并展示匹配商品。
关键字为空时显示全部商品，没有结果时显示空状态。
请输出：
1. 你对需求的理解
2. 需要确认的问题
3. 前端任务
4. 后端任务
5. 测试验收标准
不要自行增加分页、排序或模糊匹配以外的功能。AI 可能会提醒我们确认：
- 搜索是否忽略大小写。
- 是否使用模糊匹配。
- 关键字是否需要去除首尾空格。
- 搜索失败时显示什么提示。
- 是否需要防止用户频繁请求。
这些问题应该先结合产品和项目规则确认，再进入编码阶段。
这一阶段的产物
不要只留下聊天记录，可以整理出一份简短的实现约束：
text
功能：按商品名称搜索
匹配方式：包含匹配，不区分大小写
空关键字：查询全部商品
空格处理：去除首尾空格
无结果：返回空数组，前端显示空状态
错误处理：接口失败时显示错误提示
范围限制：本次不增加分页和排序这份约束就是后面让 AI 写代码和测试时的共同上下文。
四、第二阶段：让 AI 先出方案，再写代码
需求明确后，再让 AI 设计实现方案。
text
请根据已经确认的需求，设计一个简单的实现方案。
要求：
1. 说明前端需要修改哪些文件。
2. 说明后端需要修改哪些文件。
3. 说明接口参数和返回结果。
4. 说明关键的边界条件。
5. 优先复用现有项目结构，不要引入新依赖。
6. 先输出方案，不要写完整代码。一个合理的方案可能是：
text
1. 前端在搜索框中维护 keyword 状态。
2. 点击搜索时对 keyword 做 trim 处理。
3. 请求 GET /api/products?keyword=xxx。
4. 后端读取 keyword 参数。
5. keyword 为空时查询全部商品。
6. keyword 不为空时使用参数化查询进行名称匹配。
7. 前端分别处理加载中、成功、空数据和失败状态。方案确认后，再让 AI 分小步生成代码。
text
请只实现后端接口部分。
约束：
- 使用现有 Express 路由和数据库访问方式。
- keyword 为空时查询全部商品。
- keyword 不为空时按商品名称包含匹配。
- 必须使用参数化查询。
- 不修改数据库表结构。
- 保持现有返回格式。
请先列出需要修改的文件，再给出代码。一次只处理一个部分，更容易发现问题，也方便回退。
五、第三阶段：让 AI 帮你补测试
代码写完后，不要马上让 AI 重构或继续增加功能。
先让它根据需求列测试场景：
text
请根据下面的需求列出测试场景，暂时不要写测试代码。
需求：
- keyword 为空时返回全部商品。
- keyword 前后有空格时需要自动去除。
- keyword 使用包含匹配。
- 没有匹配商品时返回空数组。
- 数据库查询失败时返回统一错误。
请按正常、边界、异常三类输出，
每个场景包含输入、预期结果和测试目的。测试场景至少应该包括：
| 类型 | 输入 | 预期结果 |
|---|---|---|
| 正常 | 耳机 |
返回名称中包含"耳机"的商品 |
| 空值 | 空字符串 | 返回全部商品 |
| 空格 | 耳机 |
按 耳机 查询 |
| 无结果 | 不存在的商品 |
返回空数组 |
| 异常 | 数据库连接失败 | 返回统一错误信息 |
| 特殊输入 | 包含 SQL 特殊字符 | 不执行危险 SQL |
确认场景后，再让 AI 按项目现有测试框架生成代码。
text
请使用项目已有的测试框架，为上面确认的场景生成测试代码。
要求：
1. 先查看现有测试文件的写法并保持一致。
2. 每个测试必须有明确断言。
3. 不要修改生产代码。
4. 不要使用真实数据库和真实用户数据。
5. 说明每个测试验证了什么。重点检查测试有没有"假通过"：
- 只检查接口没有抛异常，却没有检查返回数据。
- 只检查状态码，没有检查业务字段。
- 断言过于宽泛，任何结果都能通过。
- 测试没有覆盖空值和异常情况。
六、第四阶段：让 AI 审查代码和修改范围
测试通过后，再进行代码审查。
这时最好提交本次修改的 diff，而不是整个项目。
bash
git diff -- src/routes/products.js src/views/ProductList.vue test/products.test.js把 diff 和需求一起交给 AI：
text
请审查下面这次商品搜索功能的代码修改。
已确认的需求：
- 按商品名称包含匹配。
- 空关键字返回全部商品。
- 去除关键字首尾空格。
- 无结果返回空数组。
- 必须使用参数化查询。
- 本次不增加分页和排序。
请重点检查：
1. 是否满足需求。
2. 是否存在 SQL 注入风险。
3. 是否遗漏空值、异常和空结果处理。
4. 是否影响原有商品列表功能。
5. 是否修改了需求之外的内容。
6. 是否缺少测试或文档。
请按"问题位置、严重程度、影响、建议、验证方式"输出。
先列问题，不要直接重写代码。
代码 diff：
[粘贴 git diff 内容]代码审查阶段要关注 AI 的具体证据，不要只看"整体没有问题"这样的结论。
如果 AI 指出 SQL 拼接风险，就回到代码中确认查询是否使用了参数占位符；如果它指出缺少测试，就确认对应场景是否真的存在测试文件和断言。
七、第五阶段：让 AI 整理文档
功能验证通过后，再更新 README 或接口文档。
text
请根据下面已经验证通过的接口信息，补充接口文档。
接口：GET /api/products
查询参数：
- keyword：商品名称关键字，可选
行为：
- 为空时返回全部商品。
- 不为空时按商品名称包含匹配。
- 服务端会去除首尾空格。
- 没有匹配结果时返回空数组。
请输出 Markdown 格式，包含：
1. 接口用途
2. 请求方式和地址
3. 参数说明
4. 成功返回示例
5. 空结果示例
6. 错误说明
只使用上面提供的事实，不要编造分页、排序和权限规则。文档应该基于已经实现和验证的结果生成。
不要先让 AI 写一份"看起来完整"的文档，再反过来让代码迁就文档。
八、每个阶段都设置一个检查点
AI 工作流最容易出问题的地方，是直接从一个阶段跳到下一个阶段。
可以为每个阶段设置检查点：
| 阶段 | 交给 AI 的工作 | 自己必须确认的结果 |
|---|---|---|
| 需求 | 提取规则、发现疑问 | 业务规则和范围 |
| 方案 | 拆任务、设计接口 | 方案简单且可实现 |
| 编码 | 生成局部代码 | 代码符合项目结构 |
| 测试 | 补场景和测试代码 | 断言真实有效 |
| 审查 | 查找风险和遗漏 | 问题已经修复并验证 |
| 文档 | 整理使用说明 | 文档与实际行为一致 |
只有当前阶段确认完成，才进入下一阶段。
九、建立自己的上下文模板
每个项目都可以准备一份固定的上下文模板：
text
项目名称：[项目名称]
技术栈：[语言、框架、数据库和版本]
目录结构：[相关目录]
代码规范：[命名、格式和测试要求]
接口约定：[请求和返回格式]
当前任务：[本次要完成的功能]
明确限制：[不能修改的内容]
验收标准：[什么结果算完成]每次开始新任务时，只需要补充"当前任务、明确限制和验收标准"。
这样可以减少重复描述，也能降低 AI 前后理解不一致的概率。
需要注意，不要把密钥、真实用户数据和生产环境敏感信息放进上下文模板。
十、一个适合日常开发的简化流程
如果完整流程看起来比较多，可以先记住下面这套简化版：
text
1. 先说清楚要做什么
2. 让 AI 找出不明确的地方
3. 确认方案和修改范围
4. 让 AI 一次只写一个小部分
5. 自己运行并测试
6. 让 AI 审查 diff
7. 更新文档并记录结果对于一个很小的工具函数，可能只需要经过需求、编码和测试三个阶段。
对于支付、权限、数据删除等高风险功能，则应该完整执行五个阶段，并增加人工评审。
十一、常见的 3 个错误做法
| 错误做法 | 为什么有问题 | 更好的方式 |
|---|---|---|
| 让 AI 一次完成整个项目 | 代码量大，难以理解和验证 | 拆成接口、组件和测试等小任务 |
| 没有检查就进入下一步 | 早期错误会一直传到后面 | 每个阶段确认产物后再继续 |
| 让 AI 生成后直接自我审查 | 可能重复之前的错误理解 | 重新提供需求和验收标准，必要时进行人工复核 |
十二、个人 AI 编程工作流清单
每天开始一个新任务时，可以按下面的清单执行：
- 已经用一句话说明本次目标。
- 已经列出需求中的不确定点。
- 已经确认修改范围和限制。
- 已经让 AI 输出实现方案。
- 已经把任务拆成可验证的小步骤。
- 已经运行过生成的代码。
- 已经测试正常、边界和异常场景。
- 已经让 AI 审查代码 diff。
- 已经修复高优先级问题。
- 已经更新相关文档。
- 没有向 AI 提交密钥、用户数据或未经授权的公司代码。
总结
一套实用的 AI 编程工作流，可以分为五个阶段：
text
需求 → 编码 → 测试 → 审查 → 文档AI 在每个阶段都可以提供帮助，但每个阶段的最终检查仍然需要开发者完成。
使用这套流程时，建议记住三个原则：
- 先确认需求，再开始写代码。
- 一次只让 AI 完成一个清晰的小任务。
- 每一步都运行、测试和检查，不把错误带到下一阶段。
真正高效的 AI 编程，不是让 AI 一次生成最多代码，而是让每次生成的内容都能被快速理解、验证和使用。
下一篇文章将介绍：
《真实案例：用 AI 重构一段难维护的旧代码》
✍坚持原创，求关注，点赞，收藏