# 阶段 5 多角色协同写作协议（v0.2 新增）

**版本**: 1.0
**日期**: 2026-05-23
**问题**: v0.1 的阶段 5 是 Lead PM 单写 + 四方"终审"——但终审只评不改，且 Lead PM 一人扛全部章节会出现"越界"和"挂一漏万"

**解决**: 引入 PM + 架构师 + 工程师 **3 个独立主笔**，分工写各自章节、互相 review、3 轮收敛。

---

## 跟阶段 4 辩论的本质区别

| 阶段 | 角色定位 | 任务 | 模式 |
|------|---------|------|------|
| 阶段 4 (V0→V1) | 4 个 reviewer | 找方案的问题 | 挑刺，不修方案 |
| **阶段 5 (PRD 终稿)** | **3 个 author** | **写出可执行的 PRD** | **分工写作 + 互相 challenge + 修订** |

reviewer 是"质量守门人"，author 是"内容生产者"。两者在协作时也截然不同：
- reviewer 不互相 challenge（独立挑刺）—— 阶段 4 R1
- reviewer 互相 challenge 别人的 review（pseudoreview）—— 阶段 4 R3
- **author 互相 challenge 别人写的内容并要求修订**—— 阶段 5 是这个

---

## 角色分工

### PM 主笔（agents/prd-author-pm.md）

负责"为什么做、给谁做、做完算成功的标准"。

| 章节 | 关键产出 |
|------|---------|
| §1 项目背景 + 收益 | 量化收益、依据等级、不做风险 |
| §2 用户画像 + 用户故事 | 用户角色矩阵、明确不是谁、US-N 列表 |
| §8 成功度量 | 北极星指标、关键指标矩阵（每个带基线/目标/时间窗/来源） |
| §10 验收标准 | 5 维 AC 覆盖（主流程/异常/状态切换/兼容/回归） |
| §11 依据清单 | 用户依据 / 竞品依据 / 行业基线 / 内部假设 |

### 架构师主笔（agents/prd-author-architect.md）

负责"系统怎么搭、模块怎么拆、数据怎么流"。

| 章节 | 关键产出 |
|------|---------|
| §3 核心目标函数 / 算法 | 数学形式 + 决策变量 + 约束 + 求解方式 |
| §4 数据需求 / 数据模型 | Entity-Relationship + 数据源 + Schema + 数据治理 |
| §6 流程图 + 状态机 | Mermaid 流程 + 关键状态转换 + 跨模块时序 |
| §9.架构风险 + 依赖 | 架构选择的取舍 + 外部依赖的失败模式 |

### 工程师主笔（agents/prd-author-engineer.md）

负责"实现细节、边界异常、可测试性、性能"。

| 章节 | 关键产出 |
|------|---------|
| §5 详细功能说明 | 每个 FR 的界面元素表 + 交互逻辑 + 异常场景 + 边界数值 |
| §7 边界与异常 | 数据边界 / 并发冲突 / 第三方失败 / 平台差异 |
| §9.实现风险 | 技术债识别 + 性能瓶颈 + 上线后稳定性 |
| §10 验收标准（测试细节） | AC 转测试用例 + 自动化策略 + 回归基线 |
| §12 附录-术语 | 技术术语 + 缩写 + 测试数据规范 |

### 章节归属冲突解决

某些章节是边界（如 §9 风险既有架构也有实现）：
- 架构师写"架构选择/扩展性/外部依赖"
- 工程师写"实现细节风险/性能/上线稳定性"
- §10 验收：PM 写场景，工程师写测试细节

---

## 协议：R1 → R2 → R3

### R1 · 并行独立写作

**输入**: 阶段 4 收敛的 V1 方案 + 场景锚点 + 假设清单 + 辩论记录
**任务**: 3 个 author agent **并行启动**，每人写自己负责的章节

输出：
- `{项目}/drafts/r1-pm.md`（PM 章节）
- `{项目}/drafts/r1-architect.md`（架构师章节）
- `{项目}/drafts/r1-engineer.md`（工程师章节）

**铁律**：
- 不互相参考（避免抄袭/趋同）
- 不越界写别人的章节（PM 不写架构、架构不写界面元素）
- 引用其他章节用占位符（如"参考 §5 的 FR-3"）

### R2 · 互相 review + 标记冲突

**任务**: 每个 author 看其他两个 author 的章节，找冲突、缺失、可改进点

每个 author 输出 review 文件：
- `{项目}/drafts/r2-pm-reviews-others.md`（PM 评 架构+工程）
- `{项目}/drafts/r2-architect-reviews-others.md`（架构 评 PM+工程）
- `{项目}/drafts/r2-engineer-reviews-others.md`（工程 评 PM+架构）

每条 review 用标准格式：

```
[需要改] §X.Y 第 N 段
原文：「...」
问题：...
建议：...
```

```
[冲突] §A.B 跟 §C.D 不一致
位置 A：「...」
位置 C：「...」
建议：...
```

```
[建议] §X.Y 可以加强
建议：...
```

```
[OPEN_QUESTION] §X.Y 我跟你看法不同
我的判断：...
你的判断：...
需要 Controller 或企业家裁决
```

### R3 · 主笔修订 + 联席合并

**任务**: 每个 author 收到针对自己章节的 review，分类处理：

| 标记 | 主笔处理 |
|------|---------|
| [需要改] | 必须修订（除非有充分理由驳回，记入 debate-log） |
| [冲突] | 三方协商：要么修一方、要么修双方，不解决标 OPEN_QUESTION |
| [建议] | 主笔自由决定采纳/驳回 |
| [OPEN_QUESTION] | 直接进 PRD §9.1 等企业家拍板 |

每个 author 输出修订版：
- `{项目}/drafts/r3-pm.md`
- `{项目}/drafts/r3-architect.md`
- `{项目}/drafts/r3-engineer.md`

**合并**: Controller（也就是你/PRD 大师本体）把 3 份合并成最终 `output/PRD详细版.md`：
- 按章节顺序拼接
- 解决格式不一致
- 加入 §13 一致性自检
- 加入 §14 v1.5 vs v2 差异说明

### R4（必做）· 独立跨章节平滑

R3 合并后派 `agents/cross-chapter-reviewer.md` 独立扫描数字、术语、引用、决策、时间和量纲口径。输出 `drafts/r4-cross-chapter-review.md`。

P0 冲突必须修复并重新合并；P1 交给有权拍板的人决定。R4 是终审前的固定质量门，不由用户是否察觉问题决定。

---

## 跟阶段 4 reviewer 的关系

阶段 5 协同写作产出后，**沿用阶段 4 的 4 个 reviewer 跑"PRD 终审"**：

- 工程评审：审整个 PRD 的工程可行性
- 设计评审：审界面元素/交互
- 商业评审：审运营落地
- 战略评审：审跟战略对齐

但这次评审 ≠ 阶段 5 协同写作。这是"4 reviewer 找 PRD 终稿的问题"，不是"3 author 写"。

---

## 跟硬校验的关系

合并后跑 5 件硬校验：
- check_evidence.py
- check_format.py
- check_consistency.py
- check_executability.py
- check_requirements_contract.py

任何 ❌ → 打回对应主笔修改 → 再合并 → 再校验。最多 3 轮。

---

## 工作量评估（3 个 author × 3 轮 + 评审校验）

| 子任务 | 工作量 |
|--------|--------|
| R1 并行写作 | 3 个 Agent 并行调用 1 轮 |
| R2 互相 review | 3 个 Agent 并行调用 1 轮 |
| R3 修订 | 3 个 Agent 并行调用 1 轮 |
| Controller 合并 | 主线程 |
| 跨章节平滑 | 1 个 Agent 调用 |
| 4 reviewer 终审 | 4 个 Agent 并行调用 1 轮 |
| 硬校验 + 修复 | 主线程，最多 3 轮 |

**总 Agent 调用**：本协议约 14 次（R1/R2/R3 共 9 + 跨章节 1 + 终审 4）；另有 R0 协调 1 次，修复迭代按实际问题追加。
**预计 Token 消耗**：v0.2 比 v0.1 多 2-3 倍——但产出 PRD 质量显著提升

---

## 验收：v0.2 vs v0.1 输出对比

v0.1 单 PM 写法的 PRD 典型问题（在 fba-smart-restock 项目跑出的 PRD.md 里能看到）：

1. ❌ §5 详细功能说明只有 FR 表格，缺界面元素表 + 交互逻辑 + 异常场景
2. ❌ §3 目标函数有公式，但缺架构师视角的"求解器选型 + 性能边界 + 模块划分"
3. ❌ §10 验收只有少量场景，缺工程师视角的"AC 转测试用例 + 自动化策略"
4. ❌ §4 数据需求只有清单，缺架构师视角的"Entity-Relationship + Schema 草案"

v0.2 协同写法的 PRD 期望改进：

1. ✅ §5 工程师写到每个 FR 的界面元素表 + 异常 + 边界数值
2. ✅ §3 架构师补完整算法选型逻辑 + 性能预算 + 模块解耦设计
3. ✅ §10 工程师把 AC 转成可自动化的测试用例 + 测试数据规范
4. ✅ §4 架构师画 ER 图 + Schema + 数据治理（含 PII / 时区 / 一致性）