prd

PRD 需求头脑风暴与文档化

把模糊想法通过对话质疑 → 发散 → 收敛 → 文档化，产出一份工程师拿到就能跑 /spec 的 PRD。

核心原则

1. 质疑前置：先评判需求是否值得做，再讨论怎么做；结论允许是"不值得做"
2. 锚定问题不锚定功能：PRD 围绕"谁的什么问题"展开，功能只是手段
3. 禁写技术方案：不指定架构 / 库 / 表结构 / API 形态；技术疑问显式写进"开放问题"留给工程师——这是 PRD 与 spec 的边界线
4. 用例必须具体可判定：有具体人物、具体操作序列、具体数据、明确预期结果；禁止"用户正常使用后得到正确结果"类空转描述
5. 验收必须可验证：禁止"好用 / 流畅 / 高性能"类无判定标准的表述
6. 一份 PRD 一个需求主题：发现多主题强制拆文件
7. 自包含快照：PRD 是一次性需求快照，被 /spec 消费后不再维护——规则现态由 spec 承载，不引入双源头；文档不依赖外部链接即可独立读懂
8. 语言跟随用户：正文用用户的工作语言，产品术语 / 角色名保持用户原文

---

工作流

步骤 0：读取配置 + 盘点已有 PRD

cat .bb-spec.yaml 2>/dev/null

有 base_dir → 用其值作为 bb-spec 根目录；文件不存在或无该字段 → 缺省 .bb-spec。${DOCS_DIR} = <base_dir>/docs（spec / plan / prd / test 等交付物均在其下）。

ls ${DOCS_DIR}/prd/ 2>/dev/null

发现与本次主题相关的既有 PRD → 读取后问用户：修订该文档，还是新建一份？

步骤 1：意图定性

用一句话复述要解决的问题（不是功能描述）让用户确认。例：用户说"我要一个导出按钮"，复述应是"运营每周要手工整理报表数据，耗时且易错——对吗？"

步骤 2：质疑（对用户可见）

逐项追问并呈现判断：

• 这解决谁的什么问题？有真实场景或证据吗？
• 不做会怎样？严重程度如何？
• 有没有更便宜的替代——现有功能、人工流程、买现成的？

判断"不值得做"或"有更便宜替代" → 输出一段否决理由并结束，不强行产出文档。用户坚持 → 把质疑结论记入 PRD 的"决策记录"后继续。

步骤 3：发散（头脑风暴）

• 枚举用户故事：覆盖所有受影响角色，不只主角色
• 主动补充用户没想到的：边界场景、异常路径、与既有功能的交互
• 分歧点用 AskUserQuestion 逐项收集裁决，禁止脑补替用户决定

步骤 4：收敛

• 钉死目标与非目标（非目标防 scope 蔓延，必须显式列出）
• 用户故事标优先级 P0 / P1 / P2；P0 = 缺了它需求不成立
• 每条 P0 故事至少一个主路径用例，边界 / 异常用例按需补充
• 每条故事配可验证的验收标准
• 头脑风暴中被否决的方向连同理由记入"决策记录"，防止后续重复讨论

步骤 5：产出 + 自检

写入 ${DOCS_DIR}/prd/<YYYY-MM-DD>.<主题>.md（主题用 kebab-case），按模板成文后逐项自检：

• frontmatter 含 name + description（≤ 80 字）+ date？
• 锚定在问题上，而非功能罗列？
• 非目标已显式列出？
• 每条 P0 故事都有主路径用例？用例含具体操作与可判定预期？
• 验收标准全部可验证？
• 全文无技术方案（架构 / 库 / 表结构 / API 形态）？
• 技术疑问已收进"开放问题"？
• 只含一个需求主题？

步骤 6：完成简报

## PRD 完成简报

- 产出：<路径>
- 结论：<值得做 / 用户坚持（质疑结论已记录） / 否决（未产出文档）>
- 用户故事：P0 × N / P1 × M / P2 × K
- 开放问题：<X 项，留给工程师评估>
- 下一步：把该文档交给工程师，放入项目 `${DOCS_DIR}/prd/` 后运行 `/spec` 消费

---

PRD 模板

---
name: <kebab-case，与文件名主题一致>
description: <一句话，≤ 80 字>
date: <YYYY-MM-DD>
---

# <需求标题>

## 背景与问题
<谁、在什么场景、遇到什么问题、现在怎么应对、痛点在哪。>

## 目标
- <可衡量的目标>

## 非目标
- <明确不做的事>

## 用户故事
### P0：作为 <角色>，我想要 <能力>，以便 <价值>

**用例（主路径）**
- 场景：<具体人物在具体情境下>
- 操作：<一步步做了什么，含具体输入 / 数据>
- 预期：<可判定的具体结果>

**用例（边界 / 异常，按需）**
- 场景 / 操作 / 预期 同上

**验收**
- [ ] <可验证项>

## 开放问题（留给工程师评估）
- <技术可行性 / 成本 / 依赖等待评估项>

## 决策记录
- <被否决的方向及理由；质疑环节的结论>