去年在关西一家做工业零部件的企业，项目已经上线三个月，我们那套内部问数据的agent系统用得很顺，几乎每周经营会议上都有人拿它现查数字，不用再等IT那边跑报表。那天是月度经营会，外面下着小雨，会议室的百叶窗拉了一半，坐了七八个人，生产、销售、财务的部门长都在，气氛挺轻松。生产总部一个课长随口报了个当月的退货率，说这个数字比预期好，皱了下眉嘀咕了一句这个月改善得有点猛，自己都没料到，说完还是照旧建议下个月追加一批产能。数字报出来的时候，我心里咯噔一下，因为三个月前我们做数据口径梳理的时候，这个指标我亲手核过，记忆里的数不该是这个，差了将近一半。 会开完我没吭声，先拉着客户那边的技术负责人一起查。一开始我们怀疑是不是模型自己编了个数，把执行日志一行行翻出来看，SQL语句一句话都没写错，连表名字段名都对得上，整个查询链路干干净净，没有任何报错，越是查不出毛病，越觉得不对劲。查了快一个钟头，才在一份变更记录里翻出问题，时间戳是三周前，提交说明只写了一句优化查询性能，谁都看不出这行改动碰了口径。生产系统和财务系统对退货率的定义压根不是一回事，生产那边算的是当月发货和当月退货的比例，财务那边算的是从年初到现在的累计口径，agent接的语义层，一直用的是生产这套月度口径，就是那份变更记录改的这张表，字段名字一个字没改，背后的计算逻辑却被悄悄换成了财务那套累计口径，做变更的人核对的是数据跑不跑得通，没意识到这个字段还被agent的语义层直接引用着，含义早就换了。表面上看，agent一个字都没答错，它只是精确地回答了一个没人问过的问题。 这事让我后怕的不是agent算错了，是它错得那么体面。语气笃定，格式规整，连小数点都保留了两位，谁看了都会觉得这是个靠谱的数字。要是没人多问一句，下个月的产能追加决策就会建立在一个被悄悄换过口径的数字上，那不是小数目的事。真正让这事没捅出大篓子的，一半是运气，一半是两下凑在一起，他那句连自己都没当回事的嘀咕，加上我记着旧数字多问了一句，两下才把这事摁住，少了哪一下，这个数字大概率就这么滑过去了。这行做下来我越来越觉得，最该害怕的不是AI一本正经胡说八道，那种错误反而好抓，最该害怕的是它错得刚刚好卡在没人会去怀疑的地方。 这个项目从签合同到那会儿快一年了，上线也有三个月，双方处得算是知根知底，我不想为了这一件事把攒起来的信任搭进去。日本这边的团队对这类事情很敏感，处理不好容易伤了以后配合的默契，所以跟客户那边沟通的时候，我没有把这事定性成谁的失误，而是包装成系统升级过程中常见的一类风险，大家就事论事，一起把跨系统的口径都建了一层校验，同一个指标只要来源不一样，agent回答之前必须先说一句自己用的是哪个口径。用户一开始觉得有点啰嗦，但这行干久了你就知道，宁可让人嫌啰嗦，也不能让人心安理得地信错。 现在我每接一个新项目，第一件事不是看模型选哪个，是先蹲在客户的报表堆里，把每个数字问上三遍这是怎么算出来的。那次之后我常想起那位课长皱眉的样子，他大概到现在都不知道，自己那句嘀咕帮公司躲过了一次多大的误判。AI能把数字算得又快又好看，这行做到最后拼的，可能还是有没有人在数字背后，保留着那种说不清道不明的不对劲的直觉。等哪天这类校验也能被agent自己做全了，我们这些蹲在数据堆里的人，是不是也该开始琢磨，自己那点说不清道不明的直觉，还能值几年钱。