三个判据，顺序不能换：碰不碰本机、跑多久、要不要边跑边看。 换一次顺序，十五条任务里有六条判断翻掉——而且是同一类。 第一问答错不是慢一点，是这件事根本做不到。
这一节是本章最该记的一节。3.2 讲过一张二问判断表（碰本机、要密钥）， 这一节加进第三个维度，并且强调「顺序」。 Demo 用十五条真任务跑了三遍：一遍按正确顺序、一遍按错误顺序、一遍数翻掉几条。 结果很干脆：翻掉六条，全是同一类。
一、按碰不碰本机环境分
本机有什么？ 装好的依赖、配好的环境变量、本地跑着的服务、显卡、公司内网。 云端有一个干净容器，但没有上面这些。 所以第一问问的是「能不能」，不是「划不划算」。 这一问答错了，后面的判断全都没有意义——因为那件事在云端根本做不到。 一个具体的反例：查一个依赖为什么装不上。 本机有那个坏掉的缓存，云端是干净的，它永远复现不了。 这类任务放云端，得到的是「在我这儿是好的」。 还有一个隐性依赖：网络位置。 能连内网数据库的只有你的机器，云端容器连不上——这也是「碰本机」的一种。
二、按跑多久分
十分钟是一条经验线，不是标准。
短任务在本地秒出，长任务在本地占着终端——而终端只有一个。
但这条线只在第一问之后才有意义。
一个要跑四十分钟、又要碰本机的任务，放云端等于「跑得很快地做错」。
它确实不占你终端了，但它做的事是错的。
长任务放云端还有个隐性好处：它不打断你。
在本地跑四十分钟，你的终端就废了四十分钟，这期间你连 git status 都得另开一个窗口。
三、按要不要你用眼睛看分
要边跑边看的：调样式、看日志滚动、反复改一个参数试效果。 这类活的特点是「看一眼改一下」，放云端等于每改一次等一轮。 只看结果的：批量改、跑测试、生成文档。跑完给个结论就够，中间过程你不需要看。 三问的顺序，其实就是代价的顺序： 做不成 ＞ 干等 ＞ 事后调。 先排除代价最大的那种失败，这就是为什么第一问必须是「能不能」。
四、动手 Demo：三问顺序不能换：换一次，六条判断翻掉
这个 Demo 是纯判断，但它比很多真跑的 Demo 有说服力—— 因为它把「顺序」这个抽象的东西，换成了「翻掉几条」这个数。 十五条任务，每条三个属性：碰不碰本机、大概跑多久、要不要边跑边看。 先按正确顺序判一遍，再按「先看跑多久」判一遍，最后数差几条。
def _judge(t): # 正确顺序
name, ben, mins, eye = t
if ben: return u"本地", u"要碰本机环境"
if mins > 10: return u"云端", u"跑得久，别占着终端"
if eye: return u"本地", u"要边跑边看"
return u"云端", u"快，且只看结果"
flip = [(TASKS[i][0], right[i], bad[i]) for i in range(len(TASKS))
if right[i] != bad[i]]
实跑输出：
--------------------------------------------------------------------
三问顺序不能换：换一次，六条判断翻掉
--------------------------------------------------------------------
① 十五条真任务，三个维度各问一遍
--------------------------------------------------------------------
| 任务 | 碰本机 | 分钟 | 要眼睛看 |
|---|:---:|:---:|:---:|
| 跑一遍全量测试 | 是 | 18 | 否 |
| 批量给 30 个文件加版权头 | 是 | 25 | 否 |
| 全量重跑一遍数据迁移 | 是 | 35 | 否 |
| 构建一次生产镜像 | 是 | 22 | 否 |
| 把三年日志导进本地库 | 是 | 40 | 否 |
| 对整个仓库跑一遍类型检查 | 是 | 14 | 否 |
| 把 dist 目录清掉重打 | 是 | 3 | 否 |
| 改一个函数名 | 是 | 2 | 否 |
| 把旧分支 rebase 到最新 | 是 | 6 | 是 |
| 改 CI 配置让构建缓存生效 | 是 | 9 | 否 |
| 通读 payment 模块讲清退款流程… | 否 | 12 | 是 |
| 分析线上日志找 500 的来源 | 否 | 30 | 是 |
| 给新接口写文档 | 否 | 8 | 否 |
| 生成一份测试数据 | 否 | 4 | 否 |
| 审一遍这个 PR 的 diff | 否 | 20 | 是 |
② 按「能不能 -> 划不划算 -> 需不需要人」的顺序判
--------------------------------------------------------------------
| 任务 | 放哪 | 依据 |
|---|---|---|
| 跑一遍全量测试 | 本地 | 要碰本机环境 |
| 批量给 30 个文件加版权头 | 本地 | 要碰本机环境 |
| 全量重跑一遍数据迁移 | 本地 | 要碰本机环境 |
| 构建一次生产镜像 | 本地 | 要碰本机环境 |
| 把三年日志导进本地库 | 本地 | 要碰本机环境 |
| 对整个仓库跑一遍类型检查 | 本地 | 要碰本机环境 |
| 把 dist 目录清掉重打 | 本地 | 要碰本机环境 |
| 改一个函数名 | 本地 | 要碰本机环境 |
| 把旧分支 rebase 到最新 | 本地 | 要碰本机环境 |
| 改 CI 配置让构建缓存生效 | 本地 | 要碰本机环境 |
| 通读 payment 模块讲清退款流程… | 云端 | 跑得久，别占着终端 |
| 分析线上日志找 500 的来源 | 云端 | 跑得久，别占着终端 |
| 给新接口写文档 | 云端 | 快，且只看结果 |
| 生成一份测试数据 | 云端 | 快，且只看结果 |
| 审一遍这个 PR 的 diff | 云端 | 跑得久，别占着终端 |
③ 把顺序换成「先看跑多久」
--------------------------------------------------------------------
| 任务 | 放哪 | 依据 |
|---|---|---|
| 跑一遍全量测试 | 云端 | 跑得久，别占着终端 |
| 批量给 30 个文件加版权头 | 云端 | 跑得久，别占着终端 |
| 全量重跑一遍数据迁移 | 云端 | 跑得久，别占着终端 |
| 构建一次生产镜像 | 云端 | 跑得久，别占着终端 |
| 把三年日志导进本地库 | 云端 | 跑得久，别占着终端 |
| 对整个仓库跑一遍类型检查 | 云端 | 跑得久，别占着终端 |
| 把 dist 目录清掉重打 | 本地 | 要碰本机环境 |
| 改一个函数名 | 本地 | 要碰本机环境 |
| 把旧分支 rebase 到最新 | 本地 | 要边跑边看 |
| 改 CI 配置让构建缓存生效 | 本地 | 要碰本机环境 |
| 通读 payment 模块讲清退款流程… | 云端 | 跑得久，别占着终端 |
| 分析线上日志找 500 的来源 | 云端 | 跑得久，别占着终端 |
| 给新接口写文档 | 云端 | 快，且只看结果 |
| 生成一份测试数据 | 云端 | 快，且只看结果 |
| 审一遍这个 PR 的 diff | 云端 | 跑得久，别占着终端 |
翻掉的 6 条：
跑一遍全量测试 本地 -> 云端
批量给 30 个文件加版权头 本地 -> 云端
全量重跑一遍数据迁移 本地 -> 云端
构建一次生产镜像 本地 -> 云端
把三年日志导进本地库 本地 -> 云端
对整个仓库跑一遍类型检查 本地 -> 云端
! 翻掉的全是同一类：要碰本机、又要跑一会儿的任务。
先问时长，它们就被推到云端——而云端根本没有你本机那个环境。
顺序不是风格问题。第一问是「能不能」，答错了不是慢一点，是这件事根本做不到。
所以「能不能」必须排在最前面。
④ 三问各自在问什么
--------------------------------------------------------------------
| 顺序 | 问题 | 答错会怎样 |
|---|---|---|
| 第一问 | 要不要碰你本机 | 任务做不成 |
| 第二问 | 要跑多久 | 占着终端干等 |
| 第三问 | 要不要边跑边看 | 改到一半没人管 |
! 三问都有答案之后再看成本。先问成本，等于先给自己找借口。
翻掉的六条全是同一个类型：碰本机，又跑得久。 错序那版把它们全推到了云端。 云端没有那些依赖，所以这些任务根本跑不起来。 注意「查一个依赖为什么装不上」这种任务：它既碰本机、又要跑一会儿。 按错序判，它会被推到云端——然后在干净的容器里一切正常。 第三问在什么时候才起作用？ 在第一问是否、第二问是「不到十分钟」的时候。 所以它排最后不是因为它最不重要，是因为它只在前面都通过时才轮得到。 三问都有答案之后再看成本。 先问成本，等于先给自己找借口——人会为了「省事」把不该上云的任务也推上去。
30 秒实验
- 挑三个你最近做过的任务，按三问各判一次。 判完回头看：你当时实际是怎么做的？差在哪？
- 找一个「碰本机又跑得久」的任务，试着拆成两半。 前半在本机取数据，后半在云端分析——这是最常用的一种拆法。
- 把「十分钟」换成你自己的线。 你手上什么任务算「值得让它自己跑」？这个阈值每个人不一样。
常见误区
- 「云端更快，都放云端。」 云端没有你本机那个环境。 快是快，可它做的是另一件事。
- 「本地最安全，都放本地。」 长任务占着终端，你一天干不了别的。 安全不等于划算。
- 「三个判据无所谓顺序。」 Demo 里换一次顺序，十五条翻掉六条。 顺序不是风格，是「先排除做不到的方案」。
自测三问（点开对答案）
1. 三个判据的正确顺序是什么？为什么第一问必须排最前面？ —— **碰不碰本机、跑多久、要不要边跑边看。** **第一问问的是「能不能」，答错了这件事根本做不到**——**后面两问再优也没用。** 2. 「查一个依赖为什么装不上」为什么必须放本地？ —— **本机有那个坏掉的缓存或坏掉的环境变量，云端是干净的。** **干净环境里复现不了，你得到的答案是「在我这儿是好的」。** 3. 第三问什么时候才会起作用？ —— **只在第一问是否、第二问是「不到十分钟」的时候。** **它排最后，是因为它只在前两问都通过时才轮得到。**下一篇 4.5 讲三个工具：Review、Automation、Worktree，它们各治一个病。
- ☐ （本篇完，下一篇 4.5 Review、Automation、Worktree 的角色）