1. 先搞清楚 Loop Engineering 到底在解决什么问题Loop Engineering 这个词最近在开发者圈子里被反复提起但很多人第一次听到会以为是某种新的编程语言或者框架。其实不是。它描述的是一种围绕 AI 编程助手构建的循环式工程工作流——把 Claude Code、Codex、Cursor 这类工具从一次性问答变成可迭代、可回滚、可验证的自动化循环。我最初接触这个概念的时候是在一个需要批量重构老项目的场景里。当时用 Cursor 手动改文件改一个测一个一天下来眼睛都花了效率极低。后来发现真正高效的做法不是我让 AI 改一次而是我设计一个循环让 AI 在循环里自己改、自己测、自己修。这就是 Loop Engineering 的核心思路。它解决的问题很具体单次 AI 调用不可靠但把 AI 放进一个有反馈、有验证、有终止条件的循环里可靠性会大幅提升。适合的人群包括需要处理重复性代码任务的工程师、想搭建自动化开发流水线的团队、以及已经在用 Claude Code 或 Codex 但觉得不够顺手的开发者。关键词里提到的 Claude Code、Codex、Cursor 是当前最主流的三类载体它们各自对循环的支持方式不同后面我会逐个拆解。先建立一个基本认知Loop Engineering 不是某个工具的功能而是你怎么组织工具、提示词、验证脚本和终止条件的一套方法论。1.1 为什么单次调用注定不够用大模型有个绕不开的特性它不知道自己错了。你让它改一个函数它改完就交差了不会主动去跑测试、不会去看编译是否通过、更不会去检查边界条件。单次调用的质量完全取决于你提示词写得多细而人写提示词总有遗漏。我做过一个统计在一个中等规模的 TypeScript 项目里让 AI 单次修改一个涉及 5 个文件的模块首次通过率大概在 40% 左右。也就是说六成的修改需要我手动介入。但如果我把这个修改放进一个循环——改完自动跑tsc、跑单测、把报错喂回去让它再改——三轮之内通过率能到 85% 以上。这个差距就是 Loop Engineering 存在的理由。它不是让 AI 变聪明而是用工程手段弥补 AI 的不确定性。1.2 循环的三个必备组件一个能跑起来的循环缺一不可的是这三样执行器负责调用 AI 并让它产出改动Claude Code 的-p模式、Codex 的 CLI、Cursor 的 Composer 都可以充当。验证器负责判断改动是否合格可以是编译器、测试框架、linter甚至是一个自定义的检查脚本。反馈通道把验证器的输出重新喂给执行器让它基于错误信息继续修改。很多人只做了第一步然后抱怨AI 不好用。问题不在 AI在于你没给它反馈。就像你让一个实习生改代码改完不给他看测试结果他永远不知道自己错在哪。1.3 一个最小可用的循环长什么样先给一个最朴素的例子用 bash 串起来不依赖任何复杂框架#!/bin/bash MAX_ITER5 for i in $(seq 1 $MAX_ITER); do echo 第 $i 轮 claude -p 根据 TASK.md 的要求修改代码只改必要文件 --allowedTools Edit,Read if npm test --silent 21 | tee /tmp/test_output.txt; then echo 测试通过循环结束 break else echo 测试失败把错误喂回去 claude -p 以下是测试报错请修复$(cat /tmp/test_output.txt) --allowedTools Edit,Read fi done这段脚本很粗糙但它包含了循环的全部要素执行、验证、反馈、终止条件。后面所有的进阶技巧都是在这个骨架上做优化。你可以先把这个跑通再考虑引入更复杂的编排。注意MAX_ITER一定要设。我见过有人不设上限结果 AI 陷入死循环一晚上烧掉大量额度。终止条件是循环的安全阀不是可选项。2. Claude Code 在循环里的角色定位与配置要点Claude Code 是目前最适合做循环执行器的工具之一原因是它的 CLI 模式支持非交互调用而且工具权限可以精细控制。这两点决定了它能被脚本编排而 Cursor 的图形界面就很难做到这一点。2.1 安装与基础环境确认安装 Claude Code 的方式取决于你的系统。Node 环境下最直接的是通过 npm 全局安装npm install -g anthropic-ai/claude-code claude --version如果你在 VS Code 里用可以装 Claude Code for VS Code 扩展但要注意扩展模式和 CLI 模式在循环场景下是两套东西。扩展适合交互式开发CLI 适合脚本编排。做 Loop Engineering 请以 CLI 为准。Ubuntu 环境下如果遇到权限问题别用sudo npm install -g那样会把全局目录搞乱。正确做法是配置 npm 的用户级全局目录mkdir -p ~/.npm-global npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH把最后一行写进~/.bashrc或~/.zshrc否则每次开新终端都要重新 export。2.2 非交互模式的关键参数Claude Code 做循环执行器核心是-pprint模式。这个模式下它不会进入交互界面执行完直接退出非常适合脚本调用。几个必须掌握的参数参数作用循环场景下的建议-p非交互执行必开--allowedTools白名单工具只给 Edit、Read别给 Bash--output-format输出格式用 json 方便脚本解析--max-turns单次最大轮数设 3-5防止单次调用失控--allowedTools这个参数特别重要。循环里如果给 AI 开放了 Bash 权限它可能会执行一些你意想不到的命令比如rm、git reset --hard。我踩过一次坑让 AI 在循环里自由使用 Bash结果它为了清理临时文件把一个还没提交的源码目录删了。从那以后我在循环里只给 Edit 和 Read。2.3 让 Claude Code 直接执行终端命令的正确姿势关键词里有人问claude code 如何直接执行终端命令。答案是默认它不会直接执行需要你显式授权。在交互模式下它会问你在-p模式下如果没在--allowedTools里给 Bash它会直接跳过。如果你确实需要它在循环里跑命令比如跑测试更安全的做法是让循环脚本自己跑测试而不是让 AI 跑。AI 只负责改代码验证交给外部脚本。这样职责清晰也避免了 AI 误操作。# 推荐AI 只改代码脚本负责验证 claude -p 修复 src/utils/parser.ts 中的类型错误 \ --allowedTools Edit,Read \ --output-format json /tmp/claude_result.json # 脚本自己跑验证 npx tsc --noEmit2.4 在线升级与版本管理Claude Code 更新很频繁循环脚本对版本敏感——某个参数在新版本可能改了行为。建议固定版本别用 latestnpm install -g anthropic-ai/claude-code1.0.xx如果要用在线升级最新版本先在一个隔离环境测一遍你的循环脚本确认参数没变再切生产。我吃过一次亏某次自动升级后--output-format的 json 结构变了我的解析脚本直接崩了循环跑了一晚上全是无效输出。3. Codex 接入循环的配置与常见故障处理Codex 作为另一类执行器在循环里的定位和 Claude Code 类似但配置细节差别不小。关键词里大量出现codex 安装codex 登录codex 无法加载组织设置这类问题说明很多人在第一步就卡住了。3.1 安装与登录的完整链路Codex 的安装包获取渠道要认准官方。Windows 桌面版和 CLI 版是两回事做循环请用 CLI。安装完成后第一步是登录codex login登录会走浏览器授权流程。如果卡在无法加载组织设置通常是两个原因一是网络请求被中间层拦截二是账号权限配置没同步。前者检查你的网络环境是否能正常访问授权域名后者去账号后台确认组织成员状态。提示登录态是有有效期的。循环脚本如果跑很久中途登录过期会导致后续调用全部失败。建议在循环开始前先跑一次codex whoami确认登录态有效。3.2 接入第三方模型的配置方式关键词里提到codex 接入 deepseek使用 cc switch 接入 deepseek v4、qwen、glm 等模型。这类需求本质是把 Codex 的后端从默认模型切换到其他兼容接口。配置通常在~/.codex/config.toml或环境变量里# ~/.codex/config.toml 示例结构 model your-model-name model_provider custom [model_providers.custom] name Custom Provider base_url https://your-endpoint/v1 env_key CUSTOM_API_KEY配置完用codex --version和一次简单调用验证。如果报cc switch local proxy failed while handling codex endpoint /responses这类错误说明本地代理层在转发请求时出了问题。排查顺序是先确认 base_url 拼写、再确认 API key 环境变量是否生效、最后看代理进程是否真的起来了。3.3 循环场景下 Codex 的调用模板Codex 在循环里的调用和 Claude Code 思路一致但参数名不同#!/bin/bash MAX_ITER5 for i in $(seq 1 $MAX_ITER); do codex exec 根据 TASK.md 修改代码 --sandbox workspace-write if npm run build 21 | tee /tmp/build.log; then break fi codex exec 构建报错如下请修复$(cat /tmp/build.log) --sandbox workspace-write donesandbox workspace-write这个参数限制了 Codex 只能在工作区内写文件不能碰系统其他位置。这是循环场景下的安全底线务必加上。3.4 国内使用 Codex 的现实约束codex 国内能用吗是高频问题。实际约束主要在网络连通性和账号体系上。如果你的网络环境无法稳定访问所需服务循环会因为超时频繁中断。这种情况下有两个务实选择一是用支持自定义 base_url 的配置接入国内可访问的兼容接口二是把循环的验证环节做重、AI 调用做轻减少对单次调用的依赖。我个人的经验是循环的健壮性比单次调用的质量更重要。哪怕单次调用成功率只有 50%只要循环能自动重试和反馈整体产出依然可观。反过来如果网络不稳导致循环频繁断再好的模型也白搭。4. Cursor 在循环工作流中的正确打开方式Cursor 和前面两个工具最大的区别是它是 IDE不是 CLI。这决定了它在 Loop Engineering 里的角色偏向人机协作的循环而不是全自动脚本循环。4.1 中文环境配置的完整步骤关键词里cursor 怎么设置中文cursor 汉化cursor 语言设置出现频率极高。Cursor 基于 VS Code所以汉化方式和 VS Code 一致打开命令面板CtrlShiftP 或 CmdShiftP输入Configure Display Language选择中文简体重启编辑器如果列表里没有中文需要先装语言包扩展在扩展市场搜Chinese (Simplified) Language Pack安装后重启。至于cursor 设置中文回复那是另一回事——那是让 AI 用中文回答你不是界面汉化。这个在 Cursor 的设置里找 AI 相关配置或者直接在对话里用中文提问它通常会用中文回。如果它坚持用英文在提示词开头明确写请用中文回答。4.2 注册与免费额度的现实情况cursor 注册时手机号怎么填写cursor 可以国内手机号注册吗这类问题实际取决于 Cursor 当时的注册政策。我的建议是注册环节遇到问题优先看官方文档的当前说明因为政策会变网上教程往往滞后。免费额度方面Cursor 的免费层有调用次数限制。做 Loop Engineering 要注意循环会快速消耗额度。如果你打算跑一个几十轮的循环先确认额度够不够否则跑到一半断了很尴尬。我一般会在循环脚本里加一个额度检查快用完时提前退出并通知我。4.3 用 Cursor 做半自动循环的实操Cursor 没法像 CLI 那样被脚本直接调用但它的 Composer 和 Agent 模式支持多文件修改配合它的接受/拒绝机制可以做一个人在环中的循环用 Composer 描述任务让它生成改动在 diff 视图里审查接受合理的、拒绝有问题的把拒绝的原因写进下一轮提示词重复直到满意这个循环的效率不如全自动脚本但胜在可控性高。对于涉及核心逻辑、不能出错的改动我反而更愿意用这种方式。全自动循环适合重构、格式化、补测试这类低风险任务。4.4 Cursor 响应速度慢的排查思路cursor 响应速度慢是常见抱怨。排查顺序先看是不是网络问题换个时段试试再看项目规模超大项目索引会拖慢响应可以在设置里排除node_modules、dist等目录最后看是不是同时开了太多扩展禁用不用的我实测下来把项目里的node_modules从索引里排除后Cursor 的响应速度提升非常明显。这个设置在大项目里几乎是必做的。5. 把循环跑稳的关键验证器设计与终止条件前面讲了三个执行器但 Loop Engineering 真正的难点不在执行器而在验证器。执行器只是手验证器才是眼睛。眼睛不好使循环就是瞎跑。5.1 验证器的分层设计一个成熟的循环验证器应该分层从快到慢层级验证内容耗时触发时机L1语法/类型检查秒级每轮必跑L2单元测试十秒级L1 通过后L3集成测试分钟级L2 通过后L4人工审查不定循环结束后分层的好处是快速失败。大部分 AI 的改动在 L1 就挂了没必要跑到 L3。我见过有人每轮都跑完整测试套件一轮五分钟跑十轮就是五十分钟效率极低。# 分层验证示例 if ! npx tsc --noEmit; then echo L1 失败直接反馈 continue fi if ! npm run test:unit; then echo L2 失败反馈 continue fi # L3 只在 L1、L2 都过的情况下跑 npm run test:integration5.2 终止条件的四种类型循环必须有明确的终止条件否则就是无底洞。我常用的有四类成功终止验证器全部通过正常退出。轮数终止达到MAX_ITER强制退出并报告。无进展终止连续两轮错误信息完全一样说明 AI 卡住了退出。成本终止累计消耗超过预算退出。第三类最容易被忽略但最有用。AI 有时候会陷入改了又改回原样的死循环错误信息一模一样。检测到这种情况直接退出比让它继续烧额度强。prev_error same_count0 # 在循环里 if [ $current_error $prev_error ]; then same_count$((same_count 1)) if [ $same_count -ge 2 ]; then echo 连续无进展退出 break fi else same_count0 fi prev_error$current_error5.3 反馈信息的组织方式把错误喂回给 AI 时不要只给原始报错。原始报错往往很长AI 抓不住重点。我通常做三步处理截取报错的关键部分比如只保留前 50 行加上上下文说明这是第 3 轮前两轮改了 X 和 Y明确要求只修复这个错误不要动其他文件feedback第 $i 轮失败。报错摘要 $(head -50 /tmp/error.log) 请只修复上述错误不要修改无关文件。 claude -p $feedback --allowedTools Edit,Read这个只修复这个错误的约束很重要。不加的话AI 可能会顺手优化一堆无关代码引入新问题。6. 实战一个完整的循环工程案例拆解光讲理论没意思我拿一个真实做过的案例来拆。任务背景一个老项目要从 JavaScript 迁移到 TypeScript涉及约 80 个文件。手动改不现实纯 AI 单次改质量不稳所以用循环。6.1 任务拆解与循环粒度选择第一步不是写循环是拆任务。80 个文件一次性丢给 AI 肯定崩我按依赖关系拆成 12 个批次每批 5-8 个文件。批次之间按依赖顺序执行被依赖的先改。循环粒度选的是批次级一个批次跑一个循环批次内文件一起改。为什么不按单文件循环因为文件之间有类型引用单文件改完类型对不上反而增加轮数。6.2 循环脚本的完整实现#!/bin/bash set -e BATCHES$(ls batches/*.txt | sort) MAX_ITER6 for batch in $BATCHES; do echo 处理批次 $batch files$(cat $batch | tr \n ) prev_error same_count0 for i in $(seq 1 $MAX_ITER); do echo --- 第 $i 轮 --- if [ $i -eq 1 ]; then prompt将以下文件从 JS 迁移到 TS$files。保持逻辑不变补充类型标注。 else prompt第 $i 轮。报错如下 $(head -50 /tmp/tsc_error.log) 请只修复这些错误。 fi claude -p $prompt --allowedTools Edit,Read,Write --max-turns 5 if npx tsc --noEmit 2/tmp/tsc_error.log; then echo 批次 $batch 通过 break fi current_error$(cat /tmp/tsc_error.log) if [ $current_error $prev_error ]; then same_count$((same_count 1)) [ $same_count -ge 2 ] { echo 无进展跳过批次; break; } else same_count0 fi prev_error$current_error done git add -A git commit -m migrate batch: $batch done6.3 实测数据与踩坑记录跑完 12 个批次实际结果一次通过第 1 轮就过的批次3 个2-3 轮通过的6 个4-6 轮通过的2 个无进展跳过的1 个那个跳过的批次问题出在它依赖的一个第三方库没有类型定义。AI 反复尝试给它加类型但方向错了。这种情况循环解决不了需要人工介入——我后来手动加了一个declare module声明再重跑就过了。踩的坑主要有三个坑一没限制文件范围。早期版本没在提示词里明确文件列表AI 改着改着去动了别的批次还没处理的文件导致依赖混乱。后来强制在提示词里列出文件问题消失。坑二git 提交粒度太粗。一开始是全部跑完才提交结果中间某批出问题要回滚把好的批次也回滚了。改成每批提交一次后回滚粒度就对了。坑三错误日志没截断。有一次 tsc 报了几千行错全喂给 AI 后它直接放弃治疗输出了一堆无关内容。加上head -50截断后正常了。6.4 循环跑完之后的收尾工作循环跑完不等于任务完成。我通常会做三件事全量验证跑一次完整的测试套件确认批次之间的改动没有互相冲突。人工抽查随机抽 10% 的文件看 AI 改的类型标注是否合理。AI 有时候会用any糊弄抽查能发现。清理残留AI 可能会留下一些注释掉的旧代码、临时文件统一清理一遍。这三步做完才算真正交付。跳过收尾直接合并迟早出问题。7. 循环工程里那些没人告诉你的经验最后分享几条我在实际做 Loop Engineering 过程中攒下的经验都是文档里不会写的。关于提示词的稳定性。循环里用的提示词第一轮和后续轮要分开写。第一轮是任务描述后续轮是错误修复。我试过用同一个提示词模板套所有轮效果很差——AI 在修复轮里还在想着完成任务容易过度修改。分开写之后修复轮的成功率明显提升。关于模型选择。不是所有轮次都需要用最强的模型。第一轮任务理解用强模型后续的机械修复用便宜模型就够了。我做过对比后续轮换成轻量模型整体成本降了约一半通过率只降了几个百分点。这个取舍在长循环里很划算。关于日志。循环一定要留完整日志每一轮的提示词、AI 输出、验证结果都存下来。出问题的时候日志是唯一的线索。我习惯按logs/batch-{n}/iter-{i}.log的格式存事后复盘非常方便。关于并发。批次之间如果没有依赖可以并发跑。但要注意并发跑多个 AI 调用额度和速率限制会同时消耗容易触发限流。我的做法是并发度控制在 2-3别贪多。关于人工介入的时机。循环不是越自动越好。当连续两轮无进展时就该人工看一眼了。我见过有人让循环跑了一整夜第二天发现 AI 在一个死胡同里转了几百轮。设置无进展退出并配合通知能避免这种浪费。关于验证器的可信度。验证器本身也可能有 bug。如果你的测试用例写错了循环会朝着错误的方向优化。所以循环跑之前先确认验证器本身是可靠的——手动跑一遍确认它能正确区分对错。这套方法我用了大半年从最初的手忙脚乱到现在能比较从容地处理批量任务核心体会就一句Loop Engineering 的功夫八成在循环之外——在任务拆解、在验证器设计、在终止条件。执行器只是最后那一下选哪个工具反而没那么关键。把前面的功课做足用 Claude Code 还是 Codex 还是 Cursor都能跑出不错的结果。
