自动化最容易踩的坑：命令成功了，业务却没完成

自动化最容易踩的坑：命令成功了，业务却没完成
做日常开发任务助手时，我碰到了一个很实际的问题：命令退出码是 0、模型也回答了，但业务页面没有相应结果。另一次请求超时，又无法确定服务端是否已经处理。如果直接重试，很容易把同一件事做两遍。
这类问题不只出现在任务助手里。部署、报告生成、文件同步、消息通知，都可能有“执行完成”和“业务确认完成”两个时刻。把它们混成一个成功状态，自动化就会变得不可靠。

1. 用两个维度记录结果
   执行状态记录程序做了什么：待执行、执行中、执行成功、结果未知、明确失败。业务状态记录结果是否得到确认：未核验、待同步、已确认。
   例如模型返回正文，只能证明问答执行成功；业务系统是否认可该任务，要另查业务记录。不要根据某个“去完成”按钮仍然存在，就断定任务没做过；按钮可能只是固定入口。
   情况
   执行状态
   业务状态
   下一步
   尚未开始
   待执行
   未核验
   执行一次
   已得到完整回答
   执行成功
   待核验
   查询业务记录
   请求超时
   结果未知
   未核验
   先查服务端结果
   页面已有确认记录
   执行成功
   已确认
   停止重复执行
   “未确认”不等于“失败”。这一点是避免重复执行的关键。
2. 本地去重不能代替服务端幂等
   最小去重键可以由账号、任务类型和业务日期组成：
   account_scope / task_type / business_date
   日期应使用业务规定的时区，而不是任意机器的本地时区。不同账号也不能共用完成标记。调用前持久化“执行中”和尝试次数，调用成功后立即记录脱敏回执。
   但本地文件锁或数据库唯一键只能限制本地并发，不能保证网络另一端只处理一次。对于付款、发布、通知等有副作用的动作，优先使用服务端提供的幂等键。没有幂等机制、又无法反查结果时，超时后应停在“结果未知”，不要自动重发。
3. 给重试预算，而不是无限循环
   我给一个普通问答任务设置了最多两次尝试。达到上限后，输出失败类别和下一步，由人检查；不会无限后台重试。
   需要分别处理几种结果：明确的参数或授权错误先修正原因；限流或暂时不可用按服务端提示退避，并消耗有限重试预算；读取超时先核对服务端是否完成，避免重复消耗或重复产生副作用；已执行但业务尚未同步时只查询确认结果，不重新执行。
4. 用业务证据验收
   我会分别核验三个问题：请求是否真正发出，完整结果是否返回，业务页面是否有对应确认记录。总余额变化也不能单独证明某一项任务完成，因为其他操作也可能改变余额。
   最后验收四个场景：同一天重复运行是否跳过；进程中途退出是否保留已尝试记录；切换账号是否拒绝混用状态；跨日后是否重新核验，而不是沿用昨天的成功标记。
   可靠的自动化不是把按钮都点一遍，而是知道哪些事情已经做完、哪些事情还没有证据，以及什么时候应该停止重试。
   本文由实际开发过程整理，使用 AI 辅助措辞并人工核验技术边界。示例描述通用工程设计，不包含任何活动奖励接口或认证信息。