★ FEATURED ARTICLE 1. 循环工程到底是什么从一次真实的返工说起去年冬天我接了一个数据清洗的活儿需求听起来特别简单把一批格式混乱的表格统一成标准结构然后跑一遍校验规则。我当时的做法很“传统”——打开编辑器写一段脚本跑一遍看报错改几行再跑一遍。来来回回折腾了三十多次每次都要手动复制报错信息、手动定位行号、手动改完再手动执行。那天晚上我盯着屏幕上第37次运行的结果突然意识到一个问题我花在“改代码”上的时间可能还没有花在“让代码跑起来并告诉我哪里错了”上的时间多。这就是循环工程要解决的核心问题。它不是某个具体的编程语言特性也不是某个框架的专属功能而是一种把“执行—观察—修正”这个闭环交给机器自动完成的工作方式。你设定好目标、约束条件和反馈机制然后让工具在循环里反复迭代直到结果满足要求或者触发终止条件。听起来有点像自动化测试但它的覆盖面要广得多——从代码生成、调试、重构到数据处理、模型调参、甚至文档校对只要存在“反复尝试直到达标”的场景循环工程就能派上用场。我后来把这个思路用在了日常开发里配合 Claude Code、Codex、Cursor 这类工具效率提升非常明显。举个具体的例子以前写一个正则表达式我可能要试十几次才能匹配到所有边界情况现在我把测试用例写好让工具在循环里自动生成候选正则、跑测试、根据失败用例调整通常三到五轮就能收敛。这不是魔法而是把“人肉循环”变成了“机器循环”人只需要在关键节点做判断和干预。这篇文章适合谁看如果你已经在用 Claude Code、Codex 或 Cursor 这类工具但还停留在“问一句答一句”的阶段那循环工程能帮你把效率再往上提一个台阶。如果你刚开始接触这些工具也没关系我会从最基础的概念讲起把每个环节拆开揉碎配上可以直接抄的配置和步骤。全文会围绕三个核心问题展开循环工程的基本结构是什么、怎么在主流工具里落地、以及踩过哪些坑。提示循环工程不是“让 AI 完全接管”而是“让 AI 在受控的循环里替你跑腿”。控制权始终在你手里关键是设计好循环的入口、出口和反馈信号。2. 循环工程的底层结构三个必须想清楚的问题2.1 循环的入口目标怎么定义才算“可执行”很多人用 AI 工具效率不高根本原因不是工具不行而是目标定义得太模糊。你说“帮我优化这段代码”工具只能猜你想优化什么——是运行速度可读性还是内存占用猜错了你就得重来循环根本转不起来。循环工程的第一步是把目标翻译成机器可判断的条件。我习惯用“三要素法”来定义输入循环开始时工具能拿到什么。比如一段待重构的代码、一个测试用例文件、一份数据样本。判定标准什么情况下算“成功”。比如“所有测试用例通过”“运行时间低于 200ms”“输出格式符合 JSON Schema”。终止条件什么情况下停止循环。比如“连续三轮没有改进”“达到最大迭代次数”“人工介入”。举个例子我最近用 Cursor 做一个 API 响应格式统一的任务。目标不是“把响应改好看”而是{ input: src/api/*.ts, criteria: 所有响应体必须包含 code、message、data 三个字段且 code 为数字, termination: 连续两轮 lint 检查无新增错误或迭代超过 10 次 }这样定义之后工具就知道每次循环要检查什么、什么时候该停。实测下来这种“可判定目标”能让循环的收敛速度提升至少一倍因为工具不需要反复问你“这样行不行”。2.2 循环的反馈错误信息怎么变成“下一步指令”循环工程里最容易被忽视的环节是反馈信号的设计。很多人让工具跑完一轮看到报错就手动复制粘贴给工具说“你看这个错了改一下”。这种做法的问题在于你成了循环里的“人肉消息队列”效率瓶颈全在你身上。正确的做法是让工具自己读取反馈信号。具体来说就是把报错信息、测试结果、lint 输出这些内容通过标准输出或文件写入的方式让下一轮循环能直接拿到。Claude Code 和 Codex 都支持这种模式——你可以在配置里指定“每轮结束后读取某个文件的内容作为上下文”。我常用的一个模式是“错误日志管道”# 第一轮运行测试把结果写入文件 npm test /tmp/test-output.log 21 # 第二轮让工具读取日志生成修复方案 # 在 Claude Code 里可以这样配置 claude --context /tmp/test-output.log --prompt 根据日志中的失败用例修改 src/utils/parser.ts这样工具就能在循环里自己“看到”上一轮的结果不需要你手动搬运。实测下来这个改动能让单次循环的时间从平均 3 分钟降到 40 秒左右因为省掉了人工复制粘贴和切换窗口的开销。2.3 循环的出口什么时候该停什么时候该叫人循环工程最危险的地方是无限循环。我见过有人让工具自动改代码结果工具陷入了一个“改 A 坏 B改 B 坏 A”的死循环跑了一晚上烧掉大量额度最后代码还不如原来。所以终止条件必须设计得保守一点。我的经验是设置三层保险硬性迭代上限比如最多 15 轮到了就停不管结果如何。改进幅度阈值如果连续三轮的“得分”提升小于 5%就认为收敛了停止循环。人工检查点每 5 轮强制暂停输出当前状态让我决定是否继续。这三层保险里第二层最容易被忽略但往往最有用。因为很多任务在前期改进很快后期就是微调继续跑下去收益很低。我一般会在配置里写一个简单的评分函数比如“通过的测试用例数 / 总用例数”然后监控这个值的变化。注意不要迷信“全自动”。循环工程的目的是把重复劳动交给机器但判断“结果是否可接受”这件事目前还是人更靠谱。设置人工检查点不是效率低而是防止跑偏。3. 主流工具里的循环工程落地Claude Code、Codex、Cursor 怎么选3.1 Claude Code适合“长循环”和“复杂推理”Claude Code 是我目前用得最多的工具原因是它对长上下文的支持比较好适合那种需要多轮迭代、每轮都要参考大量历史信息的任务。比如重构一个模块每轮都要看之前的修改记录、测试结果、以及原始代码Claude Code 能把这些都放在上下文里不会“忘事”。在 Claude Code 里做循环工程核心是用好--context和--prompt的组合。我通常会把循环拆成三个阶段阶段一生成候选方案。让 Claude Code 根据当前代码和测试结果生成 2-3 个修改方案。阶段二自动评估。跑测试把结果写入文件。阶段三选择与合并。让 Claude Code 读取测试结果选择最优方案或者把多个方案的优点合并。这个流程听起来复杂但用 shell 脚本串起来之后就是一条命令的事。我写了一个loop.sh大概长这样#!/bin/bash MAX_ITER10 for i in $(seq 1 $MAX_ITER); do echo 第 $i 轮 claude --context ./current-state.md --prompt 根据测试结果修改代码输出到 src/ npm test /tmp/test-result.log 21 PASS_RATE$(grep -oP \d(?% passing) /tmp/test-result.log) echo 通过率: $PASS_RATE% if [ $PASS_RATE -ge 95 ]; then echo 达标退出循环 break fi cp /tmp/test-result.log ./current-state.md done这个脚本的关键在于current-state.md这个文件——它既是上一轮的输出也是下一轮的输入。Claude Code 每轮都会读取它了解当前进展然后决定下一步怎么改。3.2 Codex适合“短平快”的代码生成循环Codex 的特点是响应快、代码生成质量稳定适合那种“生成—验证—修正”的小循环。比如写一个工具函数你给出输入输出示例让 Codex 生成实现然后跑测试根据失败用例再生成通常两三下就能搞定。Codex 的循环工程更依赖提示词的结构化。我一般会这样组织## 任务 实现一个函数输入是字符串数组输出是去重并排序后的数组。 ## 约束 - 不能使用 Set - 时间复杂度 O(n log n) - 必须处理空数组和 null 输入 ## 测试用例 - 输入 []输出 [] - 输入 [b, a, b]输出 [a, b] - 输入 null输出 [] ## 当前实现 粘贴上一轮的代码 ## 测试结果 粘贴上一轮的报错这种结构化的提示词能让 Codex 在每轮循环里都清楚“目标是什么”“哪里没做好”“下一步该改什么”。实测下来对于算法类任务平均 3 轮就能收敛比自由发挥的提示词快很多。3.3 Cursor适合“交互式循环”和“可视化调试”Cursor 的优势在于编辑器集成你可以在代码旁边直接看到修改建议然后决定接受还是拒绝。这种“人在循环里”的模式适合那些需要频繁判断的任务比如 UI 调整、样式微调。在 Cursor 里做循环工程我常用的技巧是用注释标记循环状态。比如// LOOP: 第 3 轮 // CRITERIA: 所有按钮的 hover 效果一致 // STATUS: 前两轮修复了主按钮次按钮还有问题 function Button({ variant }) { // ... }这些注释会被 Cursor 的 AI 读取作为上下文的一部分。每轮修改后我会更新注释里的状态这样下一轮 AI 就知道进展到哪了。这个做法看起来有点“土”但实测很有效尤其是多人协作的时候别人也能看懂循环到哪一步了。3.4 工具选型对照表工具适合场景循环特点注意事项Claude Code复杂重构、多文件修改长上下文适合多轮迭代注意额度消耗设置迭代上限Codex算法实现、函数生成响应快适合短循环提示词要结构化否则容易跑偏CursorUI 调整、交互式开发人在循环里可视化反馈适合小步快跑不适合大批量修改提示不要纠结“哪个工具最好”而是根据任务特点选。我通常是 Claude Code 做主力Codex 做快速验证Cursor 做界面相关的微调。三个工具配合使用比死磕一个效率高得多。4. 一个完整的循环工程实战从零到收敛的全过程4.1 任务背景与目标定义上个月我接了一个需求把一个老项目里的 30 多个 API 接口从回调风格改成 Promise/async-await 风格。这个任务的特点是重复性高、模式固定、但细节多——每个接口的回调嵌套层级不一样错误处理方式也不统一手动改的话至少得两天。我的目标定义是这样的输入src/api/目录下的所有.js文件判定标准所有接口返回 Promise错误通过 reject 抛出且原有测试用例全部通过终止条件测试通过率达到 100%或迭代超过 20 轮这个定义的关键在于“原有测试用例全部通过”——这是硬性标准工具没法糊弄。因为老项目已经有比较完整的测试覆盖只要测试过了基本就能保证功能没坏。4.2 第一轮让工具“看懂”现状第一轮我不急着让工具改代码而是先让它分析现状。具体做法是让 Claude Code 读取所有 API 文件输出一份“改造清单”claude --context src/api/ --prompt 分析所有 API 文件列出每个文件的回调嵌套层级、错误处理方式、以及改造为 Promise 风格的难点。输出为 markdown 表格。这一步大概花了 3 分钟输出了一份 30 多行的表格标注了每个文件的改造难度简单/中等/困难。这个清单后来成了循环的“路线图”——我先让工具改简单的再改中等的最后集中处理困难的。这种“分而治之”的策略比一上来就硬啃困难文件要高效得多。4.3 第二到第五轮批量改造与自动验证从第二轮开始进入真正的循环。我写了一个脚本每轮做三件事让 Claude Code 根据当前清单选择 5 个“简单”文件进行改造。跑测试把失败的用例写入日志。让 Claude Code 读取日志修复失败用例。这个循环跑了四轮改造了 20 个简单文件测试通过率从 60% 提升到 85%。每轮的平均耗时是 8 分钟左右其中工具执行占 5 分钟测试占 2 分钟人工检查占 1 分钟。这里有个细节值得说每轮只改 5 个文件而不是一次性全改。原因是如果一次性改太多测试失败的时候很难定位是哪个文件的问题。小步快跑每轮都有明确的反馈循环才能稳定收敛。4.4 第六到第十轮处理“困难”文件和边界情况剩下的 10 个文件是“困难”级别的主要是回调嵌套太深或者有复杂的错误处理逻辑。这些文件我没让工具全自动改而是采用了半自动模式工具生成改造方案但不直接写入文件。我人工 review 方案确认没问题后再让工具执行。执行后跑测试如果失败回到第一步。这个阶段跑了五轮每轮处理 2 个文件。虽然比前面慢但质量更有保障。最终在第 10 轮测试通过率达到 100%。4.5 循环工程的“收敛曲线”把每轮的通过率画出来大概是这样轮次通过率本轮主要工作160%分析现状生成清单268%改造 5 个简单文件375%改造 5 个简单文件482%改造 5 个简单文件585%改造 5 个简单文件688%处理 2 个困难文件791%处理 2 个困难文件894%处理 2 个困难文件997%处理 2 个困难文件10100%处理最后 2 个文件这条曲线很有意思前期提升快后期提升慢但每轮都有进步。如果我在第 5 轮就停止虽然能省一半时间但会留下 15% 的失败用例后续手动修可能更费劲。所以终止条件的设计很关键——不能太松也不能太紧。注意循环工程不是“跑得越多越好”。我一般会在通过率达到 95% 以上时评估一下剩余失败用例的修复成本。如果剩余的都是“边角料”问题手动修可能比继续跑循环更快。5. 常见问题与排查技巧实录5.1 循环不收敛工具一直在“原地打转”这是最常见的问题。表现是每轮都在改代码但测试通过率不升反降或者来回波动。我遇到过好几次总结下来原因主要有三个目标定义有歧义比如“优化代码”这种模糊目标工具每轮的理解可能不一样。反馈信号不完整只给工具看报错信息没给看上下文工具只能“盲改”。修改范围太大一轮改太多文件导致问题互相干扰。排查方法先检查目标定义确保每个判定标准都是可量化的。然后检查反馈信号确保工具能看到“改之前”和“改之后”的对比。最后缩小修改范围每轮只改一个文件或一个函数。5.2 工具“忘记”之前的修改上下文丢失Claude Code 和 Codex 都有上下文长度限制如果循环轮次太多早期的信息可能会被“挤掉”。表现是工具重复犯之前已经修过的错误。解决方法每轮结束后把关键信息当前状态、已修复的问题、待修复的问题写入一个单独的文件下一轮开始时让工具先读这个文件。这个文件我通常叫loop-state.md内容大概长这样## 当前状态 - 已修复文件 A、B、C 的回调嵌套 - 待修复文件 D 的错误处理 - 测试通过率85% ## 已知问题 - 文件 D 的 catch 块没有正确 reject - 文件 E 的 Promise 链缺少 return ## 下一轮目标 - 修复文件 D 和 E目标通过率 90%这个文件相当于循环的“记忆”能有效防止工具“失忆”。5.3 额度消耗过快怎么控制成本Claude Code 和 Codex 都是按量计费的循环工程如果跑得太猛额度消耗会很快。我的经验是设置硬性迭代上限比如最多 15 轮到了就停。每轮只改少量文件减少单轮消耗。用便宜的模型做初步筛选比如用 Codex 做快速验证用 Claude Code 做精细修改。人工检查点每 5 轮暂停评估是否继续。实测下来一个 30 文件的重构任务如果控制得当总消耗大概在可接受范围内。但如果放任循环跑一晚上消耗可能是前者的好几倍。5.4 常见问题速查表问题可能原因解决方法循环不收敛目标模糊、反馈不完整、修改范围太大量化目标、补充上下文、缩小范围工具“失忆”上下文超限写入 loop-state.md每轮读取额度消耗快迭代太多、单轮修改太多设置上限、小步快跑、人工检查点测试通过率波动修改互相干扰每轮只改一个模块跑完测试再改下一个工具生成错误代码提示词不清晰结构化提示词给出输入输出示例提示遇到问题先别急着换工具大部分问题都是“循环设计”的问题不是工具的问题。把目标、反馈、终止条件这三样检查一遍通常就能找到原因。6. 循环工程的进阶技巧让循环更“聪明”6.1 用“评分函数”代替“通过/失败”基础的循环工程只有两种状态通过或失败。但实际任务里很多结果是“部分通过”的。比如测试通过率 85%比上一轮的 80% 好但还没到 100%。这时候如果只有“通过/失败”两种信号工具就不知道“85% 比 80% 好”可能会放弃一个正在改进的方向。我的做法是定义一个评分函数把结果映射成一个数值。比如def score(test_result): pass_rate test_result[passed] / test_result[total] error_count len(test_result[errors]) return pass_rate * 100 - error_count * 2这个函数的意思是通过率越高越好错误数量越少越好。每轮结束后计算这个分数如果分数比上一轮高就继续当前方向如果低了就回退到上一轮的状态换个方向试试。这个技巧在处理复杂重构时特别有用因为很多修改是“有得有失”的单纯看通过率可能会误判。6.2 多方案并行让工具“赛马”有时候一个任务有多种解法与其让工具一条路走到黑不如让它同时生成多个方案然后选最好的。具体做法是让工具生成 3 个不同的实现方案分别写入不同文件。对每个方案跑测试记录得分。选择得分最高的方案或者把多个方案的优点合并。这个技巧在算法题和性能优化场景下特别好用。我试过让 Claude Code 同时生成 3 个版本的排序函数然后跑基准测试结果发现其中一个版本比另外两个快 30%。如果只让它生成一个版本可能就错过了这个优化。6.3 循环的“冷却期”防止过拟合有些任务在循环里跑久了会出现“过拟合”——工具为了通过测试写出了一些“取巧”的代码虽然测试过了但实际用起来有问题。比如为了让测试通过硬编码了一些返回值。我的应对方法是设置冷却期每跑 5 轮暂停一下人工 review 代码质量。如果发现“取巧”的痕迹就回退到之前的版本调整提示词强调“不要硬编码”“要处理边界情况”。这个技巧看起来有点“反效率”但长期来看能省很多事。因为过拟合的代码迟早要返工不如在循环里就控制住。6.4 把循环工程用在非编程场景循环工程的思路不限于写代码。我后来把它用在了文档校对和数据处理上效果也不错。比如校对一份 50 页的技术文档输入文档草稿判定标准术语一致性、语法错误数量、格式规范终止条件连续两轮没有新增修改建议具体做法是让工具每轮读取文档输出修改建议我人工确认后应用然后进入下一轮。跑了 4 轮文档质量明显提升而且每轮的工具消耗比写代码低得多。这个例子说明循环工程的核心是“闭环反馈”只要任务满足“可迭代、可验证、可终止”这三个条件就能用这个思路来提效。7. 我踩过的坑和总结的经验第一个坑是过度自动化。刚开始用循环工程的时候我恨不得把所有事情都交给工具结果有一次让工具自动改一个核心模块跑了 20 多轮代码越改越乱最后不得不全部回滚。从那以后我给自己定了个规矩核心模块的修改循环里必须有人工检查点不能全自动。第二个坑是忽视测试覆盖。循环工程的收敛依赖测试结果如果测试覆盖不全工具可能会“通过测试但功能不对”。我现在的做法是在开始循环之前先检查测试覆盖率如果低于 80%先补测试再跑循环。这个前置工作看起来费时间但能避免后面更大的返工。第三个坑是提示词太“客气”。早期我写提示词喜欢说“请帮我优化一下”结果工具的理解很发散。后来改成“把函数 X 的时间复杂度从 O(n²) 降到 O(n log n)保持输入输出不变”收敛速度明显快了。提示词越具体循环越稳定。最后一个经验是记录循环日志。每轮做了什么、结果如何、为什么继续或停止我都记在一个 markdown 文件里。这个习惯一开始是为了排查问题后来发现它还能帮我复盘——哪些任务适合循环工程、哪些不适合看日志一目了然。比如我发现模式固定的重构任务最适合循环而需要创造性设计的任务循环工程反而会限制发挥。这个内容后续还可以这样扩展把循环工程和 CI/CD 流水线结合起来让每次提交都自动触发一轮“检查—修复—验证”的循环或者把循环工程用在多语言项目里让工具自动处理国际化文件的同步和校对。这些方向我还在摸索等有成熟经验了再分享。
阅读完成 · 觉得有帮助？
