原文： Thoughts on Slowing the Fuck Down — Mario Zechner 发表于 2026 年 3 月 25 日
这是一篇让人读着读着就想拍桌子的文章。
不是因为赞同，而是因为每一段话都在刺痛那些我们都经历过、却假装没看见的东西。
我们都曾以为自己是例外
如果你用过 Cursor、Claude 或任何 AI 编码工具写过一个完整项目，你大概曾经有过这个念头：
“这东西效率太高了，我完全可以靠它十倍速产出。”
然后你继续写。一个文件接一个文件。agent 帮你搭架构、写接口、补测试——你像个乐队指挥一样，坐镇中央，挥一挥手就有一排排代码涌现。
你觉得自己是个天才管理者和一名高效产出者。
但作者告诉你一个残酷的事实：你只是把复杂性推迟了。
代理的问题，不是犯错，而是不会学习
文章里有一个比喻很妙：人类也会犯错，但人犯错之后会学习、会痛、会改。如果加班写出一堆屎山代码，半夜两点你会对着屏幕骂自己。
AI agent 不会。它不会痛。
同样的错误，它可以犯一千次，每次都用最新的热情把代码写得更烂一点。因为它的每次调用都是独立的——它没有记忆，没有懊悔，没有「我刚把这段逻辑搞砸了，这次不能再这样」的自我修正。
更致命的是：人类是瓶颈，这恰恰是好事。
一个人一天最多写几百行高质量代码。但一个 agent 可以在几小时内输出两万行。如果人写了烂代码，一天积累的烂东西有限。但如果一个 agent 军团在疯狂输出，那些「无害的小错误」会以指数级的速度叠加，直到有一天你回过头来发现——整个代码库已经没有一块你信任的地方了。
那种「一切都还可控」的幻觉
读这篇文章时，最击中的是这句：
You let them run free, and they are merchants of complexity.
我回想了一下过去写的一些 AI 辅助项目。是的，那些代码库确实变得很奇怪。到处都是「看上去像那么回事但总觉得哪里不对劲」的抽象层。有为了一个简单的 CRUD 封装了三层接口的，有在同一段逻辑里同时用了三种设计模式的。
你不敢改，因为看不懂它是怎么拼起来的。你怕一改全崩。
agent 替你搭建了一个自己也不理解的迷宫，而你发现你才是那个被困在里面的人。
那应该怎么办？
作者的建议不是「别用 AI」，而是慢下来。
这听起来可能是整篇文章里最不性感的建议。没有奇技淫巧，没有很酷的 prompt 模板，也没有所谓的人机协作黄金法则。就是：
慢。下。来。
- 架构自己画，不要丢给 agent
- API 设计自己写，agent 可以帮你补实现
- 设一个每天可接受的 agent 代码量上限——和你自己能真正 review 的能力匹配
- 该手写就手写，手写带来的摩擦感恰恰是你理解系统的过程
这就像做饭。你可以用预制菜十分钟做出一桌菜，但你永远不会知道食材在锅里发生的变化。有些感觉，跳过了就跳过了，不会再回来。
最后的刺
文章最后一段以这句话结尾（被我读到时差点笑出声）：
You can sleep well knowing that you still have an idea what the fuck is going on, and that you have agency.
对，睡得安稳。知道你写的代码到底在干什么。知道自己还有掌控权，而不是被你那支来路不明的 agent 军团绑架到一个自己也不认识的代码库里。
这是一篇写给每一个在 AI 浪潮中焦虑的人的文章。它不是在说「AI 不好」。它是在说：不要把自己交出去。
📝 思考题
读完这篇文章，检查一下自己是否真的理解了核心观点：
1. 作者认为 AI 编码 agent 犯的错误和人类犯的错误有什么本质区别？
2. 为什么说人类是瓶颈反而是一件好事？用文中的「booboo compounding rate」来解释。
3. 什么是 agentic search 的 low recall 问题？它如何导致代码重复和不一致的？
4. 「Merchants of learned complexity」是什么意思？agent 为什么特别容易制造过度复杂的设计？
5. 作者给出了哪些具体的「慢下来」的建议？你认为哪一条最实用？
6. 文中提到 AWS 的 AI 导致宕机事件和 Amazon 的"90 天重置"，结合上下文，你如何看待企业在生产环境中大规模部署 AI 编码的风险？
如果你还没读原文，强烈建议读一遍。它不长，但每一段都值得停下来想想。