# Loop Engineering.
**作者**: Addy Osmani
**日期**: 2026-06-08T23:30:35.000Z
**来源**: [https://x.com/addyosmani/status/2064127981161959567](https://x.com/addyosmani/status/2064127981161959567)
---
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop here can be thought of a recursive goal where you define a purpose and the AI iterates until complete. It's roughly five building blocks and Claude Code and Codex both have all five now.
I believe this may be the future of how we work with coding agents. However, its still early, I'm skeptical and you absolutely have to be careful about token costs (usage patterns can vary wildly if you are token rich or poor). You also still need some way to ensure quality doesn't drop and concerns re: slop are valid. That said, let's explore what this is all about.
@steipete recently said: “You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.” Similarly, @bcherny, head of Claude Code at Anthropic, said “I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops”.
Okay, so what does any of that mean?
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, or at least some think it's going to be.
Now you build a small system that finds the work, hands it out, checks it, writes down what is done and then decides the next thing, and you let that system poke the agents instead of you. I wrote before about the cousin of this, agent harness engineering, which is making the environment one single agent runs inside and the factory model - the system that builds the software. Loop engineering sits one floor above the harness. The harness but it runs on a timer, it spawns little helpers, and it feeds itself.
The thing that surprised me is this is not really a tool thing anymore. A year ago if you wanted a loop you wrote a pile of bash and you maintained that pile forever and it was yours and only yours. Now the pieces just ship inside the products. Steinberger's list maps almost exactly onto the Codex app, and then almost the same onto Claude Code. And once you notice the shape is the same you stop arguing about which tool, you just design a loop that still works no matter which one you happen to be sitting in.
## The five pieces, and then notes
A loop needs five things and then one place to remember stuff. Let me list it first and then map it.
1. Automations that go off on a schedule and do discovery and triage by themselves.
2. Worktrees so two agents working in parallel dont step on each other.
3. Skills to write down the project knowledge the agent would otherwise just guess.
4. Plugins and connectors to plug the agent into the tools you already use.
5. Sub-agents so one of them has the idea and a different one checks it.
Then the sixth thing, the memory. A markdown file, or a Linear board, anything that lives outside the single conversation and holds what's done and what is next. Sounds too dumb to matter. But it's the same trick every long running agent depends on and I went into it in long-running agents, the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesnt.
Both products have all five now.
The names are a bit different here and there but the capability is the same thing. Let me go one by one because honestly the details are where a loop either holds together or quietly leaks everywhere.
## Automations, this is the heartbeat
Automations are what make a loop an actual loop and not just one run you did once. In the Codex app you make one in the Automations tab and you pick the project, the prompt it will run, how often, and if it runs on your local checkout or on a background worktree. The runs that find something go to a Triage inbox, and the runs that find nothing just archive themselves which is nice. OpenAI uses them internally for boring stuff like daily issue triage, summarizing CI failures, writing commit briefings, hunting bugs somebody added last week. And an automation can call a skill, so you keep the recurring thing maintainable, you fire $skill-name instead of pasting a giant wall of instructions into a schedule that nobody will ever update.
Claude Code gets to the same place but through scheduling and hooks. You can run a prompt or a command on a interval with /loop, you can schedule a cron task, you can fire shell commands at certain points in the agent lifecycle with hooks, or you push the whole thing to GitHub Actions if you want it to keep running after you close the laptop. Same idea exactly, you define an autonomous task, you give it a cadence, and the findings come to you so you are not the one going around checking.
There is a second in-session primitive worth knowing, and it's the one closer to what this whole post is about. /loop re-runs on a cadence. /goal keeps going until a condition you wrote is actually true, and after every turn a separate small model checks whether you are done, so the agent that wrote the code isnt the one grading it. You give it something like "all tests in test/auth pass and lint is clean" and walk away. Codex has the same thing, also called /goal, it keeps working across turns until a verifiable stopping condition holds, with pause and resume and clear. Same primitive, both tools, wich is kind of the pattern for this whole article.
So this is the part that surfaces the work. The rest of the loop is what acts on it.
## Worktrees so parallel doesn't turn into chaos
The second you run more than one agent the files start colliding, that becomes the failure. Two agents writing the same file is the exact same headache as two engineers committing to the same lines and nobody talked to each other first. A git worktree fixes it, its a separate working directory on its own branch sharing the same repo history, so one agent's edits literally can not touch the other one's checkout.
Codex builds the worktree support right in so several threads hit the same repo at once and dont bump into each other. Claude Code gives you the same isolation with git worktree, a --worktree flag to open a session in its own checkout, and a isolation: worktree setting you stick on a subagent so each helper gets a fresh checkout that cleans itself up after. I wrote about the human side of all this in the orchestration tax, the worktrees take away the mechanical collision but YOU are still the ceiling, your review bandwith decides how many you can actually run, not the tool.
## Skills, so you stop explaining your project every single time
A skill is how you stop re-explaining the same project context every session like a goldfish. Both tools use the same format, a folder with a SKILL.md inside holding instructions and metadata, and then optional scripts, references, assets. Codex runs a skill when you call it with $ or /skills, or by itself when your task matches the skill description, which is the reason a tight boring description beats a clever one. Claude Code does it the same way and I wrote the pattern up in agent skills.
Skills are also where intent stops costing you over and over. I argued in the intent debt that an agent starts every session cold and it will fill any hole in your intent with a confident guess. A skill is that intent written down on the outside, the conventions, the build steps, the “we dont do it like this because of that one incident”, written one time where the agent reads it every run. Without skills the loop re-derives your whole project from zero every cycle, with skills it kind of compounds.
One thing to keep straight, the skill is the authoring format and a plugin is how you ship it. When you want to share a skill across repos or bundle a few together you package them as a plugin. True in Codex, true in Claude Code.
## Plugins and connectors, the loop touches your real tools
A loop that can only see the filesystem is a tiny loop. Connectors, which are built on MCP, let the agent read your issue tracker, query a database, hit a staging api, drop a message in Slack. Codex and Claude Code both speak MCP so the connector you wrote for one usually just works in the other. And plugins bundle connectors and skills together so your teammate installs your setup in one go instead of rebuilding the whole thing from memory.
This is the difference between an agent that says “here is the fix” and a loop that opens the PR, links the Linear ticket and pings the channel once CI is green by itself. The connectors are the reason the loop can act inside your actual environment instead of just telling you what it would do if it could.
## Sub-agents, keep the maker away from the checker
The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks. The model that wrote the code is way too nice grading its own homework. A second agent with different instructions and sometimes a different model catches the stuff the first one talked itself into.
Codex only spawns subagents when you ask, runs them at the same time and then folds the results back into one answer. You define your own agents as TOML files in .codex/agents/, each with a name, a description, instructions and optional model and reasoning effort, so your security reviewer can be a strong model on high effort while your explorer is some fast read-only thing. Claude Code does the same with subagents in .claude/agents/ and agent teams that pass work between them. The usual split in both is one agent explores, one implements, one verifies against the spec.
I made this case twice already, once as the code agent orchestra and once as adversarial code review. The reason it matters specifically inside a loop is the loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away. Subagents do burn more tokens since each one does its own model and tool work, so spend them where a second opinion is worth paying for. This is also basically what Claude Code's /goal does under the hood, a fresh model decides if the loop is done instead of the one that did the work, the maker and checker split applied to the stop condition itself.
## What one loop looks like
Stick it together and a single thread turns into a little control panel. Here is one shape I keep using.
An automation runs every morning on the repo. Its prompt calls a triage skill that reads yesterdays CI failures, the open issues, the recent commits, and writes the findings into a markdown file or a Linear board. For each finding that is worth doing the thread opens an isolated worktree and sends a sub-agent to draft the fix, and a second sub-agent reviews that draft against the project skills and the existing tests.
Connectors let the loop open the PR and update the ticket. Anything the loop can not handle lands in the triage inbox for me. The state file is the spine of the whole thing, it remembers what got tried, what passed, what is still open, so tomorrow morning the run picks up where today stopped.
And look at what you actually did there. You designed it one time. You did not prompt any of those steps. Thats Steinberger's whole point made real, and its the same loop in Codex or in Claude Code because the pieces are the same pieces.
## What the loop still does not do for you
The loop changes the work, it does not delete you from it. And three problems actually get sharper as the loop gets better, not easier.
Verification is still on you. A loop running unattended is also a loop making mistakes unattended. The whole reason you split the verifier sub-agent from the maker is to make the loop's “its done” mean something, and even then “done” is a claim and not a proof. I keep saying the same line from code review in the age of AI, your job is to ship code you confirmed works.
Your understanding still rots if you allow it. The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually get. Thats comprehension debt and a smooth loop just makes it grow faster unless you read what the loop made.
And yeah, the comfortable posture is probably the risky one. When the loop runs itself its very tempting to stop having an opinion and just take whatever it gives back. I called that cognitive surrender. Designing the loop is the cure when you do it with judgement and the accelerant when you do it to avoid thinking, same action, opposite result.
## Build the loop. Stay the engineer.
I think this is a preview of how our work is going to evolve. That said, If I weren't reviewing the code myself or if I relied entirely on automated loops to fix it my product’s quality would suffer. I'd likely end up stuck in a downward spiral, continuously digging myself into a deeper hole.
That said, go ahead and set up your loops, but don't forget that prompting your agents directly is still effective. It's all about finding the right balance.
Loops can also result in different outcomes depending on you. Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn't know the difference. You do.
That's what makes loop design harder than prompt engineering, not easier. Cherny's point isn’t that the work got easier. It's that the leverage point moved.
Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.
## 相关链接
- [𝙩𝙮≃𝙛{𝕩}^A𝕀²·ℙarad𝕚g𝕞 reposted](https://x.com/TaNGSoFT)
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [171K](https://x.com/addyosmani/status/2064127981161959567/analytics)
- [@steipete](https://x.com/@steipete)
- [said](https://x.com/steipete/status/2063697162748260627)
- [@bcherny](https://x.com/@bcherny)
- [said](https://x.com/rohanpaul_ai/status/2063289804708835412)
- [agent harness engineering](https://addyosmani.com/blog/agent-harness-engineering/)
- [factory model](https://addyosmani.com/blog/factory-model/)
- [loop](https://x.com/reach_vb/status/2063713960495558940)
- [long-running agents](https://addyosmani.com/blog/long-running-agents/)
- [$skill-name](https://x.com/search?q=%24skill-name&src=cashtag_click)
- [the orchestration tax](https://addyosmani.com/blog/orchestration-tax/)
- [agent skills](https://addyosmani.com/blog/agent-skills/)
- [the intent debt](https://addyosmani.com/blog/intent-debt/)
- [the code agent orchestra](https://addyosmani.com/blog/code-agent-orchestra/)
- [adversarial code review](https://addyosmani.com/blog/adversarial-code-review/)
- [code review in the age of AI](https://addyosmani.com/blog/code-review-ai/)
- [comprehension debt](https://addyosmani.com/blog/comprehension-debt/)
- [cognitive surrender](https://addyosmani.com/blog/cognitive-surrender/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:30 AM · Jun 9, 2026](https://x.com/addyosmani/status/2064127981161959567)
- [171.2K Views](https://x.com/addyosmani/status/2064127981161959567/analytics)
- [View quotes](https://x.com/addyosmani/status/2064127981161959567/quotes)
---
*导出时间: 2026/6/9 12:37:16*
---
---
## 中文翻译
# 循环工程。
**作者**: Addy Osmani
**日期**: 2026-06-08T23:30:35.000Z
**来源**: [https://x.com/addyosmani/status/2064127981161959567](https://x.com/addyosmani/status/2064127981161959567)
---
循环工程是指你不再是那个亲自向 AI 发送提示词的人，取而代之的是，你设计了一套能够自动完成这项工作的系统。这里的“循环”可以被视为一个递归的目标：你定义一个目的，然后 AI 进行迭代直到完成。它大致由五个构建块组成，Claude Code 和 Codex 目前都已具备这五个要素。
我相信这可能就是我们未来与代码代理协作的方式。不过，现在还为时尚早，我对此持怀疑态度，而且你必须时刻留意 Token 的成本（根据你的 Token 充裕程度，使用模式可能会有巨大的差异）。你仍然需要某种方式来确保质量不下降，对于生成“垃圾代码”的担忧也是合理的。话虽如此，让我们来深入探讨这究竟是怎么一回事。
@steipete 最近说：“你不应该再手动去提示代码代理了。你应该设计能自动向代理发送提示的循环。”同样，Anthropic 负责 Claude Code 的负责人 @bcherny 也表示：“我不再手动提示 Claude 了。我有运行中的循环，它们负责提示 Claude 并弄清楚该做什么。我的工作就是编写这些循环”。
好吧，这到底意味着什么？
在过去的两年里，你想从代码代理那里获得成果，方式就是写出一个好的提示词并提供足够的上下文。你输入一条指令，阅读返回的内容，再输入下一条指令。代理是一个工具，而你全程紧握着它，一轮接一轮地交互。这种模式大概已经结束了，或者至少有些人认为是这样。
现在，你要构建一个小型的系统，由它来寻找工作、分发任务、检查结果、记录已完成的事项，然后决定下一步做什么，并且让这个系统代替你去驱动代理。我之前写过这类概念的相关文章，一个是代理Harness工程，即让单个代理运行其中的环境；另一个是工厂模式，即构建软件的系统。循环工程位于 Harness 之上的一层。它就像是 Harness，但运行在定时器上，它会生成小的助手，并自我供给。
令我惊讶的是，这不再仅仅是一个工具问题。一年前，如果你想要一个循环，你得写一堆 Bash 脚本，然后永远维护这堆脚本，它是你的专属品。现在，这些组件直接内置在产品中。Steinberger 的列表几乎完美映射到了 Codex 应用上，也几乎完全映射到了 Claude Code 上。一旦你注意到这种架构模式是相同的，你就不会再争论该用哪个工具，你只需要设计一个循环，无论你恰好身处哪个环境中，它都能正常工作。
## 五个组成部分，以及相关说明
一个循环需要五样东西，外加一个用于记忆信息的地方。让我先列出来，然后再一一映射。
1. **自动化任务**：按计划启动，独立完成发现和分类工作。
2. **工作树**：确保两个并行工作的代理不会互相踩脚。
3. **技能**：记录项目知识，避免代理只能靠猜。
4. **插件和连接器**：将代理接入你已经在使用的工具。
5. **子代理**：让其中一个负责构思，另一个负责检查。
然后是第六样东西，记忆。一个 Markdown 文件，或者 Linear 看板，任何存在于单一对话之外、记录了“已做之事”和“待办之事”的载体。听起来这玩意儿太笨了，无关紧要。但这正是每一个长期运行的代理所依赖的诀窍，我在长期运行的代理一文中探讨过这个问题：模型在两次运行之间会忘得一干二净，所以记忆必须存在磁盘上，而不是上下文中。代理会遗忘，但代码仓库不会。
这两款产品现在都已具备这全部五点。
虽然这里的名字有些许不同，但功能本质是一样的。让我逐一过一遍，因为说实话，细节决定了一个循环是稳固运行，还是悄无声息地到处漏气。
## 自动化任务，这是循环的心跳
自动化任务是让循环成为一个真正的“循环”，而不是只运行一次的任务的关键。在 Codex 应用中，你可以在“Automations”标签页创建一个任务，选择项目、设定运行的提示词、运行频率，以及是在你的本地检出版本上运行还是在后台工作树上运行。那些发现了问题的运行结果会进入分类收件箱，而一无所获的运行结果会自动归档，这很贴心。OpenAI 在内部将这些用于处理枯燥的杂事，比如每日 Issue 分类、CI 失败总结、编写提交简报、追踪某人上周引入的 Bug。而且，自动化任务可以调用技能，这样你就能保持定期任务的可维护性，你只需触发 `$skill-name`，而不用把一大段指令贴到一个没人会去更新的定时任务里。
Claude Code 通过调度和 Hooks 达到了同样的目的。你可以使用 `/loop` 按间隔运行提示词或命令，你可以调度 cron 任务，你可以在代理生命周期的特定节点通过 Hooks 触发 Shell 命令，或者如果你想让它在你合上笔记本后继续运行，你可以把整个任务推给 GitHub Actions。思路完全一致：你定义一个自主任务，给它一个节奏，结果会自动呈现给你，而不是你到处去检查。
还有第二个会话内的原语值得了解，它更接近整篇文章的主旨。`/loop` 会按节奏重新运行。`/goal` 会持续运行直到你写入的条件真正满足，并且在每一轮之后，一个独立的小型模型会检查你是否完成了，这样编写代码的代理就不是给自己打分的那个人了。你可以给它类似“test/auth 下的所有测试通过且 lint 检查干净”这样的指令，然后就可以走开了。Codex 也有同样的功能，也叫 `/goal`，它会跨轮次持续工作，直到满足可验证的停止条件，支持暂停、恢复和清除。原语相同，工具皆有，这基本上就是整篇文章的模式。
所以这是负责显化工作的部分。循环的其余部分则是作用于这些发现的内容。
## 工作树，让并行不会变成混乱
只要你运行超过一个代理，文件冲突就会立刻发生，这就是失败的根源。两个代理同时写入同一个文件，其头疼程度完全等同于两个工程师在没有沟通的情况下提交了同一行代码。Git worktree 解决了这个问题，它是一个拥有独立分支的独立工作目录，但共享同一个仓库历史，所以一个代理的编辑在物理上根本不可能触碰到另一个代理的工作区。
Codex 内置了 worktree 支持，所以多个线程可以同时命中同一个仓库而互不干扰。Claude Code 通过 git worktree 提供了同样的隔离机制，通过 `--worktree` 标志在其独立检出版本中打开会话，以及一个 `isolation: worktree` 设置，你可以将其贴在子代理上，这样每个助手都会获得一个干净的检出版本，并在完成后自动清理。我在编排税一文中写过这方面的人类视角，worktree 解决了机械层面的冲突，但你依然是天花板，你实际能运行多少个代理取决于你的审阅带宽，而不是工具的能力。
## 技能，别再每次都从头解释你的项目
技能就是让你停止像金鱼一样每个会话都重复解释同样项目上下文的方法。两款工具使用相同的格式：一个包含 `SKILL.md` 的文件夹，里面存放着指令和元数据，然后是可选的脚本、引用和资源。Codex 当你使用 `$` 或 `/skills` 调用它，或者当你的任务匹配技能描述时会自动运行（这也是为什么写一个死板无聊的描述比自作聪明的描述更好）。Claude Code 的做法也一样，我在代理技能一文中写过这个模式。
技能也是让意图不再反复消耗成本的地方。我在意图债一文中指出，代理开始每个会话时都是一张白纸，它会用自信的猜测填补你意图中的任何空白。技能就是这种外部的意图记录：约定俗成的规范、构建步骤、以及“因为那一次事故，我们不再那样做”之类的备注，只写一次，代理每次运行时都会阅读。没有技能，循环每一轮都要从零重新推导你的整个项目；有了技能，它就产生了复利效应。
有一点需要理清，技能是创作格式，而插件是分发方式。当你想跨仓库分享一个技能或将几个技能打包时，你可以将它们封装为插件。Codex 如此，Claude Code 亦如此。
## 插件和连接器，循环接触你的真实工具
一个只能看到文件系统的循环是渺小的。连接器（基于 MCP 构建）让代理能够阅读你的 Issue 追踪器、查询数据库、访问暂存 API、在 Slack 中发送消息。Codex 和 Claude Code 都支持 MCP，所以你为其中一个编写的连接器通常在另一个中也能直接使用。插件将连接器和技能打包在一起，这样你的队友只需一键安装你的配置，而不用凭记忆重新构建整个系统。
这就是区别所在：一个代理只会说“这是修复方案”，而一个循环会自己打开 PR、关联 Linear 票据，并在 CI 变绿后自动在频道里 ping 一下。连接器是循环能够在你实际环境中执行操作的原因，而不只是告诉你“如果有权限它会怎么做”。
## 子代理，让构建者远离检查者
循环中最有用的结构性设计，无疑是将编写者和检查者分开。编写代码的模型在给自己的作业打分时实在是太“宽容”了。一个拥有不同指令、有时甚至使用不同模型的第二个代理，能捕捉到第一个代理自说自话所产生的问题。
Codex 仅在你要求时才生成子代理，同时运行它们，然后将结果折叠回一个答案。你通过 `.codex/agents/` 中的 TOML 文件定义自己的代理，每个都有名称、描述、指令以及可选的模型和推理强度设置，这样你的安全审查员可以是一个高强度的强力模型，而你的探索者则是一个快速的只读模型。Claude Code 的做法也一样，使用 `.claude/agents/` 中的子代理以及在彼此之间传递工作的代理团队。两者中常见的划分是一个代理负责探索，一个负责实现，一个负责对照规范进行验证。
我已经两次提出这个观点，一次是在代码代理乐团，一次是在对抗性代码审查。之所以这在循环中尤为重要，是因为循环是在你视线之外运行的，所以一个你真正信任的验证器是你能够抽身离开的唯一理由。子代理确实会消耗更多 Token，因为每个都有各自的模型和工具开销，所以要把钱花在值得“第二意见”的地方。这也基本上就是 Claude Code 的 `/goal` 在底层所做的事情：用一个全新的模型来判断循环是否结束，而不是由干活的那个模型来判断，这是“构建者与检查者”分离模式应用于停止条件本身。
## 一个完整的循环长什么样
把它们组装在一起，单个线程就变成了一个小型的控制面板。这是我一直使用的一种形态。
每天早上在仓库上运行一个自动化任务。它的提示词会调用一个分类技能，读取昨天的 CI 失败记录、开放的 Issue 和最近的提交，然后将发现结果写入一个 Markdown 文件或 Linear 看板。对于每一个值得处理的发现，该线程会打开一个隔离的工作树，并派送一个子代理去起草修复方案，第二个子代理则对照项目技能和现有测试审查该草案。
连接器让循环能够打开 PR 并更新票据。任何循环无法处理的事项都会落入我的分类收件箱。状态文件是整个系统的脊梁，它记住了尝试了什么、通过了什么、什么仍待处理，所以明天早上的运行能从今天停止的地方接续。
看看你实际上在那里做了什么。你只设计了一次。你没有去提示其中的任何步骤。这就是 Steinberger 的观点变成了现实，无论是在 Codex 还是 Claude Code 中，这都是相同的循环，因为组件就是那些组件。
## 循环目前还不能为你做什么
循环改变了工作，而不是把你从工作中抹去。而且随着循环变得更完善，有三个问题实际上变得更加尖锐，而不是更容易。
验证仍然是你自己的责任。无人值守运行的循环也是无人值守地犯错的循环。你要将验证者子代理与构建者分开，全部原因就是为了让循环声称的“做完了”具有实际意义，即便如此，“完成”也只是一个声明，而非证明。我一直引用那句来自 AI 时代代码审查的话：你的工作是发布你确认过有效的代码。
如果你放任自流，你的理解力依然会腐烂。循环运送非你编写的代码速度越快，现实存在的内容与你实际掌握的内容之间的差距就越大。这就是理解债，一个顺畅的循环只会让这种债务增长得更快，除非你阅读循环产出的内容。
是的，这种舒适的姿势可能恰恰是危险的。当循环自我运行时，很容易不再持有观点，只是照单全收它返回的结果。我称之为认知投降。当你带着判断力去设计循环时，它是解药；但当你为了避免思考而设计时，它就是加速剂。同样的动作，相反的结果。
## 构建循环。保持工程师本色。
我认为这是我们工作方式演变的预览。话虽如此，如果我不亲自审查代码，或者完全依赖自动化循环来修复，我产品的质量就会受损。我很可能最终会陷入一个向下的螺旋，不断把自己埋进更深的坑里。
尽管如此，去建立你的循环吧，但不要忘记直接向代理发送提示词依然有效。关键在于找到正确的平衡。
循环也会因人而异产生不同的结果。两个人可以构建完全相同的循环，却得到截然相反的结果。一个人用它来在他深刻理解的工作上加快速度。另一个人用它来完全避免理解工作。循环并不知道其中的区别。你知道。
这就是为什么循环设计比提示词工程更难，而不是更容易。Cherny 的观点不是工作变容易了，而是杠杆的支点移动了。
构建循环。但要像一个打算继续做工程师的人那样去构建，而不是做一个只会按“开始”键的人。