企业官网建设流程全解析

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Claude 随心用，限时 5 折。 👉 点击领海量免费额度

在实际的 AI 应用开发中，我们常常面临一个困境：面对一个复杂的技术决策或战略问题，向单一的大语言模型提问，得到的往往是一个逻辑自洽、充满自信，但可能完全错误的答案。这种“单一视角的自信”在架构选型、产品方向、技术债务处理等关键决策上，可能带来巨大的风险。council-of-high-intelligence项目正是为了解决这个问题而生。它不是一个简单的提示词集合，而是一个模拟了 18 位来自不同领域、拥有不同思维模式的“智者”进行结构化、多轮辩论的决策框架。通过强制引入模型多样性、观点对立和交叉质询，它将一个“提问-回答”的过程，转变为一个“提问-辩论-裁决”的完整决策流程，旨在暴露未知、挑战假设，最终生成一个包含分歧、不确定性和后续行动建议的审慎结论。

本文将带你从零开始，深入理解并部署council-of-high-intelligence。无论你是希望将其集成到日常开发决策流程中的技术负责人，还是对多智能体协作和高级提示工程感兴趣的研究者，都能通过本文掌握其核心概念、安装配置、运行机制，并了解如何在实际项目中规避常见陷阱，发挥其最大价值。

1. 理解“高智商委员会”的核心机制与价值

在深入命令行之前，我们必须先理解council-of-high-intelligence的设计哲学。它不是一个聊天机器人，而是一个决策模拟器。其核心价值不在于生成一个“最终答案”，而在于通过结构化的流程，最大化地暴露问题本身的复杂性、我们认知的盲区以及不同解决方案的潜在风险。

1.1 为什么单一 LLM 的决策存在风险？

当你向 Claude、GPT 或 Gemini 提出一个开放式复杂问题时，模型会基于其训练数据生成一个概率上最连贯、最符合你预期的回答。这个过程存在几个固有缺陷：

• 单一推理路径：模型只提供了一条从问题到结论的“最可能”路径，隐藏了其他同样合理甚至更优的可能性。
• 隐藏的假设：模型的回答基于大量未被言明的、内嵌于训练数据中的假设，这些假设可能与你的具体情境不符。
• 自信的谬误：流畅、结构化的文本会给人以高度自信和正确的错觉，即使内容存在事实或逻辑错误。
• 缺乏对立面：没有机制去系统性地质疑初始问题、挑战结论的根基或从完全相反的视角进行审视。

council-of-high-intelligence通过引入多样性和对抗性来系统性应对这些问题。

1.2 核心设计原则：多样性、对抗性与结构化流程

项目的设计围绕三个核心原则展开：

1. 成员多样性：委员会由 18 位具有鲜明“人格”和思维模式的 AI 角色组成，如擅长分类的亚里士多德、擅长质疑的苏格拉底、注重第一性原理的费曼、讲究实用主义的林纳斯·托瓦兹等。每个角色都绑定了一个默认的 LLM 提供商（如 Claude Opus, Sonnet），并且项目支持自动将不同成员路由到不同的后端模型（Anthropic, OpenAI, Google, Ollama 等），确保观点差异不仅来自提示词，更来自底层模型本身的差异。
2. 极性配对：成员并非随机选择，而是精心配对的“对立面”。例如：
   • 苏格拉底 vs 费曼：一个负责摧毁自上而下的假设，一个负责自下而上地重建。
   • 亚里士多德 vs 老子：一个致力于将万物分类结构化，一个认为“结构本身就是问题”。
   • 孙武 vs 马可·奥勒留：一个专注于应对外部竞争和地形，一个专注于内在的坚韧与道德清晰。 这种配对强制在分析中产生真正的张力，而非表面的附和。
3. 结构化审议协议：审议不是自由讨论，而是一个有严格步骤、字数限制和强制规则的流程。以“完整模式”为例，其 7 个步骤确保了审议的深度和效率：
   • 问题重述门：每位成员必须先用自己的话重述问题，并提供另一种可能的框架。这一步能提前暴露模糊或错误的问题定义。
   • 独立分析：成员并行进行首轮分析。
   • 交叉质询：成员必须挑战至少两位其他成员的观点。
   • 强制执行扫描：检查异议配额、新颖性门槛，防止过早达成共识。
   • 最终立场：成员提炼自己的最终立场。
   • 裁决合成：最终报告首先列出“未解决的问题”和“建议的后续步骤”，共识反而是次要的。

这种设计的结果是，你得到的不是一个“答案”，而是一个包含了多元视角、核心分歧、知识盲区和行动建议的决策简报。

2. 环境准备与项目安装

要让这个“委员会”运转起来，你需要一个能够运行 AI 智能体的客户端环境。项目主要支持 Claude Code 和 Cursor 的 Codex 模式，并能自动集成多个 LLM 提供商。

2.1 基础环境与客户端选择

首先，你需要确保拥有以下至少一个客户端的访问权限和基础配置：

注意：虽然项目也支持原生 OpenAI、Gemini、Ollama 等作为后端模型提供者，但这些通常作为“委员”的模型来源被自动路由使用，而非必须的交互客户端。与委员会交互的主界面是 Claude Code 或 Cursor Codex。

2.2 安装“高智商委员会”

安装过程本质上是将 18 个智能体定义（技能文件）部署到你的本地客户端配置目录中。

1. 克隆项目仓库： 打开终端，执行以下命令获取项目代码。

   git clone https://github.com/0xNyk/council-of-high-intelligence.git cd council-of-high-intelligence

2. 运行安装脚本： 根据你的主要使用客户端，选择对应的安装命令。

   • 如果你主要使用 Claude Code：

     # 默认安装，为 Claude Code 添加 `/council` 命令 ./install.sh

   • 如果你主要使用 Cursor Codex：

     # 为 Codex 安装技能文件 ./install.sh --codex-only

   • 如果你两者都用：

     # 为两者都安装 ./install.sh --codex

   安装脚本install.sh会执行以下操作：

   • 检查必要的 CLI 工具（claude或cursor-agent）是否存在。
   • 将agents/目录下的智能体定义文件（.md文件）复制到客户端对应的技能目录（例如~/.claude/skills/或~/.codex/skills/）。
   • 为你创建便捷的/council命令。

3. （可选）安装多模型路由配置模板： 如果你想充分利用多模型提供商（如同时使用 Claude、GPT 和本地 Ollama 模型），可以复制示例配置进行定制。

   ./install.sh --copy-configs

   这会将configs/目录下的示例 YAML 配置文件复制到项目根目录，供你后续修改。

4. 重启你的客户端： 安装完成后，必须完全退出并重新启动你的 Claude Code 或 Cursor 应用，以确保新的技能被加载。

5. 运行验证脚本（可选但推荐）： 项目提供了一个检查脚本，用于验证安装是否成功，并模拟一个简单的问题来测试所有基础功能。

   ./scripts/council-simulation-checklist.sh

   如果看到各委员开始发言并进行多轮审议，最后输出一个裁决，说明安装成功。

2.3 配置多模型提供商（高级）

委员会的核心优势之一是自动将不同成员分配到不同的 LLM 后端。以下是配置步骤：

1. 安装目标提供商 CLI：

   • OpenAI (Codex):npm install -g @openai/codex
   • Google Gemini: 参考gemini-cli项目安装。
   • Ollama: 从 ollama.com 下载安装，并拉取所需模型，如ollama pull llama3.2:1b。
   • Cursor CLI: 已作为主客户端安装。
   • NVIDIA NIM: 无需 CLI，只需设置环境变量export NVIDIA_API_KEY=your_nvapi_key。

2. 理解自动路由逻辑： 安装后，委员会启动时会自动检测系统中可用的提供商。其路由策略为：

   • 硬性约束：配对的“极性”成员（如苏格拉底和费曼）会被分配到不同的提供商，以确保观点多样性。
   • 均衡分布：成员尽可能均匀分布在所有可用提供商中。
   • 故障回退：如果某个提供商调用失败，会自动回退到 Claude。

3. （可选）手动指定路由： 你可以创建一个 YAML 配置文件来精确控制哪个委员使用哪个模型。首先复制示例文件：

   cp configs/provider-model-slots.example.yaml my-routing-config.yaml

   编辑my-routing-config.yaml，其结构如下：

   # my-routing-config.yaml provider_model_slots: anthropic: - council-aristotle - council-socrates openai: - council-feynman - council-torvalds ollama: - council-lao-tzu gemini: - council-sun-tzu

   运行时通过--models参数指定该文件：

   /council --models ./my-routing-config.yaml “我们的产品应该优先优化性能还是增加新功能？”

3. 核心使用模式与命令详解

安装配置完成后，你就可以召唤“委员会”了。所有交互都通过/council命令及其参数进行。

3.1 三种审议模式

委员会提供三种不同深度和速度的审议模式，适用于不同场景。

基础命令示例：

# 完整模式：讨论是否开源一个框架 /council Should we open-source our agent framework? # 快速模式：评估是否在代码中添加缓存 /council --quick Should we add caching to this module? # 双人模式：探讨微服务与单体架构的选择，指定苏格拉底和费曼辩论 /council --duo --members socrates,feynman Should we use microservices or a monolith?

3.2 使用预定义“三人组”与“委员会档案”

为了应对特定领域的问题，项目预定义了20个“三人组”和几个“委员会档案”，它们是由特定成员组成的专家小组。

• 预定义三人组：使用--triad <triad-name>参数。例如：

  # 使用“架构”三人组（亚里士多德、艾达·洛夫莱斯、费曼）讨论数据库选型 /council --triad architecture “Should we use a relational database or a document store for our user profiles?” # 使用“决策”三人组（卡尼曼、芒格、奥勒留）讨论商业报价 /council --triad decision “Should we accept this acquisition offer?”

• 委员会档案：使用--profile <profile-name>参数。例如：

  # 使用“经典”档案（默认，18人全体） /council --profile classic “What is the long-term impact of AI on software engineering?” # 使用“探索-正交”档案（12人，专注于发现未知） /council --profile exploration-orthogonal “What are the blind spots in our current product roadmap?” # 使用“执行-精简”档案（5人，专注于快速行动） /council --profile execution-lean “What’s the fastest path to get our MVP to users next week?”

3.3 关键运行参数解析

除了模式和小组，还有其他参数可以精细控制委员会的行为。

组合使用示例：

# 一个复杂的命令：使用“产品”三人组，手动指定成员，并禁用自动路由进行快速审议 /council --triad product --members torvalds,rams,watts --no-auto-route --quick “Is our new UI design intuitive enough for non-technical users?”

4. 解读审议结果与裁决报告

委员会的输出不是闲聊记录，而是一份结构化的决策报告。理解如何阅读这份报告至关重要。

4.1 裁决报告的结构

一份完整的“完整模式”裁决报告通常包含以下部分：

1. 问题重述摘要：委员会成员如何重新框架你的原始问题。这是检验问题质量的第一步。
2. 独立分析摘要：第一轮中，各成员从自身视角出发的核心论点。
3. 交叉质询亮点：第二轮中，成员之间最具挑战性的相互质问。
4. 最终立场：第三轮后，每位成员用一句话（STANCE:）表明的最终立场。
5. 投票统计：基于最终立场的结构化统计，显示支持、反对、弃权等分布。
6. 未解决的问题：这是报告中最关键的部分。委员会明确指出哪些方面信息不足、存在矛盾或无法达成共识。
7. 建议的后续步骤：基于审议，提出的具体、可操作的调查或实验建议。
8. 裁决摘要：对整体讨论的总结，通常不会是一个简单的“是/否”答案。

4.2 如何从报告中提取价值

不要只寻找“答案”，而应关注以下几点：

• 审视“未解决的问题”：这部分直接指出了你的决策盲区。你是否能回答这些问题？是否需要为此收集更多数据？
• 分析“投票统计”中的分歧：分歧点在哪里？是目标不一致（亚里士多德 vs 老子），还是方法不一致（托瓦兹 vs 孙武）？分歧揭示了决策的核心矛盾。
• 关注“建议的后续步骤”：将模糊的决策转化为具体的待办事项。例如，“运行一个A/B测试来测量缓存命中率”比“考虑性能”有价值得多。
• 回顾“问题重述”：如果你的问题被多位成员以不同方式重述，说明原始问题可能模糊不清。一个好的问题重述本身就能照亮解决路径。

4.3 示例报告片段分析

假设我们询问/council --triad architecture “Should we introduce a GraphQL layer in front of our REST API?”，报告可能包含：

... UNRESOLVED QUESTIONS: - What is the expected query complexity from our client teams? (Feynman) - Do we have the operational expertise to monitor and secure a GraphQL endpoint? (Torvalds) - Is the performance overhead acceptable for our high-write use cases? (Ada) RECOMMENDED NEXT STEPS: 1. Prototype a single GraphQL resolver for our most complex `User` aggregate and measure the N+1 query impact. 2. Survey frontend teams to catalog the 5 most common “chatty” REST calls that could be batched. 3. Run a load test comparing the 95th percentile latency of the REST vs. GraphQL endpoint for a composite read. VERDICT SUMMARY: The council is divided on necessity but aligned on prerequisites. Aristotle and Ada see structural elegance but warn of formal complexity. Torvalds demands a concrete performance benchmark before any “elegant” abstraction is considered. The path forward is not a yes/no on GraphQL, but a yes on the three validation steps above.

这份报告的价值在于：它没有给出“用或不用 GraphQL”的答案，而是将决策转化为三个可验证的工程任务，并明确了不同观点背后的核心关切（性能、复杂度、运维）。

5. 常见问题排查与最佳实践

在实际使用中，你可能会遇到一些问题。以下是一些常见问题的排查方法和使用建议。

5.1 安装与运行问题

5.2 使用技巧与最佳实践

1. 从具体问题开始：不要问“如何做好一个产品？”（太宽泛）。要问“基于我们当前 V1 的用户留存数据和团队 3 人前端的现状，下个季度应该优先优化 onboarding 流程还是开发社交分享功能？”（具体、有上下文）。
2. 善用“双人模式”化解僵局：当团队对某个二元选择争论不休时，用--duo模式让代表两种极端思维的委员（如torvaldsvswatts）进行辩论，将辩论记录分享给团队，往往能打破僵局。
3. 将委员会用于“前置检查”而非“事后批准”：在形成初步方案后，让委员会挑战它。例如，在技术设计文档完成后，询问/council --triad debugging “What are the weakest assumptions in this technical design?”。
4. 管理成本：完整模式调用多个模型，成本较高。对于探索性、非关键问题，可以使用--quick模式或仅使用--profile execution-lean。对于生产级关键决策，其成本相对于决策风险往往是值得的。
5. 保存与迭代：重要的审议结果应该保存下来。你可以将问题和裁决报告记录在决策日志中。几个月后，用实际结果回头审视委员会的“未解决问题”和“建议步骤”，评估其预测和建议的质量，这是一个极佳的学习循环。
6. 不要盲从裁决：委员会是高级的“魔鬼代言人”和“思维扩展器”，而不是绝对正确的预言家。它的价值在于暴露风险和视角，最终的决策责任仍然在你。

5.3 生产环境考量

如果计划在团队或持续集成环境中使用，需要考虑以下几点：

• 配置外部化：将多模型路由配置（provider-model-slots.yaml）和常用的--triad、--profile设置固化下来，形成团队标准。
• 设置预算与监控：为使用的各 LLM API 设置月度预算和告警。审议报告本身可以记录 token 使用量。
• 版本化智能体定义：agents/目录下的.md文件是核心资产。考虑将其纳入版本控制系统（如 Git），以便跟踪变更和回滚。
• 与工作流集成：可以将/council命令集成到 PR 描述模板中，针对重大代码变更自动发起一个快速审议，将结果作为评论附加。

council-of-high-intelligence提供了一个强大的框架，将 LLM 从“问答机”转变为“辩论伙伴”。它的核心贡献不是自动化决策，而是通过强制引入多样性、对抗性和结构化，极大地提升了复杂决策过程的思考质量。最有效的使用方式，是将其视为一个永不疲倦、视角多元的“红队”或“战略顾问”，在你做出重要选择之前，为你进行最后一次压力测试和视角补充。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Claude 随心用，限时 5 折。 👉 点击领海量免费额度