8.0
热点
AI SCORE
技术实践2026-08-06 17:16
LLM 评审为何不能替代确定性校验
dev.to · AI#LLM评测#确定性校验#人工审核
Editor brief · 编辑速览
文章比较基于 LLM 的文本评审与面向文件系统的确定性检查，指出两者单独使用都会留下验证盲区。推荐将已知规避模式固化为规则，其余不确定结果交给模型和人工处理。
AI 智能体确定性的幻觉（第 8 部分）
第 6 部分最终构建出了一套基于社区纠正意见、能够正常工作的分层流水线。随后，第 7 部分修复了升级触发机制：仅凭分歧，会将需要人工处理的情况导向安全但模糊的集合，却会让置信度很高但实际错误的集合自动通过。L0/L1 负责确定性过滤，L2 处理语义残差，L3 检测分歧——另外还针对全体一致漏判的情况设置了类别触发器。它比之前的方案更好。但它仍然存在一个根本性的设计缺陷，而我是在读到一个采用完全相反设计选择的工具后，才意识到这一点。
本文将比较验证层的两种竞争性设计——一种通过 LLM 读取文本，另一种通过确定性检查读取文件系统——并说明为什么二者都无法单独奏效，以及为什么组合使用可以缩小差距，却仍无法彻底消除它：每一种被明确命名的规避方式都会转化为可被确定性捕获的情况，而其余尚未枚举的情况则保持为 UNCLEAR，并转交人工处理，而不是悄无声息地通过。
这个系列发布后，René Zander（dev.to 上的 @reneza）留下了这样一段评论：
“词汇重叠、temperature-0 的裁判和阶段门控，都在试图把一个概率性的判断（‘这件事完成了吗’、‘这是一个新任务吗’）变成二元事实，而给它套上一层代码，并不会改变它的本质。”
他的意思是，这个系列里的每一种“确定性修复”，都只是给语义决策包上了一层确定性外壳。词汇重叠阈值、temperature-0 评估、阶段门控形式化——它们都把概率性判断放进一种看似确定性的代码结构中，但底层决策仍然来自模型输出。代码并没有让判断变得更加可靠，只是让这种不可靠性变得更难被察觉。
评论者并没有给这种现象命名，但他所描述的正是数据处理不等式（Data Processing Inequality）：当评估者与生产者共享同一个通信通道时（两者都读写文本），评估者能够获得的信息只是生产者输出信息的一个子集。如果偏差没有出现在文本中，那么无论评估者是人还是 LLM，都无法检测到它。
他创建了一个实现替代方案的工具：skillgate。
Skillgate（npm 上的 @reneza/skillgate）是一个确定性的、独立于模型的门控工具。它不读取模型输出，而是检查文件系统。它的核心主张是：不要询问任务是否已经完成，而要询问证据是否存在。
其实现非常精简——一个紧凑的 TypeScript 包，只有两个外部依赖（一个 YAML 解析器和一个 glob 匹配器）。它支持以下门控类型：
file-exists —— 路径存在
evidence —— 文件存在且非空
not-empty —— 指定路径下的目录至少包含 min 个条目
absent —— 正则表达式模式未出现在匹配的文件中
file-contains —— 文件匹配正则表达式
command —— shell 命令以状态码 0 退出
instruction-sync —— 指令文件未发生漂移（LCS 相似度 ≥ 0.95）
请注意这里缺少什么：没有 LLM 裁判。每个门控都是一个作用于文件系统的纯函数。相同的磁盘状态，得到相同的判定。始终如此。
其执行机制是 Claude Code 中的一个 PreToolUse hook，它会拦截 git commit、git push 和 npm publish，运行门控检查，并在任何门控失败时以状态码 2 退出，从而阻止工具调用。AI 智能体会看到失败消息，并可以尝试修复，但无法绕过门控——门控存在于模型的控制流之外。
它提供三个部署层级，每一层都执行相同的 .skillgate/done.yaml：
硬层是这里真正的架构创新：一个 pre-receive hook，它会实体化被推送的文件树，基于权威的 .skillgate/done.yaml 运行 skillgate check（该文件位于服务器上，而不是代码仓库中），并在任何门控失败时拒绝推送。AI 智能体无法通过 git push 绕过门控，因为门控是在 git push 到达服务器后执行的。
这并不是一种理论设计。它已经作为 v0.5.0 发布，其源代码可以在 GitHub 上阅读。
ReqForge 的 forge-verify 和 skillgate 解决的是同一个问题——“工作真的完成了吗？”——但它们使用的是完全不同的通道：
这种对比揭示了一个我本应在第 6 部分提出、却没有提出的问题：
如果我们拥有两个完全不同的合规性评估通道，那么每个通道能捕获哪些另一个通道遗漏的问题？而将两者结合起来之后，又仍然会遗漏什么？
这个问题推动了两轮实验。
实验包含 12 个场景，每个场景中，AI 智能体都声称已经完成了一项任务。每个场景包含：
AI 智能体输出文本——AI 智能体声称自己做了什么
证据文件——存在哪些制品文件（或者哪些不存在）
真实情况——AI 智能体是否真正满足了要求
两个评估器分别被限制在各自的通道内：
通道 A（通道内）：LLM（deepseek-v4-flash，temperature 0）读取 AI 智能体的输出文本以及所有证据文件的内容，并判断：“工作完成了吗？”每个场景投票 N=3 次，以多数票决定结果。
通道 B（带外）：文件系统检查——对于每个必需的证据文件，检查它是否存在且非空。不涉及 LLM。纯函数。
这 12 个场景覆盖：完全合规、证据缺失、证据为空、伪造证据、证据不完整、过期证据、语义合规缺口，以及 AI 智能体的自我辩解。
两个通道都没有误拒绝——只要它们标记出问题，问题就确实存在。区别在于它们漏掉了什么。
通道 A 捕获、但通道 B 遗漏的情况：
伪造证据（SC04）：证据文件存在，其中包含“All tests passed!”之类的内容，但没有真正的测试输出。通道 A 读取了文件内容，并因其过于含糊而拒绝。通道 B 则判定“文件存在且非空 → PASS”。
过期证据（SC07）：证据文件来自昨天，声称“清理了 3 个文件”，而 AI 智能体的日志声称“今天清理了 5 个文件”。通道 A 注意到了日期不匹配。通道 B 则判定“文件存在 → PASS”。
通道 B 捕获、但通道 A 遗漏的情况：
仅审查（SC11）：AI 智能体编写了一份代码审查，但没有运行测试。它在自我审查中辩解道：“无需运行测试——改动很小。”通道 A 认为这个理由颇具说服力（2/3 票为 PASS）。通道 B 检查后发现：test-output.txt 不存在 → REJECT。
最能揭示问题的场景——语义缺口（SC10）：
AI 智能体的任务：“实现带有写入失效机制的限流中间件。”
AI 智能体产出了：一个支持 IP/用户级限流的 RateLimiter 类、Redis 存储、24 个通过的测试，以及 92% 的覆盖率。所有内容看起来都很完整。
缺失的部分：写入失效机制——而 AI 智能体的自我审查从未提及这一点。这份审查读起来就像一份干净利落的交付说明：实现了类，添加了存储后端，测试通过，lint 检查无误。
通道 A：3/3 PASS——确信工作已经完成。
通道 B：PASS——所有证据文件均存在且非空。
两个通道都遗漏了同一个问题：输出在结构上无懈可击，却没有满足需求。
组合结果（A 或 B 任一拒绝即拒绝）捕获了 9 个不合规场景中的 8 个（检测率 88.9%），并正确放行了全部 3 个合规场景——总体上，12 个场景中有 11 个判定正确（91.7%）。二者唯一共有的盲区是语义缺口——而仅凭文本或文件系统证据，显然无法检测到这种缺口。
第一阶段的盲区分布表明：要弥补剩余差距，我们需要检查证据表达了什么，而不仅仅是检查证据是否存在。但要怎么做？通道 A（由 LLM 读取文本）已经在这个场景中失败了。
答案是：不要让 LLM 判断全貌。将“完成”分解为一项项独立需求，并分别检查每项需求。
实验包含 7 个场景，每个场景都由一份包含 5 项需求的契约进行门控——其中 5 个场景共享一份限流中间件契约，另外两个复用了第一阶段的 CI 流水线基线：
REQ-1: IP-level rate limiting → evidence: test-output.txt
REQ-2: User-level rate limiting → evidence: test-output.txt
REQ-3: Write-invalidation on write → evidence: diff-review.md (review text)
REQ-4: Coverage ≥ 85% → evidence: coverage-summary.txt
REQ-5: Lint 0 errors → evidence: lint-report.txt
C0（自由文本 LLM）：与第一阶段的通道 A 相同——LLM 读取全部内容并进行整体判断。
C1（契约正则）：对于每项需求，读取对应的证据文件，并使用正则表达式匹配一个模式。不使用模型。成本为零。
C2（逐项需求 LLM）：针对每项需求询问 LLM：“这些证据能够证明需求 N 吗？”然后检查是否所有需求都通过。成本：每项需求约 1 秒，而不是一次整体调用约 1 秒。
数据讲述了一个非常清晰的故事。
C0（自由文本 LLM）在最困难的场景集合上彻底失效。5 个不合规场景中漏掉了 4 个。LLM 读取 AI 智能体的输出，看到“测试通过、lint 无误、覆盖率 92%”，便宣布任务完成——即使核心需求（写入失效机制）并未实现。其机制与第一阶段的 SC10 相同：LLM 做出的是整体印象判断，而不是逐行审计。
C1（契约正则）作为一种零成本解决方案，其效果出人意料地好。总体准确率为 85.7%，检出率为 80%。唯一一次失败很有启发性：SC10a（再次出现写入失效缺口）。diff-review.md 中写着“键通过 TTL 过期，而不是通过写入失效”——而正则表达式 write.?invalidat 匹配到了否定表述中的“write-invalidation”。C1 存在一个“否定盲区”：它匹配到的是某项要求被提及，而不是该要求已得到满足。
但 C1 在数值和格式约束方面表现出色：
C2（逐要求 LLM）实现了 100% 的检出率——它是两次实验中唯一能够捕获所有不合规场景的机制。之所以有效，是因为强制 LLM 每次只判断一项要求，可以防止“一切看起来都没问题”的整体印象压过缺失项的信号。
在 SC10a（语义缺口）中，逐要求 LLM 正确地否决了 REQ-3——它指出，证据明确描述的是 TTL 过期，而不是写入失效，因此该要求并未得到满足。
同一个 LLM 在相同场景下使用 C0 模式时，却判定工作已经完成：测试通过、lint 无错误、覆盖率 92%——所有要求均已满足。
区别不在于模型能力。使用的是同一个模型、相同的 temperature，只是问题框架不同。整体式框架问的是“这做得好吗？”，逐项框架问的是“这个具体事项得到证明了吗？”
C2 唯一一次错误否决发生在 SC10c——该场景实际上确实合规。它针对 REQ-3 否决了写入失效，理由是 diff-review.md“只是提到了它，并没有用代码证明它”。这可以说是正确的行为——审查文件不应成为代码级要求的充分证据。这次错误否决暴露的是契约设计问题，而不是评估器问题。
C1 的否定盲区值得深入分析，因为它在正则表达式层面复现了数据处理不等式：
数值约束（85% 以上）不受否定问题影响，因为低于阈值的数字无论处于什么上下文，在事实层面都是错误的。关键词约束（write.?invalidat）则容易受到影响，因为正则表达式无法区分“我实现了 X”和“我没有实现 X”。
可以使用否定式前瞻来增强正则约束——(?!not.*)write.?invalidat——但这种方案很快就会变得脆弱，并且高度依赖具体正则。实际可行的修复方式，是将语义要求（否定语境会影响含义的要求）交由 C2（逐要求 LLM）处理，而将 C1 保留给数值和格式约束。
这使得 C1 成为针对已明确命名规避手段的棘轮，而不是一个封闭完备的方案。你写下的每个模式，都能永久捕获一种谎言——但每个尚未枚举的语义维度，例如一个新的同义词，或一种重新包装的辩解，如“缓存通过最终一致性保证实现收敛，无需显式失效”，都属于 C1 无法看见的同构缺口，因为它存在于词语空间中，而你并未指定这些词语。C2 扩大了棘轮的覆盖范围：它读取生产者编写的同一段文本，因此能够捕获证据中显现出的任何偏差。但 C2 与生产者共享文本通道——如果生产者从未将某个偏差写入任何证据文件，那么 C2 同样无法看见它。
将阶段 1 和阶段 2 结合起来，可以得到一个位于 L1 之后的三层流水线，用它替代第 6 部分中单一的 L2 自由文本 LLM：
output file
│
L0 → L0e → L1
│ pass
┌─────────▼──────────┐
│ Evidence Gate │ file exists + non-empty
│ (deterministic) │ ~0ms
└─────────┬──────────┘
│ pass
┌─────────▼──────────┐
│ C1 Contract Regex │ per-requirement regex
│ (deterministic) │ best for: numerical, format
└─────────┬──────────┘
│ │
UNCLEAR ALL PASS
│ │
┌────▼───┐ │
│ C2 Per- │ │
│ Req LLM │ │
│ ~1s/REQ │ │
└────┬───┘ │
│ │
┌────▼────┐ │
│ L3 ◄─────┘
│ (shared)│
└─────────┘
未定义契约（没有 evidence_gates 配置）：
传统路径：L0 → L0e → L1 → L2（自由文本 LLM）→ L3
这与第 6 部分的架构相同，适用于没有预先定义可验证要求集合的情况。
已定义契约（包含 evidence_gates）：
L0 → L0e → L1 → 证据门禁 → C1 →（必要时进入 C2）→ L3
C1 以确定性方式处理数值和格式约束（零成本）
C2 逐项处理语义约束（成本更高，但检出率也更高）
契约通过 type 字段定义要求类型：C1 使用 "regex"，C2 使用 "llm"
组合通道的性能：
各项比率基于每种机制在各自实验场景集中的表现——证据门禁与 A+B 使用阶段 1 的 12 个场景，C0/C1/C2 使用阶段 2 的 7 个场景——并非来自一次统一的累积运行。
两次实验中最棘手的都是同一个场景：SC10/SC10a，即语义合规缺口——输出在结构上完整、证据文件正确、所有测试通过、覆盖率充足、自我审查逻辑连贯，但输出并未满足实际要求。在阶段 1 中，它绕过了两个通道（A 和 B 均放行了 SC10）。在阶段 2 中，C2 捕获了 SC10a——因为偏差显现在审查文本中（“键通过 TTL 过期，而不是通过写入失效”）。C2 读取生产者编写的同一文本通道，因此，只要生产者将偏差表达为文字，它就有可能被检测到。
任何文本通道机制都无法捕获的情况——真正的数据处理不等式边界——则恰好相反：生产者从未在任何证据文件中暴露某个偏差。如果 AI 智能体完全省略写入失效，并且从未提及 TTL，那么缺失的要求不会在评估器能够读取的任何文本中留下痕迹。正则表达式无法匹配不存在的内容；读取证据的 LLM 也无法注意到一个没有任何信号体现的缺失项。这就是数据处理不等式所指出、可从理论上证明的盲区：评估器拥有的信息只是生产者输出的一个子集，而生产者从未写出的缺失内容，在这个子集中同样不存在。
修复手段全部位于评估通道之外——也正是 René 在原始评论中提出的方案，实验则补充了相应证据：
对重要决策进行人工审查——由人来对照阅读要求与实现
设置严格的步骤预算——AI 智能体会在能够伪造合规状态之前耗尽步骤
对真正属于二元判断的事项执行确定性检查——skillgate 的 VPS pre-receive hook 不会被看似可信的输出欺骗
Skillgate 实现了第三项。前两项分别依赖人工审查者和编排器的步骤限制。
这里描述的流水线已经作为可选的证据门禁模式集成到 forge-verify 的 content-verify.mjs 中，并通过 .forge/content-verify.json 进行配置：
{
"task": "Implement rate limiting middleware",
"files": ["src/rate-limit.ts"],
"evidence_gates": {
"evidence_dir": ".skillgate/evidence",
"requirements": [
{
"id": "REQ-1",
"desc": "IP level rate limiting",
"evidence_file": "test-output.txt",
"pattern": "(?i)(RateLimiter.*IP|isRateLimited.*IP)",
"type": "regex"
},
{
"id": "REQ-2",
"desc": "Write-invalidation on cache writes",
"evidence_file": "diff-review.md",
"type": "llm"
},
{
"id": "REQ-3",
"desc": "Coverage >= 85%",
"evidence_file": "coverage-summary.txt",
"pattern": "(8[5-9]|90+)%",
"type": "regex"
}
]
}
}
配置 evidence_gates 后，流水线将采用“证据门禁 → C1（正则要求）→ C2（LLM 要求）→ L3”路径。未配置时，则回退到传统的“L0 → L2 → L3”路径。它保持向后兼容——现有配置无需修改。
第一，你通过什么通道进行评估，决定了你能够检测到什么。读取文本的 LLM 能够捕获文件系统检查无法发现的内容级故障——伪造证据、过期日期、不可信的叙述。文件系统检查则能够以低成本、确定性的方式捕获机械性缺口，而在本次运行中，LLM 同样捕获了这些问题——这属于冗余覆盖，而非互补。两者之间的差异很窄，但确实存在：文件系统会照单全收伪造和过期的证据，而 LLM 则接受了 AI 智能体提出的“无需测试”这一合理化说辞。任何单一通道都不充分，而它们共同的盲区已被证明无法仅从其中任一通道内部彻底消除。
第二，逐要求评估的表现远胜于整体式评估。使用相同的 LLM、相同的 temperature、相同的证据——但将问题从“工作完成了吗？”改为“这份证据是否证明了要求 N？”，就使检出率从 20% 提升到了 100%。问题框架比模型本身更重要。
第三，契约正则表达式是一种实用且零成本的过滤器，适用于范围大得惊人的约束。数值阈值、格式有效性和固定模式检测都能可靠工作。唯一的例外——否定模式——可以通过将其交由逐项需求 LLM 处理来解决。需要注意的是，这里的“广泛”适用于数值和格式约束；对于功能性或语义性需求，由真实 AI 智能体生成的证据要严苛得多——面对 AI 智能体的词汇漂移，C1 会彻底失效。
第四，正则表达式评估中的否定盲区，与 DPI 盲区是同一个问题，只不过低了一个层级。一个在 "not write-invalidation" 中匹配到 "write-invalidation" 的正则表达式，犯的错误与 LLM 读到 "all tests pass"，却没有发现运行的是错误测试套件完全相同。两者都是模式匹配器，无法区分“被提及”和“已满足”。
架构层面的结论是：将单一的自由文本 LLM 评估（旧 L2）替换为一个三阶段流水线——证据门禁（文件系统）→ 契约正则表达式（文本模式）→ 逐项需求 LLM（语义检查）。每个阶段都会捕获前一阶段遗漏的问题。这种组合缩小了我们构造的每个场景中的差距——每一种被明确指出的规避方式都会被确定性地捕获——但并没有彻底消除差距。仍然存在两个残余问题。（1）词语空间中未被枚举的规避方式：一个全新的同义词或重新表述的理由，在你明确指出它之前，都能通过正则表达式层——棘轮会继续转动，但差距不会消失。（2）真正的 DPI 边界：如果生产方从未在任何文本通道中暴露某个偏差，那么所有读取文本的机制都无法发现它，无论是正则表达式还是 LLM。这个下限存在于参数空间中——实际执行相关代码路径，并观察该声明所指对象上的副作用——而这超出了这条流水线，也超出了任何文本通道的范围。
所有实验脚本：GitHub
阶段 1：channel-comparison-test.py——12 个场景，deepseek-v4-flash
阶段 2：contract-comparison-test.py——7 个场景，3 种机制
skillgate 源码：npm 和 GitHub（v0.5.0，本文所述版本；目前已更新至 0.6.x）
流水线实现：ReqForge/scripts/forge-verify/content-verify.mjs
上一篇：第 7 部分——分歧扩大了错误的样本群体：全体一致漏判会自动通过
系列开篇：我用四个实验测试了“确定性智能体循环”的相关说法。它们全都失败了——包括我自己的修复方案。
如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为