deliver-prd

产品需求文档（PRD）

产品需求文档是用于说明要构建什么以及为什么要构建的主要规范文档。它通过提供明确的需求、成功标准和范围边界，弥合问题理解与工程实现之间的差距。一份优秀的 PRD 能帮助工程团队构建正确的产品，同时在实现细节上保持灵活性。

适用场景

• 问题和解决方案达成一致后、工程工作开始前
• 为交接而明确功能、史诗或产品计划时
• 多个团队需要协作交付同一成果时
• 利益相关者需要在投入资源前审批范围时
• 开发和 QA 期间作为参考文档

不适用场景

• 问题尚未明确或存在争议 -> 请先使用 define-problem-statement；PRD 以问题已达成共识为前提
• 需要一页式方案来帮助利益相关者就某种方法达成一致 -> 使用 develop-solution-brief；PRD 应在达成一致后编写
• 只需要将工作拆分为一个冲刺周期中的工单 -> 使用 deliver-user-stories
• 正在记录技术或架构决策 -> 使用 develop-adr

说明

收到创建 PRD 的请求时，请按以下步骤执行：

1. 概述问题 先简要回顾要解决的问题。如果有问题陈述，请链接到该文档。确保读者在深入了解要构建的内容之前，先理解这项工作的意义。

2. 定义目标和成功指标 说明成功的标准。提供具体、可衡量的指标，并注明基线和目标值。这些指标应与要解决的问题直接相关。

3. 概述解决方案 从较高层面描述拟议的解决方案。重点说明面向用户的功能和关键能力。提供足够的细节，让利益相关者能够评估方案，同时避免过度限定实现方式。

4. 详细说明功能需求 拆解系统必须执行的操作。使用用户故事或需求陈述。每项需求都应可测试——应能验证其是否满足。

5. 将 AI 行为与证据关联 （仅当功能的输出来自模型时） 对于确定性功能，完全跳过此步骤。确定性检查可判断的属性（例如是否存在必填字段，或数量是否匹配），不会仅仅因为输出由模型生成就使功能适用此步骤；应在步骤 4 中将其列为普通需求。模型生成输出时，行为会因每次运行而异，因此“功能有效”这一说法需要附上证据。列出本次发布必须具备的行为，并针对每项行为说明如何证明其成立，以及案例必须满足什么规则才能通过；这些内容必须在运行前确定。拒答和弃答应分别列出，因为模型对这两者都没有可靠的默认行为；当功能不应作答时，它会如何处理是需求，而非实现细节。对于多步骤功能，应分别评估各个组件，因为端到端通过率会掩盖具体失败的步骤。应说明案例集的规模是如何确定的，说明方法即可，切勿照搬其他案例的数字。

   由于同一案例可能一次运行通过、下次运行失败，模板建议说明每个案例在生产设置下运行的次数，以及如何判定案例通过。模板还建议加入两项容易遗漏的内容。当模型读取的内容既未被产品指令要求遵循，也未被用户要求遵循时，该内容属于数据，绝不能视为指令。当输出展示给生成该输出所用访问权限的主体以外的人时，不得将其提供给访问权限低于内容来源的任何人。诸如“90% 的回答忠实于其来源”这类比例，只能通过精心设计的抽样来验证；在抽样方案建立之前，应保留该比例并将其验证状态标记为未解决，同时将每个案例的通过规则作为补充证据。

6. 定义范围边界 明确说明哪些内容属于范围内、哪些不属于范围内，以及哪些内容将推迟到后续迭代。清晰的范围有助于防止范围蔓延，并设定切合实际的预期。

7. 说明技术注意事项 记录可能存在的技术限制、架构决策或集成要求。不要设计系统，但要指出工程团队需要了解的注意事项。

8. 编写 Agent 执行契约 (仅当执行者将在缺少作者上下文的情况下实现此方案时) 如果实现者参与了讨论，则完全跳过此步骤。编码 Agent、外部承包商或临时接手的团队无法推断你已经掌握的信息，因此请明确说明：哪些来源具有权威性，以及两个来源不一致时以哪个为准；哪些内容不得触碰及其原因；每项 FR-n 如何验证、由谁验证；以及在什么情况下执行者必须停止并升级处理，而不是自行决定。为每项升级指定负责人；没有接收对象的升级只会变成猜测。没有验证方式的需求尚未准备好交接，因为无法区分“已完成”和“执行者认为已完成”。

9. 确定依赖项和风险 列出可能影响交付的外部依赖项、假设和风险。适用时，请附上缓解策略。

10. 提出时间线和里程碑 概述关键阶段和检查点。这有助于利益相关者了解交付计划，同时避免过早承诺具体日期。

项目记忆契约

仅当 .claude/pm-skills.local.md 存在时启用。若没有此文件，则完全忽略本节 并严格按照上述说明操作。

• 读取： active_initiative，以及记录用户画像或研究发现的任何 interpretation 产物。使用这些内容，而不要再次询问已提供过的上下文。如果没有此类内容，则照常提问，绝不要为了填补空缺而虚构用户画像。
• 写入： 将 PRD 作为 decision 产物，并将其已确定的范围边界和成功指标写入 ## Decisions 部分。
• 操作方式： 提出要写入的内容并等待确认后再写入，除非设置了 memory_auto_append: true；若已设置，则追加内容并回显所写内容。
• 写入规范： 写入前立即重新读取文件，切勿使用生成提案时读取的副本。如果文件在此期间发生变更，请将你的条目合并到当前状态并重新提出，而不是覆盖文件；只添加你自己的条目，并确保其他所有字段和部分的字节内容保持不变。运行时没有任何机制会强制执行此规范，而且该文件被 Git 忽略，因此草率地重写整个文件会丢失其他会话的工作，且无法恢复。

这是演示循环中的读取环节：如果 discover-interview-synthesis 已经记录了用户画像，就不要再要求用户提供一次。

输出格式

使用 references/TEMPLATE.md 中的模板来组织输出。完整的 PRD 应填写模板中的每个部分：概述；目标与成功指标；用户故事；范围；解决方案设计；技术注意事项；依赖项与风险；时间线与里程碑；待解决问题；附录（存在支持材料时）；AI 行为与评估（当功能的输出来自模型时）；以及 Agent 执行契约（当执行者将在缺少作者上下文的情况下实现此方案时）。

最后三项按设计有条件地适用。如果功能不需要某个部分，PRD 省略该部分仍算完整；如果包含了空白部分，则不算完整。

质量检查清单

定稿前，请确认：

• 清楚阐述了问题以及“为什么是现在”
• 成功指标具体且可衡量
• 明确界定了范围边界（包含／不包含／未来）
• 需求可测试且没有歧义
• 提出了技术考量，但没有过度具体化
• 记录了依赖项和风险，并明确了负责人
• 文档可在 15 分钟内读完
• 如果输出来自模型：每项行为需求都有相应评估和通过规则，并且涵盖拒绝和弃答
• 如果评估集按规模划分：每个切片的最低要求都说明了所承诺的覆盖范围及该切片值得获得此覆盖的原因，且不会将任何切片结果报告为失败率或失败率的上限
• 如果执行者将在没有编写上下文的情况下实现方案：每项 FR-n 都有验证方法和验证者，且每个升级处理条件都明确了负责人

示例

请参阅 references/EXAMPLE.md 查看完整示例。