sdd-requirements-normalizer

将零散、模糊、非标准化的产品需求转化为符合 Spec Driven Development（SDD）模式的 requirement 文档，用于原型设计、方案评审与后续实现。适用于产品经理、设计师或创业者提供聊天记录、会议纪要、功能想法、PRD、截图、口头描述或半成品需求时，需要快速整理出包含目标、范围、用户流程、交互规则、布局要求、状态、边界情况和验收标准的结构化文档。

概述

将模糊的产品意图整理成适合原型产出的 requirement 文档。 主动补强交互行为、页面或模块布局、状态反馈与 UX 约束，避免关键内容停留在“默认理解”或“口头约定”层面。

工作流程

1. 规范化原始输入

• 从混杂输入中提取真实需求：目标、痛点、关键对象、动作、限制条件、示例和隐含预期。
• 区分“已知事实”和“合理假设”。
• 推断需求对应的产品载体：页面、流程、仪表盘、表单、弹窗、引导、设置页、详情页、移动端页面或组件集合。
• 在能帮助理解业务语义时，保留用户原有术语。

2. 有意识地补齐关键缺口

• 如果合理假设可以推动产出，不要因为“信息不完整”就停止。
• 对缺失信息补充明确假设，例如主要用户、设备场景、入口、空状态、成功标准等。
• 将假设统一记录在 待确认问题 / 默认假设 小节中，保证文档可继续评审和迭代。
• 只有在某个选择会显著改变原型方向时，才需要向用户升级确认。

3. 强化交互与布局要求

• 将模糊描述转写为明确的交互规则。
• 重点补足：
  • 用户入口与触发方式
  • 页面或模块层级
  • 主操作与次操作
  • 状态切换
  • 校验与错误处理
  • 响应式或自适应布局预期
  • 视觉优先级与信息密度
• 当原始需求对 UX、结构或页面构成描述不足时，读取 references/interaction-layout-checklist.md 补全细节。

4. 产出符合 SDD 风格的 requirement 文档

• 使用 references/sdd-requirements-template.md 作为默认文档结构。
• 在描述布局和视觉要求时，读取 references/design-foundations.md 确保组件库、主题色、响应式规则与项目约定一致。
• 优先服务原型产出：文档要足够清晰，能直接用于 Figma、线框图、UI 生成或前端搭建。
• 优先写简洁、明确的要求，不写冗长叙述。
• 需求应描述“可观察结果”，而不是臆测技术实现方式。

输出规则

• 默认输出中文文档。
• 除非用户明确要求英文或双语，否则标题、正文、字段名、验收标准、假设说明均使用中文。
• 可以保留必要的英文产品术语，但优先给出中文表达，必要时在括号中补充英文。
• 无论信息多少，都要产出一份完整的 requirement 文档，即使部分章节较短。
• 文档必须包含：
  • 需求说明（目标、用户、范围）
  • 功能列表（表格形式）
  • 功能详细说明（流程、交互、布局、状态）
  • 原型生成要求（组件库、主题色、响应式适配、通用交互）
  • 验收标准
  • 待确认问题 / 默认假设
• 优先使用标题和项目符号，不写大段空泛文字。
• 只有在确有必要时才使用 MUST / SHOULD 等措辞，否则直接写清要求即可。
• 除非用户明确要求，不要展开技术实现细节。
• 避免使用“更直观”“更现代”“更友好”“更好用”这类空泛词，除非后面紧跟具体定义。

中文输出约定

• 优先输出适合产品、设计、原型协作的中文 requirement 文档，而不是工程实现说明。
• 标题尽量简洁明确，例如：产品目标、目标用户、核心流程、交互要求、布局要求、状态与异常、验收标准。
• 对交互和布局的描述要具体，避免使用“体验更好”“更清晰”“更现代”这类抽象表述。
• 如果原始输入本身是中文，尽量沿用用户已有术语；如果原始输入中英混合，统一成便于团队评审的中文口径。
• 如果输出面向原型工具或设计稿，可在小节中补充“页面区块建议”“组件建议”“布局建议”，但不要写成代码实现方案。

交互与布局强化重点

当原始需求信息不足时，优先补强以下内容，因为它们最直接影响原型质量：

• 信息层级：用户第一眼、第二眼、最后才需要看到什么。
• 页面构成：顶部、导航、筛选区、内容区、表单区、表格区、卡片区、面板区、底部、固定区等。
• 操作布局：主 CTA 放在哪里，哪些内容需要始终可见，哪些操作可以收进次级菜单。
• 交互反馈：悬停、按下、选中、加载、成功、空状态、禁用、校验失败、危险操作确认等。
• 流程连续性：保存、取消、返回、重试、提交、报错恢复之后各自发生什么。
• 响应式表现：在更小屏幕上，哪些内容要折叠、堆叠、隐藏、滚动或转为弹层。
• 信息密度与扫读方式：何时适合卡片、表格、列表或分栏结构。

如果请求中出现“prototype”“wireframe”“页面”“原型”“交互”“布局”“dashboard”“form”“workflow”等词，进一步提高这一部分的细化程度。

默认文档结构

除非用户明确要求其他格式，否则按以下顺序组织文档：

1. 需求说明（需求目标 / 目标用户与使用场景 / 范围定义）
2. 功能列表（表格，含功能名称、概述、适用角色、优先级、父记录）
3. 功能详细说明（核心用户流程 / 交互要求 / 布局与结构要求 / 状态与边界情况）
4. 原型生成要求（组件库 / 主题色 / 响应式适配 / 通用交互要求）
5. 验收标准
6. 待确认问题 / 默认假设

质量标准

定稿前，检查文档是否满足以下要求：

• 不需要额外开会解释，也能直接驱动原型制作
• 明确写出了用户动作和系统反馈
• 清楚说明了每个主要界面区块承载什么内容
• 能区分“本期必须有”和“可选延伸项”
• 暴露了模糊点，而不是把模糊点藏起来
• 保持足够简洁，便于产品和设计快速评审

参考资料

• 使用 references/sdd-requirements-template.md 作为默认输出模板。
• 使用 references/interaction-layout-checklist.md 补强 UX、交互和布局细节。
• 使用 references/design-foundations.md 确认组件库、主题色和响应式规则。