关于 Slowing the Fuck Down 的一些思考
关于 Slowing the Fuck Down 的一些思考
作者：Mario Zechner 日期：2026-03-25 原文：Thoughts on slowing the fuck down
这只乌龟的表情就是我看着这个行业时的样子
目录
编程 Agent 出现在这个领域已经大约一年了，它们真的能帮你构建完整的项目。之前有 Aider 和早期的 Cursor 这样的前身，但它们更像是助手而非 Agent。新一代产品很诱人，我们中的很多人花了大量业余时间来构建那些一直想做但从来没时间做的项目。
我觉得这没什么问题。用业余时间做东西是超级享受的事，而且大多数时候你不需要真的在乎代码质量和可维护性。如果你愿意的话，这也是学习新技术栈的一种方式。
圣诞假期期间，Anthropic 和 OpenAI 都发放了一些免费额度来让人们对它们令人上瘾的老虎机上钩。对很多人来说，这是他们第一次体验到 Agent 编程的魔力。入坑的人越来越多了。
编程 Agent 现在也被引入到生产代码库中了。12 个月过去了，我们正开始看到所有这些「进步」的后果。以下是我目前的看法。
一切都坏了
虽然这些都是轶事性的，但确实感觉软件已经变成了一团脆弱的烂摊子，98% 的正常运行时间正在成为常态而非例外——包括大型服务在内。而且用户界面出现了一些 weirdest fucking bugs，你本以为 QA 团队会抓到这些问题。我承认这种情况在 Agent 出现之前就已经存在了。但我们似乎在加速恶化。
我们无法接触到公司的内部信息。但偶尔有些东西会泄露给某个新闻记者。比如这个据称是 AI 导致的 AWS 宕机事件。AWS 立即进行了「纠正」。然后又在内部跟进了一个 90 天的整改计划。
微软 CEO Satya Nadella 一直在吹嘘微软现在有多少代码是由 AI 编写的。虽然我们没有直接证据，但确实感觉 Windows is going down the shitter。微软自己似乎也同意这一点，看看这篇精彩的博客文章就知道了。
那些声称 100% 产品代码由 AI 编写的公司，一致地推出了你能想象到的最烂的垃圾。我不是在指名道姓，但动辄几个 GB 的内存泄漏、UI 故障、broken-ass features、频频崩溃：这可不是他们自以为的质量标杆。这肯定也不是「让 Agent 替你干所有活」这个 fever dream 的好广告。
通过小道消息，你能听到越来越多来自大大小小软件公司的人说，他们已经用 Agent 把自己编进了死胡同。没有代码审查，设计决策委托给 Agent，搞出了一大堆没人要求的功能。That'll do it。
我们不应该怎样和 Agent 协作，以及为什么
我们基本上已经放弃了所有的纪律和自主权，换来了一种瘾——你的最高目标是在最短时间内产出最多的代码。Consequences be damned。
你在构建一个编排层来指挥一支自主 Agent 大军。你安装了 Beads，完全没意识到它基本上是一个卸不掉的恶意软件。互联网告诉你该这么做的。这才是你应该的工作方式，不然你就 ngmi。你在 ralphing the loop。看，Anthropic 用一群 Agent 构建了一个 C 编译器。是有点问题，但下一代 LLM 肯定能修好。Oh my god，Cursor 用一个 Agent 军团构建了一个浏览器。是的，当然，它并没有真的能用，而且需要一个人类时不时地转一下方向盘。但下一代 LLM 肯定能修好的。Pinky promise！分布式、分而治之、自主性、dark factories、软件在接下来 6 个月内就会被解决。SaaS is dead，我奶奶刚让她的 Claw 给她搭了个自己的 Shopify！
再说一遍，这对你那个几乎没人用（包括你自己）的副项目可能行得通。嘿，也许世界上真有某个人能让这一套真正用在一个不是 a steaming pile of garbage、并且被真实用户在生产中使用的软件产品上。
如果那个人是你，more power to you。但至少在我的同行圈子里，我还没有找到这种方式行得通的证据。Maybe we all have skill issues。
零学习、无瓶颈、延迟痛感下的 booboo 复利
Agent 的问题在于它们会犯错。这没什么，人类也会犯错。也许只是正确性错误。容易发现和修复。再加一个回归测试就更好了。或者也许是你的 linter 抓不到的 code smell。这里一个没用的方法，那里一个没意义的类型，那边一段重复的代码。单独来看，这些是无害的。人类也会犯这种 booboos。
但 clankers 不是人类。人类犯同样的错误几次后，最终会学会不再犯。要么是因为有人开始冲他们吼，要么是因为他们在真正地学习成长。
Agent 没有这样的学习能力。至少开箱即用的状态下没有。它会不断地一遍又一遍犯同样的错误。根据训练数据的不同，它还可能搞出不同错误的精彩混搭插值。
你当然可以尝试教你的 Agent。在你的 AGENTS.md 里告诉它不要再犯那个 booboo。设计最复杂的记忆系统，让它查阅以前的错误和最佳实践。这对某些特定类别的错误确实有效。但这也要求你真的观察到 Agent 犯了那个错误。
clanker 和人类之间有一个更重要的区别。人类是一个瓶颈。人类无法在几个小时内 shit out 2 万行代码。即使人类以很高的频率犯这些 booboos，一个人一天能往代码库里引入的 booboos 也就那么多。这些 booboos 的复利增长速度会非常慢。通常，如果 booboo 带来的痛苦太大了，讨厌痛苦的人类就会花时间去修复这些 booboos。或者这个人被开了，换个人来修。总之痛苦会消失。
而用一支编排好的 Agent 大军，就没有瓶颈了，没有人类的痛苦。这些小小的无害的 booboos 突然以一种不可持续的速率开始复利增长。你已经把自己从循环中移除了，所以你甚至不知道所有这些无辜的 booboos 已经形成了一个代码库怪物。你只有在为时已晚的时候才会感受到痛苦。
然后有一天你转过身想添加一个新功能。但架构——此时基本上就是由 booboos 组成的——不允许你的 Agent 大军以可运行的方式做出更改。或者你的用户在冲你大喊大叫，因为最新版本出了问题并删除了一些用户数据。
你意识到你再也不能信任这个代码库了。更糟糕的是，你意识到你让 clankers 写的那成千上万的单元测试、快照测试和端到端测试同样不可信。唯一还能可靠衡量「这东西能不能用」的办法就是手动测试产品。Congrats, you fucked yourself（和你的公司）。
习得性复杂度的贩卖者
你 have zero fucking idea 到底发生了什么，因为你把所有的自主权都委托给了你的 Agent。你让它们自由发挥，而它们是复杂度的贩卖者。它们在训练数据和强化学习训练过程中见过了无数糟糕的架构决策。你让它们来设计你的应用架构。猜猜结果是什么？
巨量的复杂度，一堆可怕的 cargo cult "industry best practices" 的大杂烩，你没有在为时已晚之前加以控制。But it's worse than that。
你的 Agent 永远看不到彼此的运行结果，永远无法看到你的全部代码库，永远无法看到你或其他 Agent 在做出变更之前所做的所有决策。因此，Agent 的决策始终是局部的，这正好导致了上面描述的那些 booboos。大量的代码重复，abstractions for abstractions' sake。
所有这些复利累积成一团不可恢复的复杂度灾难。与你在人类编写的企业代码库中看到的一模一样。那些代码库之所以走到那一步，是因为痛苦分散在大量的人身上。个体的痛苦没有达到「我需要修这个」的阈值。这个人甚至可能没有修复问题的手段。而组织对痛苦的容忍度极高。但人类编写的企业代码库需要数年才能走到那一步。组织以一种 demented kind of synergy 与复杂度一起慢慢演化，并学会如何应对它。
而用 Agent 加上一个 2 人团队，你几周之内就能达到那种复杂度。
Agent 搜索的召回率很低
所以现在你寄希望于你的 Agent 能修复这团混乱，重构它，让它变得整洁。但你的 Agent 也无法处理它了。因为代码库和复杂度太大了，而它们始终只有这团混乱的局部视野。
我说的不只是上下文窗口大小或者长上下文注意力机制在面对 100 万行代码的怪物时的失败。那些是明显的技术限制。It's more devious than that。
在你的 Agent 能尝试修复这团混乱之前，它需要找到所有需要修改的代码，以及所有可以复用的现有代码。我们称之为 agentic search。Agent 如何做到这一点取决于它拥有的工具。你可以给它一个 Bash 工具，让它用 ripgrep 搜索整个代码库。你可以给它一个可查询的代码库索引、一个 LSP 服务器、一个向量数据库。最终差别不大。代码库越大，召回率越低。低召回率意味着你的 Agent 实际上找不到它做好工作所需的全部代码。
这也是那些 code smell booboos 一开始就会出现的原因。Agent 遗漏了已有的代码，重复造轮子，引入不一致性。然后这些东西就绽放成一朵美丽的 shit flower of complexity。
我们怎样才能避免这一切？
我们应该怎样和 Agent 协作（目前我是这么想的）
编程 Agent 是 sirens（塞壬海妖），用它们的代码生成速度和 jagged intelligence 来引诱你，经常以令人目不暇接的速度高质量地完成一个简单任务。当你开始想：「Oh golly, this thing is great. Computer, do my work!」的时候，事情就开始崩坏了。
把任务委派给 Agent 显然没什么问题。好的 Agent 任务有几个共同特征：它们的范围可以被界定，这样 Agent 就不需要理解整个系统。循环可以闭合，也就是说，Agent 有办法评估自己的工作。输出不是 mission critical 的，只是一些临时工具或者内部软件，没有人的命或收入取决于它。或者你只是需要一只 rubber duck 来碰撞想法，基本上就是把你的想法与互联网和合成训练数据的压缩智慧碰一碰。如果以上任何一条适用，你就为 Agent 找到了完美的任务，前提是作为人类的你是最终的质量关卡。
Karpathy 的 auto-research 被应用于加速你的应用启动时间？Great！只要你理解它吐出来的代码完全不是 production-ready 的。auto-research 之所以有效，是因为你给了它一个评估函数，让 Agent 能根据某些指标（比如启动时间或 loss）来衡量自己的工作。但那个评估函数只捕捉了一个非常狭窄的指标。如果你的评估函数是 foobar，Agent 会高高兴兴地忽略评估函数没捕捉到的任何指标，比如代码质量、复杂度，甚至正确性。
关键是：让 Agent 做无聊的事情，那些不会教你任何新东西的事情，或者尝试你原本没时间做的不同方案。然后你评估它的产出，采纳那些确实合理且正确的想法，并最终完成实现。是的，当然，你也可以用 Agent 来做最后那个步骤。
我想建议的是：slowing the fuck down 才是正道。给自己时间想想你到底在构建什么、为什么要构建。给自己一个机会说，fuck no, we don't need this。给自己设定限制，限制你每天让 clanker 生成多少代码，使之与你实际审查代码的能力相匹配。
任何定义你系统 gestalt 的东西——也就是架构、API 等等——都要手写。也许用用 tab 补全，来点怀旧感。或者和你的 Agent 结对编程。身处代码之中。因为必须亲自编写、或者看着它一步步被构建起来这个简单的行为，会引入一种摩擦力，让你更好地理解你想要构建什么，以及系统的「感觉」如何。这就是你的经验和品味发挥作用的地方，这是当前 SOTA 模型还无法替代的。而 slowing the fuck down，忍受一些摩擦力，正是让你学习和成长的方式。
最终的结果将是持续可维护的系统和代码库，至少和我们在 Agent 出现之前的老系统一样可维护。是的，那些也不完美。你的用户会感谢你，因为你的产品现在 sparks joy 而不是 slop。你会构建更少的功能，但是正确的功能。学会说不本身就是一种能力。
你可以安心入睡，因为你知道你仍然了解 what the fuck is going on，而且你有自主权。你的理解力让你能修复 agentic search 的召回率问题，从而得到更好的 clanker 输出，需要更少的打磨。如果 shit hits the fan，你能够亲自去修复。或者如果你最初的设计不够理想，你理解为什么不理想，以及如何将其重构成更好的东西。用不用 Agent，don't fucking care。
这一切都需要纪律和自主权。
这一切都需要人类。
If you read this far — thank you.
Come tell me what you thought on X.