# 三个臭皮匠，顶个诸葛亮：让便宜模型协同工作

**Summary:** 一堂来自中文俗语“三个臭皮匠，顶个诸葛亮”的个人 AI 架构课：为什么便宜模型会被巨大提示词压垮，以及聚焦的专家会话、编排、综合和温度控制如何让它们变得有用。

- Canonical: https://markhuang.ai/zh/blog/three-cobblers-one-zhuge-liang-ai-architecture
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-04-30
- Section: AI 与 LLM
- Tags: AI 架构, 弱模型, 多 AI, 提示工程, LLM 成本, 编排
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![古代谋士剪影俯瞰三个专注的 AI 工作站，工作站之间由柔和光线连接](https://cdn.markhuang.ai/blog/three-cobblers-one-zhuge-liang-ai-architecture/hero.webp)

*古代谋士剪影俯瞰三个专注的 AI 工作站，工作站之间由柔和光线连接*

每次思考 AI 架构的时候，我都会想起一句老话：

> 三个臭皮匠，顶个诸葛亮

诸葛亮是三国时期的传奇军师，后来几乎成了"智慧"的代名词。这句话说的不是皮匠，而是视角的汇聚。三个普通人，只要协调得好，就能跟一个天才抗衡。

当 token 账单开始影响架构决策时，这句话突然变得特别实用。

很长一段时间里，遇到复杂的 AI 工作流，默认答案很简单：用你能负担得起的最强模型。跑 Sonnet，跑 Opus，跑最好的 GPT。如果输出漏东西，就加更多指令。最后 prompt 变成一大坨：需求、示例、边界情况、日志、约束，还有一堆"请小心"全塞进一个请求里。

看起来挺合理。但这也是便宜模型开始撑不住的地方。

## 巨大 prompt 的陷阱

![一个小模型节点被充满纠缠需求的巨大发光提示词团块压住](https://cdn.markhuang.ai/blog/three-cobblers-one-zhuge-liang-ai-architecture/prompt-blob.webp)

*一个小模型节点被充满纠缠需求的巨大发光提示词团块压住*

Haiku 级别的小模型很有用。它们快，便宜到可以反复调用，也擅长窄任务。但它们不是缩小版的 Opus。

跟 Sonnet 比，小模型更容易漏掉长 prompt 里的第二、第三个约束。它可能遵守主指令，却忘掉例外。跟 Opus 比，差距更明显：长线规划、冲突解决、自检能力都弱一些。当它犯下一个看似合理的错误时，它常常会把错误包装得更像回事，而不是发现错误。

这并不意外。问题不在于 Haiku 会漏东西，而在于我们把工作流设计得好像它不该漏。

## 第一步改进：把任务和规则分开

我学到的第一个修正特别简单：不要把所有东西都塞进 user prompt。

清晰的 system prompt 会改变任务的形状。System prompt 定义角色、优先级、约束、输出规范和评估标准。User prompt 承载具体的任务内容。这个分离很重要，因为模型不必再猜哪些是永久规则，哪些是一次性数据。

对弱模型来说，这个差别很大。聚焦的 system prompt 像护栏一样先限定判断方式。比如："你是需求审计者。只检查缺失的验收标准。以 JSON 返回发现的问题。"这比在一段很长的 prompt 第十二段里写"也请像需求审计者一样工作"更容易执行。

原因很具体：小模型同时处理指令的带宽更小。当规则、示例、数据和期望输出混在一起时，模型必须把注意力摊开。System prompt 先锚定行为，再让任务数据流过它。

这不会让弱模型突然变聪明，但会让任务变窄。

## 真正的架构：三个皮匠

![多个聚焦的模型会话分别检查同一个问题的不同切片，再把结构化笔记传递下去](https://cdn.markhuang.ai/blog/three-cobblers-one-zhuge-liang-ai-architecture/specialist-sessions.webp)

*多个聚焦的模型会话分别检查同一个问题的不同切片，再把结构化笔记传递下去*

专业的答案不是"写一个更好的巨大 prompt"，而是"别让一个 session 同时扮演所有角色"。

把工作拆开。

一个 session 检查需求，另一个找边界情况，第三个抽取事实，下一个找矛盾，最后一个重写语气。每个 session 都有自己的 system prompt 和窄任务 prompt。它们不需要都是诸葛亮，只需要在自己负责的小角落足够可靠。

然后用一个最终的 synthesis session 合并结果。

这就是谚语变成架构的地方。三个职责明确的小模型，可以覆盖比一个过载模型更大的表面积。提升不是来自假装弱模型很强，而是减少每个模型可能忘掉的事情数量。

当子任务相互独立时，并行很有用：安全评审、UX 评审、成本评审、事实抽取。当一个输出会变成下一个输入时，链式处理更合适：分类、抽取、验证、总结。不管哪种方式，关键动作都一样：把一个宽泛判断，换成多个狭窄判断。

## Hub-and-spoke 模式

![中央编排节点在周围专门 AI 智能体之间路由结构化上下文](https://cdn.markhuang.ai/blog/three-cobblers-one-zhuge-liang-ai-architecture/hub-spoke.webp)

*中央编排节点在周围专门 AI 智能体之间路由结构化上下文*

还有一个我喜欢的模式：hub-and-spoke。

一个 session 担任 orchestrator。它不直接解决整个问题，而是决定哪个 specialist agent 应该检查哪一部分。它只传递相关 context，收集回复，并在输出冲突时追问。最后再综合答案。

当工作不是干净的 pipeline 时，这个模式很有用。真实任务很乱。Review agent 可能发现缺失需求，缺失需求又需要回到 planning agent。Cost agent 可能反对当前架构。Orchestrator 让状态继续流动，而不要求每个 specialist 理解整个世界。

诀窍是保持 orchestrator 诚实。它应该传结构化摘要，而不是含糊感觉。它应该保留分歧，而不是把分歧掩盖过去。当外围 agent 给出冲突答案时，最终 synthesis 应该说出来，或者升级给更强模型。

便宜模型在这里有用，因为它们变成传感器。每个模型从一个特定角度观察。Orchestrator 不需要它们完美，只需要足够的覆盖面，让重要遗漏更不容易发生。

## 最后一个旋钮：temperature

![一个精确温度旋钮在可预测流水线工作和创意探索之间保持平衡](https://cdn.markhuang.ai/blog/three-cobblers-one-zhuge-liang-ai-architecture/temperature-dial.webp)

*一个精确温度旋钮在可预测流水线工作和创意探索之间保持平衡*

Temperature 不能治好弱推理，但它是让 pipeline 少一点混乱的最简单旋钮之一。

对于抽取、验证、分类、synthesis 和评审，我希望 temperature 低。可预测性比新奇更重要。如果相同输入每次产生不同 schema 或不同判断，工作流会很难调试。

对于创意工作，我会调高它。命名、头脑风暴、比喻、初稿文案、视觉想法，这些任务受益于变化。我不希望模型每次都返回最安全的平均答案。

错误在于所有地方都用同一个 temperature。架构任务需要不同模式。检查合规的 specialist 应该无聊；提出博客标题的 specialist 可以松一点；orchestrator 通常应该保守。

这就是我反复学到的课：不要把所有精力放在寻找一次完美模型调用上。设计工作，让不完美的调用仍然有用。

三个皮匠不会神奇地变成诸葛亮。但如果每个人都知道自己该看什么，并且有一个冷静的角色把结果合起来，系统就可以惊人地接近。