关于放慢脚步的思考

# 关于放慢脚步的思考 来源：https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/ 2026\-03\-25 乌龟的表情就是我看待我们行业现状的模样——一切都乱套了（https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/#toc_0） - 我们为何不该这样使用智能体以及原因所在（https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/#toc_1） - 零学习、无瓶颈、痛苦延迟导致错误不断累积（https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/#toc_2） - 复杂性问题的推手（https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/#toc_3） - 智能体搜索的召回率低下（https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/#toc_4） - 我们目前应该如何与智能体协作（https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/#toc_5） 大约一年前，真正能帮你构建完整项目的编程智能体出现了。虽然像 Aider 和早期 Cursor 这样的先驱产品已经存在，但它们更偏向辅助工具而非智能体。新一代产品极具吸引力，我们很多人花费了大量业余时间构建那些一直想做却没时间完成的项目。 我认为这挺好。利用空闲时间创造东西非常享受，而且大多数时候你确实不需要过于关心代码质量和可维护性。如果你想学习新技术栈，这也是一个不错的途径。 在圣诞假期期间，Anthropic 和 OpenAI 都推出了免费套餐，诱使人们沉迷于他们那令人上瘾的“老虎机”。对很多人来说，这是他们第一次体验到智能体编程的魔力。这个群体正在不断扩大。 编程智能体现在也被引入生产代码库。经过12个月，我们现在开始看到所有这些“进步”带来的影响。以下是我目前的看法。 ## 一切都乱套了 虽然这些都只是坊间轶事，但确实感觉软件变得脆弱不堪，98%的正常运行时间成了常态而非例外，大型服务也不例外。用户界面也出现了极其怪异的 bug，你会觉得 QA 团队本该能发现。我承认这种情况在智能体出现之前就存在了，但我们似乎正在加速恶化。 我们无法了解公司内部情况，但偶尔会有些情况泄露给记者。比如这次所谓的AI引发的 AWS（https://www.ft.com/content/00c282de-ed14-4acd-a948-bc8d6bdb339d）宕机事件。AWS 随即“纠正”（https://www.aboutamazon.com/news/aws/aws-service-outage-ai-bot-kiro）了报道，但随后内部又跟进了一份90天整改（https://www.businessinsider.com/amazon-tightens-code-controls-after-outages-including-one-ai-2026-3）。 微软 CEO Satya Nadella 一直高谈阔论（https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-30-of-the-companys-code-written-by-ai/）微软有多少代码是 AI 编写的。虽然我们没有直接证据，但确实感觉 Windows 系统越来越糟。微软自己似乎也同意这个观点，这从这篇精彩的博文（https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/）就能看出。 那些宣称产品100%代码由 AI 编写的公司，其产品质量往往糟糕透顶。不是针对谁，但以 GB 级的内存泄漏、UI 故障、功能损坏、程序崩溃为特征——这绝非他们自以为的品质保证。这也不是为“让智能体为你完成所有工作”的美好幻想所做的良好广告。 从消息灵通人士处获悉，越来越多大大小小的软件公司表示，他们通过智能体编程把自己逼进了死胡同：没有代码审查，设计决策委托给智能体，堆砌了无数无人需要的功能。这迟早会出问题。 ## 我们为何不该这样使用智能体以及原因所在 我们基本上放弃了所有纪律和自主权，陷入一种成瘾状态，将短时间产出最多代码奉为最高目标，后果不管不顾。 你正在构建一个编排层来指挥一支自主智能体大军。你安装了 Beads，完全没意识到这基本上是个无法卸载的恶意软件。网上都这么说。你就该这么干，否则你就落伍了。你在机械循环。听着，Anthropic 用智能体集群构建了一个 C 编译器。虽然有点问题，但下一代 LLM 肯定能修复它。天啊，Cursor 用一队智能体构建了浏览器。当然，它确实不太好用，需要人工时不时干预一下。但下一代 LLM 一定会解决的，保证！分布式、分治、自主、黑灯工厂，软件问题6个月内就能解决。SaaS 已死，我奶奶刚用她的 Claw（原文为 Claw，可能指某种工具）为自己搭了个 Shopify！ 再说一次，这或许对你的个人项目有用——反正没几个人用，包括你自己。嘿，也许真有人能用这种方法做出不是一坨垃圾、真正被人类实际使用的产品软件。 如果那是你，那你很棒。但至少在我认识的人中，我还没发现这种方法行之有效的证据。也许我们都有技能问题。 ### 零学习、无瓶颈、痛苦延迟导致错误不断累积 智能体的问题在于它们会犯错。这没关系，人类也会犯错。可能只是正确性错误，容易识别和修复。加上回归测试就更保险了。也可能是代码异味（code smell），你的静态分析工具没抓出来。这里一个无用方法，那里一个类型定义不合理，那边重复的代码。单独看，这些都无伤大雅。人类也会犯这种小错。 但智能体不是人类。人类犯几次同样的错误后，最终会学着不再重蹈覆辙。要么因为有人冲他们吼，要么因为他们确实在学习。 智能体没有这种学习能力，至少开箱即用时没有。它会一遍又一遍重复同样的错误。根据训练数据，它还可能“创造”出各种错误的新奇组合。 当然，你可以尝试“教育”你的智能体。在你的 AGENTS.md 文件里告诉它别再犯这个错。设计一套极其复杂的记忆系统，让它能查阅以往的错误和最佳实践。这对特定类别的错误可能有效。但前提是你确实观察到了智能体犯这个错。 智能体和人类还有一个更重要的区别。人类是瓶颈。人类不可能在几小时内吐出两万行代码。即使人类犯错频率很高，每天能引入代码库的错误数量也是有限的。错误会以非常缓慢的速度累积。通常，如果错误造成的痛苦变得太大，讨厌痛苦的人类会花时间修复错误。或者人类被开除，由别人来修复。于是痛苦就消失了。 但由一群智能体组成的“大军”没有瓶颈，也没有人类的痛苦感知。这些原本无害的小错误突然以不可持续的速度累积起来。你把自己从循环中移除了，甚至不知道这些看似无害的小错已经汇聚成了代码库的怪物。你感受到痛苦时，一切都晚了。 直到有一天你转身想添加一个新功能。但此时的架构——基本上已是错误的集合体——不允许你的智能体大军以正常方式做出修改。或者你的用户因为最新版本破坏了某些功能、删除了用户数据而对你大发雷霆。 你意识到你不再能信任这个代码库了。更糟的是，你发现当初让智能体编写的海量单元测试、快照测试和端到端测试同样不可信。唯一还能可靠衡量“这东西能用吗”的方法，就是手动测试产品。恭喜，你把自己（和你的公司）坑惨了。 ### 复杂性问题的推手 你对代码库里的状况一无所知，因为你把所有自主权都交给了智能体。你放任它们自由行事，而它们正是复杂性的推手。它们在训练数据和强化学习过程中见识过许多糟糕的架构决策。你让它们来设计你的应用架构。猜猜结果是什么？ 海量复杂性，是糟糕的“行业最佳实践”盲目模仿的大杂烩，而你没能在为时已晚前加以约束。但情况比这更糟。 你的智能体看不到彼此的运行记录，看不到整个代码库，也看不到你或其他智能体在做出修改前所做的所有决策。因此，智能体的决策总是局部的，这就导致了上文描述的问题。海量代码重复，为抽象而抽象的抽象层。 所有这些累积起来，就成了无法挽回的复杂性噩梦。这与你在人类编写的企业代码库中发现的混乱如出一辙。人类代码库之所以演变成那样，是因为痛苦分散在大量人员身上。个体的痛苦没有达到“我必须修复它”的阈值。个体甚至可能无力修复。而组织对痛苦的耐受度极高。但人类编写的企业代码库需要数年才会变成那样。组织与复杂性在一种病态的协同中缓慢演变，并学会如何与之共处。 而依靠智能体和两名人类成员的团队，几周内就能达到同等复杂度。 ### 智能体搜索的召回率低下 现在你希望智能体能修复这个烂摊子，重构代码，使其恢复纯净。但你的智能体也无法处理了。因为代码库和复杂性过于庞大，而它们对混乱的认知始终是局部的。 我指的不仅是上下文窗口大小限制，或是长上下文注意力机制在面对百万行代码怪兽时失效的问题。这些是明显的技术局限。情况比这更隐蔽。 在智能体尝试修复混乱之前，它需要找到所有需要修改的代码以及所有可以复用的现有代码。我们称之为“智能体搜索”。智能体如何执行搜索取决于它拥有的工具。你可以给它 Bash 工具，让它能用 ripgrep 遍历代码库。也可以给它一个可查询的代码库索引、一个 LSP 服务器、一个向量数据库。但归根结底差别不大。代码库越大，召回率越低。低召回率意味着智能体实际上找不到完成高质量工作所需的所有代码。 这也是为什么那些代码异味错误会首先出现。智能体遗漏了现有代码，重复造轮子，引入了不一致性。然后它们就绽放成了一朵由复杂性构成的绝美“屎之花”。 我们如何避免这一切？ ## 我们目前应该如何与智能体协作 编程智能体是塞壬女妖，用其代码生成速度和粗糙的智能引诱你入局，常常能以极快速度高质量完成简单任务。但当你想：“天啊这东西太棒了。电脑，替我工作吧！”事情就开始分崩离析了。 显然，将任务委托给智能体本身并无问题。好的智能体任务具有几个共性：可以划定范围，让智能体无需理解整个系统；闭环可验证，即智能体有办法评估自己的工作；输出并非关键任务，只是一些临时工具或内部软件，不关乎用户生计或公司营收；或者你只是需要个“橡皮鸭”来碰撞想法——这本质上是用互联网和合成训练数据的压缩智慧来测试你的想法。如果符合以上任一条件，你就找到了适合智能体的完美任务，前提是作为人类的你是最终的质量守门人。 Karpathy（https://x.com/karpathy）的 auto\-research（https://github.com/karpathy/autoresearch）用于加速应用启动时间（https://x.com/badlogicgames/status/2035469013480869912）？很棒！只要明白它吐出的代码完全不适合生产环境。auto\-research 之所以有效，是因为你给了它一个评估函数，让智能体能根据某些指标（如启动时间或损失函数）衡量其工作。但该评估函数只捕捉了一个非常狭窄的指标。智能体会欣然忽略评估函数未涵盖的指标，比如代码质量、复杂性甚至正确性，只要你的评估函数有缺陷。 关键在于：让智能体做无聊的活儿，那些不会教你新东西的事情，或者尝试一些你本没时间做的不同方案。然后你评估它的产出，挑出其中真正合理且正确的部分，并完成最终实现。当然，最后一步也可以用智能体。 我建议，放慢脚步才是正道。给自己时间思考你究竟在构建什么以及为什么构建。给自己机会说：去他妈的，我们不需要这个。根据你实际审查代码的能力，限制智能体每天生成的代码量。 所有定义系统整体形态的东西——架构、API 等等——都应该手动编写。也许可以利用代码补全功能找回些怀旧感觉。或者和你的智能体进行结对编程。要亲手写代码。因为必须亲手构建或看着它逐步搭建起来的行为本身会引入摩擦，这能让你更理解你想构建什么，以及系统“感觉”如何。这正是你的经验和品味发挥作用的地方，是当前顶尖模型尚无法替代之处。而放慢脚步、承受一些摩擦，才能让你学习成长。 最终结果将是系统和代码库保持可维护性，至少与智能体出现前的旧系统一样可维护。是的，旧系统也不完美。你的用户会感谢你，因为你的产品现在带来愉悦而非垃圾。你会构建更少的功能，但都是正确的。学会说“不”本身就是一种能力。 你可以安然入睡，因为你依然清楚发生了什么，并且拥有自主权。你的理解力有助于解决智能体搜索的召回率问题，从而获得更好的智能体输出，减少后期调整。万一出了乱子，你能介入修复。或者如果你的初始设计存在不足，你能明白为何不足，以及如何重构得更好。有或没有智能体，都他妈一样。 这一切都需要纪律和自主权。 这一切都需要人类。 本页面通过不使用 Cookie 或类似技术、不收集任何个人身份信息来尊重您的隐私。