借助 AI 拆解真实需求：把模糊描述转成开发任务清单

作者：袖梨 2026-09-15

产品需求常常只有一句话，但一句话并不足以支撑可靠的实现。以商品收藏功能为例，登录限制、重复操作、商品状态、列表规则和并发一致性都会影响最终设计。与其立刻让 AI 生成代码，更合适的做法是先借助它暴露待确认问题，再把业务结论逐层转化为接口、数据、测试与交付任务。

开篇

产品同学给出一句需求：

用户可以收藏商品，并在个人中心查看收藏列表。

这看起来像一个很简单的功能。

很多开发者会马上想到：

建一张收藏表。
增加收藏和取消收藏接口。
增加收藏列表接口。
前端放一个收藏按钮。

然后开始写代码。

但真正进入开发后，问题通常会一个接一个出现：

未登录用户能不能收藏？
同一个商品重复收藏，应该报错还是幂等成功？
商品下架或删除后，收藏列表如何展示？
收藏列表按什么排序，是否分页？
用户取消收藏时，目标记录不存在怎么办？
商品是否需要记录收藏数量？
如果要记录，计数如何避免并发不一致？
是否允许收藏自己的商品，还是所有商品都一样处理？

这些问题不是“实现细节”，而是需求的一部分。

如果没有在开发前暴露出来，AI 即使快速生成了接口和数据表，也只是在替我们更快地把模糊需求写成代码。

这篇文章不讨论如何让 AI 一次性生成完整模块。

我们要实践的是：

如何让 AI 帮我们把一句模糊需求，拆成一份可确认、可开发、可测试的任务清单。

本文不会讨论什么

在开始前，先明确本文的边界：

不会把 AI 的建议当成最终业务规则。
不会直接给出生产环境可复制的完整代码。
不会假设所有项目都应该使用同一种表结构。
不会忽略权限、幂等、数据一致性和异常场景。
不会跳过产品、业务和开发者之间的确认过程。

AI 在需求拆解阶段最有价值的角色，是帮助我们发现遗漏、整理问题和生成可讨论的候选方案。

最终规则仍然需要由真正负责业务和交付的人确认。

一、原始需求为什么不能直接进入编码

先看这句原始需求：

用户可以收藏商品，并在个人中心查看收藏列表。

它只表达了一个用户意图，却没有定义实现所需的关键事实。

如果直接让 AI 写代码：

请用 Java + Spring Boot 实现商品收藏功能，
包括收藏、取消收藏和收藏列表接口。

AI 可能会生成 Controller、Service、Repository 和表结构。

但下面这些问题仍然会被默认假设填满：

问题	可能的不同答案	不确认的风险
收藏身份	必须登录 / 游客可收藏	权限和数据归属不一致
重复收藏	报错 / 幂等成功	前端重试和用户体验不一致
商品状态	下架可保留 / 不展示 / 自动移除	列表结果与业务预期不一致
列表排序	收藏时间倒序 / 商品热度 / 手动排序	接口结果不可验收
取消不存在收藏	报错 / 幂等成功	客户端重试逻辑不稳定
收藏数量	不维护 / 实时统计 / 异步计数	性能与一致性方案不同

可以把需求拆解理解为一个转换过程：

用户的一句话
  ↓
待确认的业务问题
  ↓
可执行的业务规则
  ↓
接口、数据和状态设计
  ↓
开发任务与测试场景

AI 不负责替我们跳过这条链路。

它应该帮助我们更快地走完这条链路。

二、先给 AI 什么信息，才能开始拆需求

不要只把原始需求发给 AI。

第一轮的目标不是拿到答案，而是让 AI 区分“已知事实”和“未知问题”。

下面是本次示例的最小上下文：

原始需求：
用户可以收藏商品，并在个人中心查看收藏列表。

项目背景：
- 后端使用 Java + Spring Boot。
- 用户必须登录后才能访问个人中心。
- 商品模块已经存在，商品状态包括上架、下架、删除。
- 当前不涉及前端设计，只拆后端和接口任务。
- 业务错误统一使用 DomainException。

本轮要求：
1. 不要写代码。
2. 列出需求中需要确认的问题。
3. 按“业务规则、权限、数据、接口、异常、性能与一致性”分类。
4. 区分必须在开发前确认和可以暂时假设的内容。
5. 不确定的地方不要自行决定。

这段 Prompt 的关键不在于角色设定，而在于它明确限制了 AI 的任务：

不写代码
  ↓
先找问题
  ↓
按工程维度分类
  ↓
标出不确定性

这样得到的不是一份看似完整的实现，而是一张需要与产品、业务和团队确认的清单。

三、用 AI 把模糊需求拆成 5 类问题

下面以这个收藏需求为例，演示第一轮拆解应该得到什么。

1. 业务规则：收藏到底代表什么

先让 AI 聚焦业务语义：

基于“用户可以收藏商品，并在个人中心查看收藏列表”这条需求，
请只列出需要确认的业务规则。

要求：
1. 不讨论技术实现。
2. 每个问题说明：为什么需要确认、不同答案会造成什么差异。
3. 优先列出会影响用户体验和数据含义的问题。

这类问题通常包括：

待确认问题	推荐先确认的原因
一个用户能否收藏同一个商品多次	决定唯一性和接口幂等策略
收藏后商品下架，是否仍展示在列表中	决定查询条件和用户预期
商品删除后，收藏记录如何处理	决定数据保留和展示策略
是否需要收藏夹分组、备注或排序	决定数据模型是否需要预留字段
收藏数量是否是业务指标	决定是否维护计数和更新方式

在本文的示例中，先约定以下规则：

1. 用户必须登录后才能收藏商品。
2. 同一用户对同一商品只能有一条收藏记录。
3. 重复收藏视为幂等成功，返回当前收藏状态。
4. 已下架商品保留在收藏列表中，并标记为不可购买。
5. 已删除商品不在收藏列表中展示。
6. 本期不支持收藏夹分组、备注和手动排序。
7. 本期不维护商品收藏数。

注意：这些规则不是 AI 自动给出的标准答案，而是示例中的业务决策。

2. 权限与状态：谁能做，什么情况下能做

收藏功能表面上只有“添加”和“取消”两个动作，但仍然涉及权限和状态判断。

可以继续要求 AI 进行状态分析：

请基于以下已确认规则，分析商品收藏功能中的权限与状态问题。

[粘贴已确认规则]

请输出：
1. 每个操作的执行主体。
2. 操作前需要校验的对象和状态。
3. 不允许执行时应该返回的业务结果。
4. 可能被遗漏的并发或越权场景。

可以得到一份更容易评审的规则表：

操作	执行主体	前置校验	结果
收藏商品	已登录用户	商品存在且未删除	创建或返回已有收藏
取消收藏	已登录用户	收藏记录属于当前用户	删除或幂等返回成功
查看收藏列表	已登录用户	用户身份有效	仅返回当前用户收藏
查看下架商品	已登录用户	商品未删除	返回商品，但标记不可购买

这里有一个容易忽略的点：

“取消收藏”不能只按收藏记录 ID 删除，还必须确认记录属于当前用户。

否则就会产生越权删除问题。

3. 数据与接口：规则如何变成可交付的契约

规则确认后，再让 AI 协助提出数据和接口草案。

基于以下业务规则，为商品收藏功能设计最小的数据模型和接口契约。

约束：
- 后端为 Java + Spring Boot。
- 商品表已存在，本期不新增收藏数量字段。
- 不讨论具体 ORM 或 SQL。
- 不要给出完整代码。

请输出：
1. 收藏记录需要保存的字段及用途。
2. 建议的唯一性约束。
3. 收藏、取消收藏、查询列表三个接口的输入和输出。
4. 分页、排序和商品状态的返回规则。
5. 需要人工确认的接口细节。

在本文约定下，可以形成以下最小模型：

字段	作用
id	收藏记录标识
user_id	收藏所属用户
product_id	被收藏商品
created_at	收藏时间，用于默认排序

最重要的约束是：

user_id + product_id 唯一

它既表达了“同一用户同一商品只能收藏一次”的规则，也能在并发请求时帮助数据库维持最终一致性。

接口草案可以先定为：

接口	目的	关键输入	关键输出
`POST /products/{productId}/favorite`	收藏商品	当前登录用户、商品 ID	当前收藏状态、收藏时间
`DELETE /products/{productId}/favorite`	取消收藏	当前登录用户、商品 ID	操作结果
`GET /me/favorites`	查询收藏列表	分页参数	商品信息、商品状态、收藏时间

这里不急着确定所有字段的名称。

更重要的是确认：调用方需要什么、接口必须保障什么、异常情况如何表达。

4. 异常与幂等：哪些“失败”其实不该让用户失败

AI 特别适合帮助我们列出异常和边界场景。

可以这样提问：

请为商品收藏功能设计异常和幂等场景清单。

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

请按“用户输入、权限、数据状态、重复请求、并发请求、查询结果”分类。
每一项包含：触发条件、预期行为、是否需要返回错误。

下面是本例中需要重点确认的场景：

场景	预期行为	是否报错
未登录收藏	拒绝访问	是
商品不存在	不创建收藏	是
商品已删除	不创建收藏	是
重复收藏	返回当前收藏状态	否，幂等成功
取消不存在的收藏	返回成功	否，幂等成功
重复取消	返回成功	否，幂等成功
并发收藏同一商品	最终只保留一条记录	否，结果一致
收藏列表为空	返回空分页结果	否

为什么这里要把重复收藏和重复取消定义为成功？

因为用户可能重复点击，客户端可能超时重试，网络也可能造成请求重复到达。

如果每一次重复操作都返回错误，调用方需要额外处理很多不必要的分支。

当然，是否采用幂等成功仍然是业务决策。

AI 的价值是把这个决策提前暴露出来。

5. 开发任务与测试：把规则变成团队可执行清单

当规则、接口和异常都确认后，才适合让 AI 输出开发任务。

请把下面的商品收藏功能规则拆成后端开发任务清单。

[粘贴已确认规则、接口草案和异常策略]

要求：
1. 按“数据层、领域/服务层、接口层、测试、文档与联调”分类。
2. 每个任务写清目标、依赖和验收点。
3. 标出可以并行的任务。
4. 不写具体实现代码。
5. 最后列出发布前检查项。

一个可执行的任务清单，应该接近下面这样：

分类	任务	验收点
数据层	创建收藏记录表或实体映射	包含用户、商品、创建时间和唯一约束
数据层	增加按用户查询收藏列表能力	支持分页与收藏时间倒序
服务层	实现收藏商品逻辑	校验商品状态，重复收藏幂等
服务层	实现取消收藏逻辑	只能删除当前用户自己的记录，重复取消幂等
接口层	增加收藏、取消、列表接口	参数、鉴权和响应符合接口契约
测试	覆盖正常、权限、状态、重复和并发场景	关键规则有自动化测试
联调	确认下架、删除商品的列表展示	前后端对状态字段含义一致
文档	更新接口说明和异常约定	调用方可据此实现和排查

到这一步，原始需求才真正从“一句话”变成了团队可以开始开发的工作包。

四、完整 Prompt：让 AI 输出需求拆解和任务清单

下面这段 Prompt 可以作为类似需求的起点：

原始需求：
用户可以收藏商品，并在个人中心查看收藏列表。

项目背景：
- 后端使用 Java + Spring Boot。
- 用户必须登录后才能访问个人中心。
- 商品模块已经存在，商品状态包括上架、下架、删除。
- 业务错误统一使用 DomainException。
- 本次只拆后端和接口任务，不讨论前端视觉设计。

已确认规则：
1. 用户必须登录后才能收藏商品。
2. 同一用户对同一商品只能有一条收藏记录。
3. 重复收藏视为幂等成功。
4. 已下架商品保留在收藏列表中，并标记不可购买。
5. 已删除商品不在列表中展示。
6. 取消不存在的收藏视为幂等成功。
7. 本期不支持收藏夹分组、备注、手动排序和商品收藏数。

本轮交付要求：
1. 不写代码。
2. 复述需求和已确认规则。
3. 列出仍需人工确认的问题，并说明影响。
4. 输出权限与状态规则表。
5. 设计最小数据模型和唯一性约束。
6. 输出收藏、取消收藏、收藏列表的接口契约。
7. 列出异常、幂等和并发场景。
8. 按数据层、服务层、接口层、测试、联调和文档拆分任务。
9. 每个任务给出验收点和依赖关系。
10. 最后输出发布前检查清单。

实际使用时，不要因为 AI 给出了一份清单，就马上开始开发。

建议按下面顺序完成确认：

AI 输出待确认问题
  ↓
产品和业务确认规则
  ↓
开发者确认系统边界和技术约束
  ↓
AI 根据确认结果生成任务清单
  ↓
团队评审任务、依赖和验收点
  ↓
进入实现与测试

这样使用 AI，才能避免把“需求不清”直接转换成“代码复杂”。

五、需求拆解后，如何判断这份任务清单能不能开工

拿到 AI 生成的任务清单后，可以用下面 6 个问题进行检查：

规则明确了吗？ 团队是否知道每个关键业务动作的预期结果？
边界列出来了吗？ 重复请求、对象不存在、状态变化和越权是否有定义？
接口能联调吗？ 输入、输出、分页、异常和状态字段是否足够明确？
数据能支撑规则吗？ 唯一约束、查询索引和数据保留策略是否已经考虑？
任务能验收吗？ 每项任务是否都有可以测试或评审的完成标准？
风险有归属吗？ 哪些问题需要产品确认，哪些由后端、前端或测试负责？

你可以在评审前直接复制这份清单：

[ ] 已确认核心业务规则和本期范围。
[ ] 已列出未确认问题，并指定确认人。
[ ] 已定义权限、状态、异常和幂等策略。
[ ] 已确认接口输入、输出、分页和错误约定。
[ ] 已检查数据模型、唯一约束和并发风险。
[ ] 已拆分数据层、服务层、接口层和测试任务。
[ ] 每个任务都有验收点、依赖和负责人。
[ ] 已明确发布前需要验证的关键路径。

如果这些问题大多还没有答案，说明当前更适合继续澄清，而不是开始编码。