详细文字内容
从提示词到循环：四个阶段
三年前我们在研究怎么写好一条提示词（Prompt Engineering）。去年开始聊上下文工程（Context Engineering）——光写好指令不够，还得给够背景信息。今年年初，驾驭工程（Harness Engineering）成了新话题——光有好指令和好上下文还不够，得把工具、环境、验证机制全搭好。
到了 2026 年 6 月，循环工程（Loop Engineering）一夜之间成了整个 AI 编程圈的中心词。Claude Code 的创造者 Boris Cherny 说"我不再写提示词了，我的工作就是写循环"；开发者 Peter Steinberger 发了同样的观点，650 万人看了。
Google Chrome 工程负责人 Addy Osmani 的原文，正式命名了「循环工程」这个概念
所有人都在讨论怎么让 AI 自己跑、自己验、自己停。想把循环工程真正用起来，这篇文章就是写给你的。
从提示词到循环：AI 编程四阶段技术演进
我做了什么
我做了一个专门的 Skill（循环设计器），你回答几个问题，它就能帮你生成一份可以直接粘贴运行的循环提示词。文末附了一段精简版，复制到 Claude Code 就能跑；完整的 Skill 源码在我的 AI 编程实操课里。
但在讲工具之前，先说做这个 Skill 的过程中发现的一件事——
循环工程的本质就是需求工程。
循环工程的核心：Agent 在多个检查点之间自动迭代，直到终止条件满足
你以为你在设计循环，其实你在定义需求。「怎么让 Agent 自己停」这个问题，翻译成人话就是：你到底想让它做到什么程度？ 这件事本身就没想清楚。
每写十行 AI 代码，只有不到两行跑在用户面前——麻省理工的研究证实了这个比例。AI 写出的代码量增长了约 180%，但真正上线交付的只增长了约 30%。
180% 和 30% 之间那条鸿沟，就是"没人定义什么叫做完了"的代价。
拆完 136 个循环，发现了什么
我把三个主流的开源循环提示词库全部拉下来，逐个分析了里面的循环结构。三个库加起来，136 个循环。
ExplainX.ai 的循环库：100 个可复制的循环提示词，按 15 个分类组织
Matthew Berman 的 Forward Future Loop Library：每个循环都标注了验证条件和停止标准
发现一：85% 只能用在代码类
代码有天然优势——跑一条命令就知道还剩几个错误，退出码为零就是做完了。但改文章、调设计、优化文案？这三个库里几乎找不到能用的。
136 个开源循环的场景分布：85% 只能用在代码类任务
发现二：失败原因不是提示词差
我反复看了很多份提示词，措辞清晰、结构完整。问题出在终止条件——要么没写，要么写了等于没写。
「优化代码直到没有问题」——什么叫没有问题？ 「迭代改进直到满意」——谁满意？怎么算满意？
没有终止条件的循环，不是自动化，是自动翻车。
Reddit 上有个帖子写得直白：「说自己跑 500 个 AI 同时干活的人，要么在撒谎，要么省略了关键细节。」那个被省略的关键细节，就是终止条件。
终止方式只有两种
第一种：有命令能查
修类型错误，跑一条检查命令，零错误就停。测试全过就停。构建成功就停。就像厨房装了个油烟传感器，阿姨每擦一遍传感器检测一次，绿灯一亮就知道干净了。
第二种：没命令能查
改文章语气、优化标题吸引力、调页面排版——这些是主观判断。这时候你需要事先拆出三到五个评判维度，每个维度定好权重和通过线，让 AI 每轮按维度打分。达标就停，不达标就继续——但每轮只改有限的几处，不全文推翻重来。就像理发，每剪一刀问你行不行，你说再短一点或者可以了。
两种方式没有高下之分。区别只在一个判断：你的任务有没有一条命令能检查结果。
判断本身不难。落成可以直接运行的方案，才是真正的活。
Claude Code 官方文档：/goal 命令设好终止条件后，独立评估模型自动检查每一步是否达标
最大的发现不在技术层面
最难的不是写提示词，是搞清楚自己到底想要什么效果。
提示词 5 分钟就能写完——"帮我优化这篇文章"，一句话的事。但"优化到什么程度"，我想了一整晚。
是去掉 AI 味就够了？还是要连段落节奏、开头钩子、行动号召一起改？做到"读起来像人写的"就停，还是做到"放进公众号有传播力"才停？这两个标准差距巨大。
我拿自己的一篇文章测试：
- 宽松标准——"去掉明显的 AI 痕迹"。两轮就停了，改了 6 处。AI 味确实淡了，但文章依然平。
- 精确标准——"标题有数字和悬念、开头三句话让读者对号入座、每 300 字有一个节奏变化点、三分之一和三分之二处各有互动引导"。同一篇文章，这次改了 16 处。标题从 22 字改到 16 字，开头从第三人称陈述换成第二人称痛点场景，补了 4 个独立加粗的金句段。
同一篇文章，两种标准：6 处 vs 16 处修改
同一个工具，因为"想清楚要什么"的程度不同，出来的东西完全不一样。
你对任务的理解深度，决定了循环的上限。
你现在卡在哪个阶段？是提示词写不好，还是改到第三轮就不知道该不该继续了？评论区聊聊你的真实感受。
💡 后面会讲怎么把终止条件落成可复制的工具——收藏方便回头用。
所以这个工具不是"一键生成"
前三步——理解任务、调研最佳做法、和你研讨方案——就是帮你把模糊的"帮我优化"翻译成精确的终止条件。
最终生成的提示词只是一个副产品；真正的产出是一份被认真拆解过的需求。
循环设计器：四步流程
循环设计器是一个专门设计 AI 迭代循环的 Skill。你告诉它你想做什么任务，它通过四步帮你生成一份包含完整终止条件的循环方案——复制粘贴就能跑。
第一步 · 理解你的任务
你说「帮我优化这篇文章」或者「帮我修这个项目的测试」，它去读你的文件、看你的项目结构、搞清楚你到底想干什么。这一步你什么都不用做。
第二步 · 自动调研
它搜索这类任务的最佳做法，检查你的项目里有没有现成的验证命令，把问题按严重程度排出来。
第三步 · 和你聊
这时候它才开口，把调研发现讲给你听。不是问你"怎么判断做完"这种专业问题，而是给你选择题：想做到什么程度？什么不能改？最多跑几轮？你做选择就行。
第四步 · 生成完整方案
两套方案同时给——一套自动停的、一套每轮改一点的——标注推荐哪套。每套一千字以上，第一行就是可执行的命令。整块复制粘贴到终端回车就能跑。
循环设计器四步流程：理解→调研→研讨→生成
整个过程不需要写代码，不需要懂专业术语。
为什么不用通用模板
你肯定会想：「可读性」「完整性」「逻辑性」这几个维度往上一套，通吃所有任务不就行了？
不行。
「可读性」对一篇技术文档和一篇公众号文章意味着完全不同的事情。预设维度只能做到「大致对」，但循环的终止条件需要「精确对」——差一点就是跑飞和收工的区别。
所以这个工具的评分维度不是预设的，是根据你的任务在研讨过程中动态生成的。格式和约束是固定的——三到五个维度、权重加起来一百——但维度本身是活的。
这比直接套模板多了一步人工参与。但这一步，恰好是质量的分水岭。
三个版本的演化
这个工具经历过三个版本，每个版本踩的坑都是真实的。
版本一 · 六问模式
问你六个问题，收集答案，生成提示词。问题在于用户回答不了"怎么判断做完"——他要是知道答案就不需要工具帮忙了。六个问题本质上是把设计负担转嫁给了用户。
版本二 · 裁判模式
引入"裁判"概念——让一个独立模型来判断完成标准，执行者和裁判分离。核心发现是：让同一个 AI 既执行又判断，跟让学生自己改卷子差不多。但裁判模型只适用于有客观验证手段的任务，主观判断找不到一个独立裁判能说了算。
版本三 · 双模式并行（当前）
有验证命令的任务走独立裁判（Claude Code 的 /goal 命令就是这个机制——一个独立模型检查完成条件），没有验证命令的任务走动态评分（/loop 命令，每轮改一点、改到满意为止）。两种模式并行，不试图用一套机制覆盖所有场景。
工具设计三个版本的演化：六问→裁判→双模式
承认有些任务没有客观标准，是比强行制造客观标准更诚实的工程决策。
第一次使用建议
很多人对「循环」有心理门槛，觉得是高级玩法。
这个工具生成的方案有三重安全网：每个方案有最大轮数限制，通常三到五轮；会自动识别哪些文件不能动；每轮只改有限内容，你可以随时叫停。
你的第一次使用可以是一个很小的任务——比如「帮我优化这篇周报的措辞」。跑一次你就明白了，比读十篇教程管用。
写在最后
回到开头那条技术演进线——提示词工程（Prompt）→ 上下文工程（Context）→ 驾驭工程（Harness）→ 循环工程（Loop）。
我觉得还得加一层：需求工程。
循环本身不难，一个重复执行的机制谁都能搭。难的是告诉循环"什么时候该停"。而"什么时候该停"的答案不在技术里，在你对自己任务的理解深度里。
没有可靠验证的循环，只是更快地发布错误。
AI 能写的代码量还会继续涨——180% 会变成 280%、380%。但真正能交付的比例涨不涨，取决于我们有没有把「你到底想要什么效果」这件事当成一个正式的工程问题去做。
下载资源
📎 aaron-dev-loop-designing.zip