PRD 生成器

中文简介

PRD 生成器：把想法、研究材料或会议纪要转成可审查、可实现、可测试的产品定义。它先界定要支持的决策和问题证据，再切分 MVP；不会把愿望清单、会议发言或未验证假设伪装成已确认需求。

使用背景

在团队需要决定为谁解决什么问题、首版做到哪里、工程如何验收以及如何衡量结果时使用。产出用于产品、设计、工程、数据和业务的共同决策，并可作为 prototype-brief-builder 或 spec-to-implementation-plan 的上游输入。

核心原则

先定义问题、用户和要支持的决策，再写方案与功能；产品想法本身不是需求证据。
每条材料都标注为 [事实]、[证据]、[假设]、[推断] 或 [待确认]；不因来源是会议纪要而自动变成事实。
MVP 是验证一个最小可行结果的范围，不是把所有提议缩短描述后一起上线；每个纳入项都要回答“不做会阻断什么”。
需求描述可观察行为和边界条件，验收标准覆盖默认、空、加载、错误、权限/资格和成功状态。
指标必须有事件、属性、触发点、口径和负责人；没有基线时明确为未知，不虚构目标。
未决问题、依赖、风险和决策必须可追溯到负责人、截止时间或触发条件。

适用场景

将一句话产品想法改写成问题假设、最小验证范围和需补齐的输入，而非虚构完整 PRD。
将访谈、反馈、指标、竞品调研或会议纪要整理为有证据边界的 MVP PRD。
在功能很多、时间或团队容量有限时，明确首版、后续候选和非目标，并记录取舍。
为已有方向补足功能/非功能需求、界面状态、埋点、验收、依赖、风险和决策日志。

不适用场景

需要发现问题或收集一手用户证据；先用 feature-discovery-interviewer 或 user-feedback-synthesizer。
需要在多个已定义机会间排序或规划容量；使用 roadmap-prioritizer，不要把排序伪装成 PRD。
需要设计 A/B、灰度或假门实验的样本与停止规则；使用 experiment-designer。
要求承诺日期、成本或技术方案，却没有工程评估和依赖信息；只能记录候选与待确认项。

输入要求

先收集以下内容；未知内容可以留空，但必须标为 [待确认]：

要支持的决策、业务/产品目标、截止时间和不可触碰的限制。
目标用户、分群边界、使用情境、JTBD、当前做法与问题后果。
输入材料及来源：研究、反馈、数据、纪要、原型、既有需求或决策；保留日期和可定位出处。
候选范围、已知非目标、平台、合规/隐私、容量、依赖和已有技术决策。
成功信号、现有埋点/指标口径、基线、发布和支持约束。

信息不足时的处理

只有一句话想法： 不编造用户、痛点、基线或收益。输出问题假设卡、最小可验证 MVP、非目标、待确认问题和下一步研究/数据动作；完整 PRD 标记为条件草案。
只有会议纪要： 为每一项发言保留来源、发言人或记录位置与日期；将承诺、偏好、事实和推断分开，冲突事项进入决策日志，不能凭纪要补全需求。
目标或用户不清： 先问最少关键问题：要支持什么决定、谁在何种情境中受影响、成功怎样被观察。不能等待时，仅给出带标签的候选范围。
指标或基线缺失： 定义测量方式、事件和需补取的数据；不写任意百分比目标，也不宣称会提升某指标。
要求把所有想法放进 MVP： 明确拒绝无边界范围。按核心结果、依赖、风险和可延后性切分为 MVP、后续候选和非目标，并说明每个排除项何时重审。

工作流

建立 PRD 卡。 固定决策、目标、用户/JTBD、限制、来源清单、已知范围和未知项；先写本轮不解决什么。
整理证据账本。 给每条输入标注类型、来源/日期、支持何种判断、置信度和限制；区分直接证据与产品推断。
定义问题与结果。 写出用户在具体情境中为完成 JTBD 的现状、替代方案、成本/风险和预期结果；把方案名称从问题陈述中移除。
切分 MVP。 以最小可验证用户结果为中心，逐项判断是否阻断核心路径、是否有依赖、是否可在后续学习后再决定；明确 MVP、后续候选与非目标。
编写需求与状态。 将 MVP 拆成可观察的功能需求、非功能需求和体验状态；为每个核心流程指定默认、空、加载、错误、权限/资格和成功/完成处理。
定义测量与验收。 为可衡量的行为写事件、属性、触发点、口径、负责人和护栏；为核心需求写 Given/When/Then 验收标准及异常状态。
暴露交付条件。 记录依赖、负责人、最晚确认时间、风险、缓解措施、开放问题和不可逆决策；把冲突或取舍写入决策日志。
执行质量门槛。 使用 references/checklists.md 检查后再交付；不满足输入或验收条件时，交付缺口与下一步，而不是假装工程就绪。

专业判断规则

问题、用户与 JTBD

用“当 [用户/分群] 在 [情境] 想要 [进展/JTBD] 时，当前通过 [替代方案]，因此承担 [可观察成本/风险]”描述问题；不要写“用户需要一个 AI 功能”。
用户、情境、频率、影响或替代方案不明时均为 [待确认]。将“应该做”“很重要”“会节省时间”保留为发言或假设，直到有可定位证据。
问题陈述、业务目标和方案分开：问题说明摩擦，目标说明希望观察到的结果，方案说明候选做法；三者不能互相证明。

证据分级与会议纪要

标签	可写内容	不能据此断言
`[事实]`	已提供且可核对的系统状态、已发布能力、明确约束	未提供的因果、用户动机或未来结果。
`[证据]`	有来源/日期的访谈行为、反馈摘录、指标、研究结论	未覆盖分群的比例、总体优先级或因果。
`[假设]`	尚待验证的用户、价值、可行性或商业前提	已确认需求、收益或上线承诺。
`[推断]`	基于列明证据的有限产品解释	原始事实或所有用户的结论。
`[待确认]`	会改变范围、验收或发布决定的缺口/冲突	可忽略的小细节。

会议纪要中的“我希望”“客户会要”“应该支持”默认是提议或偏好。只有明确负责人、决定、时间和出处的结论才可登记为已决；矛盾意见必须保留争议和决策人。
证据强度按可定位性、与目标分群/情境的匹配、近期性、方法可信度和反例/冲突判断为强/中/弱；弱证据可启发研究，不足以锁定 MVP。

MVP、后续候选与非目标

为每个候选项问四件事：它是否直接完成核心 JTBD、缺失是否阻断首版学习或用户结果、是否是前置依赖、是否能在获得首轮反馈后再决定。
只有满足核心结果或不可替代依赖的项进入 MVP。可替代的便利性、扩展渠道、自动化边角、广泛配置、复杂权限模型和未验证集成默认进入后续候选，除非证据证明它们阻断核心路径。
非目标要写明不做什么、为何不做、替代处理、何时重审。不要把“以后再说”当非目标。
用户坚持全部纳入时，保留其完整愿望清单作为候选池，但交付一个有边界的推荐 MVP 和拒绝/延后理由；范围争议交由具名决策人，不在 PRD 中悄悄扩大。

需求、状态与验收

功能需求使用“在 [前置条件] 下，用户可以/系统必须 [可观察行为]，并产生 [可验证结果]”。每条标注优先级、理由、证据/假设、依赖和验收 ID。
每条核心功能需求使用 FR-* → ST-* → EV-* → AC-* 追溯链：需求表引用状态、埋点和验收 ID；状态表、埋点表和验收表都反向引用需求 ID。非功能需求至少引用已定义的 AC-*，不适用的状态或埋点必须写明原因。
非功能需求仅写可验证约束，例如响应时间的测量点、可用性目标的时间窗、权限模型、数据保留、审计、可访问性或兼容平台；不写“快速”“安全”“易用”等形容词。
每个核心界面/接口至少评估：默认、空、加载、错误、权限/资格、成功/完成。若状态不适用，写明原因，不能遗漏。
验收标准必须由独立 QA 或工程人员观察。至少覆盖主路径、输入校验、异常/恢复、权限/资格和关键埋点；将“体验好”“智能推荐”改写为可断言结果。

指标、依赖、风险与决策

指标区分结果指标、过程指标和护栏指标；每个指标写公式/口径、分子分母或事件定义、时间窗、分群、基线、目标/阈值和数据负责人。基线未知时写补数计划。
事件命名不是埋点完成：每个事件还要列触发时机、必要属性、去重/失败处理、数据消费者与验证方式。
依赖按团队/系统/数据/合规/供应商分类，记录负责人、所需输入、最晚确认时间、阻塞影响和替代方案。
风险区分发生可能性和影响；缓解不是“关注”，而是明确预防、监控、触发阈值、应对人和回滚/降级动作。
决策日志记录日期、决策、备选项、依据、影响范围、负责人和重审条件；开放问题必须有 owner 与截止时间，否则就是隐藏风险。

输出契约

按 references/templates.md 输出，并至少包含：

PRD 卡：决策、范围、目标、用户/JTBD、限制、输入来源与未知项。
证据与假设账本：标签、来源/日期、强弱、限制、影响的判断和下一步。
问题陈述、目标、成功信号、MVP/后续候选/非目标及其取舍理由。
功能、非功能和状态需求表；每条核心需求都有可测试验收标准。
埋点与指标规格：事件、属性、触发点、口径、基线/阈值、护栏和负责人。
依赖、风险、开放问题和决策日志；明确阻塞条件、责任人和时间。
信息不足时的条件草案：不得补写事实，必须列出完成 PRD 前的最小下一步。

质量门槛

不交付没有目标用户、情境、JTBD 或当前替代方案的问题陈述，除非整体标为条件草案。
不将纪要、偏好、预期收益或弱证据写为已确认事实或硬性需求。
不交付没有明确 MVP、后续候选与非目标的范围，也不把所有想法归入首版。
不交付缺少默认、空、加载、错误、权限/资格或成功状态判断的核心流程。
不交付不能被 QA 观察、不能被数据验证或没有失败处理的核心需求和指标。
不交付没有负责人/时点的依赖、开放问题或关键决策；交付前运行 references/checklists.md。

常见失败与修正

失败	修正
只有“一句话想法”却写出完整用户画像和收益数字	输出问题假设卡与最小验证范围，将用户、频率、基线和收益标为待确认。
将会议纪要中的每条诉求写成需求	建立来源账本，区分决定、偏好、证据和冲突，并让具名决策人确认范围。
为了照顾所有人把所有功能放入 MVP	保留候选池，按核心结果、阻断性、依赖和可延后性切分；写出非目标和重审条件。
写“快速、智能、无缝、安全”	改成测量点、阈值、权限规则、失败处理和可观察验收。
只写成功主路径	为每个核心流程补充默认、空、加载、错误、权限/资格和完成状态，或说明不适用原因。
指标只有名称或目标数字	追加事件、属性、触发点、公式、时间窗、基线、护栏、验证和负责人。

参考资料

references/usage-guide.zh.md：调用准备、信息不足时的交付方式和下游衔接。
references/templates.md：PRD 卡、证据账本、范围、需求、埋点、风险和决策日志模板。
references/checklists.md：输入、证据、范围、状态、验收与交接质量门槛。
references/examples.md：一句话想法、会议纪要和无边界 MVP 的合格处理示例。

prd-builder

SKILL.mdprd-builder/SKILL.md