1. 从“写提示词”到“搭循环”Loop Engineering 到底在解决什么问题如果你最近半年一直在用 Claude Code、Codex、Cursor 这类 AI 编程工具大概率经历过这样一个阶段一开始觉得“哇一句话就能生成一个函数”用着用着发现不对劲——单次对话能解决的问题越来越不够用真正麻烦的是那些需要反复迭代、多轮验证、跨文件改动的任务。你写一个提示词AI 给你一版代码你跑一下发现报错把错误贴回去它再改一版又报错再贴……来回十几轮人累得半死AI 也开始“失忆”前面说过的约束它忘了改到后面把前面能跑的逻辑又改坏了。这个痛点就是Loop Engineering循环工程要解决的核心问题。说白了它不是让你去写一个“更聪明的提示词”而是让你去设计一套让 AI 能够自己转起来的循环结构——包括任务怎么拆、每轮循环喂什么信息、什么条件下算完成、失败了怎么回退、上下文怎么管理。提示词工程Prompt Engineering关注的是“这一句话怎么说”循环工程关注的是“这一整套流程怎么跑”。我自己的理解是提示词工程是单次博弈循环工程是重复博弈。单次博弈里你把话说漂亮就行重复博弈里你得设计规则让每一轮都比上一轮更接近目标而不是原地打转甚至越跑越偏。这套东西适合谁三类人最该看。第一类是把 Claude Code、Codex 当日常主力工具但总觉得“它明明能做得更好却做不到”的开发者第二类是团队里负责搭 AI 辅助开发流程的人需要把个人经验沉淀成可复制的规范第三类是刚上手这些工具、还没被坑过的新手——提前知道循环该怎么设计能少走至少两个月的弯路。接下来我会从整体设计思路、核心细节、实操落地、问题排查四个层面把 Loop Engineering 这套东西拆开讲透。中间会大量结合 Claude Code、Codex、Cursor 的实际使用场景因为这三个是目前循环工程实践里最典型的载体。你不需要三个都用但理解它们各自的循环特性对你设计自己的流程有帮助。2. 循环工程的底层设计思路为什么不能靠“多问几轮”硬扛2.1 单轮提示词的三个天花板很多人对 AI 编程工具的期待是“我描述清楚它一次做对”。这个期待在小任务上成立比如“写一个把时间戳转成可读格式的函数”一次就能过。但任务一旦超过某个复杂度阈值单轮提示词就会撞上三个天花板。第一个天花板是上下文窗口的物理限制。你不可能把整个项目的所有文件都塞进一次对话里即使塞进去了模型对中间部分的注意力也会衰减。这就是为什么你让它改 A 文件它顺手把 B 文件里相关的代码也改了但改错了——因为它只看到了 B 文件的一部分。第二个天花板是验证反馈的缺失。AI 生成代码后它自己不知道这段代码能不能跑。你不把运行结果、报错信息、测试输出喂回去它就是在盲写。而单轮对话里你没有机制保证这些反馈被结构化地送回。第三个天花板是目标漂移。多轮对话里随着上下文越来越长最初的目标会被稀释。你一开始说“不要引入新依赖”聊到第十轮它给你加了个 lodash你还得回头去删。Loop Engineering 的第一个设计原则就是承认这三个天花板的存在然后用结构去绕开它们而不是指望模型变聪明。2.2 循环的三个基本要素状态、动作、终止条件任何一套能跑通的循环拆到最底层都是三样东西状态State、动作Action、终止条件Termination。这三个词听起来像强化学习的术语但你在 Claude Code 里手动操作的时候其实一直在无意识地做这三件事。状态就是“当前这一轮开始时AI 需要知道的所有信息”。它包括任务目标、已经改了哪些文件、上一轮的报错是什么、有哪些约束不能违反。状态管理做得好不好直接决定循环能不能收敛。动作就是“这一轮让 AI 干什么”。注意不是“让 AI 把整个任务做完”而是“让 AI 完成当前这一小步”。把大任务切成小动作是循环工程和提示词工程最大的区别。提示词工程想一口气吃成胖子循环工程是一口一口吃。终止条件就是“什么情况下这个循环停下来”。最理想的是“测试全绿”但现实里经常是“连续三轮没有新进展就停”“报错类型从编译错误变成运行时错误就算阶段性成功”这种务实的判断。我见过太多人卡在“循环不收敛”上根因基本都是这三要素里缺了一个。要么状态没管好AI 每轮都在重新理解任务要么动作太大一轮改十个文件出错都不知道哪出的要么没有明确的终止条件跑到天荒地老。2.3 为什么是“循环”而不是“流水线”有人会问那我搞个固定的流水线不就行了第一步做什么第二步做什么为什么要强调“循环”区别在于反馈驱动的迭代。流水线是开环的你预设好步骤跑完就完事中间出错了它不会自己调整。循环是闭环的每一轮的输出会变成下一轮的输入AI 根据反馈调整策略。真实开发任务里你永远无法在开始就预知所有步骤所以闭环比开环更抗造。举个具体例子。你要给一个老项目加一个新功能涉及三个文件的改动。流水线思路是改文件 A → 改文件 B → 改文件 C → 跑测试。但如果改完 A 之后发现 B 的接口和你想的不一样流水线就断了。循环思路是改 A → 跑测试看 A 是否独立通过 → 根据结果决定 B 怎么改 → 改 B → 再跑 → ……每一轮都基于上一轮的真实结果做决策。这就是为什么 Claude Code 这类工具会内置“读取文件 → 修改 → 运行命令 → 读取输出”的循环能力而 Codex 更偏向“你给它一个明确任务它在一个沙箱里自己循环”。理解你用的工具是哪种循环范式是设计流程的前提。2.4 三种主流工具的循环范式对比Claude Code、Codex、Cursor 虽然都能写代码但它们的循环范式差别很大直接决定了你的 Loop Engineering 该怎么设计。我整理了一张对比表这是我自己长期用下来总结的不是官方文档的照搬。维度Claude CodeCodexCursor循环触发方式对话驱动你每轮给指令任务驱动给一个目标它自己跑编辑器内联你选中代码它就改状态管理依赖对话上下文 项目文件依赖沙箱内的文件系统依赖当前打开的文件和选区反馈获取你手动跑命令贴结果或它自己跑沙箱内自动跑测试你手动跑它看报错适合的任务粒度中等多文件改动偏大端到端任务偏小局部修改循环控制权在你手里在它手里在你手里但粒度细看懂这张表你就知道为什么有人用 Claude Code 觉得“很听话但需要我盯着”用 Codex 觉得“省心但有时候跑偏”用 Cursor 觉得“快但只能改小东西”。这不是工具好坏的问题是循环范式匹配不匹配的问题。我的建议是大任务用 Codex 起手做骨架中等任务用 Claude Code 做迭代小修改用 Cursor 做微调。三者不是互斥的可以串成一条更大的循环链。比如 Codex 生成初版 → Claude Code 做重构和补测试 → Cursor 做最后的格式调整。这条链本身就是一套 Loop Engineering。3. 核心细节拆解状态、上下文与反馈回路怎么设计3.1 状态文件让 AI 每轮都“记得”任务目标循环工程里最容易被忽视、但最影响成败的是状态的外部化。什么叫外部化就是不要把任务目标、约束、进度只放在对话上下文里而是写到一个实实在在的文件里让 AI 每一轮都去读它。为什么这么做因为对话上下文会随着轮次增加而膨胀模型对早期内容的注意力会下降。你把关键信息写进一个TASK.md或者PROGRESS.md每轮开始时让 AI 先读这个文件它就永远不会“忘记”最初的目标。我自己的做法是维护一个极简的状态文件结构大概是这样# 任务状态 ## 目标 给用户模块增加邮箱验证功能不引入新的第三方依赖。 ## 约束 - 只能用项目已有的库 - 不能改动数据库 schema - 所有新增函数必须有单元测试 ## 进度 - [x] 阅读现有 user 模块代码 - [x] 设计验证码生成逻辑 - [ ] 实现验证码存储进行中 - [ ] 实现验证接口 - [ ] 补测试 ## 上一轮结果 验证码生成函数已写完测试通过。存储层还没动。这个文件的作用相当于给循环装了一个“记忆锚点”。每轮对话开始时你让 AI 先读它结束时让 AI 更新它。这样即使对话被清空重开任务也能接着跑。提示状态文件不要写太细写太细会变成另一种形式的上下文膨胀。只写“目标、约束、进度、上一轮结果”这四块就够了具体代码细节让 AI 自己去读源文件。3.2 上下文裁剪每轮只喂“这一轮需要的信息”循环工程的第二个核心细节是上下文裁剪。新手最容易犯的错是把所有历史对话、所有相关文件一股脑塞给 AI觉得“信息越多它越聪明”。实际上恰恰相反信息过载会让模型抓不住重点。正确的做法是每一轮只喂三类信息。第一类是不变的目标和约束从状态文件读第二类是上一轮的具体结果报错、测试输出、diff第三类是这一轮要改的文件内容只给相关的不给全部。我举个实际场景。你在改一个 Express 项目要给某个路由加参数校验。这一轮你只需要给 AI路由文件本身、校验相关的工具函数、上一轮测试的报错。你不需要给它整个项目的所有路由也不需要给它前端代码。给多了它反而可能去改不该改的地方。Claude Code 在这方面有个很好用的机制就是它会自己决定读哪些文件。但你不能完全依赖它因为它的判断基于文件名和你的描述有时候会读错。我的习惯是在指令里明确说“只看 src/routes/user.js 和 src/utils/validate.js不要动其他文件”。这句话能省掉很多麻烦。3.3 反馈回路把“报错”变成“下一轮的输入”循环能转起来的关键是反馈被结构化地送回。很多人跑循环跑不下去是因为反馈这一步做得太随意——报错信息复制粘贴一大段AI 看了半天不知道重点在哪。我的做法是把反馈压缩成三段现象、位置、期望。现象是“测试失败了报 TypeError”位置是“在 user.test.js 第 42 行”期望是“这个测试应该返回 200实际返回 500”。三段话AI 立刻就知道问题在哪。更进一步你可以让 AI 自己跑测试并读取输出。Claude Code 支持你授权它执行命令它跑完测试会自己看输出。Codex 在沙箱里默认就会跑测试。这时候你要做的是确保测试本身是可靠的——如果测试写得含糊AI 拿到的反馈就是噪音循环就会乱转。注意不要让 AI 在循环里跑那些会修改外部状态的命令比如数据库迁移、部署脚本。循环里的动作应该是可逆的、幂等的。跑测试、跑 lint、跑类型检查这些是安全的。跑npm publish这种绝对不要在自动循环里做。3.4 终止条件什么时候该停比什么时候该继续更重要终止条件的设计是循环工程里最考验经验的部分。理想情况是“所有测试通过”但现实里经常遇到测试本身有问题、或者任务定义模糊导致永远达不到“通过”。我一般设三层终止条件。第一层是硬性成功条件比如“指定的测试文件全绿”。第二层是进展停滞条件比如“连续三轮修改后报错数量没有减少”。第三层是轮次上限比如“最多跑 15 轮到了就停下来人工介入”。第二层最容易被忽略但最有用。因为循环最怕的不是失败是无效循环——每轮都在改但改的都是无关紧要的地方核心问题一直没碰。设一个“进展停滞”的判断能及时把你从无效循环里捞出来。判断进展有没有停滞可以看几个指标报错数量、测试通过率、代码 diff 的规模。如果连续几轮 diff 都很小但报错没变基本就是卡住了该人工介入了。3.5 循环的“呼吸感”别让 AI 一直紧绷着这一点比较玄但确实是我踩过坑之后才体会到的。循环不是越紧凑越好中间需要留“呼吸”的空间。什么意思就是不要让 AI 连续十几轮都在做高强度的代码修改中间要有让它“回顾和整理”的轮次。具体做法是每跑 3 到 5 轮实质性修改后插入一轮“总结轮”。这一轮不让它改代码只让它做三件事更新状态文件、列出当前还没解决的问题、给出下一步建议。这一轮看起来“浪费”实际上能极大降低后续循环跑偏的概率。我用 Claude Code 的时候经常在改完一个模块后说一句“先别改代码把当前进度和遗留问题整理一下”。它整理出来的东西往往能让我发现一些它自己没意识到、我也没注意到的问题。这一轮的价值比多改两个函数高得多。4. 实操落地从零搭一套能跑的循环工作流4.1 环境准备三个工具的安装与基础配置先把环境搭起来。这一节我按 Claude Code、Codex、Cursor 三个工具分别说你按需选装。安装过程本身不复杂但有几个配置细节会直接影响后面循环跑得顺不顺。Claude Code 的安装官方推荐的方式是通过 npm 全局安装。装完之后第一次运行会让你登录授权这一步跟着提示走就行。装好后建议先做一件事在项目根目录建一个CLAUDE.md文件把你项目的技术栈、代码规范、常用命令写进去。这个文件相当于给 AI 的“项目说明书”它每次启动都会读能省掉你反复解释项目背景的功夫。Codex 的安装和使用核心是理解它的沙箱机制。它会在一个隔离环境里跑你的任务所以你需要确保项目依赖能在沙箱里装好。第一次用的时候建议先跑一个简单任务测试沙箱是否正常比如“读取 package.json 并列出所有依赖”。如果这一步就报错说明沙箱环境有问题先解决环境再谈循环。Cursor 的安装最直接下载安装包装上就行。装完后有两件事要做一是把界面语言设成中文如果你习惯中文在设置里搜“language”就能找到二是配置好模型Cursor 支持多个模型选一个你额度够用、响应稳定的。Cursor 的免费额度有限重度使用的话要提前规划好用在哪些任务上。提示三个工具不要同时在一个项目里混用容易产生配置冲突。我的做法是按任务类型分工同一个任务只用一种工具跑完需要换工具时先把手头的循环收尾。4.2 第一个循环用 Claude Code 做一次完整的“改-测-修”我们从一个最小可跑的循环开始。任务很简单给一个已有的函数补一个边界条件处理并确保测试通过。第一步建状态文件。在项目根目录建TASK.md写清楚目标、约束、进度。这一步花两分钟但能省后面二十分钟。第二步给 Claude Code 下第一轮指令。指令要包含三部分读状态文件、读目标源文件、执行修改。我一般这么写“先读 TASK.md 和 src/utils/format.js然后给 formatDate 函数加上对 null 输入的处理返回空字符串。改完告诉我改了哪几行。”第三步跑测试。改完后你自己跑一下测试或者让 Claude Code 跑。如果通过更新状态文件循环结束。如果不通过把报错按“现象、位置、期望”三段式整理作为下一轮输入。第四步第二轮指令。这次指令是“读 TASK.md上一轮改了 formatDate 但测试报错报错是 [你的三段式描述]。请分析原因并修复只改必要的部分。”这个循环跑下来你会发现一个规律第一轮改代码第二轮修问题第三轮补边界。三轮之内基本能收敛。如果超过五轮还在改同一个函数说明任务定义有问题该停下来重新拆。4.3 进阶循环用 Codex 跑端到端任务Codex 适合跑那种“给一个目标让它自己从头做到尾”的任务。比如“给项目加一个健康检查接口包含路由、控制器、测试”。这种任务用 Claude Code 一轮轮对话也能做但 Codex 更省心因为它自己会在沙箱里循环。用 Codex 的关键是把任务描述清楚然后放手。描述里要包含目标是什么、涉及哪些文件、验收标准是什么。验收标准尤其重要因为 Codex 会拿它当终止条件。你写“接口返回 200 且 body 里有 status 字段”它就会一直跑到满足这个条件。但放手不等于不管。Codex 跑的时候你要盯着它的中间输出一旦发现它开始改不该改的文件立刻中断。我遇到过它为了“让测试通过”而去改测试文件的情况这种必须及时制止。Codex 跑完后不要直接合并代码。先让它输出一份改动清单你人工过一遍。它的循环能力很强但判断力不一定靠谱尤其是涉及业务逻辑的地方。4.4 微调循环用 Cursor 做局部精修Cursor 的循环粒度最细适合做“选中一段代码让它改”这种操作。它的优势是快你选中代码按快捷键输入指令几秒钟就改好了。用 Cursor 做循环工程核心是控制选区。选区选得准它改得就准选区选大了它会顺手改别的。我的习惯是只选要改的那个函数不选整个文件。如果改动涉及多个函数就分多次改每次只选一个。Cursor 还有一个好用的功能是“内联对话”你可以在代码里直接问它问题比如“这个函数有什么潜在问题”。这种问答式的循环适合在正式改代码之前做一轮“体检”先让它指出问题你再决定改不改。4.5 把三个工具串成一条循环链单个工具的循环跑顺了之后可以试着把它们串起来。我常用的一条链是这样的用 Codex 跑端到端任务生成初版代码和测试用 Claude Code 做代码审查和重构重点看边界条件和错误处理用 Cursor 做最后的格式调整和局部优化人工跑一遍完整测试确认无误后提交这条链的关键是每一步都有明确的交接物。Codex 交接的是“能跑的初版”Claude Code 交接的是“审查过的重构版”Cursor 交接的是“格式规范的终版”。交接物不清楚链就会断。注意串链的时候每一步都要重新读状态文件。不要让后一个工具依赖前一个工具的对话上下文因为上下文不共享。状态文件是唯一的共享介质。4.6 参数与配置的取舍几个我踩过坑的设置说几个具体的配置经验。Claude Code 的自动执行命令功能建议初期关掉等你对它的行为有把握了再开。开了之后它会自己跑命令效率高但风险也高万一它跑了个rm -rf你就哭了。Codex 的沙箱资源限制如果你的任务涉及大量依赖安装默认配置可能不够用需要调大内存和超时时间。这个在配置文件里改具体参数看你的项目规模。Cursor 的模型选择不要一味选最强的。最强的模型额度消耗快而且对于简单任务来说属于杀鸡用牛刀。我的做法是简单修改用轻量模型复杂重构用强模型把额度花在刀刃上。5. 常见问题与排查技巧实录5.1 循环不收敛AI 一直在改但问题没解决这是最高频的问题。表现是每轮都在改代码但报错信息几乎没变或者改了一个错又冒出一个新错。排查思路分三步。第一步看状态文件是不是没更新。如果 AI 每轮都在重新理解任务说明状态没同步它不知道上一轮干了什么。第二步看反馈是不是太模糊。如果你只贴了“报错了”三个字AI 只能瞎猜。第三步看任务是不是太大。如果一轮要改五个文件出错是必然的拆小。我的经验是循环不收敛十有八九是任务粒度问题。把“实现用户登录功能”拆成“写登录接口 → 写密码校验 → 写 token 生成 → 写测试”每个小任务单独跑循环收敛率会高很多。5.2 上下文丢失AI 忘了前面说过的约束这个问题的根因是对话太长模型注意力衰减。解决办法就是前面说的状态外部化。把约束写进文件每轮让它读。还有一个技巧是约束前置。每轮指令的开头先把最关键的约束重复一遍比如“记住不引入新依赖”。虽然啰嗦但有效。模型对开头和结尾的内容注意力最强把约束放开头比放中间管用。5.3 工具报错几个高频错误的处理用这些工具的过程中会遇到一些环境层面的报错。比如 Claude Code 在某些系统上安装后找不到命令通常是 PATH 没配好检查一下 npm 全局 bin 目录在不在 PATH 里。Codex 登录不上多半是网络环境问题换个网络或者检查代理配置。Cursor 提示“taking longer than expected”一般是模型响应慢或者额度用完了等一会儿或者换个模型。这些报错本身不复杂但会打断循环节奏。我的建议是把环境问题一次性解决干净不要带着环境问题跑循环否则你会分不清是 AI 的问题还是环境的问题。5.4 常见问题速查表问题现象可能原因处理方式循环多轮不收敛任务粒度过大拆成小任务每个单独跑AI 忘记约束上下文过长状态外部化约束前置改错文件上下文给太多明确指定只读哪些文件测试一直不过测试本身有问题先人工确认测试正确性工具报环境错PATH/网络/额度先解决环境再跑循环循环跑太久没有轮次上限设 15 轮上限到了人工介入代码越改越乱缺少总结轮每 3-5 轮插入一次整理轮5.5 几个独家避坑技巧第一个技巧给 AI 一个“禁止清单”。除了告诉它要做什么还要明确告诉它不要做什么。比如“不要改测试文件”“不要动配置文件”“不要引入新依赖”。这个清单能挡掉大部分跑偏。第二个技巧用 git 做循环的安全网。每轮循环开始前 commit 一次跑砸了直接 reset。这样你敢于让 AI 做大胆的尝试因为你知道随时能回退。第三个技巧观察 AI 的“犹豫”。如果 AI 在某一轮里反复说“我不确定”“可能需要确认”说明任务定义有歧义。这时候不要催它继续停下来把歧义澄清。硬跑下去只会浪费轮次。第四个技巧把成功的循环记录下来。哪套指令、哪个任务拆分方式跑得顺记下来下次遇到类似任务直接复用。循环工程的经验是可以积累的别每次都从零开始。6. 循环工程的边界哪些事不该交给循环聊了这么多循环怎么搭最后说点反向的——有些事不该交给循环。第一类是涉及业务决策的改动。比如“这个功能要不要做”“这个字段该不该加”这种需要人来判断AI 循环再多次也给不出正确答案。第二类是涉及外部系统的操作。部署、发版、改线上配置这些一旦出错影响面大不适合放在自动循环里。第三类是需要创造性设计的部分。架构设计、API 设计这种AI 可以给建议但最终决策要人来做。循环适合执行不适合决策。我自己的原则是循环负责“怎么做”人负责“做什么”和“要不要做”。把这条线划清楚循环工程才能真正提升效率而不是制造混乱。用 Claude Code 和 Codex 这段时间我最大的体会是工具的能力上限很高但你能不能摸到那个上限取决于你会不会设计循环。同样一个任务有人跑三轮就收敛有人跑二十轮还在打转差别不在模型在循环设计。这套东西没有标准答案但有几个原则是通用的状态要外部化、任务要拆小、反馈要结构化、终止条件要明确、中间要留呼吸。把这五条做到你的循环就能转起来。
