LLM 能工作，但你的产品可能不行

近日，OpenAI 报告称，GPT-5.6 Sol 在官方控制框架下仅取得 13.3% 的 ARC-AGI-3 得分。然而，在启用保留推理和上下文压缩后，同一模型得分跃升至 38.3%，同时输出令牌数减少六倍。

同样的模型，同样的基准，不同的控制框架——这一结果应彻底改变我们解读 AI 基准测试的方式。ChatGPT、Claude Code 或 Codex 绝非仅仅是 API 背后的模型。它们是模型、上下文管理、工具、记忆、权限和执行循环的整合体。

这个整体才是真正的产品。

然而，数以千计的 SaaS 产品声称使用 GPT 或 Claude，仿佛接入模型就意味着获得了这些产品所展示的能力。事实并非如此。

每家使用 LLM 的公司都在构建自己的控制框架，无论其是否意识到这一点。一个薄弱的框架能让优秀的模型显得愚蠢；而一个强大的框架则能让完全相同的模型显得聪明得多。

我曾在实验小型开源模型时亲身体验到这一点。在我们的初始应用中，有些模型几乎毫无用处。但在根据其优势调整上下文、指令和工具循环后，它们变得切实有用。

基准测试即护城河

公开的基准测试只能告诉你一个模型加控制框架在某类任务上的表现，却几乎无法说明你的产品是否能完成实际工作。

一个客服代理可以承诺退款却不实际生成；一个编程代理可以解释正确的修复方案却让测试失败；一个研究代理能产出令人信服的报告，但依据的是过时或虚构的信息源。

2025 年，Replit 的 CEO 承认其代理删除了生产数据库中的数据，并称之为“不可接受”。有趣之处不在于 AI 犯了错，而在于整个系统竟允许这个错误变成生产动作。

因此，任何价值实质性依赖 LLM 的 SaaS 都需要自己的内部基准测试。它应重现真实的输入、工具、权限和故障模式，并评估完整的部署系统：模型、提示、上下文策略和执行循环。

更重要的是，它应测试最终状态，而非模型听起来有多可信。退款是否实际创建？测试是否通过？信息源是否真实？操作是否获得授权？

如果代码能验证结果，就用代码。LLM 可以生成多种可能的解决方案，但确定性检查应验证权限、计算、工具结果和最终状态。

如今，一个令人印象深刻的 AI 原型可以在几天内构建完成。但要确保其可靠运行，仍可能需要数月时间。严肃的评估需要代表性案例、专家标签、重复运行、对抗性输入和持续维护。

每次更换模型都应触发基准测试。但更换提示、工具描述、检索策略或上下文策略时也应如此，因为每次变更都会创建一个略有不同的系统。

没有内部基准测试，团队无法知道自己是在改进产品，还是在改变其行为。

真正的产品并非 API 背后的模型，而是模型、控制框架以及证明它们协同工作的证据。没有这些证据，AI SaaS 就不能算是经过测试的产品——它只是一个在生产环境中运行的演示。

模型正成为商品，而基准测试才是护城河。