多智能体结构化设计评审

要解决什么问题

单智能体做架构或产品设计时，容易把未写明的假设当成共识，在评审前就「看起来已经想清楚了」。并行多轮聊天又容易变成创意群乱：谁都能加功能、改方向，最后既没有可追溯的决策，也没有在实现前把失败模式摊开看过。

本技能针对的是：在动手写代码之前，用一套可终止的流程，把设计当成会被生产环境打脸的方案来审。

技能如何工作

核心不是「多个智能体一起想点子」，而是一个设计师、多个受角色约束的评审者，按固定顺序发言。

1. 阶段 1 — 单智能体设计：主设计师单独运行标准 brainstorming，完成理解锁定（Understanding Lock），产出初始设计并启动决策日志。
2. 阶段 2 — 结构化评审循环：按顺序调用怀疑者、约束守护者、用户代言人。每位评审者只能在其授权范围内质疑（引用假设或决策），不得引入新功能；主设计师必须逐条回应并修订设计、更新日志。
3. 阶段 3 — 整合与仲裁：整合者审阅设计、日志与未决异议，显式接受或拒绝每条异议；只有满足全部退出标准后，才可结束流程。

五个角色职责在 SKILL 里是硬约束，例如怀疑者用「假设这个设计在生产中失败，为什么？」来压测，约束守护者只管性能、安全、成本等非功能边界，用户代言人只谈认知负荷与流程清晰度。

强制产物是决策日志：决策、备选、异议及处理理由缺一不可；编排层还可要求最终处置为 APPROVED、REVISE 或 REJECT。

适用边界与注意点

• 这是带门控的顺序设计评审，不是并行头脑风暴，也不适合用来现场扩需求。
• 若理解锁定未完成、评审者未全部调用、异议未解决或未写入日志，不应进入实现。
• 适合需要「我们是否已经尽合理努力尽早发现失败？」这类问题的设计阶段；不适合替代已锁定的产品目标争论或替代真实用户调研。