一个 AI 工具值不值得用，不看它跑通的时候有多顺，看它坏的时候说的是不是人话。
今年我们换过三条生图路径、两个看图模型、一个上传方式。没有一条是因为它画得不好——它们画得都很好。换掉它们，是因为它们坏的时候，我们不知道它坏了。
第一个 200
七月的一天，一张封面图上传到对象存储，接口返回 200。我把这一条写进当天的运行记录：封面已上传。文章照常提交、构建、上线。
上线之后，头图是白的。
后来翻回去查，文件根本没落地。200 是真的，文件不在也是真的。
那个 200 说的是「我收到了」，我读到的是「它在那儿」。这两句话之间，隔着一次写盘、一次校验、一次确认。中间那一整段，没有人负责。
这件事之后我们改了规矩：每次上传完，独立请求一遍那个文件，亲眼看到 200 才算数。两秒钟的事。以前没做，不是因为笨，是因为「上传接口返回 200」这句话看起来已经把话说完了。
第二个 200
后来换过一个模型服务。用之前，我们习惯先探一下「还活着吗」。探针用的是列模型的接口——它免费，不花额度，返回 200 就说明这把钥匙有效。
有一次它返回 200，紧接着真正的生图请求回来 402：余额不足。
一个免费的探针，测不出付费的事。它量的是「你的钥匙能不能开门」，不是「门后面还有没有货」。我们拿一个不花钱的动作，去给一件花钱的事背书。
这个错当时没被发现，是因为它长得特别像一个正常的体检结果。健康检查报告上那个绿点，和「业务能跑」之间，本来就没有因果关系——是我们把它当成了因果关系。
报错指向谁
还有一次更有意思。某个模型名一调用就报错，报的那句话是「用户已被封禁」。
第一反应当然去查账号。查了半天，账号干净。同一把 key，换一个模型，跑通了。
坏的是那条路由的渠道，不是我们。但报错文本指向我们。
一个错误，如果它指向错的人，它就不只是错误——它会让你在一个不存在的问题上花掉一整天，而真正的故障在你没看的地方继续扩大。
同样的事后来又发生了一次，形式更温和：一个模型端点报「找不到」。我们差点当成「这个模型不存在」。可「找不到」其实有两种：一种是它从来没存在过，一种是它曾经存在、后来被关掉了。前者是你写错了名字，后者是你得换名字。同一个字符串，两种死法，处置完全不同。
它们都没挂
这三件事有个共同点：出问题的时候，系统全都是活着的。
它们没挂，都在返回，都在说成功——用它们自己的语言，在它们自己那一层。
写到这儿，我停了一下。它读起来像是在说「接口不可靠」。不是的。接口一直很可靠，可靠地做着它字面上承诺的事：HTTP 的 200 只表示「这个请求被成功处理了」，落地是下一层的事；上传接口的 200 表示「服务端受理了」，写盘是下一层的事；探针的 200 表示「这个免费端点通」，额度是下一层的事。
每一层都对。我们站在第三层，读着第一层的回执，然后签了字。
真正让我改主意的，不是这几次事故本身，是我们一直以来评估工具的方式：看功能表、看 demo、看跑分。这三样东西有一个共同的前提——它们采集样本的时间，全都在工具正常的时候。
手机评测早就过了这一关。这周有个折叠屏的测评，媒体把它折了三千次，折痕才显出来，发热才显出来。三千次不是它的功能，是它的耐久。我们给一部几千块的手机做三千次折叠，却给一套跑在业务里的 AI 系统只看一段 demo。
你为什么看不见坏的那一面
因为买的人和签收的人，往往不是同一个，量的东西也不一样。
买的人量的是「它能不能做这件事」。签收的人量的是「它做不成的那天，我要多久才知道、要花多少补」。同一件东西，两头两把尺子。
而 demo 是专门为第一把尺子准备的。demo 里没有「坏了」这个状态——演示的人不会在台上把东西弄坏，因为弄坏了就没有下一场了。
这里我得自曝一句：上面那三个 200，有两个是我们自己写进运行记录的。我写过「封面已上传」，写过「服务健康」。写下那句话的时候我并不心虚，因为接口确实是那么回的。我不是被骗了，我是替它把话翻译了一遍，翻译成了我想要的那个意思。
现在问的三个问题
我们后来把选型的问题整个换了。不问「它能干什么」，问三个只有它坏的时候才答得出来的问题。
一、它说「成功」的时候，成功指的是哪一层？
收下了、做成了、有人验过了，是三件事。大部分接口只保证第一层，而你要的往往是第三层。差的那两层，得自己补一个动作：上传完去请求一次那个文件，生成完去读一次那条结果。补这个动作不贵，不补才贵——贵在你是在读者打开页面的时候，才知道它没落地。
二、它坏的时候，报的错指向谁？
指向它自己的错误是好错误，因为它等于替你做了第一步排查。指向你的错误，要先验证一下再认——很可能不是你的问题。判断方法很土：换一个模型、换一把 key、换一台机器，看那个错会不会跟着变。变了，说明错在路由上，不在你身上。
三、换掉它要多久？
这条最容易被忽略。一个工具的价值，不只在它自己，还在它旁边那条备用路径。备用路径有两种：接口长得一样的，改个地址就能切；接口完全不同的，等于重写一遍。现在的规矩是，任何一条关键路径，都得有一条改一行配置就能切过去的路。没有这条路的工具，再便宜也不进关键路径。
这三问不新鲜。难的是它们都不在采购清单上——因为清单本身，是在工具正常的时候写的。
你可能会说，多验一遍不就完了。不是的。验什么，取决于你怎么定义「成功」；定义没想清楚，验一百遍也验不到点上。我们先花了一整年，才发现自己一直在验「请求发出去了没有」，而不是「东西在不在」。
所以现在看一个工具，我先看的不是它的 200 有多顺，是它出错的时候，报的那句话能不能对上它真干的事。
我们最后留下来的那几个，不是因为它们的 200 更值钱。是因为它们说 500 的时候，说的真是 500。
