AI循环编程是什么？深度拆解Loop Engineering的真实价值与炒作成分

从"提示词已死"到"循环工程"的炒作链条

最近AI编程圈又掀起一波新概念热潮。Claude Code的作者鲍里斯（Boris）先是宣称"编程问题基本已经解决了"，随后更进一步表示"连提示词都死了"——现在他不写代码，也不写提示词，而是"写循环"。

Claude Code是Anthropic推出的命令行AI编程工具，允许开发者通过自然语言指令让AI直接在终端中读写代码、执行命令、管理git操作。它代表了从"聊天式辅助"到"智能体式自主执行"的范式转变。与GitHub Copilot的逐行补全不同，Claude Code能理解整个项目上下文并执行多步骤复杂任务，这也是为什么其作者会提出"写循环而非写提示词"的观点——工具的能力边界决定了使用方式的演进。

这并非个例。OpenAI的工程师也发推称："你不该再给编程智能体写提示词了，你应该设计循环，让循环去给你的智能体写提示词。"Bun的作者贾里德（Jared）同样暗示，手动写提示词已经是"六个月前的老办法"了。

然而，NeetCode在视频中犀利地指出了一个共同点：这些"行业先锋"告诉我们AI编程的未来方向，却始终不肯给出清晰明确的说明。他们抛出概念，却不解释具体工作流，仿佛在说"如果你跟不上，那是你的问题"。

循环工程到底是什么？一个并不复杂的概念

当我们剥开炒作的外衣，所谓"Loop Engineering"（循环工程）的核心其实非常简单：

• 本质是配方配置：预先设定一套提示词规则，让AI编程智能体按照固定流程自动执行
• 长周期任务：循环可以像cron定时任务一样持续运行，或者运行到满足某个终止条件
• 并行处理：利用Codex等工具的会话线程功能，一个主线程可以派生多个子线程独立工作

Cron是Unix/Linux系统中的定时任务调度器，允许用户按照预设时间表自动执行脚本或命令（例如"每天凌晨3点执行数据库备份"）。在AI循环工程的语境中，cron代表了最基础的触发机制——按时间间隔启动智能体。但真实的生产环境远比定时触发复杂：更高级的编排涉及事件驱动（如CI构建失败时自动触发修复智能体）、条件终止（如所有单元测试通过时停止迭代）和优先级队列（紧急bug优先于代码优化任务）。这些机制本质上是将传统DevOps中CI/CD流水线的编排理念与AI智能体结合——只不过流水线中的执行节点从确定性脚本变成了概率性的大语言模型，这一变化带来了全新的可靠性挑战。

OpenAI的Codex智能体支持多线程会话（session threads）机制，每个线程拥有独立的执行上下文和沙箱环境。主线程可以将复杂任务分解后派发给多个子线程并行处理，类似于操作系统中的进程派生（fork）。这种架构借鉴了微服务编排的思想，但将编排对象从服务实例替换为AI智能体实例，每个实例都能独立推理、执行代码和访问工具。值得注意的是，与传统多线程编程中的共享内存模型不同，AI智能体的多线程更接近消息传递模型——子线程之间不直接共享状态，而是通过任务描述和结果回传与主线程通信，这在一定程度上避免了传统并发编程中的竞态条件问题，但也引入了上下文同步的新挑战。

一篇来自谷歌云前总监的帖子（获得200万浏览量）描述了典型的循环模式：每天早上自动扫描代码仓库，读取CI报错和未解决的issue，派生子智能体起草修复方案，再派另一个子智能体审查，通过后自动开PR。

但NeetCode指出，这篇被大量传播的帖子本身很可能就是LLM生成的——"构建循环，守住工程师本分，自动化就是心跳"——正常人不会这么说话。我们正陷入一个讽刺的循环：用AI生产的水文来炒作AI概念。

实际落地：被一笔带过的工程细节才是关键

NeetCode用自己网站的bug处理流程举了一个具体例子，展示AI循环编程在实际项目中的运作方式：

1. 收到bug反馈存入数据库
2. 设定规则：每24小时让智能体读取所有bug
3. 为每个bug生成独立的子智能体，各自验证并尝试修复
4. 每个子智能体在独立的工作树（git worktree）中工作，避免冲突
5. 生成PR，由人工审核决定是否合并

Git worktree是Git 2.5（2015年发布）引入的功能，允许从同一个仓库创建多个独立的工作目录，每个目录检出不同的分支。与普通的git branch切换不同，worktree提供了物理隔离——每个工作树有自己独立的文件系统空间，拥有各自的暂存区（staging area）和工作目录。这意味着多个智能体可以同时在不同worktree中修改代码而不会产生文件锁冲突。这对AI并行编程至关重要，因为普通分支切换需要修改同一个工作目录的文件，无法支持真正的并发操作。在实际使用中，每个worktree通常对应一个独立的bug修复分支，智能体在其中自由地运行测试、修改文件、提交变更，完成后再将结果汇总到主分支——这种模式与容器化开发环境的隔离思路异曲同工。

这里面涉及大量被"一笔带过"的工程细节：

• 数据访问方式：让智能体直接查SQL容易出错，给它浏览器权限操作UI更安全但更慢
• 隔离策略：用git worktree而非普通分支，确保多个智能体并行时不互相冲突
• 风险控制：速度和安全的权衡——"我完全愿意牺牲一点速度，总比哪天智能体把数据库删了强"

这些细节恰恰说明，AI编程自动化对工程基础能力的要求不是降低了，而是提高了。你需要理解进程隔离、权限最小化原则、数据库访问控制等传统软件工程概念，才能为AI智能体搭建一个安全可控的运行环境。那些宣称"不需要懂编程就能用AI编程"的说法，在面对这些工程现实时显得格外苍白。

指数衰减：AI循环编程的数学局限

一个被忽视的基本事实是：如果智能体每次迭代的正确率是95%，十轮迭代后的累积正确率并非95%×10，而是0.95的10次方——约等于60%。这就是指数衰减。

指数衰减在这里描述的是复合错误率问题，其数学本质是独立事件概率的连乘。在传统软件工程和安全领域，这类似于詹姆斯·瑞森（James Reason）提出的"瑞士奶酪模型"——每一层防护都有漏洞，当多层漏洞恰好对齐时就会发生系统性事故。对于AI智能体而言，情况可能更糟：每次迭代不仅可能引入新错误，还可能基于前一次的错误输出做出进一步错误决策，形成错误级联（error cascading）。例如，第一轮迭代中智能体错误地修改了一个函数签名，第二轮迭代的另一个智能体基于这个错误签名编写了调用代码，第三轮的测试智能体可能认为调用代码是正确的而放行——错误像滚雪球一样越积越大。这也是为什么业界对"完全自主AI智能体"持谨慎态度的数学基础——理论上，除非每步准确率趋近100%，否则长链推理和多轮迭代的可靠性会急剧下降。这个问题在学术界被称为"复合AI系统的可靠性瓶颈"，目前尚无根本性的解决方案。

除非智能体能做到100%准确，否则错误只会不断累积，跑得越久情况越糟。这也是为什么Flask的作者在实验后表示，循环目前唯一真正有用的场景是AI代码审查——让工具持续检查并修复问题，直到没有可处理的问题为止。

代码审查之所以是循环工程的理想场景，是因为它具备天然的收敛性：每一轮审查要么发现问题并修复，要么确认无问题而终止。这与开放式的功能开发形成鲜明对比——后者的状态空间是发散的，每一步都可能引入新的设计决策和不确定性。用数学语言说，代码审查循环是一个有界的不动点迭代，而开放式开发循环更像是一个可能不收敛的递归过程。

贾里德自己也在几周后承认：循环配合任务队列效果最好，更像for-each循环（遍历预定义任务）而不是while循环（无边界自由运行）。这等于变相承认了循环工程的局限性——而这距离他暗示"大家都该写循环"才过了不到三周。

谁在炒作？利益驱动下的信息污染

为什么这些概念被过度炒作？NeetCode指出了一个关键视角：看发言人背后的利益驱动。

Anthropic和OpenAI有极强的动力去炒作智能体编程概念——这直接关系到他们产品的商业价值。Claude Code采用按token计费的模式，循环运行意味着持续消耗token；OpenAI的Codex同样依赖API调用量作为核心收入来源。当这些公司的工程师在社交媒体上推广"循环工程"时，他们既是技术布道者，也是产品推销员——这种双重身份使得他们的技术判断天然带有利益偏向。

而Google在一场分享中提出了更务实的观点：

"如果你发布软件的速度特别快，快到你根本来不及发现任何问题，那你的回滚机制还有什么意义？每一次回滚都要面对叠加在问题版本之上的一大堆互相冲突的变更。"

回滚（rollback）是软件发布中的核心安全机制，指在新版本出现问题时快速恢复到上一个稳定版本。Google提出的问题触及了持续部署（Continuous Deployment）的根本矛盾：发布频率越高，版本间的依赖关系越复杂，回滚的代价也越大。在传统的发布流程中，业界发展出了多种安全策略：金丝雀发布（先将新版本推送给小比例用户，观察无异常后再全量推送）、蓝绿部署（同时维护新旧两套环境，出问题时瞬间切换流量）、特性开关（Feature Flags，通过配置控制新功能的启停而无需重新部署）。但如果AI智能体每小时甚至每分钟都在自动合并代码并触发部署，这些依赖人工观察窗口期的安全策略可能完全跟不上节奏，导致系统处于"无法安全回退"的危险状态。这不是理论上的担忧——Google自身在大规模持续部署方面有超过十年的实践经验，他们的警告来自真实的工程教训。

这30秒的观点比Twitter上无数模棱两可的帖子都更有价值。光提升速度是不够的，必须考虑整个系统的安全阀门。

冷静看待：基础工程能力依然是核心

AI循环编程并非毫无价值，但它远没有被炒作得那么革命性。它的本质是：

1. 一种自动化编排模式，不是全新范式——类似于从手动执行shell脚本到使用Ansible/Terraform进行基础设施编排的演进，核心逻辑没变，只是抽象层级提高了
2. 对工程基础知识的要求不减反增（git worktree、并发控制、风险管理、权限隔离、可观测性）
3. 目前最适合有明确边界的重复性任务，而非开放式开发——代码审查、lint修复、依赖更新、测试生成等收敛性任务是当前的甜蜜点
4. 人工审核环节仍然不可或缺——在可预见的未来，"人在回路中"（Human-in-the-Loop）不是可选项，而是必选项

真正值得警惕的不是技术本身，而是围绕技术的信息环境——当"专家"们用AI生成的水文来推销AI概念，当所有人都在观望却假装自己是先知，我们需要的不是更多炒作，而是更多像NeetCode这样愿意说"我也不懂，但让我搞明白再告诉你们"的诚实声音。在技术快速迭代的时代，承认自己不懂比假装什么都懂更需要勇气，也更有价值。