Prd Spec Writer

---
name: prd-spec-writer
title: PRD 与功能规格撰写
description: 当要把模糊想法/用户请求/问题陈述转成结构化功能规格或 PRD 时使用；做出含问题陈述、目标/非目标、用户故事、P0/P1/P2 需求与 GWT 验收标准、领先/滞后成功指标、待解问题与分期路线的 Markdown 文档，并做范围收敛；不适用于纯 RICE 量化排序、工程实现/架构设计与 UI 视觉设计。触发词：写 PRD、功能规格、目标与非目标、验收标准、需求分期
domain: 协作/knowledge
triggers: [写 PRD / 功能规格, 把模糊想法转成结构化文档, 定义目标与非目标, 写用户故事与验收标准, Given-When-Then 验收标准, P0/P1/P2 需求分级, MoSCoW 取舍, 成功指标（领先/滞后）, 需求分期/拆 v1 v2, 范围收敛防 scope creep]
tags: [产品管理, prd, 功能规格, 用户故事, 验收标准, 目标与非目标, 成功指标, 范围管理, 协作, pm]
level: 进阶
status: stable
agents: [claude-code, codex, cursor, gemini-cli]
tools: [Read, Write, Edit]
requires: []
related: [product-manager-toolkit, codebase-to-prd, agile-product-owner, status-report-generator]
combines_with: [task-decomposition-planner, design-dev-handoff]
license: Apache-2.0
source: anthropics/knowledge-work-plugins
source_license: Apache-2.0
---
# PRD 与功能规格撰写

> domain: 协作/pm · name: prd-spec-writer

## 何时使用

把一个尚未成形的想法转写成可评审、可落地的功能规格或 PRD 时使用。典型输入任意一种：

- 特性名（「SSO 支持」）。
- 问题陈述（「企业客户一直要集中式认证」）。
- 用户请求（「用户想把数据导出为 CSV」）。
- 模糊想法（「我们得想办法治一下新手流失」）。

核心产物：一份 Markdown 文档，含问题陈述 / 目标 / 非目标 / 用户故事 / 分级需求与验收标准 / 成功指标 / 待解问题 / 时间线与分期；并在过程中主动收敛范围。

不该用的边界（转其他技能，勿强套）：

- 纯量化优先级排序（RICE / 价值×工作量矩阵）→ 用 `product-manager-toolkit`。
- 工程实现、架构设计、写代码 —— 本技能只产出需求，不落地。
- UI 视觉与交互稿 —— 本技能只描述线框级需求。
- 已有 Scrum 待办、只需写故事/估点/排 Sprint → 用 `agile-product-owner`。

## 步骤

1. 明确特性：接受上面四类任意输入，先复述你对它的理解，对齐后再往下。
2. 补全上下文（对话式，别一次抛全部问题，先问最关键的，边写边补）：
   - 用户问题：解决谁的什么痛？多频繁？
   - 目标用户：服务哪些分群。
   - 成功指标：怎么算成功。
   - 约束：技术、时间线、合规、依赖。
   - 前人工作：是否做过、有无现成方案。
3. 拉取已连接工具的上下文（连了才做，没连就用现有信息，别让用户去连）：项目管理工具搜相关工单/Epic/依赖；知识库搜既有研究/旧规格/设计文档/决策记录；设计工具拉相关原型/设计系统组件。
4. 生成 PRD（小节见下「指令」）。
5. 评审迭代：问哪些小节要调整；提出可展开某节；提议产出后续物料（设计简报、工程工单拆分、干系人提案）。

## 指令

PRD 固定小节及写法约束：

- 问题陈述：2-3 句说清痛点、谁受影响及频率、不解决的代价（用户痛/业务影响/竞争风险），以证据(用户研究/客服数据/指标)落地。
- 目标：3-5 条，具体可量化，是结果非产出（写「首次价值时间降 50%」而非「做新手引导向导」），区分用户目标与业务目标。
- 非目标：3-5 条显式不做的事，各附一句「为何出范围」(影响不够/太复杂/独立项目/为时过早)。非目标和目标同等重要，是防 scope creep 的护栏。
- 用户故事：标准格式「作为[具体用户类型]，我想要[能力]，以便[价值]」。用户类型要具体（「企业管理员」而非「用户」）；描述需求不描述 UI 控件；含边界(错误态/空态/边界条件)；按优先级排序；满足 INVEST。
- 需求：分三级，各带验收标准。
  - Must-Have(P0)：砍掉后特性还能解决核心问题吗？不能→P0。对 P0 要苛刻，全是 P0 等于没有 P0。
  - Nice-to-Have(P1)：显著改善但核心可用而无它；是有把握很快做的快速跟进，不是愿望清单。
  - Future(P2)：v1 显式不做，但设计上为它留空间，避免做出日后难改的架构决策。
- 成功指标：领先指标(天-周即变：采用率/激活率/任务完成率/耗时/错误率/使用频次) + 滞后指标(周-月才显：留存/营收/NPS/工单下降/赢单率)。目标要具体（「30 天内 50% 采用」），定测量方法与评估时点，设「达标」与「冲刺」两档。
- 待解问题：标注归谁回答(工程/设计/法务/数据/干系人)，并分阻塞(开工前必答)与非阻塞(实现中可解)；只列真正开放、上下文里答不出的问题。
- 时间线：硬截止(合同/活动/合规)、对外部团队/发布的依赖、过大时的分期建议。

验收标准用 Given/When/Then 或清单二选一，覆盖 happy path / 错误 / 边界，含「不该发生什么」(负向用例)，每条独立可测，禁用「快」「易用」「直观」等含糊词——把它们换成可度量的具体行为。

范围收敛硬规则：每份规格都写显式非目标；任何范围新增必须配一项范围删除或时间线延长；v1 与 v2 在文中清晰分隔；用「停车场」收纳出范围的好点子；时间盒调研（X 在 2 天内搞不定就砍）。

输出格式：Markdown，标题层级清晰，加粗关键句，让忙碌干系人只读标题和加粗就能抓住要点。

## 示例

用户故事（含多 persona、按优先级）：

```
作为团队管理员，我想要为组织配置 SSO，以便成员用企业凭证登录。
作为团队成员，我想要被自动重定向到公司 SSO 登录，以便不必再记一套密码。
作为团队管理员，我想要看到哪些成员已通过 SSO 登录，以便确认推广生效。
```

验收标准 — Given/When/Then：

```
Given 管理员已为组织配置 SSO，
When 团队成员访问登录页，
Then 自动重定向到组织的 SSO 提供方。
```

验收标准 — 清单：

```
- [ ] 管理员可在组织设置中填入 SSO 提供方 URL
- [ ] 登录页向成员展示「用 SSO 登录」按钮
- [ ] SSO 登录在账号不存在时新建账号
- [ ] 邮箱匹配时 SSO 登录关联到既有账号
- [ ] SSO 失败时展示清晰的错误信息
```

## 注意事项

- 对范围要有主见：一份紧致、定义清晰的规格胜过一份庞大模糊的。
- 想法太大装不进一份规格时，建议分期，只为第一期写规格。
- 成功指标必须具体可测，杜绝「提升用户体验」这类空话。
- 非目标和目标一样重要——它们在实现阶段拦住 scope creep。
- 待解问题要「真开放」：能从上下文里答出来的就不要列。
- 识别 scope creep 信号：规格批准后需求仍在加、「顺手」累积成大工程、做没人要的特性、上线日不断后移却不重新定范围、只加不减。
- 用户故事常见错误：太含糊（「想更快」——具体哪快？）、规定方案（「想要下拉菜单」——描述需求别描述控件）、无收益、太大（「想管理团队」——拆细）、内部视角（「想重构数据库」——这是任务不是故事）。

## 互见

- requires：无
- related：`product-manager-toolkit`（RICE 排序与 PRD 模板，可为本技能提供优先级输入）、`agile-product-owner`（把规格里的需求落成 INVEST 故事与 Sprint）、`github-issue-writer`、`jira-expert`
- combines_with：`product-manager-toolkit`（先量化排序再写规格）、`agile-product-owner`（规格 → 待办与 Sprint）、`enterprise-project-manager`（规格 → 项目计划与里程碑）

---

采编自 anthropics/knowledge-work-plugins（Apache-2.0 许可），已按中文技能大典 SCHEMA 适配重写。