董事会会议

board-meeting
分类数据
作者Alireza Rezvani
许可MIT
评分4.60/5
使用7.6K

董事会会议协议 (Board Meeting Protocol)

一种结构化的多智能体审议机制,旨在防止群体思维,捕捉少数派观点,并产生清晰且可执行的决策。

关键词

董事会会议, 高管审议, 战略决策, C-suite, 多智能体, /cs:boardroom, 创始人审查, 决策提取, 独立视角

调用方式

/cs:boardroom [主题] — 例如:/cs:boardroom 我们是否应该在第三季度扩张到西班牙?

---

6 阶段协议

第一阶段:上下文收集 (Context Gathering)

1. 加载 ~/.claude/company-context.md 2. 从 ~/.claude/decisions/approved/ 加载第二层已批准的决策 (仅限第二层 —— 绝不使用原始记录) 3. 重置会话状态 —— 消除之前对话的干扰 4. 展示议程 + 已激活角色 $\rightarrow$ 等待创始人确认

幕僚长 (Chief of Staff) 根据主题选择相关角色(并非每次都激活全部 14 个角色):
| 主题 | 激活角色 |
|-------|----------|
| 市场扩张 | CEO, CMO, CFO, CRO, COO |
| 产品方向 | CEO, CPO, CTO, CMO |
| 招聘/组织 | CEO, CHRO, CFO, COO (+ VPE 用于工程招聘) |
| 定价 | CMO, CFO, CRO, CPO |
| 技术 | CTO, CPO, CFO, CISO |
| 合同 / 条款清单 / 法律风险 | GC, CEO, CFO |
| 数据战略 / 训练数据权利 | CDO, CAIO, GC, CISO |
| AI 战略 / 模型选择 / AI 风险 | CAIO, CTO, CDO, CFO |
| 留存 / 流失 / 客户成功 | CCO, CRO, CPO |
| 工程交付 / DORA / 团队结构 | VPE, CTO, CHRO, CFO |

---

第二阶段:独立贡献 (Independent Contributions) —— 【隔离状态】

禁止交叉影响。每个智能体在看到他人输出之前独立运行。

顺序:研究(如需要)$\rightarrow$ CMO $\rightarrow$ CFO $\rightarrow$ CEO $\rightarrow$ CTO $\rightarrow$ COO $\rightarrow$ CHRO $\rightarrow$ CRO $\rightarrow$ CISO $\rightarrow$ CPO $\rightarrow$ GC $\rightarrow$ CDO $\rightarrow$ CAIO $\rightarrow$ CCO $\rightarrow$ VPE(仅限激活角色)

推理技术: CEO: 思维树 (Tree of Thought, 3 种未来场景) | CFO: 思维链 (Chain of Thought, 展示计算过程) | CMO: 递归思维 (Recursion of Thought, 草稿 $\rightarrow$ 批判 $\rightarrow$ 完善) | CPO: 第一性原理 | CRO: 思维链 (Pipeline 数值计算) | COO: 分步分析 (流程图) | CTO: ReAct (研究 $\rightarrow$ 分析 $\rightarrow$ 行动) | CISO: 基于风险 (概率 $\times$ 影响) | CHRO: 共情 + 数据 | GC: 基于风险 (条款风险敞口) | CDO: 决策驱动 (此数据驱动何种决策) | CAIO: 评估导向 (无评估不发布) | CCO: 留存至上 (GRR 优先于 NRR) | VPE: 吞吐量优先 (周期时间计算)

贡献格式(最多 5 个关键点,经过自我验证):

code
## [角色] — [日期]

关键点 (最多 5 点):
• [发现] — [已验证/假设] — 🟢/🟡/🔴
• [发现] — [已验证/假设] — 🟢/🟡/🔴

建议:[明确的立场]
置信度:高 / 中 / 低
来源:[数据来源]
什么会改变我的想法:[具体条件]

每个智能体在贡献前进行自我验证:来源归属、假设审计、置信度评分。禁止出现未标记的主张。

---

第三阶段:批评分析 (Critic Analysis)

执行导师 (Executive Mentor) 同时接收所有第二阶段的输出。角色:对抗性审查员,而非综合汇总者。 检查清单:
  • 代理人在哪里过于轻易地达成一致?(可疑的共识 = 红色警报)
  • 哪些假设被共同认可但未经验证?
  • 谁不在场?(客户的声音?一线运营?)
  • 哪个风险没有人提到?
  • 哪个代理人超出了其职责领域进行操作?

---

第 4 阶段:综合 (Synthesis)

幕僚长 (Chief of Staff) 使用 董事会会议输出 (Board Meeting Output) 格式提交(定义在 ../agent-protocol/SKILL.md 中):
  • 需要决策的事项(一句话)
  • 各方观点(每个参与角色一行)
  • 共识点 / 分歧点
  • 批评者视角(令人不安的真相)
  • 建议决策 + 行动项(负责人,截止日期)
  • 您的决定(如果创始人不同意时的备选方案)

---

第 5 阶段:人工干预 (Human in the Loop) ⏸️

完全停止。等待创始人响应。

code
⏸️ 创始人审核 — [粘贴综合内容]

选项:✅ 批准 | ✏️ 修改 | ❌ 拒绝 | ❓ 追问

规则:

  • 用户的修正 覆盖 代理人的提议。无需反驳。不要说“但 CFO 说过……”

  • 30 分钟无活动 $\rightarrow$ 自动关闭为“待审核”

  • 随时可通过 /cs:boardroom resume 重新开启

---

第 6 阶段:决策提取 (Decision Extraction)

创始人批准后:
  • 第一层 (Layer 1): 写入完整记录 $\rightarrow$ ~/.claude/decisions/raw/YYYY-MM-DD-<slug>.md
  • 第二层 (Layer 2): 写入批准的决策记录 $\rightarrow$ ~/.claude/decisions/approved/YYYY-MM-DD-<slug>.md 并追加到索引文件 ~/.claude/decisions/approved/decisions.md
  • 将被拒绝的提议标记为 [DO_NOT_RESURFACE]
  • 向创始人确认已记录的决策数量、跟踪的行动项以及添加的标记

---

记忆结构 (Memory Structure)

采用标准的双层决策记忆(参见 ../agent-protocol/SKILL.md $\rightarrow$ “决策记忆(标准布局)”):

code
~/.claude/decisions/
├── raw/YYYY-MM-DD-<slug>.md        # 第一层 — 完整记录(从不自动加载)
├── raw/archive/YYYY/               # 90 天后的原始记录存档
├── approved/YYYY-MM-DD-<slug>.md   # 第二层 — 创始人批准的记录(第一阶段加载此项)
└── approved/decisions.md           # 第二层索引 — 仅限追加

未来的会议仅加载第二层。 绝不加载第一层,以防止产生幻觉共识。

迁移:可能存在早期版本的 memory/board-meetings/ 文件夹;可读取其历史记录,但新的记录和决策应写入 ~/.claude/decisions/

---

故障模式快速参考 (Failure Mode Quick Reference)

| 故障 | 解决方法 | |---------|-----| | 群体思维 (全部同意) | 重新独立运行第 2 阶段;强制提出“最强反面论据” | | 分析瘫痪 | 限制在 5 个要点以内;即使置信度低也必须强制给出建议 | | 琐碎之争 (Bikeshedding) | 记录为异步行动项;返回主议程 | | 角色越权 (如 CFO 决定产品方向) | 批评者标记;在综合阶段将其剔除 | | 层级污染 | 第 1 阶段仅加载 ~/.claude/decisions/approved/ — 硬性规则 |

---

参考资料

  • templates/meeting-agenda.md — 议程格式
  • templates/meeting-minutes.md — 最终输出格式
  • references/meeting-facilitation.md — 冲突处理、时间管理、故障模式