Council of High Intelligence：把「咨询董事会」装进 Claude Code / Codex 的 18-persona 议会协议

本文导读

读完本文你将能够：

• 理解 Council of High Intelligence 为什么不是"18 个 prompt 模板"，而是一套带协议约束的多智能体协商系统
• 说出 18 个角色的极性配对逻辑，以及为什么必须跨 provider 路由
• 对照 7 步协议判断某次决策输出是否真的经过了结构化对抗
• 根据团队类型选择适合的 panel 和 mode
• 独立完成一次 --dry-route 路由检查并解读结果

适合读者：正在用 Claude Code / Codex 做技术决策，感觉"再问一次还是类似答案"的工程师或技术负责人。

目录

1. 先给判断
2. 系统地图：18 personas × 3 panel × 7 步协议 × 6 个 provider
3. 18 personas 的本质：不是百科词条，而是极性配对
4. 3 套预置 panel 的取舍：人数越多 ≠ 越好
5. 自动路由：6 个 provider 怎么把人贴上去
6. 7 步协议：把"讨论"压缩成"决策"
7. 一个具体案例
8. 20 个 Triad：把"领域知识"预编译到成员组合里
9. benchmark 解读：协议性指标 vs 决策性指标
10. 采用顺序与适用边界
11. 结尾：回到系统层价值
12. 常见问题
13. 自测题
14. 练习
15. 资料口径说明

一、先给判断：这套 skill 不是把 18 个 prompt 串起来，而是把"单模型自信地猜"换成"多模型被强制对抗"

把同一个问题丢给 Claude，绝大多数时候会得到一段结构工整、措辞自信、细节可疑的回答。模型说错并不可怕，可怕的是它用同一个家族的归纳偏差，把同一个错也答得很自信。 Council of High Intelligence（0xNyk/council-of-high-intelligence，2026 年 6 月底时为 CC0 公有领域贡献，9 月起已改 MIT；6 月 30 日 github trending daily 第一、star 2,124）做的事不是 prompt 模板，而是把"决策"重构成一次带协议约束的多智能体协商：

• 角色是带极性配对的对手——Socrates 负责拆假设、Feynman 负责从第一性原理重建，两人在同一议题上必须形成张力。
• 决策走匿名质询 + 结构化立场 + 强制多数决——交叉质询全程用匿名标签防声望偏见，每位成员最后一轮必须输出一行 STANCE: <选项> | CONFIDENCE: … | DEALBREAKER: …，由贴题席位加权计票，达到 2/3 加权多数才算共识，否则直接呈报分歧。
• 模型来源跨 provider 强制分流——极性配对的两个人必须落在不同模型家族（Claude / OpenAI / Gemini / Ollama / NVIDIA NIM / Cursor），避免一个模型的家族偏差同时传染给两个互相对抗的角色。
• 协议有有界轮次预算——full 模式 3 轮、quick 模式 2 轮、duo 模式 3 轮；Socrates 重问已答的问题会被强制给 50 词立场（“hemlock rule”），任何一对成员互相应答超过 2 条消息也会被切断。

下面按机制拆开讲：18 个角色的极性如何成对、3 套预置 panel 如何分工、7 步协议如何把对话变成投票、自动路由如何把 6 个 CLI 编排成一张"决策板凳"。

二、系统地图：18 personas × 3 panel × 7 步协议 × 6 个 provider

进入任何细节之前，先把整套系统的四层结构画出来，避免后面把"角色"和"协议步"混在一起讲。

四层关系要点：

1. Panel 是角色集合（classic 18、exploration-orthogonal 12、execution-lean 5），通过 /council --profile 切换。
2. Mode 是协议深度（full 3 轮、quick 2 轮、duo 2 人 3 步），通过 /council --quick 或 /council --duo 切换。
3. Triad 是 3 人小组（20 个领域组合），通过 /council --triad <domain> 选择，例如 --triad strategy 拉 Sun Tzu + Machiavelli + Aurelius。
4. Provider 是底层模型（Claude / Codex / Gemini / Ollama / NVIDIA NIM / Cursor），通过自动路由决定每个成员跑在哪个模型上。

读者最容易踩的坑：把"18 personas"当成"18 个 prompt"，结果发现它们之间根本不互相引用。persona 只是身份标签，真正产生对抗的是协议步（cross-examination + dissent quota）。

三、18 personas 的本质：不是百科词条，而是极性配对

直接看名单容易误读，以为是"找一个会哲学的 prompt"或者"找一个会工程的 prompt"。README 真正想表达的是：单点最强没用，必须把观点放在互相对抗的位置上。下面把 18 人按"互相撕扯的双方"重新分组：

上表对应 SKILL.md “Polarity Pairs” 主表；2026-06-27 版本的主表是上列 13 组，--duo 模式的配对表另含 Sutskever ↔ Machiavelli（安全理想 vs 行业激励）、Socrates ↔ Watts（拆假设 vs 换框架）两组。这两组原先只活在 duo 表里，协调者读的主表缺了它们——仓库后来把这个漂移当 bug 修掉（#50、#51），现在主表已并入为 15 组。

设计上，每个角色没有"客观正确答案"，都站在另一极的对立面；一份诚实的评估该让对立双方同时陈述，而不是任一方独占。

这也直接决定了为什么必须多 provider——如果 Socrates 和 Feynman 都跑在同一个 Claude 模型上，他们的"对立"只是同一个归纳偏差的两副面具。这就是自动路由的硬约束（见第五节）。

四、3 套预置 panel 的取舍：人数越多 ≠ 越好

README 给出的 3 个 panel 是用人数换视角、用速度换覆盖的明确取舍：

三套 panel 的成员构成（来自 SKILL.md）：classic 是全部 18 人；exploration-orthogonal 是 Socrates、Feynman、Sun Tzu、Machiavelli、Ada、Lao Tzu、Aurelius、Torvalds、Karpathy、Sutskever、Kahneman、Meadows 共 12 人，另配 unknowns、market-entry、system-design、reframing、ai-frontier、blind-spots 六组探索 triad；execution-lean 是 Torvalds、Feynman、Sun Tzu、Aurelius、Ada 共 5 人，配 ship-now、launch-strategy、stability 三组。

execution-lean 的设计意图是"决策会议不要把所有人都拉进来"——能上桌的只有真能下决定的人。这与"决策要民主、人多保险"的传统做法相反。README 的隐含假设是：人一多，共识噪声跟着涨；人少但约束强，真正的分歧才浮得出来。

因此"用哪个 panel"的选择本身也是一次决策：

• 技术选型、性能调优、需求歧义——execution-lean。
• 战略规划、商业模式、新市场评估——classic。
• 探索阶段、产品方向未定——exploration-orthogonal。

这个映射不是 README 明确写出来的规则，但从三套 panel 的成员构成反推，是最贴合 README 给的"domain triads"的隐含策略。

五、自动路由：6 个 provider 怎么把人贴上去

/council --dry-route 是排查自动路由的最佳入口，会打印每个成员被分配到哪个 provider。机制按以下顺序决策：

1. 极性配对硬约束：任何一对极性对（比如 Socrates ↔ Feynman）必须落到不同 provider。
2. 均匀分布：成员尽量均匀铺到所有可用 provider。
3. provider_affinity 兜底：每个 persona 的 frontmatter 里有"偏好 provider"字段，作为 tiebreaker。
4. 失败回退：任何 provider 失败 → 自动回退到 Claude。

两个值得特别说明的细节：

README 单独给了这两类 provider 示例配置（configs/provider-model-slots.{nim,cursor}.example.yaml），用来覆盖下面的边界场景：

• NVIDIA NIM 不需要 CLI，只要 export NVIDIA_API_KEY=nvapi-... 就被自动识别。130+ 开放权重模型（DeepSeek、Kimi、MiniMax、GLM、Qwen、Nemotron）通过 OpenAI-compatible endpoint 暴露，免费额度 1,000 credits、40 RPM。
• Cursor 是聚合器，单一 cursor-agent 二进制同时提供 GPT-5.x、Claude、Gemini、Grok。因此配 Cursor 时要明确选"跨家族"模型（如 gpt-5.4-high、gemini-2.5-pro、grok-4），否则本来想分流，结果却把同一个家族偏差复制两遍。

六、7 步协议：把"讨论"压缩成"决策"

full 模式的 7 步是最值得展开的一段，因为它直接决定了 Council 跟"把 18 个 prompt 拼起来"之间到底差在哪：

强制结构（enforcement）是 Council 真正的护城河。没有这几条，整个系统就退化成"18 个 prompt 各自发言"——读起来热闹，但没有"决策机制"。

具体 enforcement 五条线：

• 匿名质询（anonymized cross-examination）：Round 2 开始前，协调者把所有 Round 1 输出脱去署名，换成 Member A / Member B / … 的稳定标签，成员只看到标签。这一步防的是声望偏见——成员倾向于附和 Karpathy 而质疑匿名者，即使两段话内容相同。协议依据标注了 Choi et al.（arXiv:2510.07517）与 Karpathy 的 llm-council 实验。5 人及以上 panel 并行质询，4 人及以下改为顺序进行；质询结束后协调者在工作状态里恢复标签到真名的映射，质询记录同时保留匿名与实名两个版本，后者供 STEP 7 审计。
• dissent quota + novelty gate：如果 >70% 过早达成共识，系统强制挑两位成员去钢人对方观点；novelty gate 阻止"换句话说"式的复读。
• anti-recursion（含 hemlock rule）：Socrates 重问一个已被回答的问题，会触发 hemlock rule——强制他在 50 词内给出立场，停止提问；另外任何一对成员互相应答超过 2 条消息也会被切断。两条护栏各管一种拖会方式：前者管"无限追问"，后者管"无限对线"。
• 结构化立场行：每位成员最后一轮必须输出一行机器可解析的三字段立场：STANCE: <选项标签> | CONFIDENCE: high|med|low | DEALBREAKER: yes|no。STANCE 是简短的选项标签（如 monorepo、ship now），并与他人统一措辞——同义标签（monorepo / single repo）由协调者归并成一个选项后计票；确实不支持任何选项则写 STANCE: abstain。DEALBREAKER: yes 表示认为对立选项有实际危害而不只是次优，这类立场即使被多数票压过，也会进入裁决的 Minority Report 单独呈现。
• 加权多数决：共识的判定不是"看起来多数"，而是结构化计票。协调者在 STEP 0 选 panel 时就锁定一个"领域权重席位"——问题最贴题的那位成员计 1.5×，其余成员计 1×。席位在任何立场形成之前指定，否则协调者可以靠事后挑权重操纵结果；若两位成员同样贴题，则不设权重席位，平票按等权处理。弃权不减总权重——abstain 仍以满权重计入 W_total，等于抬高其余人达成共识的门槛，弃权不是免费退场。达到 2/3 加权多数才算共识。

如果最终未达成 2/3 加权多数，系统不会合成一个虚假共识，而是直接把分歧 + 完整计票回吐给用户，由用户决定怎么继续。“未达成共识也是结果"是 README 反复强调的判断——比"看起来同意"更有价值。

还有一个角色分工容易误读：计票由协调者执行，但最终裁决文本由 Chairman 合成——这是 STEP 1.7 选出的命名角色，从 panel 成员之外指定，不参与 Round 1–3，只负责在 STEP 7 写出最终 verdict。把它独立出来，一是让合成 prompt 显式可审计，二是允许选用与所有成员不同家族的模型来写总结，避免 synthesis 阶段再造一次家族偏差。duo 模式下 Chairman 还有一条硬约束：不得是两位辩手中的任何一个。

quick 模式（2 轮、无 cross-examination，但 Round 2 同样匿名化——轮次越少越容易从众）和 duo 模式（2 人 3 步：开场→回应→终态）则是把同一个 protocol 压缩给"简单决策"和"二元争论"用。

七、一个具体案例：/council Should we open-source our agent framework?

README 的 quickstart 只给了一条命令；下面的流转按 SKILL.md 的协议约束逐步推演。各成员的发言为示意内容，用于展示每步约束如何生效，并非仓库自带的输出记录：

/council Should we open-source our agent framework?

这一条命令会触发以下流程（按 step 序）：

1. Provider Detection & Routing：探测到 Claude（默认）+ Codex（装了 codex CLI）两个 provider。Socrates 路由到 Claude，Feynman 路由到 Codex；其他 16 人按 provider_affinity 平均铺。随后（协议的 STEP 1.7）选定 Chairman——例如让 Gemini 3 Pro 担任，与全部成员不同家族。
2. Problem Restate Gate：18 人各自先重述问题，例如：
   • Socrates: “你真正想问的是’开源能否帮我们获得开发者心智’还是’开源能否帮我们获得收入’？”
   • Aristotle: “开源是一个动作，把’什么开源’拆出来：核心代码？训练数据？评测集？”
   • Munger: “先想不开源会发生什么。损失是什么？”
3. Round 1 独立分析（400 词内）：18 人并行。
   • Sun Tzu 看外部博弈：竞品是否已开源？开源后的攻防。
   • Machiavelli 看真实激励：用户为什么来？是因为开源还是因为产品本身？
   • Taleb 看尾部风险：开源后被监管盯上的概率。
4. Round 2 Cross-Examination（匿名标签下）：所有 Round 1 输出被换成 Member A / Member B / …，每人必须挑战其中至少 2 位——包括可能属于自己的那段。
   • Karpathy（读到的是"Member F”）反驳安全优先论：“你说的安全预算对应到我们这种小团队根本不可行。”
   • Sutskever 反驳：“你用’不可行’当借口，但 safety cost 是内生的，不是外加的。”
5. Enforcement Scan：发现 Sun Tzu / Machiavelli / Aurelius（战略组）已经过早形成共识 → 强制 Karpathy / Sutskever 去钢人反对意见。
6. Round 3 终态立场（100 词 + STANCE 行）：每人输出结构化立场行，例如：
   • Sun Tzu: STANCE: open-source-core | CONFIDENCE: med | DEALBREAKER: no（有条件——评测集保留后开源核心）
   • Machiavelli: STANCE: open-source-all | CONFIDENCE: high | DEALBREAKER: no（视为心智营销手段）
   • Taleb: STANCE: do-not-open-source | CONFIDENCE: high | DEALBREAKER: yes（开源暴露被监管盯上的尾部）
7. Verdict Synthesis：协调者归并同义标签后加权计票，2/3 多数未达成 → Chairman 把 unresolved questions + 完整计票 + Minority Report（Taleb 的 dealbreaker 在此单独呈现）+ next steps 写成最终裁决，不合成假共识。

按这套协议走完，用户拿到的不是"18 个人各自发言"，而是一份带分歧地图的决策稿——这也是这套 skill 真正的产出形态。

八、20 个 Triad：把"领域知识"预编译到成员组合里

README 把 20 个常用 triad 直接列在表里。这个设计预先把"哪些角色对哪些问题有用"压成了可枚举的入口：

Triad 的价值在于把"应该问谁"从开放问题降级为枚举选项：用户不需要记住 18 个人谁跟谁合得来，只需要选领域。

这种做法在用户体验上和"用 RAG 检索相关 agent"等价，但省去了 RAG 系统本身的工程成本——一次 git clone + ./install.sh 就拿到全部 20 个 triad。

九、benchmark 解读：协议性指标 vs 决策性指标

Council 不是一个有 benchmark 的系统（没有测试集、没有分数榜），所以这一节回答的不是"它跑得多快"或"准确率多高"，而是协议性的硬指标：这些数字变化到底反映系统的哪一部分。

第一类：轮次预算指标。

数字变化反映的不是"模型能力"，而是协议设计对决策深度的影响——同一个问题在 full 和 quick 下的输出结构差异由协议而非模型决定。

第二类：consensus 指标。

• 加权 2/3 多数：贴题席位 1.5×、其余成员 1×，席位在协议开始前锁定；v1.2.0 起每票再乘上成员自报的置信度因子（high 1.0 / med 0.75 / low 0.5）。
• 未能达成直接以全票计票形式回吐给用户。
• 未尝试合成假共识——这是 README 反复强调的设计原则。

从这些指标不能直接推出什么：

• 不能推出"加权投票比简单多数更准确"——共识本身的质量依赖 triad 配置和领域权重指定。
• 不能推出"未达成 2/3 = 答案错误"——可能只是问题本身模糊（这时 Step 2 的 Problem Restate Gate 应该已经暴露）。
• 不能推出"20 个 triad 是完备的"——它们覆盖 README 写出来的高频领域，但低频领域需要用户自己组合成员。

第三类：provider 路由指标。

• 极性对必须跨 provider（硬约束）；
• 成员均匀分布（SKILL.md 将其与极性对分离并列为硬约束）；
• 任意 provider 失败 → 自动回退 Claude。

从路由指标不能推出什么：

• 不能推出"路由到 6 个 provider = 决策质量提升 6 倍"——provider 数量只是保证模型家族多样性，不是性能指标。
• 不能推出"用 NVIDIA NIM 的开放权重模型 = 开源本地决策"——NIM 仍然是远程推理，只是模型权重开放。

因此，本节真正给读者的是一把尺子：当你看到别人报告 Council 的"决策质量"时，先问一句——他用的是哪个 mode？panel 里有哪些成员？领域权重席位给了谁？

十、采用顺序与适用边界

不是所有人都该用 Council。以下是按团队类型的采用建议：

适合：

• 战略级、产品级决策——需要对抗模型家族偏差的场景。
• 多视角决策已有共识但希望结构化对抗——而不是"再开一次会"。
• 已经有 Claude Code 或 Codex 的本地工作流——./install.sh 加一行命令就能跑。
• 已经有 6 个 provider 中的至少 2 个——自动路由才能产生真正的"跨模型"。

不适合：

• 单点技术决策、bug 排查——execution-lean 也嫌重，直接问 Claude / Codex 更划算。
• 需要大量事实查询的决策——Council 不擅长"找出正确答案"，擅长"列出不同视角"。
• 团队无 Claude Code / Codex 工作流——./install.sh 的全部价值建立在 agent + subagent 已就位的前提上。

快速开始（5 分钟验证）：

Claude Code 用户走插件市场最短，两行装完：

/plugin marketplace add 0xNyk/council-of-high-intelligence
/plugin install council@council-of-high-intelligence

Codex / Gemini CLI / OpenCode 用户走安装脚本：

# 1. 克隆仓库
git clone https://github.com/0xNyk/council-of-high-intelligence.git
cd council-of-high-intelligence

# 2. 安装 skill（Claude Code 直接 ./install.sh；其他端用对应 flag）
./install.sh          # 或 --codex-only / --gemini-only / --opencode-only

# 3. 检查路由配置，不实际运行
/council --dry-route

# 4. 用 duo 模式跑一个轻量测试（2 人 3 步）
/council --duo "我应该选哪个数据库？"

安装后重启对应的客户端，/council 命令在所有受支持的 host 上同名。

采用顺序：

1. 先做 --dry-route：打印路由表，确认 provider 配置无误。
2. 跑 demo session pack：demos/session-pack.md 测试 3 个模式。
3. 用 --quick --duo 起步：先用轻量模式验证你的问题确实"需要 18 人"。
4. 再升级到 --full：评估 full 模式的输出对你实际决策的影响。
5. 最后上 --copy-configs：安装 provider-model-slots 模板，进入多 provider 阶段。

十一、结尾：回到系统层价值

Council 的价值不在 18 个 persona 的"模拟"，而在三件事：

1. 极性配对 + 跨 provider 路由——把模型家族偏差从"系统性风险"降级为"被强制对抗的局部偏差"。
2. 7 步协议 + enforcement scan——把"对话"重构成"决策"，未达成的分歧也是有效输出。
3. 20 个 triad 预编译——把"该问谁"从开放问题降级为枚举选项。

因此它的真正定位是给 Claude Code / Codex 用户的一份"决策协议附件"：Claude 依然是干活的那个，Council 只是在它旁边加了一排结构化的对手席。

如果你已经在 Claude Code / Codex 上工作，面临"再问一次还是一样答案"的瓶颈，Council 提供的不是更多答案，而是让现有答案先互相撕一遍。

十二、常见问题

Q: Council 一定要 18 个 persona 全跑吗？ 不用。--profile execution-lean 只跑 5 人，--quick 只跑 2 轮，--duo 只跑 2 人。战略级问题才需要 full 模式。

Q: 我只有 Claude Code，没有装其他 provider，还能用吗？ 能用。Council 会以 Claude 为兜底，所有成员都跑在 Claude 上。但这样就失去了"跨 provider 强制分流"的意义，极性配对仍在同一家族内，对抗效果会打折扣。

Q: 装了 Council 之后，Claude Code 会变慢吗？ 不会。Council 是按需触发的——只有输入 /council 命令时才启动协议。平时正常使用 Claude Code 不受影响。

Q: weighted 2/3 多数决的"领域权重"怎么指定？ 领域权重席位（domain-weight seat）在协议开始前就锁定：协调者按问题匹配最相关的成员，给 ta 1.5× 的平票权重，并在 [CHECKPOINT] 里明示；锁定时点必须在任何立场形成之前，避免事后加权。若两个成员同样贴题，则不设权重席位，平票时按等权处理。

Q: 成员之间质询时看得到彼此真名吗？ 看不到。Round 2 全程使用 Member A / Member B / … 匿名标签，连"哪段是自己写的"都不披露，防止声望偏见和从众效应。质询结束后协调者才恢复实名映射，实名版记录仅用于最终审计。

Q: 如果未达成 2/3 共识，输出是什么？ Council 不会合成虚假共识，而是直接输出：完整计票结果 + 各成员 STANCE: 行 + unresolved questions + recommended next steps。投了 DEALBREAKER: yes 的少数派立场会进 Minority Report 单独呈现。由用户决定如何继续。

Q: Council 的输出太长，怎么快速抓住重点？ 直接看 Step 7 Verdict Synthesis 部分的 STANCE: 汇总和 unresolved questions。如果想深入，再回看 Step 4 的 cross-examination 部分，了解分歧的具体原因。

自测题

请回答以下问题检验你的理解：

1. Socrates 和 Feynman 的极性配对逻辑是什么？为什么必须跨 provider？

2. 7 步协议中哪一步是"强制对抗"发生的地方？

3. execution-lean 只有 5 个人，为什么反而更适合技术决策？

4. 如果 Council 未达成 2/3 共识，输出是什么？

练习

练习 1：配置并测试路由

目标：验证你的环境是否支持多 provider 路由。

步骤：

1. 克隆仓库并安装：git clone https://github.com/0xNyk/council-of-high-intelligence.git && cd council-of-high-intelligence && ./install.sh
2. 运行 /council --dry-route 查看路由表
3. 确认至少 2 个 provider 可用（例如 Claude + OpenAI）
4. 记录哪些 persona 被路由到了哪个 provider

检验：你能解释为什么 Socrates 和 Feynman 不会被路由到同一个 provider 吗？

练习 2：运行一次 duo 模式决策

目标：体验最小化的对抗决策流程。

步骤：

1. 启动 Claude Code 或 Codex
2. 输入 /council --duo "我应该选哪个数据库？"
3. 观察 2 位成员如何互相质疑
4. 查看最终的 STANCE: 输出

检验：对比直接用 Claude 问答和用 Council duo 模式的答案差异。

练习 3：设计一个领域 triad

目标：为你的实际工作场景选择合适的 triad。

场景：你在做一个涉及安全、性能和团队协作的技术决策。

任务：

1. 从 18 个 persona 中选择 3 个最适合这个场景的角色
2. 解释为什么选这 3 个（考虑极性配对）
3. 用 /council --triad <你的triad名称> 测试你的配置

参考答案：

• 安全：Sutskever（前沿安全）+ Socrates（拆假设）
• 性能：Torvalds（具体方案）+ Feynman（第一性原理）
• 团队协作：Aurelius（内心治理）+ Meadows（系统思考）

资料口径说明

• 仓库：0xNyk/council-of-high-intelligence。写作时点为 CC0 公有领域贡献，2026 年 9 月复核时已改为 MIT。
• 本文中 18 personas 表、3 panel、20 triad、7 步协议、6 provider 表均来自 README 截至 2026-06-30 的版本（commit 68cd247，2026-06-27）；“极性对 13 组全表"与"20 个 triad 全表"补齐自同一版本 SKILL.md 的同名表格，--duo 配对表另含 Sutskever↔Machiavelli、Socrates↔Watts 两组。
• 2026-09-25 复核（commit dd09e28，2026-09-21）：仓库 star 4,502、fork 426；License 已由 CC0 改为 MIT。协议主线未变，但有三处演进值得知道：① v1.2.0（2026-07-04，#44）起计票改为置信度加权——成员投票权重 = 基础权重（1.0 或 1.5× 领域席位）× 置信度因子（high 1.0 / med 0.75 / low 0.5），摇摆的议会自己抬高共识门槛、把分歧升级给用户（依据 Roundtable Policy arXiv:2509.16839、ConfMAD arXiv:2509.14034）；② Claude Code 插件市场安装（#45）：/plugin marketplace add 0xNyk/council-of-high-intelligence + /plugin install council@council-of-high-intelligence，并支持项目级 ./.council.yaml 固定 profile/triad/members/chairman；③ 极性对主表已由 13 组并入为 15 组（#50、#51 修复漂移），并新增 scripts/validate-roster.py 在 CI 里跑 166 项结构检查防 roster 漂移。本文机制细节以 2026-06-27 口径为准，上述差异已在正文相应位置标注。
• 匿名质询、STANCE: <option> | CONFIDENCE: … | DEALBREAKER: … 三字段立场行、Chairman 合成角色（SKILL.md STEP 1.7）在 2026-06-27 版本均已存在，属本文口径范围内。
• Gemini CLI 支持于 2026-06-27 加入（#35），OpenCode 支持于 2026-07-03 提交、PR #41 于 2026-07-04 合入，均可通过 ./install.sh --gemini-only、./install.sh --opencode-only 单独安装；本文主体仍以 2026-06-30 的 Claude Code / Codex 口径为准。
• “极性配对”、“execution-lean”、“weighted 2/3 majority”、“hemlock rule” 等术语均沿用 README/SKILL.md 原文。
• Trending 数据来源：github.com/trending daily 2026-06-30 15:00 (Asia/Shanghai)。
• 文章不依赖任何特定 provider 的可用性；具体 provider 配置请参考 configs/provider-model-slots.example.yaml。