# 循环工程：从提示词操作员到循环设计者的 14 步路线图
**作者**: 淘沙者(TheSandPicker)
**日期**: 2026-07-06T13:59:10.000Z
**来源**: [https://x.com/Etudecn/status/2074131043679117730](https://x.com/Etudecn/status/2074131043679117730)
---
大多数开发者还在手动给编程 Agent 敲提示词。打字，等结果，看 diff，再打字。十个开发者里有九个从没写过哪怕一个能替自己发提示词的循环。
没有自动化，没有状态文件，没有验证器，没有定时任务。杠杆点已经转移了——从手敲提示词，变成设计一套系统来替你发提示词。
这是从提示词操作员到循环设计者的 14 步路线图。
内容来源：Anthropic 的工程文档、Addy Osmani 关于循环工程的长文，以及最近的量化研究。
分三个阶段：先搞清楚你是不是真需要循环，再学五个核心组件，最后搭一个最小可用、不会反咬你一口的循环。
14 步，3 个阶段。别再手敲提示词了，开始设计系统。
第一部分 · 为什么要做，以及怎么判断你需不需要
过去两年，你让编程 Agent 干活的方式是：写提示词，给上下文，读返回结果，写下一个提示词。Agent 是个工具，你得一直握着它。这个阶段快结束了。
循环工程就是搭一个小系统，让它自己找活干，把活交给 Agent，检查结果，记录发生了什么，再决定下一步怎么走。你设计一次这套系统，之后就是系统替你给 Agent 发提示词。
Addy Osmani 把它拆成了六个环节：
Anthropic 的工程师现在每天合并的代码量是 2024 年的八倍——这个数字 Anthropic 自己都说“几乎可以肯定高估了真实的生产力提升。”
数字有争议，但机制没有：杠杆点从手敲提示词转移到了设计那个替你发提示词的循环。
循环在四个条件同时满足时才值回成本。缺一个，循环的代价就大于收益。这是 AlphaSignal 分析里最实在的结论，也是大多数 X 帖子不会告诉你的部分：
四个条件用大白话讲：
- 任务是重复的。循环的搭建成本会被多次运行摊薄。一次性的活，一个好提示词更快也更便宜。如果这活儿不是每周都干，那就不叫循环，叫你跑了一次的脚本。
- 验证是自动化的。循环需要一种不靠你盯着就能判定结果好坏的机制。测试套件、类型检查、lint、构建，都行。没有自动检查，你就得坐回去逐个看 diff——这恰恰是循环本该替你省掉的事。
- 你的 token 预算能扛得住浪费。循环会反复读上下文、重试、探索。不管最后有没有产出，token 都在烧。这个技术能不能用取决于你的预算——对 token 基本免费的人来说理所当然，对按量计费的人来说就是莽撞。
- Agent 有资深工程师的工具。日志、复现环境、能跑自己写的代码并看到哪里坏了。没有这些，循环就是在瞎摸索。
这笔账不是对所有人都成立。说循环工程“显而易见”的人，通常是 token 不计量的。
说它莽撞的人，通常是拿着 20 美元消费版套餐，想跑重量级验证循环，又不想撞限额或收到意外账单。
实践中，谁真正受益：
- 有重复性、可机器检查的工作，也有预算跑的团队——持续测试分诊、依赖升级、lint 修复、在测试覆盖强的代码库上把 issue 变成 PR 草稿。
- 已有强测试套件的代码库。如果初级工程师照着清单就能干，测试套件还能兜底，那循环就合适。
- 已经在用多 Agent 模式的异步优先团队。对这些团队，例程就是缺的那层编排。
谁现在应该跳过：
- 消费版套餐上的独立开发者——token 账单比生产力提升来得更早。
- 在没有自动验证的代码上工作的人。没有真正检查的循环，就是 Agent 在反复跟自己达成共识。
- 真正的瓶颈是 review 能力而不是打字速度的团队。循环产出更多代码，如果 review 本来就是瓶颈，只会让队列更长。
对于一次性的任务、探索性的工作，或者“做完了”本身是个主观判断的事，一个精准的单次提示词还是更划算。这篇文章诚实的版本是：循环工程是真的，但大多数开发者暂时还不需要。
第二步那个 4 条件测试是战略决策。下面这个是战术层面的——把某个具体任务变成循环之前，你要过的清单。
少一条，就继续手动提示。
-
1. 任务至少每周发生一次。低于每周一次，搭建成本永远摊不回来。
-
1. 测试、类型检查、构建或 lint 能拒绝坏结果。没有自动门禁，Agent 就是自己给自己批作业。
-
1. Agent 能跑它改过的代码。没有复现环境，迭代就是瞎跑。
-
1. 循环有硬性停止条件。token 预算、迭代次数或时间限制。没有的话，循环会一直跑到有人看到账单。
-
1. 合并、部署或依赖变更之前有人审。任何不可逆的操作，都需要人工审批这道门。
好的入门循环：
- CI 失败分诊——每晚扫描失败，归类原因，简单的直接出修复 PR。
- 依赖升级 PR——每周扫描更新，测兼容性，开 PR。
- lint 修复——每个 PR 打开时自动应用风格修复。
- flaky 测试复现——循环跑直到某个假设通过测试。
- 在测试强的代码上把 issue 变成 PR 草稿，坏结果会被测试套件拒掉。
不好的入门循环——这些需要人盯着：
- 架构重写
- 认证或支付代码
- 生产部署
- 模糊的产品需求
- “做完了”是主观判断的任何事
第二部分 · 五个核心组件
自动化是让循环真正成为循环、而不是你跑了一次就丢的东西。它按计划触发，按事件触发，或按条件触发。它是心跳——循环里其他一切都挂在它上面。
两个主流工具里分别长什么样：
- Codex。Automations 标签页——选项目、设提示词、设频率、选本地检出还是后台 worktree。找到东西的运行结果进入 Triage 收件箱，没找到的自动归档。
- Claude Code。三个原语组合成同样的结构：/loop 做会话级定时，Desktop 定时任务保证重启后还在，Routines 实现笔记本关机也能在云端跑。配合 hooks 处理生命周期事件。
自动化里面有两个原语，区分了能用的循环和烧钱的循环：
- /loop 按频率重复跑。不管状态如何，想定期检查就用它。
- /goal 一直跑，直到你写的条件真的成立。一个独立的小模型来检查完成情况，所以写代码的 Agent 不是给自己打分的那个。
这就是 maker-vs-checker 分离，用在停止条件本身上。
```
> /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.
```
当你同时跑超过一个 Agent，文件就开始打架了。两个 Agent 写同一个文件，跟两个工程师不沟通就往同一行提交一样头疼。
git worktree 能解决——一个独立的工作目录，有自己的分支，共享同一个仓库历史，一个 Agent 的改动根本碰不到另一个的检出。
两个工具里的表现：
- Codex 内建了 worktree 支持——多个线程同时跑同一个仓库互不干扰。
- Claude Code 直接暴露 git worktree，一个 --worktree 参数在独立检出里开会话，还有 subagent 上的 isolation: worktree 设置，让每个助手拿到一个用完自动清理的独立检出。
worktree 解决了机械冲突，但你还是天花板。你能 review 多少，决定了你实际能并行跑多少个 Agent——不是工具决定的。
Skill 是让你不用每次会话都像金鱼一样重新解释项目背景的东西。两个工具用同样的格式：一个文件夹，里面放 SKILL.md，存指令和元数据，加上可选的脚本、参考和资源。
对循环来说为什么重要：没有 skill 的循环，每个周期都从零开始重新推导整个项目背景。有了 skill，意图会累积。
那些约定、构建步骤、“我们不这么干是因为之前出过那次事”——在外面写一次，每次运行都能读到。
```
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.
```
只能看文件系统的循环是个很小的循环。连接器，基于 Model Context Protocol（MCP），让 Agent 能读你的 issue 跟踪系统、查数据库、请求 staging API、往 Slack 发消息。
Codex 和 Claude Code 都支持 MCP，所以你为一个写的连接器通常在另一个里直接能用。
这就是“这是修复方案”的 Agent 和“自己开 PR、关联 Linear 工单、CI 绿了之后 ping 频道”的循环之间的区别。
连接器是循环能在你真实环境里动手的原因，而不是只能告诉你“如果可以的话我会怎么做”。
对循环工作回报最快的连接器，按顺序：
- GitHub——读仓库、建分支、开 PR、评论 issue、响应 webhook 事件。任何代码循环的第一天最大收益。
- Linear 或 Jira——随着循环推进更新工单，把 PR 关联回 issue，验证通过后自动关闭条目。
- Slack——发分诊结果，升级时 ping 人，早上汇总夜间运行情况。
- Sentry 或你的错误跟踪器——让循环调查实时告警，给高频错误出修复方案。
循环里最有用的结构性设计，远远超过其他的，是把写代码的 Agent 和检查代码的 Agent 分开。Osmani 说得很准：写代码的模型“给自己批作业太宽容了”。第二个 Agent，指令不同，有时候模型也不同，能抓到第一个 Agent 自己说服自己的那些问题。
这就是 Anthropic 2024 年 12 月那篇工程文章里的 evaluator-optimizer 模式，换了个名字。一个模型生成，另一个挑刺，循环往复。2026 年火的这套说法，十八个月前就有文档了。
子 Agent 在两个工具里的落地：
- Codex 只在你要求时才生成子 Agent，同时跑，然后把结果合并成一个答案。你在 .codex/agents/ 里用 TOML 文件定义自己的 Agent——名字、描述、指令、可选的模型和推理强度。你的安全审查员可以是大模型高强度推理，探索器可以是个快速的只读小东西。
- Claude Code 用 .claude/agents/ 里的子 Agent 和在它们之间传递工作的 Agent 团队做同样的事。常见分工：一个探索，一个实现，一个按规格验证。
在循环里特别重要的原因：循环跑的时候你没在看，所以一个你真正信任的验证器是你能走开的唯一理由。子 Agent 更费 token，因为每个都做自己的模型和工具调用——只在值得花第二个意见的地方花。
第三部分 · 要么搭对，要么别搭
这部分听起来蠢到不值得说，但它是每个能用的循环的脊椎。一个 markdown 文件，一个 Linear 看板，一个 JSON 状态——任何活在单次对话之外、记录了什么做完了什么还没做的东西。
为什么重要：Agent 默认记性很短。这次会话学到的东西，明天就没了，除非你写下来。
Osmani 的规则：Agent 会忘，仓库不会。没有持久状态的循环每次运行都从头开始；有状态的循环是接着上次的。
```
# 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——STATE.md 放在根目录或 .claude/ 下面。有版本控制。简单。能看 diff。适合独立或小团队。
- 外部系统（Linear、GitHub Issues、数据库）——跨仓库存活，可查询，支持团队可见性。适合多个人需要看到循环在干啥的生产级循环。
对于长跑的、容易偏离目标的循环，把状态文件配一个固定的高层规格——VISION.md 或 AGENTS.md——让 Agent 每次运行都重读。状态告诉 Agent 它在哪，规格告诉它要去哪。
如果你过了第二步的 4 条件测试，在搞花活之前先搭最小可用的循环。四个部分，不要集群。
四个部分，大白话：
- 一个自动化。一个定时运行，按频率触发，在明确条件下停止。Claude Code 里用 /loop，Codex 里用 automation。想跑到某个条件成立就配上 /goal。
- 一个 skill。一个 SKILL.md，存 Agent 不然每次都要从零推导的项目背景。
- 一个状态文件。一个 markdown 文件或 Linear 看板，记录做完了什么、下一步干什么。明天的运行是接着干，不是从头来。
- 一个门禁。测试、类型检查或构建，自动把坏结果打回去。这部分决定了循环是在帮你还是在烧钱。
顺序很重要：先让一次手动运行可靠。把它变成 skill。包进循环里。然后定时跑。跳步是循环在生产环境里失败的原因。
真正重要的指标是每个被接受的变更的成本——不是花了多少 token，不是尝试了多少任务，不是排了多少循环。如果你的接受率低于 50%，你在做循环本该替你省掉的 review 工作，循环在亏钱。
工程师 Geoffrey Huntley 记录了这个失败模式并给它起了名字。一个本该只在完成时才发出完成信号的 Agent，提前发了，循环在半成品上就退出了。没有硬门禁，循环悄悄失败，还在继续烧钱。
Ralph Wiggum 循环就是这种情况：
- 没有真正的验证器。只是让第二个 Agent “review”，没有客观信号。两个乐观主义者在互相认同。
- 软完成条件。“做完了”由 Agent 的判断定义，不是由测试、构建或类型检查定义。
- 没有硬停止。循环一直跑到被外部东西干掉（限流、你注意到了），而不是跑到成功被验证。
解法就是第十一步的门禁——一个能判定结果好坏的客观标准。一个过或不过的测试。一个编不编得过的构建。一个返回零或非零的 linter。不是一个有看法的验证器。
其他值得了解的、被量化过的失败模式：
- 长会话中的目标漂移。每次摘要都有信息损失；“不要做 X”的约束到第 47 轮就消失了。对策：一个固定的 VISION.md 或 AGENTS.md，每次运行重读。
- 自我偏好。写代码的 Agent 给自己批作业太宽容。对策：一个没看过 maker 推理过程的独立验证子 Agent。
- Agent 偷懒。循环在部分完成时就宣布“差不多了”。对策：/goal 配一个由新模型检查的客观停止条件。
这是循环越好就越尖锐、而不是越迟钝的失败模式。两个有名字的风险，都来自 Osmani 的文章：
- 理解债。循环越快地交付你没写过的代码，仓库里有什么和你理解什么之间的距离就越大。真正疼的那笔账不是 token 账单。是有一天你得调试一个团队里没人读过的系统。
- 认知投降。放弃形成自己的判断、接受循环返回的任何东西的倾向。带着判断力来设计循环是解药，为了不思考而设计循环是催化剂。同样的动作，相反的结果。
对策不是技术性的：
- 看 diff。如果你不读循环交付的东西，你在以复利积累理解债。
- 抽查门禁。挑几个循环开的 PR，验证批准它们的测试是不是真的能抓住你在意的那个失败模式。门禁会腐烂。
- 不让循环碰架构。让它待在小的、可机器检查的改动上。一旦让它碰判断题，理解债就加速膨胀。
- 跟队友一起设计循环。设计时多一双眼睛，能抓住循环会永远利用的盲区。
无人值守跑着的循环，也是一个无人值守跑着的攻击面。
你的循环需要防御的威胁模型：
- 生成的代码未经审查就合进去了。循环开 PR 比人读得快。没有包含安全检查（SAST、依赖审计、密钥扫描）的门禁，不安全的代码会自动合并。
- Skill 作为注入载体。自动安装 skill 的循环，继承了藏在描述里的所有提示词注入。安装前审计来源。
- 日志里的凭证。长时间运行的循环在调试日志里散落了你没监控的密钥。生产循环里关掉详细日志；日志内容做脱敏。
- 权限范围蔓延。一个用只读权限测试的循环，为了方便被加了“就一个”写权限，然后再也没被重新审计。每 30 天重新审计权限。
- 没跑 4 条件测试就搭循环。第二步存在是有原因的。大多数开发者至少有一条不满足。
- 没有客观门禁。让第二个 Agent “review”但没有测试、类型检查或构建，只是第二个乐观主义者。
- 一个 Agent 既写又验。自我偏好。自己给自己批作业，永远是“A+”。
- 没有状态文件。明天的运行从零开始，而不是接着干。
- 模糊的停止条件。“看着差不多了”从来不算数。用测试、类型通过或构建通过。
- 没有 token 预算上限。循环会反复读上下文和重试。没有上限，野心大的循环会烧掉你预期的 5 到 10 倍 token。
- 在消费版套餐上跑重量级验证循环。token 账单或限流，总有一个先到你。
- 自动安装社区 skill。审计过的 17,022 个 skill 里有 520 个泄露凭证。安装前读源码。
- 在判断题上跑循环。架构、认证、支付、模糊的产品决策。让循环待在 lint 修复上，别碰策略。
- 不看 diff。复利积累的理解债。有一天你调试一个没人读过的系统，代价远超 token 花费。
过去两年，跟编程 Agent 协作的杠杆在提示词上。更好的提示词，更好的上下文，更好的单次输出。
这个阶段在结束。Agent 已经好到下一个杠杆点在上面一层：那个决定它们做什么、什么时候做、用什么门禁、运行之间保留什么状态的系统。
但这个故事诚实的版本不是每个人都该赶着搭循环。大多数开发者暂时还不需要——除非任务重复、验证自动化、预算能扛浪费、Agent 有资深工程师的工具。
少一个条件，循环的代价就大于收益。
如果你过了测试，就搭小的。一个自动化，一个 skill，一个状态文件，一个门禁。先让手动跑可靠。变成 skill。包进循环。然后定时跑。顺序很重要。跳步你就是在为一个没人理解的系统付钱。
Cherny 的意思不是活儿变简单了。是杠杆点移了。搭循环，但继续做工程师。
## 相关链接
- [淘沙者(TheSandPicker)](https://x.com/Etudecn)
- [@Etudecn](https://x.com/Etudecn)
- [28K](https://x.com/Etudecn/status/2074131043679117730/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:59 PM · Jul 6, 2026](https://x.com/Etudecn/status/2074131043679117730)
- [28.4K Views](https://x.com/Etudecn/status/2074131043679117730/analytics)
---
*导出时间: 2026/7/7 11:18:48*