메뉴
PRD 或原型已写完，需要模拟正式评审会议、让六大角色出评审意见时使用（区别于 multi-perspective-review 的设计阶段审查）。 当用户说「评审PRD」「需求评审」「PRD有没有问题」「帮我挑毛病」「技术评审」「开评审会」 「PRD走查」「需求质量检查」「PRD评审报告」时，立即使用此技能。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
战略沙盘 skill。用于高阶产品战略推演、智囊团对话、项目级或产品级多项目战略议题讨论，帮助用户在正式规划、汇报或决策前拆解问题、暴露假设、进行多视角交锋和表达预演。Use when the user asks for 战略沙盘、战略推演、智囊团、产品战略、下一阶段方向、资源取舍、产品级战略、多项目推演、增长瓶颈、竞争应对、用户心智、组织协同、汇报前战略预演，或使用 `/ai-pm strategy` / `/ai-pm-strategy`。
数据分析技能。提供数据指标设计、数据洞察分析、仪表盘生成三大能力。从数据中发现产品需求和优化机会。 当用户说「分析数据」「上传Excel」「数据洞察」「数据可视化」「做仪表盘」「数据看板」 「指标设计」「埋点方案」「从数据里找需求」「数据报表」时，立即使用此技能。
PRD 生成技能。整合需求分析、竞品研究、用户故事，输出完整的产品需求文档。支持产品分身写作风格和设计规范。 当用户说「生成PRD」「写PRD」「产品需求文档」「需求文档」「功能规格书」「输出PRD」 「帮我写需求」「把需求整理成文档」时，立即使用此技能。
原型生成技能。基于 PRD 生成可交互的单页网页原型，支持移动端和 Web 端。 首次生成时询问设计规范（公司规范 / AI 情境定制 / 主流组件库），项目内记住偏好。 若项目存在 Codex 生成的视觉锚点包（06-prototype-visual/manifest.json），生成 HTML 前必须读取并遵循。 当用户说「生成原型」「做原型」「可交互原型」「HTML原型」「页面原型」「低保真」「高保真原型」 「画个界面」「把PRD做成原型」时，立即使用此技能。 边界：本技能用于「把已有 PRD/需求做成可评审原型」；脱离 PRD 的纯视觉探索、通用 UI 组件生成或视觉精修，可使用外部 impeccable 增强，但 AI_PM 原型默认以 ai-pm-frontend-design 为本地设计内核。
当需要从零开始走完完整产品立项流程（需求→分析→竞品→用户故事→PRD→原型→评审）时使用。 支持多项目管理和断点续传，复杂需求可启用多代理协作。 当用户说「我有个产品想法」「帮我做个产品」「从零开始做需求」「全流程出PRD」 「做一个App/小程序/系统」「产品立项」「继续上次的项目」「切换项目」时，立即使用此技能。
去除中文文本里的 AI 腔，让文字像真人直白写出来的。针对中文语境的真·AI tell： 工整对仗排比、"通过X实现Y"、范畴词冗余（进行了优化/起到…作用）、互联网黑话堆砌 （赋能/抓手/闭环/颗粒度）、强行升华结尾、程度副词通胀、空泛连接词、规整书面腔。 并压住"去 AI 味后滑向文青腔/段子腔"的冲动——目标是直白大白话，不是有文采。 可选用本机真实语料把文字校准到具体某个人的声音。
| 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：
{项目目录}/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（产品） | 运营 | 冷启动策略、运营工具、数据埋点 |
读取 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 条}
### 本产品已知踩坑
{知识库匹配条目，每条仅列：坑名 + 问题场景一句话 + 解决方案要点}
调用 Agent 工具，同时派发 2 个 subagent，每个 prompt 以上方 业务背景 块开头：
Subagent 1 — 技术视角（前端开发 + 后端开发 + 测试）
{project_dir}/_tmp/review_tech-{项目名}.md（项目内唯一名，跑前 rm 旧文件——/tmp 通用名跨项目会串稿，PITFALL 同族 pitfall_subagent_tmp_collision）Subagent 2 — 产品视角（产品经理 + 设计 + 运营）
{project_dir}/_tmp/review_product-{项目名}.md（同上，项目内唯一名）评审纪律（所有角色共用）：
设计角色附加：排版原则审查
对原型 HTML 逐项检查以下六条排版原则，每条给出 ✅/⚠️/❌ + 问题描述 + 修复建议：
主线程等待 2 个 subagent 完成后：合并结果，去重（多角色提及同一问题则合并并注明来源），按 Critical → Major → Minor 排序。
生成 08-reviews/08-review-report-{版本标识}.md（文件夹制，与 phase-8 同契约），输出问题汇总和修改建议。
用户选择修改策略（全部修改 / 核心修改 / 最小修改 / 指定修改）后，为每项改动标注类型：
[直接执行] — 答案唯一、无业务歧义：
[PM确认] — 涉及业务规则，PM 才有答案，合理假设不止一种：
向用户展示修改计划，每项前缀标注类型：
修改计划（共 {N} 项，其中 {n} 项需你确认）：
[直接执行] 问题2：§3.1 题卡合一优先级 P1→P0 矛盾修正
[PM确认] 问题1：坐标转置失败的用户侧行为
[直接执行] 问题3：§4.3 第三方答题卡影响范围措辞修正
...
若修改计划中存在 [PM确认] 项，触发此步骤；全部为 [直接执行] 则跳过，直接进入步骤5。
按以下格式逐项呈现，等待用户全部回复后再执行：
## 执行前需你确认（{N} 项）
**[1/N] {问题标题}**
涉及改动：{一句话说清楚要改哪里}
背景：{为什么这里有歧义，一句话}
选项：
A. {最合理的默认项}
B. {合理替代}
C. {第三项，如有}
---
**[2/N] ...**
---
全部回复后开始执行，格式如「1-A, 2-B」
规则：
[PM确认] 项收到明确答复后，才进入步骤5 执行修改原则：不创建新文件，直接在当前 PRD 中修改。修订日志是否 +V1.x 按判断卡 §八判断：首评周期内（含落实评审决议的轮次）全部熔进 V1.0 不单列；只有定稿后再次正式发给研发/评审的修订才 +V1.x。
（仅当"定稿后再次正式发出"时才追加一行，例：）
| {日期} | V1.1 | 评审后修订：修复{N}个问题（{n} Critical + {n} Major） | 全模块 | {作者} | 定稿后按评审报告v{N}修订再发 |
（首评周期内的修改：不加行，熔进 V1.0 基线。）
Step 5 执行完毕后自动触发，无需用户手动发起。
扫描范围：只扫本次被修改的段落，不全文扫描。
对被修改的每个段落，检查以下 5 类越界：
| 类型 | 典型越界写法（举例） |
|---|---|
| 技术实现 | 接口路径/字段名/枚举值/数据库表/状态码具体值 |
| 视觉细节 | 像素/色号/动效毫秒/hover/fade 等动画词 |
| 算法实现 | 模型名/chunk_size/RAG检索器/prompt文案 |
| 研发自决 | 接口超时/schema校验/缓存未命中/重试次数 |
| 用户话术 | 版本号（V1.x）/上线时间/「下个迭代」 |
越界判断原则：区分「提及」和「定义」
输出格式：
## 修改后 pm-agent 段落扫描
本次修改段落：{段落列表}（共 N 段）
⚠️ {段落位置}
原句：「{原文}」
问题：{越界类型}
建议改为：「{改写建议}」
→ 保留原句 / 接受建议改写
✅ {段落位置} — 未发现越界
无越界时只输出：✅ 所有修改段落符合 pm-agent 标准。，不输出其他内容。
修改完成。Critical 问题：{n}/{n} 已解决。
是否进行下一轮评审？回复"再次评审"或"确认完成"。
每个问题按以下结构输出：
#### 问题 {编号}: {标题}
- **严重程度**: Critical / Major / Minor
- **评审角色**: {角色名}
- **涉及模块**: {模块}
- **问题描述**: {详细描述}
- **修改建议**: {具体做法}
- **参考依据**: {依据，如法规/规范/最佳实践}
严重程度：
# 需求评审报告 - 第{N}轮
## 评审概览
- 评审时间：{日期}
- 评审对象：{产品名} PRD v{X.X}
- 评审结论：{通过 / 有条件通过 / 需修改后再评审}
## 评审统计
| 角色 | Critical | Major | Minor | 总计 |
|------|----------|-------|-------|------|
{每个角色一行}
| 总计 | {n} | {n} | {n} | {n} |
## Critical 问题（必须修改）
{按问题格式逐一列出}
## Major 问题（建议修改）
{按问题格式逐一列出}
## Minor 问题（可选优化）
{按问题格式逐一列出}
## 评审结论
- [ ] 通过 — 无需修改或仅 Minor，可进入开发
- [ ] 有条件通过 — 修改 Major 后可进入开发
- [x] 需修改后再评审 — 修改 Critical/Major 后进行下一轮
- [ ] 不通过 — 存在重大缺陷，需重新设计
跨模型意见（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 显式写一行「{日期} 评审：本次无新拍约定」——空着不算做过。这一步不做，评审不算收口。