Loops 解析:Claude、GPT、Mira,以及真正有效的做法

📅 2026/6/30 4:19:46
Loops 解析:Claude、GPT、Mira,以及真正有效的做法
你还在一句一句喂prompt给ChatGPT or Claude 吗AI 已经在每个人手里很多年了。大多数每天使用 AI 的人仍然在用最慢的方式使用它输入一个请求等待结果手动修改再继续追问全程都靠自己一步步推动。不是因为更快的方式很复杂而是因为没人给他们展示过它到底长什么样。更快的方式就是一个 loop而现在它正是全世界最顶尖的 AI 工程师最关心的东西。这篇文章会补上没人讲清楚的那一部分。读完之后你会比时间线上几乎所有人都更懂 loops它们是什么底层到底怎么运作什么时候值得用、什么时候是陷阱如何在 Claude 或 ChatGPT 里自己搭一个基础 loop以及哪些简单 loop 值得放进你自己的生活里。大多数人是怎么使用 AI 的仔细看看这种“一次只提一个请求”的习惯因为这就是整个问题所在。每一步都要经过你。你决定问什么你判断答案好不好你决定下一步做什么。除非你推动它否则 AI 不会自己往前走而你一停它也就停了。这当然也可以但它有上限。你才是引擎。AI 只是你手里的工具而工具本身不会自己做任何事。还有另一种工作方式这也是全世界最顶尖工程师正在改变构建方式的原因。你不再一步一步带着 AI 走而是只给它一次目标然后让它自己跑完步骤。它会规划、执行、检查自己的结果、修复薄弱之处并不断重复直到目标达成。你退出来工作依然继续。两位最受尊敬的工程师用不同的话说了同一件事。大多数人读到这样的句子时其实并不知道它们在实践中到底是什么意思。所以我们认真拆开来看。什么是 loopPrompt 是一条单次指令。Loop 是一个 AI 会持续朝着它工作、直到抵达的目标。你可以把它理解成一个递归目标你定义一个目的AI 不断迭代直到完成。Prompt 给你一个答案然后等你决定下一步是什么。Loop 会自己跑完整个周期DISCOVER → 搞清楚需要做什么 PLAN → 决定怎么做 EXECUTE → 执行工作 VERIFY → 按目标检查结果 ITERATE → 还没达标把结果反馈回去然后重复这五个步骤里有三个真正承担了核心工作也正是在这里人们最容易把 loops 做错。Verify 是 loop 的心脏。如果没有对结果的真实检查你就没有一个 loop你只是让 agent 一遍遍同意自己。检查才是把重复变成进展的东西。它可以是一个硬测试“代码是否通过”一个可衡量条件“数字是否高于 X”也可以是模型按评分标准进行打分的 rubric。没有关卡就等于让 agent 给自己的作业打分而完成工作的那个模型作为评分者通常太宽容了。State 让 loop 能够学习。每一轮里AI 都必须记住自己已经尝试过什么否则它会永远重复同一个错误。真正的 loop 会在旁边保留一小份记录什么已经完成什么失败了下一步是什么。明天再运行时它会接着做而不是从零开始。这也正是成本开始变高的地方后面我们会讲到。Stop condition 让 loop 保持理性。没有退出条件的 loop 会一直运行直到成功、崩掉或者耗尽你的账户。每一个严肃的 loop 都有两种停止方式成功或者硬性上限“尝试 8 次后停止并报告”。跳过这一点你就造出了一台可以整晚空转的机器。Prompt 是把一条指令交给 AI。Loop 是把一份工作交给 AI同时给它判断工作何时完成的方法以及什么时候应该放弃的规则。你真的需要一个 loop 吗大多数文章会先把 loop 卖给你再告诉你什么时候它其实是个错误。下面才是严肃的人真正会用的测试。只有当下面四件事全都成立时才值得搭建一个 loop任务会重复至少每周一次。少于这个频率搭建成本就回不来。一次性任务仍然更适合用一个好 prompt。必须有某种东西能自动拒绝糟糕输出。测试、类型检查、构建、linter、硬性规则都可以。如果没有任何东西能替你判定工作失败loop 就只是在空转。Agent 必须真的能自己端到端完成工作而不是把一半又交还给你。“完成”必须是客观的而不是主观判断。如果质量主要取决于审美人类仍然更强。漏掉其中任何一项就继续把它当作手动 prompt。这个话题最诚实的版本是loop engineering 是真实存在的但大多数人现在还不需要重型版本。每个人都能用的是轻量版本后面会讲。但你应该知道边界在哪里。为代码而生的版本Loops 最先在软件领域火起来因为代码是世界上最容易验证的东西。测试要么通过要么失败。没什么可争的所以 AI 总能知道自己是否完成了。一个 coding loop 会被给定一个目标以及一个严格的检查方式▸ LOOP SPEC GOAL: /tests/auth 里的所有测试通过lint 干净没有类型错误。 EACH ITERATION: 1. 运行测试套件并读取每一个失败项 2. 选择影响最大的单个失败项 3. 写出能修复它的最小改动 4. 重新运行测试、lint 和类型检查器 VERIFY: 测试全绿 0 个 lint 警告 0 个类型错误 STOP WHEN: verify 通过或达到 8 次迭代 ON STOP: 总结改了什么以及还有什么仍然失败