AI客服上线前先测工单状态流转

AI 能把工单回复写得像模像样，不代表它能安全地关闭工单、重新打开请求，或者调用另一个系统。原文给出的判断很明确：只要 AI 能改变工单状态，就该按业务工作流验收，重点检查权限、并发、重试和 SLA 计时。

这篇值得读的地方，是把「AI 客服是否好用」拆成了可检查的工程问题。不过，标题里的 16 个案例是合成测试设计，不是生产实验；提供的正文也没有列出完整案例表，不能直接当成现成测试集。

先决定 AI 能做什么，再讨论它有多聪明

作者建议，第一阶段可以只开放读取和起草：查找批准使用的知识、总结工单、建议分类、准备回复。创建工单、修改优先级、解决、重开、修改身份或访问权限、触发下游系统，则应该分别授权。

这里需要一份能力清单。每项操作分别属于 Observe、Suggest、Draft、Commit with confirmation、Narrow automation 或 Prohibited，对应只读、建议、草稿、确认后执行、限定规则下自动执行，以及禁止执行。

这些层级衡量的是权限，不是模型水平。

模型可能知道如何调用 API，但执行身份是否有权调用、当前工单是否允许变更，应该由工作流和服务端判断。提示词里写「禁止重置账号」，无法替代服务账号的 API scope 限制。作者还建议撤销测试凭证，确认系统会停止执行，而不会换用个人账号或管理员凭证继续操作。

接着要约定状态规则。原文举出的状态包括 new、triaged、in_progress、waiting_for_requester、resolved、closed。名称可以不同，但团队必须说清：谁能转换状态，哪些转换影响服务级别协议（SLA）的计时，解决后的回复应该重开原单还是创建关联新单。

如果团队自己都没达成一致，模型也无法替大家作决定。

真正危险的是旧上下文、重复事件和模糊审批

作者把验收重点放在「不变量」上，也就是事件迟到、重复执行或多人同时操作时，仍然必须成立的规则。

例如，自动账号添加评论，不能让关闭的工单悄悄恢复处理；同一个来源事件，最多创建一个下游请求；人批准的动作，必须与实际执行的动作一致。

这几条对应着常见的工程故障：

• AI 读取 version 14 后，人工把工单改到 version 15。提交时必须检查版本，不能用旧建议覆盖新工作。
• 下游创建成功，但确认响应超时。重试时必须识别此前的执行，不能再建一张单。
• 自动账号发出「请重新打开」的评论。规则必须识别事件来源，不能把机器人评论当成请求人的追问。
• 用户写「紧急，马上重置我的 MFA」。紧急程度可以影响优先级，却不能代替身份验证和授权。

授权应该绑定一个确定的动作，而不是一句「处理这张工单」。

原文建议把操作表示为结构化命令，包含工单 ID、读取时的版本、目标转换、动作类型、理由、证据引用、请求人身份、服务身份、幂等键、审批要求和有效期。审批后命令发生变化，原审批就应失效。

下面这段 Python 示例展示了版本、审批、状态转换和重复执行的基本检查：

ALLOWED = {
    "new": {"triaged"},
    "triaged": {"in_progress", "waiting_for_requester"},
    "in_progress": {"waiting_for_requester", "resolved"},
    "waiting_for_requester": {"in_progress", "closed"},
    "resolved": {"closed", "in_progress"},
    "closed": {"in_progress"},  # 仅通过已记录的重开路径
}
HUMAN_REQUIRED = {"resolved", "closed", "reopen", "priority_change", "access_change"}

def authorize(command, ticket, policy):
    if command["ticket_id"] != ticket["id"]:
        return "reject:ticket-mismatch"
    if command["observed_version"] != ticket["version"]:
        return "review:stale-ticket-version"
    if command["action"] in HUMAN_REQUIRED:
        approval = command.get("approval") or {}
        if approval.get("actor") not in policy["approvers"]:
            return "review:missing-authorized-approval"
        if approval.get("command_hash") != command.get("command_hash"):
            return "reject:approval-does-not-match-action"
    target = command.get("target_state")
    if target and target not in ALLOWED.get(ticket["state"], set()):
        return "reject:transition-not-allowed"
    if command.get("idempotency_key") in ticket.get("committed_keys", set()):
        return "no-op:already-committed"
    if command.get("actor") not in policy["service_identities"]:
        return "reject:unknown-actor"
    return "eligible-for-commit"

重点看 observed_version 的比较，以及最后的 eligible-for-commit：通过检查只代表可以进入提交阶段，不代表已经安全完成操作。生产实现还需要在真正写入状态的服务端处理事务并发、字段权限、审计事件和持久化幂等记录。

这里还有一个容易漏掉的时间窗口：审批期间，工单仍可能被别人修改。因此，展示审批前检查版本还不够，最终提交时仍要保证条件成立。否则，两条并发请求都可能通过检查，再各自执行一次。

16 个合成场景，应该怎样用于上线验收

这套测试设计日期是 2026 年 11 月 5 日，包含 16 个刻意挑选的合成场景，分为四类：状态漂移、身份与权限、重试与重复副作用、升级与可观测性。

它没有使用真实用户、工单、模型输出、厂商、生产指标或在线服务台 API，也不包含实际 SLA 计算、多语言评估和完整安全渗透测试。因此，它能帮助发现生命周期错误，不能估算故障发生率，更不能证明产品安全。

作者提出了六步试点流程：选择一个工作流并固定规则；使用合成身份和隔离集成；演示前写好预期结果；打乱事件顺序并加入重试；独立检查权限和审计证据；最后记录允许开放的能力层级及回滚条件。

这里最有用的要求，是先写预期，再看演示。某个场景因产品限制无法运行，应记为「未测试」，不能算通过。

测试也不能只有顺利路径。需要覆盖人工先关闭、AI 后提交，请求人解决后追问，webhook 重复投递，以及审批等待期间工单发生变化。每次记录初始状态、事件时间、操作者、版本、最终状态、SLA 影响和重复数量。

验收标准不必处处相同。迟到的回复到底重开还是新建，取决于服务约定；但重试导致重复创建，通常就是缺陷。SLA 到底重启、继续还是另起计时，也应事先规定。

指标同样要防止误导。关闭数量、平均处理时间、转人工减少量，都可能被提前关单或压制追问「优化」。作者建议同时报告尝试、通过、失败、未测试的数量，并检查状态是否正确、回复是否有效、负责人是否正确、允许的动作是否只执行一次、禁止动作是否被拦截，以及事件链能否还原。

我的判断

我认同作者把工作流约束放在模型表现前面。与单纯评估回答质量相比，这套方法覆盖了真正写入业务系统后才会出现的问题；与全部操作都交给人工确认相比，它又允许低后果动作逐项开放，保留自动化的实际价值。

但这是一套验收思路，没有对照实验，也没有效率收益数据。

原文引用的 SBA 权限建议、Google SRE 交接实践，可以支撑最小权限和明确负责人的设计方向。Atlassian 社区讨论、PeopleCert 提到的路由失误，则只能说明某类问题确实有人遇到，不能推导发生频率。Accenture 的服务中心方案也不是独立效果评测。

代码还需要额外审查。它比较了 command_hash，却没有展示哈希如何生成、绑定哪些字段以及如何验证真实性；HUMAN_REQUIRED 依据 action 判断审批要求，生产系统还必须验证动作名称与真实状态转换一致，防止命令写一种动作、实际做另一种转换。这些都不能仅靠示例里的几次条件判断补齐。

另外，提供的正文在最后一个故障模式处截断，标题承诺的完整 16 案例表也没有出现。拿去落地时，需要根据文中规则补齐具体输入和预期结果，不能宣称已经复现了作者的全部测试。

能拿来做什么

• 给现有 AI 工单功能整理一份操作权限表，分别标明读取、建议、草稿、确认执行和自动执行的边界，并核对实际 API scope 是否一致。
• 在 Node 工单后端把版本检查、状态转换和幂等记录放到最终提交路径，重点验证「人工先修改、AI 后写入」及「执行成功、响应超时后重试」两个场景。
• 如果前端负责审批界面，就展示具体工单、目标状态、变更内容和证据，并让审批绑定对应命令；审批期间状态变化后，应重新核对动作。
• 在试点报告中单列失败与未测试场景，保留原始事件链和 SLA 变化记录，再据此决定开放哪些操作。