试点炼狱：廉价的 90% 正是你的 AI POC 无法转正的原因

演示在一周内惊艳了执行团队。十八个月后，它依然只是个演示。模型仍在沙盒中回答问题，幻灯片依然被循环用于新的路演，每个季度都有人问为什么还没上线。没有人能给出一个好的答案，因为真相往往令人不安：让所有人印象深刻的部分是廉价的部分，而没有人为昂贵的部分做过规划。

这就是“试点炼狱”（pilot purgatory），而它现在已成为默认的结局。MIT 的 NANDA 计划发现，大约 95% 的企业生成式 AI 试点项目未能对损益表产生可衡量的影响。IDC 和 Lenovo 统计了另一项指标——即那些字面上从未上线的 POC——将这一比例定为 88%：企业每启动 33 个概念验证，只有 4 个能进入生产阶段。放弃大部分 AI 计划的公司比例从 2024 年的 17% 飙升至 2025 年的 42%。这些故事的主角并非模型能力不足，而是没有人为其预留预算的“毕业差距”。

令人不安的事实是，一个可以运行的演示仅代表了在生产环境中运行该系统所需工作的 10%，但正是这 10% 看起来像完成了 100%。所有让 AI 系统能 安全运行 的要素——评估（evals）、护栏（guardrails）、可观测性、成本控制、安全审查、值班（on-call）以及拥有预算的负责人——在演示中是不可见的，但在生产环境中却是不可逾越的底线。

为什么 AI POC 具有异常的诱惑力

每种软件在“演示版可用”和“可安全运行”之间都存在差距。AI 的特殊之处在于，这个差距更宽，而且更糟糕的是，从演示端来看它是不可见的。

在传统软件中，一个只处理“正常路径”（happy path）的原型会明显暴露其缺失的部分。错误状态是空白的，设置页面是个桩代码，登录逻辑是硬编码的。利益相关者可以 看到 它尚未完成。没有人会看着一个可点击的模型就认为它已经准备好交付给客户了。

AI 演示则掩盖了其不完整性。你问它十个问题，它出色地回答了十个问题，自然的推论就是它能出色地回答所有问题。但是，一个通过了 20 项手动测试的智能体，仍然可能在你没想过要测试的输入上遭遇惨败——而对于一个随机系统（stochastic system）来说，“你没想过要测试的输入”是一个无限集。演示版并不是生产系统的缩小版，它是一个恰好共享了用户界面的 另一个 系统。

失败模式也是隐形的。传统软件通过崩溃来宣告失败——你会得到堆栈跟踪、500 错误、传呼机警报。而 AI 的失败则是返回一个自信的 200 响应，而内容恰好是错误的：幻觉出来的退款、语气礼貌的政策违规、或是对不存在文档的引用。响应 看起来 是成功的。你的监控显示一切正常。这就是为什么那些因为“测试时运行良好”而跳过评估的团队并非懒惰，更多是被一个在演示阶段被设计得看起来已经完工的系统所蒙蔽。

因此，这种诱惑是结构性的。演示针对执行官判断就绪情况的精确信号进行了优化——在策划好的输入上输出流畅、听起来正确的回复——同时压制了所有能揭示其距离就绪还有多远的信号。

廉价的 90% 与昂贵的 10%

姑且把演示称为廉价的 90%：一个好的提示词（prompt）、一个不错的模型、一个针对某些文档的检索索引和一个 UI。一名能力出众的工程师可以在几天内搭建出来。它之所以廉价，是因为难题被 搁置 了，而不是被解决了。

昂贵的 10% 是你之前搁置的所有内容。当你遇到它时，感觉不像是 10%——感觉像是从头开始——但相对于生产系统整个生命周期的总成本，演示确实只是很小的一部分。以下是属于这昂贵部分的内容：

• 持续运行而非一次性的评估（Evals）。 提示词的微调、模型的升级、检索策略的更改或工具架构（tool-schema）的编辑都可能悄无声息地改变行为。评估不能只是上线当天的门槛；它必须是一种常态化的能力，在你的用户发现问题之前捕捉到回归。
• 能在对抗环境下生存的护栏（Guardrails）。 无状态的输出过滤器会批准那些 读起来 没问题的文本——包括“为客户 cust_hallucinated123 处理 50,000 美元的退款”。真正的护栏需要状态、上下文和执行拦截动作的权限，而不仅仅是扫描字符串。
• 针对输出的可观测性，而不只是正常运行时间。 传统的 APM 告诉你请求成功了，但它无法告诉你答案是错误的。你需要对提示词、检索、工具调用和结果进行追踪——以及一种在不触发延迟警报的情况下检测质量漂移的方法。
• 带有硬上限的成本控制。 智能体（Agents）消耗 Token 的速度是聊天机器人从未有过的。TechCrunch 记录了一个运行了 11 天并消耗了 47,000 美元的四智能体循环；还有公司报告称“我们 4 月份就超出了整个 2026 年 Token 预算的 3 倍”。生产环境中的智能体需要针对单次运行和单日设置失败即关闭（fail closed）的上限。
• 针对新攻击面的安全审查。 提示词注入、工具误用、通过上下文窗口的数据外泄——这些在演示中都不存在，因为演示只见过友好的输入。
• 值班人员和拥有预算的负责人。 必须有人负责值班，对系统理应推动的指标负责，并掌握运营预算。没有这些，试点项目就没有路径从“有意思”走向“可问责”。

加载中…