Workflow Dlc Pm Review

SKILL.md

---
name: pm-review
description: PM PRD 评审 skill。PRD v1.0 产出后,引导 PM 组织三端(服务端/客户端/测试)+ 设计 review 并行,通过 5 轮迭代拿到可 coding 的 v3.x 终稿。触发场景:用户说"组织 review"、"PRD 评审"、"三端对齐"、或 workflow-start 路由到此 skill。
---

# PM-Review — PRD 评审工作流

你是 PM 评审环节的引导专家。目标:**让 PRD 从 v1.0 经 5 轮并行 review 收敛到 v3.x 终稿,每次 review 的反馈都闭环**。

## 核心原则

> **PRD 和高保真是双交付物,互为校验** —— PRD 每条规则必须能在高保真走出来,高保真每个模块必须能在 PRD 查到定义。

评审的**4 大陷阱**(都升级成物理机制拦截):

| 坑 | 后果 | 拦截机制 |
|---|---|---|
| 关键澄清项自行推断 | 核心规则建在假设上,返工 | **凡"必须澄清"一律业务拍板**,不允许推断 |
| 技术 review 只看新功能 | 研发以为全部重写,估期翻倍 | **v3.0 起必含"现有逻辑继承"章节** |
| 单端 review 过 ≠ 三端过 | 服务端/客户端/测试理解各异 | **三端必须联合 review,不能串行** |
| 设计 review 与技术 review 串行 | 设计改完高保真,技术说做不了,再改 | **设计与技术必须并行** |

## 引用资产

本 skill 深度依赖以下资产,执行时按需读取:

- 📋 **[PRD 模板](../../templates/prd-template.md)** — 评审基准:每条 review 意见对照 PRD v2.0 结构落点（7.N 五子章节 + 职责边界）
- 📚 **[PM 教训全集](../../lessons/by-role/pm.md)** — PRD 评审常见坑(澄清项推断 / 继承逻辑缺失 / 三端串行)

## 门禁原则(Gate-based)

本 skill 采用 **3 阶段 + 5 轮 review**:每阶段有明确通过标准。

## 3 阶段流程

### Phase 1:评审前准备

**🎯 目标**:PRD v1.0+ 准备好进 review,三端 + 设计评审组织好。

**检查清单**:
- [ ] PRD 已迭代到 v2.x(含核心章节填实,占位"待确认"还可容忍)
- [ ] 已产出低保真原型或 mermaid 流程图(R6 要求)
- [ ] 评审日程安排(技术 3 端 + 设计,**必须并行,不能串行**)
- [ ] 评审产物形式(飞书消息 + MD 澄清清单)

**评审组织**:

> **一人多角色场景(默认)**:由 Agent 分别扮演三端视角出具 review 意见——
> - 服务端视角:从后端可行性、接口设计、数据模型角度审
> - 客户端视角:从前端实现、交互可行性、组件复用角度审
> - 测试视角:从可测试性、验收标准完整性、边界覆盖角度审
> - 设计视角:从视觉一致性、信息架构、交互规范角度审
>
> **团队协作场景**:有真人三端成员时,组织联合 review 会议,Agent 辅助整理反馈。

- **技术三端**(服务端 + 客户端 + 测试)—— 联合 review(Agent 模拟或真人)
- **设计**—— 独立 review(并行)
- **业务方**—— 必要时参加,拍板"必须澄清"项

**沟通载体**(实测效果好):
- 飞书消息发 MD 澄清清单,每条带编号
- 反馈分 3 级:**阻塞 / 风险 / 优化**

**🚧 Phase 1 门禁**:
- ✅ PRD 版本 ≥ v2.0
- ✅ 评审会议已约(日历邀请发出)
- ✅ 三端 + 设计同时启动,不允许串行
- ❌ "先给服务端看看吧" → 拒绝,三端必须并行

### Phase 2:四端并行 review(调用专业 Agent)

**核心机制:复用已有 Agent 的专业能力,不用临时空白 sub-agent**

> 每个视角的 review 由对应的专业 Agent 执行(review 模式),它们自带铁律 + 角色教训 + 专业 checklist。
> 这样即使项目还没进入开发阶段,review 也能获得开发级的专业判断。

**四端 Agent 调用映射**:

| 视角 | 调用 Agent | Review 模式 prompt 要点 |
|---|---|---|
| 服务端 | `backend-interface` | 从接口可行性审:字段规范、状态机、错误码、数据模型能否支撑 |
| 客户端 | `frontend-solution` | 从前端实现审:交互可实现性、组件复用、状态管理复杂度、技术风险 |
| 测试 | `qa-strategy` | 从可测试性审:验收标准是否可执行、边界是否覆盖、4 层测试能否设计 |
| 设计 | `design-review`(skill) | 从视觉/信息架构审:交互规范、组件一致性、响应式可行性 |

**调用方式**(主 Claude 执行):
```
并行派 4 个 Agent,每个 prompt 包含:
1. "你现在是 review 模式,不是正式设计/编码模式"
2. "审核对象:PRD v{X} 全文"(附 PRD 内容或路径)
3. "产出:阻塞(P0) / 风险(P1) / 优化(P2) 分级意见列表"
4. "无需产出接口文档/技术方案/测试策略,只产出 review 意见"
```

**为什么不用临时空白 sub-agent**:
- 临时 agent 没有铁律约束,容易"什么都说好"
- 临时 agent 没有角色教训注入,审不出专业问题
- 已有 Agent 的 Step 2 会加载对应 skill,自动获得 lessons 和 checklist

**典型节奏**(参考实测案例,v1.0 → v3.4):

| 轮次 | 端 | 结论 | 核心问题 |
|---|---|---|---|
| re-1.0 | 服务端 | 阻塞+风险+优化 | 信息架构缺失、状态流转规则缺失 |
| re-2.0 | 服务端 | 阻塞+风险+优化 | 编号修正、API 草案、继承原则 |
| re-3.0 | 服务端 | **通过** | 失败路径、超时规则、接口收敛 |
| re-2.0 | 客户端 | **通过**(2 项阻塞拍板后) | 社区工具 API、广告归因 |
| re-1.0 | 测试 | **通过** | AC 矩阵、接口未定项、版本兼容 |

**每轮 review 动作**:

1. **收集 Agent 反馈**(四端并行产出,汇总合并)
2. **分级分类**(阻塞 P0 / 风险 P1 / 优化 P2)
3. **逐条响应**(接受 / 拒绝 / 需澄清,各带理由)
4. **更新 PRD 版本**(v2.1 → v2.2 → ...)
5. **更新 0.1 变更记录**
6. **必须澄清项 → 业务方拍板**(硬要求,见下)
7. **未通过的视角 → 带修改后的 PRD 重新调用对应 Agent re-review**

**⚠️ 关键规则:凡标"必须澄清"一律业务拍板**

识别方法:
- 技术 review 中带 "[必须澄清]" / "[Need clarification]" 的反馈
- 自己吃不准、AI 拿不定主意的
- 涉及跨团队契约的

处理方式:
- **不允许 PM 自己推断答案**
- 列清单 + 责任人 + deadline,推业务方拍板
- 拍板后回写 PRD,标注决策来源

**3 级分类的决策原则**:

| 级别 | 含义 | 响应要求 |
|---|---|---|
| P0 阻塞 | 不解决无法开发 | 当轮必解决,解决后重跑 review |
| P1 风险 | 可开发但有后续 bug 风险 | 3 天内解决,解决结果更新 PRD |
| P2 优化 | 锦上添花 | 可延后到下一版或砍掉,必须明确决策 |

**🚧 Phase 2 门禁**(每轮):
- ✅ 所有反馈都有明确响应(接受 / 拒绝 / 澄清中)
- ✅ "必须澄清"项已推业务方(拍了或在等)
- ✅ PRD 版本已升级,变更记录已更新
- ❌ 有反馈被忽略(未响应)→ 回去响应
- ❌ 一轮内新增的反馈 > 3 条 → 说明 PRD 还不稳定,回 Phase 0 补物料

### Phase 3:通过确认 + 准备终审

**🎯 目标**:三端 + 设计 review 全部通过,准备进入产品终审。

**确认标准**(每端独立确认):
- **服务端**:接口草案通过 + 继承原则落地 + 失败路径明确
- **客户端**:页面结构通过 + 交互可实现 + 依赖 API 已定
- **测试**:AC 矩阵完整 + 接口未定项 = 0 + 版本兼容明确
- **设计**:高保真覆盖所有 PRD 状态 + 设计稿 ↔ PRD 一致

**🚧 Phase 3 门禁**:
- ✅ 三端"必须澄清"= 0
- ✅ "条件通过"全部收敛(无挂起项)
- ✅ PRD 版本 ≥ v3.0
- ✅ 全文"待确认/待补充/待法务"= 0
- ❌ 单端通过 ≠ 过闸,必须三端都过
- ❌ 设计 review 没同步通过 → **不能进终审**(会导致返工)

## 沟通模板

### 飞书评审消息模板

```
【{项目名} PRD v{版本号} {端}Review】

@{端 owner}:

PRD 链接: ...
高保真: ...
变更点: v{上版} → v{本版} 主要改动 ...

请逐条 review,反馈格式:
  [阻塞/风险/优化] 章节号 / 描述 / 建议

Deadline: {日期}
```

### 反馈清单模板

```markdown
# {端} Review 反馈 - PRD v{版本}

## 阻塞(P0)
- [ ] {章节号} {描述} — 建议: {...}

## 风险(P1)
- [ ] ...

## 优化(P2)
- [ ] ...

## 必须澄清
- [ ] {问题} — 归属: {业务方/技术}  deadline: {日期}
```

## 下一步

Phase 3 通过后:
- 调用 `pm-acceptance` skill 做产品终审(PRD ↔ 高保真一致性校验)
- 通过后进入 coding 阶段

## 常见卡点

| 卡点 | 做法 |
|---|---|
| 一端反复不过 | 可能是 PRD 本身有结构性缺陷,回 Phase 1 补物料 |
| "必须澄清"业务方不响应 | 发飞书群 @ + 邮件 + 会议三连,带 deadline |
| 一轮 review 反馈 >20 条 | PRD v1.0 还没稳定,拆成多次小 review 而非一次大 review |
| 设计 review 和技术 review 冲突 | 召开三方对齐会,让技术方的实现约束反馈给设计 |

## 写入日志

```json
{
  "timestamp": "ISO 8601",
  "skill": "pm-review",
  "prd_version_start": "v1.0",
  "prd_version_end": "v3.4",
  "review_rounds": {
    "服务端": 3,
    "客户端": 2,
    "测试": 1,
    "设计": 2
  },
  "blocked_issues_resolved": 8,
  "risk_issues_resolved": 15,
  "optimize_issues_accepted": 10,
  "clarification_items_resolved": 5,
  "outcome": "ready_for_acceptance"
}
```