4.3　如何“自动化”别人——自动化的局限

2019年年底，一篇题为《别学写代码——学会自动化》（Don’t Learn to Code—Learn to Automate）的文章在Hacker News上被发表出来并受到热议。文章本身的观点并不新颖，无非是鼓励读者不要畏惧学习编程的高门槛，应该从发现身边可以被自动化的任务做起，在需求驱动下自然而然地入门编程。

但善于批判性思考的Hacker News用户们似乎对此不太认可，他们指出：在工作环境下，自动化并不总是可行的。例如，排名最高的评论就认为：“对于发现问题的员工而言，问题不在于没有能力自动化，而在于有某些因素压倒性地阻碍着自动化。”

根据这则评论和其他用户在回应中的补充，这些“阻碍因素”包括：自动化方案的适用面过于狭窄、失败导致的返工成本、向他人解释或推广的困难等。简单来说，在工作环境下，自动化可能带来的有限收益无法覆盖为之付出的成本和潜在的失败风险。

如果放在过去，我可能会有些不以为然——哪里有什么阻碍，无非是惯性思维作祟罢了。但在自己参加工作并经历了几次不那么成功的尝试后，我对于这些评论描述的问题有了切身体会。

我从事的法律工作虽然通常被认为更接近所谓的脑力劳动，是“创造性”的。但“创造”却也是以大量的重复性劳动为基础的。例如，为了支撑法律报告中的一句结论，事前可能需要到商标局的网站上搜集数百个商标的申请信息，或者到数十个政府部门网站上核查是否存在负面记录并截图、汇总等。按道理说，这些都是适合用自动化代替人工的典型任务。我在刚上手时也是第一时间感到手工处理的低效，并积极寻求通过程序解决的方式，如图4-11所示。但事实证明，这些尝试最终并没有明显减少完成工作所需的时间，而其原因也印证了Hacker News的讨论。

图4-11　简化从商标局网站收集商标信息的Keyboard Maestro Macro

首先，自动化固然适合处理烦琐、重复的工作，但其逆命题却并不成立——烦琐、重复的工作未必容易被自动化。某些网站登峰造极的反爬虫、IP限流机制，以及工作中某些明显不合理却不得不遵从的格式要求，都可能为自动化带来无法克服的障碍。当然，这多少是因为我作为一个非科班出身的业余爱好者，编程能力确实有限。但即使有能力克服技术障碍，针对一个项目、一类模板找出的自动化流程，很可能因为需求、格式的细微变化，在其他项目、模板上毫无用武之地，自动化的“性价比”由此受到了极大限制。

其次，手工操作虽然烦琐，但却具有结果可控、时间可预期的好处——只要老老实实做下去，总有“熬出头”的时候。即使因为失误耽误了时间，至少也能因为付出的劳动而博得点“同情分”，更容易得到谅解。相反，一旦在使用自动化的技巧时出问题，导致耽误期限或不合要求，只能自己承担全部的风险，而很难向他人解释。

再次，工作中大多数任务都是需要团队协作的，一个人效率的提高并不足以拉动团队的效率，但自动化却经常是难以被推广的。琢磨出如何使用Word的邮件合并功能自动将上百张截图插入多个文档的指定位置是一回事，以一种通俗易懂的方式向不知域代码为何物的同事介绍这种方法却是另一回事了。

最后，从有些自私的角度来说，工作是干不完的。即使通过自动化的方式更高效地完成烦琐的工作，由于这些任务本身并没有什么技术含量，所以不会因此收获更多赞许，得来的可能只是更多的工作。

总之，当场景从个人研究切换到工作时，自动化就从一个纯粹的技术问题变成了一个同时涉及人际关系、组织关系和组织文化的综合性问题，而这些附加因素是不可能靠代码解决的。一句话，你可以“自动化”自己，却没法“自动化”别人。

不过，尽管被现实泼了些冷水，我继续实践自动化的动力并没有因此消失。每当被安排完成那些劳动密集型的工作时，我还是会首先考虑是否存在通过自动化更快完成的方法。结果，工作几个月来，我反而“东一榔头西一棒槌”地积攒了不少之前陌生的命令行脚本、网页前端和Office VBA相关知识，写起正则表达式也越来越自然了。

自己大费周章找出的自动化方案诚然可能只适用于一个任务，但在探索过程中积累的经验和技巧却是可以复用的。退一步说，哪怕最终没有找到任何捷径，思考和尝试自动化的过程也至少能让我对于任务本身有更清晰的认识，在手动完成时少走弯路。

最重要的是，思考本身就是令人愉悦的。如果劳动终究无法避免，有什么理由不让自己更开心呢？