敲下那行 import requests 之前，你的手停在键盘上。这不是危言耸听，会议室里刚散场，产品经理又丢来一个“麻烦用Python帮我处理一下Excel”的需求。你很清楚，写个脚本十分钟，但后续的破事可能纠缠你一整周。大多数自动化脚本的诞生，不是因为“值得”，而是因为“我们被要求了”。而真正成熟的开发者，在写第一行代码前，会强迫自己回答三个更狠的问题。

问题一：这真的是一劳永逸，还是给你自己造了个新岗位？

很多人对自动化的第一反应是“省时间”。可事实是，你省下的往往不是自己的时间，而是那个需求方的时间，代价是你的维护时间。真正的成本不是写脚本的半小时，而是脚本上线后每一次环境变化、数据格式微调、依赖库升级时，你都要被迫“接单”。一个粗暴的规则是：如果这个任务你手动做需要十分钟，且一个月只做一次，那么写一个需要每周调试一次的脚本，就是纯粹的负收益。

你要算的不是“脚本运行时间”，而是“全生命周期成本”。脚本写完不算完，它得在你不盯着的时候自己跑。这意味着它必须能处理网络超时、文件锁占用、权限不足、数据缺失，以及最要命的——竞争对手或同事改了输入模板。任何自动化都是一种负债，它的利息是你对未知情况的持续焦虑。 所以不妨先问：这个任务是一次性的还是一种重复性的仪式感？如果是后者，它真的每周期待你的“照看”吗？

更深一层，你要警惕“自动化表演”。有些团队喜欢把脚本做成“数字中台”，本质上只是把人工错误变成了程序错误，而且错误发生得更有规律、更隐蔽。如果一件事在没有脚本时根本没人关心，那么加了脚本之后，它也不会变成一件重要的事，只会变成一件总是出故障的事。

问题二：你确切知道脚本会怎么死吗？

新手写脚本，总喜欢写“阳光路径”：读取→处理→输出。但真实世界的脚本，是活在垃圾数据里的。你唯一能确定的，就是你输入的数据是不确定的。凡是没捕获的异常，都会在你度假的凌晨三点准时触发。 所以，写脚本的本质不是让代码“跑通”，而是给所有可能的崩溃场景预先挖好坟。

这意味着你必须先写失败路径，再写成功路径。比如读取文件时，文件不存在怎么办？存在但编码不对怎么办？编码对了但有空行怎么办？空行跳过以后，字段数不对怎么办？这些不是伪完美主义，而是自动化脚本的生存底线。因为脚本不是人，它不会“看一眼就知道这行有问题”，它只会固执地把脏数据算成更脏的结果。

更关键的是，你确定脚本的执行结果是可验证的吗？一个没有自检机制的自动化脚本，就是一颗定时炸弹，你不知道它什么时候把错误结果当成正确结果发给了所有人。 所以脚本里至少要有校验步骤：处理前后行数是否一致？关键字段是否为空？输出文件大小是否为零？运行日志里有没有错误码？这些花费你十分钟写的“防御性废话”，才是整个自动化真正值钱的地方。

而很多“聪明人”会告诉你，用异常捕获然后 pass，或者干脆 try...except Exception 挂个空壳。我要说，这种脚本别说自动化，连自动出错都算不上，它只是把你从“不知道会出错”变成了“看着错误沉默不语”。 写脚本之前，请先列一张清单：这个脚本可能以哪些方式把数据搞坏？每种方式，你要让它尖叫着停下来，还是带着警告继续跑？想清楚这个，比想清楚用哪个库重要一万倍。

问题三：三年后，还有人能改你这几行代码吗？

很多人觉得脚本是自己的私人工具，注释随便写，变量名用 a1、b2，函数堆在一起。反正自己看得懂。但请你诚实回答：三个月后，你还看得懂吗？如果你不认为三个月后的自己是个需要被伺候的陌生人，那么你根本没有资格说“这代码很清晰”。 自动化脚本最隐蔽的陷阱，就是它常年不维护，但常年被依赖。

当你说“用Python写自动化脚本”时，你其实在承诺一个长期契约：这个脚本要能随着环境演进。Python版本升级了，你的脚本还在用老掉牙的 urllib 吗？第三方库更新了，你的脚本被踩了多少弃用警告？更现实的问题是：如果这个脚本突然挂了，你的同事或接班人能不能快速接手？一份不能交接的自动化脚本，就是一座只属于你的数字废墟，它的存在价值，约等于你在某个深夜写的一段暗号。

所以，结构上请遵循“配置与逻辑分离”。把文件路径、数据库连接串、参数阈值、时间间隔全部抽到配置文件或者环境变量里。一个好的脚本，应该能让一个从未学过Python的同事，通过修改一行配置来适配新环境。 函数命名要像说话一样自然，比如 load_latest_report()，而不是 get_data()。日志要带上时间戳、级别和上下文，而不是一句 print("ok")。

更要命的，是逻辑的脆性。很多人喜欢用正则表达式去解析HTML或嵌套括号，或者用字符串切片去处理JSON。这种处理方式，让脚本每次运行都像是在走钢丝，而你自己就是那个不敢松手的人。 能用成熟库用成熟库，能标准解析就标准解析。不要试图用三十行代码去“绕过”一个你知道应该用XX库解决的问题。想要证据？看看那些曾经“挺好用”的脚本，后来是不是都变成了“我不敢升级系统”的借口。

别急着写码，先给脚本写一份“墓志铭”

让我们把这个思路更狠一点。你别想“我该怎么写这个脚本”，而是想“这个脚本最后会如何退出历史舞台？” 如果预期寿命只有一周，那你随便写，跑完就删。但如果预期寿命超过一个月，你就要给它应有的尊严：包含版本号、作者、创建日期、依赖清单、退出条件。是的，一个专业的自动化脚本必须知道什么时候该“退役”。它不能无限期地运行下去，吞掉越来越脏的数据，然后某一天产出一份让你下不了台的结果。

判断一个脚本是否真正成熟，不是看它能跑多久，而是看它跑了一段时间后，你是否有勇气删掉它。如果你不敢删，说明它不是你的工具，而是你的主人。 很多自动化项目最终沦为“手动操作加自动化辅助”——用户先手动把数据整理成脚本想要的格式，再跑脚本生成报告。这他妈的就不叫自动化，这叫被脚本驯化。

所以回到最初的三件事。第一，你是在解决问题，还是仅仅在享受“写代码”这个动作？ 如果手动做十分钟的事情，你非要写个两小时的脚本来“省时间”，那这不是效率，这是兴趣。第二，你为失败做了多少准备？ 一个对失败毫无敬畏的脚本，甚至谈不上“开发”，只能叫“输入垃圾、输出惊喜”。第三，你考虑过接手人的感受吗？ 不止是别人接手，也包括三个月后“冷冰冰”的你。

最后，衡量自动化质量的唯一标准：你的心跳速度

写完脚本，按下了第一次运行。你的心跳是快了还是慢了？如果心跳加速，说明你根本不知道它会干什么，你只是在祈祷。好的自动化脚本应该让你变得无聊，而非兴奋。 它应该每一步都有逻辑可循，每个可能出错的地方都有明确反馈，每个运行闭环都有验收标准。

不要再说“用Python写个自动化脚本很简单”这种话。简单的是用Python敲几行玩具代码。真正难的，是让一个脚本在你背后稳定运行几年，期间经历三次操作系统升级、两次数据源改版、一个实习生误删了表，却还能给出可靠的结果。这件事和“简单”无关，和“清醒”有关。

在你打开编辑器之前，请先写下三行笔记：这个脚本的存在是为了解决哪个具体的痛苦？ 它的失败模式有哪些？我如何确保自己不在跑完脚本后还得手动检查一遍？如果这三个问题你答不出来，那么请放下键盘，去做你那份“几分钟就能做完”的手工活。至少那样，你还能确定错在哪里，下一次改哪里。

但如果你答出来了——恭喜你，你要写的不是一个脚本，而是一个可以交给你自己的、有尊严、有边界、有自觉的自动化产品。这才是Python自动化真正值得热爱的地方。