让 AI 扮演安全专家审代码、扮演产品经理审需求------这件事越来越多人做。但有一个隐蔽陷阱很少有人提：多名 AI 评审达成统一意见，不代表结论可靠。 当你让同一个模型同时扮演"安全专家""架构师""测试"，角色换了，底下的推理引擎没换。很容易形成「集体幻觉」------所有人一起犯同样的错，你分不清是真共识还是一个盲区在多个角色间的回声。网上大多数多角色 Prompt 方案，没有解决这个根本缺陷。
针对重度技术写作、实验校验、代码审查场景，我自研了一套双池专家评审架构 。下文完整介绍工作流、调度机制、自动化脚本，同时客观说明这套体系的维护成本和固有限制------不神化，不推销。⚠️ 本方案有持续知识库维护成本，不适合追求开箱即用的轻度使用者。
这套思路起源于今年 6 月参与 alirezarezvani/claude-skills 开源项目讨论时，提出的命名人物质疑性评审概念。PR 因结构缺陷未合并，但维护者认可核心 idea，自行开了 #867 硬化实现并署了我的名。这个经历让我意识到很多开发者在独立工作中遇到了同样的难题------于是有了这套完整工程。
TL;DR：用真实人物（Torvalds、Carmack、Norman）的文档化原则替代泛用 prompt 审 AI 输出，建路由表自动调度 33 人专家池，用 Python 脚本机械执法规则。核心局限------33 个角色跑在同一模型上，推理引擎没换，33 人一致同意可能是一个盲区的回声。不能消灭幻觉，但让你更难被单一模型的一致性输出欺骗。适合重度技术写作与实验场景，有持续维护成本。追求开箱即用的轻度使用者可能会失望。
架构全景
核心链路：触发 → 路由调度 → 双池匹配 → 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 文件：
yaml
routes:
- id: experiment-design
triggers: ["设计实验", "验证方法论"]
load_kb: [kb-experiments, kb-paper-claims]
design_review:
roles: [Carmack, Hickey, Schell]
focus: "method + complexity + clarity"
- id: writing-review
triggers: ["文章初稿", "发布前审查"]
load_kb: [kb-articles, kb-voice-reference]
voice_review:
roles: [Zinsser, Orwell, Graham]
- id: code-review
triggers: ["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 的评论讨论。好反馈让文章变好。