别再只写 Prompt 了：AI Loop 基础使用方法

很多人已经用了好几年 AI，但每天的工作方式还是一样：输入一个请求，等回答，自己判断好不好，再继续追问。

这当然能用，但它的上限很清楚：你才是发动机，AI 只是被你不断推动的工具。只要你停下来，它也停下来。

更快的方式不是写一个更长的万能提示词，而是把任务设计成一个可以持续推进的 Loop。你给 AI 的不再是一次性问题，而是目标、成功标准、验证方式和停止规则。

01 Prompt 和 Loop 的区别

Prompt 是一条单次指令。你问一次，AI 回一次，然后等待你决定下一步。

Loop 是一个持续运行的任务结构。你先定义目标，AI 围绕这个目标反复执行、检查、修复，直到完成，或者触发停止条件。

可以把两者的差别理解成这样：

• Prompt 解决的是“这一步怎么做”。
• Loop 解决的是“为了完成这个目标，接下来一轮一轮该怎么推进”。

普通 Prompt 里，方向盘一直在你手上。Loop 里，你仍然设定边界，但具体推进、检查和修复开始交给 agent 自己完成。

这就是为什么很多 AI 工程师开始关心的不只是“怎么写提示词”，而是“怎么设计能提示 agent 的循环”。

02 一个 Loop 到底怎么跑

一个基础 Loop 通常包含五步：

1. DISCOVER：找出当前还需要做什么。
2. PLAN：决定这一轮怎么做。
3. EXECUTE：执行任务。
4. VERIFY：对照目标检查结果。
5. ITERATE：如果没达标，把结果带入下一轮继续。

这五步看起来简单，但真正决定 Loop 质量的不是“执行”，而是“验证”。

没有验证，AI 只是不断生成内容。看起来很忙，实际上可能在原地打转。只有当每一轮都有明确的检查关卡，循环才会变成进步。

03 三个核心零件

一个能用的 Loop，至少要有三个零件：验证、状态、停止条件。

第一，Verify：验证是心脏。

验证可以是硬测试，比如测试是否通过、构建是否成功、类型检查是否干净。也可以是可测量条件，比如数字是否超过阈值。还可以是评分规则，比如让另一个模型按照 rubric 评估结果。

关键是不能只让执行者自己说“我完成了”。做事的模型往往会对自己的结果太宽容，所以严肃一点的 Loop 会把执行和检查拆开。

第二，State：状态让它不要重复犯错。

每跑一轮，AI 都需要记住自己试过什么、什么已经完成、什么失败了、下一步该做什么。否则它很容易在同一个错误里反复尝试。

状态不一定复杂。一个简短的任务记录、失败日志、待办清单，就能让下一轮不是从零开始。

第三，Stop condition：停止条件让它保持理智。

没有退出规则的 Loop，会一直跑到成功、崩掉，或者把预算烧完。

一个基本的停止条件应该同时包含两个出口：

• 成功：验证通过，停止。
• 上限：达到最大轮数、时间或 token 预算，停止并汇报。

比如：最多尝试 8 轮；8 轮还没通过，就停下来说明哪里失败、已经尝试过什么、下一步建议怎么处理。

04 你真的需要 Loop 吗

不是所有任务都值得做成 Loop。

如果只是偶尔做一次的事情，写一个好 Prompt 通常更划算。真正适合 Loop 的任务，最好同时满足四个条件：

1. 任务会重复出现，至少每周都要做。
2. 坏结果能被自动拒绝，比如测试失败、构建失败、lint 报错、格式不符合规则。
3. Agent 可以从头到尾完成大部分工作，不会中途把大量判断丢回给你。
4. “完成”有客观标准，而不是完全依赖审美和主观感觉。

缺任何一条，都先别急着上重型自动化。

Loop engineering 是真实方向，但大多数人的日常工作暂时不需要很重的版本。先做轻量 Loop，反而更容易跑通。

05 为什么它最先在代码里爆发

代码天然适合 Loop，因为验证条件清楚。

测试通过就是通过，测试失败就是失败。类型检查、lint、构建结果，也都能给 agent 明确反馈。

一个最基础的 coding loop 可以这样写：

GOAL:
让 /tests/auth 里的所有测试通过。
保持 lint 干净。
不能引入 type error。

EACH ITERATION:
1. 运行测试并阅读失败信息。
2. 选择影响最大的一个失败点。
3. 用最小修改修复它。
4. 重新运行测试、lint 和类型检查。

VERIFY:
测试全绿，0 lint warning，0 type error。

STOP WHEN:
验证通过，或者达到 8 次迭代上限。

ON STOP:
总结改了什么，仍然失败的点是什么。

这段真正重要的地方，不是它看起来像模板，而是它同时写清了目标、每轮动作、验证方式、停止规则和停止后的汇报格式。

这就是 Loop 和“帮我修一下测试”之间的差别。

06 真正可维护的 Loop 由什么组成

一个能长期运行的 Loop，通常会叠五层东西。

第一层是 Automation。它决定任务什么时候被触发，是手动执行、定时执行，还是由某个事件触发。

第二层是 Skill。不要每次都粘一大段说明，把稳定下来的规则保存成可复用文件，让任务有固定边界。

第三层是 Sub-agents。做事的 agent 和检查的 agent 最好分开。一个负责快，一个负责严。

第四层是 Connectors。连接器决定 AI 只是给建议，还是能真的创建 PR、关联 ticket、触发构建、通知频道。

第五层是 Verifier。测试、构建、类型检查、规则校验，才是 Loop 能不能进入生产环境的核心。

管道可以复杂，但判断标准要简单。没有 verifier，再漂亮的自动化也不稳。

07 别忽略成本

Loop 会消耗 token，token 就是成本。

问题不只是每一轮都要花钱，而是上下文会变大。目标、代码、上一轮结果、失败原因、修改记录，都会在后续轮次里继续被读入。

所以，一个跑 10 轮的 Loop，不等于 10 次普通 Prompt。它更像是 10 次越来越重的 Prompt。

如果你还用了 maker + checker 结构，质量可能上去，但账单也会跟着上去，因为两个模型都要读任务。

真正该看的指标不是“生成了多少内容”，而是“每个被接受的有效结果成本是多少”。

如果 Loop 产出 10 个结果，你最后丢掉 6 个，那你并没有真正省下审核工作。接受率低于一半时，这个 Loop 往往已经不划算。

更危险的是安静失败：它没有明显报错，但一直在跑、一直在消耗预算、一直没有产出真正可接受的结果。

所以重型 Loop 至少要有这些护栏：

• 迭代上限。
• token 或费用预算。
• 明确的失败汇报。
• 能自动拒绝坏结果的验证关卡。
• 必要时把便宜模型和强模型分工使用。

08 最稳的搭建顺序

如果你真的要搭一个 Loop，顺序比工具更重要。

稳定的顺序通常是：

1. 先让一次手动运行稳定。
2. 把这次运行沉淀成 Skill 或固定说明。
3. 给 Skill 套上 Loop，加验证关卡和停止条件。
4. 最后再接定时任务、hooks、CI 或连接器。

最危险的做法，是跳过前面几步，直接把一个还没手动跑通的任务放进自动化。

先证明一次，再固化，再自动化。

这个顺序很朴素，但能避免大部分“睡一觉醒来发现它跑偏了”的问题。

09 Codex 小白实践

如果你还不想搭重型系统，可以先在 Codex 或任意 LLM 里做一个轻量 Loop。

核心是一次性给它三样东西：目标、严格成功标准、自我检查协议。

可以直接这样写：

你要用 Loop 的方式完成这个任务。

目标：
[写清楚我要完成什么]

成功标准：
1. [标准一，必须可判断]
2. [标准二，必须可判断]
3. [标准三，必须可判断]

每一轮都按这个顺序执行：
1. 先判断当前结果离成功标准差什么。
2. 只选择最重要的一个问题处理。
3. 做出修改。
4. 按成功标准逐条自检。
5. 如果还没达标，继续下一轮。

停止条件：
验证全部通过，或者最多运行 5 轮。

停止时输出：
1. 最终结果。
2. 自检结论。
3. 仍然不确定或需要人工确认的地方。

你会看到模型开始起草、评分、找弱点、修改、再次评分，而不是把第一版看起来差不多的内容直接交给你。

这已经是一个很轻的 Loop。

它还不是完全自动化，因为触发器仍然是你。你打开聊天窗口、粘贴任务、盯着它跑。页面关掉，它不会明天早上主动继续。

但这足够让你理解 Loop 的核心：不是让 AI 多回答一次，而是让它在同一个目标下持续改进。

写在最后

Prompt 时代，我们在学习怎么问问题。

Loop 时代，我们要学习怎么定义目标、验证结果、保存状态，以及让系统知道什么时候该停。

不要一开始就追求复杂的 agent fleet。先挑一个每周都会重复、结果可以被验证的小任务，把它跑成一个轻量 Loop。

评论区可以聊聊：你手上哪个 AI 任务，最适合先改成 Loop？