1. 从“会写代码”到“会指挥AI写代码”Loop Engineering 到底在解决什么问题这两年 AI 编程工具迭代得飞快Claude Code、Codex、Cursor 一个接一个地冒出来很多人第一次用的时候确实惊艳——补全快、能对话、能改 bug。但用久了就会发现一个尴尬的现实单次对话再强也扛不住一个完整项目的复杂度。你让 AI 写一个函数它写得挺好你让它改一个模块它开始丢三落四你让它跑一个完整的功能迭代它直接开始胡编 API。这就是 Loop Engineering 要解决的核心问题。它不是某个具体的工具也不是某个官方框架而是一套围绕 AI 编程助手构建“闭环工作流”的工程方法论。简单说就是让 AI 不再是“一问一答的聊天机器人”而是变成一个能自己跑循环、自己验证、自己修正的“工程执行单元”。我最早接触这个概念是在折腾 Claude Code 的时候。当时我让它帮我重构一个 Node.js 项目里的工具函数它改完第一版看着没问题但跑测试就挂了。我又把报错贴回去它改第二版还是挂。来回折腾了七八轮我才意识到问题不在模型能力而在我没有给它设计一个“闭环”。它每次只能看到我贴给它的片段看不到完整的上下文也没法自己跑测试验证结果。后来我把测试命令、文件结构、错误日志全部结构化地喂给它并且让它自己执行“改代码 → 跑测试 → 读报错 → 再改”这个循环效率直接翻了好几倍。所以 Loop Engineering 的本质是把 AI 编程从“单次调用”升级成“可迭代的工程流程”。它涉及几个关键环节任务拆解、上下文管理、执行验证、错误回传、循环终止条件。这套东西跟传统的 CI/CD 有相似之处但区别在于——CI/CD 是给人写的代码做自动化而 Loop Engineering 是给 AI 生成的代码做自动化验证和修正。适合谁来学我觉得三类人最需要一是已经在用 Claude Code、Codex、Cursor 但觉得“不够顺手”的开发者二是想把这套东西引入团队工作流的 Tech Lead三是单纯对 AI 编程感兴趣、想搞清楚“为什么别人用 AI 写得快而我写得慢”的独立开发者。这篇文章我会从设计思路讲到实操细节尽量把踩过的坑都摊开说。2. 核心思路拆解为什么你的 AI 编程总是“断片”2.1 单次对话模式的三个致命缺陷大部分人用 AI 编程的方式是这样的打开 Cursor 或者 Claude Code输入一段需求等它生成代码复制粘贴跑一下报错了再贴回去。这个模式在简单场景下没问题但一旦涉及多文件、多步骤、有依赖关系的任务就会暴露三个致命缺陷。第一个缺陷是上下文窗口的“遗忘曲线”。AI 模型有上下文长度限制虽然现在动辄 128K、200K token但实际使用中你会发现当对话轮次多了之后早期的重要信息会被“稀释”。比如你一开始告诉它“这个项目用的是 TypeScript 严格模式”聊了二十轮之后它可能就忘了开始给你生成any类型的代码。这不是模型笨而是注意力机制在长上下文中的自然衰减。第二个缺陷是缺乏执行反馈。AI 生成代码后它自己不知道这段代码能不能跑通。它只能根据训练数据里的模式来“猜”。你如果不把运行结果、报错信息、测试输出贴给它它就永远在盲改。这就像让一个程序员闭着眼睛写代码写完还不让跑直接提交——能不出问题吗第三个缺陷是没有终止条件。单次对话模式下什么时候算“改好了”你不知道AI 也不知道。它可能改了三版你觉得可以了也可能改了十版还在原地打转。没有明确的验证标准和终止条件循环就会变成“无限纠结”。2.2 Loop Engineering 的闭环模型Loop Engineering 的核心就是把上面三个缺陷补上。它的基本模型可以拆成五个环节任务定义把大需求拆成可验证的小任务每个任务有明确的输入、输出和验收标准。上下文注入把任务相关的文件、类型定义、依赖关系、编码规范结构化地提供给 AI。代码生成AI 根据上下文生成代码或修改方案。自动验证通过测试、类型检查、lint、构建等命令自动验证结果。错误回传与修正把验证失败的详细信息回传给 AI让它基于具体错误进行修正然后回到第 3 步。这个循环会一直跑直到验证通过或者达到预设的重试上限。听起来简单但每个环节都有很多细节可以抠。比如“上下文注入”这一环你是直接把整个项目目录扔给 AI还是只给它相关的文件你是用自然语言描述依赖关系还是把package.json和tsconfig.json直接贴进去这些选择会直接影响循环的效率。2.3 为什么是“Loop”而不是“Chain”有人可能会问这不就是 Chain 吗跟 LangChain 那种链式调用有什么区别我的理解是Chain 强调的是“顺序执行”一步接一步像流水线而 Loop 强调的是“循环迭代”有反馈、有修正、有终止条件。在 AI 编程场景下一次生成就完美的概率极低所以 Loop 比 Chain 更贴合实际。另一个区别是Chain 通常是预先定义好的固定流程而 Loop 是动态的——每一轮循环的输入取决于上一轮的输出。AI 改完代码后报了什么错决定了下一轮它要重点修哪里。这种动态性让 Loop 更适合处理“不确定性高”的任务比如重构、调试、迁移。2.4 工具选型Claude Code、Codex、Cursor 各自适合什么角色在 Loop Engineering 的框架下不同工具扮演的角色其实不太一样。我自己的组合是这样的Claude Code主力“执行器”。它的优势是能直接读写文件、执行命令适合放在循环的核心位置。你可以让它改代码、跑测试、读日志整个闭环它都能参与。Codex适合做“代码审查”和“方案建议”。它的补全和生成能力很强但直接操作文件的能力相对弱一些。我通常用它来生成初始方案或者对 Claude Code 的修改做二次审查。Cursor适合做“交互式调试”。它的编辑器集成做得最好适合在循环卡住的时候手动介入看看具体哪一行出了问题。当然这不是绝对的每个人的工作流不一样。关键是理解每个工具的能力边界然后把它们放在循环里合适的位置。下面这张表是我自己总结的对比工具核心优势在 Loop 中的角色注意事项Claude Code文件读写、命令执行、上下文管理主执行器注意 token 消耗长循环要控制上下文Codex代码生成质量高、补全强方案生成、代码审查直接操作文件能力弱需配合其他工具Cursor编辑器集成好、交互流畅手动调试、局部修改长任务容易“跑偏”需及时干预3. 核心细节解析构建一个能跑通的 Loop 需要哪些零件3.1 任务拆解把“帮我重构这个模块”变成可执行的步骤任务拆解是 Loop Engineering 的第一步也是最容易被忽视的一步。很多人直接跟 AI 说“帮我重构这个模块”然后期待它一次性搞定。结果就是 AI 改了一堆文件你也不知道它改了什么跑起来还报错。我的做法是把重构任务拆成“可独立验证”的小步骤。比如我要重构一个用户认证模块我会拆成提取认证相关的类型定义到独立文件把密码哈希逻辑抽成独立函数把 token 生成逻辑抽成独立函数更新所有调用点跑测试验证每一步都有明确的验收标准第 1 步的标准是“类型检查通过”第 2 步的标准是“单元测试通过”第 4 步的标准是“没有遗漏的调用点”。这样 AI 每完成一步我都能验证而不是等到最后才发现问题。拆解的粒度怎么把握我的经验是每一步的修改量控制在 AI 一次能处理的范围内。对于 Claude Code 来说大概是 200-500 行代码的修改量。超过这个量它就容易丢上下文。如果任务太大就继续拆。3.2 上下文注入给 AI 看的“项目说明书”该怎么写上下文注入是 Loop Engineering 里最讲究技巧的一环。你给 AI 的信息太多它会抓不住重点给得太少它又会瞎猜。我一般会准备一个“上下文包”包含以下几类信息项目结构用tree命令生成目录树让 AI 知道文件都在哪。关键配置文件package.json、tsconfig.json、.eslintrc等让 AI 知道项目的技术栈和规范。相关文件内容只给当前任务涉及的文件不要给整个项目。类型定义如果项目有 TypeScript 类型或者 JSON Schema一定要给这是 AI 理解数据结构的关键。验收标准明确告诉 AI“改完之后要跑npm test所有测试通过才算完成”。这里有个技巧用 Markdown 格式组织上下文而不是直接粘贴原始文件。比如## 项目结构 - src/ - auth/ - login.ts - register.ts - utils/ - hash.ts ## 技术栈 - TypeScript 5.0 严格模式 - Jest 测试框架 - 不允许使用 any 类型 ## 当前任务 重构 src/auth/login.ts把密码验证逻辑抽到 src/utils/hash.ts ## 验收标准 - npm run typecheck 通过 - npm test 通过这样 AI 读起来清晰你维护起来也方便。我一般会把这个上下文包存成一个CONTEXT.md文件每次循环的时候直接引用。3.3 验证环节自动化测试是 Loop 的“眼睛”没有验证的 Loop 就是“盲循环”。AI 改完代码你必须有一个自动化的方式来判断“改对了没有”。这个验证可以是类型检查tsc --noEmit或mypy单元测试jest、vitest、pytestLinteslint、ruff构建npm run build、cargo build端到端测试playwright、cypress我一般会把这些命令串成一个脚本比如verify.sh#!/bin/bash set -e echo Running typecheck... npm run typecheck echo Running lint... npm run lint echo Running tests... npm test echo All checks passed!然后让 AI 在每次修改后执行这个脚本。如果脚本失败就把错误输出回传给 AI。这里有个细节错误输出要截取关键部分不要把几百行日志全贴回去。我一般会用grep或者head过滤一下只保留错误类型和出错文件。3.4 错误回传怎么让 AI “看懂”报错信息错误回传的质量直接决定了下一轮修正的效率。很多人直接把终端输出全贴给 AI结果 AI 被一堆无关信息干扰改了半天没改到点上。我的做法是把错误信息结构化## 验证失败 - 命令npm test - 失败文件src/auth/login.test.ts - 错误类型TypeError - 错误信息Cannot read property hash of undefined - 相关代码 typescript const hashed hash(password); // hash is undefined这样 AI 一眼就能看出问题在哪。另外我会在回传错误的时候顺便告诉 AI“上一轮你改了什么”让它知道自己是在什么基础上出的错。这能避免它重复犯同样的错误。 ### 3.5 循环终止条件什么时候该停 Loop 不能无限跑下去。我一般会设置三个终止条件 1. **验证通过**所有检查都过了循环结束。 2. **达到最大重试次数**比如 5 次。如果 5 次还没改好说明任务可能拆得不够细或者 AI 理解有偏差需要人工介入。 3. **错误类型重复**如果连续两轮报的是同一个错误说明 AI 卡住了继续跑也没用直接停。 设置终止条件的好处是你能控制 token 消耗和时间成本。我见过有人让 AI 跑了几十轮最后发现是任务定义有问题白白浪费了大量 token。 ## 4. 实操过程从零搭建一个 Loop Engineering 工作流 ### 4.1 环境准备Claude Code 和 Codex 的安装与配置 先说 Claude Code 的安装。它目前主要通过 npm 分发所以你需要先有 Node.js 环境。我建议用 nvm 管理 Node 版本避免权限问题 bash # 安装 nvm如果还没装 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash # 安装 Node.js 20 nvm install 20 nvm use 20 # 安装 Claude Code npm install -g anthropic-ai/claude-code安装完成后运行claude命令它会引导你完成登录和初始化。这里有个坑Claude Code 默认会读取当前目录作为工作区所以你要在项目根目录下启动它否则它找不到文件。Codex 的安装类似也是通过 npmnpm install -g openai/codexCodex 的配置主要在~/.codex/config.json里你可以设置默认模型、API 端点等。如果你在国内可能需要配置代理才能访问 OpenAI 的 API。这里不展开说懂的都懂。Cursor 的安装最简单直接去官网下载安装包就行。安装完成后建议先设置中文界面打开设置搜索“language”选择“中文简体”。另外Cursor 的免费额度有限重度使用的话需要考虑付费方案。4.2 项目初始化创建一个适合 Loop 的目录结构我一般会为 Loop Engineering 项目创建一个专门的目录结构my-project/ ├── src/ # 源代码 ├── tests/ # 测试文件 ├── scripts/ │ ├── verify.sh # 验证脚本 │ └── context.sh # 生成上下文包 ├── CONTEXT.md # 上下文说明 ├── LOOP_LOG.md # 循环日志 └── package.jsonverify.sh是验证脚本前面已经给过示例。context.sh用来生成上下文包比如#!/bin/bash echo # 项目结构 CONTEXT.md tree -I node_modules|dist CONTEXT.md echo CONTEXT.md echo # 技术栈 CONTEXT.md cat package.json CONTEXT.md echo CONTEXT.md echo # 类型定义 CONTEXT.md find src -name *.d.ts -exec cat {} \; CONTEXT.mdLOOP_LOG.md用来记录每一轮循环的输入、输出和结果。这个日志非常重要当你发现循环卡住的时候翻日志能快速定位问题。4.3 第一轮循环让 AI 完成一个简单的重构任务假设我们要重构一个函数。原始代码是这样的// src/utils/format.ts export function formatUser(user: any) { return { name: user.firstName user.lastName, email: user.email.toLowerCase(), age: user.age || 0 }; }这个函数的问题是用any类型而且没有处理边界情况。我们的任务是把它改成严格类型并且加上空值处理。第一步把上下文包准备好然后启动 Claude Codeclaude在 Claude Code 的交互界面里输入请阅读 CONTEXT.md然后重构 src/utils/format.ts 中的 formatUser 函数。 要求 1. 定义 User 接口替换 any 类型 2. 处理 firstName 或 lastName 为空的情况 3. 处理 email 为空的情况 4. 改完后运行 ./scripts/verify.sh 验证Claude Code 会读取上下文生成修改方案然后执行验证脚本。如果验证通过它会告诉你“所有检查通过”。如果失败它会读取错误信息并尝试修正。4.4 循环日志记录每一轮的输入输出每一轮循环结束后我会把关键信息记录到LOOP_LOG.md## Round 1 - 任务重构 formatUser - 修改文件src/utils/format.ts - 验证结果失败 - 错误TypeError: Cannot read property toLowerCase of undefined - 修正方向email 为空时返回空字符串 ## Round 2 - 任务修正 email 空值处理 - 修改文件src/utils/format.ts - 验证结果通过 - 备注增加了 User 接口定义这个日志看起来简单但当你跑了十几轮循环之后它能帮你快速回顾“到底改了什么”。我踩过的坑是有一次循环跑了 8 轮还没通过翻日志才发现 AI 一直在改同一个地方因为我的验收标准写得不清楚。4.5 多工具协作Claude Code 主执行Codex 做审查当 Claude Code 完成一轮修改后我会用 Codex 做一次代码审查。具体做法是codex review src/utils/format.tsCodex 会分析代码指出潜在问题。比如它可能会说“这个函数没有处理 user 为 null 的情况”。然后我把 Codex 的审查意见作为下一轮循环的输入让 Claude Code 继续修改。这种“双工具协作”的好处是两个模型的视角不同能互相补位。Claude Code 擅长执行和验证Codex 擅长发现逻辑漏洞。我实测下来这种组合比单用一个工具的效率高不少。4.6 参数计算如何控制 token 消耗和循环成本Loop Engineering 的一个现实问题是 token 消耗。每一轮循环都要把上下文、代码、错误信息发给模型轮次多了成本会很高。我一般会做几个优化上下文裁剪只给相关文件不给整个项目。用context.sh动态生成上下文包。错误信息过滤只回传关键错误不贴完整日志。设置重试上限一般 5 次超过就人工介入。缓存不变的部分如果项目结构没变上下文包可以复用。粗略估算一下一轮循环大概消耗 5000-10000 token5 轮就是 25000-50000 token。如果用 Claude 3.5 Sonnet成本大概在几美分到十几美分之间。对于个人开发者来说可以接受但如果团队大规模使用就需要考虑成本控制了。5. 常见问题与排查技巧实录5.1 AI 改代码改“飞”了怎么办这是最常见的问题。AI 改着改着开始修改不相关的文件或者引入新的依赖。我的排查思路是检查上下文包是不是给了太多不相关的文件AI 看到什么就想改什么。检查任务描述是不是任务边界不清晰比如“优化这个模块”就太模糊“把 A 函数拆成 B 和 C”就清晰得多。检查验证脚本是不是验证范围太窄如果只跑单元测试AI 可能会忽略类型错误。我的经验是任务描述越具体AI 跑偏的概率越低。另外可以在任务描述里加一句“只修改以下文件不要动其他文件”给 AI 一个明确的边界。5.2 循环卡在同一错误上超过 3 轮如果连续 3 轮报同一个错误说明 AI 没有理解问题的本质。这时候继续跑循环是浪费 token。我的做法是人工介入自己看一下错误判断是 AI 理解问题还是代码本身有问题。重新拆解任务把当前任务拆得更细比如“先只改类型定义不改逻辑”。换工具如果 Claude Code 卡住了试试用 Cursor 手动改或者用 Codex 重新生成方案。我踩过的一个坑是AI 一直报“找不到模块”我以为是路径问题后来发现是tsconfig.json里的paths配置没给 AI 看。把配置文件加入上下文包后问题立刻解决了。5.3 验证脚本跑得太慢拖累循环效率如果验证脚本要跑几分钟循环效率会很低。我的优化方案是分层验证先跑快的检查类型检查、lint再跑慢的检查单元测试、构建。增量验证只跑受影响的测试文件而不是全部测试。并行执行用或者concurrently并行跑多个检查。比如#!/bin/bash npm run typecheck npm run lint wait npm test -- --findRelatedTests src/utils/format.ts这样能把验证时间从几分钟压缩到几十秒。5.4 常见问题速查表问题可能原因解决方法AI 修改不相关文件上下文包太大或任务边界不清裁剪上下文明确任务范围循环卡在同一错误AI 理解偏差或任务太粗人工介入重新拆解任务验证脚本太慢全量验证分层验证增量验证token 消耗过高上下文冗余轮次太多裁剪上下文设置重试上限AI 忘记编码规范上下文未包含配置文件把 tsconfig、eslintrc 加入上下文包多工具协作混乱角色分工不清晰明确每个工具的职责记录日志5.5 独家避坑技巧最后分享几个我踩坑总结出来的技巧技巧一用“最小可验证单元”来拆任务。不要按“功能模块”拆要按“可验证的修改”拆。比如“改类型定义”是一个可验证单元“重构整个认证模块”不是。技巧二给 AI 一个“退出条件”。在任务描述里明确写“如果连续两次验证失败停止修改并输出当前状态”。这样能避免 AI 无限循环。技巧三保留人工审查环节。Loop 跑通不代表代码没问题。我一般会在循环结束后自己再过一遍代码重点看逻辑边界和异常处理。AI 生成的代码在“正常路径”上通常没问题但在“异常路径”上容易有漏洞。技巧四定期清理上下文。长循环中上下文会越来越长AI 的注意力会分散。我一般每 3-5 轮就重新生成一次上下文包把已经完成的部分去掉只保留当前任务相关的信息。技巧五用版本控制做“安全网”。在启动 Loop 之前先 commit 一次。这样如果 AI 改坏了可以随时回滚。我一般会在每一轮循环结束后 commit 一次方便对比每一轮的修改。这套 Loop Engineering 的工作流我用了大概半年最大的感受是AI 编程的效率瓶颈不在模型能力而在工程流程。同样的模型有人用起来效率翻倍有人用起来还不如自己写差别就在流程设计上。把循环建好把验证做扎实把错误回传做清晰AI 才能真正成为“工程执行单元”而不是“聊天玩具”。