这两天 AI 圈又在吵幻觉的事模型查个数结论写得自信满满数字却是错的。老板们最怕的不是 AI 答不上来而是它一本正经地胡说八道——查数这活儿错一个数比不答贵十倍。我没跟着调 prompt也没跟着换更大的模型。我干了另一件事——去翻了一个开源数据智能体工作台daw「寒鸦数据工作台」的代码看它是怎么解决「AI 自信胡说」这个问题的。它的解法跟 prompt 半毛钱关系没有结论发出之前先过一道机械闸门。看完我可以负责任地告诉你三件事。第一这道闸门不信任模型的「自我检查」——让 AI 自己检查一遍自己的结论约等于让考生自己改卷子。第二闸门是三件套业务常识写成守卫声明、数字对账全机械执行、红灯触发自纠重取数每一环都不靠模型「自觉」。第三最狠的是兜底规则自纠最多两轮修不好不许静默放行必须在结论里如实告诉用户「这几项我没对上请人工复核」。1. 先看病为什么「你再检查一遍」没用先给大家科普一个概念「自我声明不可信」大模型在生成结论时说「我核对过了」和它真的核对过是两回事。前者是语言习惯后者是计算过程。让模型「再检查一遍」它大概率只是换个说法把同样的错数再讲一遍顺便补一句「经核实无误」。翻译成人话检查结论这件事不能交给生产结论的同一个脑子。daw 的作者在复盘里把这句话钉成了纪律「基础设施有 bug」与「层级错配」是最高成本的结论错误定案必须机械对账——不信任回答者的自我声明。注意这个措辞「不信任回答者的自我声明」。不是不信任模型的能力是不信任它的「嘴」。所以 daw 在 runner 层真正跑任务的那层 Rust 代码里加了一个循环每次 agent 要交付结论前先把结论文本丢进delivery_check模块做机械对账。干净才放行不干净打回去重做。这道闸门跑在模型之外用的是正则、值域比对、容差计算——全是确定性代码一行 LLM-as-judge 都没有。2. 闸门第一件把业务常识写成「守卫声明」闸门要检查什么daw 的做法很有意思它不硬编码规则而是让业务知识以 markdown 声明的形式存在知识库里每张业务表的文档下有两个小节——「# 值域守卫」和「# 关系守卫」。值域守卫管的是「实体有没有说错层级」。比如声明里写禁止武汉咨询部、大连咨询部这些是订单表部门级名不在台账战区值域允许 dept_lv2保研销售区、郑州三区、……翻译成人话同一家公司订单表里的「武汉咨询部」和台账里的「战区」根本不是一个层级的东西。AI 查数时最容易犯的错就是把部门级的名字安到战区级的位置上张冠李戴数字全错。守卫声明就是一张「什么名字属于哪个层级」的对照表结论里出现组织形状的实体正则ORG_SUFFIX_RE专门抓「XX咨询部」「XX战区」「XX军团」这类后缀就去值域里对命中禁止清单→红灯在组织形状但不在任何允许域→warn未知归属低置信提醒。关系守卫管的是「两个大数之间对不对得上」。声明两个大数的不变式比如放款总额/放款 ≈ 分期 GMV同秒重复放款去重后两数闭合容差 2%并且「同秒、重复、去重」这类解释词必须披露。结论同时提到两边、差额超容差、全文还没解释→红灯只报 GMV 不提放款这边的张力→warn。有意思的是守卫声明支持「核对 SQL」声明里可以钉一条 SQL返回一行两列左、右真值。红灯亮起时闸门直接连数据库把真值查出来喂给自纠指令——自纠的数字必须对得上机械真值。3. 闸门第二件机械对账脏活决定误报率对账逻辑本身不复杂复杂的是那些「脏活」——daw 在这上面栽过的跟头全变成了代码里的防御第一注释感知解析。守卫声明是 markdown知识库里可能合法存在被注释掉的旧声明或格式模板。解析器如果不感知 HTML 注释会把模板里的示例值当成真声明执行——等于拿着样题当考题判卷。现在解析器逐行扫描!--跨行注释一律跳过。第二零使用语境降级。结论里提到「武汉咨询部没用这个口径」实体命中了禁止清单但语境是「没用」「未收」「零」这类零使用标记。daw 维护了 9 个零标记词没用/未使用/未收/没有收/零定金/0 笔/0笔/未开/从未实体近旁有这些词就降级为合法提及不亮红灯。翻译成人话说「没用它」不算用错它。第三金额归一化与单位跳过。锚点附近的金额要归一到「万」再比「3.2 亿」和「32000 万」是同一个数锚点后第一个数字如果紧跟「单/笔/个/天/月/%」这类字符是计数或占比不是金额直接跳过。不做这层归一化对账就是个误报制造机。第四核对 SQL 先手工验证再钉入。声明纪律写得明明白白核对 SQL 必须先手工直查验证过再写进知识错了会误导自纠——闸门信它它错了全盘错。你看闸门的「智能」程度约等于零正则、字符串匹配、容差计算。但正是这种「笨」让它成了整个系统里最可信的一环。4. 闸门第三件红灯→自纠→复检修不好就认怂对账只是发现问题发现之后怎么办daw 的 runner 里是一个外层闸门循环1 次原始交付 最多 2 轮机械对账自纠MAX_GATE_CORRECTIONS 2每轮自纠的产出都要再过一遍闸门。流程是这样的结论文本进闸门→有红灯→UI 上弹出「⚠️ 交付前机械对账第 N 轮结论中的 XX 未通过对账正在自纠重取数……」→如果是关系守卫红灯且声明了核对 SQL先直查数据库拿真值做「机械接地」把真值喂进修正指令→模型重做→新结论再过闸门。这里有个关键设计自纠必须接地不许「请核实」式自纠。这是 daw 批次五的血泪教训——有一次自纠时模型没有真凭实据编了个「台账 287 笔」出来交差。从那以后纪律就是自纠的数字必须对得上直查真值拿不到真值宁可不纠。两轮自纠耗尽还有红灯怎么办daw 的选择是如实披露绝不静默放行。结论照常发出但在末尾追加「⚠️ 交付闸门残留红灯自纠 2 轮后仍有 N 项未消除实体名。已如实保留当前结论请人工复核。」代码注释里写得斩钉截铁「机制拦不完的必须明说绝不装作干净交付」。这个设计我认为是全篇最值得抄的承认机制有边界但把边界摆到台面上。用户看到的要么是干净结论要么是「结论没对上的清单」永远不会是「看起来干净其实有坑」的结论。5. 实测闸门拦下了什么光讲设计不讲实测就是耍流氓。daw 的记录里有三组硬数字deepseek 实战两轮闸门「均机械拦截」接地修正后才全绿 PASSverify v2 实测里deepseek 的「层级陷阱」错误全部 6 个错配实体被闸门机械拦截一个没漏另一轮是「5 红灯→自纠归零」——5 个红灯触发自纠环归零后交付。这些数字说明一件事闸门的价值不在「让模型变聪明」而在「让错误变可见、可修正、可披露」。上限确实在 harness工程脚手架不在底座模型——这句话是 daw 作者在评测里反复验证过的结论。给开发者的建议把「不能错」的业务规则从 prompt 搬到代码闸门。prompt 是建议代码是法律。凡是错一次就伤筋动骨的检查金额对账、层级归属、口径一致都值得一道确定性闸门。守卫声明用人话写存知识库。markdown 小节声明业务不变式业务人员能看懂、能改解析器负责把它变成机器可执行的检查。知识和代码解耦规则才能跟着业务长。自纠必须接地。红灯触发的修正指令里必须带上直查到的真值。没有真值的自纠就是让模型「再编一遍」越纠越错。设自纠轮次上限残留必须披露。无限自纠无限烧钱还可能震荡两轮修不好就认怂把「没对上的清单」交给用户。承认边界比假装干净可贵得多。脏活决定误报率。注释感知、零使用语境降级、金额归一化、单位跳过——这些不性感的细节才是闸门能不能长期开着而不被业务方骂关掉的关键。误报太多的闸门第一个死的就是它自己。说到底daw 的交付闸门回答了一个所有做 AI 应用的人都要回答的问题当模型一定会犯错时你拿什么兜底它的答案是不指望它不犯错指望犯错时被拦下、被修正、被说出来。机械、笨拙、但诚实——这可能是现阶段 AI 工程里最靠谱的诚实。