当「写Prompt」变成过去式：聊聊Loop Engineering

2026年6月，Boris Cherny 干了一件让开发者圈炸锅的事。他在一次公开分享中说，自己已经一个月没打开 IDE 了——编辑器都删了。在那一个月里，他提交了 259 个 PR，没一行代码是自己敲的，全是 Claude Code 写的。

但更关键的是后面这句话：

"我不再向 Claude 发送提示词了。我写循环，让循环去提示 Claude。我的工作变成了设计循环。"

几乎同一时间，OpenClaw 的创始人 Peter Steinberger 在 X 上发了一条帖子，大意是："你不应该再手动给编程 Agent 写提示词了。你应该设计一套循环机制，让循环去提示你的 Agent。" 这条帖子最终获得了超过 1500 万次浏览。

然后黄仁勋也下场了。他在一次公开交流中说了一句后来被反复引用的话："Nobody writes prompts anymore. The new job is to write and handle loops."

吴恩达更直接：静态 prompt 会在三到六个月内消亡。

Google Cloud AI 的工程总监 Addy Osmani 给这个新范式正式取了名字——Loop Engineering。

如果你觉得这听起来又像是一个三个月后会过气的 buzzword，我理解。但这次可能不太一样。

问题的根源：人就是那个循环

要理解 Loop Engineering 为什么重要，得先看清楚 Prompt Engineering 到底卡在哪。

传统 AI 编程的工作流是这样的：你写 prompt → AI 输出 → 你 review → 改 prompt → AI 再输出 → 你再 review……循环往复。

在这个流程里，人就是那个循环本身。每一步都依赖你的注意力、上下文记忆和决策带宽。问题不在于"写 prompt 太累"，而在于这种模式有一个硬上限：一个人一天能有效驱动的 token 量和任务复杂度是有限的。

你在用线性思维管一个非线性系统。你能写出一个完美 prompt 覆盖一个函数的所有边界条件，但你能写出一个 prompt 覆盖一个 50 个模块的项目吗？不能。

这就是为什么 Boris Cherny 说优化 prompt 已经不再产生收益了——瓶颈不在 prompt 质量，瓶颈在人。

Loop Engineering 到底做了什么

Loop Engineering 的核心思路一句话就能说完：把"那个不停 prompt AI 的人"换成"一个不停 prompt AI 的系统"。

你的角色从操作者变成了设计者。你只做一次高价值的设计决策——定义目标、设定验证规则、配置刹车条件——然后这套系统自己跑。

具体来说，一个有效的 Loop 通常包含几个关键构件：

Automations（自动触发）：CI 挂了自动修、新的未结 Issue 自动处理、按时段自动扫任务列表。Loop 不是被动等人下指令，它会自己找活干。

Worktrees（并行沙盒）：多个 Agent 同时跑在独立的 git worktree 上，各干各的，互不踩脚。Boris 说他同时跑 5 个 Claude 实例，每个在独立分支上。这不是炫技，这是生产环境。

Skills（知识固化）：把项目知识沉淀成结构化文件（比如 SKILL.md），别让 Agent 每次都在猜你的项目规范。这也是为什么 Vercel skills 项目能在 GitHub 上 5 个月冲到 2.4 万星——AI 编程的下一个瓶颈不是模型能力，是上下文管理。

Connectors（外部连接）：通过 MCP 协议接 GitHub、Linear、Slack 这些真实工具。一个只能写代码不能感知外部世界的 Agent，充其量是个好用的代码补全。接上真实系统之后，它才能成为一个有闭环能力的工程师。

Sub-agents + Maker-Checker（执行与审查分离）：这是最狠的一条。写代码和审代码的必须是两个独立的 Agent。同一个模型既当运动员又当裁判，结果永远是给自己打满分——这叫自欺式合规。分开之后，校验才是真的校验。

外挂一层记忆层（Memory）：状态不能只活在对话窗口里，必须落到磁盘。Agent 会忘，仓库不会。持久化的 STATE.md 让每个新起的 Agent 都知道上一个循环干到哪了、什么失败了、什么还没验证。

不是银弹

话说到这，我觉得有必要泼点冷水。

成本问题。Loop 放大能力，也放大 token 消耗。Uber 内部尝试过类似方案，账单出来之后紧急叫停。不是每个团队都烧得起 Anthropic 级别的 API 费用。Boris 说他用 Opus 4.5 加 Thinking 模式跑，原因是"慢一点，但错误少得多"。这话对，但前提是你付得起那个"慢"。

理解债。代码是 Agent 写的，review 也是 Agent 做的，人在 Loop 外面看着。时间长了，你对自己系统的理解会退化。不是故意偷懒，是人脑本来就需要亲手操作才能建立认知模型。Boris 自己都说了："搭好你的 loop，但要像一个打算继续当工程师的人那样搭它。"

验证盲区。测试覆盖率可以达到 100%，但测试本身是 Agent 写的。谁能保证测试逻辑是对的？Loop 越跑越远，错误也可能在闭环里被放大。这就是为什么 Sub-agent 的 Maker-Checker 模式不是可选项，是必选项。

我的判断

Loop Engineering 不是要取代 Prompt Engineering，它是架在 Prompt Engineering 上面的一层。

Osmani 把这四层栈总结得很清楚：Prompt → Context → Harness → Loop。每一层包住下一层，不是替换关系。你不会因为有了 Loop 就不需要写好的 prompt 了——你只是不需要反复手动写 prompt 了。

对于小团队和个人开发者，我建议别急着把所有东西都塞进 Loop。先从最确定、最重复的任务开始——CI 失败自动修复、定时代码审查、文档同步更新。跑通了，再扩展。

对于大团队，Anthropic 内部 80% 的工程师已经在用自改进循环了，3-6 个月目标 100%。如果你还没开始想这件事，可能再过半年就有点慢了。

最后说一句。Loop Engineering 让我真正兴奋的地方，不是"以后不用写代码了"，而是它让开发者的时间从操作层面解放出来，回到判断层面——架构怎么设计、系统边界在哪、什么该做什么不该做。这些才是工程师真正的价值所在。