AI 写代码越来越快,怎么人反而更累了?

Anthropic 最近发了一篇工程文章，讲他们为什么要重新做一套代码管理系统。

按照他们公布的数据，内部每天合并的代码变更，从今年 5 月的大约 2,500 次，增长到了 9 月的超过 30,000 次。代码产出上去了，原有的开发基础设施开始跟不上，他们便用五个月，把主代码仓库从 Git 迁移到了自建系统 Scion。

普通开发者大概不用担心这个规模的问题。Anthropic 也说了，这套方案不适合拿来普遍替代 Git。

不过，看到“代码写得太快，后面接不住”这件事，我想到了最近看到的一些吐槽。

有了 AI，怎么反而更累了？

有人说，比当牛马还累。听起来是句玩笑，但我觉得里面有一点挺真实的疲惫。

最近看到 GPT 额度重置的消息挺频繁，也看到有人为了“不亏”，努力把额度用完。

原本是有事情要做，才打开 AI。后来变成额度还剩着，得找点事情让它做。

一个任务跑着，再开一个。这个功能做好了，顺手补另一个。眼看额度又要重置，停下来还有点舍不得。

这有点像买了自助餐，已经吃饱了，想到还有几样没尝，又站起来拿了一盘。

钱花了，想多用一点，很容易理解。但用 AI 还有一笔不太显眼的投入：自己的注意力。

任务可以同时跑，结果却要有人看。AI 问了一个问题，要回复；改了一批文件，要检查；方向走偏了，还得把它拉回来。

额度用掉了，人的晚上也用掉了。

我觉得，“有 AI 反而更累”的一部分原因就在这里。工具让我们更容易开始一件事，也让人更难觉得今天已经做得够多了。

而且，AI 交回来的东西，未必只有你要的那些。

这一点，我最近也有感受。

明明只需要一个简单功能，它却很容易给你做成一套系统。很多自己没想到的场景，它都补上了，考虑得似乎很周全。

但那些场景，当下真的需要吗？

比如一个只给自己用的小工具，能把眼前的事情处理好，就已经够用了。至于以后会不会有更多用户、会不会接入别的平台，可以等遇到时再决定。

AI 有时会把这些“以后可能需要”提前做进去。单独看，每一项似乎都有理由。合在一起，却让原本简单的东西变得难懂。

这也是我对过度设计最直接的不适：我只是想解决一个问题，却要先花时间理解它替我增加的那些东西。

多出来的功能要不要留？几个模块为什么这样分？删掉一部分，会不会影响其他地方？

这些都得重新弄清楚。

AI 生成它们可能很快，我理解它们却没有那么快。尤其当实现已经铺开，文件也建好了，再决定哪些不要，还要额外花一轮精力。

Anthropic 的那篇文章里，恰好也提到了类似的问题。

他们说，工程师经常需要对 Claude 说“不”，其中一种情况，就是阻止它因为假设中的风险而增加过多的校验和复杂度。

连开发 Claude 的团队，也在处理这件事。

这倒让我觉得，对 AI 的结果不满意，不一定是因为它做得不够。有时候恰恰是做得太多，超出了这次任务真正需要的范围。

我们很容易注意到它漏了什么，却不太容易认真检查它多做了什么。毕竟“考虑周全”听起来总是件好事。

可对一个具体项目来说，多出来的代码和功能，最后都会成为需要理解、检查和维护的东西。现在用不上，也不代表留着没有成本。

把这两件事放在一起，就更容易理解那种疲惫了。

一边想着别浪费额度，不断增加任务；另一边又要消化 AI 超额交付的结果。看着屏幕上一直有进度，自己也一直在忙，却未必离最初想完成的事情更近。

我还是觉得，AI 能帮开发者省下很多时间。只是这些时间不会自动变成休息。

如果省下一个小时，马上又给自己安排两个小时的任务，那忙碌大概还会继续。再好的工具，也很难替我们决定什么时候可以停下来。

对我来说，现在更想把“这次只做到哪里”说清楚。眼前需要的功能做好、验证能用，就先停在这里。其他想法可以记下来，不急着全部实现。

至于剩下的额度，如果今天确实没什么要做的，让它剩着也没关系。

总不能为了不浪费 AI 的额度，把自己的精力都搭进去。