33 个 AI 专家全票通过？那问题才刚开始

让 AI 扮演安全专家审代码、扮演产品经理审需求——这件事越来越多人做。但有一个隐蔽陷阱很少有人提：多名 AI 评审达成统一意见，不代表结论可靠。 当你让同一个模型同时扮演"安全专家""架构师""测试"，角色换了，底下的推理引擎没换。很容易形成「集体幻觉」——所有人一起犯同样的错，你分不清是真共识还是一个盲区在多个角色间的回声。网上大多数多角色 Prompt 方案，没有解决这个根本缺陷。

针对重度技术写作、实验校验、代码审查场景，我自研了一套双池专家评审架构。下文完整介绍工作流、调度机制、自动化脚本，同时客观说明这套体系的维护成本和固有限制——不神化，不推销。⚠️ 本方案有持续知识库维护成本，不适合追求开箱即用的轻度使用者。

这套思路起源于今年 6 月参与 alirezarezvani/claude-skills 开源项目讨论时，提出的命名人物质疑性评审概念。PR 因结构缺陷未合并，但维护者认可核心 idea，自行开了 #867 硬化实现并署了我的名。这个经历让我意识到很多开发者在独立工作中遇到了同样的难题——于是有了这套完整工程。

架构全景

核心链路：触发 → 路由调度 → 双池匹配 → LLM 推理 → 多角色输出 → 机械门校验 → 人判断。黄色高亮节点标注了本文反复强调的盲区：所有角色共享同一推理引擎，33 人同意不一定是 33 个独立判断。

命名专家 > 抽象角色

别让 AI 扮演"安全专家"。给它一个真实的人名。一个有文档记录、可搜索、可溯源原则的人。

Ken Thompson，不是"安全专家"。他 1984 年的图灵奖演讲 Reflections on Trusting Trust 给了你一个实际的分析透镜——供应链风险、第三方代码的信任边界、在信任边界处校验输入。不是一个感觉，一个你可以自己去读的文档化框架。

Don Norman，不是"UX 审查者"。《设计心理学》。可供性、示能、概念模型。第一章。可搜索，可验证。

一个真实例子。Torvalds 在 TED 2016 里演示"好品味"——遍历链表删除节点的函数，一般人写一堆 if 判断边界条件。他消除特殊情况，零个 if，代码行数减半。这不是"风格好"——是消除特殊情况，而不是处理特殊情况。 这条原则落在我代码里：看到 if-else 链先问"能不能让这些情况不存在"，而不是"能不能写好这些 if"。

当这些人审查你的工作时，反馈锚定在模型生成循环之外的某个东西上。Carmack 不会说"建议优化一下"——他会标出你在没有测量的情况下猜测性能，因为他的文档化原则是"先测量，再优化"。你可以验证这条原则。你可以决定它是否适用于这里。

这就是反伪造纪律。 每条归因带置信度：

• high — 我能给你看来源。Torvalds 的 TED 演讲。Thompson 的图灵演讲。页码。
• moderate — 和他们文档化的工作一致，但找不到精确引文。
• low — 我的推断。明确标注。当作建议处理，不是分析。

规则：做不到 moderate 以上置信度，删掉这个人。宁可少几个真专家，也不加一个伪造的。模型会很乐意编一段听起来合理的 Carmack 语录。别让它得逞。

我的固定池：33 人，6 领域。每个人物带 citeable source + 置信度：

• Torvalds "好品味"（消除特殊情况）→ 2016 TED，confidence: high
• Thompson 信任边界 → 1984 图灵奖演讲，confidence: high
• Carmack "先测量再优化" → .plan 文件 + QuakeCon，confidence: high
• 余光中 "中文的生命在动词" → 1987 明报月刊，confidence: high

前提解耦了，推理没有

命名原则确实比"扮演质疑者"强。Torvalds 真的在 TED 2016 说了链表那件事——审查意见锚定在模型生成循环外的可验证事实上。这是一小块真正的独立性。

但它解耦的是前提，不是推理。

选哪条原则是锚定现实的。这条原则用在这里对不对、用得对不对——还是同一个基座模型在判断。33 个角色是 33 套戏服，底下的推理引擎没换。33 人一致同意 ≠ 33 个独立判断。可能是一个盲区在 33 面镜子里反射。

而且多角色共识比单审查者更危险。一个人说"没问题"你会再想想。三个人都说"没问题"——你信了。如果那三个人的"没问题"来自同一个盲区，你以更高置信度出货了。

怎么检测？ 跨模型方差分解。让 Claude-Carmack 和 GPT-Carmack 审同一段——如果 Claude-Carmack 同意 Claude-Thompson 但不同意 GPT-Carmack，方差来源是模型不是专家。如果 Carmack 跨模型一致，专家池是真的。独立性是一个测量问题，不是设计假设。这个验证我还没做——它是我下一步实验的核心。

提前说清楚：这套体系不能消灭幻觉，不能替代独立判断。它让你更难被单一模型的一致性输出欺骗——但它自身引入了一种新的盲区风险。认了再建。

双池：固定池保下限，随机池拉上限

固定池 — 33 个审核过的人。文档化原则。置信度评级。同一个专家审了 10 次之后，他们认得你的模式。Hickey 在你第三次实验设计里能抓到第一次漏掉的东西。

随机池 — 联网搜我没听说过的人。每次 session 一轮：搜 "[领域] engineering philosophy" → 找到陌生名字 → 把他们的透镜应用到我的工作上。打破回音室。有一次，随机池抓到的设计缺陷，两轮固定池都没发现。

随机池还有一个作用：它部分缓解了前面说的"推理未解耦"问题。随机池引入的视角来自模型训练数据之外——我搜到的真实人物的真实原则——输入的多样性高了一点点。不多，但比全是自己池子里的人好。

路由表：别手动选人

33 个人，每次都手动决定谁审什么——你做两次就停了。瓶颈不是审查者的质量，是调度。

所以我建了一张路由表。不是 chatbot，不是 agent。就是一个 YAML 文件：

routes:- id: experiment-designtriggers: ["设计实验", "验证方法论"]load_kb: [kb-experiments, kb-paper-claims]design_review:roles: [Carmack, Hickey, Schell]focus: "method + complexity + clarity"- id: writing-reviewtriggers: ["文章初稿", "发布前审查"]load_kb: [kb-articles, kb-voice-reference]voice_review:roles: [Zinsser, Orwell, Graham]- id: code-reviewtriggers: ["PR ready", "重构完成"]code_review:roles: [Thompson, Torvalds, Beck]focus: "trust boundaries + taste + testability"

我从不手动选人。完成一件事，路由表自动触发，对的专家加载对的上下文。零认知负担。

这就是想法和习惯的区别。

比如"设计实验"这条路。我每次设计新实验——Carmack 问"你在假设什么，测过没有"；Hickey 问"这个复杂度是本质的还是偶然的"；Schell 问"第一次看这个设计，第几步会困惑"。三个人的意见我认可大部分，也驳回了一些。但每次都知道他们为什么这么说——每条判断挂着来源+置信度，不是黑箱。

机械门：别让 AI 记住规则

路由表建得再漂亮也没用——三周后知识库过期、规则腐烂，没人会发现。

我不信任 AI 记得该执行什么。我信任代码。

一个 Python 脚本（_check_kb.py）每次 session 结束时运行。知识库比它的源文件旧？硬失败。路由规则超过 30 天没用过？标红。Session 结束没更新仪表盘？阻断。

听起来小。不是。有机械门之前，我会在 KB 条目过期好几周之后才发现——通常是一个专家基于过时的上下文给了反馈，我行动了，然后才意识到不对。这种事不再发生了。

代码执行规则。AI 遵循规则。永远不要让 AI 对自己执行规则。

真实场景怎么用

回复技术讨论区的质疑。 文章发出去后，总有几个人反复出现——有人每次都从方法论角度挑你实验设计的漏洞，有人从生产环境带真实案例来质疑你的假设，有人直接给你发改进方案说"你应该做这个对照实验"。

回他们之前，我对着屏幕改十几遍心里没底——怕语气不对破坏关系，怕没理解对方真正关心的点，怕回了表面问题漏了深层质疑。现在数字分身先加载对方画像——这个人上次说了什么、最关心什么方向——然后我写回复，专家团过声音门：Carnegie 看关系有没有维持，Voss 看有没有误解对方的意图，Rosenberg 看措辞有没有评判。

不是 AI 替我回。我自己回，有人帮我看。

设计实验。 Carmack 问"你在假设什么，测过没有"；Hickey 问"这个复杂度是本质的还是偶然的"；Schell 问"第一次看这个设计，第几步会困惑"。三个人的意见我认可大部分，也驳回了一些。但每次都知道他们为什么这么说——每条判断挂着来源+置信度，不是黑箱。

这些场景正好是路由表的工作——不同的触发条件匹配不同的专家组合。评论回复触发声音门（Carnegie/Voss/Rosenberg），实验设计触发方法论门（Carmack/Hickey/Schell），代码提交触发信任边界门（Thompson/Torvalds/Beck）。故事不是插曲，是架构的用例。

每一个发出去的东西——文章、实验、回复——都有人帮我看过、质疑过、补过。

会出什么问题

最深的坑：多角色共识 ≠ 多独立判断。 33 个角色在同一个模型上跑——角色换了，底下的推理引擎没换。他们一致同意的时候，你分不清是真共识还是一个盲区的 33 次回声。多角色一致让你比单审查者更有信心——共享盲区以更高置信度出货，比没有审查更危险。

真正的风险：外包判断。 专家团告诉你 Torvalds 或 Norman 或 Carmack 会标出什么。只有你能决定那个标记对你的代码库、你的用户、你的约束是否重要。如果你停止思考开始盲信——你建的这套系统比泛用 prompt 更擅长产出听起来自信的错误答案。那更糟，不是更好。

幻觉依然存在。 命名原则显著减少伪造——但不能消灭。置信度的存在有原因。low = 只是建议。标注它，或者删掉它。

维护是真的。 知识库会过期。工作方向会变。机械门抓过期——它不修内容。那还是你的事。

你会选错人。 有人在纸面上听起来对，实际给出浅层反馈。换掉。池子是活的。每月重访一次。

这个系统做的最好的事不是给你答案。是让你更难被骗——包括更难被它自己骗。

说实话

质疑性评审很多人用，肯定有比我更深的。这个系统不是你用了就变牛——是你不容易犯低级错。没有专家团之前，我总在担心"AI 说的到底靠不靠谱"。有了之后，这个问题基本缓解——不是因为我变聪明了，是因为我知道每个判断的来源和置信度。

我还没有跑过直接对比命名专家审查和泛用 prompt 的对照实验。同一个模型生成的审查，让同一个模型打分——这不叫验证，叫回声。要做合格的对照实验，需要比我目前投入的更多的精力和更严谨的设计。我在做。有数据了我会报告——不管证实还是推翻假设。

同样，跨模型方差分解——验证 33 个专家的独立性到底是真的还是戏服——也是下一步实验的核心。说清楚不是为了显得谦虚。是因为这些问题真实存在，回避它们不会让方案变得更好。

你的专家团，不是我的 33 个

你可能不需要 Carmack。你需要你信任的产品经理、你敬重的设计师、你反复读的那个作家的写作原则。

路由表、机械门、双池编排、反伪造纪律——框架通用。专家是谁，由你定。

建起来很快。expert-pool.md——一个人、一条原则、一个来源、标置信度。三个你每周遇到的情景，每个配两个专家。一个检查脚本，session 结束时跑。

我的路由表、专家池和机械门在 github.com/YuhaoLin200…。文章里描述的一切都在那里——YAML、Python、markdown。没有 demo，没有 mockup。

你的专家团上会有谁——你反复回来用的，是哪条原则？

跨模型方差分解——让 Claude-Carmack 和 GPT-Carmack 审同一段代码——是我下一步实验的核心。如果你在 LLM 互评可靠性方向踩过坑或有验证思路，评论区告诉我。

本文的核心局限——推理引擎未解耦——来自 DEV.to 读者 Max Quimby 的评论讨论。好反馈让文章变好。