不写Prompt，写Loop：AI编程的下一场范式迁移

不写Prompt，写Loop：AI编程的下一场范式迁移

如果你最近在关注 AI 编程，大概率刷到过这句话。

Anthropic 工程师、Claude Code 的创建者 Boris Cherny 在一次分享里说：

"我不再提示 Claude 了，我有一堆循环（loops）在运行，它们才是真正在提示 Claude 并判断接下来该做什么。我的工作变成了写循环。我认为，这是接下来几个月，甚至今年剩余时间里我们会看到的下一次转变。"

几乎同一时间，在 OpenAI 任职的"龙虾之父" Peter Steinberger 也发了推：你不该再给编程 Agent 写提示词了，你应该设计一套循环机制，让这些循环去提示你的 Agent。这条帖子很快获得了上百万浏览量。两个人一前一后发声，把"Loop Engineering（循环工程）"这个新词推到了台前。

过去两年，大家忙着学 Prompt Engineering：怎么给角色、给背景、给示例、给输出格式。现在风向好像变了------已经有人喊出"杀死提示词工程"。真相是什么呢？我觉得不是 Prompt 被淘汰了，而是 AI 编程的关注点，正从"怎么把一句话问清楚"迁移到"怎么设计一个能持续推进、自动验证、出错能纠偏、该停能停下来的闭环"。

一、为什么只写 Prompt 不够了

先说清楚：Prompt 当然有用，而且永远不会没用。

你问一个概念、让 AI 解释一段代码、生成一个 SQL，这些任务短、边界清楚、结果也好人工判断，一句 prompt 就够了。问题出在真实项目里。

你让 Agent 修一个登录失败的 bug，不是一句话能完成的。它要先读代码、定位调用链、判断哪个文件该改哪个不能动、修改实现、跑测试、测试失败再看日志、日志可能又暴露另一个问题、修完之后还要确认没引入副作用。这一整套流程里，你最初写的那句"帮我修一下登录失败"，只是任务的起点，而不是任务的完成机制。

它没有告诉你：去哪里找入口、哪些文件不能动、怎么判断修好了、测试失败了怎么办、什么时候必须停下来问人、什么改动算越界。这些如果都靠模型自己猜，就会出现两个问题：模型浪费大量上下文去摸索，以及看起来非常努力、最后却朝错误方向越走越远。

很多开发者抱怨"AI 写代码不稳定"，根源往往不是模型差，而是你只给了一个 prompt，却没给它一个能稳定工作的闭环。

二、Loop 到底是什么

Loop 不是玄学，也不是让 AI 一直自动跑到天荒地老。

一个最小的 Agent Loop，大概是这样的循环：目标 → 计划 → 执行 → 观察 → 验证 → 反馈 → 下一步。验证通过，停止；验证失败，把失败信息带回去重新计划；触碰边界，暂停让人决策。

Loop Engineering 的正式定义，是把"人工下达指令、检查结果、决定下一步"的流程，封装成可自动运转的系统闭环：人只负责定义目标、规则与边界，AI 和工具在预设框架内自主完成规划、执行、校验、修正，直到达标或触发停止条件。

Loop 和普通 prompt 的差别，一句话能说清：普通 prompt 是"我说一句，你答一句"；Loop 是"我给你目标、工具、规则和验收标准，你自己推进，但每一步都要留下证据"。这也是 Claude Code 这类工具跟网页聊天框最大的区别------网页里你是在和模型对话，Claude Code 里模型会读文件、搜代码、改文件、跑命令、看报错、继续修。这些动作串起来，才是 Agent Loop。

三、Prompt 工程和 Loop 工程不是一回事

很多开发者以为"Loop 不就是自动多轮 Prompt 吗"，这是典型的误区。两者的差别，几乎在每个维度都完全不同：

维度	Prompt Engineering	Loop Engineering
驱动主体	每轮都需要人输入指令	预设系统，自动推进迭代
人的角色	一线操作者，逐轮指挥	规则设计者，一次性顶层定义
AI 的角色	被动响应	主动规划 + 执行 + 自检
时间尺度	秒级 / 分钟级	小时级 / 天级
错误处理	靠人发现并重新问	AI 自己 retry / 调整策略
核心技能	写好一个 Prompt	设计工作流 + 设定终止条件

简而言之：Prompt Engineering 解决"模型怎么回答"，Loop Engineering 解决"任务怎么被可靠完成"。

举一个具体例子。你让 Agent 修改一个支付回调的 bug。

只写 prompt 的人会说："帮我修一下支付回调偶尔失败的问题，注意代码质量。"------太虚了。

会写 loop 的人会把任务这样拆："先从支付回调入口开始读，不要修改数据库迁移文件。定位失败原因后给出改动计划。修改完成后跑支付模块单测，如果测试失败，优先根据错误日志修复；如果涉及幂等逻辑或金额计算，先停下来说明风险，不要直接改核心规则。"

这里不是提示词更华丽，而是把 loop 最关键的几个部件都放了进去：搜索入口、禁止修改的范围、计划阶段、测试反馈、错误恢复、高风险暂停点。

四、坏 Loop 比坏 Prompt 更危险

这里要泼一盆冷水。

一个坏 prompt，最多回答不理想。一个坏 loop，可能会一直跑、一直改、一直烧 token，甚至把项目改乱。很多人第一次用 Agent，上来就说"你自己看着办，直到修好为止"。这句话听着潇洒，但对 Agent 来说是一个危险指令------因为"修好"没有被定义，没有测试、没有验收标准、没有权限边界、没有停止条件，它只能自己脑补，脑补就会出事。

一个好的 loop 至少要具备四个东西：明确的目标 （不是"优化一下性能"，而是"让接口 P95 从 800ms 降到 300ms 以内，且不能改变返回结构"）、可执行的工具 （能读代码、跑测试、看日志、调脚本）、验证反馈 （测试、lint、构建、日志差异能回到上下文里）、停止条件（什么时候算完成、什么时候算失败、什么时候必须停下来问人）。

这四个东西缺一个，loop 就会变成"AI 自己猜自己对不对"。这种用法不是先进，是危险。

五、验证，是 loop 的眼睛

AI 编程最容易骗过人的地方，不是代码写得差，而是它特别会"看起来完成了"。它会给你一个完整的解释，列出改了哪些文件，告诉你问题已经修复，甚至把理由说得很顺。但如果没有测试、构建、日志、人工验收这些反馈，它说"完成了"是没有意义的。

真实项目里，我们判断一个改动能不能交付，不看解释得多漂亮，而是看：单测有没有过、构建有没有过、关键路径有没有回归、日志有没有异常、边界条件有没有覆盖。这些东西就是 loop 的"眼睛"，没有它们，Agent 只能靠语言自信------而语言自信是最不值钱的。

这里有一条整个领域都强调的原则，值得单独拎出来：工人不能给自己的作业打分 。Claude Code 的 /goal 命令，每完成一轮，会把条件和对话记录交给一个独立的小模型（默认是 Haiku）当裁判，裁判返回是/否并给出理由；判不过就读理由、再跑一轮，判过才自动停止。为什么这么设计？因为一个 Agent 给自己打分，会删掉那个失败的测试，然后宣布任务完成。

有个很实际的数据点：用这种"目标 + 独立验证器"的方式，同样的模型，编码正确率从 48% 跃升到了 95%。

六、Claude Code 为什么天然适合 Loop

Claude Code 的价值，不是把 Claude 搬进了终端。它真正厉害的地方，是把 AI 编程常见的动作做成了可循环执行的系统，并且把"干什么、什么时候停"的三种动词分得很清楚：

• /goal：跑到条件满足为止（直到完成），跑在你自己机器上，需要开着会话，由独立的裁判模型判定完成，最适用于"修到测试全过"。
• /loop：你盯着看的重复循环，跑在你自己机器上，需要开着会话，可以定时（最小 1 分钟）也可以自适应节奏，关掉会话就停止。
• /schedule（Routine）：跑在 Anthropic 云端，即使你合上电脑也能继续，适合"夜间扫 PR、自动修构建失败"这类需要人离开的后台任务。

关键点在于，Loop 不再依赖外部 cron 或 shell 脚本去反复调用 claude -p。过去每次调用都是一次"冷启动"，缺少上一轮的上下文；而 /loop 会在持续存在的 Claude Code 会话里运行，保留上下文窗口、工具权限和 MCP 连接，让 Agent 能记住上一轮操作并在下一轮继续推进。开发者可以用自然语言直接创建任务，比如"每 5 分钟检查一次 PR 构建是否通过，失败就读错误日志、修复并推送新 commit"，也可以写成 /loop "9 点总结 Slack 频道新帖" --interval 30m --expires 8h。

七、开发者不是被替代了，而是位置变了

看到"不写 prompt，写 loop"，有人会紧张：以后开发者是不是不用写代码，只写规则？

没这么简单。更准确地说，开发者的工作位置在变。以前你亲手写每一行代码；后来你让 AI 生成代码，但要一直盯着、提醒它、复制粘贴错误；再往后，你要把那些反复提醒，沉淀成规则、测试、脚本、文档和权限边界------也就是把"人盯人"变成"系统约束"。

过去你会反复提醒"别改这个文件"，现在应该写进项目规则或用权限拦住；过去你会反复说"改完跑测试"，现在应该让测试命令成为默认验证步骤；过去你会靠肉眼判断它有没有改对，现在要补测试、补脚本、补验收样例。

这不是开发者价值下降，恰恰相反。越是 Agent 能干活，越需要懂工程的人来定义什么叫干对。不会写代码的人很难写出好的 loop，因为他不知道哪里危险、哪里要验证、什么改动会引发连锁问题。所以别把 loop 理解成"AI 替我做所有事"，它更像是：开发者把自己的工程判断，外化成 Agent 可以执行的闭环。

八、普通开发者怎么开始写 Loop

如果你现在还只是偶尔让 AI 写点代码，不用一下子搞很复杂，从几个小动作开始就行。

第一，别只写目标，要写验收

不要只说"修复登录问题"，加一句"修完后跑登录模块测试，并说明失败用例是否恢复"。

第二，别只让它改，要让它先定位

不要上来就说"直接改"，先让它"先找登录入口、认证中间件和错误日志位置，列出可能原因，再改"。

第三，给它边界

比如"不要修改数据库 schema""不要改公开 API 返回结构""不要调整鉴权策略，除非先说明风险"。

第四，把反复说的话写进项目规则

如果你每次都提醒同一件事，就别再靠聊天提醒了，写进 CLAUDE.md，这就是从 prompt 走向 loop 的第一步。

第五，优先补反馈信号

没有测试的项目，用 Agent 会很累，你会一直靠人工判断。一旦补了测试、lint、构建脚本，Agent 才有东西可以观察，loop 才跑得起来。

九、冷水：Loop 的代价和现实

想法很美好，但现实是，Loop 工程的 token 消耗一点都不低。有人算过，如果设置 1 分钟执行一次、连续运行 8 小时，会产生 480 次 API 调用。社区里流传最深的一句话，是一位开发者的段子：

while (你还有 token):
    在循环里把它烧掉

所以有经验的做法很少被讨论，却极其关键：每个目标都要有预算，每条 loop 都要有上限。goal 条件里可以写"最多跑 N 轮就停"，Routine 要设每日消耗上限，而且要在你离开之前就设好，而不是等账单到了再设。

更有意思的是，有人把这段"while 循环"的原型一句话总结成了这个范式迁移本身------一家初创公司闹出的"一夜 400 美元账单"，成了很多人开始认真做 Agent FinOps 的导火索。

除了成本，loop 的实现也远比想象中麻烦。"所有人都在冲向 loops，但调试一个已经跑了 47 轮的状态机，比修好一个 prompt 难 10 倍。"有人甚至调侃，自己把 Loop 引进组织后，"有点对不起同事，因为现在想迁走已经要花太多时间了"。

还有一条现实的边界：实现 Loop 的人（Boris、Peter）背后都有近乎无限的 token 支持，而普通开发者的预算没这么高。就像有开发者说的，token 充裕的公司可以随意用 while 循环，token 紧张的初创公司也能用 for 循环达成同样目标，只是花的时间更长。Loop 依然是很强的方向，只是它从一开始就把"预算与验证"这两件事摆在了核心位置。

十、最后

Boris 那句话真正值得关注的，不是"不写 prompt"这四个字，而是它提醒我们：AI 编程正在从对话技巧，进入工程闭环。

Prompt 是入口，Loop 是系统。只会写 prompt，你最多让模型回答得更像你想要的样子；会写 loop，你才能让 Agent 在真实项目里持续推进、自动验证、出错纠偏、边界内行动。

以后 AI 编程里最值钱的能力，不是会不会喊 AI 干活，而是你能不能把一个模糊任务，拆成一个可执行、可验证、可停止的闭环。就像一位开发者评价的那样："我们已经从'学会写代码'，走到了'学会编写那个会写代码的东西'。"

这个转变，才是真正的工程能力。

内行动。

以后 AI 编程里最值钱的能力，不是会不会喊 AI 干活，而是你能不能把一个模糊任务，拆成一个可执行、可验证、可停止的闭环。就像一位开发者评价的那样："我们已经从'学会写代码'，走到了'学会编写那个会写代码的东西'。"

这个转变，才是真正的工程能力。