★ FEATURED ARTICLE 1. 从“写提示词”到“搭循环”Loop Engineering 到底在解决什么问题如果你最近半年一直在用 Claude Code、Codex、Cursor 这类 AI 编程工具大概率经历过这样一个阶段一开始觉得“哇一句话就能生成一个函数”用着用着发现不对劲——单次对话能解决的问题越来越有限稍微复杂一点的任务比如重构一个模块、修一个跨文件的 bug、给项目补一套测试AI 要么改一半忘了上下文要么改完 A 文件把 B 文件搞崩了你还得反复手动把报错贴回去来回十几轮人比不写 AI 还累。这个痛点就是Loop Engineering循环工程要解决的核心问题。说白了它不是让你去写更花哨的提示词而是让你设计一套可重复、可验证、能自我纠错的执行循环把 AI 编程工具从“一次性问答机器”变成“能自己跑完一个任务闭环的工程系统”。你不再是一次次手动喂上下文而是搭好一个 loop让 Claude Code 或 Codex 在里面自己迭代执行 → 观察结果 → 判断是否达标 → 不达标就带着新信息重来。我自己的体会是提示词工程解决的是“单步质量”循环工程解决的是“多步收敛”。这两件事完全不是一个维度。你提示词写得再漂亮如果任务需要 8 个步骤、涉及 5 个文件、中间还要跑测试那单步质量再高也架不住误差累积。而循环工程的价值就在于它承认 AI 会犯错然后设计一套机制让错误被自动发现、自动反馈、自动修正最终收敛到可用结果。这套方法适合谁我的判断是三类人最该学一是已经在用 Claude Code 或 Codex 做真实项目、但总觉得“差一口气”的开发者二是团队里想把 AI 编程流程标准化、让多人协作时输出稳定的技术负责人三是刚上手 Cursor、还在纠结“怎么设置中文回复”“免费额度够不够”的新手——因为越早建立循环思维越不容易陷入“手动救火”的泥潭。接下来我会把整套 Loop Engineering 的搭建思路、核心参数、实操步骤和踩坑经验全部拆开讲你照着抄作业就能跑起来。2. 循环工程的底层设计为什么是“循环”而不是“更长的提示词”2.1 单次调用为什么必然失败误差累积的数学直觉先讲清楚一个很多人没意识到的原理。假设你让 AI 完成一个需要 10 个步骤的任务每一步 AI 做对的概率是 90%——这已经是很乐观的估计了。那么整个任务一次跑对的概率是 0.9 的 10 次方约等于0.35。也就是说哪怕单步准确率高达 90%一次成功的概率也只有三分之一。如果步骤增加到 20 步0.9^20 ≈ 0.12基本就是碰运气。这就是为什么你总觉得 AI“前面做得挺好后面就崩了”。不是它突然变笨而是误差在链条上累积。提示词工程试图把单步准确率从 90% 提到 95%但 0.95^20 也只有 0.36治标不治本。循环工程的思路完全不同它不追求一次跑对而是让系统在每一步之后都有机会检测偏差并回退重来把“一次成功的概率”转化成“有限次迭代内收敛的概率”。只要每次迭代能带来有效信息收敛几乎是必然的。2.2 一个合格 loop 的四个必备组件我踩过不少坑之后总结出一个能真正跑起来的 loop 必须包含四个部分缺一个都会退化成“手动来回贴报错”执行器Executor真正干活的那一层通常是 Claude Code、Codex CLI 或 Cursor 的 Agent 模式。它负责读文件、改代码、跑命令。验证器Verifier判断“这一步到底成没成”的机制。可以是一条测试命令、一个类型检查、一个 lint 规则甚至是一段你自己写的断言脚本。没有验证器的 loop 就是瞎跑。反馈通道Feedback Channel把验证结果结构化地送回给执行器。注意是“结构化”不是把一整屏报错原样丢回去那样只会污染上下文。终止条件Stop Condition什么时候停。可以是“测试全绿”也可以是“迭代超过 N 次就放弃并报告”没有终止条件的 loop 会烧钱烧到天亮。提示很多人搭 loop 失败90% 是卡在验证器上。他们要么没有验证器要么验证器太弱比如只看“命令有没有报错”导致 AI 改出一个能跑但逻辑错的版本loop 就“假收敛”了。2.3 工具选型Claude Code、Codex、Cursor 各自适合放在 loop 的哪一环这三个工具不是互斥的我在实际项目里经常混用。它们的定位差异很明显选错了会让 loop 效率大打折扣。工具强项适合的 loop 角色注意点Claude Code长上下文、多文件编辑、终端集成好主力执行器注意上下文窗口消耗长 loop 要定期清理Codex CLI命令执行快、脚本化能力强执行器 自动化验证配置文件要提前调好否则容易卡在登录或组织设置Cursor编辑器内交互、可视化 diff人工介入节点、审查环节免费额度有限长 loop 建议配合 CLI 工具我的常规组合是Claude Code 当主力执行器Codex 跑自动化验证脚本Cursor 留给我自己审查关键 diff。这样既有自动化吞吐又保留了人在关键节点的判断权。如果你只用一个那就用 Claude Code它的多文件编辑能力目前最适合 loop 场景。3. 核心细节拆解把 loop 拆成可配置的零件3.1 任务分解粒度为什么“一步一验证”比“一次全做完”稳新手最容易犯的错是给 AI 一个巨大的任务“帮我把这个项目重构成 TypeScript”。这种任务没法验证也没法反馈loop 根本转不起来。正确的做法是把任务切到“单次可验证”的粒度。什么叫单次可验证我用的标准是这一步做完之后我能用一条命令判断它对不对。比如“把 utils.js 改成 utils.ts 并补类型”就是可验证的因为改完跑tsc --noEmit就知道成没成。而“重构整个项目”不可验证因为它没有明确的完成信号。实操上我会把大任务拆成这样的链条改一个文件 → 跑类型检查 → 通过则进入下一个文件 → 不通过则带着类型错误重试当前文件。每个环节都是独立的小 loop串起来就是大 loop。这样即使某一步卡住也不会污染其他步骤的上下文。3.2 验证器的三种强度从“能跑”到“行为正确”验证器是 loop 的灵魂但它的强度分三档你得根据任务重要性选。弱验证只看命令退出码。比如npm run build没报错就算过。优点是快缺点是 AI 很容易写出“能编译但逻辑错”的代码。中验证跑单元测试或集成测试。这是我最常用的档位因为测试本身就是对行为的断言。前提是你得先有测试或者让 AI 先补测试再改代码。强验证端到端测试 人工抽查关键 diff。适合核心模块但会拖慢 loop 速度一般只在最后收敛阶段用。我的经验是loop 前期用弱验证快速迭代中期切中验证最后用强验证兜底。一上来就上强验证loop 会慢到你想砸键盘。3.3 反馈信息的压缩别把整屏报错塞回上下文这是我最想强调的一个细节。很多人 loop 跑不起来是因为反馈通道设计得太粗糙——AI 改完代码跑测试报了一屏错然后他们把这整屏原样贴回给 AI。结果 AI 的上下文被几百行堆栈塞满真正有用的信息哪个断言失败、期望值是什么反而被淹没。我的做法是写一个反馈压缩脚本把测试输出过滤成三行失败的测试名、期望值、实际值。比如# 把 jest 输出压缩成关键信息 npm test 21 | grep -E (✕|Expected|Received) | head -20然后只把这三行喂回去。实测下来同样的任务压缩反馈后 loop 的收敛轮数能减少 30% 到 50%。因为 AI 拿到的信号更干净判断更准。注意压缩反馈时千万别把“通过”的信息也塞回去那纯属浪费上下文。只回传失败项通过了就静默进入下一步。3.4 终止条件的设计防止 loop 变成烧钱机器没有终止条件的 loop 是灾难。我见过有人跑了一晚上第二天发现 AI 在同一个错误上循环了 200 次账单直接爆掉。终止条件至少要设三层成功终止验证器全绿正常退出。迭代上限比如最多 10 轮超过就停输出当前状态和失败原因。无进展检测如果连续 3 轮验证结果完全一样说明 AI 在原地打转立即停止。第三层最容易被忽略但最救命。实现方式很简单把每轮的验证结果哈希一下连续相同就触发熔断。4. 项目实战从零搭一个能自己修 bug 的 loop4.1 实战场景与前置准备我拿一个真实的小项目来演示一个 Node.js 写的命令行工具有几个函数在处理边界输入时会抛异常。目标是搭一个 loop让 Claude Code 自己找到并修复这些 bug全程我只在最后审查。前置准备清单一个能跑起来的项目最好有现成的测试框架我用 Jest。Claude Code 已安装并登录能正常读写项目文件。一个终端能跑npm test。一个反馈压缩脚本下面会给。如果你还没装 Claude Code安装流程不复杂装完确认能在项目目录里正常调用就行。Codex 用户同理配置文件调好之后能跑命令即可。Cursor 用户可以把 Cursor 当审查界面执行交给 CLI。4.2 第一步让 AI 先补测试建立验证基线loop 要转起来先得有验证器。但很多项目测试不全这时候别急着让 AI 改代码先让它补测试。这一步本身就是一个小 loop让 AI 读源码 → 生成测试 → 跑测试 → 如果测试本身报错就修测试。我给 Claude Code 的指令大概是这样读 src/ 下所有文件为每个导出函数生成 Jest 测试 覆盖正常输入和边界输入空值、超长字符串、负数。 生成后运行 npm test如果有测试本身写错了就修正 直到所有测试能正常运行允许有失败断言那是待修的 bug。这一步跑完你就有了一个能区分“测试写错”和“代码有 bug”的基线。这是后面 loop 能收敛的前提。4.3 第二步搭建反馈压缩与循环脚本测试有了接下来写 loop 脚本。我用 bash 写简单直接#!/bin/bash MAX_ITER10 prev_hash for i in $(seq 1 $MAX_ITER); do echo 第 $i 轮 # 跑测试并压缩反馈 result$(npm test 21) failures$(echo $result | grep -E (✕|Expected|Received) | head -20) # 无进展检测 cur_hash$(echo $failures | md5sum | cut -d -f1) if [ $cur_hash $prev_hash ]; then echo 连续无进展终止 break fi prev_hash$cur_hash # 全绿则成功退出 if [ -z $failures ]; then echo 全部通过loop 结束 break fi # 把压缩后的失败信息喂给 Claude Code claude -p 以下是测试失败信息请修复对应代码只改必要的文件 $failures done这个脚本的核心就是前面讲的四组件执行器是claude -p验证器是npm test反馈通道是 grep 压缩终止条件是迭代上限 无进展检测。4.4 第三步跑起来观察收敛过程第一次跑的时候我盯着终端看前两轮 AI 修得挺准第三轮开始有点飘——它把一个边界判断改成了硬编码。但因为测试覆盖了那个边界第四轮测试直接把它打回来了第五轮它换了个正确写法。整个过程 5 轮收敛比我手动修快得多而且我全程没干预。这里有个关键观察loop 的价值不在于 AI 一次做对而在于它做错之后能自己发现并纠正。第三轮那个硬编码如果放在单次对话里很可能就被我接受了因为它“看起来能跑”。但测试把它拦下来了。这就是验证器的意义。4.5 第四步人工审查与 loop 收尾loop 收敛不代表任务结束。我最后一定会做两件事一是用 Cursor 打开 diff逐行看 AI 改了什么重点看有没有“为了过测试而写的投机代码”二是把这次 loop 的轮数和失败模式记下来作为下次调参的依据。审查时我特别关注三类改动硬编码的返回值、被注释掉的断言、以及try/catch吞掉异常的地方。这三类是 AI 在 loop 压力下最容易产生的“作弊”行为测试可能过但代码质量崩了。5. 常见问题与排查技巧实录5.1 loop 跑不起来先查这五个高频故障现象可能原因排查方法AI 完全不改代码反馈信息为空或格式不对手动跑一次测试确认 grep 能抓到失败项每轮改一样的地方反馈没变化AI 在打转检查无进展检测是否生效看哈希是否相同越改越乱上下文被污染每轮开新会话别复用同一个 session测试一直报环境错验证器本身有问题先手动跑通测试再进 loop卡在登录或配置工具没配好单独跑一次 CLI 命令确认能正常调用这五个里“越改越乱”是最隐蔽的。原因是很多人图省事让 AI 在同一个会话里连续改十几轮上下文里堆满了历史失败信息AI 反而被带偏。我的做法是每轮都开新会话只把当前轮的压缩反馈传进去保持上下文干净。5.2 反馈压缩的三个实操技巧第一只抓失败项不抓通过项。前面说过这里再强调一次通过的信息对修复毫无帮助只会占上下文。第二保留期望值和实际值的对比。AI 修复 bug 最需要知道的就是“我以为是 A实际是 B”这个对比信息比堆栈有用一百倍。第三限制反馈行数。我一般head -20超过 20 行的失败信息说明问题太大应该先拆任务而不是硬修。5.3 什么时候该放弃 loop转人工不是所有任务都适合 loop。我总结了几条“该收手”的信号连续 5 轮无进展、失败信息涉及架构层面的设计问题、AI 开始出现投机性改动。遇到这些别硬跑停下来人工介入把任务重新拆细再进 loop。loop 是加速器不是万能药用错场景只会浪费时间和额度。5.4 关于额度与成本的实话Cursor 免费额度有限Claude Code 和 Codex 也都有用量限制。一个 10 轮的 loop如果每轮都传大段上下文消耗会很快。我的省钱经验是压缩反馈、开新会话、前期用弱验证这三招能把单次任务的消耗压到原来的三分之一左右。别小看这些细节长年累月下来差距很大。6. 我踩过的坑和几条压箱底的经验先说最大的一个坑我曾经让 loop 自己决定什么时候停。结果 AI 觉得“差不多了”就停了留下一个半成品。从那以后我所有的终止条件都是脚本硬编码的绝不让 AI 自己判断。AI 对“完成”的判断标准和你完全不一样这个权力必须握在自己手里。第二个坑是验证器太弱导致的假收敛。有次我只用npm run build当验证器AI 改出一个能编译但逻辑全错的版本loop 三轮就“成功”退出了。我审查时才发现问题。从那以后只要任务涉及逻辑我一定上单元测试绝不用编译通过当唯一标准。第三个经验是把 loop 的轮数和失败模式记下来。我有个简单的日志文件每次 loop 跑完记一行任务类型、轮数、卡在哪。跑了几十次之后我发现自己项目里 80% 的 bug 修复任务都能在 5 轮内收敛超过 8 轮的基本都是任务拆得不够细。这个数据反过来指导我优化任务分解粒度形成正循环。最后一个技巧在 loop 里给 AI 加一句“只改必要文件”的约束。不加这句AI 经常顺手“优化”一堆无关代码把 diff 搞得巨大审查成本飙升。加了之后diff 干净很多收敛也更快。这种小约束看着不起眼但对 loop 的稳定性影响很大。这套东西我用了小半年从最开始手动贴报错到现在基本能放手让 loop 自己跑中间踩的坑基本都写在上面的内容里了。你要是刚开始搭建议先拿一个小任务练手把四组件跑通再逐步加复杂度。别一上来就搞大项目那样大概率会在验证器那一环卡死。
阅读完成 · 觉得有帮助？
