一个工程师花了一个下午钻研一个问题：智能体 (agent) 能否根据合同条款核对客户的发票？他们编写了一个简单的提示词，在五份真实发票上运行，结果三份是正确的。另外两份的错误方式他们还没完全搞清楚——于是他们关上电脑，继续做别的事。在第二天早上的站会上，他们说：“是的，发票核对基本上能用了。”房间里的 PM 记下了这一点。两周后，它成了 Q3 路线图上的一个项目。一个月后，一位销售代表在续约电话中向一家大客户承诺了这项功能。
没有人撒谎。没有人孤立地做出错误决定。但团队现在已经在合同上承诺了一种行为，而这种行为的评估集 (eval set) 并不存在，其失败模式从未被记录，其可靠性预算是由一位看了演示并将其解读为正式合同的总监设定的。这是 AI 功能获取范围 (scope) 最常见的方式：不是通过规划会议，而是通过一个从未被明确提升地位的能力探索 (capability probe)。
行业对这种下游症状有一个称呼——“POC 炼狱” (POC purgatory)，即 70% 到 80% 的 AI 项目在可运行的沙盒和可交付的产品之间停滞不前的状态。但“炼狱”是一个错误的比喻，因为它暗示项目被困住了。它们并没有被困住。它们在移动——在有人检查它们是否准备好之前，它们就被承诺了，现在团队正试图将可靠性强行填补到一个承诺中。
探索是如何演变成规范的
探索是健康的。工程师应该探索模型能力的边界，“让我们看看智能体是否能处理这个”正是正确的直觉。问题不在于探索。问题在于，从外部看，探索和承诺看起来是一样的，而且在大多数团队的工作流程中，没有一个时刻能将前者明确地转化为后者。
观察这种演变是如何发生的。它经过三次交接，每一次交接都会以一种可以预见的方向发生信息损耗。
工程师到站会。 运行了五次试验并看到三次成功的工程师有一个精确的思想模型：“在极小的、不具代表性的样本上达到 60% 的成功率，还有两种我尚未命名的失败模式。”而从他们口中说出来的是“基本上能用了”。这并不是不诚实——这是压缩。“基本上能用”是对“我很惊讶它能做得这么好”的一个合理总结。但这种不确定性、样本量和未被审视的失败在压缩过程中消失了。它们本是发现中最重要的部分，却也是最先被丢弃的部分。
站会到路线图。 PM 听到“基本上能用了”，然后履行职责，即将能力转化为计划。“能用”加上“客户想要这个”等于“在 Q3 交付”。PM 投并不是在鲁莽行事；他们是根据得到的信息进行操作。而他们得到的信息在两句话之前就被剥离了误差范围。
路线图到客户。 销售代表看到了路线图，或者看到了为支持路线图而构建的演示，然后履行你的职责，即将计划转化为收入。现在，外部各方有了一个合同层面的预期。探索已经从“我运行了五次”演变为“我们欠客户一个交代”，其间从未经过任何审核，也没人问过：实际的成功率是多少，在什么情况下成功的？
在任何阶段，都没有人逾矩。每一次交接都是一个人根据收到的输入正确地履行自己的职责。这种缺陷是结构性的——流水线中没有闸门，所以探索就像流水一样顺坡而下，直到撞上客户。
你测量到的东西并不是你承诺的东西
即便抛开交接过程中的损失，还有一个更深层次的不匹配。能力探索回答的是“这是否可能？”交付承诺回答的是“这是否可靠？”这是不同的问题，最近的可靠性研究对此直言不讳：能力和可靠性是两个独立的维度。一个能力极强的系统可能极其不可靠，而一个能力平庸的系统在狭窄的范围内可能是可靠的。测量其中一个维度几乎无法告诉你关于另一个维度的任何信息。
探索优化的是最佳情况 (best case)。工程师挑选有趣的输入，观察运行情况，在看起来不对劲时重试，并以宽容的态度阅读输出。他们回答的是“这能行吗？”——而经过论证，诚实的答案是肯定的。
生产环境问的是相反的问题：“在那些我没选的输入上、没人看守的情况下、第一次尝试时会发生什么？”那五份手动挑选的发票并不是生产流量的样本。它们是工程师觉得值得尝试的发票样本。智能体在损坏的 PDF、第二语言的合同或合同中不存在的项目上的表现——这些都没有被测量，因为测量这些并不是探索的目的。
目前处理结构化业务记录的智能体在现实的企业数据上，目标完成率通常低于 55%。一个在五个精选示例上达到 60% 的探索并不是反驳这一数字的证据，而是与之相符。探索和生产现实可以同时为真，因为它们测量的是不同的分布。
将能力测试转化为交付物，而非口头陈述
这种修正始于拒绝让“能力发现”仅作为站会中的口头陈述而存在。一次探索（probe）应当产生一个微小的、结构化的交付物——称之为能力测试（capability test）——它在表面上就明确声明自己不是一项功能承诺。
它不需要很繁琐。只需记录以下五个字段：
- 设置（Setup）。 具体运行了什么——包括提示词（prompt）、模型、工具和输入集。“2026 年 5 月 Acme 账户的五张发票。”
- 观测到的成功率（Observed success rate）。 真实样本上的真实数字，并附带样本量。“5 次中成功 3 次。”而不是“基本可行”。
- 失败模式（Failure modes）。 失败的具体表现及其命名。“误读了多币种总额；幻觉出了不存在的合同条款。”如果你没有对其进行特征化，这本身就是一个发现：“2 次失败，未调查根本原因。”
- 分布差异（Distribution gap）。 测试输入与生产环境流量的差异。“手工挑选的清晰 PDF；生产环境包含扫描件和非英语合同，未经测试。”
- 非承诺姿态（Non-commitment posture）。 一行明确的声明：“这是可行性探索。它不是对生产环境可靠性的估算，也不作为路线图承诺的依据。”
最后一个字段起到了至关重要的作用。它将误差范围直接写入了文档中，使得它们在下一次交付中不会被压缩掉。当一名 PM 阅读能力测试时，他们看到的是“5 次中成功 3 次，两次未调查的失败，未在真实流量中测试”，而不是听到“它基本可行”。交付物在交接过程中的存活能力是口头陈述无法比拟的。
这样做成本很低。在一下午的探索之后，编写能力测试只需要 15 分钟。而跳过它的代价，则是花费一个季度去发布一个团队从未真正了解其成功率的功能。
在探索与路线图之间设置门槛
仅有交付物是不够的，因为生动的演示（Demo）仍然可能盖过冷静的文档。你还需要一个明确的晋升步骤：将一项能力从“探索”移动到“路线图”需要通过一个关卡（Gate），并且该关卡要有负责人。
阶段门控（Stage-gating）并不是什么新主意——它是产品工程中的标准做法，评审关卡是一个预设的决策点，问的是“这应该继续、转型还是停止？”，而不是“工作完成了吗？”。AI 功能尤其需要这个关卡，因为从演示到承诺的飞跃是如此容易且悄无声息。晋升一项能力的关卡应该要求满足三件事：
-
评估基准（An eval baseline）。 不是五个精心挑选的例子，而是从代表生产环境的输入中提取的留出集（held-out set），并带有测得的通过率。这就是“我们认为它可行”与“这是具体数字”之间的区别。如果评估集尚不存在，那么建立它就是下一步工作，在该项工作完成之前，该能力不得进入路线图。
-
工程团队签署的可靠性承诺。 有人陈述目标——“在评估集上达到 92%，且不会产生无限制的财务影响失败”——并且工程团队同意该目标在拟定的时间表内是可以实现的。拥有可靠性预算的团队才是设定预算的团队。总监对演示的解读不能替代这一点。
-
特征化的失败面（A characterized failure surface）。 已知的失败模式、触发时的表现以及影响范围。一个错误率为 8% 的对账 Agent 如果由人工审核标记案例是没问题的，但如果它自动过账到总账则是危险的。关卡必须审视失败处理机制，而不仅仅是成功率。
通过这三项审核的能力才是真正的路线图项目，并拥有诚实的可靠性目标。无法通过审核的能力并不会被永久封杀——它会被退回，转为受评估支持的正式调查。无论哪种方式，演示都不再是决定性的证据。
建立词汇表，并盯紧侧门
两个配套习惯可以防止关卡被绕过。
首先是建立一套共同的词汇表，使这种区别在日常对话中不容忽视。产品和工程团队需要用不同的词来表达“Agent 成功做到过一次”和“Agent 能够可靠地做到这一点”。当这些表达塌缩成一个词“可行”时，关卡在语言层面上就已经失效了——因为“可行”这个词正是通过交付链路传播的内容。一些团队采用了明确的措辞：一项能力是“已演示”（demonstrated，指它发生过）或“已承诺”（committed，指它拥有评估基准和签署的可靠性目标），路线图上不允许出现仅处于“已演示”阶段的内容。具体的词汇并不重要，重要的是团队达成共识：它们不是同义词。
其次是盯紧侧门。最危险的路径不是从工程师到 PM，而是销售或高管通过走廊演示发现了一项能力，并在产品团队看到之前就向客户做出了承诺。晋升关卡必须为此设有升级路径：当有人对尚未晋升的能力做出外部承诺时，这应被视为一次事故，并在承诺最终定稿前转发给关卡的负责人。这不是为了惩罚任何人，而是为了在还有余地重置预期时，追溯性地执行关卡流程。
门控即功能
AI 团队发布那些甚至无法通过自身评估套件 (eval suite) 的功能，其原因几乎从不是因为评估套件出了错。而是因为在做出承诺之前，没有人去运行评估套件 —— 因为流程中没有哪一个环节强制要求这样做。这种承诺往往发生在站会、走廊交谈、续约电话中，或者在乐观的人们传递好消息的日常沟通流里。
你无法通过要求个人更加细心来解决这个问题。链条上的每个人其实都很细心。解决之道在于增加缺失的结构：一套自带误差范围 (error bars) 的能力测试，以及一个任何路线图项目 (roadmap item) 都无法绕过的晋级门控 (promotion gate)。这种“从可行性到承诺”的门控缺失，并不是围绕 Bug 产生的流程漏洞，它本身 就是 那个 Bug。
建立起这个门控，“智能体 (agent) 能做 X 吗？”就会重新变成一个健康的问题 —— 你的团队可以自由地探索它，正是因为这种探索不再意味着你已经默许了要将其发布。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
