出了事故,最怕的不是修,而是"不知道该怪谁"。留底,就是为了那个时刻。
开场:为什么记账能避免扯皮
两个朋友一起旅游,AA 制。玩到一半对账,谁多花了?如果当时一笔笔都记下来,翻账本立刻清楚,谁也赖不掉。
如果不记账呢?“我没花那么多"“你记错了吧"“当时明明说好……"——全是扯皮,最后只能凭印象和感觉,伤和气。
留底(记录)的价值,恰恰在"出问题的那一刻"才显现:它能让你快速、有理有据地搞清楚"这事到底赖谁”。
AI 审查产品上线后,这句话尤其重要。
二、产品上线后,事故是"多头"的
AI 审查不是单机小玩具,它是一条流水线:
代码改动 → 调 AI 审查 → 产出结论 → 团队按结论动作 → 上线
一旦出了问题(比如:漏检了一个安全漏洞、上线出事故;或者误报太多、团队抱怨),你要判断锅在哪个环节。可能的"嫌疑人"有这么多:
- 考卷/标准答案的问题(数据)——“我们测的时候明明是抓到了的”;
- 模型的问题(能力)——“换了型号之后就不行了”;
- 配置/版本的问题(环境)——“上个版本可能把某个东西改坏了”;
- 运行过程的问题(执行)——“那次运行 AI 中途断了、没审完”;
- 评分规则的问题(口径)——“是我们打分规则算错了”。
如果没有留底,你只能靠猜、靠回忆、靠大家开会“各说各的”。而猜,在信任产品上是致命的——你无法向团队证明问题出在哪,也就无法让人相信"问题已经修好了”。
三、留底留什么:给每次审查拍一张“完整快照”
要让“出问题能定位、能证明”,产品要记录足够的信息。白话讲,每次审查都要留下这些:
- 这次审的是什么:哪个文件、改动前后各是什么版本(git 提交号);
- 用的什么配置:哪个 AI 型号、哪版提示词、哪版工具、哪版评分规则(都有版本号);
- 过程发生了什么:AI 调了哪些工具、每轮花了多久、最后输出是什么;
- 结果怎么算的:最后给分是怎么算出来的、判分规则是什么;
- 身份/时间:是哪一次运行、什么时候、给谁跑的。
记下这些,类比旅行记账:一旦“对不上账”,你翻出来能指认“这一步是这么发生的”。
四、关键:为什么“身份信息”不能信 AI 自报
这里有个多数人不会想到的坑:像“这是哪次运行、用的什么配置”这类“身份信息”,绝不能听 AI 自己说,必须由系统自己打上。
为什么?
- AI 是会"编"的(专业叫"幻觉”)。它完全可能自信地在输出里写一个“配置版本号”,但那可能压根不存在;
- 如果信的它的自报,那这串身份就不可靠,将来“这次运行用的什么配置”就说不清;
- 一旦身份链不可靠,整条记录的可信度就崩了——“出问题定位"全靠这串身份,结果这串身份是假的,那就全完了。
所以:身份信息由系统打、由系统管,AI 没有资格自报。 就像成绩单上的学号是教务处打印的,不是学生自己写上去的——道理一样。
五、留底也有“防篡改”的要求
留底不是“记了就完事”,它还得防止被偷偷改。因为:
- 如果留底可以被随意篡改,那"出问题翻账本"就变成了"出问题造假账本”;
- 审计的意义在于:记录一旦写下就不能反悔,谁要狡辩都拿这条记录说事。
所以留底通常要配合“指纹/版本号”一类的机制:让每条记录有身份、有来源、可核对,谁动了它都能发现。这在第 7 篇讲"故意搞破坏"时已经出现过——篡改记录必须能被发现。
通俗说:账本除了记录,还得是"防涂改的账本"。
六、跨来源的"对得上"——互相印证
留底的另一个高级用法是互相印证:同一个事实,用两个独立来源记录,如果对得上,可信度就大增。
举例:
- 某次审查用的 AI 型号,在"过程记录"里记了一次,在"结果文件"里也记了一次;
- 两个文件对得上 → 说明没写错、没被篡改 → 可信;
- 对不上 → 说明中间有环节出了问题,值得警惕。
就像一笔支出,银行卡流水和手账都记了,两个数一致,你才放心。单一来源可能坏,多来源对得上,才敢信。
深入一点(可跳读)
- 把“留什么底、怎么留、怎么防篡改”写成一份产品范围内的硬规范,所有环节共用,而不是各留各的。
- “身份由系统打”这个工程细节,落实到日志/文件里,变成“运行身份由宿主注入,不接受被测对象申报”——这是防止“自己吹自己”的数据污染。
- 留底的格式要每次可重放:拿到一条旧记录,当年能回放成同样的过程(断点可续、结果可复算)。这是"出事了能重查"的技术保障。
这一篇的收获
产品上线后,事故是"多头"的——数据、模型、配置、运行、规则都可能出问题。要快速、有理有据地定位"怪谁",每次审查都必须"留底":审了什么、用的什么配置、过程怎么发生、结果怎么算、身份是什么。身份由系统打(不信 AI 自报),记录要防篡改、能互相印证。
留了底,还要能判断这批数据本身是不是完好的——不然你会拿一堆坏数据去下结论。下一篇讲:数据"对账"与守恒。