2026 年 4 月我们从 git 里翻出 11 个自建脚本，4 个已经跑不通了。没人删，也没人修，就那么挂着定时任务，每天往日志里写报错。自建脚本的成本大头不在写，在养。
崩的五种原因
站点改版。选择器、API 路径、字段名一变，脚本立刻失效，这是最常见的。
第三方接口变更。GSC API 的字段调整、CMS 升级、webhook 格式变化，都会让脚本读不到数据。
磁盘和权限。日志写满、token 过期、服务账号被移出权限组，这些运维层面的问题最容易被忽略。
写脚本的人走了。没文档、没注释，接手的人看不懂也不敢改。
需求变了。当初要的报表没人看了，脚本还在跑。
三种崩法
静默出错最危险。脚本正常退出，但结果是空的或者错的，报表照发，数字全是零。
部分出错次之，比如只抓到一半页面，报表看着正常但少了一块。
彻底不跑反而安全，因为很快会有人发现数据没了。
我们现在的做法是每天校验输出行数，低于阈值直接报错退出，不生成报表。
三条维护规矩
每个脚本一个说明文件，写清用途、输入、输出、依赖、负责人。五分钟能写完，省后面的十次沟通。
依赖版本锁定。Python 包不锁版本，半年后换个环境跑不起来。
每季度跑一次全量验证，对着已知结果比一遍。这条最容易被跳过，但只有它能发现静默错误。
交接怎么做
录一段五分钟的屏，把脚本跑一遍，讲清每一步在做什么。视频比文档有效，因为能看到报错长什么样。
注释只写“为什么”，不写“是什么”。代码本身能看出是什么，看不出的是当初为什么这么写。
别留只有一个人能跑的脚本。这个人休假，任务就停。
哪些活别自己写
能买就买。日志分析、排名监控、死链检测都有成熟工具，自己写等于浪费三个月。
一个反面例子
2025 年我们写过一个自动提交站点地图的脚本，六行，跑了一年没坏。后来站点从 800 个 URL 涨到 3 万，站点地图超过 5 万条的上限被截断，脚本不知道，一直提交半份地图，导致新页面收录拖了一个月。
修起来十分钟，发现花了半个月。原因是没人校验过输出的条数。
只在两种情况下自建：市面上的工具满足不了具体规则，或者用量大到工具费用不合理。我们自建的脚本都落在“排序”和“拼数据”这两类事上，现成工具确实做不到。
元析智能
为软件公司做 SEO 和 GEO 优化