# 企业家 PRD 大师 · 架构决策记录

## 一、项目目标（一句话）

让**企业家**用大白话讲完想做什么，30-90 分钟后拿到一份**经过多角色评审的完美 PRD**，可直接交给 Claude Code / Codex / Cursor 写代码。

## 二、用户画像

**主要用户：企业家**（不是受过训练的 PM）

特征：
- 有商业直觉但缺产品方法论
- 说话方式抽象、跳跃："想做一个像 XX 一样的 AI 工具"
- 不愿意填模板，不耐烦被问 20 个字段
- 时间宝贵，但要求结果"上得了台面"
- 不会量化指标（说"提升用户体验"）
- 混淆用户和客户、功能和价值
- 想象力大于收敛能力

**次要用户**：刘润老师本人（教学演示 + 自己真实写 PRD）

## 三、设计原则

### 吸收的精华（来自 spec-kit / senior-pm-prompt / ai-prd-generator）

| 来源 | 吸收的机制 | 用在哪 |
|------|----------|--------|
| **senior-pm-prompt** | "What do you want to build?" 单一开放入口 | 阶段 0 入口 |
| **senior-pm-prompt** | Multi-slot 第一轮激进抽取 | 苏格拉底追问 |
| **senior-pm-prompt** | 对模糊词驳回（"提升用户体验"→which metric/baseline/target/timeframe） | Lead PM 铁律 |
| **senior-pm-prompt** | Pair every Goal with its Metric | 每问一个目标立即追问指标 |
| **senior-pm-prompt** | Never fabricate，查不到就显式记录假设与验证方法 | 数据合规 |
| **senior-pm-prompt** | PASS/FAIL 一致性检查块（US→FR / Goal→Metric） | 终审前必跑 |
| **spec-kit /clarify** | 分类驱动的歧义扫描（9 大类） | 苏格拉底追问的扫描框架 |
| **spec-kit /clarify** | 依赖驱动的高影响决策澄清 | 每轮询问当前可独立回答的完整前沿，依赖项后置 |
| **spec-kit /clarify** | 每选项题给 Recommended + 理由 | 企业家友好 |
| **spec-kit /clarify** | 接受 "yes"/"recommended" 用默认 | 减少摩擦 |
| **spec-kit /clarify** | 每答完立刻写回（原子保存） | 防止状态丢失 |
| **spec-kit /analyze** | 跨文件一致性扫描 | 终审 |
| **spec-kit /checklist** | "需求的单元测试"思想（不是测代码） | 校验设计 |
| **ai-prd-generator** | 8 步执行清单 + 反卡死规则 | Controller 主流程 |
| **ai-prd-generator** | 5 种验证 verdict (PASS / SPEC-COMPLETE / NEEDS-RUNTIME / INCONCLUSIVE / FAIL) | 假设清单 |
| **ai-prd-generator** | FR 必须有可追溯来源 | 证据系统 |
| **ai-prd-generator** | 决策题使用结构化提问 | 需要用户拍板的节点 |
| **MAGI** | 多 Agent 协作 + 双 Agent 共识 | 多角色评审团 |
| **MAGI** | 产品 vs 技术边界铁律 | Lead PM 铁律 |
| **MAGI** | 证据等级 A/B/C/D/E | 假设清单 |

### 丢掉的（不适合 Claude Code / 不适合企业家场景）

| 丢掉的东西 | 原因 |
|----------|------|
| MAGI 的 `watchdog.sh` | Claude Code 同步调用不会卡死 |
| MAGI 的 🔖 心跳机制 | 同上 |
| MAGI 的 `sessions_spawn` 接续规则 | Claude Code Agent 工具天然支持 |
| spec-kit 的 PowerShell 脚本调用 | 我们不强绑定 spec-kit 项目结构 |
| ai-prd-generator 的 64 条规则中纯技术细节（如 SP 算术、SQL注入预防） | 企业家 PRD 阶段不需要写代码细节，留给下游 Codex |
| ai-prd-generator 的 MCP server 依赖 | 增加复杂度，不是必需 |
| BMAD 的庞大模块生态 | 我们要轻量启动 |

### 我们新加的（别人没有的）

| 新机制 | 解决什么问题 |
|-------|------------|
| **品类 playbook + 通用 fallback** | SaaS/App/电商分别深挖，其他或混合品类由 generic 接住 |
| **阶段 4 多角色评审团 + 辩论协议** | 单 reviewer 找的问题深度不够；4 角色独立 + 互相 challenge 才能挖出真问题 |
| **阶段 5 多角色协同写作 (v0.2 新增)** ⭐ | 把"PM 单写 + 终审"改为"PM+架构师+工程师 3 author 并行写 + 互 review + 收敛"——产出更细节、更可执行的 PRD |
| **企业家典型卡点表** | 企业家常见错误模式（混淆用户/客户、把功能当价值、不会量化等）的专项应对 |
| **三钉子证据系统**（数据/细节/案例） | 借鉴刘润内容方法论，移植到 PRD 证据要求 |
| **假设显性化清单**（assumptions.md） | 把"猜测"变成"可证伪的假设 + 验证方式"——这是教学王牌 |
| **吵架记录**（debate-log.md） | 把多 Agent 博弈过程留档，本身就是教学素材 |
| **完整对话存档**（conversation.md） | 跟企业家的全过程留档，方便复盘 |
| **品类自适应 PRD 模板** | 不同品类（SaaS vs App vs 电商）模板侧重不同 |

## 四、七阶段流程

```
阶段 0 · 自由倾诉 → 回放初步理解
阶段 1 · 决策树深挖 → 场景锚点、假设清单、需求 ID 注册表
阶段 2 · 价值论证 → 经用户确认的价值依据与关键数字
阶段 3 · 自动调研 → 带来源的竞品与 benchmark 证据
阶段 4 · 方案 V0 + 四方评审三轮博弈 → V1、MVP 边界、debate-log
阶段 5 · PRD 终稿（三主笔协同写作 + 需求契约 + 硬校验）→ 分层 PRD 与 requirements
阶段 6 · 方案 PPT（从 PRD 静默生成）→ ppt.md 与逐页 HTML

最终交付：PRD详细版.md、PRD-summary.md、PRD-dev.md、requirements.md、
requirements-analysis.md、assumptions.md、evidence/、debate-log.md、ppt.md、ppt/
```

## 五、文件目录结构

```
prd-master/
├── SKILL.md                 ← 主 Controller
├── agents/                  ← Lead PM、reviewer、author
├── playbooks/               ← SaaS / App / 电商 / 通用调研
├── templates/               ← PRD、需求契约与证据模板
├── validators/              ← 5 件 Python 硬校验
├── references/              ← 按阶段加载的执行规范
├── docs/                    ← 说明与协作协议
└── examples/                ← 示例产物

{项目名}/
    ├── output/
    │   ├── PRD详细版.md / PRD-summary.md / PRD-dev.md
    │   ├── requirements.md / requirements-analysis.md
    │   └── ppt.md / ppt/
    ├── assumptions.md
    ├── debate-log.md
    ├── conversation.md
    ├── evidence/
    │   ├── competitors.md
    │   └── benchmark.md
```

## 六、核心机制

### 6.1 苏格拉底入口（阶段 0 → 1）

**入口铁律**：
- 第一句问开放问题（"你想做什么？"），不丢模板
- 第一轮回复**激进抽取**所有可识别 slot（参考 senior-pm-prompt）
- 输出"我听到的是这样..."回放确认，让企业家知道被听到

阶段 1 的执行契约只在 `references/提问收敛闸门.md` 维护。本架构文档只说明设计意图：一次推进一个高影响节点，AI 做定点事实查证，用户决定产品取舍；已有证据不重复问，关键分支未清零就不结束。

**9 大类覆盖审计（来自 spec-kit /clarify，企业家版调整；防漏，不是问卷顺序）**：
1. 用户画像（谁用、不用谁、决策者 vs 使用者）
2. 核心场景（什么时候用、当前替代方案）
3. 核心痛点（多痛、怎么忍受的）
4. 成功定义（什么样算成功、怎么衡量）
5. 边界（不做什么、装饰还是核心）
6. 资源约束（预算/团队/时间）
7. 技术约束（多端/性能/合规要求）
8. 业务模式（收费/免费/补贴）
9. 最大不确定性（你最不确定什么）

### 6.2 多角色辩论协议（阶段 4）

**4 个评审角色**（每个有自己的 system prompt）：

| 角色 | 视角 | 典型问题 |
|------|------|---------|
| 工程 Reviewer | 可行性、工时、技术风险 | "这个 3 个月做得完吗？""有现成方案吗？""依赖什么硬件/数据/API？" |
| 设计 Reviewer | UX 完整性、交互一致性 | "新手怎么发现这个功能？""失败状态怎么显示？""跟现有产品风格冲突吗？" |
| 商业 Reviewer | 运营、资源、变现 | "冷启动怎么做？""谁来推送/客服/数据？""第一批用户从哪来？" |
| 战略 Reviewer | 战略对齐、底层假设 | "这是真问题还是伪需求？""做这个跟你公司主线的关系是？""为什么是现在？" |

**辩论协议（3 轮）**：

```
Round 1（独立挑刺）
  四方同时收到方案 V0，各自独立输出问题清单
  禁止互相参考，避免群体思维
  输出：4 份独立挑刺清单

Round 2（Lead PM 回应）
  Lead PM 汇总四方意见，对每条挑刺要么：
    - 接受 → 修订方案
    - 驳回 → 给理由
    - 待决 → 标记需要企业家拍板
  输出：V0.5 修订 + 取舍清单

Round 3（互相 challenge）
  四方看 V0.5 后再发言，重点 challenge 别人的逻辑：
    - 工程："COO 说的运营成本不算技术成本，但是其实..."
    - 战略："产品评审纠结的功能细节，其实底层假设是错的..."
  输出：V1 方案 + 完整 debate-log.md
  ⏸ 企业家拍板
```

**辩论限制**：
- 总轮数 ≤ 3，再有分歧标 [OPEN_QUESTION] 给企业家
- 每角色每轮发言 ≤ 300 字，避免冗长
- 不准说"我同意以上所有观点"——必须独立思考

### 6.3 证据系统硬校验（阶段 5）

**check_evidence.py** 扫描：
- 裸数字（如"提升 30%"）必须紧跟 `[来源: ...]` 或 `[假设值]` 或 `[待验证]`
- 空话词清单：提升用户体验、年轻人喜欢、更好用、市场反响热烈、刚需 → 拦截
- "信息差三钉子"检查：每个核心论点需要至少 1 个数据 + 1 个细节 + 1 个案例

**check_format.py** 扫描（继承 MAGI 思路）：
- ASCII 框图（`┌└│├─`）→ 拦截，要求改 Mermaid
- HTTP 方法 + API 路径（`POST /api/...`）→ 拦截，要求改产品语言
- 数据库字段类型（`varchar(\d+)`）→ 拦截
- 章节序号混乱 → 警告

**check_consistency.py**（PASS/FAIL 检查，来自 senior-pm-prompt）：
```

随后运行 `check_executability.py` 检查 PRD 是否可直接交给编码 Agent，并用 `check_requirements_contract.py` 校验稳定 ID、EARS 语法和分析报告的 P0/P1 门禁。五件校验全部通过后才能交付。
- 每个 US 必须有 ≥1 个 FR 实现 → PASS/FAIL
- 每个 Business Goal 必须有 ≥1 个 Metric 跟踪 → PASS/FAIL
- 每个 User Goal 必须有 ≥1 个 Metric 跟踪 → PASS/FAIL
- Persona vs Goal vs User Story 一致性 → PASS/FAIL
- 任何 FAIL 自动写入 assumptions.md 的 Weak Spots
```

### 6.4 假设清单（assumptions.md）

这是教学王牌。每个假设：

```markdown
## A-001: 用户会主动打开 App 写日报

- **依据等级**: D（基于团队访谈推断，非真实数据）
- **证伪条件**: 上线 14 天，DAU < 30%
- **验证方法**: 埋点 + A/B 测试（实验组打开率 vs 对照组）
- **如果证伪怎么办**: 改用 Slack 集成主动推送
- **风险等级**: 🔴 高（核心假设，错了整个产品逻辑崩）
```

每份 PRD 必须有 assumptions.md，列出 5-15 个核心假设。

### 6.5 关键决策最小记录

PRD Master 不为每个选择生成 ADR/DR。R4 冲突处理完成后，Controller 只把同时满足以下 3 条的决定写进 PRD「关键决策」表，并复用 `state.json.key_decisions_made` 保存索引：

1. 存在至少两个真实可行方案；
2. 已由有权拍板的人确认；
3. 推翻会改变核心产品边界、关键架构或产生明显返工。

产品决策由企业家/产品负责人确认；架构决策由技术负责人确认。未确认的内容保留为 `OPEN_QUESTION` 或「架构建议」，普通选择留在对应 PRD 章节，完整讨论留在 `debate-log.md`。当前版本不创建独立 ADR/DR 文件；只有真实项目证明一张表不足以承载长期维护时，再考虑升级。

关键决策若影响系统行为或约束，必须同步落入 `REQ/AC/NFR`；设计层 `DEC-*` 仅记录设计衍生决定，避免 PRD、requirements 与设计形成互相冲突的多套事实源。

## 七、跟现成方案的关系

| 方案 | 我们的关系 | 借鉴的部分 |
|------|----------|----------|
| **github/spec-kit** | 学习其方法论 | clarify 的 9 类扫描、checklist 的"需求单元测试"、analyze 的跨文件一致性 |
| **wwwazzz/senior-pm-prompt** | 借鉴单一系统提示词的简洁性 | "What do you want to build?" 入口、激进抽取、对模糊驳回、PASS/FAIL 块 |
| **cdeust/ai-prd-generator-plugin** | 学习其严苛度 | 多文件输出、反卡死规则、verdict 分级、FR 可追溯 |
| **bmad-code-org/BMAD-METHOD** | 知道有这条路 | 多 agent 协作思想（但不抄其复杂模块系统） |
| **MAGI** (Kira2red/magi-product) | 知道有这个起点 | 产品/技术边界铁律、证据等级 A-E、双 Agent 共识 |

**关键差异**：他们都是"通用工具给 PM 用"，我们是"企业家友好的教练 + 品类 playbook + 通用 fallback + 多角色辩论 + 三钉子证据"。

## 八、历史 MVP 状态

最初的 Lead PM、双 reviewer、SaaS 模板和一致性校验 MVP 已完成；当前 v0.6 已扩展为七阶段、决策树前沿、四类调研、四方评审、三主笔协作、五件硬校验和方案 PPT。这里不再维护第二份实施清单，当前能力以 `SKILL.md` 为准。

---

**架构说明版本**: v0.6
**状态**: 已实现，随主流程同步维护