从这一篇开始，工具要脱离你的手自己跑。但在讲怎么跑之前，先讲什么该跑—— 因为自动化最大的成本不是搭起来那半天，是后面每一个月都要养着它。
本文写什么判据、典型反例、渐进路径。 本文不写我们自己自动化了什么、跑在哪、什么时刻跑。
多数人只算了左边和「搭建」，漏掉了后面两项。而那两项恰恰是长期开销：
| 被漏掉的成本 | 具体是什么 |
|---|---|
| 维护 | 依赖会变、接口会改、密钥会过期。一个自动化就是一个你要养的小系统 |
| 注意力 | 它每发一次通知，都在占你的注意力预算——哪怕内容是「一切正常」 |
| 静默失败 | 最贵的一项：它坏了但没告诉你，而你以为它还在跑。见第 22 篇 |
| # | 判据 | 不过会怎样 |
|---|---|---|
| 1 | 你已经手动做过至少三次 | 没做过三次，你根本不知道稳定流程长什么样，自动化的是一个还在变的东西 |
| 2 | 它有明确的成败信号 | 没有客观判据，它做错了你也不知道——这比不自动化更糟 |
| 3 | 做错了你承受得起 | 后果不可逆的活（删数据、发消息、动钱）不该无人值守，至少要留一道人工确认 |
「让它每天帮我总结一下」听起来很美好，问题是：总结得好不好，谁判？ 没有判据，你只会得到一串每天都在产生、但没人读也没人验的输出。 过一阵你会开始跳过它，再过一阵你会忘了它还在跑。
反过来，「每天跑一遍测试，失败就告诉我」判据极其明确——这类活才是自动化的甜区。
| 类型 | 长什么样 | 为什么不成立 |
|---|---|---|
| 没人读的日报 | 每天生成一份摘要发给自己 | 频次高、单次价值低，且没有成败判据 |
| 「一切正常」通知 | 每小时报一次平安 | 正常是常态，报正常等于训练你无视它——真出事那条也被无视了 |
| 一次性任务的自动化 | 为了跑一次而搭一套 | 频次 = 1，收益侧直接归零 |
| 自动化一个你还没想清楚的流程 | 边搭边改需求 | 违反判据 1。你在给一个移动靶建工事 |
它们的共同特征是「产出没有接收者」。 判断一个自动化值不值，最快的问法是：它的输出，谁会因为它而做出不同的动作？ 答不上来，就别搭。
| 类型 | 为什么成立 |
|---|---|
| 有明确判据的巡检 | 测试、构建、可达性、证书到期——只在失败时出声 |
| 你反复做且步骤固定的搬运 | 判据 1 天然满足，收益随频次线性增长 |
| 时间点固定、你人不在的活 | 唯一真正无法手动替代的一类——这也是上云的核心理由 |
就算三条判据全过，也别直接上无人值守。按这个顺序走，每一步都能退回去：
| 阶 | 做法 | 你在验证什么 |
|---|---|---|
| 1 | 手动跑，但把步骤写成一个脚本或一段固定提示 | 流程真的稳定了吗 |
| 2 | 定时跑，但只输出、不动手（干跑） | 它的判断对不对——这一步至少跑一周 |
| 3 | 让它动手，但每次动手前要你确认 | 动手的部分有没有副作用 |
| 4 | 无人值守，只在异常时出声 | — |
干跑期的唯一目的，是让你看见「如果它当时动手了，会做什么」。 这一周里你多半会发现两三个当初没想到的边界情况—— 那几个情况就是你没走干跑期时会踩的坑。