---
name: prd-write
description: 编写或维护项目内的 PRD。适用于首版/重大方案的完整 PRD，也适用于已有产品基线后的功能迭代 PRD；先复用 docs/product 下已确认的体验规则，只记录本次新增、偏离、候选模式和待决问题。输出保存到 docs/prd 下的功能目录。
---

# PRD 编写

将产品意图转成可评审、可交接、可持续维护的需求文档。PRD 是本次功能的决策记录，不重复抄写已确认的全局产品规则，也不是逐像素的 UI 实现说明。

## 使用边界

- **完整模式**：首版产品、重大新模块或需要重新对齐问题、用户、策略和指标的方案。
- **增量模式（默认）**：已在迭代的产品新增或调整一个功能。写清本次变化及其与体验基线的关系。
- 小型 bug、文案修正或已完全明确的工程任务不需要完整 PRD；使用仓库既有 issue/task 流程即可。
- 若需求还停在口头、没讲清边界，先用 `requirement-clarify` 采访一轮；若用户要求评审已有 PRD，交给 `grill-with-prd`；若需要建立产品级体验规则，先用 `product-experience-foundation`。

## 开始前：确定上下文

1. 确定功能名，使用短横线格式的 `<feature-name>`；目标路径为 `docs/prd/<feature-name>/prd.md`。
2. 读取仓库约定、相关现有 PRD、受影响页面和相关代码。已有 PRD 时先征求用户选择：更新、另建功能目录或保留原文。
3. 查找 `docs/product/<project-name>/`：
   - 目标产品明确时，读取 `product-context.md`、相关端（`c-end/` 或 `admin/`）的 `ux-foundations.md` 与 `patterns.md`，以及 `component-promotion-log.md`（若存在）。
   - 有多个产品或无法判断目录时，请用户指定；不得凭空选择基线。
   - 没有基线时，继续写功能 PRD，但标记“无体验基线”；若这是首版或已有页面体验不一致，建议后续运行 `product-experience-foundation`，不要自行虚构产品级规则。
4. 收集用户提供的需求、研究、数据、竞品、截图、已有流程和工程限制。事实标为来源；合理推断标为 `[INFERRED]`，无法确认的内容列入待决问题。
5. 选择模式：已有且适用的基线优先使用增量模式；只有完整战略上下文确有价值时使用完整模式。

## 增量 PRD 的核心规则

每份增量 PRD 必须明确四类内容：

| 类别 | 写什么 | 放在哪里 |
| --- | --- | --- |
| 复用基线 | 本次沿用的导航、页面模式、文案、状态或组件规则 | `体验关系` |
| 功能局部 | 只为本次功能存在的流程、字段、权限和异常状态 | `需求与验收` |
| 候选晋升 | 可能将来复用、但尚未成为产品规则的模式 | `体验关系` |
| 有意偏离 | 与基线不同的地方、原因、影响端和回写判断 | `体验关系` |

- 不重复描述基线已定义的菜单、基础控件、弹层或空/加载/错误规则；用链接和简短的“沿用”说明替代。
- 未经确认的单次模式只能标为候选，不得直接当作全局组件或通用流程。
- 若模式已被两个已确认功能采用，或产品明确确认，应提示使用 `product-experience-foundation` 更新 `patterns.md` 与晋升记录。
- PRD 与基线冲突时，记录偏离，不能静默覆盖基线。

## 输出结构

以 [template.md](template.md) 为基础。增量模式必须保留 0、1、2、5、7、8、9、10 节；3、4、6 节可精简为“沿用现有结论”或省略。完整模式应填写所有适用章节。

### 需求与验收的写法

按用户可验证的行为组织，而不是按页面或技术任务堆砌：

```markdown
### R1 创建任务
作为运营人员，我可以从任务列表新增任务，以便安排工作。

验收标准：
- 点击“新增任务”打开沿用 Admin 表单规则的弹窗。
- 必填项校验失败时，字段旁显示错误且不提交。
- 保存成功后关闭弹窗、刷新列表并显示成功反馈。
- 无创建权限的角色不显示入口，且接口仍拒绝该操作。
```

- 写清角色、触发条件、主流程、状态变化、权限、异常和验收结果。
- 只在有业务价值时补充指标、埋点、迁移、接口或数据依赖；不要为未知实现细节编造方案。
- 原型、设计规格、竞品证据等放在同一功能目录，并从 PRD 链接：`design.md`、`prototype.html`、`demo.md`、`delivery.md` 均为可选产物。

## 协作与后续路由

1. 完成草案后，用 `grill-with-prd` 审查范围、矛盾、边界、异常和未决问题，并将确认结论回写 PRD。
2. 需要外部视觉证据时用 `web-design-extractor`；需要独立高保真评审原型时用 `design-spec-prototyper`；需要贴合项目现状的可点击高保真原型时用 `pm-frontend-prototype`。
3. 体验和需求确认后，用 `prototype-to-product` 判断交付路径：直接实现，或交接到项目采用的 OpenSpec、Superpowers 或其他工程治理流程。PRD 不替代这些工程治理产物。
4. 交付时说明：PRD 路径、模式、读取的基线、复用规则、候选/偏离、未决问题与下一步评审动作。

## 常见问题

- **把 PRD 写成全产品说明书**：增量功能只写变化，其他内容链接到基线。
- **把设计细节当需求**：描述用户目标、状态和验收；视觉细节交给设计规格或原型。
- **没有非范围**：明确本次不做什么，避免把后续想法默认为承诺。
- **假装基线已确认**：历史页面只能作为观察依据；它与明确决策的权威性不同。
- **隐藏不确定性**：把缺少的角色、策略、数据或异常处理显式放在开放问题中。

## 交付前检查

- [ ] 功能目录与 `prd.md` 路径正确，既有文档没有被无意覆盖。
- [ ] 已选择完整或增量模式，并说明理由。
- [ ] 已读取或明确缺少相关产品体验基线。
- [ ] 增量 PRD 已列出复用、局部、候选与偏离（无则写“无”）。
- [ ] 范围、非范围、角色、状态、权限、异常与验收可被评审。
- [ ] 不确定内容有来源标记或开放问题，未被伪装成事实。