自动化测试并非安全网

我们都曾交付过这样的代码：测试套件全部通过，结果上线不到十分钟生产环境就燃起来了。自动化测试被当作一面无懈可击的盾牌，但实际上它只是一把扫帚——能扫掉已知的灰尘，却阻止不了天花板坍塌。

整个行业陷入了指标陷阱。代码覆盖率成了软件质量的代理指标。管理层看到 80% 的覆盖率徽章，就以为系统刀枪不入。而工程师整天在为那些永远不会出错的纯函数写脆弱的断言，真正的集成点——微服务之间、数据库锁、外部 LLM API——却完全是一团乱麻。测试套件只能证明你的代码做了你告诉它做的事，完全说明不了你让它做的事到底有没有意义。

以一个典型的 SaaS 应用集成 LLM 做搜索为例。你写了单元测试来 mock API 响应，mock 返回的是干净的 JSON，断言也通过了，你部署了。结果模型遇到了提示词注入攻击，幻觉出一个看起来有效但缺少 key 的 schema，下游的支付 worker 崩溃了——因为它期望一个字符串却收到了 null。你的单元测试全程都是绿的。它们测的是 mock 构建的幻想世界，而不是生产环境中 messy 的现实。

这就是 Kluvex 这类工具改变我们思考验证方式的地方。与其依赖同一个疲惫工程师写的静态断言（他同时也写了那个 bug），现代工作流需要持续的行为监控，观察真实的执行路径。我们需要停止假装绿灯测试等于正常运行的系统。

工程工作的真谛不是为满足 CI 管道写测试，而是预见组件以无人预料的方式交互时系统会如何失败。测试是必要的，但它们是过去失败的文档，而不是预见未来的水晶球。相应地对待它们吧。