夜雨聆风「我不再直接给 Claude 发 prompt 了。我写 loop，让 loop 去驱动 Claude 干活。我的工作变成了写 loop。」 -- 这是 Boris Cherny (Claude code的创建者) 最近说的一句话。
过去几个月，一种新用法越来越常见。
不是你跟 AI 在对话框里一问一答。是你把任务扔到队列里。机器自己捡起来，自己干。干到某个环节停下了，外面的 harness 程序看一眼——完没完？没完就接着来。
Flask 的作者 Armin Ronacher 管这个东西叫 loop。准确说，他区分了两种 loop。
第一种 loop，在 AI 编程 agent 内部。模型调用一个 tool，拿到结果，再调用下一个 tool，读文件，改代码，跑测试，最后给你一个答案。这个 loop 我们很熟悉了。
第二种 loop，在外面。你可以把它想象成一个工头——它给模型派活，模型干了一段说"我干完了"，工头看一眼，说"不，你还没完"，然后把任务塞回去，或者换个模型重新干，或者调整一下 context 再启动。
区别在哪？
第一种 loop 里，模型说了算。它觉得干完了，就停了，你来审查结果。
第二种 loop 里，工头说了算。模型说"干完了"这件事本身变成了一个信号——被另一个程序拿去判断的信号。你的角色变成了传话的人。
Armin 说他最近脑子里挥之不去的，就是这个外层 loop。
我还没学会这样干活
Armin 很诚实。他说自己到现在为止，用这种方式写他在意的代码，效果都不好。
说到底是两件事：品味，和控制。
他对代码质量有要求。他希望在跟同事讨论的时候，或者线上出问题的时候，能自己解释系统在干什么——而不是先让 AI 帮他解释一遍。
那么问题来了：再过几年，他还会有这种"理解代码"的需求吗？他说不好。但至少现在，他还没翻过这一页。
而他看过的那些由 loop 生成的代码，有几个问题：
第一，防御心太重。 模型非常怕异常。Karpathy 说过，LLM 对异常"怕得要死"。它们会在每个地方加 try-catch，加各种 fallback。但真正的好代码不是到处处理异常，而是从设计上让异常的状态根本不可能出现。
第二，太局部了。 模型看到一个问题就加一层保护，看到另一个问题又加一层。每一轮 loop 加一小块补丁，系统慢慢就变成了一个千层饼——看起来每层都很结实，但没人看得懂整体。
第三，越自动越糟糕。 Armin 特别提到，现在一些"完全自动"的编程工具，让模型不停跑二三十分钟不中断，产出的代码比去年秋天的还差。为什么？因为去年秋天你至少还在 loop 里——模型干一段，你看一段，调整一段。
把这种局部打补丁的行为放到 loop 里，会被放大。每一轮 loop 多加一道防线，系统表面上越来越"健壮"，实际上越来越不可理解。
更要命的是，如果你把这种工具交给一个初级工程师，不加指导——你问他为什么这样写，他能振振有词地给你讲一大堆道理。因为他自己也是被 AI 说服的。
loop 在哪些地方真的管用
但 Armin 不是二极管。他承认 loop 在不少场景下就是好用。
代码移植。 已经有大规模自动移植的成功案例，比如 Bun 从 Zig 移植到 Rust 的工作。Armin 自己用这种方式把 MiniJinja 移植到了 Go，体验不错。
性能探索。 让机器不断试、不断测、不断扔，找到最优方案。这不就是该让机器干的活吗？
安全扫描。 扔一个任务让它自动搜漏洞，搜到了报，搜不到继续搜。
各种研究型任务。 让它探索一个复杂的问题空间，回来给你一个报告。不涉及要长期维护的代码。
这些东西有个共同点：要么是"翻译"已有的代码而不是从零创造，要么产出的代码本来就没打算活得久。它们是概念验证，是实验，是机械式的搬运，不是要陪你走十年的业务逻辑。
Armin 说他非常喜欢那些能替他把实验中无聊部分干完的 loop——跑实验、测数据、给灵感。
软件变成了 活物(organism)
问题出在：当你用同样的 loop 方法论去写要长期维护的代码时，事情就变味了。
Armin 做了一个比喻：从"软件是一台确定的机器"，转向"软件是一个有机体"。
他入行的时候，整个环境鼓励你理解机器。总有一层你可以剥开来加深理解。代码无法预测、行为不确定的机器，不是没有，但大家都认为那不是好东西。
现在呢？
线上出了问题，很多工程师第一反应是把日志扔给 AI。让它猜原因，让它自动出补丁。补丁再被另一个 AI 审查，有时候直接就合入 main 分支了——没人看过。
够猛。也够吓人。
不是说这样不行。有些软件本就不值得人手写每一行。但你接受这种模式，就等于接受了一件事：你不再像以前那样理解整个系统了。你监控它、治疗它、稳住它，但你不一定懂它了。
你想拒绝，但可能没得选
最让人不舒服的部分来了：选择退出这场游戏，可能根本不是一个选项。
拿安全来说。就算你自己不用 loop 构建软件，别人会用 loop 攻击你的软件。攻击者会 7x24 小时开着机器扫你的漏洞。就算不是攻击者，安全研究员也会这么做。你收到的报告——不管是真漏洞还是噪音——会多到你一个人根本处理不过来。除非你也扔一台机器去应付。
curl 的维护者 Daniel Stenberg 六月份写了一篇《curl 的幸福夏天》，讲的就是维护者现在承受的压力。curl 的核心开发到目前为止还没大规模引入 AI，但维护者已经被 AI 生成的报告淹没了。
如果攻击方在 loop，报告方在 loop，防守方迟早也得 loop。不一定直接写补丁，至少筛选、验证、响应的环节得靠机器。
竞争层面也一样。有些团队会靠 loop 把构建速度拉满。五个人的小团队能干以前五十个人的活。有些创业公司会直接让 AI 对着你的产品 loop——"给我做一个跟那个一样的东西"。你愤怒、你不屑、你觉得那是一坨——但用户开心，你说呢？
新的依赖，比钱更难挣
Armin 说的另一个担忧，我印象很深。
软件一直依赖工具。他还记得编译器要花钱买的年代。但现在不一样了——新的工具不只是一次性付费，它是持续的依赖。
不光是钱包的依赖，更是认知的依赖。
如果代码是 loop 生成的，审查是 loop 做的，补丁是 loop 打的，维护也靠 loop 撑着——有一天你没权限用那些最强的模型了怎么办？地缘政治搞一下，成本涨到受不了，或者你和团队失去了脱离 AI 理解代码的能力。
那时候你手里的代码库，不只是"人类难以维护"，而是假定了机器参与维护。
这已经在发生了。越来越多的人合入了自己不能完全解释的代码。越来越多人离开 AI 就不能独立写 issue 报告，不能在聊天里清楚地讨论问题。Armin 说他越来越多地遇到这种情况：别人跟他的对话，是透过一层 LLM 转述过来的。
Armin 说，也许这不算错。但它是一个巨大的变化。
控制 loop
这篇文章的底色，是不安。
不是因为恐惧，而是因为谨慎——基于他过去几个月跟这些技术打交道的体验。
在 agent 内部 loop 里，模型最终会说"我做完了"，你审查。在此之前，你还参与引导。你学到了东西。在外部 loop 里，连"做完了"这件事都失去了意义——它变成了另一个机器要判断的信号。你的角色退化成了一个传话的。
Armin 说他不喜欢现在看到的很多由这种系统生成的代码，也不喜欢跟过多 AI 生成的软件打交道。loop 很强，但它一层层剥掉了人的责任，而且至少在今天，它非常鼓励我们对机器让步。
但他又说，他毫不怀疑 loop 时代就是我们的未来。他已经看到小得惊人的团队在以不可能的速度构建东西，看到代码库越来越像模糊、混乱的 活物(organism)——只能由更多机器来诊断。这些代码同时既混乱又有用。
所以他开始接受一个事实：问题不是"要不要 loop"——显然要。
问题是：在一个 loop 的未来里，我们怎么不放弃判断？怎么守住好工程的规则？怎么让负责任的人继续有能力监督？怎么重新思考架构，让人在这个过程中还能保持清醒？
这也是他为什么对 Pi 的态度在变化。Pi 一直很谨慎，他觉得这种谨慎是好的。他不想看到每一次交互都变成一群不受控制的机器在狂改代码。但他也知道，Pi 本身就是一个 harness，而 harness 正是人们做这类实验的中心。
即使有疑虑的人，也得开始做实验了。不是为了拥抱 loop，而是为了理解——怎么让这个未来是"有边界、能存活"的。
本文基于 Armin Ronacher 于 2026 年 6 月 23 日发布在个人博客的文章《The Coming Loop》所做的解读与延伸。原文链接：lucumr.pocoo.org/2026/6/23/the-coming-loop
