我曾经一度迷恋”同时推进三个项目”的画面。
早上写一会儿站,中午改一会儿 agent,晚上再回去推 side project。日历看起来很丰满,推送 commit 的频率也很均匀。但季度结束盘点的时候,三个项目都停在 60%,没有一个能拿去给人看。
那段时间我以为问题出在执行力。后来才意识到——执行力没问题,问题是我一直在重新加载上下文。
并行的代价从来不是线性的。Gerald Weinberg 在 1991 年的《Quality Software Management Vol. 1》里给过一张被业界引用了三十年的损耗表:一个人专注做一件事,有效产出是 100%;同时做两件,各 40%(20% 损耗在切换);三件各 20%(40% 损耗);到了五件,单项产出已经跌到 5%,80% 的时间用来切上下文。
数字本身有争议——Weinberg 自己也说那是估计、不是测量。但量级是对的。任何写过代码的人都能验证:打开一个三周没碰的 repo,从”我现在在解决什么问题”到”手指真的开始打出有用的字”,中间那段 warm-up 的时间,远比直觉长。
更阴险的是 Sophie Leroy 2009 年在《Organizational Behavior and Human Decision Processes》上发的那篇——“Why is it so hard to do my work?”。她造了一个词叫 attention residue:你从任务 A 切到任务 B 的时候,A 不会干净地从你脑子里退出去。它会以一种残影的方式留在你的工作记忆里,占着 cache,降低你处理 B 的精度和速度。
换句话说:你以为你切到了 B,实际上你只是在用一个被 A 污染的大脑做 B。
放到编程语境里,这件事更具体。
切一个 git branch 的成本不是 checkout 那两秒。是你要重新载入:这个分支的目标是什么、上次卡在哪、TODO 列表里那条注释当时为什么没立刻改、相关的库版本、约定的命名、还在脑子里某个抽屉里的那个待办设计决定。IDE 可以缓存文件树,但缓存不了你的心智模型。
Cal Newport 在 2016 年那本《Deep Work》里反复说一件事:深度工作能力是稀缺资源。我倾向于把它翻译得更工程化一点——深度工作能力是一种 cache locality。一个项目在你脑子里 warm 的时候,你能做出别人做不到的事;一旦它冷掉,你回去就只是一个普通访客。
Csíkszentmihályi 1990 年那本《Flow》写的是同一件事的另一面:flow 不是”专注一会儿”。flow 是你和系统的耦合到了一个临界点,反馈、节奏、难度、信心刚好对齐。你从一个项目跳走、再跳回来,这个耦合就要重建。三个项目并行,你永远在重建,从来不在跑。
我后来给自己定了一条很笨的规则:一段时间只让一个项目处于 hot 状态。
其他项目可以 idle、可以维护、可以接 issue,但不再”今天推一点、明天推一点”。要么 hot,要么冷藏。冷藏期间不假装”我也在做”。
这条规则上线之后,我有过一个反直觉的观察:三个项目轮着 hot,每个 hot 期专注两周,总产出比同时跑三个项目要多。多很多。多到我开始怀疑过去那种”看起来很忙”的状态,本质上只是一种心理上的对冲——同时开三个,意味着没有任何一个的失败需要我独自负责。
所以那种并行不是工程策略。是一种情绪策略。
单人项目最稀缺的资源不是时间,是连续性。 一个能持续一周的注意力曲线,胜过五个被切碎的下午。