给 AI 派活前，先算这道除法：频率乘耗时

刚上自动化的商家，第一反应通常是「能自动的全自动」：每五分钟查一次库存，每十分钟同步一次订单，每小时生成一次报表，再加上每天几次的数据备份。纸面上每一条都合理，跑上三天，机器开始变慢、任务开始互相踩，人却说不清是哪一条拖的。

问题往往不在某一条任务写得差，而在没人算过一道很朴素的除法。

一、一道除法：频率乘单次耗时，等于每小时占用多少分钟

把每条自动任务的三个数写在纸上：多久跑一次、一次跑多久、跑的时候占多少资源。第一个乘法就能看出问题：

• 每 5 分钟跑一次、单次 90 秒 → 每小时里有 18 分钟在跑，占掉三成；
• 每 10 分钟跑一次、单次 3 分钟 → 每小时 18 分钟，一样；
• 每小时跑一次、单次 40 分钟 → 看似「一小时才一次」，实际占用 67%。

三条这样的任务叠在一起，机器名义上「还有余量」，实际上任何一条稍微慢一点，就会和后面那条撞上。撞上之后表现出来的是「系统卡」，不是「任务排队」，所以人容易去查网络、查硬盘，绕一大圈。

一条实用的线：所有自动任务加起来，一小时内的占用别超过十分钟。超过就该降频、合并，或者把「每次都干」改成「有变化才干」。

二、两套程序盯同一件事，比没人盯更糟

还有一种更隐蔽的浪费：同一件事被两套逻辑同时管着。一个判得松，一个判得严，宽松的那套觉得一切正常，严格的那套觉得处处异常，于是两边反复纠正对方的纠正——服务被反复拉起、状态被反复改写，日志里全是「已处理」，实际谁也没稳定下来。

判断方法很简单：同一件事，只允许有一个判据、一个执行者。想改规则，就改那一个地方，别在旁边再加一套「保险」。加保险的本意是防出错，结果常常是先制造出一批假故障，再花几天去查这批假故障。

三、频率该按「事情变化的速度」定，不该按「我有多着急」定

门店一天卖几十单，库存五分钟查一次和半小时查一次，对生意的影响几乎一样；真正影响体验的，是「出了问题能不能在人发现之前报出来」。这两件事经常被混为一谈。

• 变化慢的数据（商品信息、价格、员工排班）——每天一次足够，甚至一周一次；
• 变化快但有缓冲的（订单、库存）——十几分钟一次就够用；
• 真要「实时」的，往往是通知，不是查询：让变化主动推过来，比让程序反复去问便宜得多。

把「查询」换成「通知」，是省机器最有效的一步，也最容易被忽略，因为它不体现在功能列表里。

四、给自动化留三条底线

• 单次有上限：一次任务超过设定时间就放弃并记录，不要无限重试——无限重试会把一次小故障放大成持续占用；
• 同一目标只有一个执行者：宁可少一层「保险」，也不要两套判据互相打架；
• 每天报一次总账：今天该跑多少次、实际跑成多少次、哪几次超时。天天报「我在跑」的自动化，人很快就会不看。

这三条不提高任何功能，但决定了这套自动化三个月后还能不能安稳运行。

五、这套思路在土拨鼠里怎么落地

土拨鼠把「定时干的事」和「有人问才回答的事」分开处理：前者按上面的除法排班，后者不占常驻资源。想知道具体能接哪些活，可以看 功能页；如果在意「这些自动化到底花多少钱」，定价页 是按实际用量算的；想先拿自己店里的一件事试算一遍，下载 之后从最小的一条开始，比一次排十条稳得多。

六、留三个问题，回去问自己的系统

• 我有几条自动任务是按「几分钟一次」排的？它们加起来一小时占多少分钟？
• 有没有两套逻辑在管同一件事？如果停掉其中一套，会不会反而更稳？
• 我的自动化是在反复「查询」，还是在等「通知」？

自动化省下的是人的时间，前提是它自己别把机器的时间吃光。排班不是勤快就好，余量才是稳定。