先本地后远程：把重复工作交给自动化之前

把重复工作交给自动化，收益很直接：一次配置，长期省时间。但自动化本身不改变任务的对错，它改变的是出错的规模和速度——原来错一次影响一个文件，现在可能是一次覆盖一整批。

这就是「先本地后远程」这个顺序的由来：先在成本最低的环境里跑通，再考虑扩大执行范围。

远程任务到底和本地任务差在哪

很多人把远程任务理解成「同一个东西换了个入口」，实际差异比想象中大。官方给出的对照是这样：

三行里最需要注意的是第二行。远程任务只有一个会话，所有指令都在同一上下文里累积。如果今天在手机上处理合同，明天处理报销，两者会在同一段历史里混着走——这也是官方建议「本地操作优先用普通任务，需要远程触发或统一查看记录时再用助理」的原因。

文件是唯一不可再生的东西

脚本写错了可以重写，配置调乱了可以重置，被覆盖的源文件不行。所以在把任务交给自动化之前，备份不是「最好做一下」，而是前置条件。

• 让自动任务只写入新文件，不覆盖原始文件——这是最省事也最有效的一条纪律。
• 批量处理前先在一份副本上跑，确认结果无误再对全量执行。
• 重要的产出物保留版本，不要在同名文件上反复改。
• 把「原文件目录」和「输出目录」分开，出错时损失范围是可控的。

自动化的第一原则不是跑得快，而是出错的时候不伤到原始数据。

哪些操作应当保留人工确认

远程控制天然会被追问权限问题。官方给出的机制里有一条很关键：涉及文件删除、系统配置修改、批准命令执行等操作，需要确认后方可执行。

在设计自己的自动化流程时，建议照这个思路划出「必须停一下」的清单：

• 任何删除操作，包括「清理」性质的批量删除。
• 修改系统级配置、环境变量、权限设置。
• 对外发送的动作：发邮件、发消息、提交表单。发出去就收不回。
• 涉及金额、合同条款、对外承诺的内容生成。

这份清单的判断标准是「可逆性」：能撤回的放手让它跑，不能撤回的必须停下来让人看一眼。

一份可以照抄的上线检查表

最后一行是最容易被跳过、也最影响推广效果的一步。自动化真正的收益不来自单个人跑得快，而来自流程能被复制——而复制的前提是，它能被写成别人看得懂的说明。