ff-requirement-analysislisted

# 需求解析（ff-requirement-analysis） ## 本步目标 把用户给的任务说明，转成一份**后续所有步骤都能照着干活**的需求基线。 基线的唯一评判标准：一个没参与过对话的人，只读这份文件，就知道该做什么、做到什么程度算完。 ## 输入 - 提示词中的【任务说明】：用户原始输入，可能是完整段落，也可能是一句话。 - 工作区 `inputs/` 下的附件（若提示词列出了文件清单，逐个 Read）。 ## 处理规则 1. **区分「用户说了的」和「你推断的」**。推断必须标注 `（推断）`，不能混进事实。 2. 任务说明里的每一个名词都要落到交付物上。用户说"帮我做个能用的网站"， "能用"必须被翻译成具体的验收条目，不能留成形容词。 3. 信息不足时**不要停下来提问**。按最合理的默认值补齐，写进「假设与默认」章节， 并同步登记到「风险」里 —— 后面有人检查点会让用户看到并纠正。 4. 判定任务类型（单选，后续步骤据此切换打法）： `文档型` / `代码型` / `分析型` / `创作型` / `混合型`。 ## 产出：REQUIREMENTS.md 必须真实写入工作区文件 `REQUIREMENTS.md`，结构如下（章节标题原样保留，后续步骤按名引用）： ``` # 需求基线 ## 一句话目标 ## 任务类型 文档型 | 代码型 | 分析型 | 创作型 | 混合型 ## 交付物清单 | # | 交付物 | 形态（文件/文档/代码/图） | 判定完成的标准 | ## 范围边界 - 包含： - 明确不做： ## 约束 （时间、技术栈、篇幅、风格、受众、依赖的外部条件） ## 验收标准 - [ ] AC-1 …（可客观判定，禁止"高质量""美观"这类无法判定的措辞） - [ ] AC-2 … ## 假设与默认 | 缺失信息 | 本步采用的默认 | 若用户不认可的影响 | ## 风险 ``` ## 硬性规则 - 验收标准至少 3 条，且每条都能被非作者判定真伪。 - 「明确不做」这一节不许省略 —— 它是防止后续步骤范围膨胀的唯一闸口。 - 不要在本步产出任何交付物本身的内容。想干活的手留住，那是第 4 步的事。 ## 完成前自检 - [ ] `REQUIREMENTS.md` 已写入工作区且非空。 - [ ] 文件里每一句话，要么来自用户原话，要么带 `（推断）` 标记。 - [ ] 验收标准里没有形容词。