# Loop engineering: the 14-step roadmap from prompter to loop designer.
**作者**: Codez
**日期**: 2026-06-09T15:50:43.000Z
**来源**: [https://x.com/0xCodez/status/2064374643729773029](https://x.com/0xCodez/status/2064374643729773029)
---
Most developers still prompt their coding agents by hand. They type, they wait, they read the diff, they type again. 9out of 10 builders have never written a single loop that prompts the agent for them.
No automation, no state file, no verifier, no schedule. The leverage point has moved - from typing prompts to designing systems that prompt. This is the 14-step roadmap from prompter to loop designer.
> Follow my Linkedin to get fresh AI alpha: linkedin.com/in/lev-deviatkin
This is the 14-step roadmap to make that shift - sourced from Anthropic’s engineering docs, Addy Osmani’s long-form on loop engineering, and recent measurement studies.
Three tiers: figure out if you actually need a loop, learn the five building blocks, then build the smallest one that works without hurting you.
14 steps. 3 tiers. Stop prompting. Start designing.
PART 1 · The Why & The Test
## 01. Loop engineering is replacing yourself as the prompter.
For two years, the way you got something out of a coding agent was: write a prompt, share the context, read what came back, write the next prompt. The agent was a tool and you held it the entire time. That part is ending.
Loop engineering is building a small system that finds the work, hands it to the agent, checks the result, records what happened, and decides the next move - on its own. You design that system once. The system prompts the agent from then on.
Addy Osmani breaks it into six parts:
Anthropic engineers now merge eight times as much code per day as they did in 2024 - a figure Anthropic itself calls “almost certainly an overstatement of the true productivity gain.”
The number is debated. The mechanism isn’t: the leverage point moved from typing prompts to designing the loop that prompts.
## 02. Run the 4-condition test before you build anything.
Loops earn their cost under four conditions. Miss one and the loop costs more than it returns. The honest take from AlphaSignal’s analysis, and the part most X-threads skip:
The four conditions in plain English:
- The task repeats. A loop amortizes its setup across many runs. For a one-time job, a good prompt is faster and cheaper. If the work does not recur weekly, you don’t have a loop - you have a script you ran once.
- Verification is automated. The loop needs something that can fail the work without you in the room. A test suite, a type checker, a linter, a build. No automated check means you’re back in the chair reading every diff - the exact job the loop was supposed to remove.
- Your token budget can absorb the waste. Loops re-read context, retry, explore. That burns tokens whether or not the run ships anything. The technique scales with budget, which is why it reads as obvious to people with effectively free tokens and reckless to people on a metered plan.
- The agent has a senior engineer’s tools. Logs, a reproduction environment, the ability to run the code it writes and see what breaks. Without that, the loop iterates blind.
## 03. Who wins, who loses. Loops favor whoever can spend.
The economics are not universal. The people calling loop engineering obvious tend to have unmetered tokens.
The people for whom it’s reckless are usually on a $20 consumer plan trying to run heavy verification loops without hitting limits or a surprise invoice.
Who actually benefits, in practice:
- Teams with repetitive, machine-checkable work and the budget to run it - continuous test triage, dependency bumps, lint-and-fix passes, issue-to-PR drafts on a codebase with strong test coverage.
- Codebases with strong existing test suites. If a junior engineer could do the task from a checklist and a test suite would catch their mistakes, a loop fits.
- Async-first teams with multi-agent patterns already in use. For these teams, routines are the missing orchestration layer.
Who should skip it, today:
- Solo builders on consumer plans - the token bill arrives before the productivity gain does.
- Anyone working on code with no automated verification. A loop with no real check is the agent agreeing with itself on repeat.
- Teams whose real constraint is review capacity rather than typing speed. A loop generates more code; if review was already the bottleneck, it just makes the queue longer.
For one-off tasks, exploratory work, or anything where “done” is a judgment call, a single well-aimed prompt still wins. The honest version of this article is: loop engineering is real, and most developers don’t need it yet.
## 04. The 30-second loop check.
The 4-condition test from step 2 is the strategic decision. This is the tactical one - the checklist you run on a specific task before you turn it into a loop.
Miss one box and keep it as a manual prompt.
- 1. The task happens at least weekly. Less than weekly → setup cost will never amortize.
- 2. A test, type check, build, or linter can reject bad output. No automated gate → the agent grades its own homework.
- 3. The agent can run the code it changes. No reproduction environment → iteration is blind.
- 4. The loop has a hard stop. Token budget, iteration count, or time limit. Without one, the loop runs until someone notices the bill.
- 5. A human reviews before merge, deploy, or dependency changes. Anything irreversible needs a human approval gate before action.
Good first loops:
- CI failure triage - nightly, scan failures, classify causes, draft fix PRs for the easy ones.
- Dependency bump PRs - weekly, scan for updates, test compatibility, open PRs.
- Lint-and-fix passes - on every PR open event, apply style fixes automatically.
- Flaky test reproduction - loop until a theory survives the test.
- Issue-to-PR drafts on code with strong tests, where bad output gets rejected by the suite.
Bad first loops - these need a human in the chair:
- Architecture rewrites
- Auth or payments code
- Production deploys
- Vague product work
- Anything where “done” is a judgment call
PART 2 · The 5 Building Blocks
## 05. Automations: the heartbeat.
Automations are what make a loop an actual loop and not just one run you did once. They fire on a schedule, on an event, or on a trigger condition. They’re the heartbeat - everything else in the loop hangs off them.
What this looks like in the two tools that matter:
- Codex. The Automations tab - pick a project, set a prompt, set a cadence, choose local checkout or background worktree. Runs that find something land in a Triage inbox; runs that find nothing archive themselves.
- Claude Code. Three primitives that compose into the same shape:
/loop for session-scoped cadence, Desktop scheduled tasks for restart-survival, Routines for laptop-off cloud runs. Pair with hooks for lifecycle events.
Two primitives inside an automation that separate working loops from expensive ones:
- /loop re-runs on a cadence. Use it when you want regular checks regardless of state.
- /goal keeps going until a condition you wrote is actually true. A separate small model checks completion, so the agent that wrote the code isn’t the one grading it.
This is the maker-vs-checker split applied to the stop condition itself.
```
> /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. Worktrees: parallel without chaos.
The second you run more than one agent, the files start colliding. Two agents writing the same file is the same headache as two engineers committing to the same lines without talking first.
A git worktree fixes it - a separate working directory on its own branch sharing the same repo history, so one agent’s edits literally cannot touch the other’s checkout.
How it shows up in both tools:
- Codex builds worktree support in - several threads hit the same repo at once without bumping into each other.
- Claude Code exposes git worktree directly, a --worktree flag to open a session in its own checkout, and an isolation: worktree setting on subagents so each helper gets a fresh checkout that cleans itself up after.
Worktrees take away the mechanical collision, but you are still the ceiling. Your review bandwidth decides how many parallel agents you can actually run - not the tool.
## 07. Skills: write project knowledge once. Read on every run.
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, plus optional scripts, references, and assets.
Why this matters specifically for loops: a loop without skills re-derives your whole project context from zero every cycle. With skills, intent compounds.
The conventions, build steps, “we don’t do it like this because of that one incident” - written once on the outside, read by every run.
```
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. Connectors: the loop touches your real tools. Via MCP.
A loop that can only see the filesystem is a tiny loop. Connectors, built on the Model Context Protocol (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.
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.
The connectors are the reason the loop can act inside your actual environment, not just tell you what it would do if it could.
The connectors that pay back fastest for loop work, in order:
- GitHub - read repos, create branches, open PRs, comment on issues, react to webhook events. The single biggest day-one win for any code loop.
- Linear or Jira - update tickets as the loop progresses, link PRs back to issues, close items automatically when verification passes.
- Slack - post triage results, ping humans on escalations, summarize overnight runs in the morning.
- Sentry / your error tracker - let the loop investigate live alerts and draft fixes for the high-frequency ones.
## 09. Sub-agents: keep the maker away from the checker.
The most useful structural thing in a loop, by far, is splitting the agent that writes from the agent that checks.
Osmani’s framing is exact: 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.
This is the evaluator-optimizer pattern from Anthropic’s December 2024 engineering post under a new name. One model generates, another critiques, repeat. The vocabulary going viral in 2026 was documented eighteen months ago.
How sub-agents land in both tools:
- Codex only spawns subagents when you ask, runs them at the same time, then folds results back into one answer. You define your own agents as TOML files in .codex/agents/ - name, description, instructions, optional model and reasoning effort.
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: one agent explores, one implements, one verifies against the spec.
The reason it matters specifically inside a loop: the loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away.
Sub-agents burn more tokens since each one does its own model and tool work - spend them where a second opinion is worth paying for.
PART 3 · Build It Right or Don’t Build It
## 10. The state file. The agent forgets. The file does not.
This is the piece that sounds too dumb to matter and is actually the spine of every working loop. A markdown file, a Linear board, a JSON state -anything that lives outside the single conversation and holds what’s done and what is next.
Why this matters: agents have short memory by default. What they learn this session is gone tomorrow unless you write it down.
Osmani’s rule: the agent forgets, the repo does not. A loop without persistent state restarts every run; a loop with state resumes.
```
# 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
```
Two patterns for where the state file lives:
- Markdown in the repo - STATE.md at the root or inside .claude/. Version-controlled. Simple. Diff-readable. Best for solo or small team work.
- External system (Linear, GitHub Issues, a database) - survives across repos, queryable, supports team-wide visibility. Best for production loops where multiple humans need to see what the loop is doing.
For long-running loops that risk drifting off the goal, pair the state file with a standing high-level spec - VISION.md or AGENTS.md - that the agent rereads each run. State tells the agent where it is. The spec tells it where to go.
## 11. The minimum viable loop.
If you passed the 4-condition test in step 2, build the smallest loop that works before anything fancy. Four parts, no swarm.
The four parts, in plain language:
- One automation. A scheduled run that fires on a cadence and stops on a clear condition. Use /loop in Claude Code or an automation in Codex. Pair with /goal when you want it to run until a stated condition holds.
- One skill. A single SKILL.md that stores the project context the agent would otherwise re-derive from zero every run.
- One state file. A markdown file or a Linear board that records what is done and what is next. Tomorrow’s run resumes instead of restarting.
- One gate. The test, type check, or build that fails bad work automatically. This is the part that decides whether the loop helps or just spends.
Order matters: get one manual run reliable first. Turn it into a skill. Wrap it in a loop. Then schedule it. Skipping ahead is how loops fail in production.
The metric that matters is cost per accepted change - not tokens spent, not tasks attempted, not loops scheduled. If your accepted-change rate is below 50% you’re doing review work the loop saved you from, and the loop is losing.
## 12. The Ralph Wiggum loop. Loops that fail quietly.
Engineer Geoffrey Huntley documented this failure mode and named it. An agent meant to emit a completion token only when finished emits it early, and the loop exits on a half-done job. Without a hard gate, loops fail quietly and keep spending.
The Ralph Wiggum loop is what happens when:
- No real verifier. Just a second agent asked to “review,” no objective signal. Two optimists agreeing.
- Soft completion conditions. “Done” defined by the agent’s judgment, not by a test, build, or type check.
- No hard stops. Loop continues until something external kills it (rate limit, you noticing) rather than until success is verified.
The fix is the gate from step 11 - something objective that can fail the work. A test that passes or fails. A build that compiles or doesn’t. A linter that returns zero or non-zero. Not a verifier that has an opinion.
Other measured failure modes worth knowing:
- Goal drift over long sessions. Each summarization step is lossy; “don’t do X” constraints disappear at turn 47. Mitigation: a standing VISION.md or AGENTS.md reread each run.
- Self-preferential bias. The agent that wrote the code is too nice grading its own homework. Mitigation: a separate verifier subagent with no exposure to the maker’s reasoning.
- Agentic laziness. The loop declares “done enough” at partial completion. Mitigation: /goal with an objective stop condition checked by a fresh model.
## 13. Comprehension debt and cognitive surrender.
This is the failure mode that gets sharper as the loop gets better, not worse. Two named risks, both from Osmani’s essay:
- Comprehension debt. The faster the loop ships code you didn’t write, the larger the distance between what the repository contains and what you understand. The bill that hurts is not the token bill. It is the day you have to debug a system no one on the team has read.
- Cognitive surrender. The pull to stop forming an opinion and accept whatever the loop returns. Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking. Same action, opposite result.
The mitigations are not technical:
- Read the diffs. If you don’t read what the loop ships, you’re renting comprehension debt at compound interest.
- Spot-check the gate. Pick a few PRs the loop opened and verify the test that approved them actually catches the failure mode you care about. Gates rot.
- Block the loop from architecture work. Keep it on small, machine-checkable changes. The moment you let it touch judgment calls, comprehension debt accelerates.
- Pair-design loops with a teammate. A second pair of eyes when designing the loop catches blind spots the loop will exploit forever otherwise.
## 14. The security tax. An unattended loop is an unattended attack surface.
A loop running unattended is also an attack surface running unattended.
The threat model your loop has to defend against:
- Generated code shipping unreviewed. The loop opens PRs faster than a human can read them. Without a gate that includes security checks (SAST, dependency audit, secret scanning), insecure code merges automatically.
- Skills as injection vectors. A loop that auto-installs skills inherits every prompt injection hiding in their descriptions. Audit skill sources before installing.
- Credentials in logs. Debug logging during a long-running loop scatters secrets across logs you don’t monitor. Disable verbose logging in production loops; sanitize what does get logged.
- Permission scope creep. A loop tested with read-only permissions gets “just one” write permission added for convenience, then never re-audited. Re-audit permissions every 30 days.
## § The mistakes that turn loops into money pits
- Building a loop without running the 4-condition test. Step 2 exists for a reason. Most developers fail at least one condition.
- No objective gate. A second agent asked to “review” without a test, type check, or build is just a second optimist.
- One agent doing both writing and verifying. Self-preferential bias. The maker grades its own homework and it’s always “A+.”
- No state file. Tomorrow’s run restarts from zero instead of resuming.
- Vague stop conditions. “Done when it looks good” never holds. Use a test, a type pass, or a passing build.
- No token budget cap. Loops re-read context and retry. Without a cap, ambitious loops burn 5-10× the tokens you expected.
- Running loops on a consumer plan with heavy verification. Token bill or rate limit, one of them gets you.
- Auto-installing community skills. 520 of 17,022 audited skills leak credentials. Read the source before installing.
- Loops on judgment-call work. Architecture, auth, payments, vague product decisions. Keep the loop on lint-and-fix, not strategy.
- Not reading the diffs. Comprehension debt at compound interest. The day you debug a system no one has read costs more than the tokens ever did.
## Conclusion:
## The leverage moved. Your job did too.
For two years, the leverage in working with coding agents was at the prompt. Better prompts, better context, better one-shot output.
That phase is ending. The agents got good enough that the next leverage point is one floor up: the system that decides what they work on, when, with what gate, and what state survives between runs.
But the honest version of this story is not that everyone should rush to build loops. Most developers don’t need one yet - not until the task repeats, verification is automated, the budget can absorb the waste, and the agent has senior engineer tools.
Miss one condition and the loop costs more than it returns.
If you pass the test, build small. One automation. One skill. One state file. One gate. Get a manual run reliable. Turn it into a skill. Wrap it in a loop. Then schedule it. Order matters. Skip ahead and you’re paying for a system no one understands.
Cherny’s point isn’t that the work got easier. It’s that the leverage point moved. Build the loop. Stay the engineer.
## 相关链接
- [Codez](https://x.com/0xCodez)
- [@0xCodez](https://x.com/0xCodez)
- [180K](https://x.com/0xCodez/status/2064374643729773029/analytics)
- [linkedin.com/in/lev-deviatkin](https://linkedin.com/in/lev-deviatkin)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:50 PM · Jun 9, 2026](https://x.com/0xCodez/status/2064374643729773029)
- [180.6K Views](https://x.com/0xCodez/status/2064374643729773029/analytics)
- [View quotes](https://x.com/0xCodez/status/2064374643729773029/quotes)
---
*导出时间: 2026/6/10 11:58:29*
---
## 中文翻译
# 循环工程：从提示词编写者到循环设计师的 14 步路线图
**作者**: Codez
**日期**: 2026-06-09T15:50:43.000Z
**来源**: [https://x.com/0xCodez/status/2064374643729773029](https://x.com/0xCodez/status/2064374643729773029)
---
大多数开发者仍然在手动向他们的编码代理发送提示词。他们打字，等待，阅读差异文件，然后再打字。10 位构建者中有 9 位从未写过一行代码来替自己向代理发送提示词。
没有自动化，没有状态文件，没有验证器，没有调度。杠杆点已经转移——从输入提示词转移到了设计能够发送提示词的系统。这是从提示词编写者到循环设计师的 14 步路线图。
> 关注我的 Linkedin 以获取最新的 AI 独家资讯：linkedin.com/in/lev-deviatkin
这是一份实现这一转变的 14 步路线图——素材来源于 Anthropic 的工程文档、Addy Osmani 关于循环工程的长文，以及近期的测量研究。
三个层级：确定你是否真的需要一个循环，学习五个构建模块，然后构建一个最小的、不会造成负面影响的可用循环。
14 个步骤。3 个层级。停止提示。开始设计。
---
**第一部分 · 原因与测试**
## 01. 循环工程就是取代你自己作为提示词编写者的角色。
两年来，你从编码代理那里获取成果的方式一直是：编写一个提示词，分享上下文，阅读返回的内容，编写下一个提示词。代理是一个工具，而你一直全程掌控着它。那个阶段正在结束。
循环工程是构建一个小型系统，它能自主地发现工作，将其交给代理，检查结果，记录发生的事情，并决定下一步行动。你只需设计该系统一次。此后，系统将代替你向代理发送提示词。
Addy Osmani 将其分为六个部分：
Anthropic 的工程师现在每天合并的代码量是 2024 年的八倍——Anthropic 自己称这个数字“几乎肯定高估了实际的生产力提升”。
这个数字虽然有争议，但机制没有：杠杆点已经从输入提示词转移到了设计发送提示词的循环上。
## 02. 在构建任何东西之前，先进行四项条件测试。
循环只有在满足四个条件时才值得投入。漏掉一个，循环的成本就会超过其回报。这是来自 AlphaSignal 分析的诚实观点，也是大多数 X 帖子跳过的部分：
用通俗的语言解释这四个条件：
- 任务是重复的。循环将设置成本分摊到多次运行中。对于一次性工作，一个精心设计的提示词更快也更便宜。如果工作不是每周都发生，你需要的不是循环——你只是运行了一次脚本。
- 验证是自动化的。循环需要某种东西，能在你没有在场的情况下判定工作失败。测试套件、类型检查器、Linter（代码规范检查工具）、构建过程。没有自动检查意味着你又要坐在椅子前阅读每一个差异文件——这正是循环原本应该消除的工作。
- 你的 Token（代币）预算能承受这种浪费。循环会重读上下文、重试、探索。无论运行是否产生交付物，这都会消耗 Token。这种技术随着预算规模的扩大而扩展，这就是为什么对于拥有近乎免费 Token 的人来说这显而易见，而对于按量付费的人来说却显得鲁莽。
- 代理拥有高级工程师的工具。日志、复现环境、运行其编写的代码并查看哪里出错的能力。没有这些，循环就是在盲目迭代。
## 03. 谁赢谁输。循环偏向那些有能力花费的人。
经济规律并不普适。那些认为循环工程显而易见的人，通常拥有不限量的 Token。
对于那些认为这是鲁莽行为的人来说，通常是因为他们处于每月 20 美元的消费级套餐中，试图运行繁重的验证循环而不触及限额或收到意外的账单。
在实践中真正受益的是：
- 拥有重复性、机器可检查的工作以及运行预算的团队——持续测试分类、依赖升级、代码规范检查与修复、在具有强大测试覆盖率的代码库上将问题转化为 PR 草稿。
- 拥有现有强大测试套件的代码库。如果初级工程师能根据检查清单完成任务，且测试套件能发现他们的错误，那么循环就适合。
- 已经采用异步优先模式和多代理模式的团队。对于这些团队，流程（routines）正是缺失的编排层。
今天应该跳过它的人：
- 使用消费级套餐的独立构建者——Token 账单在生产力提升之前就先到了。
- 任何在没有自动验证的代码上工作的人。没有真正检查的循环，只是代理在不断地自我认同。
- 真正的约束在于审查能力而非打字速度的团队。循环会产生更多代码；如果审查已经是瓶颈，它只会让队列更长。
对于一次性任务、探索性工作，或任何“完成”是一个主观判断的事情，单一的精心设计的提示词仍然胜出。这篇文章的诚实版本是：循环工程是真实的，但大多数开发者暂时还不需要它。
## 04. 30 秒循环检查。
步骤 2 中的四项条件测试是战略决策。这是战术决策——你在将特定任务转化为循环之前运行的检查清单。
漏掉一个选项，就将其保留为手动提示词。
1. 任务每周至少发生一次。少于每周 → 设置成本永远无法摊销。
2. 测试、类型检查、构建或 Linter 可以拒绝糟糕的输出。没有自动关卡 → 代理在给自己打分。
3. 代理可以运行它更改的代码。没有复现环境 → 迭代是盲目的。
4. 循环有硬性停止点。Token 预算、迭代次数或时间限制。没有这个，循环会一直运行直到有人注意到账单。
5. 人类在合并、部署或依赖更改之前进行审查。任何不可逆的操作都需要在行动前经过人类批准关卡。
不错的首批循环：
- CI 失败分类——每晚进行，扫描失败，分类原因，为简单的问题起草修复 PR。
- 依赖升级 PR——每周进行，扫描更新，测试兼容性，打开 PR。
- 代码规范检查与修复——在每次 PR 打开事件时触发，自动应用样式修复。
- 不稳定测试复现——循环直到某个假设经得起测试。
- 在具有强测试的代码上进行问题到 PR 的起草，糟糕的输出会被套件拒绝。
糟糕的首批循环——这些需要有人坐在椅子上：
- 架构重写
- 认证或支付代码
- 生产环境部署
- 模糊的产品工作
- 任何“完成”是主观判断的事情
---
**第二部分 · 5 个构建模块**
## 05. 自动化：心跳。
自动化是让循环成为真正循环而不是仅仅运行一次的关键。它们按计划、事件或触发条件启动。它们是心跳——循环中的其他一切都依赖于它们。
在两个重要工具中的表现形式：
- Codex。“Automations（自动化）”选项卡——选择一个项目，设置提示词，设置节奏，选择本地检出到后台工作树。发现内容的运行会进入分类收件箱；没有发现内容的运行会自动归档。
- Claude Code。三种原语组合成相同的形态：
/loop 用于会话范围的节奏，Desktop 计划任务用于重启后的持久性，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 worktree 解决了这个问题——一个独立的工作目录，拥有自己的分支但共享同一个仓库历史，因此一个代理的编辑从字面上看不可能触及到另一个代理的检出。
在两个工具中的表现：
- Codex 内置了 worktree 支持——多个线程同时击中同一个仓库而不会互相碰撞。
- Claude Code 直接暴露 git worktree，一个 --worktree 标志用于在其自己的检出行中打开会话，以及子代理的 isolation: worktree 设置，让每个助手获得一个干净的检出版本，并在完成后自我清理。
Worktree 消除了机械冲突，但你仍然是上限。你的审查带宽决定了你实际能运行多少个并行代理——而不是工具。
## 07. 技能：一次编写项目知识。每次运行时读取。
技能（Skills）就是让你不再像金鱼一样在每个会话中重新解释相同的项目上下文。两个工具使用相同的格式：一个包含 SKILL.md 的文件夹，其中包含说明和元数据，外加可选的脚本、引用和资产。
为什么这对循环特别重要：没有技能的循环每个周期都从零重新推导你的整个项目上下文。有了技能，意图会复利。
惯例、构建步骤、“因为那一次事故我们不这样做”——在外部写一次，每次运行时读取。
```
name: ci-triage
description: 根据根本原因（环境、偶发、真正的 bug、
依赖、基础设施）对 CI 失败进行分类，为简单的问题起草修复，
升级其余问题。每当工作流运行失败或在早上的分类循环时触发。
---
# CI 分类技能
## 分类规则
- env: 缺少密钥，错误的环境变量，基础设施未配置。 # 人工处理
- flake: 重试通过且无代码更改。 # 重试一次，然后归档
- bug: 与最近提交相关的确定性失败。 # 起草修复
- dependency: 与版本升级相关的失败。 # 起草回滚
- infra: 超时、OOM、运行器问题。 # 升级
## 修复模式
- 认证测试 → 先检查 src/auth/middleware
- 数据库测试 → 验证 CI 环境中是否应用了迁移
- E2E 测试 → 对照最新的 UI 快照检查选择器
## 切勿做
- 禁用失败的测试——始终作为升级事项提交
- 未经人工批准修改 CI 配置
- 触碰 src/payments/ 或 src/billing/ (在 claude/permissions.md 中)
## 状态
每次运行后更新 STATE.md：检查的文件路径、分类、
打开的 PR、升级的项目。
```
## 08. 连接器：循环通过 MCP 触及你的真实工具。
一个只能看到文件系统的循环是很小的循环。基于模型上下文协议（MCP）构建的连接器，让代理能够读取你的问题跟踪器、查询数据库、访问暂存 API、在 Slack 中发送消息。
Codex 和 Claude Code 都支持 MCP，因此你为一个工具编写的连接器通常在另一个中也能直接工作。
这就是代理说“这是修复方法”与循环打开 PR、关联 Linear 票据并在 CI 变绿后通知频道之间的区别。
连接器是循环能够在你的实际环境中行动的原因，而不仅仅是告诉你如果它能做什么。
对于循环工作回报最快的连接器，按顺序排列：
- GitHub - 读取仓库、创建分支、打开 PR、评论问题、对 webhook 事件做出反应。任何代码循环的第一天最大的单一胜利。
- Linear 或 Jira - 随着循环的进行更新票据、将 PR 链接回问题、在验证通过时自动关闭项目。
- Slack - 发布分类结果、在升级事项上人工通知、在早上总结夜间运行。
- Sentry / 你的错误跟踪器 - 让循环调查实时警报并为高频问题起草修复。
## 09. 子代理：让制造者远离检查者。
循环中最有用的结构，毫无疑问是将编写代码的代理与检查代码的代理分开。
Osmani 的表述很准确：编写代码的模型“在给自己打分时太宽容了”。第二个代理拥有不同的指令，有时甚至是不同的模型，它能捕捉第一个代理自说自话造成的问题。
这是 Anthropic 2024 年 12 月工程文章中评估器-优化器模式的换了个新名字。一个模型生成，另一个批评，重复。这个在 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 在 commit 3a7b8c1 上达成
```
状态文件位置的两种模式：
- 仓库中的 Markdown - 根目录或 .claude/ 内的 STATE.md。版本控制。简单。可读差异。最适合个人或小团队工作。
- 外部系统（Linear, GitHub Issues, 数据库）——跨仓库存活，可查询，支持全团队可见。最适合需要多人看到循环正在做什么的生产循环。
对于有偏离目标风险的长期循环，将状态文件与一个常驻的高级规范（VISION.md 或 AGENTS.md）配对，代理每次运行时都会重读该规范。状态告诉代理它在哪里。规范告诉它去哪里。
## 11. 最小可行循环。
如果你通过了步骤 2 中的四项条件测试，请构建...