谷歌那篇论文被翻烂了，87%的AI项目还是死在测试这关

87%的数据科学项目从未进入生产环境。这个数字VentureBeat在2019年报道过，五年后McKinsey 2023年的报告依然在说同一回事——生成式AI（人工智能生成内容） adoption在加速，但大多数组织困在实验阶段出不来。

团队能做出惊艳的demo，老板点头，预算批了。然后项目卡在"我电脑上能跑"和"线上能跑"之间的某个地方，悄无声息地烂尾。

数据质量、模型性能、组织准备度——这些背锅侠年年被拎出来。但有个更根本的问题就摆在眼前：大多数团队根本不知道该怎么测试AI系统，测试的严谨程度远不及传统软件。

他们测了代码，没测智能。

Google 2015年那篇《机器学习系统中隐藏的技术债务》被引用超过4000次，核心观点至今没人真正听进去：ML系统特别容易积累技术债务，因为它继承了传统代码的所有维护问题，还额外叠加了一层ML特有的麻烦。测试缺口是生产故障的主要来源之一。

两套系统，一套测试

生产环境的AI系统其实是两个系统拧在一起：确定性的软件层（API、数据管道、编排逻辑）和非确定性的AI行为层（提示词响应、智能体决策、模型输出）。

工程团队对第一层驾轻就熟。单元测试、集成测试、端到端测试，TDD（测试驱动开发），CI流水线卡住合并——这是成熟的纪律。

但AI层呢？提示词、智能体行为、模型响应——被当成黑盒处理。团队扫几眼输出，"差不多行了"，就往下走。没有测试套件，没有回归防护网，不知道某个提示词改动在修复A场景时把B、C、D场景搞崩了。

Google的ML Test Score评分体系把生产就绪度拆成四个维度：数据测试、模型测试、基础设施测试、监控。大多数团队四项全崩。Microsoft Research的研究发现，即便在大厂内部，ML系统的测试实践也显著落后于传统软件。

这就是缺失的测试套件。也是AI项目进不了生产的头号原因。

提示词测试长什么样

如果不会给没单元测试的函数发版，就不该给没测试用例的提示词发版。

提示词测试的结构和传统测试一样：给定输入，断言输出。区别在断言必须容纳非确定性。你不是在检查

```python assert output == "精确字符串" ```

而是在检查

```python assert output.contains("关键信息") assert output.sentiment == "positive" assert output.follows_format(json_schema) ```

这种测试需要新工具。传统断言不够用，得引入语义评估：向量相似度、LLM-as-judge（用大语言模型当裁判）、基于规则的约束检查。输入空间爆炸式增长，得做采样和覆盖分析。模型版本漂移，得建立基线和回归检测。

Anthropic的提示词测试框架把测试分为三层：单元测试（单轮提示词）、集成测试（多轮对话）、端到端测试（完整工作流）。每层都有对应的评估指标和失败阈值。这不是纸上谈兵，是他们内部跑Claude（大语言模型）生产线的实际做法。

LangChain的LangSmith、Weights & Biases的Prompts、HoneyHive这些工具都在试图填这个坑。但工具只是工具，问题在意识——大多数团队还没意识到这是一个需要专门解决的工程问题。

为什么这事这么难

测试传统软件，输入输出是确定的。测试AI系统，同一提示词给同一个模型，温度参数（temperature）不为零时，两次输出可能不一样。这违反了测试的基本假设：可重复性。

更麻烦的是评估什么。传统软件的功能需求写得清楚：用户点击按钮，订单状态变"已支付"。AI系统的"正确"是模糊的：这个摘要够好吗？这个回答有帮助吗？这个代码建议安全吗？

所以需要把模糊的"好"拆成可测量的维度。RAG（检索增强生成）系统测检索准确率、答案相关性、幻觉率。Agent（智能体）系统测任务完成率、步骤效率、工具调用正确性。每个维度要有数据集、要有基线、要有自动化的回归检测。

Google的ML Test Score paper里有个细节：他们建议把测试分为"小到能跑完"和"大到能发现问题"两类。小测试快速反馈，大测试 nightly跑。这和传统软件的分层测试策略一致，但执行起来难得多——因为"大测试"需要标注数据，而标注数据是AI项目里最贵的环节之一。

一些正在发生的改变

2023年开始，这个缺口在收窄。不是因为有银弹，而是因为生产事故够多了。

Stripe的AI团队公开分享过他们的测试策略：每个提示词改动必须通过"对抗性测试集"——专门构造的边界案例，包括注入攻击、歧义输入、长上下文压力测试。这套测试集随着线上bad case（坏案例）持续扩充，形成回归防护。

OpenAI的Evals开源框架提供了一种结构化方式：定义数据集、运行模型、打分、对比基线。这本来是给模型开发者用的，越来越多团队拿它来测自己的提示词工程。

更激进的团队在搞"提示词版本控制+CI/CD"。把提示词当代码管，PR（Pull Request，代码合并请求）触发自动化评估，分数掉超过阈值就阻断合并。这要求测试够快、够稳定、够全面——目前只有头部团队能跑通。

但方向是清楚的。AI工程正在从"炼丹"往"工程化"走，测试是这条路上的必修课。

那个87%的死亡率会降下来吗？取决于多少团队愿意把提示词测试从"有空再做"挪到"发版必做"。

你现在是怎么测提示词的—— eyeball，还是有套自动化流程在跑？