这节课要解决的是一个几乎所有后端工程师都会遇到的问题：需求并没有真的讲清楚，但开发动作已经开始往前推了。AI 在这个阶段最有价值的作用，不是直接替你写实现，而是先帮你把问题问对、边界看清、任务拆稳。
真实研发场景
最常见的情况不是“没有需求”，而是“需求只说了一半”
产品经理在群里发一句“月底前把知识问答加一个导出能力，最好还能支持失败重试”，研发立刻开始讨论怎么做。看起来信息不少，但真正关键的问题都还没落地：谁有导出权限、导出的是原始回答还是带引用的结果、重试是用户手动触发还是系统自动补偿、失败时要给前端什么状态、这一版到底是做同步接口还是异步任务。
如果这时工程师直接让 AI “帮我把这个需求拆一下，再顺手写个接口”，模型通常会给出一份看上去很完整的方案。但只要其中两个假设和真实业务不一致，后面的接口设计、状态流转和测试样例都会一起返工。
本课真正想训练的是“先收歧义，再拆任务”
需求阶段的正确顺序通常不是“理解一句话 -> 马上写代码”，而是：
- 把事实和假设分开
- 把未决问题显式列出来
- 把任务拆成可验收的小块
- 为每个任务绑定输入、输出和完成标准
AI 在这里的价值，就是帮助你更系统地做第 1 到第 3 步。
传统做法的痛点
需求返工最贵，因为它会污染后面的所有动作
需求阶段的偏差，往往不是在需求文档里显现出来，而是在后续每个环节里以更高成本爆发：
| 阶段 | 表面上发生了什么 | 实际损失 |
|---|---|---|
| 需求沟通 | 先按默认理解继续往下做 | 错误假设进入设计 |
| 接口设计 | 字段和状态先拍脑袋补齐 | 契约返工带动前后端一起改 |
| 编码实现 | 业务分支根据错误范围被写死 | 重构成本升高 |
| 测试联调 | 补样例时才发现条件没定 | 返工不再是局部 |
真正麻烦的不是需求“模糊”，而是团队没有把模糊点显式收口。
传统拆解经常会犯三个错误
- 把假设写成事实：例如默认所有用户都能导出，默认重试都是自动触发
- 按技术层拆，不按业务动作拆：比如直接拆成“Controller、Service、DTO、Test”，却没有先明确用户场景
- 没有完成标准：任务拆出来了，但没人知道什么叫“这个任务真的做完”
这三种错误一旦出现，AI 会把它们放大，因为模型天生倾向于补全看起来合理的空白。
AI 能提效到哪一步
AI 最适合先帮你做的是四件事
- 生成澄清问题清单：把需求里没说但必须回答的问题列出来
- 提取显式假设：告诉你哪些地方其实是模型在脑补
- 按用户场景拆任务：例如“发起导出”“查看导出状态”“失败后重试”
- 起草验收维度：输入、输出、权限、异常、边界条件
这些动作的共同点是：它们提高理解质量，但不替代拍板。
不能直接交给 AI 的，是范围和优先级
下面这些决策必须由人来定：
- 这一版到底做 MVP 还是做完整方案
- 哪些异常这次处理，哪些延后
- 哪个角色拥有操作权限
- 哪些任务可以并行，哪些必须顺序落地
一个实用规则是：AI 可以帮你把“还没问出来的问题”翻出来，但不能替你决定“这次到底做多大”。
推荐工作流
先准备一份最小事实包
在让 AI 参与需求拆解前，先准备下面这些内容：
- 需求原文或会议纪要
- 相关现有接口或代码路径
- 已知限制，例如权限、时效、兼容性、上线时间
- 当前还不确定的事项
没有这份事实包时，模型的输出大概率会把未知项自动补成“看起来合理”的默认值。
用四步把需求转成可执行任务
| 步骤 | AI 产出什么 | 人工要做什么 | 验证方式 |
|---|---|---|---|
| 1. 收歧义 | 澄清问题清单 | 标记哪些问题必须先问清 | 是否还能继续开发而不靠猜 |
| 2. 抽假设 | 假设列表 | 把假设分成“已确认 / 待确认” | 是否把假设写成事实 |
| 3. 拆任务 | 按业务动作切出的任务列表 | 合并过细项、删除无价值项 | 每个任务是否独立验收 |
| 4. 补验收 | 完成标准、输入输出、异常 | 把验收结果对齐到团队口径 | 能否据此设计接口和测试 |
推荐输入模板
需求原文：
相关代码或接口：
已知约束：
当前不确定点：
请输出：
1. 必问澄清问题
2. 已存在的隐含假设
3. 按业务动作拆分的任务清单
4. 每个任务的完成标准
这个模板的重点不在于 prompt 形式，而在于逼你先把事实、未知和目标结果分层表达。
与仓库代码和模板的映射
- 顶层主线地图：
../README.md适合先看整套课程为什么从需求理解开始，而不是直接从编码开始。 - 课程结构依据：
../课程设计文档.md这里能看到主线课程为何围绕研发动作组织。 - 示例项目定位：
../demo/README.md它说明了demo/是需求理解和任务拆解的材料库。 - 现有接口样本：
../demo/src/main/java/com/example/ainative/chat/controller/ChatController.java、../demo/src/main/java/com/example/ainative/dataassistant/controller/SqlAssistantController.java适合拿来练习“从现有接口倒推真实需求边界”。 - 对应练习：
../课后练习/第1课/练习.md
常见误用与风险
误用一：需求还没说清，就让 AI 开始写实现
这样做会把假设直接固化进代码和接口，后续返工范围最大。
误用二：让 AI 给“最终方案”，却没有先让它列问题
需求阶段最值钱的不是漂亮答案，而是高质量问题清单。
误用三：拆任务只按技术层，不按业务动作
这种拆法会让任务看起来完整，但并不能支持独立验收和并行协作。
误用四：没有把“已确认”和“待确认”分开
模型会天然补全未知项，所以工程师必须主动标记哪些是假设。
课后练习
建议直接在 ../课后练习/第1课/练习.md 中完成本课练习，并使用 ../课后练习/通用提交模板.md 保留 AI 输入、人工删改和验证结果。
如果你只做最小版交付，也至少保留四样东西：结构化输入、AI 产出摘要、人工判断记录、最终验证结果。
基础题
找一个你最近遇到过的含混需求，先不要写方案，只输出一份澄清问题清单。
进阶题
把这个需求拆成 3 到 6 个按业务动作组织的小任务，并为每个任务写完成标准。
挑战题
对照 demo/ 里的一个现有接口，反推它背后的需求边界，并补一份“还缺哪些确认”的说明。