将模糊的需求描述转化为结构化输入，使其可以直接用于 AI 辅助设计和开发。这是工作流的第一步——输入质量决定所有后续输出质量。
什么时候用
拿到一个需求，但它还是”想要 X 功能”这种形式，而不是”实现 X，满足 Y，不做 Z”。把模糊描述变成结构化输入之后，再进入设计或开发。
使用需求管理工具时：/req:new 命令已内置需求结构化引导，优先使用该命令，不需要手动触发此提示。
准备什么
- 原始需求：来自产品、用户或会议记录的原始文字描述，完整粘贴，不要提前整理
原始描述越完整越好——整理过的描述可能已经丢失了 AI 需要的信息。
怎么触发
单次任务
先读 04-prompt/workflow/requirement-structuring.md，
原始需求：[完整粘贴原始描述]。
请转化为结构化格式，信息不足的地方列出待澄清问题，不要自行假设填写。
输出格式
结构化后的需求应包含以下字段，每个字段必须有明确内容，不能留空或写”待定”：
| 字段 | 内容 |
|---|---|
| 目标 | 一句话，这个需求期望达成什么用户或业务目标 |
| 背景 | 为什么现在要做，触发场景是什么 |
| 功能描述 | 具体要做什么，尽量具体到交互或数据变化 |
| 约束 | 技术限制、兼容性要求、不能做的事 |
| 验收标准 | 3-5 条可测试的完成判定条件 |
| 排除范围 | 明确这次不做什么，避免范围蔓延 |
| 依赖 | 依赖哪些模块、服务或数据 |
好的输出是什么样的
- 每个字段都有具体内容，没有”待定”或”看情况”
- 验收标准是可测试的，而不是”用户体验好”这类主观描述
- 信息不足时，列出具体的待澄清问题，而不是自行假设
- 排除范围明确写了”这次不做 X”，防止开发时范围蔓延
验收标准的可测试性检查：能不能写一个测试用例来验证它？不能的话，它还不够具体。
常见失败模式
- 自行填假设：某个字段信息不足，AI 填了一个”合理”的内容而不是提问。结果到开发完了才发现理解错了。要求 AI 对不确定的信息先提问
- 验收标准太模糊：”页面加载快”——这不是验收标准。要求每条标准都能回答”怎么算做到了”
- 排除范围是空的：没有明确排除范围，开发时容易把相关功能一起做了。需求评审时主动问”这次不做什么”
版本历史
- v1.0：初始版本
- v1.1：增加”排除范围”字段，解决 AI 生成方案时频繁超出需求范围的问题