文章目录开篇本文不会讨论什么一、为什么不要一开始就问“用哪个 AI”二、一条完整开发工作流通常包含哪些环节三、盘点工作流时重点看这 5 个节点1. 需求到任务你是不是经常边写边猜2. 阅读代码你是不是总在找“入口到底在哪里”3. 方案到实现你是不是一上来就让 AI 写完整功能4. 测试和排障你是不是只在出错后才想到 AI5. 交付与复盘你是不是每次都从零开始四、盘点完成后先把 AI 放到哪里五、今天就可以完成的一次工作流盘点六、总结✍创作者全栈弄潮儿²⁰²⁶ 个人主页全栈弄潮儿²⁰²⁶ 专栏地址AI 编程进阶实战开篇开始使用 AI 编程后很多开发者最常问的问题是哪个 AI 工具更适合写代码哪个模型生成代码更准确有没有万能 Prompt用什么插件能自动帮我完成更多事情这些问题当然有价值。但如果还没有梳理过自己的开发流程即使换了更强的工具也很容易陷入下面的状态需求来了仍然不知道应该先问 AI 什么。代码生成很快测试、联调和排错却越来越乱。只在写代码时打开 AI真正耗时的需求澄清、阅读旧代码和排障却没有改善。每次对话结束后没有留下可复用的模板、清单和经验。所以在继续研究“用哪个 AI”之前我们先解决一个更基础的问题你的日常开发时间究竟花在了哪些环节哪些环节适合让 AI 参与本文不会做工具横评也不会推荐某一个模型。我们要做的是盘点一条真实的开发工作流找到 AI 最值得介入的节点并建立一套可验证的协作方式。本文不会讨论什么为了让这篇文章保持聚焦下面这些内容不会展开不比较不同 AI 工具的能力排名。不推荐“复制即可使用”的万能 Prompt。不把 AI 生成代码等同于功能交付。不用工具数量衡量开发效率。不鼓励在不了解项目的情况下让 AI 大范围改代码。本文只讨论一件事先看清自己的研发流程再决定把 AI 放到哪里。一、为什么不要一开始就问“用哪个 AI”工具只是能力的放大器不会自动修复混乱的流程。如果你的工作方式是收到需求 ↓ 边问边写 ↓ 出了问题再查 ↓ 临近交付时补测试那么即使 AI 帮你更快地产出代码也可能只是更快地把不确定性带到后面。例如下面这句提问很常见帮我实现一个订单金额计算功能。它看起来像是“让 AI 写代码”但真正缺少的信息非常多商品价格和数量是否合法优惠券是否可以超过商品总价金额按元还是按分保存运费、税费、会员折扣是否在本次范围内错误应该抛异常还是返回业务错误码这段逻辑应该放在 Controller、Service 还是领域层如果这些问题没有在流程前面解决换任何 AI 都不会让结果可靠。所以第一步不是选工具而是识别哪个环节最耗时。哪个环节信息最不完整。哪个环节最容易返工。哪个环节的结果最容易验证。AI 最适合进入“目标清楚、上下文可提供、结果可验证”的位置。二、一条完整开发工作流通常包含哪些环节不同团队的研发流程会有差异但一个功能从需求到交付通常会经过下面这条链路理解需求 ↓ 阅读现有代码与资料 ↓ 设计方案和拆分任务 ↓ 编写与修改代码 ↓ 测试、调试和排错 ↓ 代码审查、联调与发布 ↓ 文档、复盘与知识沉淀如果只把 AI 用在“编写代码”这一步你只覆盖了整条链路中的一个节点。真正值得盘点的是每个节点的输入是什么、产出是什么、常见阻塞是什么、AI 能提供什么帮助、最终由谁验证。可以先用下面这张表记录一个正在开发的真实任务工作环节当前在做什么最耗时或最容易卡住的地方可交给 AI 的辅助任务必须人工确认的结果需求理解阅读需求、和产品沟通规则不完整、边界遗漏列待确认问题、整理需求清单业务规则和验收标准代码阅读找入口、追调用链项目陌生、模块耦合总结目录、解释调用链真实代码路径和影响范围方案设计定接口、分模块方案选择多、风险不清比较方案、列风险和测试点架构与业务取舍代码实现写模块、改逻辑样板代码多、上下文切换生成草稿、补类型和注释代码质量和项目一致性测试排障写测试、查错误边界遗漏、日志分散设计测试矩阵、归类异常根因、修复和回归结果交付沉淀提交、写文档、复盘过程没有记录整理变更、生成复盘初稿最终说明和经验结论这张表不是为了把所有工作都交给 AI。它的目的是让你先看见时间和风险集中在哪里。三、盘点工作流时重点看这 5 个节点1. 需求到任务你是不是经常边写边猜如果一个需求进入开发后才不断发现接口字段没有定义。状态流转没有说清。异常情况没有讨论。验收标准只存在于口头沟通里。那么最该引入 AI 的不是代码生成而是需求拆解。可以先让 AI 输出问题清单请协助拆解下面这条需求但先不要写代码。 需求 [粘贴原始需求] 请输出 1. 需要确认的业务规则。 2. 正常、边界和异常场景。 3. 可能涉及的接口、数据结构和状态变化。 4. 可以拆分的开发任务。 5. 仍然无法从需求中判断的假设。这一步的产出应该是一份开发前检查清单而不是一段代码。2. 阅读代码你是不是总在找“入口到底在哪里”接手一个旧模块时真正耗时的往往不是修改代码而是搞清楚请求从哪个入口进入。核心业务逻辑在哪一层。数据从哪里读取和写入。哪些模块会被本次修改影响。现有测试覆盖了哪些场景。此时可以让 AI 协助做“代码导览”但前提是给出足够上下文我需要修改一个订单取消功能。 下面是相关目录结构、Controller、Service 和测试文件 [粘贴目录和关键代码] 请输出 1. 请求入口到数据写入的调用链。 2. 每个文件的职责。 3. 订单状态校验可能出现的位置。 4. 修改功能时可能受影响的调用方。 5. 建议我优先阅读的文件顺序。 不要猜测未提供的代码不确定的地方请明确标注。AI 给出的导览只能作为阅读路线图。最终仍然要通过源码搜索、断点、日志和测试确认调用链。3. 方案到实现你是不是一上来就让 AI 写完整功能复杂任务直接索要完整实现最容易得到“看起来能跑、放进项目就不合适”的代码。更可靠的方式是把这一步拆成三轮第一轮让 AI 复述任务、列出假设和风险 第二轮让 AI 比较方案、明确模块边界和测试点 第三轮让 AI 按已确认约束生成最小实现以订单金额计算为例第一轮可以这样提问现在需要实现订单金额计算支持商品总价和优惠券抵扣。 请先不要写代码。 请列出 1. 需要确认的金额和优惠券规则。 2. 建议的输入、输出和异常策略。 3. 未来接入运费、税费和会员折扣时的扩展点。 4. 可能影响正确性的边界条件。等规则确认后再让 AI 输出函数签名、实现草稿和测试矩阵。不要跳过“方案”这一层。方案讨论通常只需要几分钟却能减少大量后续返工。4. 测试和排障你是不是只在出错后才想到 AIAI 很适合参与测试设计和问题排查但它需要的是证据而不只是错误信息。对于测试可以让 AI 先列矩阵请为下面的订单金额计算规则设计测试矩阵。 规则 [粘贴已确认规则] 请按“正常、边界、异常”三类输出 - 输入 - 预期结果 - 覆盖规则 - 测试目的 暂时不要生成测试代码。对于排障可以让 AI 先组织假设请协助分析一个接口偶发失败的问题。 已知信息 - 问题现象[描述] - 完整错误栈[粘贴] - 最近代码变更[描述] - 已排除方向[描述] 请输出 1. 按可能性排序的假设。 2. 每个假设需要补充的证据。 3. 最小验证步骤。 4. 不建议直接修改的地方及原因。无论测试还是排障都不要把 AI 的回答当成最终结论。它应该帮助你更快地提出假设、设计验证和发现遗漏。5. 交付与复盘你是不是每次都从零开始一个任务完成后如果所有有用信息都留在聊天记录里那么下一次做类似任务时你还是会从零开始。建议为每一次高质量协作保留 4 类资产资产应该记录什么Prompt 模板任务背景、上下文、约束和输出格式规则清单已确认业务规则、边界和验收标准测试清单正常、异常和回归场景复盘记录AI 的有效建议、遗漏点和最终修改原因可以使用这个最小复盘模板任务 [本次开发或排障任务] AI 参与的环节 [需求 / 代码阅读 / 方案 / 实现 / 测试 / 排障 / 文档] 有效做法 [哪些上下文、Prompt 或验证动作最有帮助] 无效或有风险的做法 [AI 漏掉了什么为什么不能直接采用] 可复用资产 [Prompt、检查清单、测试模板、代码片段]当这些资产积累起来你使用 AI 的效率才会变得稳定而不是偶尔碰到一次好答案。四、盘点完成后先把 AI 放到哪里盘点完工作流后不建议同时改造所有环节。先选择一个满足下面三个条件的节点重复出现。每周都会做或者每个任务都会遇到。上下文可提供。你能清楚地给出需求、代码、日志或规则。结果可验证。能通过测试、代码审查、运行结果或人工确认判断好坏。对大多数中级开发者而言适合优先尝试的顺序通常是需求澄清 ↓ 代码阅读 ↓ 测试矩阵 ↓ 代码审查 ↓ 排障假设整理 ↓ 可控范围内的代码生成这条顺序的共同特点是前面的输出更容易被人工审核风险也更低。等你形成稳定方法后再把 AI 引入更复杂的实现和自动化环节。五、今天就可以完成的一次工作流盘点不需要等到下一个大型项目。今天可以从一个正在进行的小任务开始按下面 6 步完成盘点写下任务名称例如“新增取消订单接口”或“修复优惠券金额计算 Bug”。把任务拆成需求、阅读、方案、实现、测试、交付六个环节。在每个环节标记最耗时、最模糊或最容易返工的地方。只挑一个节点让 AI 参与并记录输入和输出。用测试、代码审查、日志或联调验证结果。把有效的 Prompt 和检查清单保存下来。可以直接复制下面这份盘点清单任务名称 [填写] 本次任务经过的环节 [ ] 需求理解 [ ] 代码阅读 [ ] 方案设计 [ ] 代码实现 [ ] 测试排障 [ ] 交付沉淀 最耗时的环节 [填写] 最容易返工的环节 [填写] 本次准备让 AI 参与的一个节点 [填写] 我会提供给 AI 的上下文 [需求 / 代码 / 日志 / 测试 / 规则] 我将如何验证输出 [测试 / 审查 / 联调 / 日志 / 人工确认] 本次要沉淀的资产 [Prompt / 检查清单 / 测试模板 / 复盘]这份清单的目的不是增加流程负担。它是为了让 AI 的使用从“临时提问”变成“有目标、有上下文、有验证的工程协作”。六、总结在选择 AI 工具之前先盘点自己的开发工作流。这件事可以帮助你看清哪些环节真正消耗时间。哪些环节最容易遗漏信息和产生返工。哪些工作适合让 AI 协助哪些判断必须自己保留。怎样把一次有效协作沉淀成可复用资产。你不需要马上把整个研发流程都交给 AI。先从一个重复、可提供上下文、结果可验证的小节点开始。当 AI 真正嵌入需求澄清、代码理解、方案设计、测试排障和复盘沉淀后它才能成为开发流程的一部分而不只是一个偶尔打开的聊天窗口。下一篇文章我们来拆AI编程工作台我的 AI 编程工作台工具、模型与基础配置如果这篇文章对你有帮助欢迎点赞、收藏、关注专栏。也欢迎在评论区留言在你的日常工作中最耗时、最想让 AI 帮忙的环节是什么