让 AI 代码审查工具不能再瞎引证

最近读了 OpenClaw 团队开源的 Clawpatch 源码，写一点感想。

这是个自动化代码审查 CLI，定位很普通：扫仓库、找 bug、跑测试、给出修复方案。市面上类似工具一抓一大把。让我多看了两眼的不是它做了什么，是它怎么防止模型胡说。

行业里大家解决”AI 输出不可信”的常见做法，一般是堆模型——三个模型投票，重叠的发现才算数。我自己在团队里也实践过这条路，确实管用，但贵，而且只能压”大家都看错”的风险，对”模型编造引证”无能为力。Clawpatch 走了另一条思路：它假设模型一定会胡说，所以让工程脚手架去拦谎言。这条思路对我冲击很大，值得展开讲讲。

一个具体的场景

想象你让 AI 看一个 Go 项目，它返回一条发现：

auth.go:120-125 存在 SQL 注入漏洞，user_id 参数未经过滤直接拼接到查询里。

你心里发毛，打开文件一看——auth.go 总共只有 60 行，根本没有第 120 行。模型在编造证据。

这种情况在 LLM 代码审查里太常见了。模型为了让 finding “看起来专业”，会顺手给一个文件名加行号，反正它知道你大概率不会一条条查。

业界惯用对策是让模型自我克制：prompt 里加一句 “Don’t fabricate evidence, only report findings with verified line numbers”。这种约束写了和没写差别不大。模型该编还是编，你没法在它给出 finding 的瞬间证伪。

Clawpatch 的做法是反过来——根本不让模型有机会编造能蒙混过关的引证。

反向校验：让引证可以被反查

这是整个工程最值钱的一招，我先用最朴素的话讲清楚。

Clawpatch 在调用模型之前，会先组装一份 prompt。这份 prompt 里包含哪些文件、每个文件取了哪些行段、是否被截断，全部记录在一个叫 manifest 的清单里。这份清单的字段大致是这样：

files: [{
  path: "src/auth.ts",
  includedLineRanges: [{start: 1, end: 80}, {start: 200, end: 250}],
  truncated: true,
  ...
}]

模型返回 finding 之后，Clawpatch 不只是把 JSON 解析了就完事——它对每条 finding 的 evidence 做四关校验：

1. evidence 引用的文件路径必须在 manifest 的 files 列表里
2. 路径不准逃出仓库根（防止 ../../../etc/passwd 这种把戏）
3. evidence 给的行段必须落在该文件实际进入 prompt 的 includedLineRanges 里——不是文件存在就行，得是模型真的看到了那几行
4. evidence 引用的原文片段（quote）必须能在指定行段的文本里搜得到（允许空白字符压缩匹配）

任何一关失败，这一条 finding 直接丢进 droppedFindings，不连累同 feature 的其他 finding。整个 run 还会把丢弃记录写进日志，肉眼可审。

回到刚才的例子：模型如果给一条”auth.go:120 SQL 注入”，但 prompt 里 auth.go 只包含了 1-60 行，校验直接判它 line range 不在 includedLineRanges 里——drop。模型如果聪明一点，编了一段 quote：”query := \”select * from users where id =\” + userID”，但源文件里搜不到这句话——drop。

这套机制把”幻觉无成本”翻转成了”幻觉无出口”。

这一招为什么重要

我先想清楚再说。

第一，它把”AI 可不可信”从模型能力问题，变成了工程能力问题。你不需要换更贵的模型，不需要堆冗余，就能让一个普通模型的输出可信度有一个数量级跃迁。

第二，它把”模型的诚实义务”摊到了人和机器之间的协议里。模型不需要诚实——它只需要在 prompt 真实给过的范围内说话，超出范围说什么都会被拦截。这比”在 prompt 里恳求模型不要胡说”工程上靠谱多了。

第三，它产生的是机器可识别的不可信信号。dropped finding 会被记进 run record 配上失败原因（path-not-included / line-out-of-range / quote-mismatch）。运维可以观察哪个模型在哪种 prompt 形态下幻觉率高，迭代时有数据可看。多模型投票的方案给不了这个粒度的可观测性。

代价也不是没有：你必须严格控制 prompt 装配，每个进入 context 的文件、每个截断后的行段都要登记。这意味着你的 prompt 管线得是”白盒”——不能是简单的字符串拼接，得有一份能被代码读取的 manifest 跟着 prompt 一起出门。多花的工程量不算大，但思维方式得换。

配合的第二招：让 schema 作为契约文件

光有 evidence 校验还不够，因为模型有时候返回的根本就不是合法 JSON。要么裸字符串，要么被 markdown 围栏 ```json 包了一层，要么字段名拼错。

Clawpatch 调 Codex CLI 的方式很巧：它把期望的 JSON Schema 写到一个临时文件，通过 --output-schema schema.json 参数交给 Codex，让 Codex 自己在生成阶段就按 schema 约束输出。这比 prompt 里写”return strict JSON only”靠谱多了——前者是模型的解码层在做硬约束，后者只是 prompt 里的祈祷。

更细节的工程妥协：Clawpatch 用 Zod（TS 的 schema 库）写好类型定义，自动转 JSON Schema，但要先剥掉 OpenAI strict mode 不认识的几个关键字（$schema、exclusiveMaximum、multipleOf 等），再强制每个 object 加 additionalProperties: false 和 required: 全字段。这些都是用工程换可靠性的细节。

万一模型还是返回了非法 JSON，Clawpatch 有三级容错：先 JSON.parse，失败就抓 ```json ``` 围栏，再失败就用状态机扫第一对配平的花括号。再失败才报错——退出码 8，错误归类是 malformed-output，附 200 字符的输出预览方便排查。

整套下来，模型从输出到落库要过四层：CLI 层的 schema 约束 → 解析层的三级容错 → schema 验证 → evidence 反向校验。每一层都把不可信信号拦在外面。

不光是代码审查工具的事

这套思路最值钱的地方，是可以搬到任何”让 AI 给出结构化结果”的场景。我列三个直接能用的方向：

做 AI 客服时，如果模型说”根据知识库第 3 条解答”，可以在调用前给模型一份知识库片段清单（带 ID），让模型只能引用清单里出现过的 ID。返回时校验 ID 是否真在清单里。引错就丢。

做 RAG 应用时，模型经常会说”参考文档 doc_42 第二段”，但 doc_42 你压根没塞进 context。给每段检索结果分配一个临时 token，让模型只能用这些 token 引用——超出范围的引用直接拦截。

做内部审计 / 合规 agent 时，模型说”违反条款 5.3″，你得知道条款 5.3 的原文是不是真的进了它的 context。同理，prompt manifest + 反向校验。

共同的工程动作只有两个：让 prompt 装配过程产生可读取的清单、让结果校验拿这份清单做反查。剩下的就是模型敢不敢瞎引，敢的话就让它的 finding 进不了你的库。

一个观察

很多团队做 AI 工程时，潜意识里把模型当成”会出错的实习生”——会想办法多复核、让他自己改。Clawpatch 这套设计反过来——它把模型当成不可靠的 IO 通道，跟磁盘损坏、网络丢包一个等级。你不会因为磁盘可能损坏就买三块盘投票，你会做 checksum；你不会因为网络可能丢包就发三遍，你会做 CRC。

代码层面对待模型输出，应该和对待这两种不可靠 IO 一样——加校验位、加白名单、加范围检查，不和模型讲道理。

我看完源码当晚就把这个思路用到了自己手头的一个 agent 项目上。原来模型给文档摘要时会引用 page=237 这种根本不存在的页码，加了反向校验之后，编造的引证直接被丢——一周后回头看，团队对这个 agent 输出的信任度肉眼可见地提了一档。

如果你也在做依赖 AI 输出的工程产品，这一招值得加进你的工具箱。Clawpatch 源码是 MIT 开源的，相关实现集中在 src/review-validation.ts 和 src/prompt.ts，半天可以读完。