设计审查门 Skill：让五个 AI 专家并行评审设计文档，在写下第一行代码前就把风险挡住
- 一句话定位：design-review-gate 是一个“自动审查门”技能，在头脑风暴和设计文档成型后自动触发，并行拉起产品经理、架构师、设计师、安全设计、CTO 五个专业代理，全部批准才放行进入实施。
- 核心机制：五代理并行审查 + 结构化 JSON 判决（APPROVED / NEEDS_REVISION）+ 最多 3 轮迭代 + 第 4 轮升级给人类决策（覆盖、延迟、修订或取消）。
- 最大差异点：不是“写完代码再评审”，而是把评审前移到设计文档阶段，用多角色视角替代单一 AI 自查，避免“自己审自己”。
- 落地方式：设计文档落到
docs/plans/*-design.md即自动激活，也可手动调用/project:review-design <路径-到-design.md>；批准后可直接联动 BEADS 创建史诗与分阶段任务。 - 适合谁用：需要严格设计把关的中大型功能开发团队、独立开发者、以及对安全与 TDD 准备度有硬性要求的项目。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：设计审查门 Skill 技能英文名：design-review-gate 技能ID：13661
它解决什么问题
在真实研发流程里，最贵的返工往往不是写错一行代码，而是在设计阶段就埋下坑：用例没想清楚、架构与现有代码库风格冲突、API 命名不一致、userId 竟然来自模型输出而不是服务端会话、没有速率限制、没有 TDD 规范……这些问题一旦进入编码阶段，修复成本会成倍上升。
传统做法是开一次设计评审会，但评审会依赖人是否到齐、是否有空、是否看得懂。design-review-gate 的思路是：把评审会变成一道自动闸门——设计文档一提交，五个专业代理同时开工，各出一份结构化评审结论，任何一方不批准，设计就回炉。
一键安装的思路与步骤
该技能属于“自动激活型”技能（详情中标注 自动激活: true），安装与启用思路如下：
- 确认前提环境：需要一个支持技能（Skill）机制与子代理（Task/Subagent）能力的 AI 编程环境，因为该技能依赖并行派发五个
general-purpose子代理。具体支持范围请以官方说明为准。 - 找到技能：在技能市场/技能仓库中以技能ID 13661 或英文名 design-review-gate 检索并安装。安装命令与入口以官方说明为准。
- 确认自动激活生效：安装后，技能会在以下任一条件下自动触发：
- 设计文档被提交到
docs/plans/*-design.md； superpowers:brainstorming技能执行完成之后（after:superpowers:brainstorming）；- 用户显式请求：
/project:review-design <路径-到-design.md>。
- 设计文档被提交到
- 验证是否生效：随便写一份最小设计文档到
docs/plans/目录下，或直接执行/project:review-design指向已有设计文档，若看到五个代理并行产出审查结论并汇总成“批准 / 需要修订”表格，即说明安装成功。 - 准备上下文文件（可选但强烈建议）：架构师代理会参考
docs/BACKEND_SERVICE_GUIDE.md、docs/SERVICE_CREATION_GUIDE.md、docs/SERVICE_INVENTORY.md；CTO 代理会参考docs/TESTING_GUIDE.md、.claude/task-completion-checklist.md、CLAUDE.md。把这些文件补齐，评审结论会显著更贴合你的代码库。
该技能的主要功能和特点
- 五角色并行审查：产品经理（用例与用户收益）、架构师（技术架构与服务边界）、设计师（UX/API 设计与开发者体验）、安全设计（威胁建模与 OWASP Top 10）、CTO（TDD 准备度与代码库对齐）同时开跑，用
Promise.all并行派发，避免串行等待。 - 结构化判决而非模糊意见：每个代理返回统一 JSON，包含
verdict（APPROVED / NEEDS_REVISION）、blockers（实施前必须修复）、suggestions（建议改进）、questions（需澄清），并且 PM 代理额外输出用例统计、安全代理额外输出威胁模型（高/中风险 + 必需缓解措施）。 - 硬性闸门逻辑：五个代理全部 APPROVED 才放行；任一 NEEDS_REVISION 就聚合反馈、呈现给用户、修订设计后重跑，最多 3 轮。
- 人类升级机制：3 轮仍未通过，不再无限打转，而是生成剩余阻塞摘要，交给人选择“覆盖（记录技术债）/ 延迟 / 修订 / 取消”，避免 AI 自嗨式空转。
- 自动触发，不靠自觉：设计文档落到指定路径即自动激活，减少“忘记评审”的人为疏漏。
- 与 BEADS 工作流打通：批准后可自动创建史诗（epic）、按阶段拆任务并添加依赖（阶段1→阶段2→阶段3→阶段4），把评审结论直接转成可执行的实施计划。
- 和普通工具比强在哪：普通 AI 代码审查工具多以“已写好的代码 / PR”为输入，且通常只有一个视角；本技能把评审点前移到设计文档，并用五个互不重叠的专业视角交叉验证，安全与 TDD 这类“容易被忽略但代价极高”的维度被强制纳入。
如何使用该技能？
步骤 1：触发评审
三种方式任选其一：
- 把设计文档保存/提交到
docs/plans/*-design.md（自动触发）； - 先跑
superpowers:brainstorming，其完成后自动接续本技能； - 手动执行：
/project:review-design docs/plans/contact-search-design.md。
步骤 2：准备设计文档内容
设计文档越具体，评审越有用。建议至少包含：用例（WHO / WANTS / SO THAT / WHEN 格式）、价值主张与可度量收益、MVP 范围、成功与失败标准、API 契约、数据与安全处理、测试规范（RED-GREEN-REFACTOR 周期、边缘案例枚举、mock 基础设施）。
步骤 3：等待五代理并行产出结论
技能会并行派发五个审查任务，例如架构师代理关注“是否遵循现有代码库模式、依赖是否成环、命名是否一致”，安全代理则逐项过 OWASP Top 10（A01 访问控制、A02 加密故障、A03 注入等）。
步骤 4：阅读汇总结果
通过时会看到类似表格：
| 代理 | 判决 | 阻塞问题 | 建议 |
|---|---|---|---|
| 产品经理 | 批准 | 0 | 1 |
| 架构师 | 批准 | 0 | 2 |
| 设计师 | 批准 | 0 | 1 |
| 安全设计 | 批准 | 0 | 2 |
| CTO | 批准 | 0 | 3 |
未通过时会明确列出阻塞项，例如：
- [设计师] 缺少错误状态：未说明搜索返回 0 条结果时的表现；
- [设计师] API 命名不一致：
get_contact_details用下划线，而现有 API 用 camelCase； - [安全设计] 关键：
userId信任边界错误，userId必须仅来自服务端会话，模型可能被越狱输出任意userId； - [安全设计] 缺少速率限制，AI 端点成本高，必须限流防滥用；
- [CTO] 缺少 TDD 规范、mock 基础设施与逐方法边缘案例枚举。
步骤 5：修订并重跑
按阻塞项修改设计文档，然后重新执行审查。技能会显示“迭代：1 of 3”这样的进度提示，明确告诉你当前处于第几轮。
步骤 6：批准后进入实施
全部通过后，按输出建议创建 BEADS 史诗与阶段任务，例如：
bd create "<功能名称>" --type epic --json
bd create "阶段1：基础设施" --type task --parent <史诗-id>
bd dep add <阶段2-id> <阶段1-id>
随后可用 superpowers:using-git-worktrees 设置工作树，正式开始阶段 1。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| design-review-gate（设计审查门） | 设计阶段的多角色自动评审闸门 | 五代理并行审查（PM/架构/设计/安全/CTO）、结构化判决、3 轮迭代、人类升级、BEADS 联动 | 需支持技能与子代理的 AI 编程环境；需准备设计文档与项目上下文文件。具体以官方说明为准 | 复杂功能的设计定稿前把关；安全敏感或需严格 TDD 的项目 | 优势：评审前移、视角全面、闸门硬性、结论可结构化流转。不足：依赖设计文档质量，文档写得太空则评审价值打折 |
| 人工设计评审会 | 传统团队评审 | 人基于经验提意见 | 需凑齐人、约时间，沟通成本高 | 高价值核心系统、跨团队决策 | 优势：能拍板、能承担业务判断。不足：费时、结论非结构化、容易遗漏安全与测试维度 |
| 单一 AI 助手自查 | 通用 AI 对话中让模型看看设计 | 单角色给建议 | 门槛最低，随口一问即可 | 小改动、快速自查 | 优势：即时、零成本。不足：单一视角、无强制闸门、无迭代与升级机制、结论难追踪 |
| 代码托管平台 PR 审查机器人 | 代码阶段的自动审查 | 对已提交代码/PR 提意见 | 需接入仓库与权限 | 编码完成后的质量兜底 | 优势：自动化、贴近 diff。不足：已是“事后”，设计层问题改起来最贵；通常不做多角色分工与威胁建模 |
| 自建多代理编排 | 用编排框架自己拼评审流水线 | 完全自定义 | 需自己写提示词、结果聚合、重试逻辑 | 有平台能力的团队 | 优势：高度可定制。不足：开发维护成本高，容易做成“能跑但没人用”的内部工具 |
该技能的典型应用场景与实际体验情况
场景一：产品经理主导的新功能设计 角色：产品经理。痛点：用例写得像需求清单，边缘场景和失败标准常被忽略。使用方式：按 WHO / WANTS / SO THAT / WHEN 写完用例后提交设计文档，PM 代理会输出“总用例数 / 清晰数 / 需返工数 / 缺失场景”，并检查是否存在“功能蔓延”和“为技术找问题”。实际体验：反馈非常具体，比如会直接点出“缺少 0 结果状态”“成功指标不可度量”，比开一次评审会来得更快。
场景二：架构师做服务拆分与集成设计
角色：技术负责人。痛点：新服务与既有服务职责重叠、依赖成环、命名风格漂移。使用方式：确保 docs/SERVICE_INVENTORY.md、docs/BACKEND_SERVICE_GUIDE.md 存在，再提交设计。架构师代理会检查服务放置、依赖流向、API 契约与重复功能。实际体验：因为代理会自动读取这些上下文文件，结论比“脱离代码库的通用建议”落地得多。
场景三：安全与合规前置把关
角色：安全工程师 / 后端负责人。痛点：安全问题总在上线前才被发现。使用方式：提交设计后重点看安全代理的威胁模型输出。实际体验：这是本技能最“值钱”的部分，它会明确指出类似“userId 必须来自服务端会话而非模型输出”“AI 端点必须限流”这类高风险项，并给出必需的缓解措施清单，而不是泛泛谈“注意安全”。
场景四：独立开发者或小团队的“虚拟评审委员会” 角色：独立开发者。痛点：没有人可以评审自己的设计。使用方式：把设计文档放进去，让五个代理轮流“挑刺”。实际体验：上手难度低（触发基本自动），但要注意三点——一是设计文档质量决定评审质量；二是 3 轮迭代后若仍未通过，不要无脑选“覆盖”，技术债会被记录下来；三是建议先补齐项目上下文文档，否则架构与 CTO 代理的判断会偏通用。
该技能能为用户带来的价值
- 把返工成本压到最低点：设计阶段的修改成本远低于编码后修改，评审前移意味着同样的问题可以在“改一段文字”而不是“改一堆代码”时被解决。
- 用流程替代自觉：自动触发 + 五方全部批准才放行的硬性闸门，让“这次太赶了先跳过评审”这类妥协无处发生。
- 补齐团队能力短板：小团队往往没有专职安全、专职 UX、专职架构评审，五个代理相当于随叫随到的“虚拟评审委员会”，每次评审成本接近于零。
- 结论可流转、可追踪：结构化 JSON（判决、阻塞项、建议、待澄清问题）天然适合作为任务系统的输入，与 BEADS 打通后可从“设计批准”直接生成史诗与阶段任务，减少手工拆解工作。
- 避免无限空转：最多 3 轮 + 人类升级，既保证质量，又不会让流程卡死；覆盖时还会记录技术债，为后续复盘留痕。
- 长期价值：随着使用次数增加，你的设计文档会越来越规范（用例格式、成功指标、TDD 规范、威胁模型），团队整体的设计素养会被这道闸门“训练”出来。
常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认它在工作？
A：在支持技能机制的 AI 编程环境中，以技能ID 13661 或英文名 design-review-gate 检索安装即可，具体安装入口与命令以官方说明为准。验证方式：向 docs/plans/ 写入一份设计文档，或执行 /project:review-design <路径-到-design.md>，若能看到五个代理的并行审查结论与汇总表格，说明已生效。
Q2：它会不会每次都要跑五遍，很慢？会不会一直卡着不放行？ A：五个代理是并行派发的，不是串行排队。放行规则是“五个全部批准”，未通过时会聚合反馈让你修订后重跑，最多 3 轮；第 3 轮之后会自动升级，让你在“覆盖 / 延迟 / 修订 / 取消”中做决定，不会无限循环。
Q3：它和普通的 AI 代码审查工具有什么区别？ A：最大的区别是评审对象和时点：本技能评审的是设计文档（实施开始前），而不是已写好的代码；其次是视角结构：产品、架构、设计、安全、CTO 五个维度分工明确，并各自输出结构化判决，其中安全代理还会产出威胁模型，这是多数通用审查工具不做的。
Q4：怎么才能让评审结论更贴合我们自己的代码库？
A：关键在于补齐上下文文件。架构师代理会读 docs/BACKEND_SERVICE_GUIDE.md、docs/SERVICE_CREATION_GUIDE.md、docs/SERVICE_INVENTORY.md；CTO 代理会读 docs/TESTING_GUIDE.md、CLAUDE.md、.claude/task-completion-checklist.md。另外设计文档本身要写足用例、成功/失败标准、API 契约与测试规范。
Q5：它适合谁用？小项目用它会不会太重？ A：最适合在“复杂功能设计定稿前”使用，尤其是安全敏感、需要严格 TDD、或多人协作易产生架构漂移的项目。小改动或不涉及架构与安全变化的调整，用单一 AI 自查即可；但只要这个功能上线后不好改、或者涉及用户数据，建议走一次审查门。