需求转PRD

要解决的问题

需求评审里最常见的事故，不是功能做不出来，而是开发拿到几句话的描述就开始动工。PM 在群里写一句「用户希望扫码后能直接预览报告」，工程师理解为「扫完码跳转到报告页面」，测试同学却按「报告全文渲染」准备用例。三方各自脑补，验收阶段再对齐，返工成本很高。

这类需求通常有两种形态：一是零散记录，散落在聊天记录、会议纪要、工单里；二是方案型需求，提出方已经画好了按钮和流程，却没说清楚用户是谁、在什么场景下、遇到什么问题、达到什么结果才算解决。

需求转PRD 就是处理这类原料的工具：把不完整的输入整理成结构化的需求分析文档和 PRD。

技能如何工作

核心能力分三层：

• 需求分析：先对输入做澄清，识别缺失的角色、场景和约束，而不是把原始记录直接排版成文档。
• EARS/GWT 表达：需求语句按 EARS（Easy Approach to Requirements Syntax）句式重写，场景用 GWT（Given-When-Then）描述，让每条需求可验证。
• 结构化输出：产出包含优先级和验收标准的需求文档，避免「优化体验」「提升效率」这类无法测试的措辞。

关键步骤大致是：收集原始需求 → 提取角色与场景 → 重写为 EARS/GWT 语句 → 标注优先级 → 生成验收标准 → 汇总成 PRD。技能会分步索要字段，而不是一次性生成后再反复推翻。

适用边界与注意点

• 输入质量决定输出质量。原始记录若连用户角色都缺失，技能只能提出澄清问题，不会凭空补全。
• EARS/GWT 约束的是表达形式，不是需求本身的正确性。验收标准写得再形式化，也替代不了业务目标的确认。
• 方案型需求要警惕「方案伪装成需求」。技能会尝试剥离已给定的实现细节，但最终取舍仍需人工判断。
• 涉及合规、安全、性能指标的专业领域需求不在其覆盖范围内，那些需要领域专家介入。