即如何解释“一劳永逸”？
如果我们要执行任何重复性任务，最好编写一个脚本或程序来完成这项工作。但关键的决定点在于何时开始考虑编写脚本？
这对人来说可能很主观，下图中，当人开始恼怒时就做出了决定。
0951579df006c3e848aaab360e1f5320.png关键的决定点在于何时决定编写脚本和了解坡度。我采取的一般方法是，当我第二次做同样的事情时，就该考虑编写脚本（或常用函数等）了。我曾陷入的误区是高估了斜率--如果这两条线多年没有交叉，你可能永远也得不到时间上的回报。
即使从技术上讲不是每次都有 "回报"，我也几乎总是宁愿用避免枯燥重复任务的方式来做事。我宁愿花六个月的时间发明和制造一台粉刷房屋的机器，也不愿意花四个月的时间在梯子上顶着烈日拿着刷子刷房子。
当然，有时你没有六个月的时间来粉刷房子。在这种情况下，除非根本不可能按时完成工作，否则我通常还是宁愿每天工作 12 小时来制造一台机器，也不愿意花同样多的 8 小时来刷油漆。
油漆很糟糕。创造和制造新东西才有趣。即使要花更多的时间来完成同样的工作，我还是宁愿这样做。当然，我现在有了一台绘画机器，下次一定会围着你转。
懒狗
手动做->懒得做->写脚本->懒得写->让gpt写 赢麻了。
有些同学认为写个脚本几分钟跑完几周的人工活很了不起
这种炫耀的心态不可取。容易让老板觉得工作不饱和。
首先像这种提升100倍生产力的工具，不但会震惊老板，也会吓坏同事，影响公司稳定和谐的环境。
正确的做法是，即便几分钟跑完任务，也应该花一周甚至更长的时间，无论是自己钻研高级数据分析之类的书提升也好，还是打磨脚本让普通人也更易用，只要老板预期两周，你一周零两天完成了，超出了他的预期，就是圆满完成任务，同时不至于引起同事的恐慌。
同样的任务，每次提升20～30%的效率，小步快跑多次满足预期，比一次巨大的冲击性满足要好得多得多，老板会认为你不断在提升。
反之，这次5分钟，下次准备几分钟搞完？
最后，即便是脚本几分钟能跑完，但如果要做成一个普通员工能快速上手的产品，能销售给更多的公司，就需要花很长时间思考、反馈、改进，这都不是一个简单的活。
两周的活话两天写个凑合的脚本跑完，然后剩下的时间进行性能优化和复用性修改，控制总工作时间基本不变
。
有时候review可能发现自己的脚本有bug 而且这种review优化是能实在提高自己编码能力的
不要解释
也不要让别人知道你用了脚本，除了你最亲最信任的人。否则你的脚本就白写了。
这就是为啥就算我写了脚本，也绝对不会把通用的东西封装的太好，不会在正前方定义变量一样，需要进行变更的时候，我直接去中间改代码，你要是想用，你就通读代码去吧。
不是混淆的问题，是领导让你告诉他怎么用的问题，你能说不么，所以我这里是把改几条配置变成要改代码，这样学的那边就从死记硬背几条配置怎么改，变成了必须学会一门语言，学会一些包怎么用，通读整个代码，对于非系统学习过的人是天堑。
带走没啥卵用，都是高度定制的，让这个东西别人学习曲线够高就行
职场回答
低情商：我写个脚本，十分钟干完你一天的活
高情商：这个东西真不好做，我可能一天才能做完
真技术参考：
- https://www.globalnerdy.com/2012/04/24/geeks-and-repetitive-tasks/
- https://akhileshyadav.wordpress.com/2012/04/26/geeks-and-repetitive-tasks/
