- name
- sdd-requirements-normalizer
- description
- 将零散、模糊、非标准化的产品需求转化为符合 Spec Driven Development（SDD）模式的 requirement 文档，用于原型设计、方案评审与后续实现。适用于产品经理、设计师或创业者提供聊天记录、会议纪要、功能想法、PRD、截图、口头描述或半成品需求时，需要快速整理出包含目标、范围、用户流程、交互规则、布局要求、状态、边界情况和验收标准的结构化文档。
SDD Requirements Normalizer
概述
将模糊的产品意图整理成适合原型产出的 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”等词，进一步提高这一部分的细化程度。
默认文档结构
除非用户明确要求其他格式，否则按以下顺序组织文档：
- 需求说明（需求目标 / 目标用户与使用场景 / 范围定义）
- 功能列表（表格，含功能名称、概述、适用角色、优先级、父记录）
- 功能详细说明（核心用户流程 / 交互要求 / 布局与结构要求 / 状态与边界情况）
- 原型生成要求（组件库 / 主题色 / 响应式适配 / 通用交互要求）
- 验收标准
- 待确认问题 / 默认假设
质量标准
定稿前，检查文档是否满足以下要求：
- 不需要额外开会解释，也能直接驱动原型制作
- 明确写出了用户动作和系统反馈
- 清楚说明了每个主要界面区块承载什么内容
- 能区分“本期必须有”和“可选延伸项”
- 暴露了模糊点，而不是把模糊点藏起来
- 保持足够简洁，便于产品和设计快速评审
参考资料
- 使用
references/sdd-requirements-template.md作为默认输出模板。 - 使用
references/interaction-layout-checklist.md补强 UX、交互和布局细节。 - 使用
references/design-foundations.md确认组件库、主题色和响应式规则。