晚上十一点多了。屏幕还亮着。我盯着刚敲完的一段自动化脚本，看进度条跟老牛拉车似的，一格一格往前蹭。编译跑通，测试没报错，包也打好了。看着挺顺，跟上了发条似的。可程序一跑完，屋里就剩机箱风扇在那儿呼哧呼哧喘粗气。我突然回过味来。一下午吭哧吭哧给它搭架子，倒把最初拿它干嘛给忘了。合着大半夜不睡觉，就为了自动清理那堆没用的临时日志？忙活半天，原地踏步。这事儿，大概就是这么个意思。真没必要跟自己较劲。
前阵子收拾书架，翻出本旧书，《Ant in Action》。书名听着挺硬核。掰开揉碎了讲，怎么用工具把Java项目的编译、测试、打包、部署全自动化。作者在那儿反复念叨一件事。把那些枯燥的、容易出岔子的活儿甩给机器，人只管核心逻辑。字里行间挺平静，就跟聊今天天气似的。可翻到“部署”那几页，我手指头在屏幕上停住了。说实话，书里这套逻辑用在写代码上确实管用。但你要硬套到过日子头上？我觉得未必那么回事。人又不是流水线上的零件。
咱们这代人，不都在给自己写这种脚本吗？早上七点闹钟响。是掀被子，还是再赖五分钟？早餐啃包子还是喝粥，工作群里老板@你该怎么回，周末去哪家苍蝇馆子能避开排队，甚至跟对象吵架，得先搜好“高情商回复模板”。咱们把日子切成一块块，设好触发条件，就盼着一切按着预定的轨道滚。卡壳了调参数，报错了打补丁。总以为这么折腾完，能腾出手来好好“生活”，去够那些真正要紧的东西。但说句实在话。这脚本越写越长，维护的坑，反而越填越多。操碎了心，图啥呢？
有时候，真让人头疼的不是事儿本身。是咱们太想让它“零报错”。书里提过持续整合，代码改一行，就得跑一遍测试。过日子也一样。发个朋友圈，得抠半天配图。见个朋友，得提前查好路线、备好几套话题。连周末去趟超市，都得列好清单。咱们硬生生把自己活成了一个全天候自测的项目，生怕哪步没踩准，整个系统直接崩盘。可人毕竟不是机器，日子也不是代码。非要把生活跑成CI/CD流水线，累不累啊？
可人毕竟不是机器，日子也不是代码。书里原话是，构建的终点是交付。可咱们好像永远卡在半道上，死磕“测试”阶段。总觉得火候不到。总想再捋顺一遍流程，再攒够点底气。结果呢？那些真正该去折腾的事，全被往后推。直到某天猛然醒悟。时间压根没因为咱们的小心谨慎而放慢脚步，反而在反复的“准备”里，悄悄耗干了。我觉得吧，这种“完美主义”在搞工程上能出活儿，但在生活里，多半是个坑。
说实在的，我以前也迷过这种掌控感。以为把每一步都铺平，生活就绊不倒我。后来才咂摸出味儿。那些最让人上头的瞬间，全出在脚本跑飞的时候。比如去年，突然心血来潮报了个没基础的陶艺班。结果捏出来的碗，跟个歪脖子鸭似的。但那天跟老师瞎扯淡的快乐，比我在工位上敲一万行代码都实在。它们没经过预编译，连个测试用例都没有，却结结实实地砸进了日子里。
也许咱们真没必要追求那么完美的自动化。允许一点编译错误。允许一次部署失败。日子本来就不需要严丝合缝的依赖管理。那些看着多余的步骤，那些来不及收拾的鸡毛蒜皮，没准正是咱们还在认真喘气的证据。机器能一键跑完，但人得自己迈腿。走得慢点，绕点远路，都没啥大不了。反正日子嘛，大概就是这么个理儿。别把自己逼太紧。
屏幕上的进度条，早跑没影了。我啪地合上电脑，连旁边刚建好的文件夹都没多看一眼。外头城市安静下来，路灯把影子拉得老长。明天照旧得爬起来，该忙活的事一件少不了。只是这回，我不打算再给它敲什么脚本了。就让它自己跑吧。报个错，也挺有意思的。