AI 产品的演示往往很容易让人兴奋。

准备一份干净的资料，输入一条精心调整过的 Prompt，模型很快给出一段完整回答。现场的人看到的是一次成功，于是接下来的问题自然变成：什么时候能上线？

可 PoC 和产品回答的不是同一个问题。PoC 证明的是，在选定输入、允许调试和可以重试的条件下，模型有机会完成任务；上线要证明的则是，面对表达不同、信息不全、甚至超出预期的真实请求，整个系统仍能把结果稳定交付给用户。

Anthropic 在一篇关于 Agent 评测的官方文章里，用两个指标解释这种差别。pass@k 关心多次尝试中能否至少成功一次，pass^k 关心多次尝试是否每一次都成功。假设单次成功率是 75%，连续三次全部成功的概率只有大约 42%。这个例子不是某个产品的真实成绩，却很准确地说明了为什么“一次演示成功”不能直接等同于“用户可以稳定使用”。

模型的不确定性不会在上线那一刻消失。AI 产品经理需要做的，是把这种不确定性拆成可以选择的场景、可以执行的评测、可以阻断的门槛、可以恢复的失败，以及可以观察的业务结果。

一、先判断任务值不值得交给 AI

AI 项目经常从模型开始：选哪一家、上下文多长、要不要 RAG、是否需要 Agent。可这些问题都排在另一个判断之后——用户的任务是否真的适合由模型参与。

大模型擅长处理自然语言、非结构化信息和存在多种合理答案的任务。它可以总结会议、改写文案、从长文中提取线索，也可以根据环境反馈选择下一步。但如果输入和输出都能被明确枚举，普通规则通常更便宜，也更稳定。用模型判断一个固定状态码，或者让 Agent 代替一条确定的数据库查询，都可能是在用更复杂的方式解决已经很清楚的问题。

判断场景时，可以先问四个问题。

  1. 这个任务是否需要理解模糊信息？ 如果只需匹配确定规则，优先使用传统方法；如果需要综合语义、上下文或多种表达，模型才有明显价值。
  2. 结果能不能被验证？ 代码可以运行测试，订单可以查询最终状态，知识问答可以检查引用。结果越容易验证，系统越有机会及时发现模型偏差。
  3. 错误会造成什么后果？ 一段营销文案不合适可以重写，错误退款、公开发布或删除数据却可能造成真实损失。
  4. 操作是否容易撤回？ 即使错误概率相同，可撤销的草稿和不可逆的付款也不应该获得相同权限。

这四个问题会导向不同的产品形态。固定、低变化的任务可以继续使用规则；开放但低风险的任务适合让 AI 提供草稿，由用户决定是否采用；需要调用工具但影响较大的任务，可以让 AI 准备方案，在执行前获得确认；只有目标清楚、结果可验证、权限有边界的开放任务，才适合逐步提高自主程度。

Anthropic 在 Building effective agents 中建议从尽可能简单的方案开始，只有当更复杂的结构能够带来可测量的改善时，再从单次调用增加工作流或 Agent。原因很直接：自主性提高以后，延迟、成本和错误传播的空间也会一起增加。

所以，场景选择不是给需求贴一个“适合 AI”的标签。它是在决定模型负责哪一段、确定性系统负责哪一段、用户在哪些位置仍然保留决定权。

二、写 Prompt 之前，先写清任务契约

场景确定以后，团队很容易直接进入 Prompt 调试。输入一批样例，调整系统提示词，看回答有没有变好。但如果“完成任务”还没有被定义，Prompt 越调越长，团队也未必知道产品是否更接近上线。

更有效的起点，是先写一份任务契约。它至少要说清五件事：谁在什么场景下使用，系统能够读取哪些输入，应该交付什么结果，哪些决定不能替用户做，以及做不下去时如何结束。

以企业知识问答为例，“准确回答员工问题”很难直接验收。一份可执行的任务契约会继续说明：回答只能使用哪些资料；关键事实是否需要引用；资料不足时应该说明缺口还是允许调用公开信息；涉及薪酬、法律或权限的问题是否需要转交；用户最终拿到的是参考答案，还是可以直接执行的业务结论。

这些约定会直接改变产品方案。要求引用，就要让检索结果和回答建立可追踪关系；不允许使用外部知识，就要限制来源范围；资料不足时必须停止，就不能让模型靠语言流畅度把空白补满；需要转交人工，就要提前设计队列、上下文和状态，而不是在错误发生后临时贴一个联系方式。

任务契约也能帮助团队区分问题属于哪一层。回答语气不合适，可能通过 Prompt 和示例调整；资料缺失，需要补数据或检索；算错价格，应该调用确定性工具；越权执行，则要修改权限和确认机制。把所有失败都当成 Prompt 问题，只会让提示词承担它解决不了的责任。

三、评估集不是上线前的考试，而是产品定义

传统软件可以检查一个按钮点击后是否进入固定状态。生成式 AI 面对相同输入，措辞和路径都可能变化，因此评测不能要求每次输出完全一样，但必须检查关键行为是否稳定。

OpenAI 的评测最佳实践建议尽早采用评测驱动的开发方式，使用贴近真实任务的测试，记录开发和生产中的输入输出，在适合的地方自动评分，并用人的判断校准自动评测。它也特别提醒，不要只依赖宽泛的学术指标，或用“感觉效果不错”代替评估。

一条评测用例至少包含三部分：给系统什么输入，希望它采取什么关键行为，以及用什么标准判断通过。它不一定要有唯一标准答案。例如测试会议总结时，可以要求必须覆盖三个决定、不得编造负责人、日期与原文一致；具体句子怎样组织，可以保留生成空间。

评估集需要同时覆盖三类情况。

  • 高频正常请求，用来证明产品解决了主要任务；
  • 信息缺失、表达含糊和超出范围的边缘情况，用来检查系统会不会主动澄清或拒绝；
  • 提示注入、越权要求和高风险操作等对抗情况，用来检查安全边界。

只用团队精心编写的理想样例，评估集很容易重复 PoC 的偏差。真实用户的改写、重试、放弃和人工转交，应该逐步成为新的测试用例。上线前的评估集来自任务假设，上线后的评估集则要不断吸收真实失败。

复杂工作流还要把“结果”和“过程”分开检查。一个订单 Agent 最后给出了正确物流信息，不代表过程一定可靠。团队还要检查它是否选对工具、是否传入正确订单号、有没有调用不必要的接口、是否在敏感操作前等待确认。Anthropic 将完整执行记录称为 transcript 或 trace，而 outcome 是环境里的最终状态。Agent 说“已经退款”只是输出，后台是否真的生成退款记录才是结果。

评分方式也要与任务匹配。格式、字段、状态和工具参数可以用代码确定性检查；开放回答可以用清楚的评分标准进行人工判断，或使用模型评审；模型评审适合扩大覆盖量，但需要定期与人工结果校准。主观任务只看一个自动分数，客观任务全部交给人检查，都不是合理分工。

Anthropic 还区分了能力评测和回归评测。能力评测回答“系统目前能把困难任务做到什么程度”，允许保留较多失败来推动改进；回归评测回答“过去已经做对的事情，现在是否仍然做对”，通过率应接近稳定上限。每解决一个有代表性的生产问题，就应该把它加入回归集，避免下一次改 Prompt、换模型或调整流程时又把旧问题带回来。

四、把上线标准写成几道明确的门

有了评估集，团队仍然需要回答：做到什么程度才允许上线？

这里没有一个适用于所有 AI 产品的统一正确率。文案助手偶尔生成平庸句子，用户可以快速改掉；报销、医疗建议或账户操作中的一次严重错误，可能比许多次正常结果更重要。平均分会掩盖错误的重量，因此上线门槛必须和任务风险一起定义。

可以把门槛分成五类。

门槛 需要回答的问题 可能采用的检查方式
任务质量 高频任务是否达到可用水平，关键错误是否被单独计算 任务通过率、关键字段准确率、人工评分
稳定性 同类输入重复运行时，结果能否持续达标 多次运行、回归集、失败分布
体验 用户要等多久，能否理解状态，失败后是否知道怎么继续 首次响应时间、任务完成时间、放弃率
成本 完成一次有效任务花多少钱，规模扩大后是否可承受 单次调用成本、每个成功任务成本、人工介入成本
风险 系统是否越权、泄露信息或执行不可逆操作 权限测试、对抗用例、确认与审计记录

NIST AI 风险管理框架把可信要求放在 AI 产品的设计、开发、使用和评估全过程中。沿着这个思路，上线门槛不应只是发布前的一次审查，而应在产品变化和真实风险出现后继续更新。

每类门槛还要区分“必须通过”和“可以观察”。例如页面文案评分略低，可以进入小范围测试；一条能够绕过付款确认的路径，则应直接阻断发布。上线清单不是把所有指标都追到满分，而是提前说清哪些问题可以带着观察，哪些问题出现一次也不能接受。

成本也不能只看 Token 单价。一次便宜调用如果经常失败，需要用户反复重试，最终的成功任务成本可能更高。更强模型单次更贵，但如果能减少工具误用和人工介入，总成本反而可能下降。产品经理应该比较的是完成用户任务的代价，而不是孤立的一次模型请求。

当这几道门有了明确判定方式，PoC 才开始变成产品。团队不再只展示能力上限，也开始为用户每天会遇到的体验下限负责。

五、把失败当成正常状态，而不是意外弹窗

AI 系统一定会遇到没见过的表达、不可用的工具、冲突的资料和超出权限的动作。如果产品只设计成功路径，用户看到的往往是模型继续猜、反复重试，或者在已经失败后仍然给出一段听起来完整的回答。

失败路径可以先分成三种处理。

第一种是补信息。目标、对象或必要参数缺失时，系统暂停执行，用尽量少的问题消除会改变结果的歧义。

第二种是缩小任务。完整任务无法可靠完成时，可以退回到风险更低的部分，例如只生成草稿、不自动发布，只给候选方案、不代替用户做决定，或者展示找到的资料而不强行合成确定答案。

第三种是停止并转交。工具连续失败、请求超出能力范围，或动作敏感且不可逆时，系统应保留已经获得的上下文，交还用户或人工处理，而不是把“继续尝试”当成默认答案。

OpenAI 的 A practical guide to building agents把人工介入的典型触发条件概括为两类：系统超过预设的失败或重试阈值，以及即将执行高风险动作。前者避免 Agent 在同一个问题上无限循环，后者确保付款、退款、取消订单等敏感决定在可靠性不足时仍由人把关。

系统也不应该只依赖模型自己声明“我有信心”。更可靠的信号来自可检查的状态：必要字段是否齐全，检索是否找到直接证据，工具是否返回成功，输出是否通过规则检查，动作是否可逆，重试次数是否超过限制。模型判断可以成为其中一个信号，但不能独自决定是否越过高风险门槛。

对用户来说，失败需要被翻译成下一步。他应该知道系统缺少什么、哪些工作已经完成、继续重试会发生什么，以及能否回到原来的状态。人工兜底也不能只是一个“联系客服”按钮；如果前面的材料和执行记录无法一起转交，用户仍要从头解释一遍，兜底只是把成本转移给了他。

六、先守住一个场景，再决定是否扩大

产品通过内部评测后，也不适合立刻覆盖所有用户和任务。更稳妥的方式是先选择一个边界清楚、价值明确、能够观察结果的场景，以有限用户或有限权限上线。

小范围上线不是延长演示，而是开始收集评估集里没有的真实分布。除了主动点赞和评分，还可以观察用户是否重复生成、是否大幅修改结果、是否频繁撤销、在哪一步离开、什么时候要求人工帮助。对于带工具的系统，还要记录工具选择、参数、执行结果、重试次数和最终环境状态。

这些信号需要回到用户任务。生成次数上升，可能代表产品受欢迎，也可能代表第一次结果总是不合格；对话轮数增加，可能说明用户在深入探索，也可能说明系统一直没有理解。只有把行为与任务是否完成放在一起看，数字才有产品含义。

每次出现代表性失败，可以按照同一条路径处理：保存输入和执行记录，判断问题来自任务定义、数据、Prompt、模型、工具还是权限，把案例加入对应评估集，修改后做回归测试，再决定是否扩大流量。Anthropic 在 Agent 评测文章中也把评测与生产监控、A/B 测试和用户研究放在同一个持续改进过程里，而不是把评测当作上线前一次性的验收。

扩展新场景时，同样要重新经过场景判断和上线门槛。客服 Agent 能查物流，不代表它已经适合自动退款；内容工具能写初稿，也不代表它可以直接发布。两个任务可能共用同一个模型，却有完全不同的验证方式、错误成本和权限要求。

模型升级也不能绕过这条流程。更强模型可能提高能力，但也可能改变措辞、工具选择和延迟成本。有稳定评估集的团队，可以较快判断新模型在哪些任务上变好、哪些行为发生回退；没有评估集时，每次升级都只能重新靠人试一遍。

结语：从“模型会不会”走到“产品能不能交付”

理解 Token、上下文、RAG、幻觉和 Agent 当然有用。它们能帮助产品经理判断问题可能发生在哪里，也能减少与研发沟通时的误解。但这些概念只有进入场景、评估、权限、成本和恢复设计后，才会变成产品决策。

一项 AI 能力走向上线，大致会留下五份可以检查的产物：场景选择表说明为什么使用 AI，任务契约定义系统承诺什么，评估集说明怎样判断好坏，风险与恢复方案规定什么时候停下来，上线看板持续回答用户是否真的完成了任务。

这五份产物不一定要做成厚重文档。对一个小功能，它们可能只是一页说明和几十条测试；对会调用工具、改变业务状态的 Agent，它们则需要进入权限系统、状态机、监控和审核流程。形式可以轻，关键决定不能缺席。

AI 产品经理需要建立的技术判断，最后不是背出某个模型有多少参数，而是能够回答一组更具体的问题：这个任务为什么值得使用模型，怎样证明结果合格，哪些错误可以容忍，哪些动作必须停下，以及什么证据足以支持下一步扩量。

PoC 展示一次可能，产品负责长期交付。把两者连接起来的，正是这些围绕不确定性做出的明确选择。

官方资料

资料核验日期：2026 年 9 月 3 日。

  1. OpenAI：Evaluation best practices
  2. OpenAI：A practical guide to building agents
  3. Anthropic：Building effective agents
  4. Anthropic：Demystifying evals for AI agents
  5. NIST：AI Risk Management Framework