瓶颈从来就不是打字速度

AI 不只是让打字变快了——它彻底挪动了瓶颈的位置。那些学会并行运行智能体的团队,和那些还在一次等一份 diff 的团队相比,会变得判若两队。

我和 AI 一起开发的最初版本很简单:让助手做 A 这件事,等待,评审 diff,再转到 B。助手是一个更快的结对编程伙伴,但仍然是「结对」,仍然是一次一件事。

那个模式大概维持了三个月,现在我已经不是那样工作了。

我现在做的是,针对同一个代码库并行运行多个 AI 编码助手,每一个都在自己的 git worktree 里,在自己的分支上,同时处理不同的问题。在任意一个时刻,各个仓库里都有五到十个活跃分支,不同的智能体同时在引擎的不同部分上推进。我做的是评审和合并,而不是编写和等待。

我这份工作发生的这个转变,就是本文要讲的内容。

一个真实的周末长什么样

三月中旬的一个周末。在这五个仓库里,从周六早餐到周日晚饭,一共落地了 112 次提交。其中 66 次的作者记录是一个 AI,47 次是我,剩下的是合并和评审驱动的清理工作。

这份工作不是一个项目,而是五个:九种类型的 WASM 移植;iOS Metal 渲染器集成;一个通过七阶段流水线处理二十一项资产的内容包运行器;卡牌对战类型第五到第七关;web 构建的性能优化。所有这些都发生在同样的两天里,分布在多个并行分支上,在每天下午和晚上陆续落地。

没有哪个人类能在厨房桌子的书桌前,一个周末打出 112 次提交。也没有哪个人类能在脑子里同时容纳五条并行的工作流,并为每一条都亲手写代码。三个月前我用的那个模式,做不出这样一个周末。

我现在用的这个模式,可以。

瓶颈发生了转移

当工作是串行的时候,瓶颈是打字。下一行代码不存在,除非有人把它写出来。AI 让这一行代码写得更快了,但它没有改变哪一步是慢的那一步。

当工作是并行的时候,瓶颈变成了选择。四个智能体各自带回一份 diff,两份是好的,一份方向对但还需要打磨,一份根本不该被写出来。慢的那一步,是判断哪份是哪份,并把活下来的那两份合并进去。

这和我训练自己去做的那份工作,完全不是一回事。打字变少,分诊变多;综合变少,选择变多。

这个周末的形态大致是这样:

• 周六上午:框定问题。哪四个问题值得四次并行尝试?每一个的成功标准是什么?一个可接受答案的大致形状是什么?
• 两天全程:抽查。智能体们在正轨上吗?有没有哪个在最初三十分钟里自信满满地写出了错误的东西?有没有谁卡住了?
• 两天的傍晚:评审和合并。diff 陆续送来,带着成功标准逐一阅读。合并达标的,对没达标的重跑或关闭,并记下这些失败尝试教会了我关于这个问题的什么东西。
• 周日结束时:写下这个周末交付了什么,以及接下来的四个问题是什么。

这更像是带着一支四人团队的技术负责人,而不是带着一个副驾驶的高级独立贡献者。它用到的是不同的肌肉,而这些肌肉在各个领域之间出奇地通用。

这和 .raku 文件如何结合

我们引擎运行的体验文件是 .raku 文件:JSON、带模式版本、可校验、可以像代码一样被评审。这个格式在设计之初就考虑到了这种并行智能体工作流。

当一个智能体编辑一个 .raku 文件时,diff 出现的方式和代码 diff 一模一样。第二个智能体可以评审第一个智能体的工作,我可以再跑第三个智能体去抽查两者。合并的决定权在我。整套流程都落在我用于运行时的同一套 pull request 纪律之内。

如果 .raku 曾经是一个二进制资产,这一切都不会成立。文件格式的选择和工作流的选择,是同一个架构决定的下游产物:体验就是代码,开发工作就是代码评审,智能体之所以能参与这个循环,是因为这个循环本身接受代码。

这个文件格式是承重的。它正是让团队能够通过智能体而非人头数来扩展规模的原因。

实践中真正有效的做法

我沉淀下来的三个模式。

第一:让智能体两两配对处理同一个问题。 当某件事不是那么简单的时候,两个训练背景不同的助手往往会产生富有成效的分歧。我让它们在各自的分支上用同一份提示词工作,然后 diff 它们的答案。分歧之处正是真正评审注意力该投入的地方。

第二:专门指定一个智能体做评审。 在任何一天,我都会让四个助手中的一个只做评审,它从不写初稿,只批判其他人产出的 diff。运行一个专职评审者的成本很小,而抓 bug 的比率相当可观。

第三:让智能体的上下文保持狭窄。 一个智能体处理单一分支上的单一问题时速度很快。一个智能体处理一个庞杂问题、背负五个小时的上下文,就会漂移,产出质量下降。解决办法是把问题拆成更小的部分,并频繁地轮换上下文。

哪些地方会出问题

诚实地说说哪些做法行不通。

协调开销是真实存在的。 两个智能体同时改同一个文件,会产生我必须解决的合并冲突。单次冲突的成本不大,但会累积。缓解办法:尽量让智能体处理不同的文件,并接受收敛这一步本身就是工作流的一部分。

评审疲劳是真实存在的。 在每天结束时评审四份 diff,比在四天里各自评审一份连续的 diff更累,决策的密度更高。在并行智能体的日子里,我会比工作串行时更早收工。

「什么都想留下」的诱惑是真实存在的。 当两个智能体都产出了看起来合理的东西时,偷懒的做法是两个都合并。有纪律的做法是只选一个。两个都合并,会让代码库里同时存在两种做同一件事的方式,这个代价比直接重跑淘汰掉输家还要高。

长时间运行的并行会话中的上下文漂移是真实存在的。 一个开着一整天的分支,会累积智能体在启动那一刻对代码库做出的种种假设。到了傍晚,这些假设可能已经过时。解决办法是果断地保持分支短命。

不是所有事情都能并行化。 带有微妙不变量的横切式重构,需要一次单独的、仔细的处理,而不是四次并行尝试。真正的技巧在于判断哪些问题能干净地拆分,哪些不能。有些日子仍然是串行的日子。

这对工程管理者意味着什么

如果你的团队正在用「串行模式外加 AI 加成」的方式工作,下一步不是「换一个更好的模型」,而是「同时使用多个智能体」。能力的天花板更高了,技能的天花板也更高了,而且它把高级角色的重心从生产转向了框定问题、验证和选择。这和我目前在其他每一个善用 AI 的领域里看到的发展方向是一致的。

未来两年里摸清并行智能体工作流的团队,和还在用串行模式的团队相比,会变得判若两队。变化的是工作的形态,不是工具本身。

两天里 112 次提交。周日合上笔记本电脑时,大多数都是绿色的。