循环工程 Loop Engineering 指南：一个 Skill 解决终止条件设计难题

2026 年 6 月，循环工程（Loop Engineering）成了 AI 编程圈的中心词。Google Chrome 工程负责人 Addy Osmani 的一篇文章正式命名了这个概念；Claude Code 的创造者 Boris Cherny 说「我不再写提示词了，我的工作就是写循环」；开发者 Peter Steinberger 发了同样的观点，650 万人看了。

我拆解了 136 个开源循环，做了一个循环设计器（Skill），然后发现了一件事：循环工程的本质就是需求工程。

这篇文章讲清楚三件事：循环工程是什么、为什么大多数循环会失败、怎么设计一个真正能自己停下来的循环。

从提示词到循环：AI 编程的四个阶段

三年前我们在研究怎么写好一条 提示词（Prompt Engineering）。去年开始讨论 上下文工程（Context Engineering）——光写好指令不够，还得给够背景信息。今年年初，驾驭工程（Harness Engineering）成了新话题——光有好指令和好上下文还不够，得把工具、环境、验证机制全搭好。

到了 2026 年 6 月，循环工程进入主流视野。所有人都在讨论怎么让 AI 自己跑、自己验、自己停。

💡 通俗讲：提示词工程是「怎么跟 AI 说话」，上下文工程是「给 AI 看什么资料」，驾驭工程是「给 AI 配什么工具」，循环工程是「让 AI 自己反复干到达标为止」。

如果你正在用 Claude Code 或 Codex 写代码，或者想了解 Claude Code 的最佳实践，想让 AI 自己跑、自己检查、自己停下来，这篇文章就是写给你的。

循环工程的核心：终止条件

你以为你在设计循环，其实你在定义需求。「怎么让 Agent 自己停」这个问题，换个说法就是：你到底想让它做到什么程度？

每写十行 AI 代码，只有不到两行跑在用户面前——麻省理工的研究证实了这个比例。AI 写出的代码量增长了约 180%，但真正上线交付的只增长了约 30%。

180% 和 30% 之间那条鸿沟，就是「没人定义什么叫做完了」的代价。

这是循环工程和之前所有阶段最大的不同：前三个阶段优化的是「怎么让 AI 做得更好」，循环工程优化的是「怎么让 AI 知道什么时候该停」。

拆解 136 个开源循环后的发现

我把三个主流开源循环提示词库全部拉下来，逐个分析了里面的循环结构。三个库加起来，136 个循环。

ExplainX.ai 的循环库：100 个可复制的循环提示词，按 15 个分类组织。

Matthew Berman 的 Forward Future Loop Library：每个循环标注了验证条件和停止标准。

发现一：85% 只能用在代码类任务

代码有天然优势——跑一条命令就知道还剩几个错误，退出码为零就是做完了。但改文章、调设计、优化文案？三个库里几乎找不到能用的内容类循环。

这意味着：如果你的日常工作不全是写代码（大多数人不是），现有的循环模板帮不了你太多。

发现二：失败原因不是提示词差

反复看了很多份提示词，措辞清晰、结构完整。问题出在终止条件——要么没写，要么写了等于没写。

「优化代码直到没有问题」——什么叫没有问题？

「迭代改进直到满意」——谁满意？怎么算满意？

没有终止条件的循环，不是自动化，是让 AI 在黑暗中无限打转。

Reddit 上有个帖子写得直白：「说自己跑 500 个 AI 同时干活的人，要么在撒谎，要么省略了关键细节。」那个被省略的关键细节，就是终止条件。

终止条件的两种设计方式

第一种：有验证命令的任务

修类型错误，跑一条检查命令，零错误就停。测试全过就停。构建成功就停。

这是最简单的场景。Claude Code 的 /goal 命令就是这个机制——你设好一个目标条件，一个独立评估模型（不是执行模型本身）自动检查每一步是否达标，达标就停。

Claude Code 官方文档：/goal 命令设好终止条件后，独立评估模型自动检查每一步是否达标。

第二种：没有验证命令的任务

改文章语气、优化标题吸引力、调页面排版——这些是主观判断，没有一条命令能告诉你「做完了」。

这时候你需要事先拆出三到五个评判维度，每个维度定好权重和通过线，让 AI 每轮按维度打分。达标就停，不达标就继续——但每轮只改有限的几处，不全文推翻重来。

两种方式没有高下之分。区别只在一个判断：你的任务有没有一条命令能检查结果。

判断本身不难。落成可以直接运行的方案，才是真正的活。

💡 通俗讲：第一种就像考试有标准答案，对完答案就知道过没过；第二种就像面试，要事先定好评分表和及格线，评委打完分才知道结果。

最大的发现不在技术层面

最难的不是写提示词，是搞清楚自己到底想要什么效果。

提示词 5 分钟就能写完——「帮我优化这篇文章」，一句话的事。但「优化到什么程度」，想了一整晚。

是去掉 AI 味就够了？还是要连段落节奏、开头钩子、行动号召一起改？做到「读起来像人写的」就停，还是做到「放进公众号有传播力」才停？这两个标准差距巨大。

拿自己的一篇文章测试：

• 宽松标准——「去掉明显的 AI 痕迹」。两轮就停了，改了 6 处。AI 味确实淡了，但文章依然平。
• 精确标准——「标题有数字和悬念、开头三句话让读者对号入座、每 300 字有一个节奏变化点、三分之一和三分之二处各有互动引导」。同一篇文章，这次改了 16 处。标题从 22 字改到 16 字，开头从第三人称陈述换成第二人称痛点场景，补了 4 个独立加粗的金句段。

同一个工具，因为「想清楚要什么」的程度不同，出来的东西完全不一样。

你对任务的理解深度，决定了循环的上限。

循环设计器：四步流程

循环设计器是一个专门设计 AI 迭代循环的 Skill。你告诉它你想做什么任务，它通过四步帮你生成一份包含完整终止条件的循环方案——复制粘贴就能跑。

第一步 · 理解你的任务

你说「帮我优化这篇文章」或者「帮我修这个项目的测试」，它去读你的文件、看你的项目结构、搞清楚你到底想干什么。这一步你什么都不用做。

第二步 · 自动调研

它搜索这类任务的最佳做法，检查你的项目里有没有现成的验证命令，把问题按严重程度排出来。

第三步 · 和你研讨

这时候它才开口，把调研发现讲给你听。不是问你「怎么判断做完」这种专业问题，而是给你选择题：想做到什么程度？什么不能改？最多跑几轮？你做选择就行。

第四步 · 生成完整方案

两套方案同时给——一套自动停的、一套每轮改一点的——标注推荐哪套。每套不少于八百字，第一行就是可执行的命令。整块复制粘贴到终端回车就能跑。

整个过程不需要写代码，不需要懂专业术语。

💡 通俗讲：循环设计器就像一个项目经理——先去了解你的需求，再去调研行业做法，然后拉你开个短会确认方案，最后交付一份可以直接执行的计划书。

为什么不用通用模板

你可能会想：「可读性」「完整性」「逻辑性」这几个维度往上一套，通吃所有任务不就行了？

不行。

「可读性」对一篇技术文档和一篇公众号文章意味着完全不同的事情。预设维度只能做到「大致对」，但循环的终止条件需要「精确对」——差一点就是跑偏和收工的区别。

所以这个工具的评分维度不是预设的，是根据你的任务在研讨过程中动态生成的。格式和约束是固定的——三到五个维度、权重加起来一百——但维度本身是活的。

这比直接套模板多了一步人工参与。但这一步，恰好是质量的分水岭。

三个版本的演化过程

这个工具经历过三个版本，每个版本踩的坑都是真实的。

版本一：六问模式

问你六个问题，收集答案，生成提示词。问题在于用户回答不了「怎么判断做完」——他要是知道答案就不需要工具帮忙了。六个问题本质上是把设计负担转嫁给了用户。

版本二：裁判模式

引入「裁判」概念——让一个独立模型来判断完成标准，执行者和裁判分离。核心发现是：让同一个 AI 既执行又判断，跟让学生自己改卷子差不多。但裁判模型只适用于有客观验证手段的任务，主观判断找不到一个独立裁判能说了算。

版本三：双模式并行（当前版本）

有验证命令的任务走独立裁判（Claude Code 的 /goal 命令就是这个机制——一个独立模型检查完成条件），没有验证命令的任务走动态评分（/loop 命令，每轮改一点、改到满意为止）。两种模式并行，不试图用一套机制覆盖所有场景。

承认有些任务没有客观标准，是比强行制造客观标准更诚实的工程决策。

第一次使用建议

很多人对「循环」有心理门槛，觉得是高级玩法。

这个工具生成的方案有三重安全网：每个方案有最大轮数限制，通常三到五轮；会自动识别哪些文件不能动；每轮只改有限内容，你可以随时叫停。

你的第一次使用可以是一个很小的任务——比如「帮我优化这篇周报的措辞」。跑一次你就明白了，比读十篇教程管用。

如果你想了解更多 Agent 工作流的实战方法，或者看看 Skill 开发的完整流程，可以先从这两篇开始。

结论：循环工程的本质是需求工程

回到开头那条技术演进线——提示词工程 → 上下文工程 → 驾驭工程 → 循环工程。

还得加一层：需求工程。

循环本身不难，一个重复执行的机制谁都能搭。难的是告诉循环「什么时候该停」。而「什么时候该停」的答案不在技术里，在你对自己任务的理解深度里。

没有可靠验证的循环，只是更快地发布错误。

AI 能写的代码量还会继续涨——180% 会变成 280%、380%。但真正能交付的比例涨不涨，取决于我们有没有把「你到底想要什么效果」这件事当成一个正式的工程问题去做。

附：可直接复用的循环设计提示词

复制下面这段到 Claude Code，回车就能跑：

你是一个循环设计器。我接下来会给你一个需要反复迭代的任务。请按以下四步帮我设计方案：

第一步【理解】：读我的任务描述和相关文件，用一段话总结你理解的任务目标。判断这个任务适不适合循环——如果是一次性决策或没有迭代空间，直接告诉我"不适合循环"并给替代建议。

第二步【调研】：分析有没有一条命令能客观判断"做完了"。有就记下这条命令；没有就为这个任务设计 3-5 个评判维度，每个维度给权重（加起来 100），通过分 80。

第三步【研讨】：把发现讲给我听，问我三个问题：①想做到什么程度？②有什么不能动？③用自动停还是每轮改一点？

第四步【生成】：根据我的回答，生成可直接运行的循环提示词。要求：终止条件明确、最大轮数 3-5 轮、每轮只改 2-3 处、列出不能碰的清单、方案不少于 800 字。

我的任务是：[在这里描述你的任务]

常见问题

循环工程和提示词工程有什么区别？

提示词工程关注的是「怎么把一条指令写好」，解决的是单次交互的质量问题。循环工程关注的是「怎么让 AI 自动跑多轮、自己判断什么时候该停」，解决的是多轮迭代中的终止条件和验证机制问题。循环工程是提示词工程 → 上下文工程 → 驾驭工程之后的第四个阶段。

循环工程适合哪些类型的任务？

循环工程在代码类任务中表现最好（有客观验证命令：测试通过、编译成功、零错误），但也适用于内容类任务（文章优化、文案改写），只是内容类任务需要事先拆出评判维度并定好通过标准，而不是依赖「改到满意为止」这样模糊的终止条件。

为什么 85% 的开源循环只能用在代码类任务？

代码类任务有天然的客观验证手段——运行一条命令就知道还剩几个错误，退出码为零就代表完成。改文章、调设计、优化文案等内容类任务缺少这种客观检测手段，需要人为定义评判维度和打分标准，设计难度更高，所以开源社区很少有成熟的内容类循环模板。

如何给内容类任务设计终止条件？

三步走：第一步，拆出 3-5 个评判维度（例如标题吸引力、开头钩子力度、节奏变化密度）；第二步，每个维度分配权重（加起来 100 分）并设定通过线（例如 80 分）；第三步，让 AI 每轮只改 2-3 处并按维度打分，达标就停。Claude Code 的 /loop 命令就是这个机制的官方实现。

Claude Code 的 /loop 和 /goal 命令有什么区别？

/goal 适用于有客观验证命令的任务——设定一个目标条件，由一个独立评估模型（不是执行模型）自动检查每一步是否达标，达标就停。/loop 适用于没有客观验证命令的任务——每轮做小幅修改，用户看完决定继续还是停止。两者并行，按任务性质选用。详见 Claude Code /loop 实战指南。

循环工程的核心本质是什么？

循环工程的本质是需求工程——「怎么让 AI 自己停」这个问题，翻译过来就是「你到底想让它做到什么程度」。终止条件写不出来，不是技术能力不够，是对任务目标的理解还不够精确。

循环设计器 Skill 做了什么？

循环设计器是一个四步工具：第一步理解你的任务（读文件、分析项目结构）；第二步自动调研这类任务的最佳做法和可用验证命令；第三步和你研讨——给你选择题而不是开放题（想做到什么程度、什么不能改、最多跑几轮）；第四步生成可直接运行的循环方案（两套并行，标注推荐哪套）。

为什么不用通用的评分模板来做终止条件？

「可读性」对一篇技术文档和一篇公众号文章意味着完全不同的事情。预设维度只能做到「大致对」，但循环的终止条件需要「精确对」——差一点就是跑偏和收工的区别。所以评分维度必须根据具体任务在研讨过程中动态生成，不能套模板。

下一步

AI 编程实操课：Claude Code + Codex + Agent 工作流，覆盖一人公司、自媒体自动化、AI 副业全场景。实战教程 + 最佳实践 + 源码包，跟着做就出成果。国内版-FlowUS | 国际版-BMC

国内版和国际版内容完全相同，根据你的支付渠道自行选择即可。