64 篇博文 含有标签「testing」

当同一个模型负责编写需求、实现代码并编写用于验证正确性的断言时，“所有测试通过”不再是功能正常工作的证据，而仅仅证明了模型是内部一致的。这是两回事，而这种区别正是编写测试的初衷。

我们通常对测试套件的理解是，它们提供了“第二意见”。作者带着一种对需求的心理模型编写代码，而测试编写者则带着略有不同的心理模型编写断言。这两个模型不一致的地方，往往就是 Bug 潜伏之处。这种说法的前提是测试编写者与代码作者拥有不同的认知视角。如果去掉了视角的差异，测试套件就不再携带关于正确性的任何独立信息——它只携带关于一致性的信息。

你的 LLM-as-judge 给新模型开了一张健康证明。胜率上升，各项评分指标全线改善，自动化评测流水线全绿通过。然后你上线了——用户满意度却下降了。

这不是边缘案例。研究人员构建了一个无论何种输入都输出固定回复的「空模型」，并在 AlpacaEval 2.0 上拿下了 86.5% 的长度控制胜率。而当时经过验证的真实最优水平是 57.5%。当一个毫无任务能力的模型都能登顶你的排行榜，你的评测框架就有了值得系统审视的问题。

大多数 AI 团队只会构建一次评测套件——在上线前的冲刺阶段，他们精心设计了边界场景用例，记录预期输出，经过评审后发布。六个月后，套件仍然通过。然而，模型在实际生产流量上已经悄然退步，而评测框架却是在那些流量出现之前编写的。它仍然在评判作者提出问题的答案，而非用户真正在问的问题。

这就是"博物馆问题"：一个在某个时间点策划的评测套件会不断积累文物。它证明系统能处理某人预期的场景，却无法覆盖真正让它崩溃的场景。

你的测试环境通过了所有检查。LLM 对每个测试提示词都做出了正确响应。延迟表现良好。质量评分看起来也不错。你发布了。然后，两天后，生产环境开始在你的评估集从未涵盖的一类查询中出现幻觉，你的成本飙升了 3 倍，因为缓存是冷的，而且你的供应商推送的模型更新静默地改变了行为，而你的旧测试套件无法检测到。测试环境显示一切正常，生产环境却给出了截然不同的结果。

这并不是一个可以通过编写更多测试用例来弥补的测试差距。预发布环境对 AI 系统具有结构性的误导，而对传统软件则不然。失败模式是系统性的，解决办法不是更好的测试环境，而是一种不同的架构。

你的 AI 评估测试集（eval suite）有 800 个测试用例。你又增加了 200 个。现在你的模型在评估中得分 94%，你满怀信心地发布了。三天后，一名用户发现了一个回归（regression）问题，而你那 1000 个测试用例中没有一个捕获到它。

这不是运气不好 —— 而是结构性问题。回归问题的存在恰恰是因为你扩充测试集的方式，而不是尽管你扩充了测试集才存在。当出现故障时增加更多评估指标（evals）的本能在理论上是正确的，但在实践中却适得其反。更多的测试并不自动意味着对重要事项的覆盖率更高。它们意味着对那些易于测试的事项有了更好的覆盖，而这完全是两回事。

你的流式传输正常工作。你的重试逻辑正常工作。你的安全过滤器正常工作。你的个性化功能也正常工作。但当你将它们部署在一起时，奇怪的事情发生了：流式传输中途出现的速率限制错误导致用户看到的是一段被截断的响应，而系统却将其记录为成功。重试机制触发了，但流式传输已经结束。个性化层提供了一个定制化的响应，而安全过滤器本应拦截这个响应——除非过滤器看到的是 Prompt 的脱敏版本，而不是个性化层所处理的那个版本。

每一个功能都通过了你编写的各项测试。然而系统还是让用户失望了。

这就是功能交互故障（feature interaction failure），它是当今 AI 系统中最容易被误诊的生产环境 Bug。

当两个微服务在API假设上出现偏差时，集成测试会在上线前捕获问题。当两个智能体在提示词假设上出现偏差时，你只会在客户收到自相矛盾的答案——或者整条流水线因级联故障崩溃——时才会发现。多智能体AI系统在生产环境中的失败率高达41%–87%。这些失败中超过三分之一并非模型质量问题，而是协调故障：某个智能体改变了输出格式，另一个智能体仍然期望旧的数据结构，而没有人为此写过测试。

根本问题在于，智能体之间通过隐式契约进行通信。一个研究型智能体——在某人的心智模型中——约定返回带有 sources 数组的JSON对象。编排型智能体依赖这个结构。没有人把它写下来，没有人测试它。六周后，研究型智能体的提示词被优化为返回排名列表而非 sources 数组，编排型智能体就悄无声息地丢失了一半输入。

有一种特定的工程债（Engineering debt）永远不会出现在你的指标中。每当有人在系统提示词（System prompt）中添加一个句子来修复一个偶发的投诉——比如 “绝不讨论竞争对手的产品” 或 “始终以正式的口吻回复” ——而随后又没有人验证模型是否真的执行了它，这种债务就会累积。几个月后，提示词增加到 800 个 Token。它听起来很有权威感，包含的内容包罗万象。但也许其中三分之一根本没起作用。

提示词变异测试（Prompt mutation testing）就是找出那三分之一无效指令的实践。该技术借鉴了软件工程中经典的变异测试：系统地在代码中引入微小、刻意的错误，以确定你的测试套件是否真的能捕获它们。在这里，你向系统提示词中引入刻意的扰动——删除一个分句、抵触一条规则、用近义词替换关键关键词——并衡量模型的输出实际发生了多大变化。那些在扰动下幸存且不影响行为的指令是装饰性的。而那些一旦被触碰就会导致出错的指令则是承重的（Load-bearing）。

一位小团队工程师花了三个月将测试生成委托给 AI。代码覆盖率从 47% 跃升至 72%，再到 98%。每次 PR 都返回绿色。然后生产环境崩了。用户注册中的竞态条件因数据库复制延迟导致重复邮箱。优惠码接口在代码无效时返回 null 而非零，导致支付计算对 4700 名客户静默出错。最终损失：4.7 万美元退款和 66 小时工程时间。测试并没有遗漏几个边界情况——它们覆盖了所写的代码，而非所部署的系统。

这就是覆盖率幻觉。随着 AI 辅助开发成为默认选项，落入这个陷阱正变得越来越容易。

经典的 Bug Bash 是一种为确定性软件量身定制的确定性仪式。十名工程师挤在一个 Slack 频道里两小时，对照着黄金路径流程清单疯狂测试，然后提交带有清晰复现步骤的工单：“点击 X，看到 Y，预期 Z。” 这套方法之所以奏效，是因为被测系统是可复现的——相同的输入，相同的输出，相同的 Bug，次次如此。

如果针对 AI 功能运行完全相同的仪式，你最终会得到 200 张工单，其中 180 张会因为“符合预期的随机波动”而被关闭，同时还会漏掉那 20 张预示着真正的群体性回归（cohort regression）的工单。这种形式不仅陈旧，而且完全错位了。针对基于 LLM 的功能进行 Bug Bash 并不是一场捕捉缺陷的会议。它是一场针对概率分布的抽样练习，如果团队像运行确定性测试那样运行它，就是在收集噪声并将其视为信号。

这篇文章讨论的是如何为随机系统重新设计 Bug Bash——包括流程形式、参与者、分级准则以及什么才算“完成”等方面需要做出哪些改变。

我见过的每一个发布过“小规模”输出 Schema 变更的 AI 团队，都经历过同样的一周。有人在系统提示词（system prompt）中重命名了一个字段——比如将 summary 改为 tldr，或者工具目录中增加了一个必填的 confidence 参数——结果下一次 CI 运行就在 800 个与该变更毫无关系的 Eval 用例中亮起了红灯。提示词的 diff 只有 15 行。而 Eval 的 diff 却变成了一个为期四天的迁移项目，且无人规划、无人负责，也从未包含在预算之内。

这就是 Eval 迁移税（Eval Migration Tax）。这是任何路线图都没有考虑到的维护成本，它以发布延迟的形式支付，而这些延迟往往被归咎于“不稳定的测试”（flaky tests），而非真正导致它们的架构选择。大多数团队在意识到这一模式之前已经支付了数年的代价，因为每一个单独的事件看起来都像是普通的日常损耗。只有当你统计一个季度内用于迁移 Eval 的工程小时数，并发现它们超过了用于改进 Eval 本应衡量的模型行为的时间时，这种复利效应才会显现。

当你团队中的初级工程师第一次输入 --update-snapshots 并推送到 main 分支时，你的测试套件就不再是测试套件了，它变成了一份记录稿。虽然 Diff 依然显示为红绿颜色，CI 徽章依然会变为通过，但信号已经悄然反转：测试套件不再告诉你代码是否正确，而是告诉你是否有人费心看过输出。对于确定性的代码，这种风险尚在可接受范围内，因为大多数 Diff 确实是符合预期的。但当网络调用的另一端是一个随机模型时，同样的流程会让每一个 PR 变成一场硬币投掷，让每一位评审者变成一个橡皮图章。

快照测试曾是确定性世界里的一个美妙构想。你记录下上周二 render(<Button />) 的生成结果，断言本周二它会生成相同的字符串。从定义上讲，任何 Diff 都是值得人工核查的行为变更。这种模式在 Jest、Vitest、Pytest、整个 React 生态系统以及一代又一代的 UI 快照扩展中得以幸存，是因为底层契约依然成立：相同的输入加上相同的代码等于相同的输出。但这个契约对 LLM 调用并不奏效。相同的输入、相同的代码加上相同的提示词（Prompt），却会产生不同的字符串——而且这种差异并非 Bug，而是产品按设计正常运行的结果。