Claude Code 之父说"不再提示 AI 了"：AI 新编程范式 Loop Engineering 到来

写代码的方式又一次被重写。这不是模型升级的故事，而是编程范式转移的故事。

2026 年 6 月初，Google 工程师 Addy Osmani 发了一篇长文，引爆了 AI 编程圈的讨论。

他把一个正在发生但尚未被命名的趋势，正式贴上了标签：

Loop Engineering —— 循环工程。

这不是一个学术概念。它是三个站在 Coding Agent 最前线的人，在同一个月内说出的同一句话。

一、三巨佬的同一句话

Boris Cherny，Anthropic 的 Claude Code 负责人，在被问到日常工作方式时说：

"我不再直接提示 Claude 了。我有循环在运行，它们提示 Claude，自己 figuring out what to do。我的工作是写循环。"

Peter Steinberger，OpenClaw 框架的创始人，在 X 上发了一条后来被广泛引用的帖子：

"你不应该在提示 coding agent。你应该设计循环来提示它们。"

Addy Osmani，Google 工程师，用一篇系统性文章把这句话翻译成了工程语言：

"Loop Engineering 是取代你自己作为提示 Agent 的人，转而设计那个提示 Agent 的系统。"

当 Claude Code 的负责人和 Codex 生态的核心人物说出同一件事时，这不是巧合，是一个正在发生的范式转移。

二、你正在做的"人肉 API"

先问一个问题：你现在用 AI 写代码的工作流程长什么样？

大概率是这样的：

你写一个 prompt。 Agent 生成代码。 你看 diff，发现有个 bug。 你把错误信息贴回去，让它修。 它修了，又跑一下。 还是有问题。 你再把新的错误贴回去……

二十分钟后你意识到——你一直在做那个最蠢的事：当人肉中转站。

你不是在思考。你是在搬运错误信息。

这就是 Loop Engineering 要终结的工作方式。

三、从 Prompt 到 Loop：四层演进

要理解 Loop Engineering 为什么是现在，需要先看到它站在谁的肩膀上。

AI 编程的进化走过了一条清晰的路径：

第一层：Prompt Engineering（提示工程）你优化的是"怎么问"。 核心问题：怎样写一条 prompt 才能让模型给出好答案？ 代表：ChatGPT 早期，所有人都在学 prompt 技巧。

第二层：Context Engineering（上下文工程）你优化的是"给模型看什么"。 窗口里除了 prompt，还放文档、历史、工具定义。 代表：CLAUDE.md、SKILL.md、AGENTS.md。 让模型不再每次从零开始猜你的项目。

第三层：Harness Engineering（驾驭工程）你优化的是"怎么约束单次运行"。 给 Agent 设定规则、反馈回路、工作流控制。 代表：Claude Code 的 Hooks 系统。 让 Agent 在一次运行中不跑偏。

第四层：Loop Engineering（循环工程）你优化的是"谁来决定 prompt 什么、何时 prompt、结果是否合格"。 核心问题变了：不再是单条 prompt 的质量，而是生成和验证 prompt 的系统的设计。 代表：Claude Code 的 /loop、/goal 命令，Codex 的 Automations。

每一层包裹前一层。Prompt 工程没有消失——它是 Loop 的组件。Context 工程没有消失——Loop 每次 turn 仍需正确注入上下文。

Loop 新增的是自主控制结构。

四、Loop ≠ Cron Job

听到"自动循环"，有人会说：这不就是 cron job 吗？定时任务，几十年前就有的东西。

区别很大。

Cron Job 做什么：运行一个固定脚本。第一步，第二步，第三步。 Loop Engineering 做什么：运行一个 Agent，让它看当前状态，选择下一步行动，执行，检查结果，决定是否需要再来一次。

Cron 里没有决策者。Loop 里有。

一个 cron job 说："依次做 A、B、C。" 一个 loop 说："看看现在什么情况，决定该做什么，做了之后检查对不对，不对就修，对就停下。"

这才是质的区别。

五、为什么是 2026 年 6 月？

这个概念不是今天才有的。它之所以在现在引爆，是因为积木刚刚凑齐。

2026 年上半年，两个主流 Coding Agent 同时把 Loop 需要的全部积木内置到了产品里：

Claude Code 方面：

• /loop 命令：把你的 prompt 变成定时任务（支持 cron 语法）
• /goal 命令：给定一个可验证条件，Agent 自己跑直到条件满足
• Hooks：在 Agent 生命周期关键点自动触发
• Auto Mode（Claude 4.6/4.7）：安全审批自动化，不再需要逐条确认

Codex 方面：

• Automations Tab：图形化配置自动化任务
• Persisted Goal（CLI 0.128.0+）：持久化目标，Agent 跨 session 持续执行

一年前，要搭一个 loop 需要一堆自己写的 bash 脚本，只有你能看懂。 现在，五块积木在两个工具里都已内置，只是命令名不同，形状完全一样。

当基础设施就位，范式转移就开始了。

六、一句话总结 Loop Engineering

如果用一句话解释 Loop Engineering 是什么：

你不再亲自每次提示 Agent。你设计一个系统，让它按计划、按目标自动提示 Agent，检查结果，决定是否继续。

杠杆从"单条 prompt 的质量"转移到了"生成和验证 prompt 的系统的设计"。

七、你的角色正在改变

这意味着你的价值在重新分配。

以前，你的价值在中间——写 prompt、看结果、修 bug、再写 prompt。你把自己耗在了执行层。

现在，价值集中在两端：定义意图和最终审阅。

中间的执行和验证，是 Agent 的工作。

这不是编程变容易了，而是最高价值的事情变了——从"写好一条 prompt"变成了"设计一个好 loop"。好 loop 乘好工程师，坏 loop 同样快地放大坏决策，而且更少的人在看。

更关键的问题是：Loop 设计能力会成为新的工程师分层标准吗？

答案是会的。能定义清晰 pass/fail 信号、能判断什么时候该 loop 什么时候该停手、能控制 loop 的 token 预算——这些会变成一个工程师和另一个工程师之间的分水岭。就像当年"会不会写自动化测试"分了一批人一样。

对普通人来说，这意味着一件事：你不需要有最强的大模型，你需要有最会设计 loop 的判断力。而这恰恰是 Human3.0 说的结构杠杆——不是更努力，而是搭一个更好的系统放大自己。

八、但先别急着全自动化

Loop Engineering 有两个大坑，几乎所有人在第一次尝试时都会踩：

第一个坑：目标定义太难。软件开发经常是探索性的——你不一定一开始就知道功能的最终形状。如果你的 end state 是模糊的，loop 会优化到你给的那句模糊话上，结果可能比你手动做一遍更糟。

第二个坑：成本失控。一个 scheduled loop 加上每次 turn 后的 verifier model，可以烧 token 烧到让你怀疑人生。Loop 在 token 预算充足的大厂最容易 hype。对普通人来说，预算本身就是架构的一部分。

所以 Anthropic 的人给了一个建议：

从简单开始，只在自动化的回报能覆盖成本时才增加自主性。如果工作流是一次性的，直接 prompt 模型就好。如果工作重复且有清晰的 pass/fail 信号，建一个 loop。如果任务模糊——比如"想一个更好的产品策略"——别把它交给 while-loop，去喝杯咖啡，先和人类聊聊，想清楚目标再说。

九、从一个最小 loop 开始

上面的话如果只停留在概念层，这篇就没有写完。

给你一个最小可执行的起点，今晚就能跑：

目标：让 Agent 自动修复一个已知的 lint 报错文件。

做法（以 Claude Code 为例）：

1. 打开项目，确认有一个 lint 报错的文件
2. 输入 /goal 修复 src/utils/format.ts 的 lint 错误，跑 npm run lint 验证，直到通过
3. 看着它跑——修改、验证、再修改，直到 lint 通过

这就是一个最朴素的 loop：有目标，有验证信号，有终止条件。

你会看到 Agent 怎么处理这个任务，会走哪些弯路，会在哪里反复失败。这些观察，比任何概念都值钱。

下一篇开始拆解 Loop 的六块积木——Automations、Worktrees、Skills、Connectors、Sub-agents、Memory。那是从"跑过一次"到"能设计好自己的 loop"之间需要理解的架构层。

《Loop Engineering 实战手册》系列计划 第 1 篇：Loop Engineering 是什么（本篇） 第 2 篇：六块积木架构拆解 第 3 篇：Loop 模式决策表——什么时候用什么 loop 第 4 篇：Anthropic 三 Agent 架构实战 第 5 篇：从零搭建实操全流程 最终篇：收官总结 + 《Loop Engineering橙皮书》预告 关注「AI生命克劳德」，不错过每一篇。