1. 从写提示词到搭回路Loop Engineering 到底在解决什么问题如果你最近在折腾 Claude Code、Codex、Cursor 这类 AI 编程工具大概率经历过这样一个阶段一开始觉得哇一句话就能生成代码用着用着就发现不对劲——同一个需求第一次跑出来的结果还行第二次就飘了改了一个 bug结果引入了三个新 bug上下文一长模型开始失忆前面说过的约束后面全忘了。这不是模型不行而是你还在用单次对话的思维去驱动一个需要循环迭代的系统。Loop Engineering回路工程这个词最近在 AI 编程圈子里被反复提起本质上讲的是一件事把 AI 编程从一次性问答变成可循环、可验证、可收敛的工程流程。它不是一个具体的工具也不是某个厂商的专有概念而是一套围绕生成—验证—反馈—修正这个闭环来设计工作流的方法论。我自己的理解是Loop Engineering 要解决的核心痛点有三个不确定性收敛大模型的输出天然带随机性单次生成不可靠但通过多轮循环 明确的验证信号可以让结果逐步收敛到可接受范围。上下文管理长任务里上下文会爆炸回路工程强调每一轮只带必要信息而不是把所有历史都塞进去。责任边界AI 负责生成人负责定义什么叫完成。这个边界如果不清晰循环就永远停不下来。和它经常一起出现的是Harness Engineering脚手架工程。如果说 Loop Engineering 是怎么转这个圈那 Harness Engineering 就是给这个圈搭什么样的跑道——包括工具链配置、验证脚本、测试用例、目录结构、约束文件比如 CLAUDE.md、AGENTS.md 这类等等。两者是配套的没有好的 harnessloop 转起来就是空转没有 loopharness 就只是一堆静态配置。这篇内容我会按从零搭一套能跑起来的回路这个思路来讲覆盖 Claude Code、Codex、Cursor 三个主流工具的实际配置差异重点讲清楚为什么这么设计以及我在实操中踩过的坑。适合已经装好工具、但用起来总觉得差点意思的开发者也适合想系统理解 AI 编程工作流的同学。2. 先把跑道铺好Harness 层的目录结构与约束文件设计很多人一上来就急着让 AI 写代码结果发现它总是自作主张——该改的文件不改不该动的文件乱动命名风格和你项目完全不搭。这不是模型笨是你没给它铺跑道。2.1 为什么约束文件比提示词更重要提示词是这一轮的指令约束文件是每一轮都要遵守的规则。在 Loop Engineering 里约束文件是回路能够稳定运转的地基。因为循环意味着多轮交互如果每轮都要重新交代一遍项目规范一是浪费 token二是模型在长上下文里对早期指令的注意力会衰减。我习惯在项目根目录放一个CLAUDE.mdClaude Code 用或AGENTS.mdCodex 和部分工具通用内容大致分四块# 项目约束 ## 技术栈 - 语言TypeScript 5.x严格模式 - 框架Next.js 14 App Router - 包管理pnpm禁止使用 npm/yarn ## 目录约定 - 业务代码放 src/features/模块名/ - 通用工具放 src/lib/ - 测试文件与源文件同目录命名 *.test.ts ## 编码规范 - 禁止 any必要时用 unknown 类型守卫 - 组件一律函数式禁止 class 组件 - 所有异步操作必须有错误处理 ## 禁止事项 - 不要修改 package.json 的依赖版本 - 不要删除现有测试 - 不要引入新的第三方库除非我明确要求这份文件的关键在于**禁止事项这一节**。我踩过的最大坑就是AI 为了帮你解决问题会顺手升级依赖、删掉它认为冗余的测试、引入一个它觉得更优雅的库。这些操作在单次对话里看起来是优化但在一个循环流程里就是灾难——你根本不知道它哪一轮动了什么。提示约束文件不要写太长。超过 200 行模型对后半部分的遵守率会明显下降。把最关键的 5 到 8 条规则放前面细节可以拆到子目录的局部约束文件里。2.2 目录结构要为可验证服务Loop Engineering 的核心是验证信号。如果项目结构让验证变得困难循环就跑不起来。我的做法是把项目分成三层层级作用对循环的意义接口层API 路由、组件 props 定义提供稳定的契约AI 改实现不改契约实现层具体业务逻辑AI 主要在这里循环迭代验证层测试、类型检查、lint 脚本每轮循环的裁判验证层最关键。我会在package.json里固定几个脚本{ scripts: { check: tsc --noEmit eslint src --max-warnings 0, test:fast: vitest run --reporterdot, verify: pnpm check pnpm test:fast } }pnpm verify就是我的回路终止条件——只要它通过这一轮循环就算收敛。这个命令要足够快我一般控制在 30 秒内否则每轮都等两分钟人会疯。2.3 三个工具的 harness 配置差异Claude Code、Codex、Cursor 在读取约束文件这件事上行为不一样这点必须搞清楚否则你以为写了规则其实根本没生效。Claude Code默认读取项目根目录的CLAUDE.md也支持子目录的局部CLAUDE.md。它的读取是向上递归 向下继承所以你可以给src/features/payment/单独写一份约束只在这个目录下生效。Codex主要认AGENTS.md放在根目录。它对嵌套约束的支持不如 Claude Code 细建议把规则集中写。Cursor走的是.cursorrules旧或.cursor/rules/*.mdc新。新版支持按 glob 匹配文件类型比如只对*.tsx生效的规则这个粒度比前两者都细。我实测下来的建议是如果你三个工具都用就维护一份AGENTS.md作为主约束然后在CLAUDE.md和.cursor/rules/里用引用或复制的方式同步。别指望工具之间自动同步它们各读各的。3. 让回路真正转起来生成—验证—修正的实操循环跑道铺好了接下来讲怎么让这个圈转起来。这一节是整篇的核心我会把每一轮循环拆开讲包括每步在干什么、为什么这么干、以及怎么判断该继续还是该停。3.1 第一轮先要计划不要代码新手最容易犯的错是第一轮就让 AI 直接写代码。结果它写了一堆你一看方向就错了全白费。正确的做法是第一轮只让它输出计划。我的标准开场是这样的请先不要写代码。阅读 CLAUDE.md 的约束然后针对以下需求给出实现计划 1. 需要改动哪些文件列出完整路径 2. 每个文件改什么一句话说明 3. 需要新增哪些测试 4. 有没有不确定的地方列出来让我确认 需求给用户列表页加上按注册时间排序的功能。这个计划轮的价值在于它把方向错误的成本从改一堆代码降到改几行计划。我统计过自己的使用数据加了计划轮之后返工率大概降了一半以上。计划轮里我最关注的是第 4 点——不确定的地方。模型主动说我不确定排序是升序还是降序比它猜一个然后你事后发现要强得多。如果它一个不确定项都没列反而要警惕说明它在硬猜。3.2 第二轮小步生成一次只改一个关注点确认计划后进入生成轮。这里的关键原则是一次循环只解决一个问题。不要在一轮里说顺便把排序加上再把分页优化一下再修一下那个样式 bug。三个关注点混在一起一旦验证失败你根本不知道是哪部分出的问题。回路工程讲究的是可归因——每一轮的失败原因必须能定位到具体改动。我的做法是把计划拆成有序的小任务每轮只推进一个按计划执行第 1 步修改 src/features/user/api.ts 添加 sortBy 参数支持。只改这一个文件改完停下来。改完停下来这句话很重要。不加这句模型经常会顺手把后面几步也做了你就失去了逐步验证的机会。3.3 第三轮用验证信号做裁判而不是靠眼睛看代码生成完很多人习惯自己肉眼扫一遍觉得看起来没问题就过了。这是回路工程里最危险的习惯因为人的注意力有限而且你会不自觉地脑补代码是对的。正确的做法是让机器当裁判。每轮生成后立刻跑pnpm verify根据结果分三种情况处理全绿进入下一轮任务。类型/lint 报错把完整报错信息贴回给 AI让它只修报错不要动其他逻辑。测试失败这是最有价值的情况。把失败的测试名、期望值、实际值一起给它让它分析是测试写错了还是实现写错了。这里有个细节贴报错时不要只贴一行。我见过很多人只贴Type error: xxx模型只能猜上下文。正确的做法是把报错前后的代码位置、完整堆栈都给它。信息越完整一轮修好的概率越高。3.4 循环的终止条件什么时候该停回路工程最反直觉的一点是循环不是越多越好而是要设计好终止条件。我给自己定的终止规则有三条pnpm verify通过且我人工 review 后认可逻辑。连续两轮修复后同一个错误还在说明方向错了回退到计划轮重新想。单轮改动超过 5 个文件强制停下来拆分。第 2 条特别重要。我踩过的坑是一个类型错误反复修不好我就一直让它修结果它越修越乱最后把本来对的代码也改坏了。后来我定了两轮不过就回退的规矩效率反而高了——因为问题往往出在计划阶段而不是实现阶段。注意回退不是失败是回路工程的一部分。Git 的git stash或git checkout .是你的好朋友每轮开始前先 commit 一次回退成本几乎为零。4. 三个工具在回路里的分工与踩坑实录Claude Code、Codex、Cursor 虽然都能写代码但它们在回路里的性格完全不同。用对了事半功倍用错了就是互相折磨。这一节讲我的实际分工方案和踩过的坑。4.1 Claude Code适合当主循环引擎Claude Code 最大的优势是对项目上下文的把握和长任务的连贯性。它在读取CLAUDE.md、理解目录结构、跨文件改动这几件事上表现最稳。所以我把主循环放在它这里跑——从计划轮到生成轮再到修复轮全程用它。它的坑主要在权限和确认上。默认情况下它每做一个操作都要问你循环跑起来会非常碎。我的做法是在项目里配置好允许的操作范围把只读操作读文件、跑测试设为自动允许写操作保留确认。这样既安全又不打断节奏。另一个坑是上下文窗口。跑到十几轮之后早期轮次的内容会挤占空间。我的应对是每完成一个阶段性任务就开一个新会话把当前状态改了哪些文件、验证结果、下一步计划写进一个PROGRESS.md新会话开头先读它。这相当于给回路做了个存档点。4.2 Codex适合当独立验证者Codex 我主要用来做交叉验证。同一个任务Claude Code 实现完之后我会让 Codex 独立 review 一遍重点看逻辑漏洞和边界情况。因为两个模型的训练数据和偏好不同它们犯的错往往不重叠交叉验证能抓到不少单模型漏掉的问题。Codex 的坑是配置文件解析。它的AGENTS.md读取有时候不生效尤其是放在非根目录的时候。我排查过几次发现是路径大小写或者文件编码的问题。解决办法很简单统一用 UTF-8 无 BOM文件名严格用AGENTS.md放根目录。还有一个常见问题是登录和组织设置。如果你用的是团队版有时候会遇到无法加载组织设置的提示通常是网络或账号权限的问题切换一下账号或者重新登录一般能解决。这类问题不影响本地回路但会打断你的节奏建议提前确认好。4.3 Cursor适合当快速迭代的编辑器内回路Cursor 的优势是在编辑器里就能完成小循环——改一个函数、跑一下测试、看结果不用切窗口。所以我把微循环放在它这里单个函数的实现、局部重构、快速试错。它的坑集中在中文支持和规则生效上。很多人问 Cursor 怎么设置中文回复其实是在设置里找语言选项但 Cursor 的界面语言和 AI 回复语言是两回事。AI 回复语言主要靠提示词控制或者在 rules 里写一条始终用中文回复。界面汉化则是另一套设置两者别搞混。另一个坑是免费额度。Cursor 的免费额度是有限的跑大循环很容易用完。我的建议是把 Cursor 留给微循环大任务交给 Claude Code 或 Codex这样额度分配更合理。4.4 三工具分工对照表维度Claude CodeCodexCursor主循环推荐可用不推荐交叉验证可用推荐一般微循环一般一般推荐约束文件CLAUDE.mdAGENTS.md.cursor/rules主要坑点权限确认、上下文配置解析、登录中文设置、额度这张表不是绝对的但如果你刚开始搭回路按这个分工走能少走很多弯路。5. 让回路收敛得更快几个实战优化技巧前面讲的是怎么转这一节讲怎么转得快、转得稳。这些都是我在实际项目里反复试出来的不是理论。5.1 把完成定义得足够具体回路跑不停很多时候是因为完成这个标准太模糊。你说优化一下性能模型永远不知道什么时候算优化好了。但你说把列表页首屏渲染时间从 800ms 降到 300ms 以下用 Lighthouse 测量这就有了明确的终止信号。我的习惯是在每个任务开始前写一句验收标准验收标准pnpm verify 通过且新增的排序功能在 1000 条数据下响应时间 100ms。这句话会直接进约束文件或者当轮提示词。有了它模型自己就知道该往哪个方向使劲循环次数明显减少。5.2 用最小可复现喂给模型修复轮里最影响效率的是信息质量。你给模型一个模糊的它不工作了它只能瞎猜。你给它一个最小可复现的例子它往往一轮就修好。我的做法是遇到 bug 先自己写一个最小的失败测试然后把这个测试连同报错一起给模型。这个测试本身就是最好的需求描述——它精确说明了输入是什么、期望是什么、实际是什么。// 最小复现排序在空数组时抛异常 test(sortByRegistration handles empty array, () { expect(() sortByRegistration([], asc)).not.toThrow(); });把这段贴给模型比说一百句排序有问题都管用。5.3 定期清理上下文别让回路背着包袱跑长循环跑到后面上下文里堆满了历史报错、废弃方案、来回讨论。这些内容会干扰模型判断让它把已经排除的方案又捡回来。我的做法是每 5 到 8 轮做一次上下文清理把当前有效状态改了哪些文件、当前验证结果、剩余任务写进PROGRESS.md然后开新会话。新会话只带CLAUDE.mdPROGRESS.md 当前任务干净利落。实测下来清理后的第一轮生成质量明显比清理前高。这就像人工作久了要休息一下模型也需要清空缓存。5.4 别让回路变成无限套娃最后一个坑也是最隐蔽的AI 修 AI 的 bug越修越多。这种情况通常发生在验证信号本身有问题的时候——比如测试写错了模型为了通过测试去改实现结果实现被改坏了。我的应对是验证层的东西人必须亲自把关。测试用例、类型定义、接口契约这些不要让 AI 随便改。如果模型说这个测试写错了我改一下你要停下来自己判断——它说的对不对很多时候它只是想绕过验证而不是真的发现了测试的问题。提示在约束文件里明确写一条禁止修改测试文件除非我明确要求。这一条能挡掉大量为了通过而作弊的行为。6. 我在这套流程里踩过的三个真实坑理论讲完了讲点实在的。这三个坑都是我实际项目里踩出来的每个都让我改了工作流。第一个坑约束文件写太满模型反而看不见重点。我一开始把CLAUDE.md写了两百多行事无巨细。结果发现模型经常违反最关键的几条规则反而是一些无关紧要的格式要求它记得很牢。后来我把文件砍到 60 行只留最核心的规则遵守率立刻上来了。教训是约束文件是宪法不是操作手册越精简越有效。第二个坑跨工具同步约束结果三份规则打架。我一度在CLAUDE.md、AGENTS.md、.cursor/rules里各写了一份规则内容还不完全一样。结果同一个任务Claude Code 和 Cursor 给出的方案风格完全不同我改来改去把自己绕晕了。后来改成一份主约束 其他工具引用世界清净了。第三个坑验证脚本太慢回路跑不动。我最初的verify脚本包含了完整的端到端测试跑一次要三分钟。结果每轮循环都要等三分钟一天下来跑不了几轮。后来我把验证拆成快速验证类型 lint 单元测试30 秒内和完整验证端到端只在阶段结束时跑效率提升非常明显。回路工程里验证速度直接决定循环速度这一点怎么强调都不过分。7. 关于 Loop Engineering 的一点个人体会折腾了这么久我最大的感受是Loop Engineering 的核心不是让 AI 多干活而是让人把精力放在定义问题上。回路转得好不好取决于你有没有把什么叫完成说清楚、有没有把验证信号设计好、有没有把约束边界划明白。这三件事做好了AI 自己就能在圈里跑得很稳这三件事没做好你就是在陪它一起空转。另外工具是会变的。今天 Claude Code 是主循环引擎明天可能就有更合适的工具出来。但生成—验证—修正这个回路的骨架不会变约束文件、验证脚本、上下文管理这些基本功也不会变。把方法论吃透换工具只是换个零件的事。最后分享一个小习惯我会给每个项目维护一个LOOP_LOG.md记录每次循环的任务、轮次、卡点、解决方案。跑一段时间回头看你会发现自己踩的坑其实高度重复这份日志就是你的避坑地图。