Loop Engineering：从提示者到循环设计者的14步路线图

勇哥AI笔记

发布于 2026-06-29 12:40:15

2100

文章被收录于专栏：技术人生黄勇技术人生黄勇

最近 Loop Engineer 比较火，发了两篇Loop Engineer Template 详解，Loop Engineering 如何使用AI编程智能体：构建可循环系统，今天继续翻译一篇具体讲解构建循环的14步路线图。

大多数开发者仍然手工提示他们的编程智能体。他们打字、等待、读diff、再打字。10个构建者中有9个从未写过一行能替他们提示智能体的循环代码。

没有自动化，没有状态文件，没有验证器，没有调度。杠杆点已经转移——从手写提示转向设计能够提示的系统。这就是从提示者到循环设计者的14步路线图。

这就是实现这种转变的14步路线图——素材来源于Anthropic的工程文档、Addy Osmani关于循环工程的长文，以及近期的测量研究。

三个层次：搞清楚你是否真的需要循环，学习五个构建块，然后构建一个最小的能工作且不会伤害你的循环。

三层架构

14个步骤。3个层次。停止提示。开始设计。

第一部分 · 为什么 & 测试

01. 循环工程就是取代你作为提示者的角色。

两年以来，你从编程智能体那里获得产出的方式是：写一个提示，共享上下文，读返回结果，写下一个提示。智能体是一个工具，而你全程握着它。

这个阶段正在结束。

循环工程是构建一个小系统，它能够发现工作、提交给智能体、检查结果、记录发生了什么、并决定下一步——全自动。你只需要设计这个系统一次，之后系统会自行提示智能体。

Addy Osmani将其分解为六个部分：

Osmani六部分

Anthropic的工程师现在每天合并的代码量是2024年的八倍——Anthropic自己称这个数字"几乎肯定高估了真正的生产力提升"。

数字存在争议。但机制不争：杠杆点从手写提示转移到了设计提示的循环。

02. 在构建任何东西之前，先做四条件测试。

循环在四种条件下才能收回成本。缺少任何一个条件，循环的成本就会超过回报。来自AlphaSignal分析的诚实结论，也是大多数X帖子跳过的部分：

四条件测试

四个条件用大白话说：

• 任务会重复出现。 循环通过多次运行来摊销其设置成本。对于一次性任务，一个精心编写的提示更快更便宜。如果工作不会每周重复出现，你就没有一个循环——你只有一个运行过一次的脚本。
• 验证是自动化的。 循环需要一个能在你不在场时判定工作失败的东西。测试套件、类型检查器、代码检查工具、构建。没有自动检查就意味着你又回到了椅子上逐行读diff——这正是循环本应消除的工作。
• 你的Token预算可以承受浪费。 循环会反复读取上下文、重试、探索。无论运行是否产出任何东西，这都会消耗Token。这种技术的可扩展性与预算挂钩，这就是为什么它在有几乎免费Token的人看来理所当然，而在使用计量计划的人看来则是不计后果。
• 智能体拥有资深工程师的工具。 日志、可复现环境、运行自己写的代码并看到哪里出错的能力。没有这些，循环就是在盲目迭代。

03. 谁会赢，谁会输。循环偏向能花钱的一方。

经济学并非普适。那些说循环工程显而易见的人，通常拥有不限量的Token。

那些认为它不计后果的人，通常在用20美元的消费者计划，试图运行重度验证循环而不触及限制或收到意外账单。

在实践中，谁真正受益：

• 有重复性、机器可检查的工作且有预算运行的团队——持续的测试分类、依赖升级、代码检查修复、在测试覆盖率高的代码库上从Issue草拟PR。
• 拥有强大现有测试套件的代码库。 如果一个初级工程师可以按照清单完成任务并且测试套件会抓住他的错误，那么这个循环就适用。
• 已经在使用多智能体模式的异步优先团队。 对这些团队来说，例行程序是缺失的编排层。

今天应该跳过的人：

• 使用消费者计划的独立构建者——Token账单比生产力提升先到。
• 任何在无自动验证的代码上工作的人。 没有真正检查的循环，就是智能体在重复自嗨。
• 真正瓶颈是审查能力而非打字速度的团队。 循环产生更多代码；如果审查已经是瓶颈，它只会让队列更长。

对于一次性任务、探索性工作、或任何"完成"是判断性决策的事情，一个精准的单次提示仍然胜出。这篇文章的诚实版本是：循环工程是真的，而大多数开发者还不需要它。

04. 30秒循环检查。

第2步的四条件测试是战略决策。这个是战术决策——在将特定任务转化为循环之前要运行的检查清单。

少勾一个框，就保持手动提示。

1. 任务至少每周发生一次。 低于每周→设置成本永远无法摊销。
2. 测试、类型检查、构建或代码检查工具可以拒绝不良输出。 没有自动关卡→智能体自己给自己批改作业。
3. 智能体可以运行它修改的代码。 没有可复现环境→迭代是盲目的。
4. 循环有一个硬性停止。 Token预算、迭代次数或时间限制。没有的话，循环会一直运行直到有人注意到账单。
5. 在合并、部署或依赖变更之前有人工审查。 任何不可逆的操作都需要人工批准关卡才能执行。

30秒检查

好的入门循环：

• CI故障分类——每晚扫描故障，分类原因，为简单的起草修复PR。
• 依赖升级PR——每周扫描更新，测试兼容性，开放PR。
• 代码检查修复——在每次PR打开事件时，自动应用风格修复。
• 不稳定测试复现——循环直到某个理论能经得起测试。
• 从Issue草拟PR——在测试覆盖强的代码上，不良输出会被测试套件拒绝。

坏的入门循环——这些需要有人在椅子上盯着：

• 架构重写
• 认证或支付代码
• 生产环境部署
• 模糊的产品工作
• 任何"完成"是判断性决策的事情

第二部分 · 五大构建块

05. 自动化：心跳。

自动化是让循环成为真正循环而不是你运行过一次的东西的关键。它们按计划、按事件或按触发条件来触发。它们是心跳——循环中的其他一切都挂在它们上面。

在两个重要工具中的样子：

• Codex。 自动化标签——选择一个项目，设置一个提示，设置一个节奏，选择本地检出或后台工作树。有所发现的运行会落入分类收件箱；没有发现的运行会自动归档。
• Claude Code。 三个可组合成相同形状的原语：/loop 用于会话范围节奏，Desktop计划任务用于重启后存活，Routines用于笔记本关闭后的云端运行。配合hooks用于生命周期事件。

自动化内部区分有效循环和昂贵循环的两个原语：

• 按节奏重新运行。当你想要无论状态如何都进行定期检查时使用。
• 持续运行直到你编写的条件实际为真。一个独立的小模型检查完成情况，所以写代码的智能体不是批改它的人。

自动化

这是制造者-检查者分离应用于停止条件本身。

> /loop 30m /goal All tests in test/auth pass and lint is clean.
  Scan src/auth for new failures, propose fixes in claude/auth-fixes,
  open draft PR when goal condition holds.
▲ Claude CronCreate(*/30 * * * * : auth quality loop)
  Stop condition: tests pass + lint clean (verified by checker)
✓ Scheduled. Will continue past intermediate completions until
  /goal condition is met by independent checker.

06. 工作树：并行但不混乱。

从你运行超过一个智能体的那一刻起，文件就开始碰撞。两个智能体写入同一个文件，就跟两个工程师没商量就提交到同一行一样头疼。

Git工作树解决了这个问题——一个独立的、在各自分支上的工作目录，共享同一个仓库历史，这样一个智能体的编辑在物理上就无法触碰到另一个的检出。

工作树GIF

在两个工具中的体现：

• Codex 正在内置工作树支持——多个线程同时命中同一个仓库而不会互相冲突。
• Claude Code 直接暴露git worktree，一个 --worktree 标志可以在自己的检出中打开会话，并且子智能体上的 isolation: worktree 设置使每个助手获得一个完成后自动清理的全新检出。

工作树消除了机械碰撞，但你仍然是天花板。 你的审查带宽决定了你实际能运行多少个并行智能体——不是工具。

07. 技能：写下项目知识一次。每次运行都读取。

技能是你如何停止像金鱼一样在每个会话中重新解释相同的项目上下文。两个工具使用相同的格式：一个包含SKILL.md的文件夹，持有指令和元数据，加上可选的脚本、参考和资源。

为什么这对循环特别重要：没有技能的循环，每个周期都从零开始重新推导你整个项目的上下文。 有了技能，意图会累积。

约定、构建步骤、"我们因为那次事故不这样做"——在外面写一次，每次运行都读取。

name: ci-triage
description: Classify CI failures by root cause
  (env, flake, real bug, dependency, infra),
  draft fixes for the easy ones, escalate the rest.
  Trigger whenever a workflow run fails or on the morning triage loop.
---
# CI triage skill
## Classification rules
- env: missing secret, wrong env var, infra not provisioned. # human
- flake: passes on retry without code change. # retry once, then file
- bug: deterministic failure tied to recent commit. # draft fix
- dependency: failure tied to a version bump. # draft rollback
- infra: timeout, OOM, runner issue. # escalate
## Fix patterns
- Auth tests → check src/auth/middleware first
- Database tests → verify migration applied in CI env
- E2E tests → check selectors against the latest UI snapshot
## Never do
- Disable failing tests — always file as escalation instead
- Modify CI config without human approval
- Touch src/payments/ or src/billing/ (in claude/permissions.md)
## State Update STATE.md after each run:
  file paths checked, classifications, PRs opened, items escalated.

08. 连接器：循环触及你的真实工具。通过MCP。

一个只能看到文件系统的循环是一个微小的循环。连接器，基于模型上下文协议（MCP），让智能体能够读取你的问题追踪器、查询数据库、访问暂存API、在Slack中发消息。

MCP连接器

Codex和Claude Code都支持MCP，所以你为一个写的连接器通常也能在另一个中工作。

这就是一个智能体说"这是修复方案"和一个循环打开PR、链接Linear工单、并在CI变绿后ping频道之间的区别。

连接器是循环能够在你的真实环境中行动的原因，而不只是告诉你会做什么（如果能的话）。

对循环工作回报最快的连接器，按顺序：

• GitHub——读取仓库、创建分支、打开PR、评论Issue、响应webhook事件。对任何代码循环来说，这是第一天最大的胜利。
• Linear或Jira——随着循环的进展更新工单、将PR链接回Issue、在验证通过时自动关闭项目。
• Slack——发布分类结果、在升级事项上ping人类、在早上总结夜间运行。
• Sentry/你的错误追踪器——让循环调查实时警报并为高频错误起草修复。

09. 子智能体：把制造者和检查者分开。

循环中最有用的结构，毫无疑问，是将写代码的智能体和检查代码的智能体分开。Osmani的表述很精准：写代码的模型"给自己批改作业时太宽容了"。一个指令不同、有时模型也不同的第二个智能体，能抓住第一个智能体说服自己相信的东西。

子智能体

这就是Anthropic 2024年12月工程帖子中的评估器-优化器模式换了个新名字。一个模型生成，另一个批判，重复。2026年病毒式传播的词汇在18个月前就已经被记录下来了。

子智能体在两个工具中的落地方式：

• Codex 只有在你要求时才生成子智能体，同时运行它们，然后将结果折叠成一个答案。你在 .codex/agents/ 中以TOML文件定义自己的智能体——名称、描述、指令、可选的模型和推理强度。你的安全审查者可以是高强度的强模型，而你的探索者可以是某个快速的只读工具。
• Claude Code 用 .claude/agents/ 中的子智能体和智能体团队做同样的事，在它们之间传递工作。通常的分工：一个智能体探索，一个实现，一个根据规格验证。

为什么这在循环内部特别重要： 循环在你不在时运行，所以一个你真正信任的验证器是你能够走开的唯一原因。子智能体消耗更多Token，因为每个都需要做自己的模型和工具工作——把它们花在值得付费获得第二意见的地方。

第三部分 · 要么建对，要么别建

10. 状态文件。智能体会忘记。文件不会。

这是听起来太简单以至于似乎不重要，但实际上是每个有效循环的脊梁的部分。一个Markdown文件、一个Linear看板、一个JSON状态——任何存在于单次对话之外并记录已完成和下一步的东西。

为什么这很重要：智能体默认只有短期记忆。 它们这个会话学到的东西明天就消失了，除非你写下来。

Osmani的规则：智能体会忘记，仓库不会。 没有持久状态的循环每次运行重新开始；有状态的循环可以恢复。

# Loop state · ci-triage
## Last run
2026-06-09 03:30 UTC · 7 failures classified,
  3 fixes drafted, 4 escalated
## In progress
- claude/fix-auth-token-refresh — tests passing locally, awaiting CI
- claude/fix-flaky-payment-webhook — retry pattern applied, monitoring
## Completed today
- claude/bump-axios-1.7.4 → merged (CI green, deps loop verified)
- claude/lint-fix-pass-june-9 → merged
## Escalated to humans
- src/billing/refund.ts — tests failing in 3 ways, root cause unclear
- ci/staging-runner — infra timeouts, not a code issue
## Lessons learned (write here, not in chat)
- 2026-06-08: PowerShell hits TLS 1.2 issue on this Windows runner. Use bash.
- 2026-06-07: tests/e2e/checkout requires Stripe webhook secret in env.
  Skip if missing.
## Stop conditions met since last review
- /goal "all tests pass + lint clean" achieved
  on commit 3a7b8c1 at 02:14 UTC

状态文件存放位置的两种模式：

• 仓库中的Markdown——根目录或 .claude/ 下的 STATE.md。受版本控制。简单。可diff。最适合个人或小团队工作。
• 外部系统（Linear、GitHub Issues、数据库）——跨仓库存活、可查询、支持团队全局可见。最适合生产环境循环，需要多人看到循环在做什么。

对于有偏离目标风险的长期运行循环，将状态文件与一个持续的高层规格文件配对——VISION.md 或 AGENTS.md——智能体每次运行都会重新读取。状态告诉智能体它在哪。规格告诉它要去哪。

11. 最小可行循环。

如果你通过了第2步的四条件测试，在搞任何花哨的东西之前，先构建最小的能工作的循环。四个部分，不需要蜂群。

最小可行循环

四个部分，用大白话说：

1. 一个自动化。 一个按节奏触发并按明确条件停止的定时运行。在Claude Code中使用 /loop，在Codex中使用自动化。当你想让它运行到明确条件成立时，配合 /goal 使用。
2. 一个技能。 一个单独的 SKILL.md，存储智能体每次运行原本会从零推导的项目上下文。
3. 一个状态文件。 一个Markdown文件或Linear看板，记录已完成和下一步。明天的运行会恢复而不是重启。
4. 一个关卡。 自动判定不良工作的测试、类型检查或构建。这是决定循环是帮忙还是只是花钱的部分。

顺序很重要： 先把一次手动运行搞可靠。把它变成技能。把它包在循环里。然后设置定时。跳步是循环在生产中失败的方式。

有意义的指标是每次接受变更的成本——不是消耗的Token，不是尝试的任务，不是排定的循环。如果你的接受变更率低于50%，你就是在做循环本该替你省下的审查工作，循环正在亏损。

12. Ralph Wiggum循环。悄悄失败的循环。

工程师Geoffrey Huntley记录并命名了这个失败模式。一个本应仅在完成时发出完成Token的智能体提前发出了它，循环在半成品上退出。没有硬关卡，循环悄悄失败并持续花钱。

Ralph Wiggum循环

Ralph Wiggum循环发生在以下情况：

• 没有真正的验证器。 只是第二个智能体被要求"审查"，没有客观信号。两个乐观主义者在互相认同。
• 软性完成条件。 "完成"由智能体的判断定义，而不是测试、构建或类型检查。
• 没有硬性停止。 循环一直持续到有外部力量杀死它（速率限制、你注意到），而不是直到成功被验证。

修复方案就是第11步中的关卡——能够判定工作失败的客观东西。 一个通过或失败的测试。一个编译或不编译的构建。一个返回零或非零的检查工具。不是一个有意见的验证器。

其他值得了解的测量失败模式：

• 长会话中的目标漂移。 每个摘要步骤都是有损的；"不要做X"的约束在第47轮会消失。缓解措施：每次运行重新读取 VISION.md 或 AGENTS.md。
• 自我偏好偏差。 写代码的智能体给自己批改作业时太宽容。缓解措施：一个独立于制造者推理的独立验证器子智能体。
• 智能体懒惰。 循环在部分完成时宣布"够好了"。缓解措施：/goal 搭配由新模型检查的客观停止条件。

13. 理解债务与认知投降。

这是一个随着循环变好而变得更加尖锐的失败模式——不是变差。来自Osmani文章的两个命名风险：

• 理解债务。 循环越快产出你没写过的代码，仓库里包含的内容与你理解的内容之间的距离就越大。真正疼的账单不是Token账单。是有一天你必须调试一个团队里没人读过的系统。
• 认知投降。 停止形成判断、接受循环返回的任何结果的拉力。当你有判断力地设计循环时，它是解药；当你用它来逃避思考时，它是加速剂。同一个行动，相反的结果。

缓解措施并非技术性的：