演示中的精彩回答，并不能说明 AI 功能在日常工作中会如何表现。有用的试验需要具体任务、有代表性的输入，以及能够判断结果的人。以一个客服流程为假设示例：每次对话后，客服人员为下一位接手者撰写交接摘要。这个任务有明确的输入和读者，同时也带来关于准确性、上下文遗漏及审核成本的实际问题。
本页内容
选择 AI 前先描述当前任务
观察客服人员目前如何准备交接：他们需要查找哪些细节？下一位客服如何使用摘要？定义能够支持下一步工作的输出，例如客户的问题、已经尝试的措施、尚未解决的疑问和约定的后续行动。记录项目应解决的困难。如果根本问题是源信息不一致，改进表单或工作流程也可能是答案的一部分。应使用同一类任务，将 AI 草稿与现有方法及更简单的替代方案进行比较。
- 明确谁制作输出、谁使用输出。
- 记录完成任务所需的信息。
- 明确试验要研究的问题。
为 AI 划定职责边界
在这个例子中，可以让功能生成内部摘要草稿，由客服人员检查和编辑。向客户发送消息或关闭工单属于另外的能力，需要单独决策。应规定功能可以访问哪些对话与账户信息，以及如何遵循用户权限。还应确定源信息不完整或功能不可用时的处理方式。提供清晰的人工操作入口，可以让流程继续运行，也让团队能够处理试验未覆盖的情况。
按照书面标准评估示例
建立评审样本集，涵盖常规对话、模糊请求、意向变化和细节缺失，并保留一部分未用于调整功能的独立样本。举例来说，客户提出退款要求，但客服只承诺进行调查。有用的摘要必须保留这一区别；写成“退款已批准”就是凭空增加承诺。请评审者记录哪些内容正确、遗漏或缺乏依据，而不只是给出整体印象。
- 必要事实：摘要是否保留了问题和实际的下一步行动？
- 无依据的说法：是否编造了行动、承诺或客户细节？
- 整项任务的工作量：客服需要多少检查和改写？
- 输入不完整：是否指出缺口，而不是靠猜测补齐？
设定发布条件与反馈机制
约定哪些错误会阻止发布、用户需要了解哪些剩余限制，以及由谁审核评估依据。在客服示例中，团队可以要求：保存摘要前，逐项人工确认所有后续行动承诺。这是一项建议的流程规则，并不证明所有错误都已消除。应让草稿便于与原文比较、编辑或拒绝。发布后，检查修改记录，并在功能发生变化时重新运行约定样本。评估应覆盖整个工作流程，包括人工审核带来的额外工作。