开发者测试代码却从不测试 AI：AI 应用的质量保障缺失

我在构建 AI 系统时一直在思考一件事：

开发者对测试代码近乎痴迷。

但一旦我们构建 AI 功能，测试策略就变成了：

"我试了三次，效果还不错。"

我认为这正在成为 AI 开发中最大的短板之一。

AI 应用也是软件

以一个简单的 AI 编程助手为例。

工作流程大致如下：

用户请求 ↓ 上下文检索 ↓ Prompt ↓ LLM ↓ 生成的代码 ↓ 验证

每个环节都可能出错。

检索可能返回错误的文件。

上下文可能不完整。

Prompt 可能存在歧义。

模型可能产生幻觉。

生成的代码可能包含 bug。

然而许多 AI 应用根本没有自动检测这些失败的方式。

我们不会接受普通 API 的这种标准。

为什么 AI 就应该例外？

"试过一次"几乎毫无意义

假设你在构建一个将自然语言转换为 SQL 的系统。

"帮我找出收入最高的 10 位客户。"

SELECT customer_name, SUM(revenue) AS total_revenue
FROM sales
GROUP BY customer_name
ORDER BY total_revenue DESC
LIMIT 10;

"帮我找出 2025 年收入最高的 10 位客户，排除已取消的订单。"

突然之间，你的系统可能产生完全不同的行为。

AI 输出是概率性的。

这意味着测试一个输入远远不够。

构建评估数据集

AI 开发者能做的最简单的事情之一，就是创建一个小型的评估数据集。

test_cases = [
    {
        "input": "Find the top 10 customers by revenue.",
        "expected_contains": ["GROUP BY", "ORDER BY", "LIMIT"]
    },
    {
        "input": "Find revenue for 2025 excluding cancelled orders.",
        "expected_contains": ["2025", "cancelled"]
    },
]

现在，每次你修改系统时，都可以用相同的用例运行 AI 系统：

这就改变了一切。

你不再是在问：

"这个感觉更好吗？"

"性能有提升吗？"

Prompt 同样需要测试

这也是我认为 Prompt 工程不会消失的原因之一。

生产环境的 Prompt 不是你写一次就完事的。

它是系统的一部分。

如果你修改了它，应该知道这次修改是否提升了输出。

我在《Prompt 工程不会消失的真正原因》中讨论过这一更广泛学科的重要性。

下一步是将 Prompt 工程与评估连接起来。

把它想象成软件工程：

Prompt v1 ↓ 评估 ↓ 结果 ↓ Prompt v2 ↓ 评估 ↓ 对比

这比根据直觉修改 Prompt 可靠得多。

上下文同样需要测试

这是另一个问题。

即使 Prompt 完美无缺，也可能因为 AI 收到了错误的上下文而得到糟糕的答案。

想象一个编程助手收到了：

Prompt: "修复这个认证 bug。"

5 个不相关的文件 + 过时的文档 + 错误的配置

模型可能会基于完全错误的信息生成看似合理的代码。

这就是为什么我认为上下文工程正在变得和 Prompt 工程一样重要。

我在《为什么上下文工程比 Prompt 工程更重要》中写过这个话题。

教训很简单：

不要只测试你问模型的问题。还要测试你给模型的信息。

工作流需要评估

当 AI 是更大工作流的一部分时，这一点变得更加重要。

用户 ↓ 检索器 ↓ LLM ↓ 工具调用 ↓ 验证 ↓ 最终响应

失败发生在哪个环节？

是检索出了问题？

是模型选错了工具？

还是 API 返回了错误数据？

这是我一直认为工作流往往比 Agent 更重要的原因之一。

一个定义良好的工作流能让你在清晰的位置进行测量和调试。

我在《为什么我认为工作流比 Agent 更重要》中详细探讨了这个观点。

你不需要昂贵的 AI 评估平台才能开始。

从 20-50 个有代表性的测试用例开始。

对于每个用例，记录：

然后每次做出重大修改时，运行这个数据集。

随着时间推移，你的评估数据集将成为 AI 项目中最有价值的资产之一。

它定义了"好"的真正含义。

我的 AI 评估规则

我开始用三个层次来思考 AI 系统：

它能产生答案吗？

它能持续产生正确答案吗？

我们能衡量它是否在改进？

工程成熟度。

第三个问题是许多 AI 项目挣扎的地方。

如果你无法衡量改进，那基本就是在猜。

评估是缺失的那一层

AI 行业已经投入了大量精力来改进：

但评估同样值得同等关注。

因为最终每个 AI 系统都需要回答一个令人不安的问题：

"你怎么知道它能工作？"

"演示看起来很震撼。"

"模型能力很强。"

"用户似乎很喜欢。"

给我看看评估。

这是我希望在 AI 领域看到更多的工程思维。

把它集成到你的 GitHub 工作流中

我还给我的配套 AI Builder 资源添加了一个简单的 AI 评估入门模板。

一个有用的结构是：

ai-evaluation/ ├── README.md ├── test_cases.json ├── evaluate.py ├── results.csv └── prompts/ ├── v1.txt └── v2.txt

想法很简单：

Prompt 修改 → 运行测试 → 记录结果 → 对比版本。

这把实验变成了工程流程。

我不认为 AI 开发应该是：

Prompt ↓ 看起来不错 ↓ 发布

而应该更像：

构建 ↓ 评估 ↓ 测量 ↓ 改进 ↓ 再次评估 ↓ 部署

这才是构建可靠软件的方式。

我相信这也是构建可靠 AI 需要采用的方式。

AI 工程的未来不会只属于那些知道如何让模型产生惊艳输出的人。

它将属于那些能够测量、再现、调试和改进这些输出的开发者。

因为 AI 领域最重要的问题不是：

"模型能做到吗？"

而是：

"我能证明我的系统可靠地做到吗？"