ai-pm-review

name: ai-pm-review description: >- PRD 或原型已写完，需要模拟正式评审会议、让六大角色出评审意见时使用（区别于 multi-perspective-review 的设计阶段审查）。 当用户说「评审PRD」「需求评审」「PRD有没有问题」「帮我挑毛病」「技术评审」「开评审会」 「PRD走查」「需求质量检查」「PRD评审报告」时，立即使用此技能。 argument-hint: "[项目目录路径 | --round=N]" allowed-tools: Read Write Edit Bash(mkdir) Bash(ls) Agent

需求评审

原型质量基线（评审前必读）

评审若涉及原型，质量基线对齐 .claude/skills/ai-pm/references/prototype-judgment-card.md：

• 默认按可操作级判（§1.1）：可自由操作、占位按钮做成真交互、认有限意图+澄清兜底、不假全量重算、L2 人机确认是真检查点。只有 PM 明确说"这次降档到 X 级"才放宽——否则评审里把"演示级 click-through"当成不达标。
• 视觉验证必带截图（§11）：原型相关的评审意见，要么基于浏览器实跑+截图核对，要么如实标"仅 DOM/源码层面审查、未视觉核对"。DOM 断言全绿 ≠ 视觉对——溢出、折行、竖排、对齐错位等纯视觉 bug 只有渲染出来看才能抓到。

输入

• 主要：{项目目录}/05-prd/<当前 PRD 文件>（由 _status.json.active_prd 指定；首次默认 05-PRD-v1.0.md）
• 参考：{项目目录}/06-prototype/index.html（原型，如有）
• 参考：{项目目录}/02-analysis-report.md、04-user-stories.md

输出

{项目目录}/08-review-report-v{N}.md（评审报告）→ 更新 PRD

六大评审角色

执行步骤

步骤1：读取评审材料 + 加载业务上下文

读取 PRD、原型、需求分析、用户故事，确定评审轮次（--round 参数，默认第1轮）。

同时加载业务上下文（用 test -f 检查，存在则读取，不存在静默跳过）：

1. _memory/L0-identity.md — 产品定位、目标用户、核心约束
2. _memory/L1-decisions.md — 最近 5 条关键决策（避免把已决策的事当问题提）
3. _memory/L2-prd-versions.md — 历史 PRD 版本摘要（知道哪些功能已在 V1/V2 覆盖）
4. 知识库相关条目 — 从 templates/knowledge-base/pitfalls/ 和 templates/knowledge-base/insights/ 中，grep 与 PRD 关键词（学科名、题型名、产品名）匹配的文件，最多取 5 条，读取每条的「问题场景」和「解决方案」段落

将以上内容拼装为 业务背景 块，注入到两个 Subagent 的 prompt 开头。格式：

## 业务背景（评审前必读，不可忽略）

### 产品定位与目标用户
{L0-identity.md 全文}

### 历史版本已覆盖的功能
{L2-prd-versions.md 全文，若无则省略此节}

### 关键历史决策（不要把这些当问题提）
{L1-decisions.md 最近 5 条}

### 本产品已知踩坑
{知识库匹配条目，每条仅列：坑名 + 问题场景一句话 + 解决方案要点}

步骤2：2 组 Subagent 并行评审

调用 Agent 工具，同时派发 2 个 subagent，每个 prompt 以上方 业务背景 块开头：

Subagent 1 — 技术视角（前端开发 + 后端开发 + 测试）

• 系统提示：同时扮演前端开发、后端开发、测试三个角色，不与用户交互
• 任务：结合业务背景读取 PRD 和原型，输出三个角色各自的评审意见
• 输出至：/tmp/review_tech.md

Subagent 2 — 产品视角（产品经理 + 设计 + 运营）

• 系统提示：同时扮演产品经理、设计、运营三个角色，不与用户交互
• 任务：结合业务背景读取 PRD 和原型，输出三个角色各自的评审意见
• 输出至：/tmp/review_product.md

评审纪律（所有角色共用）：

• 「业务背景」中已覆盖的历史版本功能，不作为本次缺失问题提出
• 评审意见必须基于目标用户的实际角色（L0 中定义的）；若 PRD 用户与 L0 定义冲突，应指出矛盾而非凭空假设用户行为
• 已知踩坑中有对应条目的问题，直接引用坑名而不重复展开，节省篇幅
• 不建议超出本期需求范围的新功能（判断依据：L1 决策 + 版本摘要 + PRD 背景章节）

设计角色附加：排版原则审查

对原型 HTML 逐项检查以下六条排版原则，每条给出 ✅/⚠️/❌ + 问题描述 + 修复建议：

1. 留白呼吸 — 内容覆盖率是否在 60-70%？是否有挤满的区域？
2. 对比与缩放 — 标题层级是否有 2+ 维度差异（字号+字重+颜色）？眯眼测试能否区分层级？
3. 亲近与分组 — 标题是否离下方内容更近而非上方？列表间距是否 < 段间距？
4. 对齐与网格 — 是否存在未对齐的元素？中文段落是否两端对齐？
5. 重复与一致 — 同级元素是否使用相同样式？是否有孤立格式（仅一处加粗、仅一处用不同色）？
6. 视觉层次 — 用户视线路径是否清晰？关键操作按钮是否突出？

主线程等待 2 个 subagent 完成后：合并结果，去重（多角色提及同一问题则合并并注明来源），按 Critical → Major → Minor 排序。

步骤3：生成评审报告

生成 08-review-report-v{N}.md，输出问题汇总和修改建议。

步骤4：生成修改计划（含分类标注）

用户选择修改策略（全部修改 / 核心修改 / 最小修改 / 指定修改）后，为每项改动标注类型：

[直接执行] — 答案唯一、无业务歧义：

• 文字矛盾修正（如优先级前后不一致）
• 现有逻辑的格式补全（如将"与V1/V2一致"扩写为 Given/When/Then 格式）
• 结构性新增（附录扩列、新增章节标题等）

[PM确认] — 涉及业务规则，PM 才有答案，合理假设不止一种：

• 功能边界决策（失败后退回老流程 vs 报错阻断）
• 历史逻辑继承（互斥是权限层还是配置层）
• 系统能力未确认（某系统是否支持某操作）

向用户展示修改计划，每项前缀标注类型：

修改计划（共 {N} 项，其中 {n} 项需你确认）：

[直接执行] 问题2：§3.1 题卡合一优先级 P1→P0 矛盾修正
[PM确认]   问题1：坐标转置失败的用户侧行为
[直接执行] 问题3：§4.3 第三方答题卡影响范围措辞修正
...

步骤4.5：PM 确认关口

若修改计划中存在 [PM确认] 项，触发此步骤；全部为 [直接执行] 则跳过，直接进入步骤5。

按以下格式逐项呈现，等待用户全部回复后再执行：

## 执行前需你确认（{N} 项）

**[1/N] {问题标题}**
涉及改动：{一句话说清楚要改哪里}
背景：{为什么这里有歧义，一句话}

选项：
A. {最合理的默认项}
B. {合理替代}
C. {第三项，如有}

---

**[2/N] ...**

---
全部回复后开始执行，格式如「1-A, 2-B」

规则：

• 选项最多 3 个，A 是推荐默认项，B/C 是合理替代
• 二选一时只给 A/B，不填废选项
• 所有 [PM确认] 项收到明确答复后，才进入步骤5 执行
• 不允许带未确认假设执行任何改动

步骤5：执行 PRD 修改

修改原则：不创建新文件，直接在当前 PRD 中修改，修订日志追加新记录。

| {日期} | v1.{N} | 评审后修改：修复{N}个问题（{n} Critical + {n} Major） | 全模块 | AI_PM | 基于评审报告v{N} |

步骤5.5：pm-agent 段落回归扫描

Step 5 执行完毕后自动触发，无需用户手动发起。

扫描范围：只扫本次被修改的段落，不全文扫描。

对被修改的每个段落，检查以下 5 类越界：

越界判断原则：区分「提及」和「定义」

• PM 写「状态码由研发定义后补充」→ 不越界（PM 在移交决策权）
• PM 写「返回 HTTP 404 状态码」→ 越界（PM 在定义技术实现）

输出格式：

## 修改后 pm-agent 段落扫描

本次修改段落：{段落列表}（共 N 段）

⚠️ {段落位置}
  原句：「{原文}」
  问题：{越界类型}
  建议改为：「{改写建议}」
  → 保留原句 / 接受建议改写

✅ {段落位置} — 未发现越界

无越界时只输出：✅ 所有修改段落符合 pm-agent 标准。，不输出其他内容。

步骤6：询问是否再次评审

修改完成。Critical 问题：{n}/{n} 已解决。
是否进行下一轮评审？回复"再次评审"或"确认完成"。

问题格式

每个问题按以下结构输出：

#### 问题 {编号}: {标题}
- **严重程度**: Critical / Major / Minor
- **评审角色**: {角色名}
- **涉及模块**: {模块}
- **问题描述**: {详细描述}
- **修改建议**: {具体做法}
- **参考依据**: {依据，如法规/规范/最佳实践}

严重程度：

• Critical：影响核心功能或存在重大风险，必须修改，阻塞发布
• Major：影响体验或存在明显缺陷，建议修改
• Minor：细节优化，可选修改

输出格式

# 需求评审报告 - 第{N}轮

## 评审概览
- 评审时间：{日期}
- 评审对象：{产品名} PRD v{X.X}
- 评审结论：{通过 / 有条件通过 / 需修改后再评审}

## 评审统计
| 角色 | Critical | Major | Minor | 总计 |
|------|----------|-------|-------|------|
{每个角色一行}
| 总计 | {n} | {n} | {n} | {n} |

## Critical 问题（必须修改）
{按问题格式逐一列出}

## Major 问题（建议修改）
{按问题格式逐一列出}

## Minor 问题（可选优化）
{按问题格式逐一列出}

## 评审结论
- [ ] 通过 — 无需修改或仅 Minor，可进入开发
- [ ] 有条件通过 — 修改 Major 后可进入开发
- [x] 需修改后再评审 — 修改 Critical/Major 后进行下一轮
- [ ] 不通过 — 存在重大缺陷，需重新设计

终轮通过标准

• Critical 问题全部解决
• Major 问题解决率 >= 80%
• 未新引入 Critical 问题