pm-skills 的 create-prd 技能实战：用 8 段式模板写出高质量产品需求文档（PRD）-二趣网

pm-skills 的 create-prd 技能实战：用 8 段式模板写出高质量产品需求文档（PRD）

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills

导读

create-prd是 pm-execution 插件中用于生成**产品需求文档（PRD）**的核心技能，它以一套经过实战验证的 8 段式模板为骨架，把"写给谁、为什么做、做什么、怎么衡量、何时发布"等产品决策要素串成一份可直接对齐工程师、设计师与高层管理者的权威规范文档。读完本文，你将掌握该技能的完整工作流、8 个章节的撰写要点、/write-prd命令对它的编排方式，以及它与用户故事、预演（pre-mortem）、红队评审等下游技能的衔接关系，能直接在自己的 AI 编程助手工作流中产出专业级 PRD。

一、技能定位：pm-execution 插件中的 PRD 生成器

在 PM Skills Marketplace 的整体架构中，技能（Skill）是概念与框架，命令（Command）是用户触发的端到端流程（详见 CLAUDE.md 的 Key Design Rules）。create-prd正是典型的"技能"：它定义了一整套 PRD 撰写框架，Claude 等 AI 助手在对话主题与 PRD 相关时自动加载它，无需显式调用；而/write-prd命令则把这一技能编排成一条完整的交互式工作流。

该技能在仓库中的完整定义位于 pm-execution/skills/create-prd/SKILL.md，其 frontmatter 声明了触发条件：

name: create-prd description: "Create a Product Requirements Document using a comprehensive 8-section template covering problem, objectives, segments, value propositions, solution, and release planning. Use when writing a PRD, documenting product requirements, preparing a feature spec, or reviewing an existing PRD."

注意 description 中列出的四个使用场景——撰写 PRD、记录产品需求、准备功能规格（feature spec）、评审已有 PRD——这意味着该技能既可以"从零写"，也可以"评审改"。仓库的插件验证器 validate_plugins.py 会强制校验技能 frontmatter 的name与目录名一致、命令 frontmatter 必须包含description和argument-hint，保证这些触发描述在运行时可靠可用。

二、六步工作流：从输入到落盘的完整过程

create-prd的 Instructions 定义了六步执行流程，构成一个"收集 → 思考 → 套模板 → 表达 → 排版 → 存档"的闭环：

收集信息（Gather Information）：若用户提供了文件（需求简报、调研报告、策略 deck、Slack 线程、邮件），先完整阅读；若用户提及研究、URL 或客户数据，则使用网络搜索补充上下文与市场洞察。
逐步思考（Think Step by Step）：动笔前先厘清四个关键问题——我们在解决什么问题？为谁解决？如何衡量成功？有哪些约束与假设？
套用 8 段式模板（Apply the PRD Template）：按第三节详解的八个章节组织文档。
使用通俗语言（Use Accessible Language）：以小学毕业生能理解的水平写作，避免行话，使用清晰短句——这正是仓库其他技能（如user-stories）反复强调的"plain language"原则（见 pm-execution/skills/user-stories/SKILL.md）。
结构化输出（Structure Output）：以排版良好、标题清晰的 Markdown 文档呈现 PRD。
保存输出（Save the Output）：由于 PRD 篇幅可观，统一保存为PRD-[product-name].md格式的 Markdown 文件。

值得强调第 1 步与第 2 步的配合：该技能明确要求"如果用户提供了文件，仔细阅读它们"，这与/write-prd命令 Step 2 中"提取文档里已有的内容、只追问缺口"的缺口补齐策略一致，避免让用户重复提供信息。

三、8 段式 PRD 模板逐段详解

这是create-prd的核心资产。模板由 8 个章节组成，从"这是什么"一直推进到"何时发布"，逻辑链条完整：

1. Summary（摘要，2–3 句）

用两到三句话说明这份文档讲的是什么。作用是让任何读者在 30 秒内判断"这份 PRD 是否与我相关"。

2. Contacts（联系人）

列出关键干系人的姓名、角色、备注。这看似琐碎却至关重要——PRD 是多人协作的依据，缺少责任人的章节在评审时容易陷入无人认领的境地。

3. Background（背景）

回答三个递进问题：

背景：这个项目是关于什么的？
为什么是现在（Why now）？有什么发生了变化？
这是否是"最近才变得可能"的事情（例如新技术的成熟、新法规的出台、竞品动态）？

背景章节的价值在于建立"紧迫性论证"，让评审者理解项目启动的时机依据，而不是只看到一个功能清单。

4. Objective（目标）

这是"为什么做"的章节，包含四个子问题与一个关键输出：

目标是什么？为什么它重要？
它将如何使公司与客户受益？
它如何与愿景和战略对齐？
关键结果（Key Results）：如何衡量成功？要求使用SMART OKR 格式（具体、可衡量、可达成、相关、有时限）。

这里与该仓库的brainstorm-okrs技能、/plan-okrs命令形成呼应——OKR 思维贯穿 pm-execution 插件，PRD 中的关键结果可以直接作为后续团队级 OKR 的输入。

5. Market Segment(s)（市场细分）

回答"我们为谁构建"：

为谁而建？存在哪些约束？
关键原则：市场由人们的问题/任务（problems/jobs）定义，而非人口统计学特征（demographics）。

这一条直接体现了 Jobs to Be Done（JTBD）思想，与仓库内job-stories技能（"When [situation], I want to [motivation], so I can [outcome]"）、market-segments技能的方法论一脉相承。换句话说：不要写"25–40 岁的都市白领"，而要写"每周花 10 小时手工汇总报表、渴望自动化的财务分析师"。

6. Value Proposition(s)（价值主张）

回答四个问题：

我们解决哪些客户任务/需求？
客户将获得什么？
他们会避开哪些痛点（pains）？
哪些问题我们比竞争对手解决得更好？

模板特别提示考虑Value Curve（价值曲线）框架——通过对比自身与竞品在各价值要素上的表现，找到差异化空间。这与 pm-execution 之外的价值主张类技能（如 pm-product-strategy 插件的value-proposition）在方法论上同源。

7. Solution（解决方案）

解决方案章节包含四个子块：

7.1 UX/原型：线框图、用户流程图（wireframes, user flows）；
7.2 关键功能：详细的功能描述（不是一句话的功能名，而是"做什么、给谁用、边界是什么"）；
7.3 技术：可选，仅在相关时出现（避免 PRD 沦为技术方案书）；
7.4 假设（Assumptions）：我们相信但尚未验证的假设——必须显式列出，让团队知道哪些前提需要验证。

"假设"子块是整个模板中极具工程价值的一环：它把隐性风险变成显性待办，为后续的strategy-red-team红队评审和pre-mortem预演提供了明确的攻击面（详见第五节）。

8. Release（发布）

回答三个问题：

需要多长时间？
第一版包含什么，未来版本包含什么？
避免精确日期，使用相对时间框架（如"Phase 1: 6–8 周"）。

"用相对时间而非绝对日期"是一条反工程陷阱的实战规则：PRD 生命周期长于会议周期，绝对日期会在计划微调后迅速失真，而相对时间框架保持长期有效。这也是后续/write-stories命令把功能拆成"一个 sprint 内可完成的故事"的前提。

四、/write-prd 命令：如何编排 create-prd

技能定义了"怎么写"，命令定义了"怎么用"。/write-prd 的 frontmatter 如下：

description: Create a comprehensive Product Requirements Document from a feature idea or problem statement argument-hint: "<feature or problem statement>"

调用示例

/write-prd SSO support for enterprise customers /write-prd Users are dropping off during onboarding — we need to fix step 3 /write-prd [upload a brief, research doc, or strategy deck]

注意其 argument-hint 与设计意图：接受任何形式的输入——功能名（"SSO support"）、问题陈述（"企业客户一直在要求集中式认证"）、用户请求（"用户想导出 CSV 数据"）、模糊想法（"我们应该处理一下 onboarding 流失问题"）、甚至上传的文档（简报、研究报告、Slack 线程、邮件）。

四步工作流

Step 1 — 理解功能：接纳任意形式的输入，不做格式预设。

Step 2 — 收集上下文：以对话方式提问，最重要的排最前，按需补齐缺口，六个问题依次为：

用户问题：解决什么问题？谁遇到？有多痛？
目标用户：哪些细分人群？规模多大？他们当前的替代方案（workaround）是什么？
成功指标：怎么知道这成了？做对了会推动什么指标？
约束：技术约束、时间线、法规、对其他团队的依赖？
先例（Prior art）：之前尝试过吗？市场上已有解决方案？
范围偏好：完整方案还是分阶段？

若用户提供了带上下文的文档，则提取已有内容、只追问缺口——这与技能工作流第 1 步严格对应。

Step 3 — 生成 PRD：应用create-prd技能产出 8 段式文档。命令给出了可直接套用的标题骨架（含作者、日期、状态、干系人头部信息），并额外强化了目标章节（Goals / Non-Goals / Success Metrics 表）和需求章节（P0/P1/P2 用户故事与验收标准表）。

Step 4 — 评审与迭代：生成后主动提供后续动作，例如：

"要我收紧范围吗？我可以挑战哪些 P1 其实应该是 P2。"
"要对这份 PRD跑一次 pre-mortem吗？"
"要我拆成用户故事给工程团队吗？"
"要我生成干系人更新来同步这份文档吗？"

最后把 PRD 保存为 Markdown 文件到用户工作区。

五、与上下游技能的协同：从 PRD 到交付

create-prd不是孤立的。从仓库的 pm-execution/README.md 可以看到它身处一个完整的"执行"技能生态，PRD 落盘后通常流向以下三处：

拆解为可交付故事：/write-stories 命令从 PRD 中提取需求，按用户故事（User Stories，3 C's + INVEST）、工作故事（Job Stories）或 WWA（Why-What-Acceptance）三种格式拆成 5–15 个独立故事，每个故事附带 3–5 条验收标准，并为 P0/P1/P2 排序——恰好对应 PRD 模板 Solution 章节的功能描述。
红队攻击假设：strategy-red-team 技能专门"攻击承重假设"（load-bearing assumptions）：它从 PRD 中提取每条主张，区分"若为假则计划死亡"的承重假设与装饰性假设，把每个失败模式写成可证伪的"Fails if ___"，再按"影响 × 可能性 × 测试成本"排序，为每条给出本周要拿到的证据与 kill criteria——直接消费 PRD 第 7.4 节的假设清单。
发布前预演：pre-mortem 技能假设产品在 14 天后发布并失败，倒推风险，把风险分类为 Tigers（真实风险）、Paper Tigers（被夸大的担忧）、Elephants（没人明说的隐忧），并仅对 Launch-Blocking（发布阻塞）级别的风险输出"风险 → 缓解措施 → 负责人 → 截止日期"的行动计划——正好接住 PRD Release 章节的发布规划。

这种"PRD 生成 → 故事拆解 → 假设攻击 → 发布预演"的链路，正是命令"完成后建议下一个命令"设计哲学的体现：工作流互相衔接，跟着提示走即可。

六、写作纪律与质量底线（Notes）

create-prd的 Notes 部分是整套模板的质量守门员，也是评审 PRD 时的检查清单：

尽可能具体、以数据驱动：泛泛的"改善体验"没有信息量，可衡量的目标才有价值。/write-prd 命令对此给出了对照范例：""improve NPS" 是糟糕的写法，"increase NPS from 32 to 45 within 90 days of launch"才是合格的指标"。
把每个章节与整体战略挂钩：PRD 不是孤岛，每个决策都要能回指公司战略与产品愿景。
显式标记假设，让团队去验证——这正是第五节所述红队与预演得以展开的前提。
保持简洁但完整（concise but complete）：控制篇幅不是删减信息，而是剔除重复与无关内容。

七、可复现的实战路径

要在自己的 AI 编程助手中复现这条 PRD 工作流，步骤如下：

安装插件：将pm-execution插件安装到 Claude Code（claude plugin install pm-execution@pm-skills）或通过 Cowork 的插件市场添加phuryn/pm-skills（安装细节见 README.md 的 Installation 一节）；该技能对其他支持通用 SKILL.md 格式的助手同样可用。
触发技能：直接输入/write-prd <功能或问题陈述>，或在对话中描述 PRD 撰写需求以自动加载create-prd技能。
按 8 段模板产出并保存：以PRD-[product-name].md命名保存。
按第五节链路继续：需要时依次执行/write-stories、strategy-red-team、pre-mortem完成拆解、攻击与预演。
遵循仓库规范：若你修改了仓库内技能或命令，需运行 validate_plugins.py 校验 frontmatter、名称一致性及命令→技能引用（详见 CLAUDE.md 的 Operational Procedures），并在 README 与 marketplace.json 中同步数量与版本号。

小结

create-prd的价值不在于"生成一份长文档"，而在于用 8 段式模板把问题定义、目标衡量、市场细分、价值主张、解决方案、发布规划这六类决策强制前置到写作过程中，并通过通俗语言要求与假设显式化，让 PRD 真正成为对齐各方、指导开发、可被挑战的权威规格。配合/write-prd的交互式编排与用户故事、红队、预演等下游技能，它构成了 pm-execution 插件中最完整的"想法 → 规格 → 交付"转化通道。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析