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

Loop 工程：从提示词写手到循环设计者的 14 步路线图。2026 年 6 月 9 日 · 19 分钟阅读 · 查看原文 ↗ Claude 自动化 Loops MCP 大多数开发者仍然手动给他们的编码 agent 写提示词。他们输入，等待，读 diff，再输入。10 个构建者里 9 个从没写过哪怕一个能替他们给 agent 写提示词的循环。 没有自动化，没有状态文件，没有验证器，没有调度。杠杆点已经转移了——从「输入提示词」到「设计会提示的系统」。这就是从提示词写手到循环设计者的 14 步路线图。 关注我的 Linkedin 获取新鲜的 AI alpha：linkedin.com/in/lev-deviatkin 这就是促成那个转变的 14 步路线图——取材自 Anthropic 的工程文档、Addy Osmani 关于 loop 工程的长文，以及近期的测量研究。 三个层级：先搞清楚你是否真的需要一个循环，学会五个构建块，然后构建一个最小、能工作、又不伤害你的循环。 14 步。3 个层级。别再提示了。开始设计。 第 1 部分 · 为什么与测试 Loop 工程就是「把作为提示词写手的你替换掉」。 两年里，你从编码 agent 那里得到东西的方式是：写一个提示词，分享上下文，读返回的内容，写下一个提示词。agent 是一件工具，而你全程握着它。这部分正在结束。 Loop 工程是构建一个小系统：它找到工作，交给 agent，检查结果，记录发生了什么，并决定下一步——自己来。你只设计一次这个系统。之后由系统来给 agent 写提示词。 Addy Osmani 把它拆成六部分： Anthropic 的工程师现在每天合并的代码量是 2024 年的八倍——这个数字 Anthropic 自己都称为「几乎可以肯定是对真实生产力提升的夸大」。 数字有争议。机制没有：杠杆点从「输入提示词」移到了「设计那个写提示词的循环」。 在构建任何东西之前，先跑 4 条件测试。 循环在四种条件下才值回成本。缺一个，循环的成本就超过回报。来自 AlphaSignal 分析的诚实结论，也是大多数 X 帖子跳过的部分： 用大白话说的四个条件： 任务会重复。循环把搭建成本摊到很多次运行上。对一次性任务，一句好提示词更快更便宜。如果工作不是每周都重复出现，你就没有一个循环——你只有一个跑过一次的脚本。 验证是自动化的。循环需要一个能在你不在场时把工作判失败的东西。一个测试套件、类型检查器、linter、构建。没有自动化检查，你就回到了椅子上读每一个 diff——那恰恰是循环本应移除的工作。 你的 token 预算能吸收浪费。循环会重读上下文、重试、探索。无论这次运行有没有交付任何东西，这都在烧 token。这个技术随预算扩展，这就是为什么它对拥有实际上免费 token 的人来说「显然」，而对用计量套餐的人来说「鲁莽」。 agent 拥有高级工程师的工具。日志、可复现环境、运行它写的代码并看到什么坏掉的能力。没有这些，循环就是在盲迭代。 谁赢，谁输。循环偏爱能花钱的人。 经济学并不普适。那些说 loop 工程「显然」的人，往往有无限量 token。 对它来说「鲁莽」的人，通常是在 $20 的消费套餐上，试图在不触顶限或意外账单的情况下跑重验证循环。 实际上谁受益： 有重复性、可机检的工作、且有钱跑它的团队——持续测试分诊、依赖升级、lint-and-fix 跑批、在测试覆盖强的代码库上做 issue-to-PR 草稿。 有强大现有测试套件的代码库。如果一个初级工程师能照着清单完成任务、而且测试套件能抓住他们的错误，那循环就合适。 已经用上多 agent 模式的 async-first 团队。对这些团队来说，routine 是缺失的编排层。 今天应该跳过它的： 消费套餐上的独立构建者——token 账单比生产力收益先到。 任何在没有自动化验证的代码上工作的人。一个没有真实检查的循环，就是 agent 一遍遍自我认同。 真正瓶颈是审查能力而非输入速度的团队。循环生成更多代码；如果审查本来就是瓶颈，它只是让队列更长。 对一次性任务、探索性工作，或任何「完成」是判断性的事情，一句瞄得准的提示词仍然赢。这篇文章的诚实版本是：loop 工程是真的，而大多数开发者现在还不需要它。 30 秒循环检查。 第 2 步的 4 条件测试是战略决策。这个是战术决策——你在把一项具体任务变成循环之前跑的那份清单。 缺一个勾，就保持手动提示。 任务至少每周发生一次。少于每周 → 搭建成本永远摊不回来。 一个测试、类型检查、构建或 linter 能拒绝坏输出。没有自动化关卡 → agent 给自己的作业打分。 agent 能运行它改的代码。没有可复现环境 → 迭代是盲的。 循环有一个硬停止。token 预算、迭代次数或时间限制。没有的话，循环会跑到有人注意到账单为止。 人类在合并、部署或依赖变更之前审查。任何不可逆的东西都需要一个人类批准关卡才能行动。 好的首个循环： CI 失败分诊——每晚，扫描失败，分类原因，为简单的起草修复 PR。 依赖升级 PR——每周，扫描更新，测试兼容性，开 PR。 lint-and-fix 跑批——在每个 PR 打开事件上，自动应用风格修复。 Flaky 测试复现——循环直到某个理论在测试下存活。 在测试强的代码上做 issue-to-PR 草稿，坏输出会被套件拒绝。 坏的第一个循环——这些需要有人在椅子上： 架构重写 鉴权或支付代码 生产部署 模糊的产品工作 任何「完成」是判断性的事情 第 2 部分 · 5 个构建块 Automations：心跳。 Automations 是让循环成为真正循环、而不是你跑过一次的东西的那个东西。它们按计划、按事件、或按触发条件触发。它们是心跳——循环里的其它一切都挂在它们上面。 这在两个重要的工具里长什么样： Codex。Automations 标签页——选一个项目，设一个提示词，设一个节奏，选本地 checkout 还是后台 worktree。找到东西的运行会落到一个 Triage 收件箱里；什么都没找到的运行会自我归档。 Claude Code。三个组合成同样形状的原语： /loop 用于会话作用域的节奏，Desktop 定时任务用于重启后存活，Routines 用于合上笔记本也能跑的云端运行。再配上 lifecycle 事件的 hooks。 一个 automation 内部两个把「能工作的循环」和「昂贵的循环」区分开的原语： /loop 按节奏重新运行。当你想要不管状态如何都定期检查时用它。 /goal 一直跑，直到你写的条件真的为真。一个单独的小模型检查完成度，所以写代码的那个 agent 不是打分的那一个。 这是把 maker-vs-checker 的分工应用到了停止条件本身上。 Worktrees：并行而不混乱。 你跑超过一个 agent 的那一刻，文件就开始碰撞了。两个 agent 写同一个文件，就像两个工程师没先沟通就往同一行提交一样头疼。 一个 git worktree 解决了它——一个在它自己分支上的独立工作目录，共享同一个仓库历史，所以一个 agent 的编辑字面上碰不到另一个的 checkout。 它在两个工具里怎么出现： Codex 内置了 worktree 支持——多个线程同时打同一个仓库而互不碰撞。 Claude Code 直接暴露 git worktree，一个 --worktree 标志在它自己的 checkout 里开会话，还有 subagent 上的 isolation: worktree 设置，让每个帮手拿到一个用后自清理的新 checkout。 Worktrees 消除了机械碰撞，但你仍然是天花板。你的审查带宽决定你能实际并行跑多少个 agent——不是工具。 Skills：项目知识写一次。每次运行都读。 一个 Skill 是让你停止像金鱼一样每会话都重新解释同一个项目上下文的方式。两个工具用同一个格式：一个文件夹，里面一个 SKILL.md，存放指令和元数据，外加可选的脚本、引用和资产。 为什么这对循环特别重要：没有 skills 的循环每个周期都从零重新推导你整个项目上下文。有了 skills，意图就复利了。 约定、构建步骤、「因为那次事故我们才不这么做」——在外面写一次，每次运行都读。 Connectors：循环触及你的真实工具。经由 MCP。 一个只能看文件系统的循环是个很小的循环。Connectors 基于 Model Context Protocol（MCP），让 agent 读你的 issue 跟踪器、查询数据库、打一个 staging API、往 Slack 发条消息。 Codex 和 Claude Code 都说 MCP，所以你为一个写的 connector 通常另一个直接就能用。 这就是「一个说『这是修复』的 agent」和「一个开 PR、关联 Linear ticket、并在 CI 绿了之后 ping 频道的循环」之间的区别。 Connectors 是循环能在你真实环境里行动、而不只是告诉你「如果它能它就会怎么做」的原因。 对循环工作回报最快的 connectors，按顺序： GitHub——读仓库、建分支、开 PR、评论 issue、响应 webhook 事件。任何代码循环第一天最大的胜利。 Linear 或 Jira——随循环进展更新 ticket，把 PR 关联回 issue，验证通过时自动关闭条目。 Slack——发分诊结果，升级时 ping 人，早上总结隔夜运行。 Sentry / 你的错误跟踪器——让循环调查实时告警，并为高频的起草修复。 Sub-agents：让 maker 远离 checker。 循环里最有用的结构性东西，毫无疑问，是把写代码的 agent 和检查的 agent 分开。 Osmani 的说法很精确：写代码的模型「给自己的作业打分时太手软了」。第二个有不同指令、有时是不同模型的 agent，能抓到第一个自我说服出来的东西。 这是 Anthropic 2024 年 12 月工程帖子里的 evaluator-optimizer 模式，换了个新名字。一个模型生成，另一个批评，重复。2026 年病毒式传播的词汇，十八个月前就被记录在案了。 sub-agents 在两个工具里怎么落地： Codex 只在你要求时生成 subagent，同时跑它们，然后把结果折叠回一个答案。你在 .codex/agents/ 里把自定义 agent 定义为 TOML 文件——名字、描述、指令、可选模型和推理力度。 你的安全审查员可以是一个高强度的大模型，而你的探索者可以是个快速的只读小东西。 Claude Code 用 .claude/agents/ 里的 subagents、以及在它们之间传递工作的 agent teams 做同样的事。 通常的分工：一个 agent 探索，一个实现，一个按 spec 验证。 它在循环内部特别重要的原因：循环在你没看着的时候跑，所以一个你真正信任的验证器，是你能走开的唯一理由。 Sub-agents 烧更多 token，因为每个都做自己的模型和工具工作——把它们花在「第二意见值得付钱」的地方。 第 3 部分 · 要么建对，要么别建 状态文件。agent 会忘。文件不会。 这是听起来蠢到不像会重要、实际上却是每个能工作的循环的脊柱的东西。一个 markdown 文件、一个 Linear board、一个 JSON 状态——任何存在于单次对话之外、保存「什么完成了、什么是下一步」的东西。 为什么这重要：agent 默认记忆很短。它们这一会话学到的东西，除非你写下来，明天就没了。 Osmani 的规则：agent 会忘，仓库不会。没有持久状态的循环每次运行都重启；有状态的循环续跑。 状态文件放哪的两种模式： 仓库里的 Markdown——根目录或 .claude/ 里的 STATE.md。版本控制。简单。diff 可读。最适合独立或小团队工作。 外部系统（Linear、GitHub Issues、一个数据库）——跨仓库存活、可查询、支持团队级可见性。最适合多个真人需要看到循环在做什么的生产循环。 对可能漂离目标的长期循环，把状态文件和一个常驻的高层 spec 配对——VISION.md 或 AGENTS.md——让 agent 每次运行都重读。状态告诉 agent 它在哪里。spec 告诉它要去哪。 最小可行循环。 如果你通过了第 2 步的 4 条件测试，在任何花哨的东西之前，先构建能工作的最小循环。四部分，不搞 swarm。 四部分，用大白话： 一个 automation。一次按计划触发的调度运行，并在一个清晰条件上停止。在 Claude Code 里用 /loop，或在 Codex 里用一个 automation。当你想要它跑到某个明确条件成立时，配上 /goal。 一个 skill。一个单独的 SKILL.md，存放 agent 否则每次运行都要从零重新推导的项目上下文。 一个状态文件。一个 markdown 文件或一个 Linear board，记录什么完成了、什么是下一步。明天的运行续跑，而不是重启。 一个关卡。自动判失败坏工作的测试、类型检查或构建。这是决定循环是帮忙还是烧钱的部分。 顺序重要：先让一次手动运行可靠。把它变成一个 skill。把它包进一个循环。然后调度它。跳步，就是循环在生产中失败的方式。 重要的指标是「每个被接受改动的成本」——不是花掉的 token，不是尝试的任务，不是调度的循环。如果你的接受率低于 50%，你就是在做循环本该替你省掉的审查工作，循环正在亏。 Ralph Wiggum 循环。悄悄失败的循环。 工程师 Geoffrey Huntley 记录并命名了这个失败模式。一个本应只在完成时才发完成 token 的 agent，提前发了它，循环就在半个活儿上退出了。没有硬关卡，循环悄悄失败并继续烧钱。 Ralph Wiggum 循环发生在以下情况： 没有真正的验证器。只是一个被要求「审查」的第二个 agent，没有客观信号。两个乐观主义者互相认同。 软完成条件。「完成」由 agent 的判断定义，而不是测试、构建或类型检查。 没有硬停止。循环持续到某个外部东西杀了它（限速、你注意到了），而不是直到成功被验证。 修复就是第 11 步的关卡——某个能客观判失败工作的东西。一个通过或失败的测试。一个编译或不编译的构建。一个返回零或非零的 linter。不是一个「有意见」的验证器。 其它值得知道的、被测量过的失败模式： 长会话里的目标漂移。每个总结步骤都是有损的；「别做 X」的约束在第 47 轮消失了。缓解：一个每次运行都重读的常驻 VISION.md 或 AGENTS.md。 自我偏爱偏差。写代码的 agent 给自己的作业打分太手软。缓解：一个与 maker 推理隔离的独立验证 subagent。 Agentic 懒惰。循环在部分完成时就宣布「足够好了」。缓解：/goal 配一个由新模型检查的客观停止条件。 理解债务与认知投降。 这是随着循环变好而变得更尖锐、而非更钝的失败模式。两个有名字的风险，都来自 Osmani 的文章： 理解债务。循环越快交付你没写的代码，仓库所包含的和你所理解的之间的距离就越大。伤人的账单不是 token 账单。是有一天你不得不调试一个团队里没人读过的系统的那一天。 认知投降。停止形成自己的观点、接受循环返回的任何东西的拉力。带着判断去做，设计循环就是解药；为了逃避思考去做，它就是加速器。同样的动作，相反的结果。 缓解不是技术性的： 读 diff。如果你不读循环交付的东西，你就是在按复利租理解债务。 抽查关卡。挑几个循环开的 PR，验证批准它们的测试真的抓到了你在意的失败模式。关卡会腐烂。 把循环挡在架构工作之外。让它留在小的、可机检的改动上。你让它碰判断性工作的那一刻，理解债务就加速。 和队友结对设计循环。设计循环时第二双眼睛能抓到盲点——否则循环会永远利用这些盲点。 安全税。一个无人值守的循环是一个无人值守的攻击面。 一个无人值守的循环，也是一个无人值守的攻击面。 你的循环必须防御的威胁模型： 生成的代码未经审查就交付。循环开 PR 的速度比人读得快。没有包含安全检查（SAST、依赖审计、秘密扫描）的关卡，不安全代码就自动合并了。 Skills 作为注入载体。一个自动安装 skills 的循环，会继承藏在它们描述里的每一次提示注入。安装前审计 skill 来源。 日志里的凭据。长期循环期间的 debug 日志把秘密撒进你不监控的日志里。在生产循环里禁用 verbose 日志；清理确实被记录的内容。 权限范围蔓延。一个以只读权限测试的循环，为图方便加了「就一个」写权限，然后从未重新审计。每 30 天重新审计权限。 § 把循环变成烧钱坑的错误 不跑 4 条件测试就建循环。第 2 步存在是有原因的。大多数开发者至少在一个条件上失败。 没有客观关卡。一个被要求「审查」却没有测试、类型检查或构建的第二个 agent，只是第二个乐观主义者。 一个 agent 既写又验证。自我偏爱偏差。maker 给自己的作业打分，永远是「A+」。 没有状态文件。明天的运行从零重启，而不是续跑。 模糊的停止条件。「看起来好了就完成」永远不成立。用一个测试、一次类型通过、或一次通过的构建。 没有 token 预算上限。循环重读上下文并重试。没有上限，雄心勃勃的循环会烧掉你预期的 5-10 倍 token。 在消费套餐上跑重验证循环。token 账单或限速，总有一个抓到你。 自动安装社区 skills。17,022 个被审计的 skills 里，520 个泄漏凭据。安装前读源码。 在判断性工作上跑循环。架构、鉴权、支付、模糊的产品决策。把循环留在 lint-and-fix，而不是战略。 不读 diff。按复利算的理解债务。你调试一个没人读过的系统的那一天，代价比 token 曾经花的都大。 结论： 杠杆转移了。你的工作也转移了。 两年里，和编码 agent 打交道的杠杆在提示词上。更好的提示词、更好的上下文、更好的一次性输出。 那个阶段正在结束。agent 变得足够好，下一个杠杆点在上一层：决定它们做什么、何时做、用什么关卡、以及运行之间什么状态存活的系统。 但这个故事的诚实版本不是「每个人都该冲去建循环」。大多数开发者还不需要——直到任务重复、验证自动化、预算能吸收浪费、而且 agent 有高级工程师的工具。 缺一个条件，循环的成本就超过回报。 如果你通过了测试，就建小的。一个 automation。一个 skill。一个状态文件。一个关卡。让一次手动运行可靠。把它变成 skill。把它包进循环。然后调度。顺序重要。跳步，你就是在为一个没人理解的系统付钱。 Cherny 的点不是工作变容易了。是杠杆点转移了。建循环。保持工程师。 Prompts name: ci-triage description: 按根因分类 CI 失败（env、flake、真 bug、 依赖、infra），为容易的起草修复，其余升级。 每当一个 workflow 运行失败、或在早间分诊循环时触发。 --- # CI triage skill ## 分类规则 - env：缺秘密、错的环境变量、infra 未配置。# human - flake：不改代码重试就通过。# retry once, then file - bug：与最近提交相关的确定性失败。# draft fix - dependency：与版本升级相关的失败。# draft rollback - infra：超时、OOM、runner 问题。# escalate ## 修复模式 - Auth 测试 → 先查 src/auth/middleware - Database 测试 → 验证 CI 环境里应用了 migration - E2E 测试 → 对照最新 UI 快照检查 selectors ## 绝不做 - 禁用失败的测试 —— 总是作为升级上报 - 未经人类批准修改 CI 配置 - 碰 src/payments/ 或 src/billing/（见 claude/permissions.md） ## State 每次运行后更新 STATE.md：检查的文件路径、分类、 开的 PR、升级的条目。 > /loop 30m /goal test/auth 里所有测试通过且 lint 干净。 扫描 src/auth 找新失败，在 claude/auth-fixes 里提议修复， 当 goal 条件成立时开草稿 PR。 ▲ Claude CronCreate(*/30 * * * * : auth quality loop) 停止条件：测试通过 + lint 干净（由 checker 验证） ✓ 已调度。会在中间完成之后继续， 直到 /goal 条件被独立 checker 满足。 # Loop state · ci-triage ## Last run 2026-06-09 03:30 UTC · 7 个失败已分类，3 个修复已起草，4 个已升级 ## In progress - claude/fix-auth-token-refresh — 测试本地通过，等待 CI - claude/fix-flaky-payment-webhook — 已应用重试模式，监控中 ## Completed today - claude/bump-axios-1.7.4 → 已合并（CI 绿，deps 循环已验证） - claude/lint-fix-pass-june-9 → 已合并 ## Escalated to humans - src/billing/refund.ts — 测试三种方式失败，根因不明 - ci/staging-runner — infra 超时，不是代码问题 ## Lessons learned（写在这里，不写在聊天里） - 2026-06-08：PowerShell 在这个 Windows runner 上碰到 TLS 1.2 问题。用 bash。 - 2026-06-07：tests/e2e/checkout 需要环境里的 Stripe webhook secret。缺了就跳过。 ## 自上次审查以来满足的停止条件 - /goal「所有测试通过 + lint 干净」在提交 3a7b8c1 于 02:14 UTC 达成 Links linkedin.com/in/lev-deviatkin 标签：# X # Claude # 自动化 # Loops # MCP # Linkedin 相关文章 Loop Engineering：Boris Cherny 方法——替你给编码 agent 写提示词的系统 大多数开发者仍然手动给编码 agent 写提示词。输入，等待，读 diff，再输入。你就是那个循环。Claude Loops MCP 自动化