大多数开发者仍然在用手动方式给编码智能体写提示。他们打字、等待、读 diff、再打字。10 个开发者里有 9 个从没写过一个能替自己去给智能体下达提示的循环。
没有自动化，没有状态文件，没有校验器，没有调度。杠杆点已经转移了——从敲提示词转向设计会去敲提示词的系统。这就是从提示者到循环设计师的 14 步路线图。
关注我的 Linkedin 获取新鲜的 AI alpha：linkedin.com/in/lev-deviatkin
这是完成这一转变的 14 步路线图——素材取自 Anthropic 的工程文档、Addy Osmani 关于循环工程的长文，以及近期的若干测量研究。
三个层级：先弄清楚你到底需不需要一个循环，再学会五个基本构件，最后搭出那个最小、可用、又不会反噬你的循环。
14 步。3 个层级。停止提示。开始设计。
第 1 部分 · 为什么，以及那道测试
01. 循环工程正在把作为提示者的你替换掉。
过去两年里，你从编码智能体那里拿到东西的方式是：写一个提示、提供上下文、读它返回的内容、再写下一个提示。智能体是一件工具，而你自始至终握着它。这个阶段正在结束。
循环工程是搭建一个小系统，它找出工作、把工作交给智能体、检查结果、记录发生了什么、然后决定下一步——全部自主完成。你只设计这个系统一次，从此之后，由这个系统去给智能体下达提示。
Addy Osmani 把它拆成六个部分：
Anthropic 的工程师如今每天合入的代码量是 2024 年的八倍——这个数字连 Anthropic 自己都称之为“几乎可以肯定夸大了真实的生产力增益”。
这个数字有争议。但其中的机制没有争议：杠杆点已经从敲提示词转移到设计那个去敲提示词的循环。
02. 在动手搭建之前先跑一遍 4 条件测试。
循环要在四个条件下才对得起它的成本。缺一条，循环的代价就会超过它的回报。这是 AlphaSignal 分析里诚实的那部分，也是大多数 X 长帖会跳过的部分：
用大白话说，这四个条件是：
- 任务会重复。 循环把它的搭建成本摊销到很多次运行上。对于一次性的活儿，一个好提示更快也更便宜。如果这工作不会每周都来一次，你拥有的就不是循环——而是一段你只跑过一次的脚本。
- 校验是自动化的。 循环需要某种东西，在你不在场时也能让这份工作“判不及格”。一套测试、一个类型检查器、一个 linter、一次构建。没有自动化检查，你就又回到椅子上逐个 diff 地读——而那恰恰是循环本应替你免掉的活儿。
- 你的 token 预算能吸收浪费。 循环会反复重读上下文、重试、探索。不管这一轮有没有产出可交付的东西，它都在烧 token。这项技术随预算而扩展，这也是为什么它对那些 token 近乎免费的人来说显而易见，对按量计费的人来说则像是鲁莽之举。
- 智能体拥有一名资深工程师的工具。 日志、一个可复现的环境、运行它自己写的代码并看哪里崩了的能力。没有这些，循环就是在盲目地迭代。
03. 谁赢，谁输。循环偏向那些花得起钱的人。
这套经济账并非放之四海皆准。那些把循环工程说成理所当然的人，往往用着不计量的 token。
而那些觉得它鲁莽的人，通常是在 20 美元的消费级套餐上，试图跑重型校验循环，又不想撞上限额或收到一张意外账单。
实践中真正受益的人：
- 既有可被机器检查的重复性工作、又有预算去跑的团队——持续的测试分诊、依赖升级、lint 修复轮次、在测试覆盖率强的代码库上把 issue 草拟成 PR。
- 已有强测试套件的代码库。 如果一名初级工程师能照着清单完成这个任务、而一套测试又能抓住他的错误，那么循环就合适。
- 已经在用多智能体模式的 async-first 团队。 对这些团队来说，例程（routines）正是缺失的编排层。
今天就该跳过它的人：
- 用消费级套餐的单兵开发者——token 账单会比生产力增益先到。
- 任何在没有自动化校验的代码上工作的人。 一个没有真实检查的循环，就是智能体在反复地自我附和。
- 真正瓶颈在于评审能力而非打字速度的团队。 循环会生成更多代码；如果评审本就是瓶颈，它只会让队列更长。
对于一次性任务、探索性工作、或任何“算不算完成”要靠判断的活儿，一个瞄得准的提示仍然取胜。这篇文章诚实的版本是：循环工程是真实存在的，但大多数开发者还用不上它。
04. 30 秒循环自检。
第 2 步的 4 条件测试是战略层面的决策。这一条是战术层面的——在把某个具体任务变成循环之前，你对它跑的检查清单。
漏掉任意一项，就把它继续当作手动提示。
- 1. 这个任务至少每周发生一次。 低于每周一次 → 搭建成本永远摊销不回来。
- 2. 一个测试、类型检查、构建或 linter 能否决坏输出。 没有自动化关卡 → 智能体在给自己的作业打分。
- 3. 智能体能运行它改动的代码。 没有可复现环境 → 迭代是盲目的。
- 4. 循环有硬性停止条件。 token 预算、迭代次数或时间上限。没有它，循环会一直跑到有人注意到那张账单为止。
- 5. 在合并、部署或依赖变更之前有人类评审。 任何不可逆的操作，行动之前都需要一道人类审批关卡。
好的首个循环：
- CI 失败分诊——每晚一次，扫描失败、分类成因、为简单的那些草拟修复 PR。
- 依赖升级 PR——每周一次，扫描更新、测试兼容性、开 PR。
- lint 修复轮次——在每次 PR 打开事件上，自动应用风格修复。
- 不稳定测试复现——循环运行，直到某个假设能扛过测试。
- issue 转 PR 草稿，发生在测试强的代码上，坏输出会被测试套件否决。
糟糕的首个循环——这些需要人坐在椅子上：
- 架构重写
- 认证或支付代码
- 生产部署
- 含糊的产品工作
- 任何“算不算完成”要靠判断的活儿
第 2 部分 · 5 个基本构件
05. 自动化：心跳。
自动化是让一个循环成为真正的循环、而不只是一次你跑过一回的运行的东西。它们按计划、按事件、或按某个触发条件被点燃。它们是心跳——循环里其余的一切都挂在它们身上。
在两个要紧的工具里，它长这样：
-
Codex。 Automations 标签页——选一个项目、设一个提示、设一个节奏、选本地 checkout 或后台 worktree。有所发现的运行会落进一个 Triage 收件箱；一无所获的运行会自我归档。
-
Claude Code。 三个能组合成同一形态的原语：
/loop 用于会话级节奏，桌面端定时任务用于熬过重启，Routines 用于合盖跑（笔记本关机也能跑）的云端运行。再配上 hooks 来处理生命周期事件。
自动化内部有两个原语，把可用的循环和昂贵的循环区分开：
- /loop 按节奏重跑。当你想要不论状态如何都定期检查时用它。
- /goal 会一直跑，直到你写下的某个条件真正成立。一个独立的小模型来检查是否完成，于是写代码的那个智能体不会同时是给它打分的那个。
这就是把“生产者 vs 校验者”这一拆分应用到停止条件本身。
> /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. Worktree：并行而不混乱。
你一旦跑超过一个智能体，文件就开始打架。两个智能体写同一个文件，跟两个工程师不打招呼就往同样的行里提交，是一样的头疼。
一个 git worktree 能解决它——一个在自己分支上、共享同一仓库历史的独立工作目录，于是一个智能体的编辑根本碰不到另一个的 checkout。
它在两个工具里如何呈现：
- Codex 内建了 worktree 支持——好几个线程同时打到同一个仓库，彼此不会撞上。
- Claude Code 直接暴露了 git worktree、一个让会话在自己 checkout 里打开的 —worktree 标志、以及子智能体上的 isolation: worktree 设置，让每个助手拿到一个用完会自我清理的全新 checkout。
Worktree 拿掉了机械层面的碰撞，但你仍然是天花板。 你的评审带宽决定了你实际能跑多少个并行智能体——而不是工具。
07. 技能：把项目知识写一次。每次运行都读。
技能（Skill）是你不再像金鱼一样每个会话都把同样的项目上下文重新解释一遍的方式。两个工具用同一种格式：一个文件夹，里面放一个 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。
一个只能看到文件系统的循环是个很小的循环。连接器建立在 Model Context Protocol（MCP）之上，让智能体读你的 issue 跟踪器、查一个数据库、打一个 staging API、往 Slack 里丢一条消息。
Codex 和 Claude Code 都讲 MCP，所以你为其中一个写的连接器，通常在另一个里直接就能用。
这就是“说出‘修复在这里’的智能体”和“打开 PR、关联 Linear 工单、并在 CI 变绿后在频道里 @ 一声的循环”之间的差别。
连接器正是循环之所以能在你真实环境里动手、而不只是告诉你它若能动手会做什么的原因。
为循环工作回本最快的连接器，按顺序：
- GitHub——读仓库、建分支、开 PR、在 issue 上评论、对 webhook 事件作出反应。任何代码循环上手第一天最大的收益。
- Linear 或 Jira——随循环推进更新工单、把 PR 关联回 issue、在校验通过时自动关闭条目。
- Slack——发布分诊结果、在升级时 @ 人类、早上把整夜的运行汇总成摘要。
- Sentry / 你的错误跟踪器——让循环调查实时告警、为高频的那些草拟修复。
09. 子智能体：让生产者远离校验者。
在一个循环里，到目前为止最有用的结构性做法，是把写代码的智能体和检查代码的智能体拆开。
Osmani 的说法很精准：写了这段代码的模型“给自己的作业打分时心太软了”。一个带着不同指令、有时是不同模型的第二个智能体，能抓住第一个智能体自我说服后放过的东西。
这就是 Anthropic 2024 年 12 月那篇工程博文里的评估器-优化器模式，换了个新名字。一个模型生成，另一个批评，循环往复。2026 年开始病毒式传播的那套词汇，十八个月前就被记录下来了。
子智能体在两个工具里如何落地：
-
Codex 只在你要求时才派生子智能体，让它们同时运行，再把结果折叠回一个答案。你把自己的智能体定义为 .codex/agents/ 里的 TOML 文件——名称、描述、指令，可选的模型与推理强度。
你的安全评审员可以是一个开到高强度的强模型，而你的探索者是某个只读的快家伙。
-
Claude Code 用 .claude/agents/ 里的子智能体、以及在彼此之间传递工作的 agent 团队做同样的事。
常见的分工：一个智能体探索，一个实现，一个对照规格校验。
它在循环里之所以格外要紧的原因： 循环在你不盯着的时候运行，所以一个你真的信得过的校验器，是你能放手走开的唯一理由。
子智能体会烧更多 token，因为每一个都做自己的模型与工具工作——把它们花在“第二意见值得付费”的地方。
第 3 部分 · 要么把它搭对，要么别搭
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 步的 4 条件测试，那就在搞任何花哨东西之前，先搭出那个最小、可用的循环。四个部件，不要群集。
用大白话说，这四个部件是：
- 一个自动化。 一个按节奏点燃、并在一个清晰条件上停止的计划运行。在 Claude Code 里用 /loop，或在 Codex 里用一个 automation。当你想让它一直跑到某个声明的条件成立时，配上 /goal。
- 一个技能。 一个 SKILL.md，存储那些智能体本来每次运行都要从零重新推导的项目上下文。
- 一个状态文件。 一个 markdown 文件或一块 Linear 看板，记录哪些已完成、哪些是下一步。明天的运行是续上，而不是重启。
- 一道关卡。 那个自动让坏工作不及格的测试、类型检查或构建。正是这一部分，决定了循环是帮了忙还是只在花钱。
顺序很重要： 先把一次手动运行做可靠。把它变成一个技能。用一个循环把它裹起来。然后再调度它。跳着来，正是循环在生产中失败的方式。
要紧的指标是每个被接受改动的成本——不是花掉的 token，不是尝试的任务数，不是调度的循环数。如果你的被接受改动率低于 50%，你就在做循环本应替你免掉的评审工作，而这个循环正在亏钱。
12. Ralph Wiggum 循环。悄无声息地失败的循环。
工程师 Geoffrey Huntley 记录并命名了这种失败模式。一个本应只在完成时才发出完成 token 的智能体提早发了它，于是循环在一份半成品上退出。没有硬关卡，循环会悄无声息地失败，并继续花钱。
Ralph Wiggum 循环就是下面这些情形发生时的产物：
- 没有真正的校验器。 只是叫第二个智能体去“评审”，没有客观信号。两个乐观主义者互相附和。
- 软性完成条件。 “完成”由智能体的判断定义，而不是由一个测试、构建或类型检查定义。
- 没有硬性停止。 循环一直继续，直到某个外部东西把它杀掉（限额、你注意到了），而不是直到成功被校验。
修复办法就是第 11 步的那道关卡——某个能让工作不及格的客观东西。一个通过或失败的测试。一次能编译或不能编译的构建。一个返回零或非零的 linter。不是一个“有意见”的校验器。
其他值得知道的、有实测的失败模式：
- 长会话中的目标漂移。 每一次摘要步骤都是有损的；“不要做 X”这类约束在第 47 回合消失了。缓解：一份每次运行都重读的常驻 VISION.md 或 AGENTS.md。
- 自我偏好偏差。 写了这段代码的智能体给自己的作业打分时心太软。缓解：一个独立的校验器子智能体，完全不接触生产者的推理过程。
- 智能体式偷懒。 循环在部分完成时就宣布“够好了”。缓解：用 /goal，配一个由全新模型检查的客观停止条件。
13. 理解债与认知投降。
这种失败模式随着循环变好、而不是变坏，反而越发尖锐。两个有名的风险，都出自 Osmani 的文章：
- 理解债（comprehension debt）。 循环越快地交付你没写过的代码，仓库里有什么和你理解什么之间的距离就越大。真正让你疼的账单不是 token 账单。而是你不得不去 debug 一个团队里没人读过的系统的那一天。
- 认知投降（cognitive surrender）。 那股停止形成自己观点、直接接受循环返回任何东西的拉力。设计循环——当你带着判断去做时是解药，当你为了逃避思考去做时则是加速剂。同一个动作，相反的结果。
缓解办法并非技术性的：
- 读 diff。 如果你不读循环交付的东西，你就是在以复利借入理解债。
- 抽查那道关卡。 挑几个循环开的 PR，核实那个批准它们的测试是否真的抓得住你在意的失败模式。关卡会腐烂。
- 禁止循环碰架构工作。 让它待在小的、可被机器检查的改动上。你一旦让它碰判断性的活儿，理解债就会加速。
- 结对设计循环。 设计循环时多一双眼睛，能抓住那些循环否则会永远利用下去的盲点。
14. 安全税。一个无人看管的循环也是一片无人看管的攻击面。
一个无人看管运行的循环，同时也是一片无人看管运行的攻击面。
你的循环必须防御的威胁模型：
- 生成的代码未经评审就交付。 循环开 PR 的速度比人类读得过来还快。没有一道包含安全检查（SAST、依赖审计、密钥扫描）的关卡，不安全的代码会自动合并。
- 技能作为注入向量。 一个会自动安装技能的循环，会继承藏在那些技能描述里的每一处提示注入。安装前先审计技能来源。
- 日志里的凭据。 长跑循环期间的调试日志会把密钥散落到你不监控的日志里。在生产循环里关闭冗长日志；对确实会被记录的内容做脱敏。
- 权限范围蔓延。 一个以只读权限测试过的循环，为了图方便被加了“就这一个”写权限，然后再也没被重新审计。每 30 天重新审计一次权限。
§ 那些把循环变成钱坑的错误
- 没跑 4 条件测试就搭循环。 第 2 步的存在是有原因的。大多数开发者至少不满足其中一个条件。
- 没有客观关卡。 一个被叫去“评审”、却没有测试、类型检查或构建的第二个智能体，只是第二个乐观主义者。
- 同一个智能体既写又验。 自我偏好偏差。生产者给自己的作业打分，永远是“A+”。
- 没有状态文件。 明天的运行从零重启，而不是续上。
- 含糊的停止条件。 “看起来不错就算完成”从来站不住。用一个测试、一次类型通过、或一次通过的构建。
- 没有 token 预算上限。 循环会重读上下文并重试。没有上限，雄心勃勃的循环会烧掉你预期 5-10 倍的 token。
- 在消费级套餐上跑重型校验的循环。 token 账单或限额，总有一个会逮到你。
- 自动安装社区技能。 在被审计的 17,022 个技能里，有 520 个会泄露凭据。安装前读源码。
- 在判断性工作上用循环。 架构、认证、支付、含糊的产品决策。让循环待在 lint 修复上，别碰策略。
- 不读 diff。 复利计息的理解债。你去 debug 一个没人读过的系统的那一天，代价比 token 从来都大。
结论：
杠杆移动了。你的工作也是。
过去两年，与编码智能体协作的杠杆在提示这一层。更好的提示、更好的上下文、更好的一次成型输出。
那个阶段正在结束。 智能体变得足够好，于是下一个杠杆点上移了一层：那个决定它们做什么、何时做、用什么关卡、以及哪些状态在多次运行之间存活的系统。
但这个故事诚实的版本，不是说每个人都该冲去搭循环。大多数开发者还用不上一个——直到任务会重复、校验是自动化的、预算能吸收浪费、并且智能体拥有资深工程师的工具为止。
缺一个条件，循环的代价就会超过它的回报。
如果你通过了测试，就搭小的。一个自动化。一个技能。一个状态文件。一道关卡。 把一次手动运行做可靠。把它变成一个技能。用一个循环把它裹起来。然后再调度它。顺序很重要。跳着来，你就是在为一个没人理解的系统付费。
Cherny 的观点不是说工作变容易了。而是说杠杆点移动了。 搭好循环。继续做那个工程师。