brief-to-prd

name	brief-to-prd
description	将一句话、几句话或一段简短业务描述扩展为结构化中文需求文档 / PRD 草案的技能。用于需求澄清、想法成稿、版本规划、功能定义、立项前梳理，或当用户只提供简短目标描述，希望输出范围、用户故事、流程、规则、验收标准、风险与待确认问题时使用。

简述转需求（中文）

快速开始

1. 先判断输入是 产品想法、版本目标、单功能需求 还是 问题陈述。
2. 从原始描述中只提取可证实事实：角色、目标、动作、对象、约束、期望结果。
3. 使用 references/brief-expansion-checklist-zh.md 补齐常见需求维度，但缺失信息一律标注 [待确认]。
4. 用 references/prd-template-zh.md 输出结构化需求文档。
5. 明确区分 原始事实、推断假设、待确认问题，禁止把猜测写成既定规则。

工作流

1) 锁定需求粒度

• 若输入描述的是整体产品方向，按“版本/产品级 PRD”输出。
• 若输入聚焦单个场景或功能，按“功能级 PRD”输出。
• 若用户只想要简版，可保留“目标、范围、流程、规则、验收”五个核心部分。

2) 从简述抽取需求种子

• 优先抽取以下元素：
  • 用户角色
  • 目标 / 要解决的问题
  • 核心动作
  • 关键对象或数据
  • 约束条件
  • 成功结果
• 若原文没有明确给出，不要补成确定结论，统一标注 [待确认]。

3) 扩展为可评审需求

• 使用 references/brief-expansion-checklist-zh.md 逐项检查：
  • 触发条件与前置条件
  • 主流程与异常流程
  • 状态变化与数据影响
  • 权限与边界规则
  • 非功能要求
  • 风险与未决问题
• 若某项只能凭经验推测，必须显式标记为 [推断]。

4) 组装输出

• 始终使用 references/prd-template-zh.md 作为输出骨架。
• 每条关键需求尽量补足：用户价值、触发方式、主流程、异常流程、业务规则、验收标准。
• 当原始信息不足时，优先输出“待确认问题列表”，不要用冗长空话填充。

5) 质量校验

• 保证结构化：阅读者能快速看出目标、范围、流程、规则、风险。
• 保证可验收：每条核心需求至少对应 1 条可测试标准。
• 保证可追溯：能区分哪些内容来自原文，哪些是合理推断。
• 保证不越界：不虚构业务指标、权限模型、接口字段、组织流程。

输出规则

• 默认输出中文 Markdown。
• 默认包含三类标识：
  • 原始事实：用户描述中直接出现的信息。
  • 推断：基于通用产品分析补出的合理假设。
  • 待确认：无法从输入稳定推出的信息。
• 如果用户只给一句话，也先输出完整草案，再附“待确认问题”。
• 如果用户明确要求“不要发散”，则只保留原始事实与最小必要结构。

参考资料

• references/prd-template-zh.md：简述转需求的标准模板
• references/brief-expansion-checklist-zh.md：从短描述扩展需求的检查清单