用好 Loop 能让你事半功倍，六个实战场景教你驾驭循环工程

过去两年，绝大多数人使用AI的方式是这样的：写一句提示词，等待回应，读一遍，再补一句，继续等待。人一直握着工具，一回合一回合地往前推。

但到了2026年，风向变了。OpenClaw的作者Peter Steinberger发了一条阅读量超过两百万的推文：“你不该再去提示你的编程助手了，你该去设计那些替你提示助手的循环。”Anthropic Claude Code的负责人Boris Cherny也分享了类似的实践：“我已经不直接提示Claude了，我有一堆循环在跑，是它们在提示Claude、在决定下一步。我的工作是写循环。”随后，Addy Osmani把这件事命名为循环工程。

循环工程的核心，就是从“自己一句句去提示”转到“设计一套会持续提示的系统”。

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

一、循环到底是什么？

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

循环工程在技术谱系中的位置示意图

循环和cron定时任务的区别在于，循环里面多了一个会判断下一步的智能体。cron执行的是写死的脚本；循环会观察当前状态，挑选动作，执行，检查结果，再决定是继续、重试、回滚还是停止。这个“观察、决策、行动、验证”的过程，就是循环的内核。主流AI厂商最终都靠近了这个结构，其源头可以追溯到2022年普林斯顿大学和Google提出的ReAct框架——推理与行动交替进行。

一个循环由什么组成

一个完整的循环由五个部件和一个状态层构成：

循环工程的六件套结构图

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

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

二、怎么判断一个活该不该做成循环？

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

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

三条都满足，它适合做成一个循环；缺一条，老老实实手动提示或写个普通脚本更划算。

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

流程型：步骤已知、顺序已知、结果可预测。比如发票进来→匹配→付款。画成流程图没有任何决策分叉，用传统自动化（脚本、RPA）就行，不需要循环。

工具辅助型：目标已知，但路径多变。你问、它答、你定夺，人还在方向盘上。这是今天大多数AI辅助工具所处的位置。

目标驱动型：你定个目标、画个边界，让系统自己摸索出步骤，评估、决策、行动、检查，重复到完成，或者把高风险事项交给人。这一类才适合做循环。

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

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

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

成品大概长这样：

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

然后逐步拼装。

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

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

验收条件定义模板图

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

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

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

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

# Claude Code：每 5 分钟跑一次，会话开着才有效
/loop 5m 检查部署有没有跑完，跑完就告诉我结果

# OpenCode：自己用 shell 当心跳（opencode run 跑完一句就退出）
while true; do
  opencode run "检查部署是否完成，完成就回 DONE"
  sleep 300
done

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

# Claude Code：给一个它自己输出能证明的条件
/goal test/auth 下所有测试通过，且 npm run lint 干净。

# OpenCode：用 shell + 退出码，让命令来判停
for i in $(seq 1 8); do          # 一定要封顶，别无限跑
  opencode run "让 test/auth 的测试通过，并修掉 lint 报错。"
  if npm test -- test/auth && npm run lint; then
    echo "第 $i 次达标"; break
  fi
done

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

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

# 自己机器上用 cron：每个工作日 9 点
0 9 * * 1-5 cd /path/to/repo && claude -p "查 CI 看板，总结失败项" >> ~/cron.log 2>&1

# 同样一行，OpenCode 版
0 9 * * 1-5 cd /path/to/repo && opencode run "查 CI 看板，总结失败项" >> ~/cron.log 2>&1

想要笔记本关着也跑，就用云端例行程序（runroutine.io）或 GitHub Actions 的 schedule 触发。

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

on:
  pull_request:
    types: [opened, synchronize, reopened]
# 触发后让智能体 review 这个 PR 的 diff

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

第2步：把步骤写进一个技能（skill），让循环提示保持一行

凡是你每次都要重新解释的东西，都应该放进技能文件里。这样定时任务的提示可以缩成一句“跑 daily-triage 技能”，细节留在版本控制里，谁都能改。

一个真实可用的 SKILL.md 示例：

---
name: daily-triage
description: 晨间维护：读进度文件，收集昨夜 CI 失败、新 issue、审计告警，
  起草安全修复（每个都由单独的 reviewer 检查），通过的开 PR，
  有风险的写进进度文件留给人。用于每日定时维护循环。
---
# 每日 triage（按顺序做，别跳过进度文件，它是你唯一的跨次记忆）

## 1. 先读记忆
- 打开 progress.md，读“进行中”和“需要人”两节。
- “已完成”里有的，不要重做。

## 2. 找活（按序，最多取 5 条）
1. 上次记录之后失败的 CI。
2. 带 bug、maintenance 标签的 open issue。
3. npm audit（或本项目审计命令）的新告警。

## 3. 逐条处理
- 开一个独立 checkout：git worktree，或新分支 claude/<短slug>。
- 起草解决“这一个”问题的最小改动，不要捆绑多个改动。
- 把 diff 交给 reviewer 智能体，拿到结论再继续。

## 4. 按结论决定
- PASS 且低风险（不动公开 API、无数据迁移、不删文件）：开 PR，标题 fix: <一行>，关联 issue。
- FAIL 或动到任何风险项：不开 PR，往 progress.md“需要人”追加一条，写清你试了什么、为什么停。

## 5. 最后更新记忆
- 完成项移到“已完成”并写上今天日期，保存 progress.md。

## 铁律
- 一次最多开 5 个 PR；绝不直接动 main，只用 claude/* 分支；拿不准就升级给人。

第3步：做检分离——配一个 reviewer 子智能体

循环里很重要的一条原则：写代码的智能体不许给自己的活判分。模型给自己打分时经常过于宽松。需要配一个单独的、只读的、通常用更便宜模型的reviewer，它负责跑测试、对照规范，只回答PASS或FAIL：

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

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

第4步：装上状态文件

模型每次跑完就忘，记忆必须放在模型之外、放在磁盘上。可以分两层：

  • 规则文件（CLAUDE.md、AGENTS.md）：记录稳定习惯，保持简短，因为每次读都会产生费用
  • 进度文件：记录“试了什么、过了什么、还开着什么”
<!-- progress.md：循环的跨次记忆 -->
## 已完成
- 2026-06-22：修了 test/auth 的 flaky 测试（token 刷新时重试）
## 进行中
- 依赖审计：7 个告警修了 3 个；lodash 升级遇到一个 API 变更
## 需要人
- 图像库 CVE-2026-xxxx：修复会改输出格式，升级给维护者

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

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

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

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

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

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

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

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

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

代码与工程类

可以交出去的活：

  • 每天排查CI失败
  • 给issue分诊
  • 修一类反复出现的bug
  • 跑依赖升级
  • 做框架迁移
  • 逐个review PR

常见变体：

  • “跑到测试通过为止”：/goal test/auth 全过且 lint 干净，让小模型判停
  • 框架/API迁移（清空队列模式）：找下一个还在用旧API的文件，迁到新写法，跑测试，停止条件是“没有文件再匹配旧写法”，封顶200次
  • 安全漏洞规模化：先用一个简单的LLM评委给每个文件打分（出内存安全问题的可能性 × 从网页触发的难易度）排优先级；智能体可以连续尝试多种办法去触发一个bug；验证再分两段，先触发真实崩溃，再让验证器确认报告合理。同一结构也能用于性能优化和技术债

内容流水线类

可以交出去的活：

  • 批量清洗文案
  • 把粗想法变成吸引人的开头
  • 把一篇长内容拆成多平台版本
  • 按缺口批量生成文章

这里要把“完成态”写成可以数得出来的检查：

/goal 把 captions.txt 里每条改写到 150 字内、不带话题标签，全部改完为止，
      别动其他文件，最多 30 回合。      # 可验收：0 条超 150 字或含 #

/goal 把 ideas.txt 里 20 个粗想法各改成一个 10 词内的 hook，全做完为止。
                                       # 可验收：20 条全部改写完

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

信息监控与研究类

可以交出去的活：

  • 盯日志、盯服务健康
  • 盯竞品定价页
  • 盯API变更日志
  • 盯一个领域的新闻
  • 做一轮竞品调研

按触发方式分四种：

触发方式 说明 示例
心跳 短间隔持续跑 每5分钟查staging错误日志，错误率超1%就开issue
定时 固定时间跑批 每工作日10点review所有超3天的PR
钩子 事件触发跑一次 PR推上来、CI挂了、消息到了
目标 迭代到达标才停 找出品类所有公开竞品，按五个维度打分，起草定位简报

还有一种办法，是把实时网页当心跳：监控一组URL，内容一变就触发。定价页改了，启动竞品响应；changelog更新了，触发文档重写；状态页出事，叫醒on-call。

文档生成类

可以交出去的活：

  • 把一摞PDF逐个写摘要
  • 把零散数据整理成结构化报告
  • 按模板写提案/方案初稿
  • 维护一份会过时的文档

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

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

按风险选循环模式：

  • 反思 + schema校验：起草结构化报告，对照schema补全缺字段，人最后过一遍
  • 多智能体review + 人类闸门：A起草，B查规范、查合规，人签字
  • 反思 + 清单校验：起草，对照方法论框架检查，标出需佐证的论断
  • 带护栏的自治：逐条校验，只把没过自动检查的（通常<5%）升级给人

个人事务与办公

可以交出去的活：

  • 清理爆满的收件箱
  • 每月那份想到就头疼的报告
  • 客服工单清理

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

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

商业与运营

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

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

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

五、风险与边界

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

1. 让循环停下来很难

每个循环都得带硬刹车，三道闸尽量都要有：

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

三者缺一，账单就容易失控。一个朴素的成本感：一拍（maker + checker）大约读4万token、写6千token，按Sonnet 4.6价格约0.2美元一拍；一天5拍、一月20天约20美元，还算便宜。同一循环改成全天每5分钟一拍，拍数上百倍，轻松破1000美元一月，却未必多产出价值。

真正花钱的是频率。 省钱三招：

  • 模型分级（强模型规划与检查、便宜模型干活——这是最大头的省）
  • prompt和规则文件保持简短
  • 降低频率（每小时一次比每5分钟一次便宜约12倍）

2. 验证还是你的活

无人值守地跑，也会无人值守地犯错。把做和检拆开，是为了让“做完了”有点分量；但“done”只是声明，还得看证据。读循环开的diff，对它产出的代码负责。 最诚实的checker是测试runner和linter，命令没法说服自己“这活挺好”。

3. 理解会慢慢变薄

循环把你没写的代码更快送进仓库，“仓库里有什么”和“你真正理解什么”之间的缺口会变大——这叫理解债。循环跑起来以后，人也容易照单全收——这叫认知投降。

同样是设计循环，带着判断去做，它会帮你把熟悉的工作推进得更快；为了逃避思考去做，它会把你推到更陌生的地方。循环分不出这两种情况，人得自己分。

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

不要追求一步到位，直接跳到“自动合并”。按成熟度阶梯，一次爬一格：

循环工程成熟度阶梯图

当前这格产出的东西，已经是你本来也会手动接受的结果，再往上走。

放手前的最小安全清单

序号 安全措施
1 成功条件
2 上限（次数、分钟、花费）
3 隔离分支或worktree
4 只读的checker
5 状态文件
6 人类闸门（风险或失败的活交给人，绝不直推main）
7 日志或通知（夜里出事要看得见）

缺一样，循环就容易不安全、健忘，或者出了问题没人知道。

一个好记的公式

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

  • 清晰度：把“完成长什么样”定义清楚的能力
  • 技能：review产出、改进循环的能力

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

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

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