循环工程：Boris Cherny 方法——替你提示编程智能体的系统

循环工程：Boris Cherny 方法——让系统替你给编程 Agent 下提示 2026年7月8日 · 13分钟阅读 · 查看原文 ↗ Claude Loops MCP Automation  大多数开发者仍然靠手动给他们的编程 Agent 下提示。输入、等待、看 diff、再输入。你就是那个循环。 > "我不再给 Claude 下提示了。我让正在运行的循环去提示 Claude，并弄清楚要做什么。我的工作就是写循环。" —— Boris Cherny，Claude Code 的创造者 本文会解释这句话的含义，说明如何判断你是否真的需要循环，然后带你走完一个可运行循环的每一个环节，并附上你现在就能直接复制的提示词。 第一部分 · 概念 循环是什么，它取代了什么 一个提示词是一条指令。你提问，得到回答，然后决定下一步做什么。 一个循环是一个目标：AI 会一直朝着这个目标努力，直到达成为止，而不需要你逐步提示。你只需定义一次目的，剩下的交给循环处理。 三个部分决定了每个循环的成败： 第二部分 · 检验 你真的需要循环吗？ 并非每个任务都值得用一个循环。只有当四个条件全部满足时，循环才配得上它的成本。少一个，手动提示依然更划算。 适合作为第一批循环：CI 失败排查、依赖升级、lint-and-fix 清理、复现不稳定的测试、在测试覆盖扎实的代码上把 issue 草拟成 PR。 暂时跳过：架构重写、认证或支付、生产环境部署，以及任何"完成"需要主观判断的事情。   第三部分 · 构建 如何一步步构建一个可运行的循环 下面的每一点都对应 Cherny 公开描述过的构建模块。每一步都附有一个你现在就能粘贴使用的提示词。 01 写下目标，而不是下一条提示词。 与其一轮一轮地引导 Claude，不如一次性写下"完成"到底意味着什么，然后让它持续工作，直到该条件成立为止。 Claude Code 的 /goal 命令做的正是这件事。一个独立且更小的模型会在每一轮之后检查条件是否成立，因此完成工作的那个 agent 永远不会自己决定自己是否已经完成。 02 把"制造者"与"检查者"分开。 写代码的模型在批改自己的作业时总是过于宽厚。没有独立检查的循环，不过是一个 agent 在反复自我认同。 解决办法是结构性的：用不同的指令做第二次检查，而它的唯一职责就是找出问题所在。 03 给它跨会话存活的记忆。 会话一结束，agent 就会忘掉一切。Claude Code 用 CLAUDE.md 解决了这个问题——这是它在每个会话开始时都会读取的一个文件。 当 Claude 犯错时，正确的做法不是在对话里修好它然后翻篇，而是让 Claude 把这条教训写进那个文件里，这样未来每个会话都能继承这个修复。 04 保留一个状态文件，让明天的运行是"续跑"而非"重跑"。 Agent 默认只有短时记忆。它们在一个会话里学到的东西，除非你记下来，否则到下一个会话就消失了。状态文件是任何存在于对话之外、记录"已完成什么、什么失败了、下一步是什么"的东西：仓库里的一个 markdown 文件、一块 Linear 看板、一段 JSON。   没有它，每次运行都是冷启动，并以全额的 token 成本重新推导上下文。有了它，循环就能从上次中断的地方继续。你也可以随时打开那个文件，准确看到循环一直在做什么。 仓库里的 Markdown。把 STATE.md 放在仓库根目录或 .claude/ 目录内。纳入版本控制、便于 diff 查看。最适合个人或小团队使用。 外部系统。Linear、GitHub Issues、数据库。可跨仓库存续，最适合需要多人可见的场景。 对于长期运行的循环，把状态文件与一份常驻规范（VISION.md）搭配使用，agent 每次运行都会重新读取它。状态告诉它"现在在哪"，规范告诉它"要往哪去"。 05 用 worktree 隔离并行运行的 agent。 两个 agent 编辑同一批文件，和两个工程师互不沟通却往同一段代码提交一样令人头疼。git worktree 让每个 agent 在各自的分支上拥有独立的检出。一个 agent 的改动在字面意义上就无法碰到另一个 agent 的文件。 Claude Code 通过在子 agent 上设置 isolation: worktree，直接暴露了 git worktree。每个帮手都会拿到一个干净的检出，用完即清理。 Codex 则原生内置了 worktree 支持。多个线程同时操作同一个仓库也不会冲突。 Worktree 解决的是机械层面的冲突，但你仍然是天花板。你的审查带宽决定了你实际能并行运行多少个 agent。从两个开始，而不是十个。 06 通过 MCP 把它连接到你的真实工具。 一个只能看到你本地文件的循环，最多只能提出建议。基于 Model Context Protocol 构建的连接器，让 agent 能够读取你的 issue 追踪器、打开 pull request、发布到 Slack、查询数据库、调用 staging API。 这才是"说出'这是修复方案'的 agent"和"真的把修复上线、关联 Linear 工单、并在 CI 通过后提醒频道"的循环之间的真正区别。Claude Code 和 Codex 都支持 MCP，所以你为其中一个写的连接器通常也能在另一个里用。 对循环工作回报最快的连接器，按顺序排列如下： GitHub。读取仓库、创建分支、发起 PR、评论 issue、响应 webhook 事件。对任何代码循环来说，这是第一天就能见效的最大收益。   Linear 或 Jira。随循环推进更新工单、把 PR 关联回 issue、在验证通过时自动关闭条目。 Slack。发布排查结果、在需要升级处理时通知相关人员、早上汇总过夜运行的成果。 Sentry / 你的错误追踪器。让循环调查实时告警，并为高频出现的问题草拟修复方案。 07 加入"心跳"，让它无需你也能运行。 一个靠你手动触发的循环，只是你今天碰巧运行的一个脚本。心跳会按计划、按事件或按条件触发它，完全不用你操心。 /loop 会按固定节奏重复运行。当你想要定期检查、而不论当前状态如何时使用它。例如：每 30 分钟扫描一次 CI 失败。 /goal 会一直运行，直到你写的某个条件成立为止。一个独立的小模型负责检查完成度，因此"制造者"不是那个打分的。例如："所有测试通过且 lint 干净。" /goal 的关键细节在于：检查完成度的评估模型与做事的模型不是同一个。制造者不能宣布自己已完成。这正是第 02 步里"制造者 vs 检查者"的分离，只是把它应用到了停止条件本身。 08 把每一次验证器的拒绝都变成一条永久规则。 这正是让循环随着时间不断改进、而不仅是跑得更快的原因。第 2 步抓住了缺陷，第 8 步确保这个缺陷永远不会再出现。把拒绝提炼成一条硬性规则，写进循环做任何事之前都会读取的那个文件里。 经过几个项目之后，你的约束文件会变成一份能够自我执行的"活文档"。验证器每次需要抓的东西越来越少，因为规则在不断收紧。这才是"自我学习"的诚实版本：模型并没有重新训练它的权重，是围绕它的系统变得越来越聪明。 09 从一个循环扩展到一支小型机群。 Cherny 同时运行着多个循环：一个搜寻架构改进，另一个统一重复的抽象，两者都源源不断地提交 PR。但顺序比数量更重要。 一旦你拥有不止一个循环，真正重要的指标是：每个被采纳改动的成本。如果你的改动采纳率跌破 50%，循环的花费就已经超过了它省下的部分。   10 把循环升级为后台 agent。 最后一招。一旦循环稳定下来、并有技能支撑，就把它指向一个触发器：一个计划、一个 webhook、一次文件投递。让它主动运行，只把最终交付物和偏差呈现出来。循环里剩下的唯一人类，就是你设定的那个问题，以及你针对答案做出的那个决定。 第四部分 · 坦诚的部分 哪里会出错 Token 成本会不断累加。无论这一轮是否交付了任何东西，循环都会反复重读上下文并重试。无限 token 的套餐下舒舒服服，计量套餐下就成了挥霍。 循环会悄无声息地失败。没有硬性停止条件的话，循环会在自己并未真正完成时就宣布"完成"，把成本花在自信上，而不是结果上。 一个无人看管的循环就是一个无人看管的攻击面。任何能够合并代码或持有写入权限的东西，都需要按计划定期复核权限，而不是设置一次就完事。 循环改变的是工作，而不是对你的需求。循环越快交付那些并非你亲手写的代码，你的仓库里所包含的东西与你所理解的东西之间的鸿沟就越大。请阅读 diff。 让循环变成无底洞的错误 没有独立的把关。让第二个 agent 去"审查"、但背后没有任何测试支撑，它不过是第二个乐观主义者。 同一个 agent 既写又查。自我偏好偏差。打出的分数永远宽厚。 没有状态文件。明天的运行从零重新开始。 模糊的停止条件。"看起来不错就算完成"永远站不住脚。要用测试、类型检查通过、一次构建来判定。 没有 token 预算上限。野心勃勃的循环会烧掉你预期 5-10 倍的 token。 让循环去处理需要主观判断的事。架构、认证、支付。让循环专注于 lint-and-fix，而不是战略。 不阅读 diff。这是按复利累积的"理解负债"。 第五部分 · Cherny 认为接下来会发生什么 最终留存下来的部分 当被问及人类最终会在哪方面保持独特优势时，Cherny 说的不是代码、设计或产品感。他说的是价值观：教会系统该在乎什么——就像你教一个人那样，而不是像教一个函数那样。 他描述过自己运行数百个 Claude 实例，监控着 Twitter、GitHub 和 Slack，自动浮现产品创意。如今这些创意大多还很糟糕，但他预计几个月内大部分会变得优秀。天花板不在模型，而在你围绕它构建的循环的质量。 他自己的轨迹恰好证明了这一点。2024 年末：Claude 写了 10-20% 的代码。2025 年中：他卸载了自己的 IDE。2026 年：他完全不再提示 Claude。他设计那些替他提示的系统。 结论 大多数开发者暂时还不需要循环。要等到任务会重复出现、验证已自动化、预算能吸收浪费、且 agent 拥有真实工具之后才需要。如果你不满足这四个条件，一条瞄准得当的单个提示词仍然是正确的选择。 如果确实满足：从小处构建。一个心跳。一个技能。一个状态文件。一道把关。先让一次手动运行可靠起来，再把它变成一个技能，再包进循环里，再排上计划。顺序很重要。 写下目标，而不是提示词。把检查者与制造者分开。给它记忆。然后让开。 ## 提示词 ```plaintext Run these as parallel, isolated sub-agents, each in its own worktree: 1. [agent A task, e.g. fix the failing auth tests] 2. [agent B task, e.g. update dependency X] 3. [agent C task, e.g. unify duplicated validation logic] Rules: - Each agent works only inside its own checkout. - No agent may modify files outside its assigned scope. - Report back only when each one is verified by the gate, not merely when it claims to be "done." - If two agents need to touch the same file, flag it as a conflict and escalate instead of guessing. ``` ```plaintext Run skill "[name]" on a weekly schedule. Trigger: [schedule / new file / webhook event] On each run: 1. Execute the full workflow 2. Apply constraints from CLAUDE.md 3. Verify against the goal 4. Deliver output + diff vs last run Only ping me if a deviation crosses [threshold]. Otherwise update STATE.md and archive the run. ``` ```plaintext Review everything the verifier rejected across the last [N] runs. Group the rejections by root cause. For each recurring cause, write one hard rule into CLAUDE.md using this format: # CONSTRAINTS.md - loaded automatically - [rule distilled from the rejection, written as a direct instruction] - [another rule] - Scope-lock: do not touch anything outside the task's stated scope. Do not just fix the individual output. Bake the lesson into the file every future run reads first. Then re-run the last failed task with the new constraints applied and confirm the rejection no longer triggers. ``` ```plaintext Before starting any new work, read STATE.md in full. Update it after every run with: ## Last run [timestamp] - [summary of what happened] ## Completed - [task, commit hash if relevant] ## In progress - [task, current status] ## Escalated to human - [task, reason it could not be resolved autonomously] ## Lessons learned (write here, not in chat) - [any rule worth promoting to CLAUDE.md] Never start a new run without reading this file first. ``` ```plaintext You are the VERIFIER, not the author. A different agent wrote the attached work. Your only job is to find what is wrong. Do not praise it. Do not summarize what it does well. Check against these criteria: - [criterion 1] - [criterion 2] - [criterion 3] For each: output PASS or FAIL with the exact line or reason. If everything passes: APPROVED. If anything fails: REJECTED + the single most important fix first. ``` ```plaintext Using the GitHub connector: scan open issues labeled "bug" from the last 7 days. For any issue where the fix is a single, testable change: 1. Create a branch named claude/fix-[issue-number] 2. Implement the fix 3. Run the test suite 4. If tests pass, open a PR linking back to the issue 5. Post a summary comment on the issue For anything riskier: leave a comment explaining why it needs a human. Do not open a PR. ``` ```plaintext Add a permanent rule to CLAUDE.md based on the mistake you just made. Write it as a short, direct instruction a future session will follow. Not a description of what happened. Format: - MISTAKE: [one line] - RULE: [the exact behavior to do instead, every time] Then confirm the file was updated. ``` ```plaintext Set up a recurring loop: Cadence: every [30 minutes / morning / on new commit] Goal: [the condition that means done for this cycle] On each run: 1. Read STATE.md first 2. Check for new work matching the scope 3. Do the work 4. Run the verification gate 5. Update STATE.md with results 6. Stop Notification rules: - If goal is met silently: just archive. - If a blocker appears: ping me with [channel/method]. - If token spend exceeds [N] this cycle: pause and report. Do not wait for my input between steps. ``` ```plaintext I want to add a second parallel loop alongside the one already running. Existing loop: [name / purpose of loop 1] New loop: [purpose, e.g. hunt for duplicated code to unify] Rules: - Keep them in separate worktrees. - Both write to the same STATE.md but in clearly separate sections. - Each loop has its own verification gate. - If both loops try to touch the same file in the same cycle, the second one yields and logs the conflict. - Report a combined summary at the end of each cycle. ``` ```plaintext You will work in a loop until the task meets the bar below. Do not ask me questions. Make a sensible assumption and continue. TASK: [describe exactly what you want produced] DONE MEANS (be strict, all must hold): - [condition 1, e.g. all tests in test/auth pass] - [condition 2, e.g. lint is clean] - [condition 3, e.g. no function longer than 40 lines] EVERY TURN: 1. State the one next step. 2. Do it. 3. Check your result against DONE MEANS. List what still fails. 4. If everything holds, print FINAL and stop. If not, fix the weakest point and go again. ``` 标签：# X # Claude # Loops # MCP # Automation # Guide 相关文章 循环工程：从提示词使用者到循环设计者的 14 步路线图 /loop 30m /goal test/auth 中的所有测试通过且 lint 干净 Claude Automation Loops MCP 我如何用 Claude 做到每月 200,000 美元（完整指南） 我们的应用目前每周营收 50,000 美元。 Claude MCP Automation UGC 图工程（Graph Engineering）在 Microsoft、Stanford 和 Anthropic 取代了 RAG。它是这样工作的。 收藏并关注——我是 Sprytix，一名开发者，构建能把技术变成真实收入的 AI 系统和自动化流水线。私信开放。 Claude AI MCP Automation