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

许多人在用AI扮演多重角色来审代码和评估需求，但一个隐蔽的陷阱是集体幻觉。由于推理引擎未变，所谓的多角色共识并非真正独立的判断。为此，我自研了一套双池专家评审架构，旨在解决这一根本缺陷，下文将完整介绍其工作流与机制。

这套方案专为重度技术写作、实验校验及代码审查场景设计，包含详细的工作流、调度机制与自动化脚本。同时，我也将客观说明其维护成本与固有限制，不神化，不推销。需要提醒的是，本方案涉及持续的知识库维护，不适合追求开箱即用的轻度使用者。

该思路源于今年6月参与alirezarezvani/claude-skills开源项目讨论时，我提出的命名人物质疑性评审概念。尽管PR因结构缺陷未能合并，但维护者认可了核心想法，并自行硬化实现。这一经历让我意识到许多独立开发者都面临同样的难题，于是便有了这套完整的工程化方案。

架构全景

核心链路为：触发 → 路由调度 → 双池匹配 → LLM推理 → 多角色输出 → 机械门校验 → 人工判断。需要特别注意的是，所有角色共享同一推理引擎，33人同意并不等同于33个独立判断。

命名专家 > 抽象角色

不要仅仅让AI扮演“安全专家”，而是赋予它一个真实的人名，一个具有文档记录、可搜索、可溯源原则的人。

例如，Ken Thompson并非泛泛的“安全专家”。他1984年的图灵奖演讲《Reflections on Trusting Trust》提供了一个实际的分析透镜，让你能聚焦于供应链风险、第三方代码的信任边界，而非一种模糊的感觉。这是一个你可以亲自阅读并验证的文档化框架。

Don Norman也不是抽象的“UX审查者”。《设计心理学》中的可供性、示能、概念模型，都是可搜索、可验证的具体原则。

再举一个真实的例子：Torvalds在TED 2016中演示了“好品味”——遍历链表删除节点的函数，一般人会用大量if判断边界条件，而他消除了特殊情况，使代码行数减半。这条原则落在我代码里，就变成了：看到if-else链先问“能不能让这些情况不存在”，而不是“能不能写好这些if”。

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

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

1. high — 我能为你提供来源，如Torvalds的TED演讲、Thompson的图灵演讲及具体页码。
2. moderate — 与文档化工作一致，但找不到精确引文。
3. low — 属于我的推断，会明确标注，当作建议处理而非分析。

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

我的固定池有33人，覆盖6大领域，每个人物都附带可引用的来源及置信度：

1. Torvalds“好品味”（消除特殊情况）→ 2016 TED，confidence: high
2. Thompson信任边界 → 1984图灵奖演讲，confidence: high
3. Carmack“先测量再优化” → .plan文件 + QuakeCon，confidence: high
4. 余光中“中文的生命在动词” → 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都进行一轮搜索，找到陌生名字，将他们的透镜应用到我的工作上，以打破回音室。有一次，随机池抓到的设计缺陷，两轮固定池都没发现。

随机池还有一个作用：部分缓解了“推理未解耦”的问题。它引入的视角来自模型训练数据之外，即我搜到的真实人物的真实原则，输入的多样性更高了一点。

路由表：别手动选人

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问“第一次看这个设计，第几步会困惑”。他们的意见我认可大部分，也驳回了一些，但每次都知道他们为什么这么说。这些场景正好是路由表的工作，不同的触发条件匹配不同的专家组合。

会出什么问题

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

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

幻觉依然存在。命名原则显著减少伪造，但不能消灭。置信度的存在有原因，low只是建议，需要标注它或者删掉它。维护是真的，知识库会过期，工作方向会变，机械门抓过期但不修内容，那还是你的事。你会选错人，有人在纸面上听起来对，实际给出浅层反馈，换掉即可。池子是活的，每月重访一次。

说实话

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

我还没有跑过直接对比命名专家审查和泛用prompt的对照实验。同一个模型生成的审查，让同一个模型打分，这不叫验证，叫回声。要做合格的对照实验，需要更多的精力和更严谨的设计。同样，跨模型方差分解，验证33个专家的独立性到底是真的还是戏服，也是下一步实验的核心。

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

你可能不需要Carmack，你需要你信任的产品经理、你敬重的设计师、你反复读的那个作家的写作原则。路由表、机械门、双池编排、反伪造纪律，框架是通用的，专家是谁，由你定。

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

这套双池专家评审框架，旨在让你更难被AI的一致性输出欺骗。专家人选由你定，但需牢记：多角色共识不等于独立判断。它虽有维护成本，但提供了一个可验证、可溯源的工程化评审路径。