夜雨聆风最近 AI 圈又冒出来一个新词：
Loop Engineering。
直译过来是“循环工程”，它其实说的是一件很具体的事：以后真正重要的，可能不再是你会不会写一句漂亮的 Prompt，而是你会不会设计一个能让 AI 自己持续工作的闭环。
也就是说，人不再每一步都坐在电脑前，手动告诉 Agent 下一步该干什么。
你要做的，是定义目标、提供上下文、设置验证条件、安排触发机制，然后让系统自己一轮一轮跑下去。
这就是 Loop。
这个词从哪来的？
这波讨论最早是几条英文圈的发言串起来的。
2026 年 6 月 2 日，Claude Code 负责人 Boris Cherny 在 Acquired Unplugged 的访谈里提到，他现在已经不怎么手动 prompt Claude 了。他有一些 loop 在跑，这些 loop 会自己提示 Claude、自己判断下一步要做什么。
他的工作，变成了写 loop。
几天后，OpenClaw 作者、后来加入 OpenAI 做 agents 的 Peter Steinberger 在 X 上也说了类似的话：
随后，Google 工程师 Addy Osmani 写了一篇长文《Loop Engineering》，正式把这个概念梳理出来。
所以这个词不是凭空造出来的。它更像是一个行业里已经发生的工作方式变化，终于被人起了个名字。
Loop 到底是什么？
过去我们用 AI 写代码，大概是这样的：
你说一句，AI 做一步。
AI 写完，你看一眼。
不对，你再补一句。
它再改，你再检查。
这其实还是人驱动的。
AI 是工具，但你是那个一直踩油门、打方向盘的人。
Loop Engineering 想做的是反过来：你不再充当每一轮的调度器，而是设计一个系统，让系统自己完成“发现问题、分配任务、执行、验证、记录状态、继续下一轮”。
比如一个很简单的 loop 可以是：
每天早上自动检查项目里的 CI 失败记录。
如果发现某个测试挂了，就开一个独立 worktree。
派一个 Agent 去修。
修完跑测试和 lint。
再派另一个 Agent 做 review。
如果通过，就开 PR。
如果失败，就记录原因，下一轮继续处理，或者把问题丢回给人。
这就不是一次性 Prompt 了。
这是一个自动化工程闭环。
一个完整 Loop 需要什么？
Addy Osmani 把 Loop 拆成几个关键组件，我觉得这个拆法很清楚。
第一，触发机制。
Loop 必须能自己启动。可以是定时任务、cron、hook、GitHub Actions，也可以是 Codex 或 Claude Code 里的自动化任务。
如果每次都要你手动点一下，那还不是真正的 loop。
第二，隔离环境。
多个 Agent 同时工作时，最怕互相改同一个文件。Worktree 的意义就在这里：每个 Agent 在自己的工作区里改，互不干扰，最后再合并。
第三，项目知识。
Agent 每次启动时都像一个新同事。如果没有 AGENTS.md、CLAUDE.md、skills、docs、记忆文件，它就会不断重复问上下文，或者基于错误前提瞎猜。
Loop 是自动跑的，人不一定在旁边盯着，所以知识体系尤其重要。
第四，工具连接器。
只会读本地文件的 Agent，能力很有限。接上 GitHub、Linear、Slack、数据库、CI、MCP 之后，它才真的能进入你的工作流。
发现问题、修复问题、更新 issue、通知团队，这才叫闭环。
第五，验证机制。
这是最关键的一点。
Loop 不能只是“让 AI 一直干活”，它必须知道什么时候算完成，什么时候算失败。
“优化一下这个项目”不是好目标。
“test/auth 全部通过，tsc --noEmit 零报错，npm run lint 零违规”才是好目标。
一个不能验证的 loop，只是在自动制造不确定性。
为什么大佬们都开始重视 Loop？
因为 AI 编程的抽象层级又往上走了一层。
最早是人手写代码。
后来是 IDE 自动补全。
再后来是人提示 Agent 写代码。
现在开始变成：人设计系统，让 Agent 自己在系统里循环工作。
Boris 的重点在这里：工程师的工作正在从“写代码”变成“设计自动化工作流”。
Peter 的重点也类似：如果每一步都要人手动提示，那人还是整个流程的瓶颈。真正的杠杆，是让 loop 去提示 Agent。
Addy 的贡献，是把这件事从一句口号变成工程框架：自动化、worktree、skills、connectors、sub-agents、memory、verification。
还有 Karpathy 的 autoresearch 也很典型：给 AI 一个实验环境，让它自己改代码、训练、评估、保留或丢弃结果，然后重复。人不再直接改每一行代码，而是在设计实验循环。
这就是 Loop Engineering 的精神。
但 Loop 不是魔法
Loop 很强，但它也很危险。
因为一个坏 Prompt 只会错一次，一个坏 Loop 会自动错很多次。
如果目标定义不清楚，它会在模糊目标里乱转。
如果验证机制太弱，它会把错误结果当成成功。
如果项目知识过期，它会基于错误上下文做出一堆“看起来很努力”的修改。
所以 Loop Engineering 的核心能力，其实不是会不会写脚本，也不是会不会配 hook。
它真正考验的是三件事：
你能不能定义清楚目标。
你能不能设计可靠的验证。
你能不能让系统在失败时停下来、记下来、交还给人。
这也是为什么 Loop 不会让工程师消失。它只是把工程师从“每轮操作员”推到了“系统设计者”的位置。
最后
Prompt Engineering 解决的是：我该怎么跟 AI 说话。
Context Engineering 解决的是：我该给 AI 什么背景。
Harness Engineering 解决的是：我该把 AI 放进什么样的工具和约束里。
而 Loop Engineering 解决的是：我该如何让 AI 在一个可验证的闭环里持续工作。
这可能就是接下来 AI 编程最重要的变化。
不是让 AI 替你多写几段代码。
而是让你开始设计一套系统，让代码、测试、反馈、修复、记录和交付自己转起来。
未来真正值钱的，可能不是“会写 Prompt 的人”。
而是能把目标、工具、验证和反馈串成 Loop 的人。
