AI 指控“显示层插鬼影行“时，先过两步定案：payload 对账与直查数据库的防误诊做法

原创于 2026-10-23 09:15:08 发布 · 214 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文提出AI Agent在指控‘显示层插鬼影行’时的防误诊机制：第一步payload对账（校验summary/meta.rows/rows三处行数一致性），第二步直查数据库逐字复核。强调‘基础设施有bug’为最高成本结论，须经机械验证与独立复核；同时明确证据同源规则、读串识别信号（行号超范围）及避坑清单，保障推理链路可信。

AI 指控"显示层插鬼影行"时，先过两步定案：payload 对账与直查数据库的防误诊做法

学习目标：学完这篇，你会给 AI Agent 加一条"基础设施有罪推定"的熔断纪律——当模型说"框架/渲染/驱动层有 bug"时，必须先过两步定案（payload 对账 → 直查数据库复核）才能下结论，外加三条证据规则和"读串"的识别信号。这套清单可以直接抄进你自己的 agent 交付纪律里。

0. 先说问题

先说一个真实的 P0 事故，发生在我的数据智能体工作台 daw 的复盘第十一轮（2026-09-01）。

那天模型在查数时，把上下文里相邻的两条 GROUP BY 结果读串了：一份是 dept_lv3 的 50 行，一份是 dept_lv2 的 22 行，模型把 lv3 结果里的行当成了 lv2 的行。它的验证探查又全打在了 dept_lv2 上——0 行，恰恰证明 dept_lv2 是干净的，却被它当成了"显示渲染层往结果里插了鬼影行"的证据。

接下来发生的事是事故升级：它把"显示层有鬼影"写进了知识库，并且据此撤回了一个真实的业务发现——"未匹配到部门"那批单子，其实是无销售跟进的自然转化单，全月 33 笔、100% 转化、52.09 万。一个本来能讲给老板听的洞察，就这么被一个子虚乌有的"基础设施 bug"给埋了。

复盘时我直查 Hologres 逐字核实：payload 与数据库直查完全一致。查询链路、渲染链路，从来就没有鬼影。最后勘误了两处被污染的知识，把真实发现恢复了回来。

这件事让我立了一条纪律，至今钉在项目的 AGENTS.md 里："基础设施有 bug"是成本最高的结论，定案前必须两步全过。这篇教程就把这两步、三条证据规则，以及"读串"的识别信号，完整拆给你。

1. 事故还原：三步走偏，一步比一步贵

先把事故的链条摆出来，看看一个错误的结论是怎么一步步"坐实"的：

第一步：读串。 上下文里两条 GROUP BY 结果紧挨着：dept_lv3 50 行，dept_lv2 22 行。模型在推理里引用"行 #19""行 #36"去论证 lv2 的分组——lv2 只有 22 行，行号超出范围的地方，就是它把 lv3 的行读成了 lv2 的行。

翻译成人话：引用的行号超过了结果的总行数，这就是读串的指纹。 就像你说"第 36 页写了……"，但那本书一共只有 22 页——后面的论证不用看了，源头就错了。

第二步：验证探查打错了地方。 模型想验证"鬼影"，探查 SQL 全打在 dept_lv2 上，返回 0 行。它把 0 行解读成"果然有问题"——但 0 行恰恰证明 dept_lv2 干干净净，没有它声称的那些行。这就好比你怀疑 A 抽屉里多了不属于你的东西，去翻了 B 抽屉发现是空的，然后宣布"看，A 抽屉果然有问题"。

第三步：写进知识库，撤回真发现。 有了"证据"，它把"显示层插鬼影行"写进知识库，还顺手撤回了"未匹配到部门"那批自然转化单的业务发现。污染知识库 + 埋掉真洞察，双重损失。

有人可能会问：模型犯错不是很正常吗，为什么定成 P0？因为"基础设施有 bug"这个结论一旦坐实，后续所有的排查方向、所有的知识沉淀都会被带偏。它是所有结论里纠错成本最高的那个，所以它的定案门槛也必须最高。这就是"两步定案"存在的理由。

2. 定案第一步：payload 对账，机械的不依赖模型判断

"基础设施有 bug"是最贵的结论，所以第一步必须是最便宜、最机械、不依赖模型"感觉"的检查：payload 对账。

daw 每次查询返回的 payload 里有三处关于行数的声明：

位置	是什么
summary 声明	摘要里说的"返回了 N 行"
meta.rows	元数据里记录的行数
rows 实际数组	真正拿到的数据行，数一数

定案规则很简单：三处必须一致。summary 说 22 行，meta.rows 是 22，rows 数组数出来也是 22——那就没有鬼影，有鬼影的话这三处一定对不上。渲染层如果真往结果里"插行"，插的是 rows 数组里的数据，meta.rows 和 summary 不可能同步造假还恰好一致。

这一步为什么重要？因为它把"有没有鬼影"从一个需要模型推理判断的问题，变成了一个数数的机械问题。机械检查的好处是：它不依赖模型的注意力，不会被读串污染。模型可以读串上下文，但它数不清三处声明吗？能——只要你让它先数数，再下结论。

那次事故里，payload 与 DB 直查完全一致——这一步如果当时做了，事故在第一步就结束了。

3. 定案第二步：直查数据库，逐字复核

第一步过了，还不能定案——payload 本身也可能是被污染的（比如查询就写错了）。第二步：绕开整个 agent 链路，直查数据库，逐字复核。

那次复盘我就是这么干的：直接连 Hologres，把有争议的那几组数字逐字对了一遍。结果：payload 里是什么，库里就是什么，一字不差。查询链路没撒谎，渲染链路没插行。

这两步的关系是：第一步排除"链路中间被动手脚"，第二步排除"源头就是错的"。两步全过，"基础设施有 bug"这个结论才能成立；任何一步没过，结论作废，回去找自己的问题。

顺序也不能反：先直查数据库再对 payload，等于默认"链路可疑"；而绝大多数时候，可疑的是模型自己的解读。先做便宜的机械检查，再做贵的直查——这是成本排序。

4. 证据规则：验证探查必须同源，跨列的 0 行不是证据

除了两步定案，还有一条证据规则是那次事故里血的教训：验证探查必须与产生可疑分组的同一列、同一查询同源。

模型怀疑的是"lv2 分组里多了行"，它的验证探查却打在 dept_lv2 整个列上查 0 行。这有两个问题：

第一，探查对象错位。可疑的是"某次特定查询的 lv2 分组结果"，探查却变成了"dept_lv2 列里有没有数据"。这是两个不同的问题，第二个问题的答案（0 行）回答不了第一个问题。

第二，0 行被反向解读。0 行恰恰证明 lv2 干净，却被当成了"有鬼"的证据。这是一个逻辑谬误：用"没查到"来证明"有问题"。正确的解读是：0 行 = 这条探查路径上没有异常，怀疑不成立，换条路。

翻译成人话：你要证明 A 抽屉里有不属于你的东西，就去翻 A 抽屉；翻 B 抽屉发现是空的，证明的是 B 抽屉没问题，不是 A 抽屉有问题。跨列、跨查询的 0 行，永远不是"有鬼"的证据。

5. 读串的识别信号：行号超出范围

读串是这次事故的源头，也是最值得单独拎出来的一个信号，因为它有一个极其好认的指纹：模型引用的行号，超出了结果集的总行数。

lv2 结果一共 22 行，模型推理里写"行 #19 的值是……行 #36 的值是……"——#36 已经超过 22 了。这说明它引用的根本不是这份结果里的行，而是隔壁那份 50 行结果里的。上下文里多份查询结果相邻摆放时，这种串行是高频事故。

给你的检查清单上加这一条，执行起来非常机械：模型在推理里引用"第 N 行"时，先问一句——N 有没有超过这份结果的总行数？超过了，后面的论证直接作废，不用再往下看了。

6. 为什么这样设计

第一，结论的定价决定检查的成本。 "基础设施有 bug"一旦坐实，会污染知识库、带偏后续所有排查、还可能埋掉真实发现——它是所有结论里纠错成本最高的。所以它的定案门槛也必须最高：两步全过，缺一不可。便宜的结论可以靠模型直觉，贵的结论必须靠机械检查 + 独立复核。

第二，机械检查优先于模型判断。 payload 对账（数三处行数）不需要理解业务，不需要推理，只需要数数。把最关键的证伪步骤做成"模型再糊涂也做不错"的样子，这是给 AI 立纪律的核心手法——不要考验模型的注意力，要绕过它。

第三，证据必须同源。 跨列、跨查询的验证探查，回答的是另一个问题。把"验证探查必须与产生可疑分组的同一列、同一查询同源"写成硬规则，是为了堵住"我查了，0 行，所以有问题"这种反向解读的逻辑漏洞。

顺带一提，同一轮复盘还顺手修了错误分类器的一个同类问题：分类器原来把一切含 “does not exist” 的报错一锅端进"表缺失"，结果 Hologres 不支持 hex(text) 函数、text 列与数字字面量比较报 operator does not exist: text = integer，都被误导去"重注册表"。修法是拆出 function_missing 和 operator_mismatch 独立分类，对症给建议（函数问题换等价写法、类型问题加引号或显式转换），并用两个真实报错原文钉了回归测试。逻辑是相通的：定性错了，修法全错——无论是对报错分类，还是对"有没有鬼影"下结论。

7. 避坑清单

"基础设施有 bug"先当假的：这是成本最高的结论，定案前必须两步全过（payload 对账 → 直查数据库复核），一步没过就回去找自己的问题。
行号超出范围 = 读串了：模型引用"第 N 行"时，先看 N 有没有超过结果总行数。超过了，后面论证作废。
跨列的 0 行不是证据：验证探查必须与可疑分组同一列、同一查询同源。0 行证明的是"这条探查路径干净"，不是"怀疑成立"。
数仓兜底标签大概率是真实 ETL 值：“无”“未匹配到部门”"未知"这类值，别当脏数据随手丢掉——那次事故里，"未匹配到部门"恰恰是全月 33 笔、100% 转化、52.09 万的关键洞察。丢掉它，等于丢掉业务。
定性错了修法全错：报错分类里 “does not exist” 不能一锅端（函数缺失、运算符类型不匹配 ≠ 表缺失）；结论定性也一样，"有鬼影"和"我读串了"是两种定性，对应完全不同的修法。

8. 总结

给 AI Agent 的"基础设施有罪推定"熔断纪律，四句话：

模型说"框架/渲染/驱动层有 bug"，先当假的——这是最贵的结论，定案门槛最高。
第一步 payload 对账：summary 声明、meta.rows、rows 实际行数三处一致，机械检查，不依赖模型判断。
第二步直查数据库：绕开 agent 链路，逐字复核。两步全过才能定案。
证据必须同源：验证探查与可疑分组同一列、同一查询；行号超出结果行数范围 = 读串，论证作废。

核心思想一句话：贵的结论配贵的检查，便宜的检查先做——不要让模型的注意力，成为你最高成本结论的唯一证人。

给开发者的建议：去翻一下你的 agent prompt 或系统提示词，找找有没有"当模型怀疑基础设施/框架/驱动有问题时"的处理纪律。如果没有，把上面的两步 + 三条规则抄进去，钉成机械检查。重点是第一条"行号超出范围 = 读串"——它是成本最低、误报率最低的一个信号，先加上，立刻就能拦下一类事故。