AI 功能验收：把准确变成可测标准

AI 功能演示得再顺，也不等于团队已经知道什么叫「做对了」。一句「回答要准确」，既不能指导测试，也无法判断泄露隐私、查错订单或越权退款是否应该阻止上线。

作者借一个小型网店客服助手，提出了一套验收设计：先拆任务，再约定可观察的结果，用测试案例和权限控制确定发布边界。它值得参考，但要先说明：这是示例方案，没有已部署产品的实测结果，也没有模型跑分。

同一个聊天框，为什么要拆成三种需求

顾客询问退货政策、查询订单状态、申请退款，看起来都在和客服聊天，背后需要的能力却不同。

回答退货政策，可以依据经过批准的文档；查询订单状态，需要当前订单数据，还得确认提问者有权访问；执行退款会改变业务状态，可能必须经过单独的审批流程。

验收标准应该跟着任务走。政策回答要检查依据是否有效，订单查询要检查身份和数据是否匹配，退款则要检查执行权限和审批条件。不能因为入口都是聊天框，就共用一句「回答准确」作为标准。

聊天体验可以统一，验收责任必须拆开。

作者还提醒，验收条件里的名词也需要落地。「当前批准的政策」要有人负责维护，要有版本和更新流程；「转人工」要有明确去向，而且那个渠道确实有人处理。否则，助手只是把问题礼貌地送进了一个没人打开的收件箱。

先写出什么算失败，再讨论换哪个模型

作者建议先建立一组范围有限的合成案例，也就是团队编写的测试问题，用它们覆盖不同的失败方式：

• 政策文档里有明确答案的普通问题。
• 文档没有答案的问题。
• 信息含糊、需要追问的请求。
• 涉及其他顾客信息的请求。
• 旧文档与已批准更新发生冲突的问题。
• 要求忽略政策或执行未授权操作的请求。

关键顺序是：先写可接受结果和不可接受行为，再让模型生成回答。

例如，资料缺失的案例要事先约定助手该如何处理，不能看到模型给出的答案后，再临时解释它为什么「也可以」。具体采用澄清、拒绝还是转人工，要由任务要求决定，原文没有提供一套通用答案。

还应留出一部分有代表性的案例，不参与提示词调试。否则，团队可能只是在反复优化已经看过的题目，最后把熟悉测试题误当成能力提升。

原文提到了 Anthropic 的 agent 评估指南，作为评估结构和不同评分器的参考。但网店案例是作者自行设计的示例，并非该指南提供的实验结果。

一个准确率，为什么不足以决定上线

回答流畅，仍然可能泄露隐私；政策引用正确，也可能操作了错误的订单。因此，作者主张把评估拆成四个维度，分别记录：

维度	要检查的问题
回答质量	内容是否得到批准来源的支持？
任务行为	需要时是否追问，或提供转人工？
操作安全	是否遵守工具权限和审批边界？
运行表现	测试条件下的延迟、超时和供应商故障如何？

这几项不能互相抵消。某个回答再完整，也无法补偿它暴露了其他顾客的信息。

小规模案例集也不能证明整个用户群体中的精确失败率。作者建议报告通过和失败的数量、具体案例以及局限，而不是用一个漂亮百分比制造确定感。原文没有给出样本量、通过率或延迟阈值，这些仍需团队自己定义。

对于会执行操作的助手，提示词还不够。若助手无权退款，就应该由工具和授权层限制它的能力。原文借 OWASP 的 AI Agent Security 指南说明：模型行为约束与系统控制需要分开考虑。

示例方案允许助手准备结构化退款请求，再由有权限的流程校验订单、金额、资格和审批，最后执行退款。这里真正决定能否动账的，是外围系统。

发布决策也要提前写清：哪些失败阻止发布，哪些要求限制开放范围，哪些可以上线后由指定负责人跟进。同时记录模型标识、提示词版本、来源快照、工具配置和评估条件；这些输入发生实质变化时，需要重新评估。

我的判断

我认同作者把「准确」拆成任务、证据和权限的做法。它能让产品、工程和安全团队讨论同一个功能，尤其适合已经接入业务工具的助手。

但这更像一套验收框架，还不是拿来就能执行的发布规范。原文没有说明案例数量、评分规则、失败阈值，也没有展示真实流量下的表现。它没有提供与单一准确率方案的对照数据，不能据此宣称这套方法已经降低了多少风险。

相比只靠提示词禁止操作，工具层授权的边界更明确。不过它能否成立，取决于现有系统是否真的做好了身份校验和审批。模型无法替团队补齐这些基础设施。

有限的合成案例适合启动评估；它们能发现指定问题，却不足以证明真实用户的各种表达都已被覆盖。

能拿来做什么

• 给客服类 AI 功能写需求时，分别列出政策问答、订单查询和业务操作的验收条件，并标明各自依赖的数据与权限。
• 在调整提示词前，按原文的六类失败方式建立案例，提前写出预期结果，并保留部分案例用于独立检查。
• 如果 Node 服务向助手提供业务工具，把身份、订单归属和审批校验放进服务端流程，让助手提交的请求接受系统验证。
• 在发布记录中保存模型标识、提示词版本、来源快照和工具配置，同时写清阻止上线的失败类型及后续负责人员。