| 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/、04-user-stories/（各取最新 V）
输出
{项目目录}/08-reviews/08-review-report-{版本标识}.md（评审报告，文件夹制）→ 更新 PRD
六大评审角色
| 组别 | 角色 | 评审重点 |
|---|
| 组1（技术） | 前端开发 | 交互实现可行性、组件复用、前端工作量 |
| 组1（技术） | 后端开发 | 接口设计、数据模型、性能与工期 |
| 组1（技术） | 测试 | 可测试性、验收标准、边界与异常场景 |
| 组2（产品） | 产品经理 | 需求完整性、用户价值、优先级与 MVP 边界 |
| 组2（产品） | 设计 | 用户体验、交互流程、视觉一致性 |
| 组2（产品） | 运营 | 冷启动策略、运营工具、数据埋点 |
执行步骤
步骤1：读取评审材料 + 加载业务上下文
读取 PRD、原型、需求分析、用户故事，确定评审轮次（--round 参数，默认第1轮）。
同时加载业务上下文（用 test -f 检查，存在则读取，不存在静默跳过）：
_memory/L0-identity.md — 产品定位、目标用户、核心约束_memory/L1-decisions.md — 最近 5 条关键决策（避免把已决策的事当问题提）_memory/L2-prd-versions.md — 历史 PRD 版本摘要（知道哪些功能已在 V1/V2 覆盖）- 知识库相关条目 — 从
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 和原型，输出三个角色各自的评审意见
- 输出至：
{project_dir}/_tmp/review_tech-{项目名}.md（项目内唯一名，跑前 rm 旧文件——/tmp 通用名跨项目会串稿，PITFALL 同族 pitfall_subagent_tmp_collision）
Subagent 2 — 产品视角（产品经理 + 设计 + 运营）
- 系统提示：同时扮演产品经理、设计、运营三个角色，不与用户交互
- 任务：结合业务背景读取 PRD 和原型，输出三个角色各自的评审意见
- 输出至：
{project_dir}/_tmp/review_product-{项目名}.md（同上，项目内唯一名）
评审纪律（所有角色共用）：
- 「业务背景」中已覆盖的历史版本功能，不作为本次缺失问题提出
- 评审意见必须基于目标用户的实际角色（L0 中定义的）；若 PRD 用户与 L0 定义冲突，应指出矛盾而非凭空假设用户行为
- 已知踩坑中有对应条目的问题，直接引用坑名而不重复展开，节省篇幅
- 不建议超出本期需求范围的新功能（判断依据：L1 决策 + 版本摘要 + PRD 背景章节）
设计角色附加：排版原则审查
对原型 HTML 逐项检查以下六条排版原则，每条给出 ✅/⚠️/❌ + 问题描述 + 修复建议：
- 留白呼吸 — 内容覆盖率是否在 60-70%？是否有挤满的区域？
- 对比与缩放 — 标题层级是否有 2+ 维度差异（字号+字重+颜色）？眯眼测试能否区分层级？
- 亲近与分组 — 标题是否离下方内容更近而非上方？列表间距是否 < 段间距？
- 对齐与网格 — 是否存在未对齐的元素？中文段落是否两端对齐？
- 重复与一致 — 同级元素是否使用相同样式？是否有孤立格式（仅一处加粗、仅一处用不同色）？
- 视觉层次 — 用户视线路径是否清晰？关键操作按钮是否突出？
主线程等待 2 个 subagent 完成后：合并结果，去重（多角色提及同一问题则合并并注明来源），按 Critical → Major → Minor 排序。
步骤3：生成评审报告
生成 08-reviews/08-review-report-{版本标识}.md（文件夹制，与 phase-8 同契约），输出问题汇总和修改建议。
步骤4：生成修改计划（含分类标注）
用户选择修改策略（全部修改 / 核心修改 / 最小修改 / 指定修改）后，为每项改动标注类型：
[直接执行] — 答案唯一、无业务歧义：
- 文字矛盾修正（如优先级前后不一致）
- 现有逻辑的格式补全（如将"与V1/V2一致"扩写为中文句式验收标准——禁用 Given/When/Then 英文格式，PITFALL-031）
- 结构性新增（附录扩列、新增章节标题等）
[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.x 按判断卡 §八判断：首评周期内（含落实评审决议的轮次）全部熔进 V1.0 不单列；只有定稿后再次正式发给研发/评审的修订才 +V1.x。
（仅当"定稿后再次正式发出"时才追加一行，例：）
| {日期} | V1.1 | 评审后修订：修复{N}个问题（{n} Critical + {n} Major） | 全模块 | {作者} | 定稿后按评审报告v{N}修订再发 |
（首评周期内的修改：不加行，熔进 V1.0 基线。）
步骤5.5：pm-agent 段落回归扫描
Step 5 执行完毕后自动触发，无需用户手动发起。
扫描范围：只扫本次被修改的段落，不全文扫描。
对被修改的每个段落，检查以下 5 类越界：
| 类型 | 典型越界写法（举例） |
|---|
| 技术实现 | 接口路径/字段名/枚举值/数据库表/状态码具体值 |
| 视觉细节 | 像素/色号/动效毫秒/hover/fade 等动画词 |
| 算法实现 | 模型名/chunk_size/RAG检索器/prompt文案 |
| 研发自决 | 接口超时/schema校验/缓存未命中/重试次数 |
| 用户话术 | 版本号（V1.x）/上线时间/「下个迭代」 |
越界判断原则：区分「提及」和「定义」
- 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 问题
评审收口必做（forced-artifact，Stage3-A4 · 2026-07-12 挂点）
跨模型意见（D3①）：评审开工先查 .ai-shared/review-exchange/inbox-codex/ 有无 Codex 意见待并入；收口时若产生给 Codex 的问题，写 inbox-claude/ 并登记 ledger——不让用户当消息总线。
外部反馈回灌（D3③）：研发疑问（截图/群消息）、线下评审结论，逐条录入项目 08-reviews/feedback-ledger.md（| 日期 | 来源 | 反馈 | 处置 | 销账日期 |）——评审真身在线下，外部反馈是比 AI 评审意见更值钱的输入；PRD 修订前先清这本台账。
评审结束（无论通过与否）必须执行约定包 §6 live 回写：本次评审新拍的术语、口径、被推翻的旧约定，逐条写入项目 _conventions.md §6（带日期+来源"评审 {日期}"）；无新增则在 §6 显式写一行「{日期} 评审：本次无新拍约定」——空着不算做过。这一步不做，评审不算收口。
