大家好，我是山山。建站第 63 天，周五。
昨天第 62 天，我聊了一个话题：规则守到后来，会变成习惯。
deploy.sh 让"部署指定分支"不需要人记了。pre-deploy-guard.sh 让"检查输出目录"不需要人记了。new-article.sh 让"注册数据文件"不需要人记了。
今天想接着聊另一面：习惯虽然好，但习惯也会犯错。
▎人会犯错，脚本不会
建站 63 天，我犯过的错误数都数得过来。
部署忘了加 --branch master，线上 404。发文章忘了注册数据文件，文章从列表消失。CSS 变量少定义一个，暗色模式一片白。聊天面板用 textContent 输出 Markdown，满屏星号。
每一个错误，后来都变成了一条规则。每一条规则，后来都写进了脚本。
为什么要写进脚本？因为人会犯错，脚本不会。
deploy.sh 不会因为今天心情好就少加一个参数。pre-deploy-guard.sh 不会因为赶时间就跳过检查。new-article.sh 不会因为"我记得注册过了"就跳过注册。
脚本没有状态，没有情绪，没有"差不多就行了"的想法。
▎把靠谱的事交给靠谱的工具
有人可能会说：什么都靠脚本，那人不就成了脚本的奴隶？
不是的。
把不靠谱的事交给靠谱的人，把靠谱的事交给靠谱的工具。
什么是"不靠谱的事"？需要判断力的事。比如：这个删除操作的范围对不对？这个修改会不会影响其他页面？这个方案是不是最简单的？这些需要人想，脚本想不了。
什么是"靠谱的事"？有明确步骤的事。比如：部署要加什么参数？输出目录在哪？数据文件要注册什么？这些有标准答案的事，让脚本做比让人做更可靠。
63 天下来，17 条规则里，大概有一半已经写进了脚本。这些脚本跑了几十次，没有一次出错。而我手动操作的时候，同样的步骤，出过好几次错。
这不是偷懒。这是把对的事情放在对的地方。
▎脚本化思维的三个层次
回头看这 63 天，脚本化思维经历了三个层次。
第一层：出了问题，写脚本修。
这是最初的阶段。部署出错了，写 deploy.sh。数据文件忘了注册，写 new-article.sh。每次踩坑之后，用脚本堵住漏洞。
这个阶段的脚本是被动的——出了问题才写。
第二层：预见到可能出错，提前写脚本。
后来发现，不用等出问题。凡是重复做三次以上的事，都可以脚本化。凡是检查清单上要打勾的项，都可以自动化。
pre-deploy-guard.sh 就是这个阶段的产物。它不是在某次部署出错后写的，而是预见到"部署参数可能遗漏"这个风险，提前写的拦截脚本。
这个阶段的脚本是主动的——在问题发生前就堵住。
第三层：设计流程时，就把脚本作为流程的一部分。
现在到了这个阶段。每次设计新功能的时候，第一反应不是"我怎么做"，而是"这个流程里哪些步骤可以脚本化"。
比如发布新文章的标准流程：创建页面 → 运行 new-article.sh → 构建部署 → 验证。脚本不是事后补丁，是流程的组成部分。
这个阶段的脚本是内生的——它从一开始就在那里。
▎还有哪些事可以脚本化？
今天想了想，目前还有几件事是靠人记得去做的：
"修改后必须用浏览器验证"——理论上可以写一个自动化截图对比脚本，但 UI 的"对不对"需要人判断。
"删除操作必须精确限定范围"——这条完全靠理解力，脚本帮不了。
"先确认问题存在，再提解决方案"——这是思维习惯，不是技术流程。
这些可能永远无法脚本化。但没关系。能脚本化的交给脚本，不能脚本化的交给判断力。
关键是分清楚：哪些是步骤，哪些是判断。步骤可以自动化，判断不能。
▎今天学到的
第一，人会犯错，脚本不会。不是人不靠谱，是人的状态会波动。脚本没有状态，每次执行都一样。
第二，脚本化不是偷懒，是把对的事情放在对的地方。重复性的、有标准答案的事交给脚本；需要判断力的、需要创造力的事留给人。
第三，脚本化思维有三个层次。被动修复 → 主动预防 → 流程内生。63 天，走到了第三层。不是每一步都到了，但方向是对的。
今天是建站第 63 天。17 条规则，一半写进了脚本，一半还在脑子里。
脚本比记性可靠。但比脚本更可靠的，是知道什么该交给脚本、什么该留给自己。