用 AI 编程时，先定方案再动手写代码

把需求直接交给 AI 生成代码，看似省去了分析环节，却可能把尚未确认的假设迅速固化到实现中。尤其当任务涉及权限、状态、并发、性能或跨模块改动时，真正影响交付质量的往往不是编码速度，而是方案是否经得起评审。更稳妥的做法，是先让 AI 暴露问题、比较取舍并明确验收边界，再进入小范围实现。

开篇

当我们把需求交给 AI 时，最常见的一句话是：

帮我实现这个功能。

这句话当然能得到代码。

但对于中级开发者来说，真正需要警惕的不是“AI 写得慢”，而是：

• 代码已经生成了，才发现方案选错了。
• 接口写完了，才发现同步处理会阻塞请求。
• 数据库改完了，才发现没有考虑并发和幂等。
• 功能跑通了，才发现和已有模块的分层不一致。
• 测试补完了，才发现需求本身没有定义验收边界。

AI 越擅长生成代码，我们越应该把“写代码”放在正确的位置。

对于包含状态、权限、数据、性能、异步任务或跨模块改动的需求，更稳妥的顺序应该是：

理解需求
  ↓
明确假设和问题
  ↓
比较方案与风险
  ↓
确认模块边界和验收标准
  ↓
生成最小实现
  ↓
测试、审查和迭代

本文不讨论如何让 AI 一次性写出完整项目。

我们只讨论一个更可靠的协作习惯：

让 AI 先写方案，再写代码。

本文不会讨论什么

为了让“先写方案”真正服务于开发，而不是增加形式负担，本文不会：

• 要求每个小函数都先写一份长设计文档。
• 把 AI 生成的方案直接当作技术决策。
• 用复杂架构解决简单问题。
• 在业务规则还不清楚时强行进入方案设计。
• 因为有方案就跳过代码审查和测试验证。

方案不是为了显得专业。

方案的作用是让团队在投入编码前，先看清关键假设、选择和风险。

一、为什么复杂任务不能直接从代码开始

先看一个常见需求：

后台管理员可以按筛选条件导出订单。

直接让 AI 写代码时，往往会得到一个查询订单列表、生成 CSV 或 Excel、返回下载响应的接口。

但真正需要先确认的问题很多：

问题	不同选择	对实现的影响
导出数据量	小量同步 / 大量异步	是否需要任务队列和文件存储
导出格式	CSV / Excel / 多工作表	文件生成库和字段映射不同
权限范围	全部订单 / 仅所属业务线	查询条件和数据脱敏不同
字段内容	完整用户信息 / 脱敏信息	安全与合规边界不同
导出频率	无限制 / 限流 / 每日上限	防止资源被滥用
文件有效期	永久 / 临时下载	存储、清理和下载鉴权不同
失败处理	同步报错 / 任务状态可重试	接口和状态模型不同

如果这些问题没有讨论，AI 生成的代码可能在演示环境可用，但很难直接进入真实系统。

所以，复杂任务的第一轮问题不应该是：

请帮我实现订单导出功能。

而应该是：

请先分析订单导出需求的实现方案、关键假设、风险和测试点。
暂时不要写代码。

这会把“代码生成”从默认起点，变成经过确认后的实现步骤。

二、一份可执行方案，至少要回答哪 5 个问题

AI 输出的方案不必很长，但至少要帮助我们回答下面 5 个问题。

1. 要解决的业务问题是什么

先确认任务目标和本期边界。

例如：

目标：
后台管理员可以按订单创建时间和订单状态导出订单数据。

本期范围：
- 支持 CSV 格式。
- 支持订单创建时间和状态筛选。
- 仅支持具有订单管理权限的管理员。

本期不处理：
- 自定义导出字段。
- 多工作表 Excel。
- 导出结果邮件通知。

边界越清楚，方案越不会无限膨胀。

2. 有哪些可选方案，它们的取舍是什么

对订单导出而言，常见方案可能包括：

方案	特点	适用情况	主要风险
同步接口直接返回文件	实现简单、调用直接	数据量小、生成快	请求超时、占用应用线程
异步创建导出任务	用户可稍后下载	数据量大、生成耗时	需要任务状态、文件管理和清理
离线报表系统	能力更完整	报表需求复杂且频繁	引入成本和系统复杂度高

AI 可以帮助列出方案，但“采用哪个方案”需要结合真实数据量、用户体验、团队现有基础设施和上线节奏确认。

3. 需要修改哪些模块，数据如何流动

一个可评审方案应该清楚说明：

管理员发起导出
  ↓
权限与筛选参数校验
  ↓
创建导出任务
  ↓
查询订单并生成文件
  ↓
保存文件和更新任务状态
  ↓
管理员查看状态并下载

这段流程会反过来帮助我们确认：

• 是否需要新增导出任务实体。
• 是否需要异步执行器或消息队列。
• 文件存在哪里，多久清理。
• 下载时如何再次校验权限。
• 失败后是否允许重试。

4. 关键风险和异常场景是什么

方案不能只描述正常流程。

至少要提前列出：

• 筛选时间范围过大。
• 数据量过大或导出任务超时。
• 任务重复创建。
• 导出过程中订单数据发生变化。
• 文件生成失败或存储失败。
• 用户无权限下载其他人的文件。
• 文件过期后访问下载链接。

这些问题不一定都要在第一期解决。

但必须明确哪些是本期约束，哪些需要后续演进。

5. 如何验收和测试

一份方案必须能转化为验证动作。

例如：

验收点：
1. 有权限的管理员可以提交符合筛选条件的导出任务。
2. 无权限用户无法创建或下载导出文件。
3. 导出文件中的订单字段和筛选条件一致。
4. 任务失败时可以看到失败状态和原因。
5. 过期文件不可下载。
6. 重复提交请求不会产生不符合预期的重复任务。

如果方案无法说明怎样验证，它仍然只是一个抽象想法。

三、实战：先让 AI 为订单导出写方案

下面使用一条完整 Prompt，让 AI 在不写代码的前提下完成方案草稿。

1. 第一轮：复述需求并列出待确认问题

现在需要新增“后台订单导出”能力。

原始需求：
后台管理员可以按筛选条件导出订单。

项目上下文：
- 后端使用 Java + Spring Boot。
- 已有订单查询接口和订单管理权限校验。
- 已有对象存储服务，可用于保存临时文件。
- 系统已经支持异步任务执行。
- 业务错误统一使用 DomainException。

本轮要求：
1. 不写代码。
2. 复述你理解的需求。
3. 列出必须在开发前确认的问题。
4. 按业务、权限、数据量、文件、任务状态、异常与验收分类。
5. 区分已知事实、可暂时假设和必须人工确认的内容。

这一步的目标不是得到方案结论，而是先暴露不确定性。

2. 第二轮：要求 AI 比较方案与风险

确认一部分规则后，再让 AI 给出候选方案：

已确认规则：
1. 仅具有订单管理权限的管理员可以导出。
2. 仅支持 CSV 格式。
3. 单次导出可能包含较多订单，不适合同步返回文件。
4. 文件保存到现有对象存储，下载有效期为 24 小时。
5. 用户可以在导出任务列表中查看状态和下载结果。
6. 本期不支持邮件通知和自定义导出字段。

请比较至少两种实现方案。

对每种方案输出：
1. 处理流程。
2. 需要新增或修改的模块。
3. 优点和缺点。
4. 对性能、权限和失败重试的影响。
5. 推荐程度和推荐理由。

不要写代码。

此时应该得到“同步导出”和“异步任务导出”的对比，而不是一段仓促的实现。

3. 第三轮：让 AI 把选定方案变成模块设计

假设团队决定采用异步任务导出，下一轮可以继续收敛：

我们选择“异步导出任务”方案。

请设计最小可交付方案，不写完整代码。

请输出：
1. 导出任务的状态模型。
2. 需要新增或修改的类、方法和数据结构。
3. 从创建任务到下载文件的数据流。
4. 权限校验应该放在哪些步骤。
5. 幂等、并发和失败重试策略。
6. 需要补充的测试矩阵。
7. 本方案仍然存在的风险和人工确认项。

这一步得到的内容，才适合进入技术评审或开发任务拆分。

4. 第四轮：把方案转换为开发任务

方案确认后，可以让 AI 输出团队可执行的任务清单：

基于已确认的异步订单导出方案，拆分后端开发任务。

要求：
1. 按数据层、服务层、异步执行、接口层、权限、安全、测试和运维清理分类。
2. 每个任务写清目标、依赖、验收点。
3. 标出可以并行的任务。
4. 不写具体实现代码。
5. 最后给出发布前检查清单。

经过这四轮，需求已经从一句话变成：

已确认规则
  + 方案选择
  + 模块边界
  + 风险清单
  + 验收标准
  + 开发任务

现在才适合进入代码实现。

5. 第五轮：只让 AI 生成最小实现

当规则和方案已经确认后，代码请求就可以更精确：

请只实现“创建订单导出任务”的 Service 层方法。

上下文：
- 使用已存在的订单管理权限校验。
- 导出任务状态初始为 PENDING。
- 文件生成由现有异步执行器处理，本方法不生成文件。
- 使用现有 DomainException。

要求：
1. 不修改 Controller 和异步执行器。
2. 校验筛选参数和当前用户权限。
3. 创建导出任务并返回任务 ID。
4. 先说明改动点和仍需确认的假设。
5. 再给出代码与单元测试。

这时，AI 生成的代码范围小、上下文完整，审查和回滚都更容易。

四、一条“先方案后代码”的通用 Prompt

下面这份模板可以用于大多数复杂任务：

任务目标：
[要实现或修改的业务能力]

项目上下文：
[技术栈、相关模块、已有基础设施、现有规范]

已确认规则：
[业务、权限、状态、数据和安全规则]

本期范围：
[本次必须完成的内容]

本期不处理：
[明确排除的内容]

本轮交付要求：
1. 暂时不要写代码。
2. 复述任务理解。
3. 列出待确认问题和假设。
4. 给出至少两种可选方案及取舍。
5. 说明推荐方案、模块边界和数据流。
6. 列出风险、异常、并发与安全问题。
7. 输出验收标准和测试矩阵。
8. 最后将方案拆成开发任务清单。

当方案确认后，再使用第二轮实现模板：

已确认方案：
[粘贴选定方案和任务边界]

本次只实现：
[一个具体类、方法或模块]

实现约束：
[允许修改的文件、禁止修改的范围、依赖限制]

验收要求：
[测试场景、接口结果、日志或性能要求]

请先说明改动点、假设和风险，再给出最小代码实现与测试。

五、什么时候可以从方案进入代码

不要以“AI 已经生成方案”为标准开始编码。

更适合进入代码阶段的信号是：

[ ] 业务目标和本期范围已经明确。
[ ] 关键权限、状态和数据规则已经确认。
[ ] 复杂度足够高的方案已经比较过取舍。
[ ] 模块边界、调用流程和主要依赖已经清楚。
[ ] 已经列出关键异常、并发和安全风险。
[ ] 验收标准和测试场景可以实际执行。
[ ] 本次代码改动范围已经足够小且可审查。

如果其中多项仍然不明确，不要急着让 AI 写更多代码。

继续补充规则、缩小范围或确认方案，通常比以后重构更省时间。

六、总结

让 AI 先写方案，再写代码，不是多加一道形式流程。

它是在代码生成速度越来越快的情况下，保留工程判断的必要步骤。

面对复杂任务，可以按下面顺序协作：

1. 让 AI 复述需求并找出未知问题。
2. 让 AI 比较候选方案和关键取舍。
3. 确认模块边界、数据流、风险和验收标准。
4. 把选定方案拆成开发任务。
5. 最后让 AI 在明确边界内生成最小实现和测试。

请记住：

代码生成可以很快，但方案一旦错误，后面的速度只会让返工更早发生。

下一篇文章，我们继续完善开发前的判断能力：

AI 写代码前，我会让它先回答的 6 个问题。