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

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

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

命名专家 ＞ 抽象角色

痛点：把 AI 当成抽象“安全专家”会导致答案缺乏可追溯来源，容易被模型幻觉误导。

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

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

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

实际案例：Torvalds 在 TED 演讲里演示“好品味”——遍历链表删除节点的函数，一般人会写一堆 If 判断边界条件。他消除特殊情况，零个 If,代码行数减半。这不是“风格好”，而是消除特殊情况，而不是处理特殊情况。

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

这就是反伪造纪律。

• high — 我能给你看来源，置信度高。
• moderate — 与他们文档化的工作一致，但找不到精确引文。
• low — 我的推断，明确标注。当作建议处理，不是分析，

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

我的固定池：

• Torvalds “好品味”→ TED，confidence: high.
• Kenneth Thompson 信任边界 → 图灵奖演讲，confidence: high.
• Carmack “先测量再调整” → .plan 文件 + QuakeCon。 confidence: high.
• 余光中 “中文的生命在动词” → 明报月刊，confidence: high.

前提解耦了推理没有

Pain point：即使前提使用真实人物，也无法改变底层模型统一推理的问题。

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

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

SOP：

• Select principle that anchors reality.
• If principle is applied correctly → ✅；否则 → ❌，
• "人一致同意" ≠ "独立判断"，可能是盲区在镜子里反射。

Pain point：A consensus among multiple roles is more dangerous than a single reviewer because shared blind spot gets amplified.

如何检测盲区？

L​跨模型方差分解：让 Claude‑Carmack 与 GPT‑Carmack 同时审同一段。如果两者结果不同，则差异来源于模型而非专家；如果一致，则说明专家池具备一定独立性。其实，这一步仍在实验阶段，是后续主要。不过，

提前声明

This framework cannot eliminate hallucinations nor replace independent human judgment. It merely makes it harder to be fooled by a single model’s consistent output—while introducing a new class of blind‑spot risk. Use it consciously.

架构全景

The core pipeline:

1. 触发 → 路由调度 → 双池匹配 → LLM 推理 → 多角色输出 → 机械门校验 → 人判断.
2. The yellow‑highlighted nodes mark repeated blind spot: all roles share same inference engine;human agreement does not guarantee independent judgments.

再看双池，固定池保下限。随机池拉上限

固定池

• A curated list of vetted experts with documented principles and confidence levels.
• The same expert can review multiple times;patterns emerge .

随机池

• The system queries web for “ engineering philosophy”,extracts unfamiliar names,and adds ir lenses to current session.
• This breaks echo‑chambers. In one case,a random expert flagged a design defect that both fixed‑pool reviewers missed.
• The random pool also mitigates,albeit partially,“un‑decoupled inference” issue by injecting perspectives outside pre‑seeded knowledge base.

再看路由表，别手动选人

Pain point：You waste time manually assigning reviewers for each task。leading to inconsistent coverage and bottlenecks.

routes:
- id: experiment-design
triggers:
load_kb:
design_review:
roles这方面，focus: "method + complexity + clarity"
- id: writing-review
triggers:
load_kb:
voice_review:
从roles来看，- id: code-review
triggers:
code_review:
roles这方面，focus: "trust boundaries + taste + testability"

The routing table automatically fires when a trigger matches,loads appropriate knowledge bases,and dispatches right experts—zero cognitive overhead.

机械门的观点是，别让 AI 记住规则

Pain point：The routing table can become stale;knowledge bases decay over weeks without notice,causing outdated feedback to slip through.

• A Python script ) runs after each session.
  • If any KB file is older than its source script → hard fail.
  • If a routing rule hasn’t been used for>30 days → flag red.
  • If session ends without dashboard update → block deployment.

This “mechanical gate” ensures that rules are enforced by code rar than by memory of an LLM. The AI follows whatever rule you give it at runtime;never let it self‑maintain its own rule set.

真实场景怎么用

技术讨论区回复

Pain point：You often feel insecure when replying to recurring critics—uncertain tone,missed hidden concerns。or superficial answers that don’t address deep objections.

• The system first loads a persona profile of critic .
• Your draft reply passes through a “voice gate”: Carnegie checks relationship tone;Voss checks for misinterpretation of intent;老实说，Rosenberg checks for judgmental language.
• You still write reply yourself;expert board only validates tone and completeness before you hit send.

实验设计

• Carmack asks “What hyposis?Have you measured?”，老实说，
• Kenny Hickey probes “Is this complexity intrinsic or accidental?”，老实说，Schell asks “At which step would a first‑time reader get confused?”，不过，

  Each feedback item carries its source + confidence level – no black box.

  会出什么问题

  liPitfall #1: 多角色共识 ≠ 多独立判断 – 同一基座模型产生回声。使得高置信度输出更危险，liPitfall #2: 外包判断 – 专家团只提供视角，你仍需自行决定其对业务的关键性。liPitfall #3: 幻觉依然存在 – 命名降低伪造概率，但低置信度条目仍只能视作建议或删除。liPitfall #4: 持续维护成本 – 知识库过期、业务方向变化，需要机械门抓取并手动更新。说起来，liPitfall #5: 错选人物 – 某些看似权威的人只能给出浅层反馈；每月复盘并刷新池子，怎么说呢，

  The system’s greatest value isn’t giving you answers—it makes you harder to deceive。including by its own outputs.

  实际来说

  这篇文章主要局限 — 推理引擎未解耦 —— 来自 DEV.to 读者 Max Quimby 的评论讨论。好反馈让文章变好，

  🔬 hermes-workspace — 路由表 + 专家池 + 机械门，完整工程公开📂 paper-validator — 层 governance 架构。含 L4 漂移预测器👋 GitHub · DEV.to

。

---