Claude Code 主创放弃写 Prompt 了：他改写循环。Prompt Engineer 这个岗位还活得下去吗？
上周 AI 开发圈讨论最热烈的不是模型发布，而是一条招聘描述。Anthropic Claude Code 负责人 Boris Cherny 在 The New Stack 采访中说了句让所有人沉默的话："我不写 prompt 了，我写循环。"Loop Engineering 这个词，可能成为未来两年开发者技能树里最烫手的新技能。
一条招聘描述，一个信号
消息源头是 The New Stack 的一篇专访。Boris Cherny——Claude Code 的工程负责人，也是 Anthropic 内部最清楚"人类怎么跟 AI Agent 协作"的那个人——在谈到他们正在招的岗位时，没有用"Prompt Engineer"这个词，而是一个新的标签：Loop Engineer。
他的原话大意是：他不再花时间精雕细琢一条 prompt，而是把任务拆成可循环执行的小步骤，让模型在 plan → act → verify → repeat 的回路里自己推进。
这话从一个每天跟 Claude Code 产品深度交互的人嘴里说出来，分量很重。因为这不是"一种更高级的 prompt 技巧"，而是一种根本不同的交互范式。
Prompt Engineering 的天花板在哪里？
过去两年，Prompt Engineering 一直是"用好 AI 的核心竞争力"。但如果你认真跟踪前沿实践者，会发现它正在撞上一堵墙：
- 边际收益递减：一开始改几个字能让输出质量飙升 50%，但现在翻来覆去调整几十遍 prompt，可能只提升 5%。上限越来越明显。
- prompt 本质上是"传声筒"：你给模型一个指令，它执行一次，然后你检查结果。如果结果不好，你的选择只有两个——改 prompt 再来一次，或者手动修正。你没法教模型"记住这个教训，下次遇到类似情况自动调整"。因为 prompt 是一次性的、无状态的。
- prompt 不可验证：你怎么知道一条 prompt 改了之后是不是真的"更好"了？绝大多数 Prompt Engineer 靠的是直觉和人工评分。当你的 prompt 有 300 个 token，嵌入了大量 few-shot 示例时，你就已经失去了对输出质量的系统化控制。
Prompt Engineering 本质上是在设计"问题"。Loop Engineering 在设计"过程"。
Loop Engineering 到底是什么？
用最简单的类比：
| 旧范式 | 新范式 |
|---|---|
| 你写一个完美的 prompt → 模型一次性执行 → 你接受/拒绝结果 | 你写一个循环 → 模型在每个循环中：尝试 → 检查自己 → 如果不满意，自动调整再试 → 直到自我判定成功 |
它把"人在循环里"变成了"人在循环外定义规则、模型在循环里自己迭代"。
Cherny 描述的具体实践大概是这样：
定义一个循环： 1. 给模型一个可以独立完成的子任务 2. 给模型一个"判断自己是不是做对了"的验证标准（可以是代码编译通过、测试通过、或者 LLM as Judge） 3. 如果验证不通过，自动回溯、修正、重试 4. 如果超过 N 次循环仍不通过，暂停并把结果交给人判断这和传统的"高并发 prompt 调优"思路是两个完全不同的方向。一个追求"一次命中"的精度，一个追求"过程收敛"的可靠性。
这个转变对开发者意味着什么？
你现在需要的技能会变
做 Loop Engineering，需要的技能和 Prompt Engineering 很不一样：
| Prompt Engineering 技能 | Loop Engineering 技能 |
|---|---|
| 对话设计、格式控制 | 任务拆解、循环设计 |
| few-shot 示例编排 | 验证标准制定（test-driven） |
| 经验直觉 | 可回滚的状态管理 |
| 输出美化 | 工具白名单 + 权限控制 |
简单说：Prompt Engineer 是个"作家型"岗位，Loop Engineer 是个"架构师型"岗位。你不需要写出最优美的那句话，但你需要设计出让模型大概率走向正确结果的路径结构。
岗位会怎么演进？
我不认为"Prompt Engineer 已死"——至少在接下来两年里，大多数 AI 产品仍然依赖 prompt 作为主要交互方式。但可以确定三个趋势：
- Prompt Engineering 会下沉为"基础技能"。就像今天每个程序员都会写 SQL，但不一定需要专门的 DBA。
- Loop Engineering 会成为 Agent 开发的核心技能。当你的产品不是"一个用 AI 的聊天框"，而是"一个能自主完成多步任务的 Agent"时，你不会在设计 prompt——你会在设计循环。
- "Agent Architect"会成为一个新岗位。这个岗位不写 prompt，不写循环，而是定义 Agent 能力的边界——“这个 Agent 能在哪些范围内行动？哪些事情绝对不允许？一旦越界怎么处理？”
这是一个从"让 AI 好好说话"到"让 AI 靠谱做事"的范式迁移。
一个值得观察的信号
Karpathy 之前提过 “context engineering”——强调 prompt 不只是文字，是整个上下文窗口的设计。ChatGPT 早期有 "system prompt 工程"的实践。这些都是同一个方向上的不同探索。
但 Boris Cherny 把这件事推进到了"循环设计"这个层面，是因为他手上有 Claude Code 这个产品作为实验场。Claude Code 本来就是一个"需要多次迭代才能完成任务"的 Agent——不是一次性问答工具。所以 Loop Engineering 不是他们的理论偏好，而是在实践中被倒逼出来的工程解法。
这对所有做 Agent 的团队都是一个信号：如果你的 Agent 已经在做多步任务，但你还是靠"调 prompt 一条龙"来改进它，你可能会在未来 6-12 个月被"调循环"的团队拉开一个数量级的效率差距。
你现在可以试试的事
如果你感兴趣，这里有一个零成本的入门：
在 Claude Code 或 Cursor 里，别要求它一次性写完整段代码，而是把它拆成三步：
- “写出函数签名 + 核心逻辑框架”
- “用我给的测试用例跑一遍，告诉我哪里不对”
- “根据失败点逐一修正”
这三步不是"一个复杂 prompt"——它们是一个简单的 loop。你会立刻发现，做对了的代码不需要你再手改；出错的地方会以更系统的方式被定位和修复。
这就是 Loop Engineering 的最小实践单位。
参考：The New Stack / Boris Cherny / Anthropic Claude Code 团队