文章目录开篇本文不会讨论什么一、原始需求为什么不能直接进入编码二、先给 AI 什么信息才能开始拆需求三、用 AI 把模糊需求拆成 5 类问题1. 业务规则收藏到底代表什么2. 权限与状态谁能做什么情况下能做3. 数据与接口规则如何变成可交付的契约4. 异常与幂等哪些“失败”其实不该让用户失败5. 开发任务与测试把规则变成团队可执行清单四、完整 Prompt让 AI 输出需求拆解和任务清单五、需求拆解后如何判断这份任务清单能不能开工六、总结✍创作者全栈弄潮儿²⁰²⁶ 个人主页全栈弄潮儿²⁰²⁶ 专栏地址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 个问题进行检查规则明确了吗团队是否知道每个关键业务动作的预期结果边界列出来了吗重复请求、对象不存在、状态变化和越权是否有定义接口能联调吗输入、输出、分页、异常和状态字段是否足够明确数据能支撑规则吗唯一约束、查询索引和数据保留策略是否已经考虑任务能验收吗每项任务是否都有可以测试或评审的完成标准风险有归属吗哪些问题需要产品确认哪些由后端、前端或测试负责你可以在评审前直接复制这份清单[ ] 已确认核心业务规则和本期范围。 [ ] 已列出未确认问题并指定确认人。 [ ] 已定义权限、状态、异常和幂等策略。 [ ] 已确认接口输入、输出、分页和错误约定。 [ ] 已检查数据模型、唯一约束和并发风险。 [ ] 已拆分数据层、服务层、接口层和测试任务。 [ ] 每个任务都有验收点、依赖和负责人。 [ ] 已明确发布前需要验证的关键路径。如果这些问题大多还没有答案说明当前更适合继续澄清而不是开始编码。六、总结AI 在需求阶段最有价值的能力不是替你决定业务而是帮助你把隐含问题提前显性化。面对一句模糊需求可以按下面 5 步使用 AI先让 AI 列出未知问题不要直接写代码。把问题分成业务、权限、数据、接口、异常和一致性维度。与产品、业务和团队确认关键规则。再让 AI 把规则转换为接口、任务和测试清单。用验收点和发布前检查表确认任务是否可以开工。从“收到需求就写代码”变成“先拆清楚再实现”看起来多了一步。但它通常能减少后期需求变更、接口返工和遗漏边界带来的成本。下一篇文章我们进入编码前最关键的一步让 AI 先写方案再写代码。如果这篇文章对你有帮助欢迎点赞、收藏、关注专栏。也欢迎在评论区留言你最近遇到过哪一句“看起来简单、拆开却很复杂”的需求✍坚持原创求关注点赞收藏