机器人回复了“已处理”，页面上也没有报错，工单却未必完成。用户请求的是把某个问题解决，回复只是执行过程中的一个事件。若完成判定只检查最后一条消息或某个按钮是否点过，系统很容易把动作结束当成目标达成。

完成规则从用户目标写起

以“修正一条客户地址并同步到指定系统”为示意：修改本地字段成功、同步请求被接受、目标系统已读取到新地址，分别对应不同事实。若工单约定的结果包括目标系统可见，就不能在请求被接受时提前关闭。

验收条件应在执行前明确，并绑定对象身份、目标值和适用范围。对象错了，即使修改接口返回成功也不满足工单；只修正部分字段，也不能因为主步骤成功就忽略剩余要求。

给每个条件找一条可靠证据

可以把完成判断写成很短的验收记录：

这里的证据要能追到来源和时间。模型自己生成的一句“已同步”，不能作为同步事实的独立证据。旧截图也不能证明当前状态，除非验收规则明确接受那个时点的结果。

图中“已完成”声明停在核对页之外，验收页保留已证实和待核对的条件。篮球画面借终场结果核查作比喻，实际工单仍由事先约定的业务规则验收，不以图片中的比赛规则代替。

未知应保留为未知

外部调用超时后，接口没有给出结果，适合写“执行结果待确认”。把它算成失败会诱发重试，把它算成成功又会提前关闭工单。系统应保留原操作身份，先查询或人工核对，再决定是否补录或重做。

工单允许部分交付时，应区分已完成部分和未完成部分，明确剩余责任。人工终止、用户取消和成功关闭也需要不同状态；它们都可能让流程停止，却不能共享一枚成功标记。

最后再核对一次验收规则本身是否被擅自降低：如果原目标包含通知接收人，不能因为发送接口难查就改成“已生成通知内容”。规则变更需要有授权和记录。完成判定检查的是既定目标及其证据，过程热闹、回复流畅都不能补上缺失的业务结果。