3.2 任务入口选择：本地执行，还是交给云端做

📄 一句话概括

本地能碰到你的环境和密钥，云端碰不到——这一个差别决定了八成的选择。 三条判据：碰不碰本机环境、要不要密钥、要不要人盯着。 判错方向的后果不对称：该本地扔了云端，是「改了个你看不见的副本」。

📝 本章和前面几章的关系

上一篇把入口跑通了。这一篇讲第一个真正的选择：活儿在哪儿干。 这个选择在补全时代不存在（只有本地）， 在对话时代也不存在（还是本地）——它是委派时代才有的新问题。 为什么值得单开一节？因为它出的是「隐形事故」。 本地跑错了，你看得见；云端跑错了，改动落在云端那个副本里，你以为改了，其实本地没动。 这一篇的 Demo 给了十条真任务，按三条判据逐条打分，最后一条判错方向的后果单独演。

一、本地执行能碰到什么

本地执行的最大特点是「它就在你机器上」。 这一条带来三个好处和两个麻烦。 好处一：能用到你的环境。 你的 venv、你的本地数据库、你的 node_modules、你的 .env——这些它都能直接用，不用你搬。 好处二：能随时打断。 它跑到一半你想改主意，一个 Ctrl+C 就停——云端任务停不了，只能等它跑完或者取消。 好处三：改动落在你的工作区里。 你能立刻 git diff 看、能立刻改、能立刻回滚。 麻烦一：它也能碰到你不希望它碰的东西。 同一台机器上的其他项目、你的 ssh key、你的浏览器 cookie—— 这些东西在同一个用户下，它理论上都能读（除非沙箱模式限制住）。 麻烦二：它会占你的机器。 一个跑半小时的任务，你的电脑就热半小时——而且内存、CPU 都是抢的。

二、云端执行省掉什么

云端执行是「在别人的干净容器里跑」。 干净的意思是：没有你的 venv、没有你的 .env、没有你昨天的临时文件。 它省掉三样东西： ① 省你的机器（跑多久都不占你资源）；② 省你的等待（扔过去就可以走开）； ③ 省掉「环境不一致」（容器是照仓库里的配置建的，谁的机器上都一样）。 但它同时带来一个必须处理的问题：改动在云端。 它跑完会给你一个分支或者一个 PR，你得把那个结果拉回来。 这一步经常被忘——因为界面上会显示「任务完成」，看起来像已经落到你本地了。 还有一个隐含的好处，容易被忽略：云端更安全。 因为它碰不到你本机的密钥（除非你主动给）。 所以「不想让它碰到敏感文件」这件事，扔云端比在本地加限制更彻底。

三、一张判断表

判据	打几分	为什么
要用本机的 venv／数据库	本地 +2	云端没有这些，跑不起来
要用密钥或凭据	本地 +2	密钥不该进云端容器
要随时看、随时打断	本地 +1	云端只能等
以上都没有	云端	省机器、省等待

打分规则：到 2 分就本地，不到就云端。 分数不是精确的科学，是把「直觉」写成了可核对的东西—— 十条任务打完分，你会发现大部分判定跟你直觉一致，不一致的那几条才是值得细想的。 「要密钥」这一条权重跟「碰本机」一样重，理由只有一个： 密钥一旦进了云端容器的上下文，就等于泄露了。 你没法知道它在容器里被写进了哪个日志、哪个缓存。 还有一类任务两边都行，选哪个看「你要不要看见过程」。 比如「给三十个文件补 docstring」—— 你不关心它怎么补，只关心结果，那就扔云端；如果这三十个文件风格各异、你要一个个看，那就本地。

四、动手 Demo：十件事，哪些该在本地做、哪些该扔云端

这个 Demo 把判断表变成代码：十条任务，每条标三个维度，按「本地 +2／云端 +1」打成结论。 打分是规则算的，你可以照着改成自己团队的权重。 十条里五条本地、五条云端——注意「分析一个线上报错的日志」被判成本地，理由是要密钥， 这一条大概是最反直觉的。

tasks = [
    ("改本地仓库一个函数",        1, 0, 1),   # 碰本机/要密钥/要盯
    ("跑一遍本地全量测试并修失败", 1, 0, 0),
    ("把整个模块的命名统一一遍",   0, 0, 0),
    ("连本地数据库改表结构",       1, 1, 1),
    ("分析一个线上报错的日志",     0, 1, 0),
    ("给一个 PR 写审查意见",       0, 0, 0),
]

for name, local_env, secret, watch in tasks:
    score = local_env * 2 + secret * 2 + watch
    print(name, "->", "本地" if score >= 2 else "云端")

实跑输出：

--------------------------------------------------------------------
十件事，哪些该在本地做、哪些该扔云端
--------------------------------------------------------------------


  ① 先定三个判据
  --------------------------------------------------------------------
| 判据 | 本地做 | 云端做 |
|---|---|---|
| 碰不碰本机环境 | 要用本机的 venv、数据库、密钥 | 用干净容器，碰不到本机 |
| 跑多久 | 几分钟内 | 几十分钟，人可以走开 |
| 要不要人眼看 | 要随时看、随时打断 | 跑完看结果就行 |

  三条里第一条是硬判据：要碰本机环境的，只能本地——云端容器里没有你的 venv、没有你的 .env。

  ② 十个真任务，逐条判
  --------------------------------------------------------------------
| 任务 | 碰本机 | 要密钥 | 要盯 | 结论 |
|---|:---:|:---:|:---:|---|
| 改本地仓库一个函数 | 是 | — | 是 | 本地 |
| 跑一遍本地全量测试并修失败 | 是 | — | — | 本地 |
| 把整个模块的命名统一一遍 | — | — | — | 云端 |
| 给三十个文件补 docstring | — | — | — | 云端 |
| 连本地数据库改表结构 | 是 | 是 | 是 | 本地 |
| 读一份 PDF 总结成 README | — | — | — | 云端 |
| 调 UI 的间距和颜色 | 是 | — | 是 | 本地 |
| 分析一个线上报错的日志 | — | 是 | — | 本地 |
| 批量升级依赖版本 | — | — | — | 云端 |
| 给一个 PR 写审查意见 | — | — | — | 云端 |

  打分规则：碰本机 +2、要密钥 +2、要盯 +1，到 2 分就本地。
  ! 「要密钥」这条权重跟「碰本机」一样重——因为密钥不该出现在云端容器里。

  ③ 判错的两种后果
  --------------------------------------------------------------------
| 判错方向 | 后果 |
|---|---|
| 该本地却扔了云端 | 跑不起来（没环境），或者跑起来了但改了另一个副本 |
| 该云端却放本地 | 占着你的机器几十分钟，你还得盯着 |

  第一种是真事故：云端跑出来的改动，落在云端那个副本里——你以为改了，其实本地没动。
  ! 所以「云端任务」跑完必须把改动拉回来，而且要核对——这一步经常被忘掉。

表格里「要密钥」那一列有两条是「是」：连本地数据库、分析线上日志。 两条都判成了本地——第一条是因为碰本机，第二条纯粹是因为要密钥。 「分析一个线上报错的日志」这一条值得细想。 直觉上它是「读一份文件、总结一下」，扔云端最省事。 但只要那份日志要用生产的凭据去拉，就不能扔——正确做法是先把日志下载到本地，再扔云端分析。 这一步拆分很关键：把「取数据」和「分析数据」分开，一个本地一个云端。 第三节讲判错的两种后果，第一种是真事故： 云端跑出来的改动，落在云端那个副本里。 界面上显示「完成」，你会以为本地已经改了。 所以云端任务跑完必须做一件事：核对本地的 diff。 没看到 diff，就当没改。 「该云端却放本地」的后果轻得多——只是占你机器、你还得盯着。 所以判不准的时候，往本地判：本地判错的代价是效率，云端判错的代价是「你以为改了」。

30 秒实验

把你这周做的五件事，按三条判据各打一次分。 打完看有没有一条跟你直觉不一致——那一条就是你的认知盲区。
如果你用过云端任务，回想一次：跑完之后你核对本地改动了吗？ 没核对的那次，现在去 git log 看一眼——大概率那条改动根本不在本地。
练一个拆分动作：把「取数据」和「分析数据」分成两个任务。 前者本地（要密钥），后者云端（只处理文本）。

常见误区

「云端更先进，什么都扔云端。」 云端碰不到你的环境。 要用本机 venv、本地数据库的任务，扔过去只会「跑不起来」，或者跑在一个空环境里。
「本地更安全，什么都别上云。」 本地的风险是「它能碰到你所有的东西」——其他项目、ssh key、浏览器数据。 「不想让它碰敏感文件」这件事，扔云端反而更彻底。
「云端跑完了，界面显示成功，就成了。」 成功的是「云端那个副本」。 本地有没有变，要自己 git diff 看。 没看 diff 就当没改。

自测三问（点开对答案）

1. 三条判据里哪一条权重最高？为什么？ —— **「碰本机环境」和「要密钥」都是 +2，权重最高。**前者是因为云端根本没有那些环境； **后者是因为密钥一旦进了云端容器就等于泄露。** 2. 「分析线上日志」该放哪儿？怎么放？ —— **拆成两步：取数据本地（要密钥），分析数据云端（只处理文本）。** **把日志下载到本地再上传，比直接把生产凭据给它安全得多。** 3. 判不准的时候往哪边判？为什么？ —— **往本地判。** **本地判错的代价是效率（占机器、要盯着），云端判错的代价是「你以为改了其实没改」**—— 两种代价不对等。

下一篇 3.3 讲一次任务从头到尾长什么样：读、改、验三段，以及它什么时候会停下来问你。

☐ （本篇完，下一篇 3.3 一次完整任务的执行流程）