# 最近火爆硅谷的 Loop Engineering 到底是个什么东西？

看到一篇文章，叫：《循环工程》，这个概念最近在硅谷很火，在这里分享一下我的理解。

最近在开发者圈子里，有一个新概念开始被频繁提起，叫做“循环工程”（Loop Engineering）。这个词听起来挺唬人的，但其实核心意思很简单：你不再一句一句地告诉 AI 该干什么，你设计一套自动运转的系统，让这套系统去替你跟 AI 打交道。

这个概念是怎么来的呢？Anthropic 公司负责 Claude Code 的工程师 Boris Cherny 说了一句话：“我已经不自己给 Claude 写提示词了，我写的是循环，让循环去提示 Claude，然后自己想办法解决问题。我的工作就是写循环。”另一位知名开发者 Peter Steinberger 也说了类似的话：“你不应该再手动提示编程 AI 了，你应该去设计能提示 AI 的循环。”

这两句话放在一起看，其实在说同一件事：人和 AI 之间的协作方式，正在发生一次升级。

## 从“一问一答”到“自动运转”

过去两年，大家用 AI 写代码的方式基本上是这样的：你打一段话，AI 回你一段代码，你看看对不对，再打一段话，AI 再回一段。整个过程你得全程坐在电脑前，一轮一轮地推进。你就像一个拿着工具的工人，工具很强，但你得一直握着它。

现在有人开始换一种玩法了。你搭一个小系统，这个系统自己去发现有什么活要干，自己把活分配给 AI，自己检查 AI 干得对不对，自己记录哪些做完了哪些没做完，然后自己决定下一步该干什么。整个过程你可以不在场，它自己转。

这就像什么呢？以前你是一个厨师，每道菜都亲自炒。现在你变成了一个餐厅经理，你设计好菜单、流程、质检标准，然后让厨房自己运转。你偶尔巡一圈，看看有没有出问题就行。

仔细想想，这种思路其实在很多领域都能看到。比如做自媒体的人，一开始什么都自己干，写稿、排版、发布、回复评论。后来慢慢搭建起一套流程，有些环节交给工具或者助手，自己只管最核心的决策。循环工程本质上就是这个逻辑在编程领域的体现。

## 一个循环需要哪五个零件

作者把一个完整的循环拆成了五个组件，外加一个记忆系统。我一个一个说。

第一个是自动化调度。你设定一个时间表，比如每天早上八点，系统自动跑一遍，看看昨天有没有新的 bug 报告，有没有测试失败，有没有新提交的代码需要关注。发现问题的就进入待办列表，没发现问题的就自动归档。你早上打开电脑，看到的是一份整理好的清单，哪些需要你关注，哪些已经处理了。

第二个是工作树隔离。这个稍微技术一点，但道理很简单。如果你同时让两个 AI 改同一个文件，它们会打架，就像两个人同时在一张纸上写字一样，写出来的东西乱七八糟。工作树隔离就是给每个 AI 一份独立的副本，各改各的，改完了再合并。谁也不会踩到谁。

第三个是技能文件。AI 有一个毛病，就是每次对话开始它什么都不记得。你上次跟它说过“我们项目用的是这个框架，代码风格是那样的，这个地方千万别动因为之前出过事”，下次它全忘了。技能文件就是把这些项目知识写成一个文档，AI 每次启动都会先读一遍，这样它就不用每次都从零开始猜你的项目是怎么回事了。

这一点其实特别值得琢磨。我们在生活中也经常遇到类似的情况，比如你带一个新同事，每次都要从头解释一遍公司的规矩和做事方式，累不累？如果有一份写得清清楚楚的手册，新人来了自己看一遍就能上手，效率完全不一样。技能文件就是给 AI 写的那份“新人手册”。

第四个是连接器。一个只能读写本地文件的 AI，能做的事情很有限。但如果它能连上你的项目管理工具、能查数据库、能往 Slack 群里发消息、能自己去开一个代码合并请求，那它能做的事情就多太多了。连接器就是让 AI 能够操作你日常工作中用的那些工具。

有了连接器，AI 就从一个“只能给你建议”的角色，变成了一个“能帮你执行”的角色。它不再只是说“你应该这样修”，它能直接把修好的代码提交上去，把相关的任务卡片标记为完成，然后在群里通知一声“搞定了”。

第五个是子代理。这个概念特别有意思。就是你不让一个 AI 既写代码又检查代码。为什么？因为自己检查自己的作业，总是会手下留情的。所以你让一个 AI 负责写，另一个 AI 负责审查，审查的那个用不同的指令甚至不同的模型，专门挑毛病。

这跟我们日常生活中的道理一模一样。写完一篇文章自己检查，总觉得写得挺好的，让别人一看，一堆问题。考试做完自己检查，很难发现错误，换个人一眼就看出来了。让写代码的 AI 自己判断“我写完了，质量没问题”，这个判断是不可靠的。必须有另一个角色来验证。

最后还有一个贯穿始终的东西，就是外部记忆。可以是一个 markdown 文件，也可以是一个项目管理看板，反正就是一个 AI 对话结束后不会消失的地方，用来记录“什么做完了，什么还没做，上次试了什么方案失败了”。没有这个记忆，循环每天早上醒来都是失忆状态，昨天的进度全丢了。有了这个记忆，今天的运行能接着昨天的成果继续往前推。

## 循环跑起来是什么样的

把这五个零件加上记忆组装起来，一个典型的循环长这样：

每天早上，自动化调度启动，调用一个分诊技能，读取昨天的测试失败记录、新开的 issue、最近的代码提交，然后把发现的问题写进一个状态文件。对于每个值得处理的问题，系统开一个隔离的工作树，派一个子代理去写修复方案，再派另一个子代理对着项目规范和已有的测试去审查这个方案。审查通过的，连接器自动开 PR、更新任务卡片、在群里通知。搞不定的，放进待办箱等你来看。

你做了什么？你设计了这套东西一次。之后每天早上它自己跑，你只需要处理它搞不定的那部分。

## 三个越来越尖锐的问题

作者在文章最后提了三个警告，我觉得这三个警告比前面所有的技术细节都重要。

第一个：验证永远是你的责任。循环无人值守地跑，也意味着它可能无人值守地犯错。就算你设了审查子代理，那也只是降低了出错概率，不是消除了。AI 说“搞定了”，这是一个声明，不是一个证明。最终确认代码能用、质量过关的那个人，还是你。

第二个：你对自己项目的理解会悄悄腐烂。循环跑得越顺，产出的代码越多，你没亲手写的代码就越多。时间一长，你的项目里有大量你其实不太理解的东西。作者管这个叫“理解力负债”。这个债不还，迟早有一天你会发现自己看不懂自己的项目了。

这一点放到更大的范围来看也成立。任何时候，当一个工具帮你做了太多事情，而你不去理解它做了什么，你就在积累一种隐性的风险。表面上效率很高，实际上你对事情的掌控力在下降。

第三个：最舒服的姿态往往最危险。当循环自己跑得很好的时候，你特别容易进入一种状态，就是不再动脑子了，它给什么你就收什么。作者管这个叫“认知投降”。设计循环这件事，如果你是带着判断力去做的，它能让你更强。如果你是为了逃避思考才去做的，它只会让你更弱。同一个动作，心态不同，结果完全相反。

## 同样的循环，不同的人，不同的结果

作者在结尾说了一段话，我觉得特别到位：两个人可以搭建一模一样的循环，得到完全相反的结果。一个人用它来加速自己深度理解的工作，另一个人用它来回避理解工作本身。循环分不出这两种人的区别，但你自己分得出。

所以循环工程比写提示词更难，不是因为技术门槛更高，是因为它对使用者的自律和判断力要求更高了。杠杆的位置变了，你能撬动的东西更大了，但如果你站错了位置，被撬飞的也可能是你自己。

作者最后的建议很实在：去搭建你的循环吧，但要像一个打算继续当工程师的人那样去搭建它，不要只做那个按下启动键就走开的人。直接提示 AI 依然有效，关键是找到自动化和亲力亲为之间的平衡点。这个平衡点在哪里，每个人不一样，但你得有意识地去找它，而不是让惰性替你做这个决定。

#科技先锋官##How I AI#