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

大多数开发者仍在手动提示他们的编程智能体。他们输入、等待、阅读差异（diff）、再输入。十分之九的开发者从未写过哪怕一个代替他们提示智能体的循环。

没有自动化，没有状态文件，没有验证器，没有计划。杠杆点已经移动——从输入提示词，到设计提示智能体的系统。这是从提示者到循环设计者的 14 步路线图。

关注我的 Linkedin 获取最新 AI 资讯：linkedin.com/in/lev-deviatkin

本路线图来源于 Anthropic 的工程文档、Addy Osmani 关于 Loop 工程的长文，以及近期的测量研究。

三个层级：弄清楚你是否真的需要一个循环，学习五大构建块，然后构建最小可用的循环而不伤害自己。

14 步。3 个层级。停止提示，开始设计。

第一部分 · 为什么，以及测试

01. Loop 工程是用自己来替代提示者的过程。

在过去两年里，从编程智能体获取输出的方式是：写一个提示词，分享上下文，读取返回内容，写下一个提示词。智能体是工具，你始终握着它。这个阶段正在结束。

Loop 工程是构建一个小系统，让它自行找到工作、交给智能体、检查结果、记录发生的事情，并决定下一步行动。你设计那个系统一次，系统从此负责提示智能体。

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

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

这个数字有争议，但机制没有争议：杠杆点从输入提示词转移到了设计提示的循环。

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

循环在四个条件下才物有所值。缺少一条，循环的成本就会超过回报。这是来自 AlphaSignal 分析的诚实看法，也是大多数 X 帖子跳过的部分：

用简单语言表达的四个条件：

任务会重复。 循环通过多次运行来摊销其设置成本。对于一次性工作，一个好的提示词更快更便宜。如果工作不是每周都有，你没有循环——你有一个只运行了一次的脚本。
验证是自动化的。 循环需要某种能在没有你在场的情况下判断工作是否失败的东西。测试套件、类型检查器、代码检查器、构建工具。没有自动化检查，意味着你又回到了椅子上阅读每一个差异——这正是循环本应消除的工作。
你的 Token 预算能吸收浪费。 循环会重读上下文、重试、探索。无论运行是否交付了任何东西，这都会消耗 Token。这种技术随预算扩展，这就是为什么对于 Token 实际上免费的人来说它显而易见，而对于按量计费的人来说则是鲁莽的。
智能体拥有高级工程师的工具。 日志、可复现环境、运行它写的代码并查看哪里出错的能力。没有这些，循环就是在盲目迭代。

03. 谁赢谁输。循环有利于能花钱的人。

经济学不是普适的。称 Loop 工程显而易见的人，往往拥有不限量的 Token。

对他们来说鲁莽的人，通常是在 20 美元消费者套餐上，试图运行繁重的验证循环而不触发限额或意外账单的人。

实践中谁真正受益：

有重复性、可机器检查的工作和运行预算的团队——持续测试分类、依赖升级、lint 修复、在有强测试覆盖的代码库上将问题转为 PR 草稿。
有强大现有测试套件的代码库。 如果初级工程师可以从清单和测试套件完成任务，且测试套件能捕捉他们的错误，那么循环就适合。
已经使用多智能体模式的异步优先团队。 对于这些团队，例行任务是缺失的编排层。

今天应该跳过的人：

使用消费者套餐的独立开发者——Token 账单在生产力提升到来之前就到了。
任何在没有自动化验证的代码上工作的人。 没有真正检查的循环，只是智能体在重复地自我赞同。
真正瓶颈在审查能力而非输入速度的团队。 循环生成更多代码；如果审查已经是瓶颈，它只会让队列更长。

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

04. 30 秒循环检查。

第 2 步的 4 条件测试是战略决策。这是战术决策——在将特定任务变成循环之前运行的清单。

缺少任何一项，就保持为手动提示。

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

好的首个循环：

CI 失败分类——每晚，扫描失败，分类原因，为简单的问题起草修复 PR。
依赖升级 PR——每周，扫描更新，测试兼容性，开 PR。
Lint 修复——在每次 PR 打开事件上，自动应用风格修复。
不稳定测试复现——循环直到理论通过测试。
在有强测试的代码上将问题转为 PR 草稿，不良输出会被测试套件拒绝。

不好的首个循环——这些需要人在场：

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

第二部分 · 5 大构建块

05. 自动化任务：心跳。

自动化任务是让循环成为真正循环而非只运行一次的东西。它们按计划、按事件或按触发条件触发。它们是心跳——循环中的其他一切都依附于它们。

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

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

将有效循环与昂贵循环区分开来的两个自动化内部原语：

/loop 按节奏重复运行。当你想要定期检查而不管状态时使用。
/goal 持续运行直到你写的条件真正成立。一个独立的小模型检查完成情况，所以写代码的智能体不是给它评分的那个。

这是创作者与检查者分离被应用到停止条件本身的做法。

> /loop 30m /goal 所有 test/auth 中的测试通过且 lint 干净。
  扫描 src/auth 中的新失败，在 claude/auth-fixes 中提出修复，
  当目标条件成立时开 PR 草稿。

▲ Claude
  CronCreate(*/30 * * * * : auth quality loop)
  停止条件：测试通过 + lint 干净（由检查器验证）
✓ 已调度。将在中间完成状态后继续
  直到 /goal 条件被独立检查器满足。

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

你一运行多个智能体，文件就开始冲突。两个智能体写同一个文件，和两个工程师提交到同一行代码而不事先沟通，是完全一样的头疼事。

git 工作树解决了这个问题——一个独立的工作目录，在自己的分支上，共享同一个仓库历史，所以一个智能体的编辑从物理上就不可能碰到另一个智能体的检出。

在两个工具中的样子：

Codex 内置工作树支持——多个线程可以同时操作同一个仓库而不互相碰撞。
Claude Code 直接暴露 git worktree，一个 --worktree 标志用于在自己的检出中打开会话，以及一个 isolation: worktree 设置放在子智能体上，让每个助手获得一个运行后自动清理的新检出。

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

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

技能是让你不再像金鱼一样每次会话都重新解释同样的项目上下文的方法。两个工具使用相同的格式：一个包含 SKILL.md 的文件夹，里面有指令和元数据，加上可选的脚本、参考资料和资产。

这对循环特别重要的原因：没有技能的循环每个周期都要从零重新推导你的整个项目上下文。有了技能，意图会复利增长。

惯例、构建步骤、"我们不这样做是因为那次事故"——只写一次放在外部，每次运行都读取。

name: ci-triage
description: 按根本原因（环境、不稳定、真实 bug、
  依赖、基础设施）分类 CI 失败，为简单的问题起草修复，
  其余的上报。在工作流运行失败或早晨分类循环时触发。
---

# CI 分类技能

## 分类规则
- env: 缺少密钥、错误环境变量、基础设施未配置。# 人工处理
- flake: 不修改代码重试后通过。# 重试一次，然后归档
- bug: 与最近提交相关的确定性失败。# 起草修复
- dependency: 与版本升级相关的失败。# 起草回滚
- infra: 超时、内存溢出、运行器问题。# 上报

## 修复模式
- 认证测试 → 先检查 src/auth/middleware
- 数据库测试 → 验证迁移在 CI 环境中已应用
- E2E 测试 → 对照最新 UI 快照检查选择器

## 禁止操作
- 禁用失败测试——始终作为上报归档
- 未经人工批准不修改 CI 配置
- 不触碰 src/payments/ 或 src/billing/（见 claude/permissions.md）

## 状态
每次运行后更新 STATE.md：检查的文件路径、分类结果、
已开的 PR、已上报的事项。

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

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

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

这就是"这里有个修复方案"的智能体与"自动开 PR、链接 Linear 工单、CI 变绿后 ping 频道"的循环之间的区别。

连接器让循环能在你的真实环境中行动，而不只是告诉你如果它能行动它会做什么。

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

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

09. 子智能体：让创作者远离检查者。

循环中最有用的结构性设计，毫无疑问，是把写代码的智能体和检查代码的智能体分开。Osmani 的描述很精准：写代码的模型"在给自己的作业打分时太好说话了"。一个有不同指令、有时使用不同模型的第二个智能体，能捕捉到第一个智能体说服自己忽略的问题。

这是 Anthropic 2024 年 12 月工程文章中**评估器-优化器模式（evaluator-optimizer pattern）**在新名称下的体现。一个模型生成，另一个批评，如此循环。2026 年病毒式传播的词汇，在十八个月前就已记录在案。

子智能体在两个工具中的实现：

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

它在循环内部尤其重要的原因： 循环在你不看的时候运行，所以一个你真正信任的验证器是你能放手离开的唯一理由。子智能体确实会消耗更多 Token，因为每个都做自己的模型和工具工作——把它们花在值得第二意见的地方。

第三部分 · 正确构建，或者不要构建

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

这是那个听起来太简单、似乎无关紧要，却实际上是每个有效循环脊梁的组件。一个 Markdown 文件、一个 Linear 看板、一个 JSON 状态——任何存在于单次对话之外、记录已完成和待完成事项的东西。

为什么这很重要：智能体默认记忆很短。它们本次会话学到的内容，明天就消失了，除非你把它写下来。

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

# 循环状态 · ci-triage

## 上次运行
2026-06-09 03:30 UTC · 7 个失败已分类，3 个修复已起草，4 个已上报

## 进行中
- claude/fix-auth-token-refresh — 本地测试通过，等待 CI
- claude/fix-flaky-payment-webhook — 已应用重试模式，监控中

## 今日已完成
- claude/bump-axios-1.7.4 → 已合并（CI 通过，依赖循环已验证）
- claude/lint-fix-pass-june-9 → 已合并

## 已上报给人类
- src/billing/refund.ts — 测试以 3 种方式失败，根本原因不明
- ci/staging-runner — 基础设施超时，不是代码问题

## 学到的经验（写在这里，不要写在聊天里）
- 2026-06-08: PowerShell 在这个 Windows 运行器上遇到 TLS 1.2 问题，使用 bash。
- 2026-06-07: tests/e2e/checkout 需要环境中的 Stripe webhook 密钥，缺失则跳过。

## 上次审查以来满足的停止条件
- /goal "所有测试通过 + lint 干净" 在 02:14 UTC 的提交 3a7b8c1 上达成

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

仓库中的 Markdown——STATE.md 放在根目录或 .claude/ 内。受版本控制，简单，差异可读。最适合个人或小团队工作。
外部系统（Linear、GitHub Issues、数据库）——跨仓库存活，可查询，支持团队级可见性。最适合多人需要查看循环状态的生产循环。

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

11. 最小可行循环。

如果你通过了第 2 步的 4 条件测试，在做任何花哨的事情之前，先构建能运行的最小循环。四个部分，没有集群。

用简单语言表达的四个部分：

一个自动化任务。 按节奏触发、在明确条件下停止的计划运行。在 Claude Code 中使用 /loop，或在 Codex 中使用自动化任务。当你希望它运行直到某个声明的条件成立时，配合 /goal 使用。
一个技能。 单个 SKILL.md，存储智能体否则每次运行都要从零重新推导的项目上下文。
一个状态文件。 记录已完成和待完成事项的 Markdown 文件或 Linear 看板。明天的运行恢复而不是重新开始。
一个门控。 自动判断工作是否失败的测试、类型检查或构建工具。这是决定循环是帮助还是只是消费的部分。

顺序很重要： 先让一次手动运行可靠。将其变成技能。包装成循环。然后调度它。跳过这个顺序是循环在生产中失败的方式。

重要的指标是每个被接受变更的成本——不是花费的 Token，不是尝试的任务，不是调度的循环。如果你的被接受变更率低于 50%，你在做循环本应为你节省的审查工作，循环在亏损。

12. Ralph Wiggum 循环：静默失败的循环。

工程师 Geoffrey Huntley 记录了这种失败模式并为其命名。一个本应只在完成时发出完成令牌的智能体过早发出了它，循环在工作只完成一半时退出。没有硬性门控，循环会静默失败并持续消费。

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

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

修复方法是第 11 步的门控——某个能使工作失败的客观东西。通过或失败的测试，编译或不编译的构建，返回零或非零的代码检查器。不是一个有意见的验证器。

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

长会话中的目标漂移。 每个摘要步骤都有损耗；"不要做 X"的约束在第 47 轮消失。缓解：每次运行都重新读取的常设 VISION.md 或 AGENTS.md。
自我偏好偏见。 写代码的智能体在给自己的作业打分时太好说话了。缓解：一个没有接触过创作者推理的独立验证器子智能体。
智能体懒惰。 循环在部分完成时声明"足够好了"。缓解：由新鲜模型检查的带客观停止条件的 /goal。

13. 理解债与认知投降。

这是随着循环变好而变得更尖锐、而不是更容易的失败模式。两个命名风险，都来自 Osmani 的文章：

理解债（Comprehension debt）。 循环交付你没有写的代码越快，仓库包含的内容与你理解的内容之间的距离就越大。最痛苦的不是 Token 账单，而是你不得不调试一个团队中没有人读过的系统的那一天。
认知投降（Cognitive surrender）。 停止形成意见、接受循环返回的任何内容的冲动。有判断地设计循环是解药，用它来逃避思考是加速剂。同样的行动，截然相反的结果。

缓解措施不是技术性的：

读差异。 如果你不阅读循环交付的内容，你是在以复利利率租用理解债。
抽查门控。 挑选几个循环开的 PR，验证批准它们的测试实际上能捕捉你关心的失败模式。门控会腐烂。
阻止循环进行架构工作。 让它处理小的、可机器检查的变更。一旦你让它触碰判断决定，理解债就会加速。
与队友共同设计循环。 设计循环时的第二双眼睛，能捕捉循环否则会永远利用的盲点。

14. 安全税：无人值守的循环是无人值守的攻击面。

无人值守运行的循环，同时也是无人值守运行的攻击面。

你的循环必须防御的威胁模型：

未经审查就交付的生成代码。 循环开 PR 的速度比人类阅读的速度快。没有包含安全检查（SAST、依赖审计、密钥扫描）的门控，不安全的代码会自动合并。
技能作为注入向量。 自动安装技能的循环会继承其描述中隐藏的所有提示词注入。安装前审计技能来源。
日志中的凭据。 长时间运行循环中的调试日志会将密钥散布在你不监控的日志中。在生产循环中禁用详细日志；对确实记录的内容进行脱敏处理。
权限范围蔓延。 以只读权限测试的循环为了方便被添加了"只是一个"写权限，然后再也没有重新审计。每 30 天重新审计一次权限。

§ 将循环变成钱坑的错误

不做 4 条件测试就构建循环。 第 2 步的存在是有原因的。大多数开发者至少有一个条件不满足。
没有客观门控。 被要求"审查"的第二个智能体，没有测试、类型检查或构建，只是第二个乐观主义者。
一个智能体既写又验证。 自我偏好偏见。创作者给自己的作业打分，结果总是"A+"。
没有状态文件。 明天的运行从零重新开始而不是恢复。
模糊的停止条件。 "看起来不错时完成"永远不成立。使用测试、类型通过或构建通过。
没有 Token 预算上限。 循环会重读上下文并重试。没有上限，雄心勃勃的循环会消耗你预期的 5-10 倍 Token。
在有繁重验证的消费者套餐上运行循环。 Token 账单或速率限制，总有一个会找上你。
自动安装社区技能。 17,022 个审计过的技能中有 520 个会泄露凭据。安装前阅读源代码。
在判断决定工作上使用循环。 架构、认证、支付、模糊的产品决策。让循环处理 lint 修复，而不是战略。
不读差异。 以复利利率累积的理解债。你不得不调试没有人读过的系统的那一天，成本比 Token 贵多了。

结论：

杠杆点移动了。你的工作也是。

在过去两年里，与编程智能体合作的杠杆在提示词上。更好的提示词、更好的上下文、更好的单次输出。

这个阶段正在结束。 智能体已经足够好，下一个杠杆点在更高一层：决定它们工作什么、何时工作、使用什么门控，以及什么状态在运行之间存活的系统。

但这个故事的诚实版本不是每个人都应该赶快构建循环。大多数开发者还不需要——不是在任务重复、验证自动化、预算能吸收浪费、智能体有高级工程师工具之前。

缺少一个条件，循环的成本就会超过回报。

如果你通过了测试，就小规模构建。一个自动化任务。一个技能。一个状态文件。一个门控。 让一次手动运行可靠。将其变成技能。包装成循环。然后调度它。顺序很重要，跳过就是在为没有人理解的系统付费。

Cherny 的观点不是说工作变容易了，而是说杠杆点移动了。构建循环，保持工程师身份。