自动化运行成功，为什么仍然不能交付？

成功运行只覆盖了正常路径

一条自动化在测试中从输入走到输出，只能证明当前样本、当前权限和当前依赖下的正常路径可用。真实运行会出现空字段、重复数据、接口限流、登录失效、网络中断、模型输出漂移、人工修改和外部系统变更。

如果系统没有识别这些状态，失败可能不会表现为明显报错，而是产生重复写入、遗漏、错误分类或静默停止。此时任务日志显示“完成”，业务结果却已经不可用。

可交付系统的五个工程条件

第一是可观测：知道每个任务处于什么状态、用了什么输入、经过什么规则。第二是幂等与去重：重复触发不会造成重复结果。第三是恢复：失败后能够从安全位置重试，而不是全部重来。第四是人工接管：系统知道何时停止自动判断并交给明确角色。第五是验收：输出需要满足业务标准，而不只是技术调用成功。

这五个条件不是附加功能，而是把“能跑”变成“可用”的主体。缺少其中任何一项，都可能把节省的操作时间转化为更昂贵的排错和返工。

• 任务状态是否覆盖等待、运行、成功、失败、需人工和已取消
• 同一输入重复提交时会发生什么
• 依赖服务恢复后，系统从哪里继续
• 人工接管是否带着完整上下文和建议动作
• 业务验收失败是否会阻止后续步骤

任务成功率不是唯一指标

成功率需要先定义分母和成功标准。若系统自动重试十次以后完成，技术上可能被记为成功，但延迟和调用成本已经超出业务要求。若输出结构正确但内容错误，也不能视为业务成功。

更完整的指标应包括端到端完成率、首次通过率、人工接管率、平均恢复时间、重复执行率、异常未发现率和单位有效结果成本。指标不必越多越好，但必须覆盖系统最可能造成损失的位置。

交付前应该做什么

交付前需要用真实但受控的数据进行故障注入：主动制造超时、缺失、重复、权限失效和错误输出，观察系统是否按预期阻断、告警、恢复和记录。仅测试成功样本会系统性高估可靠性。

同时应明确责任边界：谁维护接口，谁处理业务异常，谁有权修改规则，修改后如何回归验证。软件交付不是把代码移交出去，而是让运行、判断和恢复都有明确所有者。