员工依赖 AI 功能前，应如何测试？

原型能顺利回答几个问题。现在有人想让员工开始使用它。在答应之前，请供应商演示它如何处理员工实际会交给它的工作，也包括它无法回答的问题。

你可以把讨论落到具体事情上：选定一项工作，约定什么结果才算可用，再请熟悉这项工作的人检查一组真实案例的结果。这样，你就有依据作出发布决定。

先选一项工作，并划清功能边界

设想一个功能，它根据获准使用的内部指引起草答案，员工在使用前会先阅读草稿。这是假设情境，但能帮助你看清验收标准。

写清楚这个功能可以使用哪些资料、面向哪些人，以及会产出什么。在这个例子中，它根据该员工有权查看的指引起草答案。发送答案或修改记录，则是需要单独测试的其他功能。

接着约定什么结果才算可用。草稿应回答问题、符合已批准的资料、保留会影响结论的条件，并指出依据来自哪份资料。如果资料无法回答问题，草稿就应该说明这一点。明确承认资料缺失，也可以算是合格结果。

编造规则、漏掉会改变答案的条件，或自信地引用了错误指引，都会让草稿无法使用。请在检查结果前先说清这些区别，否则，读起来流畅的答案很容易让人信服。

测试人们实际会问的问题

对于起草答案的例子，至少要包括以下几种情况：

• 普通问题。 指引里有明确答案。草稿是否准确使用了答案，并指出正确的来源？
• 含糊的问题。 可能适用两种流程。功能会先询问作出选择所需的信息，还是悄悄替人选一种？
• 资料缺失。 已批准的指引没有涉及这个请求。功能会说明缺口，并把问题留给员工处理吗？

这些只是起点。测试集应覆盖实际工作的多种情况：常见请求、信息不全、措辞棘手的问题，以及出错后果严重的情况。使用获准的代表性数据或经过安全处理的案例，不要把机密记录输入未经批准的服务。

Microsoft 的评估指南建议使用有代表性的互动案例和有挑战性的情形。对管理者来说，关键是确认这些案例是否涵盖员工需要帮助的情况。通用模型基准无法替你的应用回答这个问题。

请熟悉这项工作的人评判结果

请熟悉这项任务的人根据约定的标准检查答案。他们应能解释答案为什么可用、错误或无法确定。若判断存在争议，或错误后果严重，再请另一人复核。

自愿采用的 NIST 人工智能风险管理框架支持记录测试、模拟部署条件，并听取相关专家意见。它能帮助你询问测试了什么、由谁检查，但不会为你的功能提供通用的及格线。

把部分评估案例留作独立测试，不要全部用于改进功能。如果供应商针对每道测试题不断调整，你了解的只是它对这些熟悉问题的处理能力。使用独立案例，才能更好地检验它面对未专门调优的工作时会怎样表现。

自动评分有助于整理结果，但也需要核查评分是否合理。人会漏看错误，用 AI 给另一个 AI 打分也可能出错。请查看实际答案及评分理由。

别只看平均分，也要检查失误

总分有助于比较不同版本。除此之外，还要按重要情况和错误类型查看结果。普通问题可能回答得不错，但遇到缺少来源的问题时，却反复编造答案。平均分会掩盖你必须针对特定用途作出的决定。

记录发生了哪些失误、后果有多严重，以及哪些地方仍不确定。判断哪些问题会阻止预定用途。可接受的错误程度取决于任务本身和出错后的影响，没有一个百分比适用于每家企业。

如果功能还会执行操作，就要检查连接系统里实际发生了什么。例如，它声称已更新一条记录时，请检查目标记录是否确实改成了预期值。Anthropic 于 2026 年 1 月发布的 AI 智能体评估说明解释了软件执行操作时为何要关注最终结果。它发出“任务已完成”的消息，并不能证明任务真的成功。

输出质量只是验收的一部分。安全、权限、隐私和其余工作流程，都需要各自适当的检查。答案得分高，并不能证明这些环节也运作正常。

明确具体的发布决定

请供应商提供一份简要记录，写明任务和边界、测试案例及预期结果、由谁审核、重要失误、尚存的不确定性，以及测试所用版本。如果模型、指令、来源资料或连接的软件会影响结果，也应一并记录。约定这些内容变更后，哪些检查必须重做。

这些证据应能支持以下三种决定之一：

• 批准有限范围使用。 结果支持在明确边界内执行特定任务。员工知道何时需要复核、停止使用，或退回原有流程。
• 修复后重测。 先修正已发现的具体失误。约定哪些案例要重跑，以及用哪些独立案例检查修复是否有效。
• 暂缓发布。 重要失误仍未解决，或现有证据不足以支持计划中的用途。

有限范围的试点可以从实际工作中补充证据。请事先明确参与人员、任务、权限、复核安排和备用流程，并指定负责人跟踪问题，必要时暂停试点。小规模试点结果良好，只能支持有限范围内的使用，无法证明功能普遍可靠。

验收讨论结束时，你应该清楚员工可以在哪些方面依赖这个功能、哪些地方仍需人来判断，以及什么情况会触发再次测试。如果你正在规划 定制业务应用中的 AI 功能，我们可以讨论它要完成的工作，以及验收前需要哪些证据。