AI开发范式的第四次跃迁：从Prompt Engineering到Loop Engineering

文章目录

[AI开发范式的第四次跃迁：从Prompt Engineering到Loop Engineering](#AI开发范式的第四次跃迁：从Prompt Engineering到Loop Engineering)
- 引爆点：Prompt已死，Loop当立
- [一、概念辨析：Loop 到底是什么？](#一、概念辨析：Loop 到底是什么？)
- - [1.1 一句话定义](#1.1 一句话定义)
  - [1.2 Loop 和 Agent 的关系](#1.2 Loop 和 Agent 的关系)
  - [1.3 旧范式的痛点：人肉瓶颈](#1.3 旧范式的痛点：人肉瓶颈)
  - [1.4 新范式的本质：目标驱动 + 自动验收](#1.4 新范式的本质：目标驱动 + 自动验收)
- 二、落地现状：双雄对峙
- - [2.1 Claude Code 体系](#2.1 Claude Code 体系)
  - [2.2 OpenAI Codex 体系](#2.2 OpenAI Codex 体系)
  - [2.3 结论：模型卷不出差别了，差距在 Loop 编排](#2.3 结论：模型卷不出差别了，差距在 Loop 编排)
- [三、实操指南：怎么 Loop 起来？](#三、实操指南：怎么 Loop 起来？)
- - [3.1 准入测试：4 个灵魂拷问](#3.1 准入测试：4 个灵魂拷问)
  - [3.2 最小可行 Loop 的 5 个组件](#3.2 最小可行 Loop 的 5 个组件)
  - [3.3 核心设计原则：拆卷子](#3.3 核心设计原则：拆卷子)
  - [3.4 避坑指南](#3.4 避坑指南)
  - [3.5 核心指标：每个被接受改动的平均成本](#3.5 核心指标：每个被接受改动的平均成本)
- 四、历史演进：四次范式跃迁
- 结语：从操作员到架构师

引爆点：Prompt已死，Loop当立

2026年6月，NVIDIA CEO 黄仁勋在一次访谈中扔下了一颗炸弹：

"Nobody writes prompts anymore. The new job is to write and handle loops."

翻译过来就是------现在根本没有人写Prompt了，新时代的核心工作是编写和管理Loop。 他称这是"定义2026下半年格局的转折点"。

这句话不是危言耸听。

就在同一周，Claude Code 的负责人 Boris Cherny 在 CNBC 的采访中说了一句更狠的：

"I don't write the prompt anymore. Claude writes the prompt, and now I'm talking to that new Claude that is kind of coordinating."

（我已经不写提示词了。Claude 自己写提示词，而我在跟那个负责协调的"新 Claude"对话。）

OpenAI 工程师、OpenClaw 作者 Peter Steinberger 更直接，他在 X 上发了条"月度提醒"：

"Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

（月度提醒：别再给编程 Agent 写提示词了。你应该设计 Loop，让 Loop 去给你的 Agent 写提示词。）

三句话，三个不同阵营的顶级玩家，指向同一个方向。

当大众还在卷"怎么写好提示词"的时候，顶级圈层已经在谈"怎么设计自动化闭环"了。这个认知差，就是本文要拆解的东西。

一、概念辨析：Loop 到底是什么？

1.1 一句话定义

Loop（循环）= 你不再亲手给 AI 下指令，而是设计一个系统，让系统替你下指令、替你验收、不合格自己重来，直到活干完。

用 Claire Vo（ChatPRD 创始人）的话说：

"It's really just reminding people that you don't have to use your human fingers to type in a prompt in order for your agent to do work on your behalf."

（这其实就是在提醒人们：你不需要用你的人类手指去敲提示词，你的 Agent 才能替你干活。）

1.2 Loop 和 Agent 的关系

这是被问最多的问题。答案很简单：

概念	比喻	职责
Agent	干活的"员工"	执行具体任务：写代码、查资料、发消息
Loop	管理这套人的"制度"	发现工作 → 分配任务 → 验收结果 → 不合格打回 → 记录状态 → 决定下一步

Agent 是干活的"人"，Loop 是让这个人不用盯着也能持续干活的"管理机制"。

1.3 旧范式的痛点：人肉瓶颈

回顾过去两年，我们跟 AI 编程工具的交互模式是这样的：

复制代码

你写 Prompt → AI 出代码 → 你读 → 你改 Prompt → AI 再出 → 你再读 → ...

这个循环里，人全程卡在中间。AI 每吐一口，你就得嚼一下。AI 快了，但人成了瓶颈。

Google Cloud 工程主管 Addy Osmani 在他的博客里精准描述了这个问题：

"For like two years the way you got something out of a coding agent was you wrote a good prompt and shared enough context. You type a thing, you read what came back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after the other. That part is kind of over."

（过去两年，你从编程 Agent 那里拿到东西的方式是：写好提示词，给足上下文。你敲一个东西，读返回结果，再敲下一个。Agent 是个工具，而你全程握着它，一轮接一轮。这种模式基本结束了。）

1.4 新范式的本质：目标驱动 + 自动验收

Loop 的核心是两个关键词：

目标驱动（Goal-Driven）：你不再说"怎么做"，你只说"做到什么程度算完"
自动验收（Auto-Verification）：有一个独立的"裁判"来判断工作是否合格，而且这个裁判不能是干活的那个人

Andrej Karpathy 最近反复引用的一句话精准概括了这层关系：

"You can outsource your thinking, but you cannot outsource your understanding."

（你可以外包你的思考，但你没法外包你的理解。）

Loop 不是让你撒手不管。它是让你从"操作员"变成"架构师"------你不再亲自拧螺丝，但你设计了整条流水线，并且知道什么时候该喊停。

二、落地现状：双雄对峙

目前围绕 Loop 形成了两大产品阵营，而且有趣的是，它们的能力图谱惊人地一致。

2.1 Claude Code 体系

Claude Code 的 Loop 体系围绕三个核心原语展开：

原语	功能	本质
`/goal`	设定目标，AI 持续工作直到验收条件满足	"干到合格为止"
`/loop`	按时间间隔重复执行任务	"每隔 X 分钟检查一次"
`/schedule`	定时任务 + Cron 调度	"每天早上 9 点跑一遍"

最值得关注的设计是 Evaluator Architecture（验收器分离） ：Claude Code 的 /goal 在每一轮工作后，会用**一个独立的小模型（Haiku）**来检查"目标达成了吗"。这个设计哲学很关键------写代码的模型不能给自己的作业打分，它会对自己太宽容。

Boris Cherny 在 Anthropic 开发者大会上透露，自 Opus 4.5 以来，他个人的所有代码都是 Claude Code 写的。他说：

"接下来是循环------Agent 之间互相提示，中间无需人工审核。"

2.2 OpenAI Codex 体系

Codex 的 Loop 体系更强调"自动化流水线 + 多子 Agent 并行"：

Automations（自动化）：定时触发的工作流，结果汇入 Triage 收件箱
Subagents（子 Agent） ：定义在 .codex/agents/ 中的专用 Agent，可并行执行
Worktrees（工作树）：每个线程独立的 git 工作区，互不干扰
云端沙箱：Agent 在云端并行工作，不占用本地资源

Peter Steinberger 分享了他的典型 Loop：

"Tell Codex to maintain your repos, wake up every 5 minutes and direct work to threads. That makes it easy to parallelize + steer work as needed."

（告诉 Codex 维护你的仓库，每 5 分钟醒来一次，把工作分发到不同线程。这让并行化和按需调度变得极其简单。）

2.3 结论：模型卷不出差别了，差距在 Loop 编排

Addy Osmani 做了一个非常精辟的对比表，揭示了两个阵营的能力完全对位：

能力	Codex	Claude Code
定时触发	Automations tab	/loop, /schedule, cron
目标驱动	/goal	/goal
工作隔离	内置 worktree	git worktree, --worktree
项目知识	Agent Skills	Agent Skills
外部连接	Connectors (MCP)	MCP servers
子 Agent	.codex/agents/	.claude/agents/
状态管理	Markdown / Linear	AGENTS.md / progress files

"The names are a bit different here and there but the capability is the same thing."

（名字略有不同，但能力完全一样。）

这意味着什么？模型本身卷不出差别了。真正的差距在上层的 Loop 编排能力。 谁能设计出更高效、更可靠、更省 Token 的 Loop，谁就能在 AI 开发的下半场胜出。

三、实操指南：怎么 Loop 起来？

3.1 准入测试：4 个灵魂拷问

在动手搭 Loop 之前，先问自己四个问题。如果任何一个答案是"否"，就别 Loop------老老实实写 Prompt。

拷问	为什么重要
任务重复发生吗？	Loop 的价值在于复用。一次性任务不值得搭系统
有自动化验收手段吗？	没有测试套件/Linter/CI，Loop 就是盲飞
Token 预算扛得住吗？	Loop 会持续消耗 Token。如果单次成本 × 循环次数 > 你的预算，别搞
Agent 有"高级工程师"权限吗？	读日志、跑测试、操作文件系统------没有这些工具，Loop 就是残废

3.2 最小可行 Loop 的 5 个组件

Addy Osmani 总结了 Loop 必备的五个组件，缺一不可：

复制代码

┌─────────────────────────────────────────────────────────┐
│                    Loop 五要素架构                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ① Automations（触发器）                                  │
│     └─ 定时唤醒，发现工作，分诊归类                        │
│                         ↓                               │
│  ② Worktrees（工作区隔离）                                │
│     └─ 并行 Agent 互不踩脚                                │
│                         ↓                               │
│  ③ Skills（项目知识）                                     │
│     └─ 一次写好，每次复用，不再重复解释项目背景              │
│                         ↓                               │
│  ④ Plugins/Connectors（外部连接）                         │
│     └─ 连接 Issue Tracker、数据库、Slack、CI              │
│                         ↓                               │
│  ⑤ Sub-agents（子 Agent）                                │
│     └─ 一个写，一个验，一个汇报                            │
│                         ↓                               │
│  + State File（状态文件）                                  │
│     └─ Markdown 文件或 Linear Board，记录"做了什么、下一步" │
│                                                         │
└─────────────────────────────────────────────────────────┘

搭建顺序：先手动跑通 → 写成 Skill → 包进 Loop → 上定时。

不要一上来就搭全自动 Loop。先手动跑一遍完整流程，确认每一步都靠谱，再逐步自动化。这是无数人用 Token 烧出来的教训。

3.3 核心设计原则：拆卷子

Loop 工程最重要的设计原则只有一条：

写代码的和验代码的必须分开（Evaluator Architecture）。

为什么？Addy Osmani 的原话一针见血：

"The model that wrote the code is way too nice grading its own homework."

（写代码的模型给自己的作业打分时，太容易放水了。）

正确做法：

复制代码

Generator Agent（生成器）          Evaluator Agent（验收器）
      │                                    │
      │ 写代码                              │ 读代码
      │ 跑测试                              │ 独立跑测试
      │ 自我感觉良好                        │ 严格按 spec 验收
      │                                    │
      └──────── 提交 ──────────────────────→│
                                           │
              ←──── 通过 / 打回 ────────────┘

两个 Agent 用不同的指令、甚至不同的模型。验收器只看结果是否符合 spec，不看"谁写的"。

3.4 避坑指南

坑 1：没有硬停止条件

Loop 最怕死循环。必须设置硬停止条件：

yaml 复制代码

# 示例：Loop 停止条件
hard_stop:
  max_iterations: 10        # 最多跑 10 轮
  max_tokens: 500000        # Token 上限
  max_wall_time: 30min      # 时间上限
  stop_on: ["测试全部通过", "无法修复"]

坑 2：状态不落地

Agent 每次运行都是"失忆"的。状态必须落盘：

markdown 复制代码

<!-- state.md -->
## 当前状态
- 已完成：修复了 auth.py 的空指针
- 进行中：user_test.py 第 42 行断言失败
- 阻塞：需要确认 API 版本号
- 下一步：修完 user_test.py 后跑全量回归

坑 3：让 Loop 处理"需要人类判断"的任务

架构重写、安全策略决策、用户体验判断------这些需要人类判断的事情，不要让 Loop 碰。Loop 擅长的是"有明确验收标准的重复性工作"，不是"我也不知道对不对"的模糊任务。

3.5 核心指标：每个被接受改动的平均成本

Loop 工程只有一个北极星指标：

每个被接受的改动，平均花了多少 Token（多少钱）。

如果被接受率低于 50%，说明你的 Loop 在亏钱------一半的 Token 都烧在了被拒绝的改动上。

适合 Loop 的场景 vs 不适合的场景：

✅ 适合 Loop	❌ 不适合 Loop
CI 失败自动修复	一次性脚本
依赖版本更新 + 回归测试	"帮我看看这个 bug"（无验收标准）
Flaky Test 排查与修复	架构重写
每日 Issue 分诊	"你觉得这个设计怎么样"
代码审查自动汇总	需要人类判断的模糊任务
文档自动同步更新	探索性原型开发

四、历史演进：四次范式跃迁

Loop Engineering 不是凭空出现的。它是 AI 开发范式持续进化的必然结果：

复制代码

┌──────────────────────────────────────────────────────────────────┐
│                  AI 开发范式的四次跃迁                              │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ① Prompt Engineering (2023-2024)                                │
│     关注："怎么说"                                                │
│     核心技能：写提示词、Few-shot、Chain-of-Thought                  │
│     代表作：GPT-4, Claude 3                                       │
│     ─────────────────────────────────────────                    │
│                                                                  │
│  ② Context Engineering (2024-2025)                               │
│     关注："给看什么"                                              │
│     核心技能：RAG、长上下文管理、知识库构建                          │
│     代表作：Claude 200K, Gemini 1M                                │
│     ─────────────────────────────────────────                    │
│                                                                  │
│  ③ Harness Engineering (2025-2026)                               │
│     关注："给什么工具/环境"                                        │
│     核心技能：MCP、Function Calling、Sandbox、Agent Skills         │
│     代表作：Claude Code, OpenAI Codex, Cursor                     │
│     ─────────────────────────────────────────                    │
│                                                                  │
│  ④ Loop Engineering (Now)                                        │
│     关注："设计循环/系统"                                          │
│     核心技能：自动化编排、验收器分离、状态管理、子 Agent 协作         │
│     代表作：/goal, /loop, Automations, Subagents                  │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

从学术脉络来看，Loop 是姚顺雨（Shunyu Yao）等人提出的 ReAct 框架（Reasoning + Acting）的工程化收敛。ReAct 的核心思想是"思考→行动→观察→再思考"的循环------而这正是 Loop 的底层逻辑。学术界在 2022 年就埋下了种子，工业界在 2026 年把它变成了产品。

结语：从操作员到架构师

Loop Engineering 不是为了让程序员失业。恰恰相反------它是为了让程序员从"操作员"进化为"系统架构师"。

Google 的 Addy Osmani 在博客结尾写了一段警告，值得每个人认真读：

"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. I'm skeptical and you absolutely have to be careful about token costs."

（Loop 工程正在取代你作为"提示词输入者"的角色。你设计系统来代替你。我持怀疑态度，而且你必须对 Token 成本极度小心。）

Karpathy 反复引用的那句话是最好的收束：

"You can outsource your thinking, but you cannot outsource your understanding."

你可以让 AI 替你写代码、替你跑测试、替你修 Bug、甚至替你写提示词。

但你不能让 AI 替你理解------理解你的业务、理解你的架构、理解"为什么这个设计是对的"。

Loop 不是让你躺平。它是让你把精力从"操作"上解放出来，投入到"理解"和"设计"上。

从 Prompt 到 Loop，不是工具的升级，是角色的跃迁。

参考链接：

Business Insider: Forget prompt engineering: 'Loop engineering' is all the rage now
The New Stack: The Anthropic leader who built Claude Code says he ditched prompting
Addy Osmani: Loop Engineering
NDTV Profit: What Is Loop Engineering, And Why Does Jensen Huang Says You Must Learn It
Karpathy on X: "You can outsource your thinking, but you cannot outsource your understanding"

本文基于 Business Insider、The New Stack、Addy Osmani 博客、NDTV Profit 等多家媒体的报道，以及 Jensen Huang、Boris Cherny、Peter Steinberger、Andrej Karpathy 等核心人物的公开言论整理撰写。