Workflow Dlc Pm Review

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 模板 — 评审基准:每条 review 意见对照 PRD v2.0 结构落点（7.N 五子章节 + 职责边界）
• 📚 PM 教训全集 — 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 执行):

text

并行派 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 没同步通过 → 不能进终审(会导致返工)

沟通模板

飞书评审消息模板

text

【{项目名} 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"
}