图 1：本文封面，点明「识别重复、拆解流程、脚本化」的主题。
下班前回顾今天干了什么：从后台导出三张报表，合并成一个表，调格式，截图发到群里；把同一句话术复制粘贴给十几个咨询的人；临下班再手动核对一遍库存数字。真正需要动脑的判断，可能不到工作时间的一半，另一半全是重复动作。
核心结论：重复劳动不是命，是还没被拆解的流程。
凡是「每天都在做、步骤固定、做错了也能重来」的事，几乎都具备被脚本接管的条件。难的不是写代码，而是用一套方法把值得自动化的环节从日常噪音里筛出来。这套方法就四步：记录盘点、流程拆解、筛选判定、脚本化沉淀。
第一步：记录盘点。
凭感觉说不准自己忙在哪，如实记录才行。拿一周时间，每完成一件事就记一行：做了什么、花了多久、是不是第一次做。一周后回看，反复出现的环节自己会浮出来——数据导出、格式整理、复制粘贴、定时上报，几乎都是高频项。没有这份清单，自动化就是拍脑袋，大概率给不值得做的事写了工具。
第二步：流程拆解。
挑一个高频环节，把它的操作过程拆成可以逐条枚举的子步骤：打开哪个页面、点哪个按钮、复制哪一列、按什么规则改名。拆得出来，说明这件事规则明确；拆不出来、每一步都要看情况临场判断，说明你还没把它理解透——先别谈自动化，先把流程本身想清楚。拆解这一步同时也在倒逼你优化流程：很多环节拆到一半就发现，有三步本来就是多余的，不用自动化，直接删掉。
第三步：筛选判定。
不是所有能自动的事都值得自动。三个标准逐条过：
一，规则是否明确。能写成「如果这样就那样」的事才适合脚本；每一步都依赖人肉审美的，交给工具只会批量制造错误。
二，频率是否够高。每天出现一次以上的事，自动化才值回开发成本。每天省 30 分钟的事，花一两天写脚本是赚的；每月才做一次的事，写脚本的时间比一辈子手动做还久，不做。
三，出错代价是否可控。全自动只用于可回滚、可重跑的事。发出去的邮件收不回，删掉的数据难恢复，这类环节哪怕前面九步全自动，最后一步也必须留人工确认。
第四步：脚本化与沉淀。
先写一次性脚本验证思路，跑顺了再固化成定时任务或小工具，最后纳入团队的工具链，附上两三行使用说明。自动化的产出不止是省时间：脚本不会累、不会手滑，还把原本只存在于某个人脑子里的隐性经验，固化成了可以交接、可以复用的资产。人请假了，流程还在跑。
拿一个常见场景串一遍。
假设你每天要从三个后台各导出一份 CSV，合并去重，算出十几个指标，贴进日报模板发到群里，手动一趟四十分钟。走一遍四步：盘点确认它每天出现、耗时稳定；拆解后发现十五个子步骤步步有明确规则；判定三关全过——规则明确、每天一次、算错了重跑一遍就行；于是先写一个本地脚本跑通，再挂成每天早上八点的定时任务。之后每天看一眼结果就行，一个月省下十几个小时，还顺带消灭了手滑贴错数字的事故。
图 2：自动化四步方法与「值不值得做」的筛选标准。
几个容易踩的坑。
一，上来就追求全自动，忽略异常分支。脚本处理得了标准情况，处理不了网页改版、字段缺失，至少要让它遇到异常时停下来报警，而不是闷头算出一个错结果。二，给低频事项写脚本，投入产出不成立，感动自己而已。三，给不可回滚的操作去掉人工确认，省十分钟，可能赔上一天。四，脚本写完只存在自己电脑里，换台机器就失传——沉淀进仓库和文档，自动化才算真正完成。
行动建议很具体。
本周就做一次时间盘点，不用任何工具，拿备忘录逐行记。周末挑出那个「每天出现、规则明确、错了能重来」的最小环节，写下你的第一个脚本。哪怕它只省五分钟，你换来的也不只是五分钟——是「流程可以被拆解和接管」这个手感。
你工作里重复次数最多的那个环节是什么？用「规则明确、频率够高、代价可控」这三条量一量，它过关了吗？欢迎聊聊。