★ FEATURED ARTICLE 1. 循环工程到底是什么从概念到落地场景1.1 一个被名字耽误的实用方法论第一次看到“Loop Engineering”这个词很多人会以为是某种硬件层面的循环控制技术或者跟嵌入式开发里的主循环、事件循环有关。实际上在AI辅助编程的语境下它指的是一套围绕迭代循环构建的工程化工作方法——把“写代码”这件事拆成若干个可重复、可验证、可回滚的小循环每个循环里都有明确的输入、动作和验收标准。我最初接触这个概念是在用Claude Code做重构的时候。当时面对一个两千多行的老模块直接让AI“帮我重构一下”结果它一口气改了十几个文件跑起来一堆报错我连它改了哪里都理不清。后来换了个思路把重构拆成“读一个函数→改一个函数→跑一次测试→确认无误→进入下一个”的循环每次只动一小块出问题立刻能定位。这就是循环工程最朴素的样子。它解决的核心问题是AI编程工具能力很强但“一次性大改”的失败成本极高。循环工程通过控制每次迭代的范围把不可控的大风险拆解成可控的小风险。适合所有正在用Claude Code、Codex、Cursor这类工具做实际项目的人尤其是接手遗留代码、做大规模重构、或者需要保证线上稳定性的场景。1.2 为什么现在特别值得关注过去一年AI编程工具从“补全单行代码”进化到了“理解整个项目并执行多步操作”。Claude Code能直接读写文件、执行终端命令Codex能根据自然语言描述生成完整函数Cursor能跨文件做重构。能力越强越需要一套方法来约束它——否则就像给一个大力士一把没有刻度的扳手力气越大越容易拧坏螺丝。循环工程的价值在于它提供了一套与工具能力匹配的操作纪律。不是限制工具而是让工具的输出变得可预期、可验证。我实测下来同样的重构任务用循环工程的方式做返工率能降低六成以上而且整个过程心里有底不会出现“改到一半不知道自己在哪”的情况。1.3 核心循环的四个阶段一个完整的工程循环包含四个阶段我把它简称为RIVA循环Read读取让AI读取当前要处理的最小单元比如一个函数、一个类、一个配置文件。关键是限定范围不要让它读整个项目。Intent意图用一句话说清楚这次循环要达成什么目标比如“把这个函数的同步IO改成异步”“给这个类加上参数校验”。Verify验证改完之后立刻跑测试、跑lint、或者手动触发一次调用确认行为符合预期。Advance推进确认无误后把这个改动提交或暂存然后进入下一个最小单元。这四个阶段看起来简单但每个阶段都有讲究。比如Read阶段如果范围划大了AI会引入无关改动Intent如果写得模糊AI会自由发挥Verify如果跳过问题会累积到后面才爆发。后面我会逐个拆解每个阶段的实操细节。2. 工具链选型Claude Code、Codex、Cursor怎么配2.1 三个工具在循环中的角色分工很多人纠结“到底用哪个工具”我的经验是不要二选一而是让它们各司其职。在循环工程的框架下三个工具对应不同的循环环节工具最适合的环节核心优势典型用法Claude CodeRead Intent能直接读文件、执行命令上下文理解强读取模块、分析依赖、执行重构CodexIntent 生成函数级生成质量高补全逻辑严谨生成新函数、补全测试用例CursorVerify 编辑编辑器内联操作流畅diff直观审查改动、微调、跑测试这个分工不是绝对的但遵循一个原则读取和分析用Claude Code生成和补全用Codex审查和微调用Cursor。这样每个工具都在自己最擅长的环节工作循环效率最高。2.2 Claude Code的安装与基础配置Claude Code目前有桌面版和命令行版两种形态。命令行版更适合循环工程因为它能直接嵌入终端工作流。安装方式根据系统不同有所差异核心是确保Node环境就绪然后通过包管理器安装。安装完成后第一件事是配置项目级的权限文件。默认情况下Claude Code每次读写文件都会询问这在循环中会打断节奏。可以在项目根目录创建一个配置文件声明哪些目录允许自动读写{ permissions: { allow: [ Read(src/**), Write(src/**), Bash(npm test), Bash(npm run lint) ], deny: [ Read(.env), Write(package-lock.json) ] } }这个配置的意图很明确允许它在src目录下自由读写允许跑测试和lint但禁止碰环境变量文件和锁文件。锁文件一定要禁写否则AI一次依赖安装就可能把整个lock文件重写导致依赖版本漂移。注意权限配置是循环工程的安全带。宁可多花五分钟配好也不要让AI在无约束状态下操作项目。2.3 Codex的接入与模型选择Codex在国内的使用体验取决于接入方式。目前常见的做法是通过API接入模型选择上建议用推理能力强的版本处理复杂逻辑用轻量版本处理简单补全。配置文件通常放在用户目录下核心字段包括模型名称、API端点、超时时间。一个容易踩的坑是超时设置。循环工程中经常需要AI读取较大文件或生成较长函数默认超时往往不够。建议把超时调到60秒以上同时开启流式输出这样即使生成时间长也能看到进度不会以为卡死了。另一个关键是上下文窗口管理。Codex每次请求携带的上下文有限如果让它在循环中反复读取整个项目很快就会超出窗口。正确做法是每次只传当前循环需要的最小上下文——比如只传目标函数和它的直接依赖而不是整个文件。2.4 Cursor的中文环境与效率设置Cursor的默认界面是英文的对中文用户来说设置中文回复能显著提升阅读效率。在设置里找到语言选项把界面语言和AI回复语言都切成中文。注意这两个是分开的界面语言影响菜单回复语言影响AI输出的内容。注册环节Cursor支持多种方式国内用户用邮箱注册即可不需要纠结手机号的问题。免费额度方面新账号有一定量的快速请求次数超出后会降速但不会断供对于循环工程这种“小步快跑”的用法额度消耗其实比想象中慢——因为每次循环的请求都很小。Cursor还有一个对循环工程特别有用的功能内联diff审查。每次AI改动后它会用高亮标出增删行你可以逐行确认。我习惯在Verify阶段用这个功能快速扫一遍确认没有意外改动后再跑测试。2.5 工具之间的切换与协同三个工具同时用最大的问题是上下文同步。我的做法是用项目文件本身作为共享上下文。Claude Code读取并分析后把结论写到一个临时笔记文件里Codex生成代码时把笔记文件作为上下文传入Cursor审查时直接看代码diff。这样工具之间不需要直接通信通过文件系统间接同步。另一个技巧是统一快捷键。三个工具默认的快捷键不同容易按错。我把它们的“执行当前操作”都映射到同一个组合键上形成肌肉记忆后循环的节奏感会强很多。3. 循环工程的核心操作流程3.1 循环单元的划分原则循环工程最关键的一步是划分循环单元。单元太大一次改太多容易失控单元太小循环次数过多效率低。我的经验法则是一个循环单元对应一个可独立测试的行为。具体来说如果改一个函数这个函数有对应的单元测试那它就是一个循环单元。如果改一个类类的方法之间有耦合那就把类拆成几个循环先改构造函数和初始化逻辑跑一次测试再改核心方法再跑一次最后改辅助方法。每次只动一个方法测试通过后再动下一个。对于前端组件循环单元可以是一个组件的渲染逻辑、一个事件处理函数、或者一个样式块。对于配置文件循环单元可以是一个配置项。核心判断标准是改完之后我能不能用一条命令验证它是对的。如果不能说明单元划大了。3.2 Read阶段如何让AI精准理解上下文Read阶段的目标是让AI理解当前循环单元而不是整个项目。很多人习惯说“读一下这个项目”这是循环工程的大忌。正确做法是明确指定文件路径和行号范围。比如要改一个函数可以这样下指令读取 src/services/userService.js 中 getUserById 函数大约在第45行到第80行 以及它调用的 validateUserId 函数在 src/utils/validators.js 第12行到第25行。 不要读取其他文件。这样AI的上下文里只有两个函数分析精度高而且不会因为读了无关文件而产生“顺手改一下”的冲动。如果项目结构复杂AI可能找不到文件。这时候可以用Claude Code的搜索能力先让它定位在 src 目录下搜索所有包含 getUserById 的文件列出文件路径和行号。定位到之后再执行精确读取。这个“先搜索后读取”的两步法比直接让AI猜文件位置可靠得多。3.3 Intent阶段把需求写成可执行的指令Intent阶段是把“我想干什么”翻译成AI能精确执行的指令。模糊的意图会导致AI自由发挥而自由发挥在循环工程中是不可接受的。对比一下模糊意图“优化这个函数”精确意图“把这个函数里的同步文件读取改成异步使用fs.promises保持函数签名不变错误处理逻辑不变”精确意图包含三个要素改什么、改成什么、什么不变。第三个要素经常被忽略但它极其重要——它告诉AI哪些东西不能碰避免它在改A的时候顺手把B也改了。我习惯在Intent里加一句“只修改这个函数不要改动其他任何代码”。这句话看起来多余但实测能显著减少意外改动。AI有时候会“好心”帮你优化相邻的代码在循环工程里这是灾难。3.4 Verify阶段验证手段的层次化设计Verify阶段是循环工程的质量闸门。验证手段分三个层次按成本从低到高排列静态检查跑lint、跑类型检查。成本最低几秒钟出结果能抓住语法错误和类型不匹配。单元测试跑当前循环单元对应的测试。成本中等几十秒到几分钟能抓住逻辑错误。集成验证手动触发一次真实调用或者跑端到端测试。成本最高但能抓住单元测试覆盖不到的问题。我的做法是每次循环至少跑静态检查涉及逻辑改动必须跑单元测试涉及接口改动必须做集成验证。三个层次不必每次都全跑但静态检查是底线不能省。如果项目没有单元测试怎么办那就手动构造一个最小验证场景。比如改了一个工具函数可以在终端里用node直接调用它传几个典型参数看输出。这个手动验证的过程其实就是在补测试债。3.5 Advance阶段提交策略与回滚准备Advance阶段是把验证通过的改动固化下来。这里的关键是提交粒度。一个循环单元对应一个提交提交信息写清楚这次循环做了什么。这样如果后面发现问题可以精确回滚到某个循环之前的状态。我习惯用git的暂存功能每次循环验证通过后git add当前改动的文件但不急着commit。等积累了三到五个循环后再一起commitcommit信息里列出这几个循环的内容。这样既保持了细粒度又不会让提交历史过于碎片化。回滚准备方面除了git我还会在循环开始前把当前文件复制一份到临时目录。虽然git能回滚但有时候改动还没提交git回滚不了。有个物理备份心里更踏实。4. 项目实战用循环工程重构一个真实模块4.1 项目背景与重构目标我拿一个真实的Node.js项目练手。这个项目有一个orderService.js里面有一个processOrder函数大约300行负责订单处理的全流程校验参数、查库存、算价格、写数据库、发通知。问题是这个函数太长了逻辑耦合严重改一处容易影响另一处。重构目标是把它拆成五个独立的函数validateOrder、checkStock、calculatePrice、saveOrder、sendNotification每个函数职责单一可以独立测试。整个重构过程用循环工程的方式推进。4.2 第一个循环拆出参数校验第一个循环单元是validateOrder。Read阶段让Claude Code读取processOrder函数的前50行以及项目里已有的校验工具函数。Intent阶段指令是从 processOrder 函数中提取参数校验逻辑创建一个新的 validateOrder 函数。 新函数接收 order 对象返回 { valid: boolean, errors: string[] }。 保持原有的校验规则完全不变不要添加新的校验。 只创建新函数不要修改 processOrder 的其他部分。AI生成后Verify阶段跑lint和已有的订单测试。测试通过说明校验逻辑没有破坏。Advance阶段把新函数和原函数的调用点一起暂存。这个循环花了大约十分钟。如果不用循环工程直接让AI重构整个函数很可能一次改出十几个问题排查时间远超十分钟。4.3 第二个循环库存检查的异步改造第二个循环单元是checkStock。这个逻辑原本是同步的但库存查询实际上要走网络请求同步写法会阻塞。Intent阶段指令从 processOrder 中提取库存检查逻辑创建 checkStock 函数。 将同步的库存查询改为异步使用 async/await。 函数签名async function checkStock(order) 返回 { available: boolean, shortage: number }。 错误处理保持原有逻辑网络异常时抛出同样的错误类型。这里有个细节AI一开始把错误处理改成了返回{ available: false }而不是抛异常。这改变了原有行为。我在Verify阶段跑测试时发现了因为有一个测试用例专门验证网络异常时的错误类型。于是回退在Intent里补充“网络异常时必须抛出StockServiceError不要吞掉异常”。重新生成后通过。这个循环暴露了一个重要经验AI倾向于“优化”错误处理把异常改成返回值。在循环工程中这种行为必须被约束因为错误处理方式的改变会影响调用方。4.4 第三个循环价格计算的纯函数化第三个循环单元是calculatePrice。这个逻辑原本依赖外部的this上下文和几个实例变量。Intent阶段指令提取价格计算逻辑创建纯函数 calculatePrice。 所有依赖的外部变量改为通过参数传入。 函数签名calculatePrice(order, pricingRules, userLevel) 返回 number。 计算逻辑和精度保持完全一致不要改变舍入方式。纯函数化的好处是可测试性大幅提升。Verify阶段我写了一个快速测试脚本传入几组典型参数对比新旧函数的输出。全部一致后通过。这个循环的坑在于浮点数精度。AI在重构时把原来的toFixed(2)改成了Math.round导致某些边界值结果不同。测试脚本抓到了这个差异。教训是涉及数值计算的重构Verify阶段必须做新旧对比不能只跑原有测试。4.5 第四、五个循环数据库写入与通知解耦第四和第五个循环相对简单因为前三个循环已经把主要逻辑拆出去了。saveOrder循环主要是把数据库操作提取出来加上事务边界。sendNotification循环是把通知逻辑改成事件驱动通过EventEmitter解耦。这两个循环各花了五到八分钟主要时间花在Verify阶段的集成测试上。因为涉及数据库和外部通知需要启动测试环境。但因为有前三个循环打下的基础改动范围很小问题定位很快。五个循环做完processOrder从300行变成了一个20行的编排函数依次调用五个子函数。整个重构过程大约两小时中间没有出现“改崩了要回滚整个重构”的情况。4.6 循环工程的效率对比为了量化效果我做了个对比同样的重构任务用传统“一次性大改”的方式做了一次用循环工程做了一次。指标一次性大改循环工程总耗时1.5小时2小时返工次数4次1次返工耗时约1小时约10分钟最终bug数3个0个心理负担高全程焦虑低每步可控一次性大改看起来总耗时短但返工耗时加起来反而更长而且最终还有bug。循环工程虽然单次循环看起来慢但总耗时可控质量更高。更重要的是循环工程的过程中你知道自己在哪一步出了问题能立刻定位这种确定性是传统方式给不了的。5. 常见问题与排查技巧实录5.1 AI不按指令改总是“顺手优化”这是最高频的问题。AI看到一段代码即使你只让它改一个函数它也会“好心”把相邻的代码一起优化了。排查思路先检查Intent指令是否足够明确有没有加“只修改这个函数不要改动其他任何代码”这句话。如果加了还出现就在Verify阶段用diff工具逐行审查发现意外改动立刻回退并在下一轮Intent里把“不要改XX”写得更具体。我的经验是Claude Code比Codex更容易“顺手优化”因为它的上下文理解更强更容易产生“整体优化”的冲动。用Claude Code做Read和Intent时要特别强调范围限制。5.2 循环次数太多感觉效率低循环单元划得太细会导致循环次数过多。判断标准是如果一个循环单元改完之后你花在Verify上的时间比改代码的时间还长说明单元划小了。这时候应该把相邻的几个小单元合并成一个稍大的单元。另一个原因是Verify手段太重。如果每次循环都跑完整的集成测试那确实慢。应该分层验证小改动只跑lint和单元测试涉及接口的才跑集成测试。5.3 测试环境启动慢拖累Verify这是基础设施问题不是循环工程本身的问题。解决办法是让测试环境常驻不要每次循环都重启。比如数据库用Docker容器常驻测试数据用fixture预置测试用例之间做好隔离。这样Verify阶段只需要跑测试命令不需要等环境启动。如果环境实在启动慢可以在循环中先用mock验证逻辑等积累几个循环后再做一次真实环境的集成验证。但mock验证不能完全替代真实验证最终还是要跑一次真的。5.4 AI生成的代码风格与项目不一致这个问题在多人协作的项目中特别明显。解决办法是在项目根目录放一个代码风格说明文件比如.editorconfig或者一个简短的STYLE.md在Intent阶段让AI先读这个文件。Claude Code和Cursor都能读取项目配置文件并遵循。另一个技巧是在Intent里附上一个“参考实现”的路径让AI模仿那个文件的风格。比如“参考src/services/otherService.js的代码风格”。这比抽象的风格描述有效得多。5.5 循环过程中发现前面的循环有问题这是正常情况循环工程不要求一次做对。发现前面循环有问题时不要在当前循环里顺手修而是回退到那个循环单独修完再继续。比如第三个循环发现第一个循环的validateOrder少了一个校验规则应该先回退到第一个循环的状态补上校验验证通过然后再重新推进到第三个循环。这样做看起来麻烦但能保证每个循环的状态都是干净的。如果在前面的问题没修的情况下继续推进问题会累积到最后排查成本更高。5.6 常见问题速查表问题现象可能原因排查动作预防措施AI改动范围超出预期Intent范围描述不清检查diff回退意外改动Intent加“只改XX”约束循环效率低单元划太小或验证太重合并小单元分层验证按可测试行为划分单元测试跑得慢环境未常驻检查环境启动方式用容器常驻测试环境代码风格不一致未提供风格参考检查项目配置文件Intent中附参考文件路径前面循环有问题验证不充分回退到问题循环单独修每个循环严格VerifyAI吞掉异常AI倾向“优化”错误处理检查错误处理逻辑Intent明确错误处理方式6. 进阶技巧让循环工程更顺手的几个习惯6.1 维护一个循环日志每次循环开始前在临时文件里记一行循环编号、目标、涉及文件。循环结束后记一行结果、耗时、遇到的问题。这个日志不需要很正式就是给自己看的。积累十几个循环后回看日志能发现自己的模式——比如哪类改动容易出问题哪类验证手段最有效。我用的是一个简单的Markdown文件放在项目根目录的.loop-log.md加在.gitignore里不提交。格式大概是## Loop 3 - 2024-XX-XX 目标提取 calculatePrice 为纯函数 文件src/services/orderService.js 结果通过耗时8分钟 问题AI把toFixed改成了Math.round测试抓到6.2 为循环工程准备专用测试脚本项目原有的测试套件可能很重跑一次要几分钟。循环工程需要的是快速反馈所以值得为常用循环单元写一些轻量测试脚本。比如针对工具函数的测试可以直接用node运行不需要启动整个测试框架。这些脚本放在scripts/loop-tests/目录下按循环单元命名。每次循环的Verify阶段先跑这些轻量脚本通过了再跑正式测试。这样大部分问题在轻量脚本阶段就被抓住了不用等正式测试。6.3 用git worktree做并行循环如果项目比较大可以同时开多个循环每个循环在一个独立的git worktree里进行。这样循环之间互不干扰一个循环在Verify时另一个循环可以继续改。等所有循环都验证通过后再合并回主分支。这个技巧适合大型重构但要注意合并冲突。如果两个循环改了同一个文件的不同部分合并时可能冲突。所以并行循环的前提是循环单元之间文件不重叠。6.4 定期回顾循环质量每做完一个较大的任务花十分钟回顾一下哪些循环一次通过哪些循环返工了返工的原因是什么。如果发现某类循环总是返工说明这类循环的Intent模板或者Verify手段需要调整。比如我发现自己早期做“异步改造”类循环时总是返工原因是Intent里没有明确错误处理方式。后来在模板里固定加上“错误处理保持原有逻辑异常类型不变”返工率就降下来了。6.5 把循环工程用在非编程场景循环工程的思路其实不限于编程。写文档、做设计、甚至整理数据都可以用同样的方法把大任务拆成小循环每个循环有明确的输入、动作、验证。比如写一篇长文可以按章节循环读参考资料→写这一节→检查逻辑和事实→确认后进入下一节。这样比一次性写完再改要高效得多。我在写技术方案文档时就用这个方法。每个循环写一个小节写完立刻让AI检查事实错误和逻辑漏洞确认后继续。最后整篇文档的返工率比一次性写完低很多。6.6 循环工程的边界循环工程不是万能的。对于探索性任务——比如“我不知道这个功能该怎么实现先试试看”——循环工程反而会限制思路。这种情况下应该先做一次自由探索找到方向后再用循环工程来落地。另外对于非常小的改动——比如改一个变量名、修一个拼写错误——循环工程的开销大于收益。直接改就行不需要走完整循环。判断标准是如果改动的影响范围你完全清楚而且验证成本极低就不需要循环。我个人的习惯是改动涉及三个以上文件或者涉及核心逻辑就走循环工程否则直接改。这个阈值可以根据项目情况调整。6.7 一个容易被忽略的细节循环之间的休息连续做五六个循环后注意力会下降Verify阶段容易走神。我的做法是每做完三个循环强制休息五分钟站起来走走回来再继续。这五分钟的投入能避免因为疲劳导致的验证疏漏很划算。循环工程的本质是用纪律换确定性。它不会让单次操作变快但会让整个任务的总耗时和总风险大幅下降。对于需要保证质量的工程任务这个交换是值得的。
阅读完成 · 觉得有帮助？
