1. 从“写提示词”到“搭流水线”Loop Engineering 到底在解决什么问题如果你最近半年一直在用 Claude Code、Codex、Cursor 这类 AI 编程工具大概率经历过这样一个阶段一开始觉得“哇一句话就能生成一个函数”用着用着发现不对劲——同一个需求换个说法结果天差地别复杂任务跑着跑着就偏了改了一个 bug又冒出三个新问题。这不是你的错觉而是单次提示词交互模式的天花板。Loop Engineering循环工程这个词最近在开发者圈子里被反复提起它讲的不是“怎么把提示词写得更漂亮”而是怎么把 AI 编程工具组织成一个可循环、可验证、可收敛的工程流程。你可以把它理解成以前你是“跟 AI 聊天”现在你是“给 AI 搭一条流水线”让它自己跑、自己检查、自己修正你只在关键节点做决策。这个教程适合三类人第一类是把 Claude Code、Codex、Cursor 当日常主力工具但总觉得效率没拉满的开发者第二类是刚接触这些工具想跳过“瞎试”阶段直接建立正确工作流的入门者第三类是团队里负责制定 AI 编码规范的技术负责人。我会从核心思路拆解开始一路讲到具体工具的配置、循环的搭建、常见故障的排查最后给一个完整的项目实战。需要先说明一点Loop Engineering 不是一个官方术语也不是某个产品的功能名它是社区里对“把 AI 编码工具用出工程化效果”这套方法论的概括。所以不同人理解会有差异我讲的是我自己在多个项目里跑通、并且稳定复现的那一套。2. 核心思路拆解为什么单次提示注定失败2.1 单次提示的三个致命缺陷先说清楚问题才知道 Loop Engineering 在补什么。缺陷一上下文漂移。你给 AI 一个任务它开始生成代码。生成到第三段的时候它已经“忘记”了第一段里你强调的约束条件。这不是模型笨而是单次交互里没有强制它回头检查的机制。就像你让一个实习生写模块写完不 review 直接提交出错是必然的。缺陷二验证缺失。单次提示的产出质量完全依赖你肉眼检查。代码能不能跑、边界条件对不对、有没有引入新依赖全靠你自己看。任务一复杂检查成本就超过了自己写的成本。缺陷三无法收敛。复杂任务需要多轮迭代但单次提示模式下每一轮都是“重新开始”上一轮的产出和反馈没有形成结构化积累。你改到第五版已经不知道第一版为什么那么写了。2.2 Loop Engineering 的核心循环模型Loop Engineering 的本质是把“生成-验证-修正”这个循环显式地搭出来。一个最小可用的循环包含四个环节规划Plan把模糊需求拆成可验证的子任务明确每个子任务的输入、输出、验收标准。执行Execute让 AI 工具按子任务生成代码或配置一次只做一件事。验证Verify用自动化手段测试、lint、类型检查、运行结果判断产出是否达标而不是靠肉眼。修正Fix把验证失败的反馈结构化地喂回给 AI让它针对性修改而不是重新生成。这四个环节循环起来直到所有子任务通过验证。关键在于验证必须是自动化的、客观的否则循环就退化成“你反复跟 AI 扯皮”。2.3 为什么这套方法现在才火三个条件同时成熟了。第一Claude Code、Codex 这类工具开始支持直接执行终端命令和读写文件AI 不再只是“生成文本”而是能真正操作你的项目。第二这些工具开始支持项目级上下文比如 CLAUDE.md、AGENTS.md 这类约定文件让循环有了稳定的“记忆锚点”。第三社区沉淀出了一批可复用的循环模板比如 Harness Engineering 里提到的“测试先行 AI 补全”模式让普通人不用从零设计。注意Loop Engineering 不是让你完全放手不管。它的目标是把你从“逐行检查代码”里解放出来让你专注在“定义验收标准”和“处理循环卡住的异常”上。人的角色从“写代码的人”变成“设计流水线的人”。3. 工具选型Claude Code、Codex、Cursor 各自适合循环的哪个环节3.1 三款工具的定位差异很多人纠结“到底用哪个”其实它们不是替代关系在 Loop Engineering 里可以各司其职。我按自己的使用体验做个对照工具核心优势适合的循环环节典型短板Claude Code终端命令执行强项目级上下文理解好执行、修正需要配置初次上手门槛略高Codex代码补全和单文件生成快执行局部跨文件循环能力弱Cursor编辑器集成好交互直观规划、人工验证自动化循环能力依赖插件我的实际组合是用 Cursor 做规划和人工 review用 Claude Code 跑自动化执行和修正循环Codex 作为单文件快速补全的补充。这个组合不是唯一解但在我经手的项目里稳定性最好。3.2 Claude Code 的安装与基础配置Claude Code 是循环里的“执行引擎”配置对了后面省很多事。安装方式按平台分# macOS / Linux npm install -g anthropic-ai/claude-code # 验证安装 claude --versionWindows 用户如果遇到 npm 全局安装的路径问题建议用 WSL 或者直接在项目目录下用 npx 调用。安装完成后第一件事是在项目根目录创建CLAUDE.md文件这是循环的“记忆锚点”。# 项目约定 - 语言TypeScript严格模式 - 测试框架Vitest - 提交前必须通过npm run lint npm run test - 禁止引入新的运行时依赖除非在 PR 描述里说明理由这个文件的作用是每次 AI 执行任务前都会读取它作为约束。没有这个文件AI 每次都在“猜”你的项目规范循环就会反复在同一个地方出错。3.3 Codex 与 Cursor 的接入要点Codex 的安装相对简单官网下载对应平台的安装包即可。它的强项是单文件内的代码生成适合循环里“执行”环节的局部任务。但要注意Codex 对项目级上下文的理解不如 Claude Code所以复杂任务不要指望它一次跑通。Cursor 的配置重点在中文回复设置和语言环境。很多人搜“cursor 怎么设置中文回复”其实是在设置里找 Language 选项。路径是Settings → General → Language选中文后界面会汉化但 AI 回复的语言还需要在提示词里明确或者在.cursorrules文件里写一句“始终用中文回复”。# .cursorrules - 始终用中文回复 - 代码注释用中文 - 解释技术方案时先给结论再给理由这个文件放在项目根目录Cursor 会自动读取。实测下来比每次在对话里强调“用中文”稳定得多。3.4 第三方模型接入的注意事项社区里经常讨论“codex 接入 deepseek”“使用 cc switch 接入 deepseek、qwen、glm 等模型”。这类操作的本质是替换底层模型端点。我的建议是循环工程里模型稳定性比模型能力更重要。一个能力稍弱但响应稳定的模型比一个能力强但时不时超时的模型更适合跑循环。如果你确实要接入第三方模型注意几个坑第一端点路径要对比如/responses这类路径写错会直接报错第二模型名称要匹配社区里出现过“the gpt-5.6-sol model is not supported”这类报错就是模型名和端点不匹配第三超时设置要放宽循环里单次请求超时会打断整个流程。提示接入第三方模型前先用一个最小任务比如“生成一个加法函数并写测试”跑通全流程确认端点、模型名、超时都正常再上复杂任务。4. 搭建你的第一个循环从需求到可运行代码4.1 循环的目录结构设计循环要跑得稳目录结构得先定好。我用的结构是这样的project/ ├── CLAUDE.md # AI 约束文件 ├── .cursorrules # Cursor 约束 ├── specs/ # 任务规格 │ └── task-001.md ├── src/ # 源码 ├── tests/ # 测试 └── scripts/ └── verify.sh # 验证脚本specs/目录是关键。每个子任务写成一个 markdown 文件包含任务描述、输入、输出、验收标准。这样 AI 每次执行时读的是结构化的规格而不是你临时打的几句话。4.2 任务规格的写法以“实现一个用户注册接口”为例规格文件这样写# task-001: 用户注册接口 ## 输入 - POST /api/register - body: { email: string, password: string } ## 输出 - 成功201 { userId: string } - 失败400 { error: string } ## 验收标准 1. email 格式校验非法返回 400 2. password 长度 8否则返回 400 3. 邮箱重复返回 400 4. 通过 tests/register.test.ts 全部用例注意验收标准必须是可自动验证的。“代码写得好”不是验收标准“通过测试用例”才是。4.3 验证脚本的编写验证脚本是循环的“裁判”。没有它循环就是自说自话。一个最小验证脚本#!/bin/bash # scripts/verify.sh set -e echo 运行 lint npm run lint echo 运行类型检查 npx tsc --noEmit echo 运行测试 npm run test echo 全部通过 set -e的作用是任何一步失败就立即退出返回非零状态码。AI 工具读到这个状态码就知道验证失败了需要修正。4.4 循环的启动与收敛判断启动循环的提示词模板读取 specs/task-001.md按验收标准实现。 实现完成后运行 scripts/verify.sh。 如果验证失败根据失败输出修正代码再次验证。 最多循环 5 次5 次后仍失败则停止并输出失败原因。这里“最多循环 5 次”是必须的。没有上限AI 可能在一个死胡同里反复撞墙浪费时间和额度。5 次是我实测下来比较平衡的值简单任务 1-2 次通过复杂任务 3-5 次超过 5 次基本说明规格本身有问题需要人工介入。5. 实操过程一个完整项目的循环实录5.1 项目背景与任务拆解我拿一个真实的小项目举例给一个已有的 Node.js 服务加“文章收藏”功能。需求是用户可以收藏文章、取消收藏、查看收藏列表。拆成三个子任务task-001数据模型和数据库迁移task-002收藏/取消收藏接口task-003收藏列表接口每个任务单独写规格文件单独跑循环。不要把所有任务塞进一个循环那样验证失败时你分不清是哪个环节的问题。5.2 task-001 的执行记录规格文件写好后启动 Claude Codeclaude然后在对话里输入循环提示词。第一次执行AI 生成了模型定义和迁移文件运行验证脚本lint 通过但测试失败——它忘了写迁移文件的回滚逻辑。验证输出FAIL tests/migration.test.ts ● rollback should drop favorites table Expected table to not exist, but it doesAI 读到这个输出第二次循环自动补上了回滚逻辑验证通过。整个过程我只看了一眼失败输出确认是合理失败没有手动改任何代码。5.3 task-002 的循环卡点与处理task-002 跑到第三次循环还没通过失败输出一直在变但都是同一个测试用例失败。这时候我判断不是 AI 能力问题是规格写得有歧义。回去看规格发现“取消收藏”的验收标准写的是“返回 200”但没写“如果未收藏过该文章返回什么”。AI 每次猜的都不一样。补上规格“未收藏时取消返回 404”。重新跑循环一次通过。这个卡点让我记住一个经验循环反复失败时先怀疑规格再怀疑 AI。5.4 task-003 的快速通过有了前两个任务的积累CLAUDE.md里的约定和已有的代码模式成了上下文task-003 一次循环就通过了。这也是 Loop Engineering 的一个隐性收益循环跑得越多项目上下文越丰富后续任务越顺。6. 常见问题与排查技巧实录6.1 工具层面的高频故障现象可能原因排查方向cc switch 报 proxy failed端点配置错误或网络问题检查端点路径、模型名是否匹配codex 无法加载组织设置账号权限或配置缓存重新登录清理本地配置缓存cursor 响应速度慢上下文过大或模型负载精简 .cursorrules拆分任务claude code 命令执行无响应权限或路径问题检查工作目录确认命令在 PATH 中模型不支持报错模型名与端点不匹配核对端点文档里的模型名列表6.2 循环层面的典型问题问题一循环不收敛反复改同一个地方。原因通常是验收标准模糊AI 每次理解不同。解决方法是把验收标准写成具体的断言比如“返回 400 且 error 字段包含 invalid email”而不是“校验邮箱”。问题二循环通过验证但代码质量差。验证脚本只检查功能不检查质量。补充 lint 规则和类型检查把质量标准也纳入验证。我通常会在CLAUDE.md里加一条“函数不超过 50 行超过则拆分”。问题三循环消耗额度太快。控制单次循环的任务粒度。一个任务如果预计需要 AI 生成超过 200 行代码就拆成两个。粒度越细单次循环越短失败成本越低。6.3 独家避坑技巧技巧一验证脚本先于代码存在。在让 AI 写实现之前先自己把测试用例写好。这样循环的目标非常明确让测试通过。这比“实现一个功能”这种模糊目标稳定得多。技巧二给循环加“冷静期”。连续失败 3 次后不要让它继续而是让它输出“当前理解的任务是什么、卡在哪里、需要什么信息”。这个动作能暴露规格里的歧义比继续硬跑有效。技巧三保留每次循环的产出。用 git 在每次循环后提交一次commit message 写清楚是第几次循环、验证结果。这样出问题时可以回滚到任意一次也方便复盘循环为什么没收敛。技巧四中文回复的稳定性靠文件不靠嘴。与其每次在对话里说“用中文”不如在.cursorrules和CLAUDE.md里写死。实测下来文件约束的稳定性远高于对话约束。7. 从单循环到多循环Harness Engineering 的衔接7.1 什么是 Harness Engineering当你的项目里跑通了几个单循环后会自然遇到一个问题多个循环之间怎么协调比如 task-002 依赖 task-001 的产出task-003 又依赖 task-002。这时候就需要 Harness Engineering——给多个循环搭一个外层框架管理依赖、顺序和共享上下文。社区里对 Harness Engineering 的讨论还比较早期我的理解是它是 Loop Engineering 的上一层管的是“循环之间的编排”。一个简单的 harness 可以是一个 shell 脚本按依赖顺序依次启动循环每个循环通过后自动进入下一个。7.2 一个最小 harness 的实现#!/bin/bash # scripts/harness.sh set -e for task in specs/task-*.md; do echo 执行 $task claude --task $task --verify scripts/verify.sh --max-loops 5 if [ $? -ne 0 ]; then echo 任务 $task 失败停止流水线 exit 1 fi git add -A git commit -m 完成 $task done echo 全部任务完成 这个脚本的核心逻辑是按文件名顺序执行任务每个任务通过验证后提交失败则停止。文件名用task-001、task-002这样的前缀保证顺序可控。7.3 多循环的上下文共享多循环跑起来后最大的挑战是上下文共享。task-003 需要知道 task-001 定义的数据模型长什么样。我的做法是每个循环结束后把关键产出比如接口签名、数据模型追加到一个CONTEXT.md文件里下一个循环启动时先读这个文件。# 项目上下文 ## 数据模型来自 task-001 - Favorite: { userId, articleId, createdAt } ## 接口来自 task-002 - POST /api/favorite - DELETE /api/favorite这个文件是自动生成的不需要手写。可以在验证脚本通过后让 AI 把本次产出摘要追加进去。8. 项目实战复盘哪些环节真正省了时间8.1 时间账的粗略对比拿前面那个收藏功能举例我做了个粗略对比环节传统方式Loop Engineering写代码约 3 小时约 40 分钟含循环等待写测试约 1 小时约 30 分钟提前写好调试约 1.5 小时约 20 分钟循环自动修正人工 review约 1 小时约 40 分钟重点看规格和验证省下来的时间主要在调试和写代码上但前期写规格和验证脚本的时间增加了。净收益在任务复杂度中等偏上时最明显简单任务比如改个文案用循环反而是负担。8.2 哪些任务不适合跑循环不是所有任务都值得搭循环。我的判断标准是如果任务的验收标准无法自动化验证就不适合。比如“优化代码可读性”“调整 UI 配色”这类主观任务循环的验证环节没法客观判断跑起来就是自欺欺人。另外探索性任务也不适合。比如“调研三个方案哪个好”这种任务需要人的判断循环帮不上忙。8.3 循环工程的长期价值跑了一段时间后我发现最大的收益不是“省了多少小时”而是项目里沉淀了一套可复用的规格和验证脚本。新功能来了照着已有规格改一改循环就能跑。这种积累效应是单次提示模式给不了的。我个人在实际操作中的体会是Loop Engineering 的门槛不在工具而在“把需求写成可验证规格”的能力。这个能力练出来了用什么工具都能跑出效果练不出来工具再强也是白搭。所以如果你刚开始别急着上复杂工具链先拿一个小任务把规格和验证脚本写扎实跑通一个循环再逐步扩展。