从零搭建你的 AI 编程工作流

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