从提示词到循环工程，AI协作的新范式正在重塑开发流程。
核心内容：
1. Loop Engineering的核心概念与工作模式转变
2. 从单次指令到闭环系统的设计关键
3. 实践中的挑战与未来应用前景

 Datawhale干货 

作者：Addy Osmani，谷歌云 AI 总监

大部分人第一反应是：这下轻松了。以前一行行敲代码，现在动动嘴；以前自己 debug，现在丢给 Agent。但谷歌云 AI 总监 Addy Osmani 最近一篇刷屏长文,结论正相反：想把这东西真用明白，比过去写提示词还难。

他还打了个比方：你可以让自己当个全程在场的工程师，也可以当个只管按启动键的人。这种新的干活方式，AI 圈最近给它起了个名字：Loop Engineering，循环工程。

这件事的起点，是 Claude Code 负责人 Boris Cherny 说，自己现在基本不直接给 AI 下指令了，而是写好一个个 loop，让 loop 去驱动 AI。用他的原话说:「我的工作就是写循环。」

一个大厂核心产品的负责人，说自己主要的工作就是写 loop；一个大厂 AI 总监，说这事比写提示词还难。

问题就来了：这个让一圈大佬都改了干活方式的 loop，到底是什么？它凭什么被说得这么重要，又难在哪？

一、从写提示词，到 Loop Engineering

先看看大家平时是怎么用 Agent 的。

你说一句，它做一点，你看一眼，不对再补一句，它再改，你再看。上下文不够，你还得重新交代背景、提醒它别动哪里。AI 是在干活，但一直盯着进度、一步步往前推的人，还是你。

所以那个阶段，大家最在意的是提示词怎么写：怎么把第一句话说得准、说得全。

但用久了会碰到另一个问题：真正花时间的，往往不是第一句提示词，而是后面那一长串重复动作。发现问题、拆任务、并行处理、回头检查、记录这轮做到哪、决定是继续还是交还给人。这些动作每天都在发生，加起来才是大头。

于是重点变了。以前是“怎么写一句好提示词”，现在变成“怎么把这一串反复发生的动作，设计成一个能自己转起来的 loop”。

这就是 Loop Engineering 想做的事。它把提示词定义成了一个零件，而真正决定结果的，变成了那个 loop。

二、Loop Engineering 到底是什么用一句不绕的话讲：Loop Engineering，就是你不再亲自一轮一轮指挥 Agent，而是把“发现问题、执行、检查、记录、继续下一步”这条链路，做成一个能自动运转的小系统。

重点不在“自动”，在“闭环”。

有人会把 loop 理解成定时跑个任务。定时只是开始。一个真正能用的 loop，至少要做到这几件事：它能自己启动，知道去哪找信息，做完一轮知道怎么检查结果，失败了知道要不要重试，每轮知道把进展记到哪，也知道什么时候该停下来交给人。

这本质还是一套工作流。

Addy 在原文里的说法是：loop 不是你去给 Agent 写提示词，而是你设计一个系统，让这个系统替你去写。人的位置往后退了一层，从执行者，变成了调度者。

三、一个完整的 loop 长什么样

Addy 把它拆成“五个积木，加一个记忆机制”。换成更直白的问法，一个 loop 得同时回答六个问题。

第一，谁来把它叫醒？不会自己启动的，不叫 loop，只能算“你手动点一次”。所以第一件事是调度：定时、按事件触发，或者跑到目标完成才停。比如每天扫一遍昨晚失败的 CI，每半小时看一次新 issue，测试不过就一直改。这一层决定的，是你在用工具，还是在运行系统。

第二，多个 Agent 一起干活，怎么解决并行问题？ 只要并行，就迟早会出现改同一处文件、彼此覆盖的情况。所以要隔离。代码场景里这就是 worktree：给每个 Agent 一个独立工作空间，各改各的，最后再合并。没有隔离的并行，常常不是提效，而是批量制造冲突。

第三，AI 怎么知道你们平时怎么干活？这是 skill，或者说项目知识。模型每次开工，都很容易重新变回一个不熟悉你项目的新同事。所以得把知识写到外面：项目怎么启动、哪些目录别碰、命名规范是什么、踩过哪些坑。提示词是当场的临时指令，skill 是长期的固定规则。没有这层规则，loop 每转一圈都要重新认识你一遍。

第四，它能不能碰到本地资料？只能看本地文件的 Agent，还是半封闭的，它能给建议，但推不动真正的工作。有用的 loop 往往要接出去：issue 系统、数据库、CI、测试环境、PR、通知工具。这一步决定了 AI 是“说”还是“做”——是告诉你“这里可能有 bug，建议这么改”，还是直接开分支、跑测试、开 PR、关联工单，把结果丢进你的待审列表。

第五，谁来检查它，进行结果的验收？写代码的 Agent 往往高估自己的答案，它写完再问自己“行吗”，答案大概率是“行”。所以越来越多 loop 把执行和验证拆开：一个负责做，一个专门挑错，必要时换不同模型、不同视角来查。道理跟团队里那条老规矩一样——写代码的人，最好别自己给自己 review。在无人盯着的 loop 里，这条更要紧，因为它一旦犯错，会顺着 loop 越跑越远。

第六，它怎么记住昨天做到哪了？这是最不起眼、却几乎所有长期 loop 都离不开的部件：记忆。可能只是一个 markdown 文件、一张看板、一份外部记录，但它必须存在。Agent 最大的麻烦之一，是每次启动都太像重新来过：昨天验证过的结论今天再查一遍，上周否掉的方案这周又端上来。所以得有个对话之外的载体，记下做过什么、失败过什么、哪些已确认、哪些还得人来处理。Addy 在原文里有句话适合做总结：模型会忘，但仓库不会忘。

四、Loop Engineering 的成本和边界Addy 原文里没有把 Loop Engineering 讲成一个无脑乐观的方案，他一直在提醒两件事：成本，和边界。

先说成本。loop 一旦跑起来，就不是问一次答一次的计费方式了。它会反复读上下文、反复试错、反复验证，有时还拉好几个 Agent 一起干，token 消耗可能非常大。如果任务不值得反复跑、没有稳定的反馈，或者只是一次性的小事，loop 很可能还没帮你省时间，先把成本烧光了。

再说边界。loop 能替你推进流程，但不能替你担责任。AI 说“完成了”，不等于真没问题；说“测试通过了”，也不等于业务逻辑对。一个没人盯着的 loop，也会没人盯着地犯错。还有一个更隐蔽的代价：AI 干得越多，人越容易不再去看过程，时间一长，代码越堆越多，自己真正理解的却越来越少。

所以 loop 的用法，从来不是把人拿掉，而是把人从重复劳动里抽出来，但把判断、验收和刹车这三样权力留在自己手里。

五、哪些工作适合用 loop代码是 loop 最先爆发的地方，因为它天然有反馈：测试过没过、程序跑不跑、日志报不报错，都能直接验证。但把这个思路抽象一下，它适合的工作远不止编程。

比如内容选题。一个 loop 可以这样跑：每天定时去扫新闻源、X、博客、论文站，先挑出值得看的，补上来源、摘出核心观点、标出有争议的地方，资料不够的地方标红，最后把一份选题清单交给编辑。运营、研究、客服、产品分析也类似，很多流程都满足同一个条件：任务会重复、流程相对稳定、结果有一部分能检查。满足这几点，loop 就有落地空间。

写在最后：人和 AI 的协作方式已经升级把 Loop Engineering 当成一个新词，它很快会被下一个词替代。但它背后的人与 AI 的协作模式是很多大佬在思考的：当 AI 能够处理更长链路的任务时，人和 AI 的协作方式，也得从一轮一轮的对话，升级成一个能自己运转的闭环。

过去大家比的是谁的提示词写得好。接下来比的可能是谁的 loop 设计得好：怎么调度、怎么验证、怎么记录、什么时候该停。

回到开头 Addy 那句话：这件事不会让你的工作变简单，它只是把发力点挪了个位置。你可以选择做那个始终在场、清楚每一步在发生什么的工程师，也可以做那个只负责按下开始键、然后看着代码越堆越多的人。

一起“点赞”三连↓