选 AI 工具之前，先梳理你的开发工作流

AI 能迅速生成代码，却未必能解决需求模糊、调用链不清、测试遗漏和反复返工等问题。若研发流程本身缺少明确输入、产出与验证标准，更强的模型也可能只是把风险推向后续环节。要让 AI 真正提升开发效率，需要先梳理日常工作流，再确定它适合参与的位置。

开篇

开始使用 AI 编程后，很多开发者最常问的问题是：

• 哪个 AI 工具更适合写代码？
• 哪个模型生成代码更准确？
• 有没有万能 Prompt？
• 用什么插件能自动帮我完成更多事情？

这些问题当然有价值。

但如果还没有梳理过自己的开发流程，即使换了更强的工具，也很容易陷入下面的状态：

• 需求来了，仍然不知道应该先问 AI 什么。
• 代码生成很快，测试、联调和排错却越来越乱。
• 只在写代码时打开 AI，真正耗时的需求澄清、阅读旧代码和排障却没有改善。
• 每次对话结束后，没有留下可复用的模板、清单和经验。

所以，在继续研究“用哪个 AI”之前，我们先解决一个更基础的问题：

你的日常开发时间，究竟花在了哪些环节？哪些环节适合让 AI 参与？

本文不会做工具横评，也不会推荐某一个模型。

我们要做的是盘点一条真实的开发工作流，找到 AI 最值得介入的节点，并建立一套可验证的协作方式。

本文不会讨论什么

为了让这篇文章保持聚焦，下面这些内容不会展开：

• 不比较不同 AI 工具的能力排名。
• 不推荐“复制即可使用”的万能 Prompt。
• 不把 AI 生成代码等同于功能交付。
• 不用工具数量衡量开发效率。
• 不鼓励在不了解项目的情况下让 AI 大范围改代码。

本文只讨论一件事：

先看清自己的研发流程，再决定把 AI 放到哪里。

一、为什么不要一开始就问“用哪个 AI”

工具只是能力的放大器，不会自动修复混乱的流程。

如果你的工作方式是：

收到需求
  ↓
边问边写
  ↓
出了问题再查
  ↓
临近交付时补测试

那么即使 AI 帮你更快地产出代码，也可能只是更快地把不确定性带到后面。

例如，下面这句提问很常见：

帮我实现一个订单金额计算功能。

它看起来像是“让 AI 写代码”，但真正缺少的信息非常多：

• 商品价格和数量是否合法？
• 优惠券是否可以超过商品总价？
• 金额按元还是按分保存？
• 运费、税费、会员折扣是否在本次范围内？
• 错误应该抛异常，还是返回业务错误码？
• 这段逻辑应该放在 Controller、Service 还是领域层？

如果这些问题没有在流程前面解决，换任何 AI 都不会让结果可靠。

所以，第一步不是选工具，而是识别：

1. 哪个环节最耗时。
2. 哪个环节信息最不完整。
3. 哪个环节最容易返工。
4. 哪个环节的结果最容易验证。

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. 测试和排障：你是不是只在出错后才想到 AI

AI 很适合参与测试设计和问题排查，但它需要的是证据，而不只是错误信息。

对于测试，可以让 AI 先列矩阵：

请为下面的订单金额计算规则设计测试矩阵。

规则：
[粘贴已确认规则]

请按“正常、边界、异常”三类输出：
- 输入
- 预期结果
- 覆盖规则
- 测试目的

暂时不要生成测试代码。

对于排障，可以让 AI 先组织假设：

请协助分析一个接口偶发失败的问题。

已知信息：
- 问题现象：[描述]
- 完整错误栈：[粘贴]
- 最近代码变更：[描述]
- 已排除方向：[描述]

请输出：
1. 按可能性排序的假设。
2. 每个假设需要补充的证据。
3. 最小验证步骤。
4. 不建议直接修改的地方及原因。

无论测试还是排障，都不要把 AI 的回答当成最终结论。

它应该帮助你更快地提出假设、设计验证和发现遗漏。

5. 交付与复盘：你是不是每次都从零开始

一个任务完成后，如果所有有用信息都留在聊天记录里，那么下一次做类似任务时，你还是会从零开始。

建议为每一次高质量协作保留 4 类资产：

资产	应该记录什么
Prompt 模板	任务背景、上下文、约束和输出格式
规则清单	已确认业务规则、边界和验收标准
测试清单	正常、异常和回归场景
复盘记录	AI 的有效建议、遗漏点和最终修改原因

可以使用这个最小复盘模板：

任务：
[本次开发或排障任务]

AI 参与的环节：
[需求 / 代码阅读 / 方案 / 实现 / 测试 / 排障 / 文档]

有效做法：
[哪些上下文、Prompt 或验证动作最有帮助]

无效或有风险的做法：
[AI 漏掉了什么，为什么不能直接采用]

可复用资产：
[Prompt、检查清单、测试模板、代码片段]

当这些资产积累起来，你使用 AI 的效率才会变得稳定，而不是偶尔碰到一次好答案。

四、盘点完成后，先把 AI 放到哪里

盘点完工作流后，不建议同时改造所有环节。

先选择一个满足下面三个条件的节点：

1. 重复出现。 每周都会做，或者每个任务都会遇到。
2. 上下文可提供。 你能清楚地给出需求、代码、日志或规则。
3. 结果可验证。 能通过测试、代码审查、运行结果或人工确认判断好坏。

对大多数中级开发者而言，适合优先尝试的顺序通常是：

需求澄清
  ↓
代码阅读
  ↓
测试矩阵
  ↓
代码审查
  ↓
排障假设整理
  ↓
可控范围内的代码生成

这条顺序的共同特点是：前面的输出更容易被人工审核，风险也更低。

等你形成稳定方法后，再把 AI 引入更复杂的实现和自动化环节。

五、今天就可以完成的一次工作流盘点

不需要等到下一个大型项目。

今天可以从一个正在进行的小任务开始，按下面 6 步完成盘点：

1. 写下任务名称，例如“新增取消订单接口”或“修复优惠券金额计算 Bug”。
2. 把任务拆成需求、阅读、方案、实现、测试、交付六个环节。
3. 在每个环节标记最耗时、最模糊或最容易返工的地方。
4. 只挑一个节点，让 AI 参与并记录输入和输出。
5. 用测试、代码审查、日志或联调验证结果。
6. 把有效的 Prompt 和检查清单保存下来。

可以直接复制下面这份盘点清单：

任务名称：
[填写]

本次任务经过的环节：
[ ] 需求理解
[ ] 代码阅读
[ ] 方案设计
[ ] 代码实现
[ ] 测试排障
[ ] 交付沉淀

最耗时的环节：
[填写]

最容易返工的环节：
[填写]

本次准备让 AI 参与的一个节点：
[填写]

我会提供给 AI 的上下文：
[需求 / 代码 / 日志 / 测试 / 规则]

我将如何验证输出：
[测试 / 审查 / 联调 / 日志 / 人工确认]

本次要沉淀的资产：
[Prompt / 检查清单 / 测试模板 / 复盘]

这份清单的目的不是增加流程负担。

它是为了让 AI 的使用从“临时提问”变成“有目标、有上下文、有验证的工程协作”。

六、总结

在选择 AI 工具之前，先盘点自己的开发工作流。

这件事可以帮助你看清：

1. 哪些环节真正消耗时间。
2. 哪些环节最容易遗漏信息和产生返工。
3. 哪些工作适合让 AI 协助，哪些判断必须自己保留。
4. 怎样把一次有效协作沉淀成可复用资产。

你不需要马上把整个研发流程都交给 AI。

先从一个重复、可提供上下文、结果可验证的小节点开始。

当 AI 真正嵌入需求澄清、代码理解、方案设计、测试排障和复盘沉淀后，它才能成为开发流程的一部分，而不只是一个偶尔打开的聊天窗口。

下一篇文章，我们来拆AI编程工作台：

我的 AI 编程工作台：工具、模型与基础配置