Loop Engineering——直译叫“循环工程”，听起来像编译器课本里的东西，但它说的其实很朴素：不要每一步都靠人手打一条提示词，而是设计一个能自己反复触发、自己找活、自己检查、自己记录进度的工作循环。

过去大家争的是“怎么写出神级提示词”，现在一些用得比较深的人开始说，真正要设计的，已经不只是 prompt，而是让 agent 持续工作的那套系统。

听着有点绕，换成人话就是：以前你像坐在副驾驶，一路告诉 AI“左转、直走、查这个文件、改那段代码”；现在你更像在搭一条小流水线，告诉它什么时候开工、去哪找任务、找谁检查、做到哪一步必须停下来找你。

这就是 loop。

一、Loop 不是更长的提示词，而是让 AI 定期回来干活

先说几个常用的概念：

提示词像一次派单。你说“帮我总结这篇文章”，AI 做完就结束。

Agent像一个会用工具的员工。你说“修这个 bug”，它会读文件、跑测试、改代码、再跑测试。

Loop则像一套值班制度。它不只处理眼前这张单，还知道“每天早上检查 CI”“每 30 分钟看一次 PR 有没有新评论”“如果测试失败就开一个隔离分支尝试修复”“修不了就写清楚原因等人来接”。

差别就在这里：prompt 是你说的一句话，agent 是那个帮你干活的人，loop 是一套让它反复回来干活的安排。

Addy Osmani 在《Loop Engineering》里把这个变化说得很直接：loop engineering 的重点，是把你自己从“持续提示 agent 的人”换成“设计这个提示系统的人”。这个系统会找工作、分派工作、检查工作、记录结果，然后决定下一步。

所以 loop 只是把我们平时自动化脚本说的那些规则，提前写清楚，让 AI 可以照着长期执行。

二、一个能跑起来的 loop，通常要想清楚六件事

1. 它什么时候开始干活

没有“什么时候开始”，就谈不上循环，最多只是一次性任务。

这个时间点可以很简单：

每天 9 点检查一次项目；
每 10 分钟看一次部署是否完成；
每次 PR 有新评论就醒来；
你手动输入 /goal，让它一直工作到满足退出条件。

在 Codex 里，Automations 可以按计划运行，也可以挂在当前线程上当“心跳”。官方文档里也提醒过，这类提示词要经得起反复运行：每次醒来做什么、什么时候汇报、什么时候停止，都要说清楚。

这一步很像闹钟。区别是普通闹钟叫醒你，loop 的闹钟叫醒 AI。

2. 它要记得上次做到哪了

这是很多人第一次做 loop 会漏掉的东西。

AI 单次对话可以很聪明，但你别指望它下周还记得“上次已经试过方案 B，失败原因是数据库迁移冲突”。所以，loop 最好有个地方专门记账。

最土的办法反而最好：一个 Markdown 文件————AI时代最重要的文件格式（另一个我觉得就是html）。

比如：

# triage-state

## 已处理

- 2026-06-22: 修复登录页移动端样式，PR #123，已合并

## 待处理

- CI 在 Windows 上失败，疑似路径分隔符问题

## 不要重复尝试

- 不要再升级 next-mdx-remote，当前版本受 Next 15 约束

这东西看起来很笨，但非常管用。模型会忘，仓库不会忘；对话会压缩，文件不会凭空消失。

3. 技能：别让它每次都重新猜你的规矩

如果你每次都要告诉 AI“我们项目怎么构建、文章怎么写、测试怎么跑、哪些目录不能碰”，那 loop 跑几次之后一定会变形。

所以要把稳定知识写成 skill。

在 Codex 里，skill 其实就是一个带 SKILL.md 的目录。你可以把这个工作流什么时候触发、要按哪些步骤走、能用哪些脚本和参考资料，都写进去。官方文档也把它当成一种沉淀可复用工作流的格式：说明、资源、脚本，都可以打包进去。

换个说法：prompt 是临场交代，skill 是岗位说明书。loop 跑得越久，越应该少靠临场交代，多靠岗位说明书。

4. 多个 AI 同时干活时，别让它们互相踩脚

一个 agent 干活时，最怕两件事：改错文件，和跟另一个 agent 同时改同一批文件。

所以 loop 一旦要并行，就要把工作区隔开。代码项目里最常见的是 git worktree：每个 agent 在自己的目录和分支里改，互不影响。一个负责修 CI，一个负责补文档，一个负责做安全审查，最后再由主线程汇总。

没有隔离的并行 agent，就像三个装修队同时冲进同一个厨房，谁都说自己是在帮忙，最后墙拆了、水管也断了。

5. 干活的人，最好不要自己检查自己

这是 loop 设计里最重要的一条。

让同一个模型先写代码、再评价自己写得好不好，效果通常会偏乐观。Addy 那篇文章里有一句很形象的话：写代码的模型太容易对自己的作业客气。

所以一个靠谱 loop 至少要拆出两个角色：

执行者：负责找方案、改文件、产出草稿；
检查者：负责按标准检查结果，最好只读、不改。

Codex 的 subagents 就是干这个的。官方文档里说，Codex 可以并行启动专门的子 agent，再把结果汇总回来；但它也提醒，每个 subagent 都会自己消耗模型和工具调用，所以成本会更高。

这点很关键：subagent 不是越多越好。它适合花钱买第二意见，不适合给每个小任务都拉一堆人开会。

6. 它要能接上真实工具

只会读本地文件的 loop，能做的事很有限。

真正有用的 loop 往往要接外部系统：GitHub、Linear、Slack、数据库、监控平台、文档库。这些连接器的意义不是让 AI “知道更多”，而是让它真的能在工作流里把事情做完。

比如一个 PR loop：

图示加载中…

这样才算真的跑进了工作流里。否则它只是在本地写了一篇“如果我能操作 GitHub，我会这么做”的作文。

三、普通用户怎么开始：先做一个小到不会出事的 loop

第一次别上来就设计“让 AI 每天维护整个公司代码库”。这太大了，也太容易出岔子。

更稳的起点，是找一个低风险、重复、结果也容易检查的任务。

比如：

每天总结过去 24 小时的项目提交；
每周整理一次收藏夹里的论文和文章；
每小时检查一次某个部署页面是否恢复；
每天把 issue 分成“可直接修”“需要产品决策”“信息不足”三类；
每周检查博客草稿里有没有断链、图片缺失、frontmatter 错误。

它们有三个共同点：

第一，输入稳定。 它知道去哪找材料。

第二，输出明确。 它知道最后要交一份什么东西。

第三，错了也不致命。 最坏就是报告写差了、分类分错了，你能改回来。

一个最小 loop 可以这样写：

每天下午 6 点检查这个仓库过去 24 小时的变化。

你要做三件事：

只读取 git log 和相关 diff，不修改文件。
按“功能变化 / 修复 / 风险 / 需要我决定的事”四类写一份简报。
如果没有值得报告的变化，就只回复“今天没有需要处理的项目变化”。

什么时候停：

简报已生成，或确认没有变化。

不能做的事：

不要提交代码。
不要推送。
不要调用外部服务。

这就是一个最小版 loop。它很小，但该有的东西都有：什么时候开始、看哪些东西、最后交什么、什么时候停、哪些事不能做。

等这个小 loop 稳了，再加 skill、连接器、检查者。不要一上来就把所有能力都塞进去。

四、设计 loop 时，先写“怎么才算做完”

很多 prompt 写不好，是因为目标含糊；很多 loop 跑坏，是因为没说清楚什么时候该停。

比如“帮我持续优化这个项目”就很危险。持续到什么时候？优化什么指标？能不能改架构？能不能删文件？测试失败了是继续试，还是停下来汇报？这些都没说。

一个好的 loop，应该先写清楚“什么叫做完了”。

比如不要写：

帮我把登录模块修好。

改成：

目标：修复登录模块里 expired token 导致用户被踢回首页的问题。

做完的标准：

新增一个覆盖 expired token 的测试；
相关测试通过；
lint 通过；
diff 只涉及登录、session 或测试文件；
最终说明根因、修改点、验证命令。

如果试了 3 次还是无法让测试通过，就停下来，不要继续硬改，把已经发现的问题告诉我。

这不是啰嗦。对 loop 来说，停止条件就是刹车。自动化没有刹车，跑得越快越危险。

五、写 loop 的时候，可以按四步来

我自己一般会把 loop 拆成四步：先找事，再动手，再检查，最后记录。

图示加载中…

第一步：它从哪里找活

发现阶段要尽量具体。

差的写法：

看看项目里有没有问题。

好的写法：

检查最近 24 小时内 main 分支新增的 CI 失败、GitHub issue 中带 bug 标签且无 assignee 的项目、以及最近一次构建日志里的错误。

AI 当然可以探索，但你得给它圈个范围。否则它每次醒来都像刚进公司第一天，东看看西看看，最后给你一份“我发现项目很复杂”的废话。

第二步：它能改哪些东西

能改什么、不能改什么，最好直接写清楚。

比如：

允许修改：

src/auth/**
tests/auth/**

不允许修改：

数据库迁移
支付相关代码
package-lock.json
环境变量和部署配置

不要只写“谨慎修改”。谨慎是态度，不是边界。

第三步：它怎么知道自己没搞砸

检查方式越接近你真实交付前会做的事，这个 loop 就越靠谱。

代码类任务可以是测试、lint、类型检查、截图对比、构建。写作类任务可以是来源链接、字数范围、引用检查、事实核对清单。运营类任务可以是表格字段完整、重复项检测、审批状态。

关键是：一定要让 loop 有东西可以检查。

Claude Code 官方文档里也有类似建议：给 Claude 一个可以验证的目标，它会做得更好。比如明确测试用例、期望截图、输出格式，而不是只说“写好一点”。

第四步：它下次怎么接着干

每次 loop 结束，都要留几句记录。

最简单可以要求：

结束前更新 loop-state.md：

本轮读取了哪些输入；
做了哪些改动；
跑了哪些验证；
哪些问题留到下轮；
哪些方向已经尝试失败，不要重复。

这一步能明显减少“AI 每次醒来都从头猜一遍”的情况。

六、什么时候别用 loop

Loop 很诱人，因为它看起来像“我睡觉，它干活”。但有些任务不适合。

一次性、高判断密度的任务，不适合。 比如公司战略、产品定位、关键技术选型。你可以让 AI 帮你研究，但不要让它无人值守地“持续推进”。

没法检查结果的任务，不适合。 如果你说“每天帮我把产品做得更好”，它只能瞎猜。没有指标，没有测试，没有用户反馈，这不叫 loop，只是把愿望说给 AI 听。

高风险的外部动作，不适合一上来就自动化。 发邮件、转账、删数据、改生产配置、公开发布内容，这些动作都应该默认需要人确认。AI 可以先帮你准备草稿，但不应该默认替你按下按钮。

成本收不住的任务，也不适合。 多 agent、长上下文、频繁定时，一起叠上去，token 会烧得很快。Business Insider 那篇报道里也把成本列成 loop 最大的担忧之一。Addy 的建议很实在：subagent 花的是钱，只有当“第二意见值得付费”时再开。

七、两个可以直接照着改的 loop 设计

例子一：代码仓库维护 loop

适合：个人项目、开源仓库、小团队工具库。

每天上午 9 点运行一次仓库维护 loop。

发现阶段：

查看过去 24 小时新增的 CI 失败；
查看 open issue 中 label=bug 且没有 assignee 的项目；
查看最近一次依赖更新引入的测试失败。

执行阶段：

对每个候选问题，先写入 maintenance-state.md；
只挑一个“范围小、可验证”的问题尝试修复；
在独立 worktree 中修改；
不修改部署、密钥、数据库迁移和支付逻辑。

验证阶段：

优先运行最小相关测试；
如果改动跨模块，再运行完整测试或构建；
让 reviewer subagent 只读检查正确性、回归风险和测试缺口。

什么时候停：

一个问题被修复并通过验证；
或没有低风险问题可做；
或连续 3 次尝试失败。

结束动作：

更新 maintenance-state.md；
汇报根因、diff 摘要、验证命令；
不自动推送，等待我确认。

这个 loop 不追求“一次干完所有活”。它只追求每天稳定解决一个小问题。长期看，这比一次性开十个 agent 到处乱改更有用。

例子二：写作研究 loop

适合：博客、Newsletter、行业报告、竞品追踪。

每周一上午 8 点运行一次 AI 工具动态研究 loop。

发现阶段：

只查官方博客、官方文档、论文和一手访谈；
最近 7 天内发布的内容优先；
二手媒体只能作为线索，不能作为唯一事实来源。

执行阶段：

把候选材料写入 research-state.md；
每条材料给出一句“为什么值得写”；
选出最多 3 个主题，不直接成稿。

验证阶段：

检查日期、数字、产品名称是否能回到原始来源；
如果来源不足，标成“待核实”，不要展开写。

什么时候停：

形成 3 个候选选题；
或确认本周没有值得写的材料。

结束动作：

给我一份选题清单；
不发布；
不改正式文章文件，除非我明确选择一个主题。

这个 loop 的重点不是“自动写文章”，而是帮你做选题雷达。让 AI 把重复的信息搜集和初筛吃掉，把判断权留给人。

八、真正难的不是让 loop 跑起来，而是让它别把你变懒

Loop Engineering 听上去像是 prompt engineering 的升级版，但我觉得它更像是在做管理。

你不再只问“这句话怎么写，模型更听话”，而是开始问：

这个任务值得重复自动化吗？
它从哪里拿输入？
它怎么判断自己做完了？
它失败时怎么停下来？
它能碰哪些系统，不能碰哪些系统？
它的状态放在哪里？
谁来复核它？

这些问题没有“提示词怎么措辞”听起来酷，但更重要。

AI agent 的底层循环其实一直都在那里：读取上下文、采取动作、观察结果、继续下一步。

图示加载中…

Claude Code 的官方文档就把它描述成 gather context、take action、verify results 的 agentic loop；一篇分析 Claude Code 架构的论文也指出，核心机制可以看成一个调用模型、运行工具、重复执行的 while-loop，真正复杂的是周围的权限、上下文、扩展、子 agent 和持久化系统。

换句话说，真正聪明的地方不只是模型本身，还包括你给它搭的那条轨道。

所以，别把 loop 当成“我终于可以不管了”。更准确的说法是：你从手动操作员，变成了流程设计者。以前你的价值体现在每一步怎么提示；现在你的价值体现在这套循环会不会找对事、守住边界、承认失败、留下记录。

Loop 的意义不是让人退出工作，而是让人把注意力从“下一条提示词怎么写”，挪到“这套系统到底值不值得信”。

这大概才是 Loop Engineering 真正有意思的地方：它不是让你不用思考，而是逼你把该想的事提前想清楚。