القائمة
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 显式写一行「{日期} 评审：本次无新拍约定」——空着不算做过。这一步不做，评审不算收口。