一次性任务值得自动化吗？一个月才做一次的活怎么交出去

写脚本有个前提：这件事要重复足够多次，多到值得为它写一套代码。

很多自动化工具默认你满足这个前提。现实里还有一类活反过来：步骤不少，做起来烦，频率很低，一年四次，或者一个月一次。

手动做嫌烦，写脚本不划算。下面说这类任务怎么处理。

三个低频场景

季度结算的截图汇总。财务每个月末要打开四个后台，把结算页截图存下来，按月份命名，丢进共享盘。四个后台，每个三到五屏，加起来二十多步。一个月一次。

大促前的备货检查。每次大促前要把十几个店铺的库存页翻一遍，标记出低于安全线的商品。一年就两三次大促，但每次要翻十几家店。

突发的竞品调研。老板说「你去看看这三家竞品最近在推什么」，于是一晚上翻了几十个账号的首页。这种事每年几次，每次来得很急。

三件事的共同点是：步骤多，但不难，做完能核对。这就是值得交出去的类型。

写一套脚本，要先把流程拆清楚，把每一步的定位方式定下来，处理各种异常，再调试。这套功夫在每天要跑的活上摊得开，在一个月跑一次的活上摊不开。工程量一样，收益只有三十分之一。

还有一个更具体的原因：低频任务的流程经常差不多，但不完全一样。上个月四个后台，这个月变成五个。上次按月份命名，这次财务说要按店铺命名。每次都有点小变化。脚本最怕这种小变化。

所以过去多数人就手动做，忍着。

把这件事说一遍

iEasyRun 的做法是：你用自然语言把这件事说一遍，它自己到屏幕上去做。

不写坐标，不写控件路径，也不用先把流程拆成伪代码。你说「打开这四个后台，把结算页截图，按 2026-09 命名存到桌面那个文件夹」，它听懂，然后一步步做。

写脚本的成本和任务长度成正比。说的成本和任务长度几乎无关。一件二十步的活，说清楚大概三分钟。三分钟和两天，就是这类低频任务值不值得交给它跑的分界。

脚本记的是「第 320 行 65 列那个点」，界面一改就要回去改。AI 操作手机是看屏幕上有什么再决定：读出当前页面上的文字和元素，判断哪一个是目标，然后点下去。

低频任务上这个差别更明显，因为：

• 一个月才跑一次，中间 App 很可能已经更新过一版
• 每次的入口位置可能都不一样，比如后台首页改过布局
• 你根本不会为了这种活去维护脚本

它找的是写着「导出」的按钮。坐标从 320, 65 挪走了，也找得到。按钮从左边挪到右边、菜单从一级变二级，照样找得到。

下个月还要做的话

两种做法，看你懒到什么程度。

跑完存成工作流。第一次用对话跑通之后，把过程保存下来，下次直接调用，不用说第二遍。适合确定以后还会做、流程也不会变的活。

什么都不存，下次再说一遍。下个月到了，照着上次那句话再说一次。说的成本只有三分钟，一年做四次完全够用。

多数人先用第二种。某件事做到第三次，发现每次说的都差不多，再顺手存成工作流。比一上来就规划工作流自然。

判断就三条。

步骤多，但不难。步骤越多，人越容易在中间漏掉某一步。这是交给电脑最直接的收益。

每次流程基本一样。不用完全一样，大同小异就行。每次都要现场靠人做判断的活，它替不了。

做完能核对。截图存没存对、库存标没标出来，有明确的东西可以查。没法核对的结果，交给谁都不放心。

两种活不用交：两三步就能点完的，省不下多少；每次规则都不一样的，它做不了。

第一次先挑最短的那件低频活。别拿季度结算这种二十多步的上手。先用一件七八步的跑一遍，看它理解的和你想的是否一致。前一两次看着它跑，之后可以放手。

跑完去 执行历史 看一眼：状态对不对，有没有中途失败的步骤。低频任务更要看这个。高频的活出问题，你下次就发现了。低频的活，可能两个月后才发现上个月就错了。

软件完全免费，装在自己电脑就能跑。同一台手机上，高频的活继续用脚本，低频的活用对话跑，两者不冲突。