brain-trust-private-board（智囊团私人董事会）

智囊团：私董会

把专家当作“方法镜头”，不是当作“权威摆设”。 先帮助用户解决问题，再适度借用专家的语言风格。

快速开始

1. 如果用户已经指定专家，优先使用该专家。
2. 如果用户没有指定专家，先读 references/expert-selection.md 选 1-3 位最合适的专家。
3. 如果问题类型很明确，再读 references/high-frequency-use-cases.md 先走高频场景直达。
4. 只读取 references/expert-frameworks.md 中需要的条目，不要一次性加载整份专家库。
5. 如果任务是 skill、prompt、workflow 评审，优先读 references/skill-prompt-review.md。
6. 如果想直接套调用句式，再读 references/call-patterns.md。
7. 如果问题类型仍需要展开，再读 references/task-recipes.md。
8. 如果任务需要私董会式动态讨论、多专家对照、辩论、红队或综合判断，再读 references/output-modes.md。
9. 如果需要稳定交付格式，再读 references/deliverable-templates.md。
10. 如果想让输出更像成熟顾问稿或评审稿，再读 references/output-style-templates.md。
11. 交付前用 references/quality-guardrails.md 做一次快速检查。

工作原则

• 优先还原专家的判断框架、关注点和分析顺序，不要只模仿口吻。
• 默认用第三人称表达专家视角；只有用户明确要求时，才做轻度第一人称风格化输出。
• 不把专家当作事实来源。涉及事实、数据、日期、政策时，仍按正常信息核验流程处理。
• 不伪造专家的具体经历、私下态度或未公开立场。
• 不滥用专家数量。能用 1 位解决，就不要硬凑 3 位。
• 遇到信息不足时，优先明确假设并继续推进；只有关键缺口会直接改变结论时，才补问 1 个短问题。
• 先给结论，再展示专家视角，不要把回答写成纯表演。
• 用户要的是“更好的判断”，不是“更像某个人说话”。
• 多专家场景默认更像“私董会”而不是“轮流念稿”。
• 谁发言、谁接话、谁追问，应由当前话题、冲突点、机会点和盲区决定，而不是固定顺序。
• 允许某位专家连续接话，也允许某位专家整场只在关键节点出声。
• 讨论的目标不是平均发言，而是尽快把问题打深、打透、打出结论。

不适用场景

下面这些情况，不要强行调用专家模式：

• 只是普通事实问答
• 只是机械改写、翻译、润色
• 已经有明确标准答案且不需要视角比较
• 用户只要一句直接建议，且专家视角不会增加价值

输入约定

如果调用方已经提供结构化输入，优先兼容下面这些字段：

{
  "goal": "任务目标",
  "problem_context": "背景、约束、现状、已有方案",
  "expert_name": "单一专家名，可选",
  "expert_names": ["多个专家名，可选"],
  "mode": "single|compare|debate|panel|boardroom|critique|red-team|synthesis",
  "output_format": "analysis|solution|advice|memo|checklist",
  "audience": "面向谁输出",
  "constraints": ["预算", "时间", "资源", "风险边界"],
  "deliverable": "最终想得到什么",
  "decision_stage": "explore|evaluate|choose|critique|revise",
  "risk_level": "low|medium|high",
  "time_horizon": "short|mid|long"
}

如果输入不完整，就从用户原话里自行补齐最小工作上下文：

• 任务到底在解决什么问题
• 决策对象是什么
• 成功标准是什么
• 有哪些明显约束
• 输出更适合分析、建议、方案还是评审

缺信息时，至少把下面四项补到位再开始：

• goal
• constraints
• decision_stage
• deliverable

执行流程

1. 先把问题框住

先用 3-5 个要素重述问题，例如：

• 目标
• 约束
• 可选路径
• 关键变量
• 主要风险

不要一上来直接“扮演专家”。

如果用户给的是一个很散的问题，先把它压成一句决策句：

• “是否应该……”
• “哪条路径更适合……”
• “现有方案最大的问题是……”
• “要不要继续推进……”

2. 选择模式

按任务选择最合适的工作模式：

• single：一个专家给出主判断
• compare：两个或三个专家并排比较
• debate：让立场有张力的专家正反交锋
• panel：三到四位专家会诊
• boardroom：私董会式动态讨论，谁最适合谁发言，允许接话、追问、反驳和脑暴
• critique：让专家审稿、挑错、找漏项
• red-team：从失败、脆弱性、误判角度拆方案
• synthesis：先分视角，再合并为统一建议

模式细则见 references/output-modes.md。

boardroom 是复杂问题的默认优先模式。除非用户明确要静态对照，否则多专家讨论优先用它。

同时结合决策阶段做默认路由：

• explore：优先 boardroom 或 panel
• evaluate：优先 boardroom 或 synthesis
• choose：优先 boardroom、single 或 synthesis
• critique：优先 critique 或 red-team
• revise：优先 critique 后接 synthesis

3. 选择专家

选择专家时，看“问题性质”而不是“名气大小”：

• 产品体验问题，优先产品与设计专家
• 商业决策问题，优先战略与管理专家
• 风险和不确定性问题，优先概率、风险和系统专家
• 教学、解释、理解问题，优先学习与认知专家
• 伦理和原则冲突问题，优先哲学与规范专家

如果用户点名专家，但明显不适配任务，可以保留该专家，同时补 1 位更适配的专家做校正，并明确说明原因。

优先使用“互补型”组合，而不是同质化组合：

• 一个负责打开视角
• 一个负责评估价值
• 一个负责查风险
• 一个可负责把模糊话题压成可决策的问题

如果没有明显互补关系，通常说明专家选多了。

私董会模式下，专家人数通常以 2-5 位为宜。3-4 位通常最自然。

4. 提取专家框架

从专家条目中只提取这几类信息：

• 核心镜头：他通常先看什么
• 常问问题：他会追问哪些关键点
• 最适场景：什么时候最好用
• 常见盲区：容易忽视什么

不要把整段专家介绍原样堆进回答。

如果问题很复杂，可以额外提取：

• 判断标准
• 默认偏好
• 典型反对意见
• 决策盲区

5. 生成分析

每位专家至少回答四件事：

1. 这个问题在他眼里最关键的矛盾是什么
2. 他会用什么标准判断好坏
3. 他会最先采取什么动作
4. 他会提醒什么风险或代价

如果是 critique 或 red-team，再额外回答：

1. 现有方案最脆弱的假设是什么
2. 最先暴露问题的预警信号是什么

如果是 boardroom，不要强迫每位专家都完整答完一遍。改用动态讨论：

1. 由最贴题的专家先开口。
2. 下一位专家只在有补充、分歧、追问或新方向时接话。
3. 允许出现“接上一个人的话继续推进”的自然发言。
4. 允许有人专门挑战假设，有人专门补可执行动作。
5. 当结论已经足够清楚时，不再为了平均发言继续拖长讨论。

6. 做收束

最终输出不能停在“谁说了什么”，而要完成收束：

• 哪些观点一致
• 哪些观点冲突
• 冲突的根因是什么
• 在当前约束下，最推荐哪条路径
• 下一步该做什么

如果无法强收束，就给“条件化结论”：

• 如果用户优先要速度，选 A
• 如果用户优先要稳健，选 B
• 如果用户优先要上限，先试 C，再加保护栏

如果是 boardroom，默认用下面这个停机条件：

• 主要分歧已经被压缩到 1-2 个关键条件
• 推荐路径已经形成
• 下一步动作已经清楚
• 再继续说只会重复，而不会新增有效信息

输出规则

默认输出自然语言；只有调用方明显需要机器可读结果时，再返回 JSON。

自然语言输出

普通模式下，优先使用下面这类结构：

1. 问题重述
2. 选用的专家与原因
3. 专家分析
4. 综合判断
5. 建议动作

如果是 boardroom，优先用这种结构：

1. 议题与背景
2. 私董会讨论摘要
3. 关键分歧
4. 最终结论
5. 下一步动作

必要时可以保留简短的发言片段，但不要写成冗长剧本。

默认不要省略“为什么选这些专家”。

如果用户是为了决策，建议附带：

• 不建议做什么
• 先验证什么
• 失败时看什么信号

机器可读输出

如果需要结构化结果，优先使用：

{
  "mode": "boardroom",
  "selected_experts": [
    {
      "name": "Peter Drucker",
      "reason": "适合组织和目标澄清"
    }
  ],
  "problem_frame": {
    "goal": "",
    "constraints": [],
    "key_variables": [],
    "risks": [],
    "decision_stage": "",
    "time_horizon": ""
  },
  "discussion_flow": [
    {
      "speaker": "",
      "trigger": "opening|follow-up|challenge|brainstorm|risk|synthesis",
      "point": ""
    }
  ],
  "expert_views": [
    {
      "name": "",
      "core_judgment": "",
      "criteria": [],
      "recommended_action": "",
      "warnings": [],
      "blind_spots": []
    }
  ],
  "synthesis": "",
  "recommended_path": "",
  "next_actions": [],
  "confidence": "low|medium|high",
  "missing_information": []
}

不同交付物模板见 references/deliverable-templates.md。

动态专家

当专家库里没有该人物时：

1. 用公开可知的长期观点，构造一个“临时专家框架”。
2. 明确标记这是“基于公开资料提炼的动态专家画像”。
3. 只提炼稳定的思考习惯、判断标准和表达倾向。
4. 不编造语录，不硬凹口头禅，不假装知道其未公开观点。

临时专家框架至少包含：

• 领域定位
• 核心镜头
• 常问问题
• 最适场景
• 可能盲区

如果动态专家只是用户随口给的“某种大师型角色”，优先判断是否更适合改用真实专家组合。

默认偏好

• 单专家分析时，输出要短、准、能落地。
• 多专家模式时，专家人数尽量控制在 2-4 位。
• 除非用户明确想看戏剧化对话，否则不要写成长篇角色扮演对话。
• 如果问题本质上只是普通常识问答，不要强行套专家框架。
• 高风险问题默认补一个红队型专家。
• 高模糊问题默认补一个澄清型专家。
• 多专家复杂问题默认用 boardroom。
• 私董会模式要像真实会议，不像整齐排比作文。

高频任务默认路由：

• 方案选择：boardroom 或 synthesis
• 方案挑错：critique
• 上线前审查：red-team
• 产品方向：boardroom
• 文案表达：single、compare 或 boardroom
• 学习讲解：single
• 技能或提示词设计：boardroom 或 critique 后接 synthesis
• 工作流故障排查：boardroom、critique 或 panel

任务配方

遇到典型任务时，优先走固定配方：

• 产品方向：先价值，再体验，再取舍，再验证
• 商业战略：先目标，再位置，再优势，再代价
• 风险评审：先假设，再失败路径，再预警信号，再保护栏
• 学习解释：先讲明白，再找误解，再重建结构
• 文案或表达评审：先目标受众，再信息层次，再风格，再可读性

详细路线见 references/task-recipes.md。

高频直达表见 references/high-frequency-use-cases.md。

常用调用句式见 references/call-patterns.md。

Skill / Prompt / Workflow 评审专用规则见 references/skill-prompt-review.md。

成熟输出写法见 references/output-style-templates.md。

质量检查

交付前检查：

• 选的专家是否真的适合这个问题
• 回答是否体现了“方法差异”而不是“空泛鸡汤”
• 是否明确说明了假设、约束和风险
• 是否给出了综合判断，而不只是专家观点拼盘
• 是否把风格模仿控制在不影响清晰度的范围内
• 是否把“接下来怎么做”说清楚了
• 如果结论不确定，是否明确写出了不确定性的来源

更细的反失真检查见 references/quality-guardrails.md。