1. 从“写提示词”到“搭回路”Loop Engineering 到底在解决什么问题如果你最近半年一直在用 Claude Code、Codex、Cursor 这类 AI 编程工具大概率经历过这样一个阶段一开始觉得“哇一句话就能生成一个函数”用着用着发现不对劲——同一个需求反复描述三遍AI 每次给的实现都不一样改完 A 文件忘了 B 文件跑起来直接报错上下文一长模型开始“失忆”前面说过的约束后面全忘了。这不是模型不行而是我们一直在用“单次对话”的方式去驱动一个“多步骤工程”。Loop Engineering回路工程要解决的就是把这个过程从“碰运气式对话”变成“可重复、可验证、可迭代的工程回路”。我自己的理解是Loop Engineering 不是某个具体工具的功能而是一套围绕 AI 编程助手构建的工作方法论。它的核心是把一次任务拆成“规划—执行—验证—修正”四个环节每个环节都有明确的输入输出并且让 AI 在回路里自己跑起来而不是你一句我一句地喂。Claude Code 的 agent 模式、Codex 的自动化任务、Cursor 的 Composer 多文件编辑本质上都是在往这个方向走。这套东西适合谁如果你只是偶尔用 AI 补全几行代码那暂时用不上但如果你每天有大量重复性的编码、重构、调试任务或者你在带团队、想让 AI 稳定产出而不是“抽卡”那 Loop Engineering 就是必须跨过去的一道坎。下面我按自己实际搭回路的顺序从环境准备一直讲到问题排查尽量把每一步的“为什么”说清楚。2. 环境准备Claude Code、Codex、Cursor 三件套怎么装怎么配2.1 三个工具的定位差异与选型逻辑很多人一上来就问“哪个最好”这个问题本身就不对。这三个工具在 Loop Engineering 里扮演的角色不一样我一般是这么分的工具核心定位适合的回路环节典型场景Claude Code终端里的 agent能直接执行命令、读写文件执行 验证批量重构、跑测试、修 lintCodex云端/本地的任务型 agent规划 执行独立完成一个 feature 分支Cursor编辑器内的多文件编辑规划 修正交互式改代码、review diff选型逻辑很简单需要 AI 直接动终端、跑命令的用 Claude Code需要它独立完成一个完整任务的用 Codex需要你盯着它改、随时介入的用 Cursor。三者不是替代关系而是回路里不同环节的工具。2.2 Claude Code 安装与终端配置Claude Code 的安装方式取决于你的系统。macOS 和 Linux 下最省事的是用 npm 全局装npm install -g anthropic-ai/claude-codeWindows 下我建议用 WSL2原生 Windows 支持一直不太稳定。装完之后在项目根目录跑claude就能进交互模式。第一次用会让你登录按提示走就行。这里有个坑要提前说Claude Code 默认会在项目根目录找CLAUDE.md文件作为项目级上下文。这个文件非常关键后面讲回路设计时会重点说。如果你在 VS Code 里用装官方插件Claude Code for VS Code然后在设置里把终端路径指向你装好的 claude 可执行文件。Ubuntu 下配置时注意权限问题如果npm install -g报 EACCES别用 sudo 硬来改 npm 的全局目录mkdir ~/.npm-global npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH2.3 Codex 安装与配置文件解析Codex 现在有 CLI 和 IDE 插件两种形态。CLI 版本装完后核心是配置文件~/.codex/config.toml。这个文件决定了它用哪个模型、走哪个 endpoint、超时多久。一个我常用的基础配置长这样model gpt-5-codex approval_policy on-request sandbox_mode workspace-write [model_providers.local] name Local base_url http://localhost:8080/v1approval_policy这个参数值得展开说设成on-request时Codex 遇到需要写文件或跑命令会先问你设成never就是全自动适合你已经把回路跑通、信任它的时候。新手千万别一上来就never我见过太多人让 Codex 自动跑结果它把整个目录重写了。如果你遇到codex 无法加载组织设置这类报错九成是配置文件里的 provider 名字和实际 endpoint 对不上或者 token 过期了。先codex --version确认版本再检查 config.toml 的缩进——TOML 对缩进敏感[model_providers.local]下面的字段必须属于这个 section。2.4 Cursor 中文设置与注册注意事项Cursor 默认是英文界面设置中文的路径是CtrlShiftPmacOS 是CmdShiftP打开命令面板输入Configure Display Language选zh-cn重启即可。注意这是界面语言不是 AI 回复语言。要让 AI 用中文回复得在 Rules 里加一条Always respond in Chinese (Simplified).或者在.cursorrules文件里写同样的规则。很多人把这两个搞混以为设了界面中文 AI 就会说中文结果发现它还是英文回复。注册方面Cursor 支持邮箱注册国内手机号能不能用取决于当时的验证策略这个会变我不做保证。免费额度每个账号每月有一定次数的快速请求超出后降速但不完全断。如果你只是轻度使用免费额度基本够重度用的话还是建议上付费响应速度差别很明显。3. 回路设计的核心把一次任务拆成可验证的四个阶段3.1 为什么“一次性提示”必然失败先讲清楚问题。你给 AI 一个提示“帮我实现一个用户登录功能”它返回一堆代码。这个过程中发生了什么模型在它的上下文窗口里做了一次前向推理输出了一段它认为最可能的实现。问题在于它不知道你项目里已有的认证中间件长什么样它不知道你的数据库 schema它不知道你的代码风格约定它没法验证自己写的代码能不能跑所以它只能“猜”。猜对了是运气猜错了是常态。Loop Engineering 的第一个原则就是不要让 AI 猜把信息喂给它把验证交给它。3.2 四阶段回路规划、执行、验证、修正我自己的回路是这么搭的规划阶段先让 AI 读代码库输出一份实现计划。这一步不写代码只输出“我打算改哪些文件、每个文件改什么、依赖关系是什么”。Claude Code 里可以用claude 分析这个需求输出实现计划不要写代码。计划出来后你 review 一遍不对就让它改计划改到对为止。执行阶段计划确认后让 AI 按计划逐个文件改。这一步的关键是限制它的行动范围——一次只改一个文件或一个模块改完立刻进入验证。验证阶段这是最容易被忽略的一步。验证不是“看一眼代码觉得对”而是真的跑起来。Claude Code 可以直接执行终端命令所以验证就是让它跑测试、跑 lint、跑构建。Codex 的 sandbox 模式也能跑命令。Cursor 里你可以让它生成测试然后你手动跑。修正阶段验证失败后把错误信息原样喂回给 AI让它基于错误修正。注意是原样喂回不要自己总结错误因为你的总结可能丢信息。这四个阶段形成一个闭环每转一圈代码质量就往上走一层。转个三五圈基本就能收敛到一个可用的实现。3.3 上下文管理CLAUDE.md 和 .cursorrules 怎么写回路能不能跑起来很大程度上取决于 AI 有没有稳定的“项目记忆”。Claude Code 用CLAUDE.mdCursor 用.cursorrulesCodex 用AGENTS.md。这些文件的作用是一样的把项目级的约定固化下来让 AI 每次进回路都带着同样的背景知识。我自己的CLAUDE.md一般包含这几块# 项目约定 - 语言TypeScript严格模式 - 测试框架Vitest - 提交前必须跑npm run lint npm run test # 目录结构 - src/apiHTTP 接口层 - src/core业务逻辑 - src/db数据访问层 # 禁止事项 - 不要引入新的依赖除非明确说明理由 - 不要修改 package.json 的 scripts这个文件不用写太长但每一条都要是“AI 容易犯错的地方”。比如我项目里禁止在 core 层直接调 db 层这条写进去之后AI 生成的代码就很少越界了。3.4 回路的收敛条件什么时候停回路不能无限转。我一般设三个停止条件满足任意一个就停测试全绿且 lint 无报错连续两轮修正后错误数量没有减少达到预设的最大轮次我一般设 5 轮第二个条件特别重要。如果 AI 改了两轮错误还是那么多说明它卡住了继续转只是浪费 token。这时候应该人工介入看看是不是计划本身有问题或者上下文里缺了关键信息。4. 项目实战用回路跑一个真实的重构任务4.1 任务背景与初始状态我拿一个真实的小项目举例。这是一个 Node.js 写的 API 服务大概 3000 行代码问题是一堆接口的错误处理逻辑散落在各个 handler 里有的返回{error: xxx}有的返回{message: xxx}前端处理起来很痛苦。目标是把所有错误响应统一成一个格式。这个任务如果手动做大概要改 20 多个文件每个文件改法还不一样很容易漏。用回路跑我大概花了 40 分钟其中大部分时间在 review 计划。4.2 规划阶段让 AI 先读再写第一步我让 Claude Code 先分析代码库claude 扫描 src/api 下所有 handler找出所有返回错误响应的位置输出一份清单包含文件路径、行号、当前返回格式。不要修改任何文件。它跑了几分钟输出了一份 23 个文件的清单。我扫了一遍发现它漏了两个用throw new Error的地方手动补进去。这一步的价值在于AI 帮你做了机械性的扫描工作但判断还得你来。然后我让它基于清单输出重构计划claude 基于上面的清单输出重构计划。要求1. 定义一个统一的错误响应格式2. 每个文件怎么改3. 改完后怎么验证。不要写代码。计划出来后我重点看了两件事统一格式的定义是否合理以及验证方案是否可执行。它建议的格式是{code: number, message: string, details?: object}我觉得可以。验证方案是“跑现有测试 手动 curl 几个接口”我改成“跑现有测试 新增一个错误格式的单元测试”因为手动 curl 不可重复。4.3 执行阶段分批改改完就验计划确认后我没有让它一次性改完 23 个文件而是按目录分批。第一批改src/api/user下的 5 个文件claude 按计划修改 src/api/user 下的文件只改错误响应部分其他逻辑不动。改完后跑 npm run test:user。它改完跑了测试挂了 2 个。我把失败信息原样喂回去claude 测试失败信息如下粘贴原始输出。分析原因并修正。它发现是有一个地方它把res.status(400)改成了res.status(500)改回来就好了。这一批过了之后再改下一批。分批的好处是错误定位范围小。如果一次性改 23 个文件然后测试挂了你根本不知道是哪个文件的问题。分批改每批 5 个左右挂了立刻能定位。4.4 验证阶段测试、lint、构建三件套每批改完我固定跑三个命令npm run test npm run lint npm run build三个都过才算这批完成。这里有个经验lint 和 build 经常能抓到测试抓不到的问题。比如有一次 AI 改完测试全绿但 build 挂了因为它用了一个只在 devDependencies 里的类型。这种问题测试跑不出来只有构建时才暴露。4.5 修正阶段把错误原样喂回去修正阶段的核心技巧是不要自己总结错误把原始输出完整贴给 AI。我试过自己总结“测试挂了因为类型不对”结果 AI 按我的总结去改改错了方向。后来我改成贴原始报错它自己分析出来的原因比我准。还有一个技巧如果同一个错误改了两轮还没好就停下来把相关文件的完整内容贴给它让它重新读一遍上下文。很多时候是它的上下文里还留着旧版本的代码导致它基于错误的前提在改。5. 常见问题与排查技巧实录5.1 工具类问题速查问题现象可能原因排查方向cc switch local proxy failed本地代理端口被占用或配置错误检查 config 里的 base_url 端口lsof -i :端口看占用codex 无法加载组织设置config.toml 的 provider section 写错检查 TOML 缩进和 section 名codex 登录不上token 过期或网络问题重新登录检查系统时间是否准确Cursor 响应速度慢上下文太大或免费额度降速清理对话历史检查是否超出免费额度Claude Code 不执行终端命令权限未授予检查 approval 设置确认允许执行5.2 回路类问题AI 改不对怎么办这是最高频的问题。我的排查顺序是第一检查上下文是否完整。很多时候 AI 改不对是因为它没看到关键文件。让它先读相关文件再改。第二检查计划是否有问题。如果执行阶段反复出错回到规划阶段重新做计划。计划错了执行再努力也没用。第三缩小任务范围。如果一个大任务反复卡住把它拆成更小的子任务。我遇到过改一个复杂函数反复失败拆成“先改参数校验、再改业务逻辑、最后改错误处理”三步每步都一次过。第四换工具。有些任务 Claude Code 做不好但 Cursor 做得好反之亦然。别死磕一个工具。5.3 我踩过的三个坑坑一让 AI 一次改太多。刚开始我图省事让它一次改十几个文件结果错误定位极其痛苦。后来改成每批不超过 5 个文件效率反而高了。坑二不写 CLAUDE.md。有段时间我懒得维护项目约定文件结果 AI 每次生成的代码风格都不一样review 起来很累。写完之后代码一致性明显提升。坑三验证阶段偷懒。有几次我觉得“代码看起来对”就没跑测试结果提交后 CI 挂了。现在我强制自己每批必跑三件套不跑不进入下一批。5.4 关于 Codex 接入其他模型的说明Codex 的配置文件支持自定义 provider理论上可以接入任何兼容 OpenAI 接口的模型服务。配置方式是在config.toml里加一个[model_providers.xxx]section指定base_url和api_key。但要注意不同模型对 Codex 的 agent 协议支持程度不一样有些模型不支持 function calling接进来会报错。我试过几个稳定性差异很大建议先用小任务测试别直接上生产。6. 把回路跑顺之后我的工作流变成了什么样跑顺回路之后我每天的工作流大概是这样的早上到工位先把当天要做的任务列出来每个任务用 Codex 或 Claude Code 跑一遍规划输出计划。计划 review 完分批执行每批跑验证。中间遇到卡住的切到 Cursor 手动介入。下午基本就是在 review AI 改出来的代码和跑测试。这个流程跑下来我的实际编码时间大概减少了六成但 review 和验证的时间增加了。总体效率是提升的因为 review 比从零写快得多而且 AI 不会犯低级错误比如拼错变量名。有一点要提醒回路不是万能的。涉及架构决策、业务逻辑判断、性能优化的任务AI 给的建议经常不靠谱这些还是得自己来。回路适合的是那些“机械性强、验证标准明确”的任务比如重构、补测试、改格式、修 lint。把这些任务交给回路把精力留给真正需要思考的部分这才是 Loop Engineering 的正确用法。最后分享一个我最近在用的技巧给回路加一个“自检”步骤。在修正阶段结束后让 AI 自己 review 一遍改动输出“这次改动可能影响哪些其他模块”。很多时候它能发现你没想到的连带影响提前避免线上问题。这个步骤不费多少 token但价值很高。