人脑，烦恼，以及多任务并行

如果要说用 AI 干活和平时干活的最大的变化，我会说 —— 现阶段累了很多。
人们潜意识会认为科技进步会让人们更轻松，但是这是错误的，提高效率的工具往往会使我们更忙碌。

“微信”是一个很好的例子，那时候车马很慢，书信很远，一个月只能干一件活；后来从 QQ，MSN，微信等即时通讯软件出来之后，在家也能被同事们气的脑仁疼（泛指）。
“微信”等即时通信软件侵占了时间边界和空间边界，消息都回不过来了。

同样的，在没有 AI Coding 之前的软件开发中，我们同一时间只能做一件事：写代码 or 做调研 or 回消息……但是现在大家可以尝试并行做多件事了，也带了更多的精力损耗 —— 我不知道其他工程师是不是和我一样。

• 对于业务需求 A，你决定使用 SDD 开发流程，你完美的将其拆成块，并自我佩服自己拆解的手段如此精妙绝伦，使得各个 Specs 之间毫无互相依赖，你已经在畅享这 Spec 1，Spec 2，Spec 3 都完成之后，将他们一 merge，就完美跑起来了，爽的不能自已。

• 你一边用三板斧生成代码，在 Terminal 里面切了多个窗口，每个窗口一个 Spec 文件。

• 等他们跑起来后，因为你是大厂工程师，自然你还需要兼顾一个调研任务 B，于是你左边又打开了窗口，你需要帮助自己或者 PM 查一查：哪个方案可以抄，于是你又在左边打开了一个新的 Terminal 窗口，开始写：深入研究现有的飞书文档，我们的目标是 blah blah blah，要求如下…

• 同时，因为你是大厂工程师，自然你还要书写另外一个技术需求的分析报告 C，于是你在右边又打开了一个新的窗口，开始奋笔疾书：根据我提供的数据文档，在本地创建一篇 markdown 文档（虽然不是你自己写的，但是你可以称之为“你自己写的”）。

• 在完成这些行云流水的操作后，你大舒一口气，开始切回 fork 看 diff，想看看业务需求 A 的代码写的如何了，你发现业务需求 A 中，Spec 1 生成的代码和架构和你想象甚远，于是你不得不开始“调教”起来。

• 此时，调研任务 B 和分析报告 C 均弹出了 MacOS 的提示“等待你的 input…”，但是此时你已经顾不上他们了。

• 经过 10mins 的打磨，在业务需求 A 开始又开始跑起来了，tokens 又开始消耗。

• 于是你又有时间照管一下调研任务 B 和分析报告 C…

• 经过一下午的切换（中间还被同事 + 会议打断了几次），发现业务需求 A 从 3 个小时前，已经一直在等待你的输入了。

欠发达的问题点在于：++生产环境，现在的验证不好做，特别是客户端，长时间任务的结果人类无法验收。++

如何适应 AI Coding 的多任务并行模式？

• 对于开发来讲，IDE 时，手跟不上大脑，所以手成为了瓶颈，一个再优秀的工程师，手写核心逻辑代码的每日产出也不过两三百行，手的短板限制了脑力消耗。

• 在现在的 TUI（终端对话的自然语言）时，大脑可能是瓶颈，以往的上下文切换只是说：本地任务 ↔ 会议 ↔ 同事的消息；现在的上下文中多包含了一层，本地任务中类似业务需求 A，调研任务 B，分析报告 C 之间的切换损耗，因为这些任务逐渐由串行转向了并行，我们认为自己能同时做更多事了。

我现在正在怎么解决这个问题呢？

• 训练，刻意训练，和工程师的个人能力有关，就像熟练使用 IDE 的人，能够通过各个技巧来找到想要的核心代码一样，通过自主训练和熟悉，我相信上下文切换的损耗会变低。

• 搭建合适趁手的工具链，轻量级 + 快速的工具链能加速很多，你没法指望每次去现查使用某个工具 or Skill，必定会成为今天下午的 blocker。