1. 循环工程到底是什么从“一次性对话”到“可迭代系统”的认知转变很多人第一次听到“Loop Engineering”这个词会下意识觉得它又是一个被包装出来的新概念。我一开始也这么想直到我在一个真实项目里被反复折磨了整整两周才真正理解它要解决的问题有多具体。先说结论循环工程的核心是把“向模型提问”这件事从一次性的、靠运气的对话变成一套可设计、可观测、可收敛的迭代系统。它关注的不是某一次回答好不好而是整个“提问—执行—观察—修正”的闭环能不能稳定地把你带到目标。为什么这个概念现在才火起来因为早期的模型能力有限你问一句它答一句能答对就不错了根本没有“循环”的空间。但当下的编码类工具已经能读写文件、执行命令、跑测试、看报错、再改代码这就意味着一次任务里模型可能要自主决策几十甚至上百步。步数一多问题就暴露了它会在某个地方卡死、会反复改同一个文件、会忘记最初的目标、会在错误的假设上越走越远。我踩过最典型的一个坑让工具帮我重构一个模块的日志输出结果它改着改着开始“顺手”优化旁边的工具函数最后提交的 diff 里混进了七八个我没要求的改动其中一个还引入了空指针。那次之后我才明白没有循环约束的自动化本质上是把失控的风险也一起自动化了。所以循环工程要回答的是三个问题循环的目标怎么定义得足够清晰循环的每一步怎么被观测和验证循环的终止条件怎么设定才不会过早停止或无限打转。这三个问题听起来朴素但真正落地时每一个都能让新手栽跟头。这篇文章适合两类人一类是刚开始用编码工具、还在“它能帮我写代码”这个阶段的朋友另一类是用了一段时间、发现结果时好时坏、想搞清楚怎么把它用稳的从业者。我会把原理、实操、参数、避坑经验都摊开讲尽量让你看完就能在自己的项目里复现。2. 循环工程的整体设计思路为什么是“闭环”而不是“长提示词”2.1 长提示词的幻觉与循环的真实价值新手最容易走的一条路是把所有要求塞进一个超长的提示词里指望模型一次性理解全部意图。我早期也这么干过写过一个将近两千字的提示词把代码规范、目录结构、命名习惯、测试要求全列进去。结果呢模型确实“看”了但执行到第三步就开始偏离因为它没有机制去检查自己有没有偏离。长提示词的问题在于它是静态的。它假设任务环境不变、假设模型一次就能规划正确、假设执行过程中不会出现意外。但真实的编码任务里意外才是常态依赖装不上、测试挂了、文件被别的进程占用、接口返回格式和文档不一致。循环工程的思路完全不同。它承认“第一次大概率不对”然后把精力放在如何快速发现不对、如何低成本修正上。这就像调试代码你不会指望一次写完就没 bug你会加日志、加断点、跑测试让问题自己暴露出来。提示判断一个工作流是不是“循环工程”最简单的标准是——它有没有一个独立的、由外部工具而不是模型自己执行的验证步骤。如果验证也是模型“自己觉得对”那它仍然是长提示词不是循环。2.2 三类循环模式与适用场景在实际项目里我总结出三种常见的循环模式它们的成本和适用场景差别很大。循环模式验证方式适用场景单次成本收敛速度人工确认循环人看结果后决定下一步探索性任务、架构设计高占用人力慢但可控测试驱动循环跑测试/类型检查/构建有明确验收标准的编码任务中快自评循环模型自己检查输出文案、注释、简单重构低快但不可靠我的经验是能用测试驱动循环的绝不用自评循环。自评循环最大的问题是模型对自己的错误有“盲区”它倾向于认为自己的输出是对的你让它检查它经常回一句“看起来没问题”。而测试是客观的红就是红绿就是绿没有商量余地。人工确认循环虽然慢但在任务目标本身还不清晰的时候是必须的。比如你要重构一个模块但你自己都还没想好新架构长什么样这时候让模型自主循环就是灾难它会基于错误的假设狂奔。正确做法是先人工确认几轮把目标收敛清楚再切换到测试驱动循环。2.3 循环的“燃料”与“刹车”上下文管理循环能跑起来靠的是上下文但上下文也是循环最大的敌人。每跑一轮对话历史就长一截模型要处理的信息越来越多注意力被稀释早期的重要约束容易被淹没。我做过一个粗略的观察在一个中等复杂度的重构任务里当对话轮次超过十五轮之后模型开始明显“健忘”会重复问已经确认过的问题或者忘记某个已经改过的文件。这不是模型变笨了是上下文里噪音太多了。所以循环工程里必须有一套上下文管理策略。常见的做法有三种一是定期摘要把前面的关键决策压缩成一段简短的状态描述二是外部记忆把任务状态、已改文件、待办事项写到一个单独的文件里每轮开始时读进来三是分阶段重置把大任务拆成几个小任务每个小任务用新的对话窗口。我个人最推荐第二种因为它最稳定。摘要依赖模型总结能力可能丢信息重置会丢失跨阶段的上下文。而外部记忆文件是你自己控制的写什么读什么完全透明出问题也好排查。3. 核心细节解析循环工程里那些决定成败的关键参数3.1 目标定义把“帮我优化一下”翻译成可验证的断言循环工程失败的第一大原因是目标定义得太模糊。“帮我优化一下这个函数”这种指令模型没法验证自己有没有完成因为它不知道“优化”的标准是什么——是更快更短更可读还是修掉了某个隐藏 bug我的做法是把目标翻译成可验证的断言。比如“优化这个函数”可以翻译成函数执行时间从 120ms 降到 50ms 以内单元测试全部通过圈复杂度从 12 降到 8 以下不改变对外接口签名这四条里前三条都能被工具自动验证第四条可以靠类型检查或接口对比来验证。一旦目标变成断言循环就有了明确的“完成信号”模型也知道该往哪个方向使劲。注意断言不要一次给太多。我试过给一个任务列了十几条验收标准结果模型顾此失彼改完这条违反那条。后来我改成“核心断言不超过三条次要断言放到后续循环里”成功率明显提升。3.2 步长控制为什么“一次只做一件事”反而更快新手容易犯的另一个错误是让模型在一个循环里做太多事。比如“重构这个模块顺便把测试补上再把文档更新了”。听起来很高效实际上每一件事都会引入新的变量一旦出错你根本不知道是哪一步导致的。循环工程里有个反直觉的原则步长越小整体收敛越快。因为每一步的验证成本低、失败定位快、回滚容易。我现在的习惯是把任务拆到“一次改动只影响一个关注点”的粒度比如这一轮只改数据层下一轮只改调用方再下一轮补测试。这样做看起来轮次变多了但每轮的成功率高返工少。我统计过自己最近十个任务拆细之后平均总轮次反而比“大步走”少了三成左右因为大步走经常走到一半发现方向错了前面全白做。3.3 终止条件三种必须设置的“刹车”循环没有终止条件就是无限烧钱。我见过有人让工具跑了一晚上第二天发现它在两个文件之间反复横跳改了又改回去token 消耗惊人代码一行没净增。必须设置的终止条件有三类成功终止所有核心断言通过循环正常结束失败终止连续 N 轮我一般设 3 轮验证都不通过且没有明显进展强制停止并报告预算终止设定最大轮次或最大 token 消耗到点就停第三类最容易被忽略但最救命。我现在的默认配置是最大轮次 20、连续失败 3 轮即停。这两个数字不是拍脑袋来的20 轮足够覆盖大多数中等任务3 轮连续失败基本可以判定是方向性错误而不是偶发问题。3.4 验证工具的选择测试、类型检查、构建的优先级验证工具的选择直接决定循环的质量。我的优先级排序是类型检查 单元测试 构建 静态分析 模型自评。类型检查排第一因为它最快、最确定、覆盖最广。很多低级错误拼写、参数类型、空值在类型检查阶段就能拦住根本不用等到跑测试。单元测试排第二因为它验证的是行为正确性比类型检查更接近业务。构建排第三主要验证依赖和配置问题。静态分析lint我放在后面因为它的规则经常和实际需求冲突容易产生噪音让循环在无关紧要的格式问题上打转。模型自评放最后只在前面都没有的时候用。4. 实操过程从零搭一个能跑通的循环工作流4.1 环境准备与工具链搭建先说环境。我用的是一台普通的开发机系统是 Ubuntu 22.04内存 16G。工具链方面核心是编码助手加一个能跑命令的终端环境。安装过程这里不展开重点说配置。配置文件我建议单独放一个目录不要和项目代码混在一起。我的习惯是在用户目录下建一个~/.loop-config/里面放三样东西主配置文件、外部记忆文件模板、验证脚本。主配置文件里最关键的是验证命令和终止条件。验证命令我一般写成一行 shell把类型检查、测试、构建串起来任何一步失败就返回非零。这样循环只需要看退出码逻辑简单可靠。# 验证脚本示例 verify.sh set -e npm run typecheck npm run test -- --runInBand npm run build echo ALL CHECKS PASSED外部记忆文件我命名为STATE.md里面固定几个区块当前目标、已完成项、待办项、已知问题、关键决策。每轮循环开始时读进来结束时更新。这个文件是循环的“短期记忆”比对话历史可靠得多。4.2 第一个循环从失败中学习的最小案例我拿一个真实的小任务来演示给一个工具函数补上边界处理。原始函数处理数组时没考虑空数组和 null会抛异常。第一轮我把目标写成断言空数组返回空数组、null 返回空数组、正常数组行为不变、测试通过。然后让工具执行。它改了函数加了两个判断跑测试通过了。看起来一轮就完成了。但我在 review 的时候发现它把 null 和 undefined 都处理了但没处理非数组的输入比如传了个字符串进来。这不是我断言里写的但属于同类问题。于是我加了第四条断言非数组输入抛出明确的类型错误。第二轮它补上了这个判断测试通过。这个案例说明一个点第一轮的断言往往不完整循环的价值就在于让你在过程中发现遗漏并补上。如果我只跑一轮就结束这个边界问题就会留到生产环境。4.3 参数计算轮次、超时、重试怎么定参数不是拍脑袋定的我一般按任务复杂度估算。一个粗略的公式是预估轮次 涉及文件数 × 1.5 验证步骤数 × 2。比如一个任务涉及 3 个文件、有 2 个验证步骤预估轮次就是 3×1.5 2×2 8.5取整 9 轮。实际配置时我会把这个数字乘以 2 作为上限也就是 18 轮留出返工空间。超时方面单轮超时我设 5 分钟。超过 5 分钟还没结束大概率是卡在某个死循环或者网络请求上了强制中断比干等划算。重试我一般不设自动重试因为失败往往意味着需要人工介入调整目标或断言盲目重试只是浪费资源。参数推荐值调整依据最大轮次预估轮次 × 2任务复杂度单轮超时5 分钟任务类型网络类可放宽连续失败阈值3 轮低于 3 容易误停高于 3 浪费上下文摘要间隔每 5 轮对话长度增长速率4.4 实操现场一次完整循环的记录我记录了一次真实的重构任务涉及 4 个文件目标是抽出一个重复的校验逻辑。整个过程跑了 11 轮其中 3 轮失败。第 1 到 3 轮模型识别出重复逻辑抽成公共函数但调用方替换时漏了一处类型检查报错。第 4 轮修复漏掉的调用方类型检查通过但测试挂了一个因为公共函数的错误信息格式和原来不一致。第 5 到 6 轮调整错误信息格式测试通过。第 7 轮我 review 时发现公共函数的参数命名不够清晰加了一条断言要求重命名。第 8 到 9 轮重命名并更新所有调用方。第 10 轮跑全量验证通过。第 11 轮更新 STATE.md记录决策。这 11 轮里真正“写代码”的轮次只有 5 轮左右其余都是验证、修正、记录。这个比例很正常循环工程里大部分时间花在验证和收敛上而不是生成上。如果你发现自己的循环大部分轮次都在生成新代码那说明断言定得太松或者步长太大了。5. 常见问题与排查技巧实录5.1 循环卡死模型反复改同一个地方这是最常见的问题。表现是模型连续几轮都在改同一个文件、同一个函数改来改去回到原点。原因通常是断言之间有冲突或者验证工具给出了矛盾的信号。排查方法先看 STATE.md 里记录的最近几轮改动找出重复的模式。然后检查断言看是不是有两条断言互相矛盾。我遇到过一次一条断言要求“保持函数签名不变”另一条要求“把参数从位置参数改成关键字参数”这两条直接冲突模型就在中间反复横跳。解决办法是把冲突的断言拆到不同阶段先做签名变更再做参数风格调整分两轮完成。5.2 验证通过但结果不对断言的盲区有时候所有断言都通过了但结果就是不对。这通常是因为断言覆盖不全漏掉了某个关键维度。比如测试只覆盖了正常路径没覆盖异常路径或者类型检查通过了但逻辑是错的。我的应对方法是定期做“反向验证”故意构造几个断言没覆盖的边界输入看结果是否符合预期。如果不符合就把这个输入补成新的断言。这个过程重复几次断言的覆盖度就上来了。提示反向验证不需要每轮都做我一般每 5 轮做一次或者在一个阶段完成、准备进入下一阶段时做。5.3 上下文丢失模型忘记了早期约束跑得轮次多了模型会忘记早期的约束。表现是它开始违反之前确认过的规则比如命名规范、目录结构、错误处理方式。解决办法前面提过用外部记忆文件。但光有文件不够还要确保每轮开始时文件被正确读入。我遇到过配置文件路径写错导致 STATE.md 根本没被读进去模型自然就“失忆”了。所以配置好之后一定要验证一次故意在 STATE.md 里写一条奇怪的约束看模型下一轮会不会遵守。如果遵守了说明读取正常。5.4 成本失控token 消耗远超预期成本失控通常有三个原因轮次太多、上下文太长、验证太频繁。轮次太多往往是断言太松或步长太小上下文太长是摘要策略没做好验证太频繁是把重验证比如全量测试放到了每一轮。我的优化顺序是先检查断言能收紧就收紧再检查摘要间隔从每 5 轮改成每 3 轮最后把重验证改成阶段性执行比如每 3 轮跑一次全量测试其余轮次只跑类型检查。问题现象可能原因排查动作解决方向反复改同一处断言冲突检查断言列表拆分阶段验证过结果错断言盲区反向验证补充断言忘记早期约束上下文丢失检查记忆文件读取修复配置成本失控轮次/上下文/验证逐项排查收紧断言、调整间隔5.5 独家避坑三个我踩过的坑第一个坑是在循环里做格式化。我一开始让循环顺便跑格式化工具结果格式化改动和逻辑改动混在一起diff 巨大review 时根本看不出逻辑变化。后来我把格式化单独拎出来在循环开始前和结束后各跑一次循环内部不碰格式。第二个坑是让模型自己决定何时停止。我试过在提示词里写“你觉得完成了就停止”结果它要么过早停止要么永远不停止。终止条件必须由外部工具判断不能交给模型。第三个坑是忽略失败轮次的价值。失败轮次不是浪费它暴露了断言的盲区或目标的模糊之处。我现在会专门记录失败轮次的原因这些记录后来成了我优化断言库的重要素材。6. 循环工程的扩展玩法与个人体会6.1 把循环工程用在非编码场景循环工程的思路不限于编码。我后来把它用在了文档写作上目标是“写一篇技术说明”断言是“覆盖三个核心概念、每个概念有示例、总字数在范围内、术语一致”。验证工具换成了字数统计脚本加术语检查脚本。效果同样不错尤其是术语一致性靠人眼检查很容易漏脚本一跑就出来了。数据清洗场景也适用。断言可以是“空值率低于 1%、字段类型符合预期、行数在合理范围”。每轮清洗后跑验证不通过就调整清洗规则。这个思路比一次性写个大脚本然后祈祷它跑对要稳得多。6.2 循环工程与团队协作的结合一个人用循环工程是一回事团队用是另一回事。团队场景下STATE.md 可以变成共享的任务看板断言可以变成代码评审的检查项验证脚本可以进 CI。这样循环工程就从个人技巧变成了团队规范。我参与过的一个小团队就是这么做的他们把验证脚本接进了 CI每次提交自动跑断言写在 PR 模板里review 时逐条对照。结果是返工率明显下降因为问题在提交阶段就被拦住了而不是等到测试环境才暴露。6.3 我个人的几条经验用到现在我最大的体会是循环工程的门槛不在工具而在目标定义。工具再强目标模糊它也帮不了你。我见过太多人把精力花在折腾工具配置上却不肯花十分钟把目标写清楚结果循环跑得越多偏得越远。第二条体会是验证要趁早断言要从严。早期松一点看起来省事但问题会累积到后面修复成本指数上升。我现在的习惯是宁可第一轮多花时间把断言写严也不愿意后面反复返工。第三条是失败轮次要复盘。每次循环失败我都会花两分钟想想为什么失败是断言问题、目标问题还是工具问题。这个习惯让我慢慢积累了一套自己的断言模板现在开新任务时直接套用起步快很多。最后分享一个小技巧如果你不确定断言该怎么写可以先手动做一遍任务把你实际检查的每一步记下来这些步骤就是天然的断言。手动做一遍花不了多少时间但能让你的循环少走很多弯路。这个内容后续还可以这样扩展把常见任务的断言模板整理成一个库新任务直接引用进一步降低启动成本。