关于放慢节奏的思考 -- { Mario Zechner }这篇文章写了作者对目前Agent编码的反思。原文题目：Thoughts on slowing the fuck down
2026-03-25图中乌龟的表情就是我看待我们行业的样子
自从可以真正构建完整项目的编码Agent出现，已经过去大约一年。之前也有一些前身，比如 Aider 和早期的 Cursor，但它们更像是助手而非Agent。新一代Agent非常诱人，我们很多人都花了大量空闲时间构建那些一直想做却没时间做的项目。
我认为这没问题。用空闲时间创造东西非常享受，而且大多数情况下你无需过于关心代码质量和可维护性。这也为你提供了学习新技术栈的机会。
在圣诞假期期间，Anthropic 和 OpenAI 都发放了一些免费资源，吸引人们体验他们的“上瘾式老虎机”。对很多人来说，这是第一次感受到Agent式编码的魔力。参与的人越来越多。
编码Agent现在也被引入到生产代码库中。经过 12 个月，我们开始看到所有这些“进步”的效果。以下是我当前的看法。
一切都坏掉了
虽然这些都是轶事，但软件似乎已经变成了脆弱的混乱，98% 的正常运行时间成为常态而非例外，包括大型服务。用户界面出现的 bug 古怪至极，按理 QA 团队应该捕捉到。我承认这在Agent出现之前就存在，但现在似乎在加速。
我们无法接触公司内部情况，但偶尔会有一些情况被新闻记者曝光，比如据称 AI 导致的 AWS 停机，AWS 立刻“修复”，随后内部进行 90 天重置。
微软 CEO Satya Nadella 一直在谈论 AI 在微软写了多少代码。虽然没有直接证据，但确实有一种感觉：Windows 正在走下坡路。微软自己似乎也认同这一点，从这篇博客文章可见一斑。
声称产品代码 100% 由 AI 编写的公司，总是产出最糟糕的垃圾。不是在指责，但内存泄漏动辄数 GB，UI 错误、功能损坏、崩溃：这不是他们想象的质量标志，也绝不是广告宣传的“Agent帮你完成一切”的好宣传。
从行业内部传来消息，越来越多公司（无论大小）的人说他们通过Agent编码把自己逼入死角。没有代码审查，设计决策交给Agent，无数没人需要的功能。这就是原因。
我们不该如何与Agent协作以及原因
我们基本上放弃了所有纪律和自主性，沉迷于一种追求：在最短时间内产出最多代码。后果无所谓。
你在构建一个用于指挥自主Agent军队的编排层。你安装了 Beads，却完全没意识到它几乎是无法卸载的恶意软件。网上告诉你要这么做，你就照做。你把自己套入了循环。Anthropic 用Agent群体构建了一个 C 编译器，有些破损，但下一代 LLM 一定能修复。Cursor 用Agent大军构建了浏览器，当然它不完全可用，需要人偶尔干预，但下一代 LLM 一定能解决问题。分发、拆分、自治、暗工厂、软件六个月内搞定。SaaS 死了，我奶奶让 Claw 自己建了 Shopify！
对于几乎无人使用的个人项目，这种方式或许可行。如果有人能让这种方法适用于真正被人使用的软件产品，那更好。
如果是你，那就尽管去做。但在我同行圈内，我尚未见到这种方法有效的证据。也许我们都有技能问题。
错误叠加却没有学习、没有瓶颈、痛苦延迟
Agent的问题在于它会犯错。这没关系，人类也会犯错。可能只是正确性错误，容易识别和修复。加上回归测试效果更佳。或者是代码气味，你的 linter 没发现的。单独看，这些都是无害的。人类也会犯这种错。
但 Agent 不是人类。人类犯错几次后会学会不再犯，要么有人训斥，要么自身在学习路径上。
Agent没有这种学习能力，至少开箱即用时没有。它会一遍又一遍地犯同样的错误，根据训练数据，甚至可能创造出新的错误组合。
你可以尝试教Agent，在 AGENTS.md 里告诉它别再犯同样错误，或者设计复杂记忆系统查找历史错误和最佳实践。这对特定类别错误有效，但需要你观察Agent犯错。
更重要的区别是，人类是瓶颈。人类不可能在几小时内输出两万行代码。即使频繁犯错，每天引入的错误有限。错误累积缓慢，如果痛苦太大，人类会花时间修复，或者被解雇由他人修复。痛苦就消失了。
有了Agent军团，没有瓶颈、没有人类痛苦，这些小错误会以无法承受的速度累积。你脱离了循环，不知道这些无害的错误已经形成了庞大的代码怪物，痛苦只在为时已晚时显现。
某天你想增加新功能，但架构大部分都是错误，Agent无法有效修改，或者用户因最新版本出问题丢失数据而尖叫。
你意识到无法再信任代码库。更糟的是，你让 clanker 写的无数单元、快照和端到端测试同样不可靠。唯一可靠的方式就是手动测试。恭喜，你害了自己（和公司）。
学到的复杂性的商人
你完全不清楚发生了什么，因为把一切自主权交给了Agent。它们是复杂性的商人。它们在训练数据和 RL 训练中见过很多糟糕架构决策，你让它们来架构应用，结果就是：
极其复杂的混合体，由可怕的“行业最佳实践”堆砌而成，你没来得及控制。更糟的是，你的Agent彼此看不到对方的执行，无法查看完整代码库或之前的决策。因此，Agent决策总是局部的，导致上述错误。大量代码重复，为抽象而抽象。
这些累积成无法恢复的复杂混乱。就像人类企业代码库一样。人类企业代码库之所以如此，是因为痛苦分散在大量人身上，个体无法触发“必须修复”阈值。个体可能无力修复，而组织有极高痛苦耐受力。人类企业代码库需要多年才能达到这种状态，组织随着复杂性缓慢演化并学习应对。
有了Agent和两名人类团队，你可能在几周内达到这种复杂度。
Agent搜索的召回率低
你希望Agent修复、重构代码，但它们应对不了。因为代码库和复杂度太大，Agent只能局部查看。
不仅仅是上下文窗口或长序列注意力机制的问题。更微妙的是，在Agent尝试修复前，它必须找到所有需更改的代码和可复用代码，即所谓Agent搜索。工具不同，方法不同：Bash、可查询代码库索引、LSP 服务、向量数据库。最终，代码库越大，召回率越低。低召回意味着Agent不会找到所有需修改的代码。
这也是代码气味错误产生的原因。Agent遗漏现有代码，重复、引入不一致，进而形成复杂的“糟糕花”。
如何避免这些问题？
我们该如何与Agent协作（至少目前我是这么认为的）
编码Agent像海妖，以惊人的生成速度和不稳定智能诱你入网，完成简单任务时速度快且质量高。问题出在你想：“天哪，这太棒了，电脑帮我做吧！”
显然，把任务交给Agent没问题。合适的任务特点：范围可控，不需理解完整系统；循环闭合，Agent能评估自己工作；输出非关键，仅是临时工具或内部软件，没人生命或收入依赖；或者仅是橡皮鸭讨论，让想法与网络与训练数据的压缩智慧碰撞。只要满足条件，你找到了完美任务，前提是你作为人类是最终质量把关。
Karpathy 的自动研究用来加速应用启动？很好，只要你明白输出代码根本不适合生产。自动研究可行，因为你给它一个评价函数，让Agent根据指标（如启动时间或 loss）评估工作。但评价函数仅捕获狭隘指标，Agent会忽略其他指标，如代码质量、复杂性，甚至正确性。
关键是：让Agent做枯燥、不会教你新知识的事情，或尝试你没时间尝试的方案。然后评估它的成果，取合理正确的想法，完成最终实现。最终步骤也可用Agent辅助。
我建议，放慢节奏才是正道。给自己时间思考真正想做什么、为什么做。给自己机会说：“不，我们不需要这个。”限制每天让 clanker 生成的代码量，按你能审查的能力设定。
系统的总体设计、架构、API 等核心部分，手写完成。可以用 tab 补全感受怀旧，或与Agent结对编程。亲自编码，逐步构建，增加摩擦，帮助你理解要构建什么以及系统“感觉”。这是经验和品味发挥作用的地方，是当前 SOTA 模型无法替代的。放慢节奏，经历摩擦，让你学习和成长。
最终，你会得到可维护的系统和代码库，至少和Agent出现前的老系统一样可维护。用户会感谢你，产品带来愉悦而非垃圾。功能更少，但更恰当。学会说“不”本身就是一种能力。
你可以安心，因为你仍然了解发生了什么，并掌握自主权。理解能力可解决Agent搜索的召回问题，生成更可靠输出，减少修改量。如果出问题，你能亲自修复；设计不佳，你知道原因并能重构改善。有或没有Agent，都无所谓。
所有这一切需要纪律和自主权。
所有这一切都需要人类。
How I AI
