Master Loop Engineering: 6 Practical Scenarios to Double Your AI Productivity

过去两年，99%的人用 AI 写代码、写东西，大概都是这样：写个 prompt，等它回，读一遍，再补一句，继续等。人一直握着工具，一回合一回合往前推。

到了 2026 年年中，大家开始聊另一件事情了。OpenClaw 作者 Peter Steinberger 发了一条两百多万阅读的推：「你不该再去 prompt 你的编程 agent 了，你该去设计那些替你 prompt agent 的循环。」Anthropic Claude Code 负责人 Boris Cherny 也讲到类似经验：「我已经不 prompt Claude 了，我有一堆 loop 在跑，是它们在 prompt Claude、在决定下一步。我的工作是写 loop。」随后 Addy Osmani 把这件事命名为 Loop Engineering（循环工程）。

说得直白一点：

Loop Engineering，就是从“自己一句句去 prompt”转到“设计一套会继续 prompt 的系统”。

人的价值没有消失，只是位置变了。一头是意图：把“我到底要什么”说到可以验收。一头是担责：跑出来的东西，最后算在你头上。中间那些反复问、反复查、反复改的步骤，可以交给循环。

这事已经没那么折腾了。一年前你想要个 loop，常常要攒一摞只有自己看得懂的 bash。到 2026 年中，Claude Code、Codex、OpenCode 已经把不少零件做进产品里。看懂 loop 的形状，比纠结工具名更重要。

**

一、Loop 是什么

要理解循环工程，先看它在谱系里的位置。这几年杠杆点一直在往离“裸模型调用”更远的地方移：

它和 cron 定时任务的差别，在于里面多了一个会判断下一步的 agent。cron 跑写死的脚本；循环会看当前状态，挑动作，执行，检查结果，再决定继续、重试、回滚或停止。这个“观察、决策、行动、验证”（observe-decide-act-verify）就是循环的内核。主流 AI 厂商最后都靠近了这个结构，源头可以追到 2022 年普林斯顿和 Google 的 ReAct 框架（推理与行动交替）。

一个循环由什么组成：五个部件和一个状态层

第六个最容易被新手跳过。模型每次跑完都会忘，状态文件就是让今天这次运行知道昨天干了什么的办法。少了它，很多系统看似在循环，其实只是在重复同一个第一步。

记住这个六件套的形状，忘掉每一个具体命令键，你就学会了循环工程；反过来背熟命令键、错过形状，你只学会了这个月的 CLI。

**

二、怎么判断一个活该不该做成 loop

不要把所有活都做成循环。先过三道筛子：

• 重复：你做得够频繁，设计这套系统的成本能赚回来。
• 可验：“做完了”能写成一个 agent 或验收子 agent 真能跑的检查。说不清“通过长什么样”，循环就不知道何时该停。
• 值得：产出对得起烧的 token。循环有时间和金钱的底价，琐碎小活不够格。

三条都满足，它想要一个循环；缺一条，老老实实手动 prompt 或写个普通脚本更划算。

另一个判断角度，是看这活属于哪种工作结构：

• 流程型：步骤已知、顺序已知、结果可预测（发票进来→匹配→付款）。画成流程图没有任何决策分叉，用传统自动化（脚本、RPA）就行，不需要循环。
• 工具辅助型：目标已知，但路径多变。你问、它答、你定夺，人还在方向盘上。这是今天大多数 AI copilot 的位置。
• 目标驱动型：你定个目标、画个边界，让系统自己摸出步骤，评估、决策、行动、检查，重复到完成，或者把高风险事项交给人。这一类才适合循环。

更值得判断的问题是：“哪些地方需要装一个会判断下一步的循环？”

**

三、手把手搭你的第一个循环

前面讲的是形状。这里直接搭一个最常见的“晨间维护循环”。你可以照着在一个 throwaway 测试仓库里试，第一次别对着重要仓库跑，循环会自己改文件。

成品大概长这样：

1每个工作日早上 9 点：           # ① 心跳
2  读 progress.md               # ⑥ 状态文件（记忆）
3  找昨夜的 CI 失败 + 新 issue   # 要干的活
4  对每一条：
5    在独立 checkout 里起草修复   # ② Worktree
6    用项目的 triage 技能         # ③ Skill
7    让一个单独的 reviewer 打分    # ⑤ 子 agent（做/检分离）
8    PASS：开 PR                  # ④ 连接器
9    有风险：写进 progress.md 留给人
10  更新 progress.md             # ⑥ 状态文件

然后逐件拼。

第 0 步：选一个活，并把“完成”写成能被验证的条件

这是全场最难的一步。“把代码改好”太虚，“test/auth 全过且 npm run lint 干净”才够用。把停止条件写成验收单，四个字段尽量都补上：

agent 还是那个执行者，你写的是它必须通过的那张验收单。

第 1 步：装上心跳，让它自己启动

心跳有四种，从“停在这次会话里”到“完全没你也跑”。按需要选：

① 会话内循环（盯着看，关掉会话就停），适合盯一个长任务直到完成：

1# Claude Code：每 5 分钟跑一次，会话开着才有效
2/loop 5m 检查部署有没有跑完，跑完就告诉我结果
3
4# OpenCode：自己用 shell 当心跳（opencode run 跑完一句就退出）
5while true; do
6  opencode run "检查部署是否完成，完成就回 DONE"
7  sleep 300
8done

② 跑到达标为止，让循环自己判断何时停止：

1# Claude Code：给一个它自己输出能证明的条件
2/goal test/auth 下所有测试通过，且 npm run lint 干净。
3
4# OpenCode：用 shell + 退出码，让命令来判停
5for i in $(seq 1 8); do          # 一定要封顶，别无限跑
6  opencode run "让 test/auth 的测试通过，并修掉 lint 报错。"
7  if npm test -- test/auth && npm run lint; then
8    echo "第 $i 次达标"; break
9  fi
10done

/goal 好用的地方在这里：每回合结束后，一个单独的小模型读一遍记录，判断“达标没有”。写代码的那个 agent 不给自己判分。它没有内置的“试 N 次就放弃”，要封顶就写进条件里，比如“跑满 20 回合就停”。

③ 无人值守定时，你睡觉它也跑：

1# 自己机器上用 cron：每个工作日 9 点
20 9 * * 1-5 cd /path/to/repo && claude -p "查 CI 看板，总结失败项" >> ~/cron.log 2>&1
3
4# 同样一行，OpenCode 版
50 9 * * 1-5 cd /path/to/repo && opencode run "查 CI 看板，总结失败项" >> ~/cron.log 2>&1

想要笔记本关着也跑，就用云端 routine（在 claude.ai/code/routines 建，跑在服务器上）或 GitHub Actions 的 schedule 触发。

④ 事件驱动，PR 打开、CI 挂了、消息到了就触发。比如一个 PR review 的 GitHub Action：

1on:
2  pull_request:
3    types: [opened, synchronize, reopened]
4# 触发后让 agent review 这个 PR 的 diff

给循环两个刹车：一个成功条件，一个上限。成功条件说明这事什么时候算完成；上限说明最多跑几次、几分钟、多少钱。少了上限，预算会被一个达不到的目标慢慢烧掉。

第 2 步：把步骤写进一个 skill，让循环 prompt 保持一行

凡是你每次都要重新解释的东西，都该进 skill。这样定时任务的 prompt 可以缩成一句“跑 daily-triage 技能”，细节留在版本控制里，谁都能改。一个真实可用的 SKILL.md：

1---
2name: daily-triage
3description: 晨间维护：读进度文件，收集昨夜 CI 失败、新 issue、审计告警，
4  起草安全修复（每个都由单独的 reviewer 检查），通过的开 PR，
5  有风险的写进进度文件留给人。用于每日定时维护循环。
6---
7# 每日 triage（按顺序做，别跳过进度文件，它是你唯一的跨次记忆）
8
9## 1. 先读记忆
10- 打开 progress.md，读“进行中”和“需要人”两节。
11- “已完成”里有的，不要重做。
12
13## 2. 找活（按序，最多取 5 条）
141. 上次记录之后失败的 CI。
152. 带 bug、maintenance 标签的 open issue。
163. npm audit（或本项目审计命令）的新告警。
17
18## 3. 逐条处理
19- 开一个独立 checkout：git worktree，或新分支 claude/<短slug>。
20- 起草解决“这一个”问题的最小改动，不要捆绑多个改动。
21- 把 diff 交给 reviewer agent，拿到结论再继续。
22
23## 4. 按结论决定
24- PASS 且低风险（不动公开 API、无数据迁移、不删文件）：开 PR，标题 fix: <一行>，关联 issue。
25- FAIL 或动到任何风险项：不开 PR，往 progress.md“需要人”追加一条，写清你试了什么、为什么停。
26
27## 5. 最后更新记忆
28- 完成项移到“已完成”并写上今天日期，保存 progress.md。
29
30## 铁律
31- 一次最多开 5 个 PR；绝不直接动 main，只用 claude/* 分支；拿不准就升级给人。

第 3 步：做/检分离，配一个 reviewer 子 agent

循环里很重要的一条：写活的 agent 不许给自己的活判分。模型给自己打分时经常太宽。配一个单独的、只读的、常用更便宜模型的 reviewer，它跑测试、对照规范，只回 PASS 或 FAIL：

1---
2name: reviewer
3description: 对照 spec 和测试结果检查 diff，回 PASS 或 FAIL 并给理由，不做任何改动。
4tools: Read, Bash(npm test*), Bash(npm run lint*), Bash(git diff*)
5model: claude-haiku-4-5
6---
7你是一个严格的只读 reviewer，从不改文件。
81. 自己跑测试和 linter，亲自读输出，别信“它说通过了”。
92. 对照 CLAUDE.md 里的项目约定和相关 spec 检查改动。
103. 找 bug、漏掉的边界情况、安全风险、对公开行为的改动。
11然后只回其中一个：
12- PASS：后跟一行你验证了什么。
13- FAIL：后跟具体理由，一行一条。
14“看起来没问题”不算 PASS。测试必须真的过，且改动只做了被要求的事。

子 agent 更费 token，每个都跑自己的模型和工具。把它花在值得第二意见的地方，比如任何会在你不盯着时提交东西的循环；只读的小杂活就别配了。

第 4 步：装上状态文件

模型每次跑完就忘，记忆必须放在模型之外、放在磁盘上。可以分两层：一层是规则文件（CLAUDE.md、AGENTS.md，记录稳定习惯，保持短，因为每次读都要花钱）；一层是进度文件，记“试了什么、过了什么、还开着什么”：

1<!-- progress.md：循环的跨次记忆 -->
2## 已完成
3- 2026-06-22：修了 test/auth 的 flaky 测试（token 刷新时重试）
4## 进行中
5- 依赖审计：7 个告警修了 3 个；lodash 升级遇到一个 API 变更
6## 需要人
7- 图像库 CVE-2026-xxxx：修复会改输出格式，升级给维护者

习惯就一条：每次跑，开头读它，结尾更新它。当循环反复犯同一个错，别急着写更玄的 prompt，把教训写进规则文件，让后面的每一次运行都能读到。

第 5 步：接上工具，让它能动手

只能读文件的循环只会“说”。连接器（基于 MCP）让它开 PR、更新工单、发 Slack、查库、调 staging API。一个系统只能说“这是修复方案”，另一个系统能在测试通过后开 PR、关联工单、发频道，差别就在这里。把你手动用的那些连接器，加进定时或云端 routine 的连接器清单即可。

把六件拼起来：一个真实早晨

你把上面这些设计一次。某个早晨醒来，记录可能是这样：

1[09:00] daily-triage 触发
2  → 读 progress.md：1 项还在进行（lodash），无新标记
3  → 发现：昨夜 2 个 CI 失败、1 个新 npm-audit 告警
4  → CI 失败 #1（flaky auth 测试）：
5        在 claude/fix-auth-retry 分支起草修复
6        reviewer → PASS（测试绿；token 刷新重试；无 API 改动）→ 开 PR #142
7  → CI 失败 #2（report.ts 类型错）：
8        起草修复 → reviewer → PASS → 开 PR #143
9  → 告警（图像库）：安全修复会改输出格式
10        reviewer → FAIL（公开行为变更）→ 写进 progress.md“需要人”，不开 PR
11  → 更新 progress.md，退出
12[你，09:30] 两个待 review 的 PR，一个要拍板的事项。你一个字没敲。

这就是循环工程在干的事：找活、起草、检查，把安全的部分发出去，只把真正需要人的决定交到你手里。Claude Code 和 OpenCode 的差别，主要在心跳和运行位置；中间的 skill、状态文件、worktree、做/检分离、连接器，设计思路差不多。

**

四、它能省下哪些重复劳动

骨架学会了，就可以把“晨间维护”这套东西搬到别的活上。别急着扩大范围，先问一句：产出能不能被命令、清单或另一个 agent 验收？

代码与工程类

可以交出去的活：每天扒 CI 失败、给 issue 分诊、修一类反复出现的 bug、跑依赖升级、做框架迁移、逐个 review PR。

做法基本沿用晨间维护循环。常见变体有几种：

• “跑到测试通过为止”：/goal test/auth 全过且 lint 干净，让小模型判停。
• 框架/API 迁移（清空队列模式）：找下一个还在用旧 API 的文件，迁到新写法，跑测试，停止条件是“没有文件再匹配旧写法”，封顶 200 次。
• 安全漏洞规模化：这类已有公开案例，比如某浏览器一个月提交 423 个安全修复。关键不只在模型能力，也在外层结构：先用一个简单的 LLM 评委给每个文件打分（出内存安全问题的可能性 × 从网页触发的难易度）排优先级；agent 可以连续尝试很多办法去触发一个 bug；验证再分两段，先触发真实崩溃，再让 verifier 确认报告合理。误报会少很多。同一结构也能用于性能优化、技术债。

内容流水线类

可以交出去的活：批量清洗文案、把粗想法变 hook、把一篇长内容拆成多平台版本、按缺口批量生成文章。

这里要把“完成态”写成数得出来的检查。比如：

1/goal 把 captions.txt 里每条改写到 150 字内、不带话题标签，全部改完为止，
2      别动其他文件，最多 30 回合。      # 可验收：0 条超 150 字或含 #
3
4/goal 把 ideas.txt 里 20 个粗想法各改成一个 10 词内的 hook，全做完为止。
5                                       # 可验收：20 条全部改写完

更大的形态是多 agent 流水线：一个 agent 按内容缺口生成配图文章并排版，一个 agent 推送发布。但这里要清醒一点。模型越强，瓶颈越像指挥者的品味。循环会放大你写进 rubric、skill、验证步骤里的判断；判断糊了，它只是更快地生产一堆你不该发的东西。

信息监控与研究类

可以交出去的活：盯日志、盯服务健康、盯竞品定价页、盯 API changelog、盯一个领域的新闻、做一轮竞品调研。

按触发方式，可以分四种：

• 心跳：短间隔持续跑。每 5 分钟查 staging 错误日志，错误率超 1% 就开 issue。
• 定时：固定时间跑批。每工作日 10 点 review 所有超 3 天的 PR，逐个总结阻塞并 @ 作者。
• 钩子：事件触发跑一次。PR 推上来、CI 挂了、消息到了。
• 目标：迭代到达标才停，适合范围未知的任务。找出我们品类所有公开竞品，按这五个维度打分，起草定位简报。

还有一种办法，是把实时网页当心跳：监控一组 URL，内容一变就触发。定价页改了，启动竞品响应；changelog 更新了，触发文档重写；状态页出事，叫醒 on-call。个人场景里最轻的版本，就是晨间简报：每天早上读未读邮件，把最重要的 3 封各一行发我 Slack，别回任何东西。

文档生成类

可以交出去的活：把一摞 PDF 逐个写摘要、把零散数据整成结构化报告、按模板写提案/方案初稿、维护一份会过时的文档。

核心是“清空队列 + 反思、多 agent 检查”：

1/goal 给 reports 文件夹每个 PDF 写 5 行白话摘要到 summaries.md，
2      每个都有为止，别改 PDF，最多 40 回合。  # 可验收：每个 PDF 都有对应摘要

按风险选循环模式：

• 反思 + schema 校验：起草结构化报告，对照 schema 补全缺字段，人最后过一遍。适合工地报告、表单类。
• 多 agent review + 人类闸门：A 起草，B 查规范、查合规、标出不该出现的敏感标识，人签字。适合诊疗方案、合规文档。
• 反思 + 清单校验：起草，对照方法论框架、字数格式和数据一致性检查，再标出需佐证的论断。适合提案。
• 带护栏的自治：逐条或逐批校验，只把没过自动检查的（通常 <5%）升级给人。适合数据批处理。

文档写手循环还能再套四层：① agent 干活（克隆仓库、读写文件、开 PR）；② 验证循环（一个 grader 跑检查，链接是否都通、CI 是否全绿、diff 是否只动了被要求的范围，不达标就带反馈打回）；③ 事件循环（某频道一来消息就触发）；④ 改进循环（拿运行记录喂分析 agent，自动改进 prompt 或工具配置）。

个人事务与办公

可以交出去的活：清理爆满收件箱、每月那份你一想到就头疼的报告、客服工单清理。

做法也不用复杂。用“目标 + 定时器”拼第一个自治 agent，不用写代码。建一个 routine：“每天早上读未读邮件，最重要的 3 封各一行发我 Slack，别回任何东西”，连上 Gmail/Slack，设每天 9 点。进阶时再加一个 skill，里面写你的处理方法；再加一个独立 checker，比如它判断某个被自动关闭的工单该留给人，就重新打开。

安全建议很简单：先只读。让它先“总结、汇报”跑几天，用大白话设死限制（“不许回复”“不许删除”），看着头几次跑，再让它动手。

商业与运营

替你处理：那些本来周期性做、其实该连续做的决策。定价每季度看一次竞品再调，HR 每年调研一次半年后才行动，产品每 sprint 按上月数据排一次优先级，这些都可以重新看。

做法是从“能力地图”升级成“循环地图”。对每项能力问：它是流程型（传统自动化）？工具辅助型（给人配更好工具）？还是目标驱动型（部署一个有边界、有升级触发、有人类监督的循环）？把“定价信号每天评估、实时建议”“持续追踪早期流失、在人递辞呈前标出干预点”这种位置识别出来。真正的价值，常常来自一个原本不存在的决策循环，或者把慢的季度循环改成更快的连续循环。

也要记得行业现实。Gartner 预测到 2027 年底，超过 40% 的 agentic AI 项目会被砍掉，原因是成本失控、价值不清、风控不足。很多问题都指向同一件事：把 agent 硬塞进碎片化流程，却没想清楚循环该装在哪、需要什么才能跑。

**

五、风险与边界

循环改变了工作方式，但没把你从工作里删掉。循环越强，下面三个问题越绕不开。

1. 让循环停下来很难。每个循环都得带硬刹车，三道闸尽量都要有：

• 迭代次数硬上限：跑不动的循环不能一直转；
• 无进展检测：最近几轮没有任何变化，就停；
• token、美元预算上限：账单失控前先停。

三者缺一，账单就容易失控。一个朴素的成本感：一拍（maker + checker）约读 4 万、写 6 千 token，按 Sonnet 4.6 价约 0.2 美元一拍；一天 5 拍、一月 20 天约 20 美元，便宜。同一循环改成全天每 5 分钟一拍，拍数上百倍，轻松破 1000 美元一月，却未必多产出价值。真正花钱的是频率。省钱三招：模型分级（强模型规划与检查、便宜模型干活，这是最大头的省）、prompt 和规则文件保持短、降低频率（每小时一次比每 5 分钟一次便宜约 12 倍）。

1. 验证还是你的活。无人值守地跑，也会无人值守地犯错。把做和检拆开，是为了让“做完了”有点分量；但“done”只是声明，还得看证据。读循环开的 diff，对它产出的代码负责。最诚实的 checker 是测试 runner 和 linter，命令没法说服自己“这活挺好”。
2. 理解会慢慢变薄。循环把你没写的代码更快送进仓库，“仓库里有什么”和“你真正理解什么”之间的缺口会变大（comprehension debt，理解债）。循环跑起来以后，人也容易照单全收（cognitive surrender，认知投降）。同样是设计循环，带着判断去做，它会帮你把熟悉的工作推进得更快；为了逃避思考去做，它会把你推到更陌生的地方。循环分不出这两种情况，人得自己分。

**

六、上手节奏：一阶一阶赚信任

不要追求一步到位，一步跳到“自动合并”。按成熟度阶梯，一次爬一格。当前这格产出的东西，已经是你本来也会手动接受的结果，再往上走。

放手前的最小安全清单有七样：成功条件、上限（次数、分钟、花费）、隔离分支或 worktree、只读的 checker、状态文件、人类闸门（风险或失败的活交给人，绝不直推 main）、日志或通知（夜里出事要看得见）。缺一样，循环就容易不安全、健忘，或者出了事没人知道。

一个好记的公式：

AI 杠杆 = 你的技能 × 你的清晰度

清晰度：把“完成长什么样”定义清楚的能力。

技能：review 产出、改进循环的能力。

**

每一年，工具都会吸收掉更多机械部分：编排、检查、调度。去年还要靠自己的 shell 脚本，今年变成内置的 /goal、routine、dynamic workflow。但工具吸收不掉两端的东西：意图（说清楚到结果可被验收）和担责（对发出去的东西负责）。这也是它叫“工程”的原因。

去搭你的循环，把那些重复、可验的活交出去。但要像一个打算继续当工程师的人那样去搭它。读循环写出来的东西，对质量负责，写好 skill，定义好停止条件。

循环可以让你在已经理解的工作上更快，也可以帮你逃开那些本该理解的部分。选哪条路，工具不会替你决定。

关于作者

Kyrie — 前国内大厂 R&D 工程师，现居曼谷，做中国科技企业出海 BD。持续分享出海一线真实记录、AI 在业务里的实战用法，偶尔也聊聊美股投资和国外生活。

• X：.@KyrieCheungYep