团队想自动分配客服工单。演示效果不错，但遇到描述模糊、情况紧急或同时涉及两个团队的工单时，系统会怎么做？光看演示无法判断。
可以先做影子试跑：仍由原流程负责处理，自动化只记录自己本来会怎么做。对比之后，再决定是否给它执行权限。
先观察一种决策
从一个明确的输出开始，例如推荐工单队列。记录决策时能看到的信息、系统建议、是否放弃判断，以及团队实际选择的队列。不要让系统先看到最终处理结果，再把它答对算作预测成功。
只使用团队有权处理的数据。真实输入不适合进入测试环境时，就改用经过批准、去除不必要信息的样本。影子模式不是天然安全的：是否阻止正式写入、如何处理日志，都需要单独设计。
让试跑无法误触正式操作
需要访问数据时使用只读权限，或把事件发到独立测试环境。发送消息、修改记录和触发后续任务，应在模型之外明确禁用。提示词写着“仅模拟”，不等于系统失去了执行能力。
以工单分流为例，试跑建议应该写到审核日志，而不是正式工单的分配字段。查看结果的人也应能清楚区分两者。
重点复核不一致的情况
建议不同，可能是自动化判断错误，也可能是人工做了合理的例外处理，或原有分配标准本身不一致。让审核人先给差异分类，再统计结果。
例如，普通账单问题被送到通用队列，可能只是多耽误几分钟；紧急账号访问问题被漏掉，后果可能更严重。两者应分别记录。系统不作建议的情况也要计入，否则容易高估覆盖率。
约定什么结果可以进入小范围上线
- 明确哪些情况允许自动执行。
- 约定可接受的错误水平，以及哪些错误会阻止上线。
- 给异常队列安排负责人。
- 先小范围启用，并保留人工替代方案。
- 开始正式执行后，再次检查实际结果。
影子试跑的目的不是单独证明系统已经准备好，而是弄清哪些判断足够稳定，哪些还应留给人。
下一步可查看 AI 工作流交接检查单，或联系我们讨论试点。
