把重复开发动作脚本化：从 30 分钟到 3 分钟

我有一个习惯：同一件事做了三次以上，就开始想能不能脚本化。不是因为懒，是因为手工流程最大的问题不是慢——而是每次都可能漏一步。尤其在发布前，漏一个环境变量、漏一次 lint 检查、漏一个数据库迁移，就可能导致返工甚至线上事故。脚本化的本质不是"加速"，而是"把确定性固化下来"：同样的输入永远产出同样的执行序列，不会因为今天犯困就少跑一步。

还有一个容易被忽略的好处：脚本即文档。三个月后你忘了上次发布前到底做了什么，打开脚本看一眼就知道了。比起翻聊天记录或者问同事"上次你是怎么搞的"，可靠太多了。

脚本化最大的陷阱是一上来就想写一个"全自动大脚本"。正确的做法是先列清单，把所有高频动作写出来，然后筛选哪些适合自动化：

1. 把高频动作写成 checklist：拉代码、装依赖、跑 lint、跑测试、生成构建、更新 changelog。先列全，再筛选。
2. 只自动化"稳定动作"——那些每次都一样、不会有条件分支的步骤。不要把频繁变化的逻辑硬编码进脚本，那样维护成本比手工还高。
3. 有条件分支的步骤（比如"如果是 main 分支就发正式版，否则发预览版"），先写成两个独立脚本，等模式稳定了再考虑合并。过早抽象是脚本维护成本失控的头号原因。

我见过太多脚本一开始就追求"通用框架"，结果只有作者自己能用，换个人来连参数都看不懂。好的脚本应该像说明书——读一遍就知道它在干什么：

1. 每个脚本只做一件事，失败时给出清晰报错——至少要让人知道是哪一步挂了。set -e 加上每步前后的 echo，是最简单有效的做法。
2. 命名尽量直白：check.sh、build.sh、release-dry-run.sh。别取 run.sh 这种什么都没说的名字。脚本名应该能回答"我运行这个会发生什么"。
3. 脚本头部写清楚前置条件和输出物，用注释就行，不用搞文档系统。比如 # 前置：已安装 Node 20+，已在 .env 中配置 DATABASE_URL。这一行注释能帮你省掉无数次"跑一半才发现环境不对"的时间。