顾问委员会 是做什么的？
为模糊决策召集四位顾问：
- 内嵌的 Claude 声音
- 怀疑者子代理
- 实用主义者子代理
- 批评者子代理
这适用于模糊决策，而不是代码审查、实施计划或架构设计。
何时使用
在以下情况下使用顾问委员会：
- 一个决策存在多条可信路径且没有明显的优胜者
- 你需要明确地揭示权衡关系
- 用户要求提供第二意见、异议或多个视角
- 对话锚定效应是一个真实风险
- “执行/不执行”的决定能从对抗性挑战中受益
示例：
- monorepo vs polyrepo
- 立即发布 vs 打磨后再发布
- 功能标志 vs 全面发布
- 简化范围 vs 保持战略广度
何时不应使用
| 不使用顾问委员会的情况 | 应使用 |
|---|---|
| 验证输出是否正确 | santa-method |
| 将一个功能分解为实施步骤 | planner |
| 设计系统架构 | architect |
| 审查代码中的错误或安全问题 | code-reviewer 或 santa-method |
| 直截了当的事实性问题 | 直接回答 |
| 显而易见的执行任务 | 直接执行任务 |
角色
| 声音 | 视角 |
|---|---|
| 架构师 | 正确性、可维护性、长期影响 |
| 怀疑者 | 挑战前提、简化、打破假设 |
| 实用主义者 | 发布速度、用户影响、运营现实 |
| 批评者 | 边缘情况、下行风险、失败模式 |
三个外部声音应作为全新的子代理启动，只提供问题和相关上下文，而不是完整的持续对话。这就是反锚定机制。
工作流程
1. 提取真正的问题
将决策简化为一个明确的提示：
- 我们正在决定什么？
- 哪些约束条件重要？
- 什么算作成功？
如果问题很模糊，在召集委员会之前先问一个澄清性问题。
2. 只收集必要的上下文
如果决策与代码库相关：
- 收集相关文件、代码片段、问题文本或指标
- 保持紧凑
- 只包含做出决策所需的上下文
如果决策是战略性的/通用的：
- 跳过仓库存档，除非它们实质性地改变答案
3. 首先形成架构师的立场
在阅读其他声音之前，写下：
- 你最初的立场
- 支持它的三个最强理由
- 你所偏好路径的主要风险
先这样做，以便综合结果不会简单地镜像外部声音。
4. 并行启动三个独立的声音
每个子代理获得：
- 决策问题
- 紧凑的上下文（如果需要）
- 严格的角色
- 没有不必要的对话历史
提示模板：
你是一个四人决策委员会中的[角色]。
问题：
[决策问题]
上下文：
[仅相关的代码片段或约束]
请以如下格式回应：
1. 立场 — 1-2句话
2. 推理 — 3条简洁的要点
3. 风险 — 你建议中的最大风险
4. 意外 — 其他声音可能忽略的一件事
直接陈述。不要模棱两可。保持在300字以内。
角色重点：
- 怀疑者：挑战问题框架、质疑假设、提出最简单的可信替代方案
- 实用主义者：优化速度、简单性和实际执行
- 批评者：揭示下行风险、边缘情况以及计划可能失败的原因
5. 在偏差防护规则下进行综合
你既是参与者又是综合者，因此请使用以下规则：
- 不要在没有解释原因的情况下驳回外部观点
- 如果某个外部声音改变了你的建议，请明确说明
- 始终包含最强烈的异议，即使你拒绝它
- 如果有两个声音反对你最初的立场，请将其视为一个真实信号
- 在裁决之前保持原始立场可见
6. 呈现紧凑的裁决
使用以下输出格式：
## 委员会： [简短的决策标题]
**架构师：** [1-2句话的立场]
[1行说明原因]
**怀疑者：** [1-2句话的立场]
[1行说明原因]
**实用主义者：** [1-2句话的立场]
[1行说明原因]
**批评者：** [1-2句话的立场]
[1行说明原因]
### 裁决
- **共识：** [他们一致的地方]
- **最强烈的异议：** [最重要的分歧]
- **前提检查：** [怀疑者是否质疑了问题本身？]
- **建议：** [综合后的路径]
保持简洁，能在手机屏幕上快速浏览。
持久化规则
不要从本技能向 ~/.claude/notes 或其他隐藏路径写入临时笔记。
如果委员会实质上改变了建议：
- 使用
knowledge-ops将经验教训存储在正确的持久位置 - 或者，如果结果属于会话记忆，使用
/save-session - 或者，如果决策改变了当前执行的真相状态，直接更新相关的 GitHub / Linear 问题
仅当决策改变了实质内容时才持久化。
多轮跟进
默认情况下只进行一轮。
如果用户想要另一轮：
- 保持新的问题聚焦
- 仅在必要时包含之前的裁决
- 尽可能保持怀疑者角色的“干净”，以保留反锚定的价值
反模式
- 使用委员会进行代码审查
- 在任务仅仅是实施工作时使用委员会
- 将完整的对话记录提供给子代理
- 在最终裁决中隐藏分歧
- 无论重要性如何，都将每个决策持久化为笔记
相关技能
santa-method— 对抗性验证knowledge-ops— 正确持久化重要的决策变更search-first— 必要时在召集委员会之前收集外部参考材料architecture-decision-records— 当决策成为长期系统策略时，将结果正式化
示例
问题：
我们是否应该现在以alpha版本发布ECC 2.0，还是等待控制平面UI更加完善后再发布？
可能的委员会格局：
- 架构师推动结构完整性，避免混乱的用户界面
- 怀疑者质疑UI是否真的是制约因素
- 实用主义者询问现在可以发布什么而不损害信任
- 批评者关注支持负担、期望债务和发布混乱
价值不在于达成一致。价值在于在选择之前使分歧清晰可见。