为什么 AI 的自检总在糊弄你

写在前面

我在看 GitHub 上的 AI Skill 的时候，发现了一个叫 Luopan（罗盘） 的项目，觉得很有意思。

这个项目是一个行业研究引擎——你输入一个行业名，AI 就给你输出一份结构化的产业地图。底层方法论借鉴麦肯锡的行业研究框架，落地成了 8 个 Phase：信源分级（A/B/C/D 四级）+ 多源视角矩阵 + 对抗验证 + 诚实原则。作者是大厂转型人，有腾讯和字节的背景，思路确实比较专业。

但在使用过程中，我发现了一个问题——对抗验证环节，很多时候都是糊弄过去。

我让 AI 写一份行业报告，写完让它在最后过一遍，检查有没有漏的、错的东西。理论上应该没问题，结果每次都是 AI 跑两秒钟，说"检查完毕，没发现问题"，然后直接过了。

问题不在设计上。设计没问题，环节也完整。问题在于：那个写报告的人和检查报告的人，其实是同一个 LLM ，在同一个上下文里。这就像让写作文的人自己判卷——他不可能严格。

这事我后来琢磨了一下，发现不只是 Luopan 有这个问题。很多带"自检"环节的 AI 应用/SKILL，最后都是这样糊弄过去。

为什么自检会失效

这个不是 bug，是 LLM 推理机制的固有特征。

生成一段文本的时候，LLM 会建立一种"自我信念"——它觉得自己在说什么，觉得已经说对了。再回头检查，它不是真的在检查，而是在确认自己刚才的判断。它只会强化，不会推翻。

你可以想一下：如果你自己写了一篇东西，然后立刻自己读一遍，你能找出多少真正的问题？可能一两个。但如果你等两天再读，或者换人读，发现的东西会多很多。

LLM 的问题比这个更严重——它连"等两天"都做不了。生成和检查是同一个上下文、同一个推理状态，根本没有"换视角"这回事。

行业里为什么还在用

因为自检环节看起来很好。

主流的 Agent 框架里（例如 Codex），都内置了某种形式的自检。它让设计者感觉"我已经想到了，流程是完整的"。而且确实有一部分场景是有效的（这很依赖模型）——比如当验证规则和生成规则不完全一致的时候。

但大多数 Skill 设计者可能没意识到，结构上的完整不等于效果上的有效。你在 SKILL.md 里写了一行"最后检查一下"，AI 会执行这一行，但它执行的方式和你期望的不一样。

怎么解决这个问题

我让Gemini 查询得出目前业界有六种主流方案，按成熟度从低到高排列：

下面是对每种方案的简要说明：

方案一：独立验证 Agent（Self-Critique / CRITIC 框架）

目前最主流的做法。生成和验证由两个独立过程完成：

生成 Agent（写报告）↓验证 Agent（读报告，独立打分，输出问题列表）↓生成 Agent（根据问题修改）↓验证 Agent（再次打分）↓循环 2-3 次直到达标

CRITIC 框架（2024 论文）的实证结论：3-4 轮循环能将输出质量提升 30-50% 。关键不是"检查"，而是循环修改。

方案二：反向种子注入（Adversarial Seeding）

在报告生成前故意植入一个已知错误，让 AI 在自检阶段找出来。如果它找不出来，说明自检流程本身在糊弄。

Phase 0 注入规则：- 在热身搜索阶段故意引用一个过时数据或虚构数字- 要求 AI 在 Phase 8 自检时发现并纠正- 如果没发现 → 重新执行自检，直到发现为止

这既是测试也是训练，强迫 AI 进入真正的"挑刺"模式。

方案三：检查项结构化 + 必须输出修改

把"挑刺者视角再过一遍"这种抽象要求，改成结构化问题清单，且每条问题必须对应一个修改动作：

□ 问题：[具体描述]→ 修改：[具体改了什么]→ 位置：[改在哪个模块哪一段]

没有"修改"字段的自检条目直接视为无效。

方案四：门控机制（Gating）

Luopan 在 Phase 0.5 和 Phase 1 已有门控检查（覆盖≥4视角、≥5个有效结果），但验证阶段没有。可以加：

Phase 7 对抗验证 → 必须输出至少 N 条具体问题如果问题数 < N → 自动触发重新对抗验证如果连续 M 轮都找不出问题 → 触发反向种子测试

方案五：双上下文隔离

用 Hermes 的 delegate_task 实现真正的独立验证——生成和审核是两个完全独立的 Agent，没有共享上下文：

主 Agent（生成报告）↓ 输出保存为文件审查 Agent（读文件，纯审稿角色，不知道生成过程）↓ 输出问题清单主 Agent（根据清单修改）

方案六：量化评分 + 阈值

给每条检查项打分，低于阈值必须重试：

□ 每条核心判断有数据支撑：0/3/1（0=无，1=有）□ 每条判断有来源链接：0/1□ 每条判断有"所以呢"：0/1□ 公司分类有理由：0/1...总分 ≥ 阈值 才进入下一步

什么才是有效的自检

我总结一下，有效的自检需要满足几个条件：

第一，检查的人要独立。 生成和审核不能是同一个上下文。

第二，输出要结构化。 不能只说"没发现问题"，必须列出具体找到的问题。

第三，必须有修改动作。 检查项后面要跟上修改记录，没有修改的检查就是没执行。

第四，要有门控。 不达标必须重试，不能走过场。

第五，要可追溯。 每一步都留痕，出了问题能复盘。

结尾

自检不是写在 SKILL.md 里就会生效的东西。它需要独立的评判者、量化的标准、强制的门控。

最容易被糊弄的环节，往往是写在那里的环节。