AI上线后怎么测？这位工程师把锅甩给了日志

产品经理庆祝"顺利上线"时，一位工程师正在后台数钱——数的是被幻觉悄悄烧掉的钱。这不是段子，是生产环境里每天都在发生的事。

核心矛盾：用测代码的方式测AI，本身就是bug

原文作者抛了一张图，把问题说得很直白：

我们给代码写单元测试，是为了确保特定输入返回特定输出。但AI要面对的是" messy, ambiguous inputs"——混乱、模糊的输入。用确定性测试套件去套概率模型，就像用游标卡尺量海浪。

更麻烦的是危险信号变了。传统软件崩了会报错，AI崩了会自信地撒谎。作者见过太多案例：LLM功能"平稳"上线，实际上却在缓慢失血——数据泄露、幻觉输出、用户流失，全被"没崩溃"的假象盖住。

那张图里画了一条分界线：左边是代码测试的思维，右边是AI测试的现实。中间隔着一道鸿沟。

幻觉不是模型病，是数据病

作者举了个扎心的例子：让LLM总结法律合同，它凭空捏造了一个条款。你的单元测试在干嘛？检查输出有没有100个字符。测试通过了，欺诈发生了。

「I need to test against truth.」

这句话是全文锚点。要抓幻觉，不能看输出长度，得看输出真假。作者的做法是建检索评估流水线（retrieval evaluation pipelines），模拟向量数据库。上下文弱，模型就幻觉；不承认喂了垃圾数据，就永远修不好模型。

这里有个反直觉的点：很多人把幻觉当成模型问题，拼命调参。但作者说，先测你的数据管道。RAG系统里，检索质量是上游，模型生成是下游。上游浑了，下游再干净也没用。

Agent的坑：它会删生产数据库

如果说LLM是单点故障，Agent就是连环雷。原文把Agent定义为"stateful simulations of humans"——有状态的人类模拟。它们会用工具、会推理、会循环。

失败模式也很人类：卡在推理循环里出不来，或者把生产环境的DELETE端点当成测试环境点了。这不是部署配置错，是可靠性工程没做。

作者的策略很"不舒服"但有效：不再信任模型的内部思维链。强制Agent记录每一次工具调用，然后审计这些日志。查什么？查状态码看了吗，重试逻辑写了吗。

一个残酷发现：大多数Agent能通过基础单元测试，但在真实日志审计里一塌糊涂。就像驾照考试满分，上路就追尾。

生产环境测试的三条硬规矩

把原文的方法论拆出来，其实是三个转向：

第一，从测输出格式转向测事实准确性。字符数、JSON结构这些表面合规，掩盖不了内容造假。

第二，从信任模型转向信任日志。内部思维链不可见，工具调用记录是唯一能审计的抓手。

第三，从单点测试转向流水线测试。RAG要测检索，Agent要测工具链，端到端的可靠性比模型分数更重要。

作者提到MegaLLM作为多模型优化的例子，但核心观点不绑定任何平台——这是工程思维的迁移，不是工具采购清单。

为什么这事现在必须想

LLM功能上线越来越容易，测好越来越难。作者见过的"顺利上线" celebrations，背后往往是监控盲区里的慢性失血。生产环境测试不是可选项，是AI产品从demo走向业务的门票。

具体怎么做？先挑一个正在运行的LLM功能，找出它的"100字符测试"——那种通过了但没用的检查。替换成一个真问题：这个输出，事实对吗？