1. 从“会写代码”到“会设计循环”Loop Engineering 到底在解决什么问题第一次听到 Loop Engineering 这个词很多人会以为是某种新的编程语言或者框架。其实不是。它更像是一种工程方法论核心就一句话把 AI 编程工具从“一次性问答”变成“可重复、可验证、可迭代的自动化循环”。你不再是一句一句地给 AI 喂提示词而是设计一套让 AI 自己跑起来、自己检查、自己修正的闭环系统。我最早接触这个概念是在用 Claude Code 做一个小型重构项目的时候。当时我发现自己陷入了一个很尴尬的境地每次让 AI 改代码它改完我都要手动跑测试、手动看 diff、手动把错误信息再贴回去。一轮下来我花在“搬运信息”上的时间比写代码还多。后来我意识到问题不在于 AI 不够聪明而在于我没有给它设计一个能自己获取反馈的循环。这就是 Loop Engineering 要解决的核心痛点。具体来说Loop Engineering 涉及几个关键要素。第一是触发机制也就是什么条件下启动一轮循环比如代码提交后、测试失败后、或者定时触发。第二是执行体也就是谁来干活可能是 Claude Code、Codex、Cursor 这类工具也可能是它们组合使用。第三是验证层这是最容易被忽略但最关键的部分你需要有自动化的测试、lint、类型检查来告诉 AI“你刚才那步做对了没有”。第四是反馈回路把验证结果结构化地传回给 AI让它基于真实反馈做下一轮决策。第五是终止条件什么时候循环结束是测试全绿、达到最大轮次、还是人工确认。这套东西听起来有点像 CI/CD但区别在于 CI/CD 的“执行体”是确定性的脚本而 Loop Engineering 的执行体是概率性的 AI。这就带来了一个根本性的挑战你不能假设 AI 每次都对但你可以设计一个让它错了也能自己发现并纠正的机制。这也是为什么 Harness Engineering 这个词经常和 Loop Engineering 一起出现——Harness 原意是“马具”在工程语境里指的是给 AI 套上一套约束和引导装置让它在一个可控的范围内发挥能力。适合学这套东西的人我觉得有三类。第一类是已经在用 Claude Code、Codex、Cursor 这些工具但感觉效率卡在某个瓶颈上的开发者。第二类是想把 AI 编程引入团队流程但担心不可控、不可审计的技术负责人。第三类是对自动化工作流本身感兴趣想理解“AI 参与下的循环系统”和传统自动化有什么区别的工程师。如果你属于这三类中的任何一类接下来的内容应该能给你一些可以直接抄作业的思路。2. 工具选型与核心思路拆解为什么是 Claude Code Codex Cursor 的组合2.1 三个工具在循环里各自扮演什么角色很多人会问Claude Code、Codex、Cursor 到底选哪个我的答案是不要选要组合。它们各自的能力边界不一样在 Loop Engineering 的框架里可以形成互补。Claude Code 的优势在于终端原生和长上下文推理。它可以直接在你的项目目录里执行命令、读文件、写文件而且对复杂重构任务的理解能力比较强。我在做跨文件重构的时候Claude Code 能一次性理解十几个文件的依赖关系这是它最值钱的地方。但它的短板是响应速度和成本如果你让它跑一个高频循环账单会很难看。Codex 的优势在于代码补全的精准度和与编辑器的深度集成。它在单文件、局部修改的场景下反应极快适合做循环里的“快速修正”环节。比如测试报了一个类型错误Codex 能在你还没反应过来的时候就给出修复建议。但它的全局视野不如 Claude Code复杂任务容易迷路。Cursor 的优势在于交互体验和多模型切换。它本身不是一个模型而是一个编辑器层面的调度器。你可以在 Cursor 里同时配置 Claude 和 GPT 系列的模型根据任务类型切换。在 Loop Engineering 里Cursor 更适合作为人工介入的入口——当循环跑到需要人类判断的时候你在 Cursor 里看一眼 diff决定是继续还是回滚。所以一个典型的循环架构是这样的Claude Code 负责“大动作”比如根据 issue 描述生成初始实现Codex 负责“小修正”比如根据 lint 错误快速打补丁Cursor 负责“人工闸门”在关键节点让你确认方向。三者通过文件系统和 Git 历史来传递状态而不是通过复杂的 API 编排。2.2 为什么不用“全自动一条龙”我试过让一个工具从头跑到尾结果很惨。Claude Code 在连续跑了七八轮之后开始“幻觉”它会反复修改同一个文件每次都说“这次应该对了”但测试依然失败。后来我分析原因发现是反馈信息没有被结构化地压缩。每一轮它都拿到一大堆原始日志上下文越来越长信噪比越来越低最后它就迷失了。这让我意识到一个关键设计原则循环的每一轮传给 AI 的反馈必须是经过提炼的、结构化的、可操作的。比如不要直接把 500 行测试日志丢给它而是提取出“哪个测试失败了、期望值是什么、实际值是什么、错误类型是什么”这四要素。这个提炼工作可以由脚本完成也可以由另一个 AI 实例完成但绝对不能省。另一个原则是循环要有“刹车”。我现在的做法是设置三层终止条件第一层是测试全绿自动停止第二层是连续三轮没有进展就暂停并通知我第三层是单轮修改超过 200 行就强制人工确认。这三层刹车让我在享受自动化的同时不至于第二天早上起来发现代码库被改得面目全非。2.3 Harness Engineering 在其中的位置Harness Engineering 这个词最近被提得很多我的理解是它是 Loop Engineering 的“约束层”。Loop 解决的是“怎么让 AI 转起来”Harness 解决的是“怎么让 AI 不跑偏”。具体到实操层面Harness 包括几个东西一是权限边界比如 AI 只能改 src 目录下的文件不能碰配置文件二是操作白名单比如只允许执行 npm test 和 npm run lint不允许执行任意 shell 命令三是变更审计每一轮修改都要有 Git commit方便回滚和追溯。我自己的项目里Harness 是通过一个简单的 shell 脚本实现的。这个脚本在每一轮循环开始前检查当前 Git 状态是否干净在每一轮结束后自动 commit 并打 tag。如果某一轮修改了白名单之外的文件脚本会直接拒绝并回滚。这套东西不复杂但能挡住 90% 的“AI 手滑”事故。3. 核心细节解析与实操要点从零搭建一个可跑的循环3.1 环境准备Claude Code 和 Codex 的安装与配置先说 Claude Code 的安装。官方推荐的方式是通过 npm 全局安装命令是npm install -g anthropic-ai/claude-code。装完之后在项目目录下运行claude就能启动。第一次启动会引导你完成认证按照提示走就行。这里有个小坑如果你在 Ubuntu 上遇到权限问题不要用 sudo 装而是配置 npm 的全局目录到用户空间具体是npm config set prefix ~/.npm-global然后把~/.npm-global/bin加到 PATH 里。这样后续升级和插件管理都会顺畅很多。Codex 的安装取决于你用哪个版本。如果是 VS Code 插件形态直接在扩展市场搜 Codex 安装即可。如果是 CLI 形态通常是通过npm install -g openai/codex或者对应的包管理器。装完之后需要配置 API key建议放在环境变量里而不是硬编码在配置文件里。Windows 用户如果遇到“无法加载组织设置”的报错大概率是配置文件路径问题检查一下%APPDATA%下的配置目录是否存在。Cursor 的安装最简单官网下载安装包一路下一步。装完之后建议先做两件事一是设置中文回复在设置里搜“language”或者直接在 AI 对话里说“请用中文回复”Cursor 会记住这个偏好二是配置模型在设置里填入你的 API key选择默认模型。如果你同时有 Claude 和 GPT 的 key可以配置多个模型在对话时手动切换。注意所有工具的 API key 都不要提交到 Git 仓库。建议用.env文件管理并把.env加入.gitignore。我见过不止一个项目因为 key 泄露被刷爆账单的。3.2 循环的骨架一个最小可用的脚本下面是我自己在用的一个最小循环脚本用 bash 写的不依赖任何复杂框架。你可以直接复制到项目根目录改改变量就能跑。#!/bin/bash MAX_ROUNDS5 PROJECT_DIR$(pwd) LOG_DIR$PROJECT_DIR/.loop-logs mkdir -p $LOG_DIR for round in $(seq 1 $MAX_ROUNDS); do echo Round $round # 第一步让 Claude Code 根据当前状态做修改 claude --prompt 请阅读 .loop-logs/last-feedback.txt 中的反馈修复对应问题。只修改 src 目录下的文件。 \ --output $LOG_DIR/round-$round-output.txt # 第二步跑测试和 lint npm test $LOG_DIR/round-$round-test.txt 21 TEST_EXIT$? npm run lint $LOG_DIR/round-$round-lint.txt 21 LINT_EXIT$? # 第三步如果全绿就退出 if [ $TEST_EXIT -eq 0 ] [ $LINT_EXIT -eq 0 ]; then echo All checks passed at round $round git add -A git commit -m loop: round $round passed exit 0 fi # 第四步提炼反馈写入下一轮的输入 node scripts/extract-feedback.js \ $LOG_DIR/round-$round-test.txt \ $LOG_DIR/round-$round-lint.txt \ $LOG_DIR/last-feedback.txt # 第五步提交本轮修改方便回滚 git add -A git commit -m loop: round $round attempt done echo Max rounds reached without success. Manual intervention needed. exit 1这个脚本的核心逻辑就是改 - 测 - 提炼 - 再改。其中extract-feedback.js是关键它负责把原始日志压缩成 AI 能理解的短反馈。我后面会详细讲这个脚本怎么写。3.3 反馈提炼把 500 行日志变成 5 行有效信息很多人循环跑不起来问题就出在反馈提炼这一步。直接把原始日志丢给 AI它会淹没在噪音里。我的做法是写一个简单的 Node 脚本做三件事提取失败测试的名称、提取期望值和实际值的差异、提取 lint 错误的文件行号和规则名。// scripts/extract-feedback.js const fs require(fs); const testLog fs.readFileSync(process.argv[2], utf8); const lintLog fs.readFileSync(process.argv[3], utf8); const lines []; // 提取测试失败信息 const failRegex /FAIL\s(.?)\n.*?Expected:\s*(.?)\n.*?Received:\s*(.?)\n/gs; let match; while ((match failRegex.exec(testLog)) ! null) { lines.push(测试失败: ${match[1].trim()}); lines.push( 期望: ${match[2].trim()}); lines.push( 实际: ${match[3].trim()}); } // 提取 lint 错误 const lintRegex /(\S\.\w):(\d):(\d)\s-\s(.)/g; while ((match lintRegex.exec(lintLog)) ! null) { lines.push(Lint 错误: ${match[1]}:${match[2]} - ${match[4].trim()}); } if (lines.length 0) { lines.push(没有检测到明确的失败信息请检查测试输出格式是否匹配。); } console.log(lines.join(\n));这个脚本不复杂但效果立竿见影。原来 AI 要处理几千 token 的日志现在只需要处理几十 token 的结构化反馈准确率和速度都上来了。你可以根据自己项目的测试框架调整正则核心思路就是只保留可操作的信息。3.4 权限边界让 AI 只碰该碰的东西Harness 的核心是权限控制。我的做法是在项目根目录放一个.loop-config.json里面定义允许修改的目录和允许执行的命令。{ allowedPaths: [src/, tests/], allowedCommands: [npm test, npm run lint, npm run build], maxLinesPerRound: 200, requireCommitPerRound: true }然后在循环脚本里加一个检查步骤每一轮结束后用git diff --stat看修改了哪些文件如果超出 allowedPaths 就自动回滚。这个检查用几行 shell 就能实现CHANGED$(git diff --name-only HEAD) for file in $CHANGED; do if [[ ! $file ~ ^(src/|tests/) ]]; then echo 越界修改: $file回滚本轮 git checkout -- . exit 1 fi done这套东西看起来简陋但实际跑起来非常有效。我试过故意让 AI 去改package.json脚本在 0.5 秒内就回滚了完全没有造成污染。4. 实操过程与核心环节实现一个真实的重构项目复盘4.1 项目背景与初始状态我拿一个真实的小项目来演示一个用 TypeScript 写的命令行工具大概 2000 行代码有 40 多个单元测试。项目本身功能是正常的但代码结构比较乱很多函数超过 100 行类型定义散落在各个文件里。我的目标是让 AI 在循环里自动完成重构拆分长函数、统一类型定义、保持测试全绿。初始状态是测试全绿lint 有 12 个 warning没有 error。我把这个状态作为起点打了一个 Git tag 叫pre-loop。4.2 第一轮让 Claude Code 做“大扫除”第一轮我给的提示词是这样的请阅读项目结构找出所有超过 80 行的函数将它们拆分为多个小函数。 要求 1. 不改变任何对外行为所有测试必须保持通过。 2. 拆分后的函数要有清晰的命名和类型标注。 3. 只修改 src 目录下的文件。 4. 每完成一个文件的修改简要说明改了什么。Claude Code 跑了大概三分钟修改了 7 个文件新增了 23 个小函数。然后我跑测试结果 40 个测试里有 3 个失败了。失败原因都是“函数返回值类型不匹配”——它在拆分的时候把某个函数的返回类型从PromiseUser改成了PromiseUser | null但没有更新调用方的处理逻辑。这时候反馈提炼脚本发挥作用了。它提取出三个失败测试的名称和期望/实际值写入last-feedback.txt。第二轮 Claude Code 拿到这个反馈只用了 40 秒就修好了这三个问题。测试全绿lint warning 从 12 个降到 4 个。4.3 第二轮让 Codex 做“精细打磨”第二轮我换了个策略不再让 Claude Code 做大范围修改而是让 Codex 针对剩下的 4 个 lint warning 做定点修复。Codex 的优势在这里体现得很明显它直接在每个 warning 的位置给出修复建议我只需要确认应用。4 个 warning 在 2 分钟内全部解决而且没有引入任何新问题。这一轮我没有用自动化循环而是半自动Codex 给建议我点确认。原因是 lint warning 往往涉及代码风格偏好有些 warning 是“可以修但没必要”的让 AI 全自动修可能会过度改动。在循环里保留人工闸门有时候比全自动更高效。4.4 第三轮引入 Cursor 做人工审查重构完成后我在 Cursor 里打开 diff 视图整体看了一遍。Cursor 的好处是它能把 AI 的修改按文件、按块展示我可以快速扫一遍哪些改动是合理的、哪些是多余的。我发现有一处它把一个本来很清晰的函数拆成了三个更小的函数反而增加了理解成本。我在 Cursor 里手动合并了回去然后提交。这一轮让我意识到Loop Engineering 不是要消灭人工而是要把人工放在最需要判断力的位置。前面的机械性修改交给循环最后的审美和架构判断留给人。这个分工比“全自动”或者“全手动”都更高效。4.5 关键参数与选择依据在整个实操过程中有几个参数是我反复调整后确定下来的列出来供参考。参数初始值调整后调整理由最大循环轮次105超过 5 轮还没搞定说明问题定义不清继续跑是浪费单轮最大修改行数无限制200超过 200 行的修改很难审查容易藏 bug反馈提炼粒度原始日志结构化四要素原始日志噪音太大AI 容易迷失测试超时30s120s重构后测试变慢30s 会误判为失败Git commit 频率每轮结束每轮开始和结束方便对比“改之前”和“改之后”这些参数没有绝对的最优值要根据项目规模和 AI 工具的响应速度来调。我的建议是先从保守值开始跑几轮之后再逐步放宽。比如最大轮次先设 3如果发现经常不够用再加到 5。5. 常见问题与排查技巧实录5.1 循环跑不起来先检查这五个地方我遇到过很多次“脚本跑了但 AI 没反应”的情况排查下来基本都是这几个原因。第一是认证过期Claude Code 的 token 有时候会失效重新登录一下就好。第二是工作目录不对脚本必须在项目根目录跑否则 AI 找不到文件。第三是提示词里的文件路径写错了AI 读不到反馈文件就会瞎猜。第四是测试命令的退出码不对有些测试框架即使失败也返回 0导致循环误判为成功。第五是Git 状态不干净上一轮的修改没提交这一轮的 diff 就乱了。排查顺序建议先手动跑一次 AI 命令看有没有输出再手动跑一次测试看退出码最后检查 Git status。这三步能定位 80% 的问题。5.2 AI 反复改同一个地方怎么办这是最典型的问题。AI 在第一轮改了一个函数测试失败第二轮它又改回去测试还是失败第三轮再改过来……陷入死循环。我的解决方法是在反馈里加入历史信息。具体来说在last-feedback.txt里不仅写当前失败信息还写“上一轮你已经尝试过 X 方案没有成功请换一个思路”。这个简单的提示能打破大部分死循环。另一个技巧是限制单轮修改范围。如果 AI 连续两轮都在改同一个文件第三轮就强制它只能改其他文件。这个逻辑可以在脚本里用git diff --name-only的历史记录来实现。5.3 测试太慢导致循环效率低重构项目里测试跑一次要 90 秒五轮循环就是 7 分半大部分时间花在等测试上。我的优化方法是分层测试循环里只跑受影响的测试文件全量测试留到循环结束后跑一次。具体做法是用jest --findRelatedTests或者类似的命令只跑和修改文件相关的测试。这样单轮测试时间从 90 秒降到 15 秒左右。但这里有个坑相关测试可能漏掉跨模块的回归问题。我的折中方案是循环里跑相关测试循环结束后强制跑一次全量测试。如果全量测试挂了就回到循环里再跑几轮。这样既保证了速度又不会漏掉问题。5.4 常见问题速查表现象可能原因解决方法AI 无输出认证过期或工作目录错误重新登录检查 pwd测试退出码始终为 0测试框架配置问题检查 jest/mocha 的 exit code 配置循环超过 5 轮无进展问题定义不清或反馈噪音太大重新写提示词优化反馈提炼脚本AI 修改了不该改的文件权限边界没生效检查 allowedPaths 配置和回滚逻辑修改后测试全挂AI 理解错了任务回滚本轮把提示词写得更具体循环跑完但代码质量差缺少人工审查环节在循环后加 Cursor 人工 reviewAPI 费用超预期循环轮次太多或上下文太长降低最大轮次优化反馈提炼5.5 几个我踩过的坑第一个坑是在循环里跑npm install。有一次 AI 觉得某个依赖版本不对自己跑了npm install结果把 lock 文件改得面目全非。后来我把npm install加进了命令黑名单只允许跑测试和 lint。第二个坑是让 AI 自己写测试。我试过让循环里的 AI 在修 bug 的同时补测试结果它写的测试全是“断言 true 等于 true”这种废话。后来我改成测试必须由人写AI 只负责让现有测试通过。第三个坑是忽略 Git 历史。有一轮 AI 的修改把之前修好的 bug 又改回来了因为它的上下文里没有“之前修过什么”的信息。后来我在每轮开始前把最近三次 commit 的 message 喂给它这个问题就少了很多。6. 循环之外的思考这套方法适合什么、不适合什么6.1 适合的场景Loop Engineering 最适合的是有明确验证标准的重复性任务。比如让测试从红变绿、修复 lint 错误、统一代码风格、升级依赖版本、补全类型定义。这些任务的共同点是有客观的“对错”判断AI 可以自己验证自己。另一个适合的场景是大规模但低风险的修改。比如把 100 个文件里的var改成const或者把某个 API 的调用方式统一更新。这种任务人工做很枯燥AI 做很快而且有测试兜底风险可控。6.2 不适合的场景反过来没有明确验证标准的任务不适合放进循环。比如“让代码更优雅”、“优化架构”、“提升可读性”这些没有客观标准AI 改完之后你没法自动判断好坏循环就转不起来。高风险的核心逻辑修改也不适合。比如支付流程、权限校验、数据迁移这些一旦改错后果严重必须人工逐行审查。循环可以用在这些模块的测试补全上但不能用在逻辑修改上。6.3 一个实用的判断标准我自己的判断标准很简单如果这个任务你能写出一个自动化的“通过/不通过”判断就适合放进循环如果判断标准需要人的主观判断就不适合。这个标准帮我省了很多试错时间。7. 从单循环到多循环进阶玩法7.1 嵌套循环的思路当项目变大之后单个循环可能不够用。我现在的做法是外层循环管方向内层循环管细节。外层循环每跑一轮让 AI 看一遍整体测试报告和代码覆盖率决定下一步该修哪个模块。内层循环针对这个模块跑具体的修复循环。这样既保证了全局视野又保证了局部效率。实现上外层循环可以用一个简单的调度脚本根据覆盖率报告生成任务列表然后对每个任务调用内层循环脚本。内层循环就是我前面讲的那个最小循环。7.2 多工具协作的循环另一个进阶玩法是让不同工具负责不同阶段。比如Claude Code 负责生成初始实现Codex 负责根据测试反馈做快速修正Cursor 负责最后的人工审查。这三个阶段可以串成一个更大的循环如果人工审查不通过就把审查意见反馈给 Claude Code重新走一遍。这种多工具协作的难点在于状态传递。我的做法是用一个共享的state.json文件记录当前阶段、上一轮结果、待办事项。每个工具在开始工作前先读这个文件工作结束后更新这个文件。这样即使工具之间没有直接通信也能通过文件系统保持同步。7.3 循环的监控与告警循环跑起来之后你需要知道它什么时候卡住了。我的做法是加一个简单的监控脚本每 30 秒检查一次循环日志的最后修改时间。如果超过 5 分钟没有更新就发一个通知邮件或者即时消息。这个脚本用stat命令加cron就能实现不需要复杂的监控系统。另外建议在循环脚本里加一个心跳输出每一轮开始和结束都打印时间戳和当前状态。这样即使你不盯着看事后也能通过日志分析哪一轮花了最长时间、哪一轮修改最多。8. 一些个人体会和后续可以扩展的方向这套 Loop Engineering 的方法我用了大概三个月最大的感受是它改变了我对“写代码”这件事的认知。以前我觉得写代码就是一行一行敲现在我觉得写代码更像是设计一个系统让系统自己去完成那些重复性的工作。我的角色从“执行者”变成了“设计者”和“审查者”。但我也要泼一盆冷水Loop Engineering 不是银弹。它解决的是“重复性验证和修正”的问题不解决“创造性设计”的问题。你依然需要自己想清楚要做什么、为什么这么做、架构怎么设计。AI 能帮你把想法落地得更快但不能替你想。后续我打算尝试的方向有两个。一是把循环和 CI 打通让每次 push 自动触发一轮循环在 CI 环境里跑测试和修复。二是引入多模型投票机制同一个问题让 Claude 和 GPT 分别给方案取共识部分减少单模型的偏见。这两个方向都还在实验阶段等跑通了再写出来分享。如果你也在用类似的方法欢迎交流。踩过的坑越多这套东西就越成熟。