authoring-prd

authoring-prd — SKILL.md

变体： standard · 使用时机： 根据产品创意编写（或修订）全面的 PRD，达到下游构建工作可据此规划的质量标准。

概述

此技能讲解如何撰写出色、全面的产品需求文档（Product Requirements Document），重点在于撰写者应如何判断，而不是列出章节清单。它假设有两位协作者：一个提供章节 结构 的 PRD 模板工具，以及一种深度研究能力，用于为各章节提供证据依据。撰写者会收到一份产品创意（以及任何上游背景文档），并必须将其详细阐述为 PRD——绝不输出泛泛的套话。达标标准是：最终 PRD 可用于规划——工程师能够据此制定里程碑和任务。此技能与 reviewing-prd 使用同一套标准：第 5 步的自检就是评审者的 12 项条件标准，因此作者和评审者不会各行其是。

何时启用

• 根据产品创意或简报编写新的 PRD。
• 将简略的创意扩展为全面的需求文档（产品或重要功能）。
• 修订现有 PRD，以版本化增量的形式记录（新增或变更需求、范围调整）——参见第 6 步。
• 使用经过研究、决策完备的内容填写 PRD 模板。

不要在以下情况启用：

• 评审或评分已完成的 PRD → 使用 reviewing-prd。
• 编写其他类型的文档（功能规格、技术设计、运行手册、线框图）→ 使用对应文档类型的技能。PRD 说明是什么 + 为什么；如何实现则由下游的功能规格（逐项说明功能行为）和技术设计（工程设计）阐述。
• 只需一行说明，或无需需求文档的微小改动。

输入

阅读项目创意以及计划交给你的所有文档——即你的 depends_on 集合（由前期探索环节放在上游的任何分析文档，例如问题陈述、市场／竞争对手分析、商业论证或用户研究）——并以这些内容为 PRD 提供依据。不要假设输入固定不变：此技能列出的典型上游材料只是方法指引，并不限制你可能收到的内容。务必做到内容自足——根据你实际收到的任何背景信息撰写文档；如果缺少预期的参考文档，就基于现有信息继续，并将缺口明确列为假设，切勿捏造内容来填补。在条件允许时使用研究能力（深度研究），使文档内容全面详尽，而不只是填满模板。修订时，现有 PRD 和变更请求也属于输入（第 6 步）。

能力上下文（如有提供）： 如果调用方注入了 capability_record（来自 capability-map.yaml product_capabilities 的记录），请在第 1 步之前阅读。它定义了你的范围边界：owns = 你负责覆盖的实体；refs = 你会引用但不负责的实体；publishes/consumes = 你会说明的事件；entry_points/exit_points = 用户进入和离开的方式；has_ui/has_api/has_persistence = 适用的界面。若存在此记录，将其视为硬性约束——不得超出它定义的边界。

工作流程

第 1 步：从模板工具获取结构——不要自行编造大纲

从 PRD 模板工具获取章节结构（全面版）。此处不要重述或重新推导章节清单；本技能提供的是如何妥善填写这些章节的方法。如果没有可用模板，就获取一套全面的 PRD 结构（请求提供或自行构建，或者采用标准 PRD 章节集合），然后继续。

如果注入了所有能力记录（product_capabilities 列表）：将当前有效的 L1 能力列表用作 PRD 的范围骨架——每项能力对应一个章节。根据分类中的 archetype.primary 和 domain.primary 确定框架。

Step 2: 加载想法和上下文；命名产品类型；发现信息缺口

阅读产品想法和所有上游上下文。命名产品类型——消费级 / B2B 企业级 / 内部工具 / 平台 API / 数据与机器学习 / 受监管领域——因为这会决定哪些章节更重要（参见 references/archetype-and-amend.md）。起草前，填补知识缺口——找出核心问题、成功指标、用户和约束方面有哪些未知之处，并设法解决（提问、调研或明确说明假设）。每个章节的内容都必须基于这个想法及其用户，而不是套用通用模板。想法不够具体时，必须明确说明假设，不能默默套用通用内容。如果连核心问题都无法可信地假设出来，就停止起草，并提出 Step-5 中针对想法过于单薄的阻碍。

Step 3: 开展调研，为各章节提供依据

深入调研，为问题、用户、市场与竞争环境以及指标基线提供证据依据。在关键处引用来源。调研这个想法所属的具体领域，而不是“PRD 通论”。如果没有可用的调研能力，切勿捏造证据或引用——将问题、用户和指标明确标注为假设，并列在“构建前验证”部分。

第 4 步：按章节方法填写

按照以下方法填写模板各章节：

• 问题 — 以痛点的证据开篇（数据、研究、信号）；指出谁有这个痛点，以及目前为此付出的代价。将问题表述为待完成的任务（“当 [情境] 时，我想要 [动机]，以便 [结果]”），让问题基于真实任务，而不是预设某项功能。断言一个未经证实的问题，是 PRD 最常见的失败原因。
• 目标与成功指标 — 设定 2–4 个可衡量的结果；每项都要有目标和衡量方法／跟踪埋点，并在构建前定义。将先行指标（投入）与滞后指标（结果）配对；如果某项核心指标容易被操纵或可能损害其他方面，则指定一项护栏／反向指标。使用框架（North Star／OKR／HEART／AARRR）选出合适的少数指标——框架是工具，不是交付物。提供几条精炼的要点，而不是堆砌指标。（深度说明：references/nfr-and-metrics.md。）
• 用户与用户画像 — 提供具体的用户画像，并说明其真实需求和使用场景；编写用户故事（“作为……，我想要……，以便……”）。
• 范围：MVP 与非目标 — 将首发必备项与后续事项分开；明确说明非目标和发布标准。“范围外／不会实现”清单是防止范围蔓延的主要护栏（必要时可设置功能预算／时间限制）。使用 RICE／MoSCoW／Kano 等方法辅助排序，并说明排序依据。
• 需求 — 包括功能需求（可测试，以用户视角描述）和非功能需求；将后者归入明确命名的分类体系，每个关键类别都要有可量化／可检查的目标：性能（p95 延迟、吞吐量）、可用性／可靠性（SLO）、安全、隐私／数据处理、无障碍（最低达到 WCAG 2.2 AA）、可扩展性、可维护性、兼容性、本地化／国际化、合规性——具体要求应与产品类型相称（有意采用尽力而为的非功能需求时，可以注明）。 （分类体系与量化标准：references/nfr-and-metrics.md。）
• 用户故事与验收标准 — 每个故事都要附带验收标准（Given/When/Then 或基于规则），以便独立测试是否“完成”。
• 可追溯性 — 保持完整链路：每项功能都能追溯到一个目标；每个目标至少对应一项功能；每项指标都关联一个目标；每个故事都有验收标准。采用轻量级敏捷方法（简短矩阵），无需笨重的 RTM 工具。不得有无关联的功能，也不得有未对应功能的目标。
• 依赖项 — 将跨团队及外部依赖项（服务、数据、第三方、所需审批）作为单独事项列出；这些依赖项会影响后续排期。
• 风险 — 评估可能性／影响并制定缓解措施；进行简短的事前验尸（“如果 6 个月后失败了，原因会是什么？”），以此明确潜在问题。
• 假设、未决问题、决策日志 — 明确列出未知事项；对于持续更新的 PRD，记录关键决策（内容／时间／原因）。
• 跨职能就绪情况（按需提供的辅助内容，非必需章节） — 提示进行可行性审批，并根据产品类型考虑 GTM／发布／支持／分析。只纳入该产品类型需要的内容——不要给每份 PRD 都硬加 GTM 章节。
• 贯穿各部分的要求 — 面向跨职能读者，使用精准、无行话且无歧义的语言；每个实体只使用一个名称。

步骤 5：交接前根据可规划性标准进行自检

确认以下所有适用条件均已满足（这与 reviewing-prd 所要求的 12 项标准相同）：

1. 有证据支持的问题——有证据（或明确标注的假设）支持，并以用户要完成的任务来表述；不是直接断言。
2. 明确的用户——至少明确主要用户角色及其具体需求。
3. 可衡量的成功——提供 2–4 项指标，每项都有目标值和衡量方法；如果主要指标显然可以通过损害已陈述目标的方式被操纵，则设立一道护栏指标。
4. 合理的 MVP 边界——明确范围内与范围外/非目标事项，以及发布标准。
5. 具体的功能——功能及其验收标准足够具体，能够据此制定里程碑/任务。
6. 有依据，而非臆测（不编造）——问题和指标以证据为依据；明确标注假设并列入“构建前验证”；不编造数字。
7. 风险、依赖项上下文和待解决问题均已提出——不予隐瞒。
8. 清晰且无歧义——避免行话，术语一致；不以模糊的形容词代替需求。
9. NFR 分类——包含该原型中起关键作用的 NFR 类别，且每项都有可量化/可检查的目标（或注明尽力而为）。
10. 可追溯——没有孤立功能；每个目标都有对应功能；指标与目标相关联；用户故事包含验收标准。
11. 列明依赖项——提出跨团队/外部依赖项及签核要求（或注明“无”）。
12. 修订完整性（修订时）——见步骤 6。

信息不足的想法门槛：如果无法用证据支持核心问题，甚至无法对其作出可信假设，应将其列为阻碍项（“想法过于单薄，无法编写具体规格——需要先进行探索”），而不是用假设粉饰。

步骤 6：将现有 PRD 修订为有版本记录的增量变更（迭代时）

当输入是现有 PRD 加上一项变更（而非从零开始的新想法）时：

• 界定变更范围——说明本次修订涉及哪些内容，以及明确不涉及哪些内容。
• 原地编辑，不要重写——只更改受影响的需求/目标/指标/范围条目；不要重新生成整个 PRD（重新生成会丢失来源信息，并可能造成悄无声息的偏移）。
• 版本号 + 变更日志——更新 PRD 自身的文档版本；添加变更历史条目，说明谁在何时提出了请求、变更内容和原因。
• 标记已被取代的内容——明确标记过时的需求/指标已被取代（并说明原因），而不是悄悄删除。
• 分析影响范围——追踪变更的影响范围：哪些验收标准、指标、其他需求及下游文档（feature-spec、technical-design）现已过时。列出受影响项（或说明“对下游无影响”并给出原因），以免追溯链条断裂。

（完整的修订流程：references/archetype-and-amend.md。）

规则

硬性规则（绝不违反）：

• 为问题提供证据。 没有证据或明确标注的假设时，绝不声称问题存在。
• 指标必须可衡量。 每个成功指标都必须有目标值和衡量方法；拒绝虚荣指标或不可衡量的目标。如果主要指标容易被操纵，则添加护栏指标。
• NFR 必须有数值目标。 关键的非功能需求必须明确量化目标；“应该很快／安全”不算需求。
• 避免含糊表述。 将主观词语（“快”“直观”“简单”“可扩展”）替换为可量化的基准（例如，“p95 < 200ms”“≤ 3 次点击完成任务”）。
• 绝不捏造证据。 不要编造统计数据、调查数字或引文。无来源的说法应标注为明确标注的假设，并注明“构建前验证”。编造数字比坦诚地说明假设更糟。
• 明确 MVP 边界。 始终说明范围内、延后处理和非目标事项。不要把所有内容都塞进“MVP”。
• 为用户故事制定验收标准。 没有可核验验收标准的用户故事不算完成。
• 保持链路可追溯。 每个目标至少对应一个功能，不得出现孤立功能。
• 组合，而非重复。 使用模板工具的章节结构；本技能负责填充内容。
• 展开给定想法。 PRD 的具体内容必须来自想法和研究，不能是通用套话。
• 修订，而非重写。 修改现有 PRD 时，应在原文中修改、更新版本并记录变更日志；绝不悄悄重新生成。
• 可规划，否则不算完成。 不要交付工程师无法据此制定里程碑的 PRD。
• 能力边界（提供 capability_record 时）。 文档输出的范围必须限定在该记录的边界内。生成边界以外的内容（将 refs 实体当作自有内容，或设计超出 exit_point 的流程）属于范围违规——等同于编造规范中不存在的内容。

偏好（可覆盖）：

• “全面”决定输出的目标范围，但仍须保持适度——追求决策完整，而非字数。内容单薄的想法可以合理省略不需要的章节（简单工具无需 NFR 矩阵，没有依赖时无需依赖项章节）。
• 目标／指标控制在 2–4 条；风险分析优先采用简短的事前验尸，而非冗长的风险表。
• 框架（North Star／OKR／HEART；RICE／MoSCoW／Kano）可用于选择合适的指标／优先级；根据产品类型选择适用框架，不要生搬硬套。

注意事项

• 未经证实的问题。 “用户在 X 上遇到困难”却没有证据，读起来很权威，却是大多数 PRD 中最薄弱的部分——请提供依据，或标明这是一个假设。
• 虚荣指标。 “用户会喜欢它”／“提升参与度”都不是指标。指标需要说明衡量什么、目标是什么以及如何追踪。
• 没有护栏的指标。 一个可被操纵的头条指标（例如“发送的消息数”），若没有任何措施防范其可能造成的危害（垃圾信息），就会招致指标操纵——请注明反向指标。
• 把 NFR 写成形容词。 “应该快速且安全”——请改为该类别的量化目标（p95、SLO、WCAG 2.2 AA），并根据产品类型设定合适的指标。
• 孤立功能／悬空目标。 没有服务于任何明确目标的功能（或没有对应功能的目标）会破坏规划者所依赖的逻辑链——追溯其关联，或将其删去。
• MVP 边界模糊。 没有明确的纳入／排除划分和发布标准，范围就会无限膨胀。请明确列出排除项。
• 复述大纲。 在 PRD 内容中重新推导章节列表，而不是依据判断填写模板中的各个章节。
• 泛泛填充。 对任何产品都成立的内容，说明你展开的是模板，而非想法。
• 条件反射式添加 GTM。 给不需要 GTM／发布章节的产品类型（例如内部工具）的 PRD 硬加该章节。准备度提示是按需使用的辅助内容，并非通用章节。
• 修改时悄悄重写。 只改一项需求，却重新生成整个 PRD——这会丢失变更日志，还可能造成偏移。请直接在原文中修改。

对照示例——泛泛而谈（表面上符合要求）与有依据的内容（可用来进行自查）：

章节	泛泛而谈／缺乏依据（不通过）	有依据（可发布）
问题	“自由职业者很难追踪发票。”	“[来自真实研究] X% 的自由职业者表示每季度至少有 1 笔付款逾期；痛点在于催款，而非录入数据。” (数字必须来自真实来源——绝不能编造；若未经研究，请将其写成已标明的假设，并加上“待验证”)
指标	“减少逾期付款。”	“在 90 天内将付款周期中位数从 21 天缩短至 14 天，通过发票付款时间戳追踪；护栏指标：每位用户的支持工单数不超过基线。”
NFR	“付款应该快速且可靠。”	“付款状态 webhook 在 60 秒内更新（p95）；滚动 30 天窗口内的送达率为 99.9%。”
验收标准	“登录功能正常。”	“给定一位凭据有效的注册用户，当其提交登录表单时，应在 < 2 秒内进入控制面板；凭据无效时，应显示内联错误。”

如果你的填写内容像左栏那样适用于任何产品、没有数字、没有来源，就还没有完成。

反模式

• “成功指标就是它能正常工作。” 无法衡量——请定义指标、目标和衡量方法。
• “MVP = 全部功能集。” 没有边界——请划分必需项与后续项，并列出非目标。
• “我会自己写大纲。” 这会重复模板工具的工作——直接采用它提供的结构。
• “想法不够成熟，所以我会写一份通用 PRD。” 应指出假设和待解决问题；绝不要使用套话。
• “跳过研究吧，我懂 PRD。” 研究为这个想法的问题、用户和市场提供依据——而不是为 PRD 理论提供依据。
• “它应该快速且直观。” 用模糊形容词冒充需求——请改为可量化的基准。
• “NFR 是实现细节。” 过早遗漏 NFR 会导致昂贵的返工——请在编写 PRD 时注明目标。
• “这次改动我要重新生成整份 PRD。” 应直接修改原文，并更新版本和变更日志。

输出

一份达到 第 5 步可规划性标准的完整（或修订后）PRD。抽象消费者包括下游规划阶段（据此制定里程碑和任务）、下游功能规范／技术设计（据此详细说明实现方式），以及评审者（reviewing-prd，负责验证同一项 12 条件标准）。PRD 的结构由模板工具提供；此技能负责内容质量。形式：文本 Markdown 文档（此方法与形式无关）。

相关内容

• PRD 模板工具（例如 content-template-gateway）——提供此技能要填写的完整 PRD 章节结构。
• 深度研究能力——以有关给定想法的证据为各章节内容提供依据。
• reviewing-prd——对完成的 PRD 验证同一项 12 条件可规划性标准；作者和评审者遵循同一标准，避免偏差。
• **design-review**技能——用于评审 PRD 下游工程文档（功能规范／技术设计／ADR／RFC）的同级关卡；这是独立关卡，不用于 PRD 本身。
• 典型的上游 depends_on：问题陈述／市场扫描／商业论证／用户研究（仅供参考，并非前置条件——内容应自成一体）。

渐进式披露

• references/nfr-and-metrics.md——NFR 类别分类法及数值目标标准，以及指标框架（North Star／OKR／HEART／AARRR）和护栏指标／反向指标指南。填写需求或目标与指标时加载。
• references/archetype-and-amend.md——各原型的章节侧重叠加内容（消费者／B2B／内部／平台 API／数据 ML／受监管）及完整的修订（原位编辑 + 版本管理 + 影响传递）流程。确定原型或进行修订时加载。
• references/sources.md——方法和质量标准的研究来源记录（仅在审查指南来源时加载）。

正文预算

• description ≤ 1,024 个字符（agentskills.io 上限）。
• 正文约 500 行／5,000 个 token（软性目标——质量优先；若持续超过 700 行／7,000 个 token，则标记）。
• 大量内容放在 references/ 中，按需加载。