一种没人及时发现的失误
让 AI 总结一条 CI pipeline，你会得到一段很整齐的话：lint 阶段 42 秒、build 3.5 分钟、整条 pipeline 16.4 分钟、比上周快 18%。读起来像一份报告。两个小时后才有人发现 build 从来没有花过 3.5 分钟，而失败率是从另一周抄来的。
这段话看起来没有任何可疑之处。问题就在这里：编造的数字和真实的数字，排版上完全一样。
为什么模型会这样
AI 在写总结时并不是在查你导出档里的行，而是在生成「最像下一个词」的内容——而「像」不等于「有出处」。两种失误最常见：
- 编造：那里需要一个数字，于是就生成了一个。「失败率 2.4%」会出现，是因为 pipeline 总结里通常有失败率，而不是因为 2.4% 真的存在。
- 漂移：数字本身是真的，但在流转中变了样——被四舍五入两次、秒和分钟换算错、从相邻的行/周/项目里串了行。
这两种都能通过人工审阅，因为审阅看的是文字逻辑，不是算术。
五分钟核验流程
1. 留原始导出，不要只留摘要。 把 CSV、日志、SQL 查询结果交给 AI。如果来源本身就是摘要，就没有东西可以核对了。
2. 把每个数字都当成需要出处的断言。 一条实用规则：没有来源行号，就不进报告。 这跟新闻业要求引用出处是一个道理，只是用在算术上。
3. 先对单位，再对数值。 1500 ms、1.5 s、0.025 min 是同一个时长。AI 总结里大量「看起来错」的数字其实是单位或四舍五入造成的，而真正编造的数字就藏在这片噪声里。
4. 留出容差。 摘要里保留三位有效数字的数值不可能和原始的 4183000 完全相等。设一个小的相对容差（1% 是个合理默认值），超出容差的判定为「待核实」，而不是直接判错。
5. 把「待核实」和「错误」分开。 待核实代表你贴的来源里找不到它——它可能是对的，只是来自你还没提供的数据；但在找到那个来源之前，它不能进报告。
AI 数字核验器 把第 3～5 步自动化了：把 AI 回答和来源一起贴进去，它会抽出每个数字、归一化单位与倍数量词、逐一比对，并把找不到出处的标红，同时给出对应的来源行号作为证据。
标红之后做什么
按影响从大到小处理，并给每个数字归类：
| 现象 | 常见原因 | 处理方式 |
|---|---|---|
| 完全找不到，但量级合理 | 编造 | 删掉，或者要求给出出处 |
| 差几个百分点 | 四舍五入、口径不同、周期不同 | 确认统计周期再用 |
| 只在单位换算后才匹配 | 摘要产生的偏差 | 可以用，但要写清单位 |
| 匹配到相邻但不同的行 | 串行 | 改正，并复查相邻数字 |
这套方法的边界
比宣传更重要的是说清限制：核验工具确认的是可追溯性，不是真实性。
- 数字全对，结论仍可能是错的——判断部分还是要人来做。
- 如果你贴的来源本身是旧的、错的，甚至是 AI 生成的，所有检查都会通过。
- 截图和聊天摘要不适合当来源，因为你要核对的数字可能在复制前就已经被四舍五入掉了。
- 只存在于你没贴的系统里的数字会一直是「待核实」，这是正确行为，但它不是结论。
把它当成一道低成本的第一道关：拦住「编造的数字直接进了汇报」这种代价最高的失误，论证本身仍然交给人的判断。
让它变成习惯，而不是救火
两个做法能让这件事长期跑得下去：
- 要过程，不要只要结论。 让 AI「把用到的原始数字和命令列出来」，多数情况下就能得到可核对的内容。
- 开会前核，而不是会后核。 核验只要几分钟；等一个编造指标已经发出去之后再发更正邮件，是几个小时。
核验器 完全在浏览器本地运行，内部报表、CI 日志和财务数字不会离开你的电脑；如果来源是从接口拿到的 JSON，先用 JSON 格式化工具 整理一下再贴进去会更顺。