--- name: prd-multi-role-review description: > 当用户要求对 PRD / 产品需求文档做多角色 review、stakeholder 视角审查、 跨职能 sanity check、或在 PRD 进入实现前做最后一轮把关时使用。 并行 spawn 8 个 subagent，每个扮演一个角色（产品 / 架构 / 安全 / UX / 工程 / QA / 运维 / Red Team），独立给出 finding，主进程聚合 + 找跨角色 Top Blocker。 与 doc-review（工程实现就绪度 4 lens）正交：本 skill 关注"产品/业务/合规层 多角色挑刺"，doc-review 关注"工程从 0 实现卡不卡"。 与 plan-review（实施方案 4 section）正交：本 skill 在 PRD 阶段，plan-review 在方案落地阶段。 触发短语：多角色审 PRD、跨职能 review、stakeholder review、PRD 多视角审查、 PRD multi-role review、各种角色审一遍、prd-multi-role-review。 --- # PRD 多角色并行审查技能 ## 定位 PRD 写完 / 大改后准备进入 PR 实施前，**用 8 个不同角色的 lens 并行审一遍**， 找出单一作者视角看不到的盲点。每个角色独立 spawn subagent，避免在主上下文里 "自己跟自己辩论"造成的视角混淆。 **核心 insight**：作者写 PRD 时永远在「自己的视角」里。多角色 review 不是 让一个人切换视角假装审 8 次（这做不到），而是真的分配到 8 个独立上下文里 各审一次再聚合。 ## 与现有 skill 的边界 | Skill | 何时 | 审什么 | 视角 | |---|---|---|---| | **本 skill** | **PRD 完成 → 进入实施前** | **产品价值 / 业务可行性 / 跨职能盲点** | **8 个独立角色并行** | | `doc-review` | 模块文档全套写完 → 开干代码前 | 工程实现就绪度（够不够支撑写代码）| 工程内部 4 个 lens | | `plan-review` | 有具体实施方案 → 写代码前 | 架构 / 代码质量 / 测试 / 性能 | 工程方案 4 section | | `docs-main` §3 | 任何时候 | 文档之间一致性（drift / 死链）| 静态校验 | **典型组合（推荐执行顺序）**： 1. 写完 PRD → **`prd-multi-role-review`**（本 skill，多角色把关业务+合规+UX） 2. 本 skill 发现的 🔴/🟡 改完 → `doc-review`（工程实现维度，4 lens） 3. 都过 → `plan-review`（具体方案落地前最后一审）→ 开干 ## 何时使用 / 不该使用 **使用本 skill**： - 新模块全套 PRD（顶层 + 各 phase）刚写完 - 大功能 PRD 大改 → 准备 review 卡点签字前 - 用户说"多角度审一遍"、"各种角色看看"、"stakeholder review" - PRD 即将进入 [`docs/standards/14-feature-request-workflow.md`](../../docs/standards/14-feature-request-workflow.md) 的 review 卡点 **不要用本 skill**： - 单字段 / 文风 tweak → 用 `docs-main` - PRD 还没写 / 只写了一半 → 太早，先 `plan-feature` 写完 - 审具体实施方案 / 代码方案 → 用 `plan-review` - 审"够不够实现"工程维度 → 用 `doc-review` ## 8 个角色定义 每个角色是**独立 subagent**，拿到完整 PRD 内容 + 角色 charter + 输出格式约束。 | # | 角色 | 关注什么 | 典型 finding | |---|---|---|---| | 1 | **产品负责人** | Vision 是否清晰 / Persona 是否真实 / North star 选择 / 优先级判据 / 价值主张 / 不做清单合理性 | "north star 是任务完成率，但没定义'有效解'" | | 2 | **架构师** | 与已有架构一致性 / 设计原则落实 / 不变量可执行性 / 阶段切分合理性 / 跨阶段技术债 | "INV-2 用户身份继承在 cron isolated agent 场景没说怎么办" | | 3 | **安全 / 合规** | 数据隔离 / 审计 / 鉴权 / 第三方 ToS / 威胁模型 / 数据归属 / PII / 审批留痕 | "AAD ↔ FFAI Identity 映射首次配对挑战的安全边界没说" | | 4 | **UX / 设计** | 用户故事完整性（边界/失败/空数据）/ 验收可观察 / i18n / 无障碍 / 跨端一致 | "US-101 没说 0 项目延期时怎么显示，空数据态缺规格" | | 5 | **工程负责人** | PR 拆分可行性 / 工作量估算 / capacity / 跨模块依赖 / 启动顺序 / 关键路径 | "PR4.5 依赖 PR4 完成，但 PR4 含 5 层 Compaction 的工作量估低了" | | 6 | **QA** | 验收标准是否可测 / 测试金字塔覆盖 / 性能/安全测试 / 回归 / 数据准备 | "BDD '5 秒内出表格' 没说具体测试环境基线" | | 7 | **运维 / SRE** | 部署模式 / 监控 / quota / SLO / 故障恢复 / 灰度 / 日志 / 容量规划 | "ModelRouter 月度成本告警阈值谁定 / 触发后谁响应没说" | | 8 | **Red Team** | 故意刁钻：找漏洞 / 攻击 vision / 假设挑战 / 用户拒绝场景 / "为什么这个会失败" | "Vision 假设员工会用自然语言提审批，但 50% 老员工只会点表单" | ## 核心工作流 ### Step 0 — 输入收集 用户应提供： - 要审的 PRD 路径列表（一份顶层 + N 份阶段 PRD，或单份） - （可选）业务背景 / 已知关注点 / 想 skip 的角色 如未提供，用 `ls docs/modules//01-prd*.md` 列候选请用户选。 ### Step 1 — 主进程预处理 **目的**：减少 8 个 subagent 重复读 PRD 的 token 浪费。 主进程做： 1. 读完所有要审的 PRD（一次性 Read） 2. 生成 **共享上下文摘要**（300-500 字），含： - 模块定位 / Vision 一句话 - Persona + 核心场景列表（不展开） - 阶段地图（Phase 数量 + 每 phase 业务范围一行） - 关键不变量 / 不做清单 - 当前已 review 的 PR 卡点 / 已决策项 3. 准备 8 份 prompt（见 §「角色 Prompt 模板」） ### Step 2 — 8 个 Agent 并行 spawn（关键步骤） **必须在单条消息里同时发 8 个 Agent 工具调用**——并行不是顺序，否则失去 multi-perspective 的核心价值（每个角色受前一角色 finding 污染）。 每个 subagent 调用： - `subagent_type: "general-purpose"`（无专门 role agent，用通用） - `description`: `"PRD review by <角色名>"` - `prompt`: 完整角色 charter + PRD 全文 + 输出格式约束（见 §「角色 Prompt 模板」） **关键约束**（写进每个 subagent prompt）： - subagent 必须只用自己角色的 lens，不要替其他角色想 - 输出严格按 🔴/🟡/🟢 三级 + 引用 PRD 行号 - 每级最多 5 项（防止 finding inflation） - 不要建议改文档（主进程聚合后由用户决定） ### Step 3 — 主进程聚合 收齐 8 份 finding 后做 4 件事： 1. **按角色分组展示**（每角色独立 section） 2. **跨角色 Top Blockers**：同时被 ≥ 2 个角色标 🔴 的 finding 提取出来，作为 PRD 进入实施前**必须解决**的清单 3. **冲突识别**：不同角色给相反建议时显式标注（如「产品要 north star = 任务 完成率，但 QA 说不可测」），让用户决策 4. **覆盖度自检**：8 个角色全部跑通；如某角色返回 "无 finding" 也要标注 （可能是 PRD 这维度真稳，也可能是 prompt 没击中） ### Step 4 — 收敛建议 按 finding 总数判定： | Top Blockers | 跨角色 🔴 总数 | 建议 | |---|---|---| | 0 | ≤ 5 | **可进入 doc-review**（工程维度审一轮再开干）| | 1-2 | 5-10 | 改完 Top Blockers + 主要 🔴 → 重审本 skill 跑第二轮 | | ≥ 3 | > 10 | PRD 有结构性问题 → 回 `plan-feature` 做需求重梳 | **何时建议停审**：8 角色都跑过 1 轮 + Top Blockers ≤ 1 + 用户明确开干意愿。 **何时建议继续**：Top Blockers ≥ 3 或冲突 ≥ 2 个未解决。 ## 角色 Prompt 模板（写进 Agent.prompt 里） 每个角色的 prompt 模板**必须包含 5 段**： ``` 你是 <角色名>，正在 review 一份 PRD。 ## 你的角色 charter <3-5 句话，定义这个角色关心什么、不关心什么、典型 finding 长什么样> ## 共享上下文摘要 <主进程预处理生成的 300-500 字摘要> ## PRD 全文 <完整 PRD 内容> ## 输出格式（严格遵守） 按 🔴/🟡/🟢 三级输出 finding，每级最多 5 项： 🔴 必须改（实施前必须解决，否则<本角色视角>会出大问题） 1. <标题> - 位置：: - 问题：<具体描述，1-2 句> - 修法：<具体改成什么> 🟡 该改（能跑但有 bug / 后续埋坑） ... 🟢 可选优化 ... ## 关键约束 - 只用 <你的角色> lens，不要替其他角色想 - 引用 PRD 具体行号 - 每级 ≤ 5 项；不要为凑数制造 finding - 不要建议改 PRD 文档（主进程聚合后由用户决定） - 如某层真无 finding，明确写"无" ``` ### 8 个 charter（直接复制进 prompt） **1. 产品负责人** > 你只关心：① Vision 一句话能不能讲清产品是什么、② Persona 是否真实存在 > 且优先级排得对、③ North star metric 选得对不对（活跃 vs 价值 vs 质量）、 > ④ 优先级判据是否经得起推敲（为什么 P0 不是 P1）、⑤ 价值主张能否打败外部 > 对标产品、⑥ "不做清单"是不是真的下决心不做。 > 你不关心：技术实现 / 测试覆盖 / 部署细节。 **2. 架构师** > 你只关心：① PRD 描述的功能/不变量 是否跟已有架构（02-architecture.md 等） > 一致、② 阶段切分是否技术上合理（前置依赖 / 不变量在每个 phase 都站得住）、 > ③ 跨阶段技术债（Phase 1 这么做，到 Phase 2 会不会要重构）、④ 设计原则 > （G1-Gn）有没有在 PRD 里被默默违反、⑤ 横切关注点（i18n / quota / 错误恢复） > 在 PRD 里有没有最小约束。 > 你不关心：UI 细节 / 业务话术 / 单个 PR 工作量。 **3. 安全 / 合规** > 你只关心：① 数据隔离（多组织 / 多租户）/ ② 鉴权链路（用户身份继承 / 权限 > 越权可能性）/ ③ 审计可追溯（所有动作可回放？审计字段是否不可篡改）/ > ④ 第三方 ToS（接外部 LLM/API 是否合规、数据出境）/ ⑤ 威胁模型（prompt > injection / 凭据泄漏 / 沙盒逃逸）/ ⑥ PII 处理 / ⑦ 数据归属（用户文件存哪、 > 删除策略）。**特别盯**：跨组织、跨用户、跨设备的边界。 > 你不关心：性能 / UX / 工时。 **4. UX / 设计** > 你只关心：① 用户故事是否覆盖完整路径（含正常 + 边界 + 失败 + 空数据 + > 无权限态）、② 验收标准是否可观察（"5 秒内"这种数字怎么测）、③ i18n / 多 > 语言 / 无障碍（a11y）支持、④ 跨端体验一致性（Web/Desktop/Mobile/Teams > 关键路径同等便利）、⑤ 错误态文案 / 加载态 / 空数据态规格、⑥ 用户认知 > 负担（首次用户怎么 onboarding）。 > 你不关心：架构 / 数据模型 / 部署。 **5. 工程负责人** > 你只关心：① PR 拆分是否可独立交付（每个 PR 自洽）、② 工作量估算是否合理 > （这种规模的 PR 通常多少工时）、③ 跨模块依赖（依赖的业务 Service 准备好 > 了吗）、④ 关键路径上的卡点（哪个 PR 卡住会让全链路停滞）、⑤ 启动顺序 > （onModuleInit 顺序 / 数据 seed 顺序）、⑥ 团队 capacity（人手够不够）/ > 是否需要外部技能（如 iOS 原生工程师）。 > 你不关心：业务话术 / UI 细节 / 单元测试 happy path。 **6. QA** > 你只关心：① 验收标准是否可测（写得出 BDD 吗）、② 测试金字塔覆盖（L0 契约 > / L1 集成 / L2 E2E / L3 人工 是否都规划了）、③ 性能 / 安全 / 兼容性测试 > 需求、④ 测试数据准备（mock LLM / seed / 跨组织数据隔离测试）、⑤ 回归覆盖 > （新功能上线后老功能怎么跑）、⑥ 灰度策略 + 回滚验证。 > 特别盯：写在 PRD 里的"5 秒内"、"≥ X%"等数字到底怎么测。 > 你不关心：架构内部分层 / 业务话术。 **7. 运维 / SRE** > 你只关心：① 部署模式（单实例 / 多实例 / 容器编排）、② 监控告警（关键指标 > dashboard / alert 阈值 / 谁响应）、③ Quota / 限流（per-user / per-org / > 全局 / 超限策略）、④ SLO（首字延迟 / API p99 / 可用性）、⑤ 故障恢复（进程 > 崩溃 / 上游断 / 数据中间态）、⑥ 灰度上线策略、⑦ 日志（保留 / 检索 / 隐私）/ > ⑧ 容量规划（用户增长 N 倍后哪里先垮）。 > 你不关心：UI 视觉 / 业务流程合理性。 **8. Red Team（刁钻视角，专门挑刺）** > 你的工作是**让作者难堪**。质问： > ① Vision 假设有没有可能整个错（"你假设员工愿意用自然语言提审批，但 50% > 老员工只会点固定表单怎么办"）、② Persona 真的会用吗（"项目经理已经有 X > 工具习惯了，凭什么换"）、③ "三件套"是不是因为容易做才选的，不是因为价值 > 高、④ 验收标准能不能被刷数据（"DAU 高但每会话只问 1 句话"）、⑤ 不变量 > 哪条最容易被现实击穿、⑥ 哪个里程碑最可能 miss / 时间表是否乐观、⑦ 给作者 > 找一个"上线 3 个月后这个产品被砍掉"的剧本，倒推哪里最可能崩。 > 你不需要"建设性"——找问题就够了。 ## 输入要求 - 要审的 PRD 路径（绝对路径或相对项目根） - （可选）业务背景 / 已知关注点 / skip 哪些角色 ## 输出要求 - 8 个角色独立 section，按 🔴/🟡/🟢 输出 - 跨角色 Top Blockers（≥ 2 角色标 🔴 的）单独 section - 冲突识别 section（角色之间相反建议） - 收敛建议（开干 / 重审 / 重梳） ## 反模式（避免） - ❌ **顺序跑 8 个角色而不是并行** → 后角色被前角色污染，失去 multi-perspective 价值 - ❌ **把 8 个角色 prompt 塞主上下文让自己审 8 次** → 一个上下文做不到真正切换角色 - ❌ **每个角色 prompt 不带 PRD 全文，让 subagent 去 Read** → 8 次重复 Read 浪费 token - ❌ **finding 不带 PRD 行号** → 用户没法定位 - ❌ **finding 数量不限** → finding inflation，用户找不到重点（每级 ≤ 5 项强制） - ❌ **审完直接擅自改 PRD** → 越权，应由用户决策 ## 收敛与重跑建议（dogfood 实验更新，2026-05-16） **修正旧反模式**：早期 SKILL.md 写"同 lens 跑两次信号增量 ≈ 0"——dogfood 实验（FFAI Agent 模块 4 份 PRD）证实**这是错的**： - **Round 1**（v0.3 PRD）：~115 finding（40🔴 + 40🟡 + 35🟢） - **Round 2 纯重跑**（v0.4 PRD，已应用 Round 1 finding）：~150 finding，**重复率仅 8%，新发现 80+** **为什么信号增量不为零**（三个机制）： 1. PRD 在两轮之间被改动 → 新内容引入新缺口（如 PR12.5 引入"政治前置"问题、SLA 三段拆分引入"hard threshold vs p95 矛盾"问题等） 2. LLM 非确定性 + 角色 charter 引导探索不同路径（同样产品负责人 charter 第二次会盯到不同的薄弱处） 3. 上一轮 finding 应用后让"原来的小问题"变成"现在的真问题"（如修了 INV-1 SLO 措辞引出"季度统计 SLO 不可证伪"的更深问题） **新的收敛建议**（基于 4 轮 dogfood 实验更新 2026-05-16，见 learning 文件）： 实测数据反驳了"边际收益快速递减"假设——**PRD 不变 + 纯 LLM 非确定性 → 每轮仍贡献 ~50 真新 finding 稳态**。 | 轮次 | finding 性质 | 应用方式 | 推荐 | |---|---|---|---| | R1 | "表面 PRD 缺漏" | 直接 Edit | **必跑** | | R2 | "v_n+1 引入新缺口 + 中层缺漏" | Edit | **必跑** | | R3 | "深层 PRD 矛盾 + 跨文档 drift" | Edit + 一致性修正 | **建议跑** | | R4 | "混合：缺漏 + 战略 trade-off + meta-finding" | 分类处理 | **关键 PRD 跑** | **真正的"停跑"信号**（不是 finding 数量阈值，是 finding 性质变化）： 1. ✅ **出现 meta-finding**（质疑实验/方法论本身）→ 已经挖到方法论层 = 该停 2. ✅ **Top P0 比例 ≤ 30% + 战略 trade-off 占比上升** → 不再是 PRD 问题 3. ✅ **持续 N 轮真新数稳定（不再衰减）** → 进入 LLM 非确定性 baseline，再跑也是同样数量级 4. ✅ **用户明确 ship 意愿** **轮次推荐**： - 简单 PRD（< 500 行）：2 轮足够 - 标准 PRD：**3 轮起，4 轮上限**（4 轮通常会出现 meta-finding 信号） - 关键 PRD（核心模块 / vision）：4 轮 + 在 R4 之后召开人类 stakeholder review（AI 闭环再多轮也补不上"异步思考时间"维度） **关键 anti-pattern**： - ❌ 基于 1-2 个数据点修正反模式条目（dogfood 已验证：R0 直觉错 → R2 修正错 → R3 修正错 → R4 才稳） - ❌ 承诺"