每日自动化的头号恐惧不是「跑失败」，而是「跑到一半崩了，不知道重跑会发生什么」：重跑会不会把昨天的通知再发一遍？会不会把台账写重？会不会把已经部署的页面又推一次？答案取决于一个词——幂等：同一操作执行一次和执行 N 次，系统状态应当相同。今天把苏运AI 每日总调度里的幂等设计拆给你看。
流水线型任务（采集 → 写作 → 部署 → 通知）天然会半途崩：网络抖动、上游 502、磁盘满、进程被杀。如果设计上「重跑 = 从头再来」，那每次故障都会带来重复副作用，运维者只能手动对账，自动化反而变成负担。幂等的目标是把「重跑」从危险动作变成随手动作——崩在哪，就从哪接着跑。
把流水线拆成编号步骤（前置巡检 → 基础设施 → 留资闭环 → 内容生产 → 部署校验 → 汇总推送），每步完成后立即落一条状态记录（步骤名 / ok-fail-skip / 备注 / 时间戳），存到独立状态文件。重跑时逐条查表：status == ok 的步骤直接跳过，只跑未完成的。关键细节：登记必须发生在副作用落地之后，且写入用「临时文件 + 原子替换」，防止状态文件本身写坏。
每日任务的状态文件带日期戳，加载时发现日期不是今天就自动重置。这样「昨天跑成功过」不会让今天被跳过，「今天崩了」也不会污染明天。状态的生命周期和业务周期对齐，是幂等设计里最容易被忽略、又最省心的一招。
步骤级跳过还不够——单步内部的副作用也要幂等：
· 写台账：追加前先查「同名项目已存在则跳过」，重复巡检不会写重；
· 部署文件：先算本地哈希，远程字节数/MD5 一致就不推，只推增量；
· 发通知：一天只允许一条汇总，发送前查「今天已发」标记，发送后回读送达状态。
三层幂等键（步骤键 + 业务键 + 周期键）叠起来，整条流水线才能真正做到「随便重跑」。
有些步骤今天本来就不该跑（比如只在周一出周报），有些步骤需要 AI 创作内容还没就位。它们不该记 fail，也不该假装 ok——记 skip 并写明原因，既不阻断其它步骤，又给「补跑」留下线索。状态只有如实，断点续跑才有意义。
这套「步骤登记 + 按天滚动 + 幂等键」骨架，是苏运AI 对外提供「AI 代运营 / 工作流」服务时的标准件：把你业务里每天重复的流程（对账、报送、巡检、通知）做成敢重跑的自动化。敢重跑，才敢无人值守——这是自动化从「演示品」到「生产件」的分水岭。