停用 AI 一个月之后

一个二十分钟能做完的任务，交给 agent 只要五分钟。剩下的两天，他在等评审、切任务、回评论、看 CI、改格式。

这不是段子，是一个开发者对自己半年的复盘。他最后的结论是：并行 AI 带来的效率是幻觉，带来的疲惫是真的。

一、发生了什么

文章 9 月 25 日发在作者的个人博客。他在维护一个开源项目时已经禁止 AI 投稿，但在公司里照用不误，而且用得越来越深。

路径很典型：先是编辑器里的增强补全，然后是用模型生成测试和函数，接着把整张工单的描述贴进去让 agent 实现。再往后，他同时开多个 agent，放在不同的 git 工作树里，用命令行工具接上 Jira，让它们各自领任务。

问题从这里开始。

他发现自己说不清哪些改动是真正需要的。代码库对他本来就不熟，agent 说需要，他就信了。他估计自己和同事对自己推送的代码，理解程度可能不到两成。

更直接的是注意力。一个任务交给 agent，那三十分钟他切去干别的；同时开三个，就一直在切换。有的活本来二十分钟能做完，agent 五分钟给出结果，他花两天才真正交付，因为中间夹着别的任务、别的评审、别的等待。

还有一次，一个 agent 卡了三十分钟没出结果。他催了一句，二十秒就出来了。那半小时烧掉了三十美元的 token。

转折点是一次代码评审。同事指出，他那个 PR 里的测试根本没有测到这次改动的场景。他写了十年代码，做 TDD 出身，这种错误让他觉得丢人。他意识到自己已经失去了控制，而且靠「更严格地要求 AI」救不回来，因为被说服、变懒、变将就的是他自己。

一个月前，他停用了 AI。回到 TDD，回到只改五个文件的 PR，回到两行写完的 PR 描述。他说自己并没有比两个月前表现差，也不担心被裁。

二、跟你有什么关系

同时开多个 agent 的。 你的瓶颈不是生成速度，是评审带宽和上下文切换。生成快十倍，评审不会快十倍。

做代码评审的。 长篇 PR 描述会让人放松警惕。描述越流畅，越要直接看 diff。

带团队的。 如果所有人都只按回车，团队对系统的理解会一起变薄。这不是个人习惯问题，是组织风险。

三、怎么把节奏拿回来

1. 给并行设上限。 同一时间只开一个需要你决策的任务。agent 可以后台跑，但你的注意力不能分片。
2. 按「评审时间」而不是「生成时间」排期。 一个任务预计五分钟生成，就要预留半小时读代码、跑测试、写描述。排期只算前一半，必然延期。
3. 先写测试，再让 agent 改。 但测试必须由你确认它真的会失败。否则你得到的是一个永远通过的测试和一个没修好的 bug。
4. 把 PR 描述压短。 超过三段的描述通常是在替代码解释自己。让 diff 说话，说不清就说明改动太大。
5. 每周留半天完全手写。 挑一个你熟悉的小模块，自己改、自己提交。目的是保持「读代码—改代码—验证」这条链路不断。
6. 记录切换次数。 一天里你从一件事跳到另一件事几次？超过十次，基本可以确定问题不在工具，在安排。

四、三个别信的说法

「多开几个 agent 就是并行生产力。」 生成可以并行，判断不能。每个 PR 都要你读、你验、你负责，这部分是串行的。把串行的工作塞进并行的时间表，只会积压。

「AI 写的代码，评审一下就行。」 评审的前提是你有能力判断。作者的问题是，他已经看不懂某些改动了，评审变成了盖章。理解不能外包给评审环节。

「效率工具用得越多，产出越高。」 他那句「二十分钟的活花了两天」，就是产出被流程吃掉的例子。衡量单位应该是交付的功能，不是生成的代码行数。

五、一句话结论

AI 把写代码的时间压到几分钟，却把等评审、切上下文、重新理解的时间拉了回来；节奏不是被模型拖慢的，是被「同时做太多」拖慢的。

信息来源

• One month without AI，bustikiller，2026 年 9 月 25 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 19 日。