★ FEATURED ARTICLE 1. 从“会用工具”到“会造工具”Loop Engineering 到底在解决什么问题这两年 AI 编程工具迭代得飞快Claude Code、Codex、Cursor 轮番上阵很多人已经习惯了在终端里敲一句自然语言让模型帮忙改代码、跑测试、提交 PR。但用久了你会发现一个很尴尬的现象单次对话再强它也只是一个“高级补全”。你让它改一个函数它改得漂漂亮亮你让它独立完成一个跨文件、跨模块、需要反复验证的中型任务它就开始飘——上下文丢失、步骤跳跃、改完不测、测完不复盘。Loop Engineering循环工程要解决的正是这个断层。它不是某个具体工具而是一套把 AI 编程助手从“单次问答”升级成“可循环、可验证、可收敛的自动化工作流”的工程方法论。你可以把它理解成给 AI 装上一个“感知—决策—执行—验证—修正”的闭环让它像一名真正的工程师那样反复迭代直到任务达标而不是交完差就撒手不管。这套东西适合谁三类人最该认真看。第一类是已经在用 Claude Code、Codex、Cursor 但只会“一问一答”的开发者你的效率其实只发挥了工具的三成第二类是想把 AI 编程接入自己项目流水线的团队技术负责人你需要的是可复现的循环结构而不是某个人的手感第三类是刚上手这些工具的新人与其零散地学一堆快捷键不如先建立“循环”这个心智模型后面所有工具都只是这个模型的不同实现。我先把结论摆在这Loop Engineering 的核心不是提示词写得多花哨而是把任务拆成可验证的小步让每一轮循环都有明确的输入、输出和判定标准。下面我会从整体设计、核心细节、实操落地、问题排查四个层面把这套方法掰开揉碎讲清楚中间会穿插 Claude Code、Codex、Cursor 的具体配置和踩坑记录。2. 整体设计与思路拆解为什么是“循环”而不是“对话”2.1 单次对话的三个致命缺陷先说说为什么“对话式编程”在真实项目里会翻车。我拿自己踩过的坑举例。第一个缺陷是上下文漂移。你在一个会话里聊了二十轮前面定义的接口规范、命名约定、目录结构到第十五轮模型基本就记不清了。它开始自己发明字段名把userId写成user_id把异步改成同步。这不是模型笨是上下文窗口的物理限制加上注意力衰减。第二个缺陷是缺乏验证闭环。你让模型写个函数它写完就宣布“完成”。但代码能不能跑、边界条件对不对、有没有破坏原有测试它不知道也不关心。你得自己手动跑一遍发现问题再贴回去一来一回全是人工成本。第三个缺陷是无法收敛。复杂任务往往需要试错但对话模式下每次试错都是“推倒重来”模型不会记住上一轮为什么失败。结果就是它在同一个坑里反复横跳你越催它越乱。Loop Engineering 的思路就是针对这三点下药用结构化状态对抗上下文漂移用自动验证补上闭环用失败记忆实现收敛。2.2 循环的四个基本阶段一个标准的工程循环我习惯拆成四段Plan规划→ Act执行→ Verify验证→ Reflect反思。这四段不是线性走一遍就完而是转圈直到 Verify 通过或者达到最大轮次。Plan 阶段负责把模糊需求拆成可执行的具体步骤输出一份“任务清单”每一条都要能被独立验证。Act 阶段按清单逐条执行每次只做一件事做完立刻进入 Verify。Verify 是关键它必须是一个机器可判定的动作——跑测试、跑 lint、跑类型检查、对比输出快照而不是“我觉得应该对了”。Reflect 阶段则把失败原因结构化地记录下来喂回下一轮 Plan。这里有个反直觉的点循环的粒度要小。很多人一上来就让 AI“重构整个模块”这是大忌。正确的做法是把任务切到“改一个函数 跑对应单测”这种粒度一轮循环控制在几分钟内。粒度越小验证越快收敛越稳。2.3 工具选型的底层逻辑Claude Code、Codex、Cursor 这三个工具在循环里扮演的角色其实不一样选型要看你的循环跑在哪一层。Claude Code 是终端原生的 agent它天然适合做“执行器”——能直接读写文件、跑命令、看输出。它的优势在于工具调用能力强适合放在 Act 和 Verify 阶段。Codex 更偏向代码生成和补全的底层能力适合做 Plan 阶段的“方案生成器”或者在循环里当“第二意见”来交叉验证。Cursor 是 IDE 集成优势在于人机协同适合你在 Reflect 阶段人工介入、审查 diff、做最终决策。我的建议是别指望一个工具包打天下。用 Claude Code 跑自动循环用 Cursor 做人工审查关口用 Codex 做方案备选三者通过文件系统和 git 串起来。这就是所谓的 Harness Engineering脚手架工程——你搭的不是提示词是一套让多个工具协同的“跑道”。提示循环工程里工具之间的“接口”比工具本身更重要。文件格式、git 提交规范、测试命令的统一这些才是让循环跑起来的地基。3. 核心细节解析与实操要点把循环真正搭起来3.1 任务清单的写法让每一步都可验证循环能不能跑起来八成取决于任务清单写得好不好。我见过太多人把清单写成“优化性能”“修复 bug”这种废话模型看了只能瞎猜。好的清单长这样- [ ] 在 src/utils/date.ts 中新增 formatRelativeTime 函数 验证npx vitest run src/utils/date.test.ts 全绿 - [ ] 将 src/components/Feed.tsx 第 42 行的硬编码时间替换为 formatRelativeTime 验证npm run typecheck 无报错且 Feed 组件快照测试通过 - [ ] 补充 formatRelativeTime 的边界用例刚刚、1分钟前、1年前 验证新增 3 个测试用例且全部通过看出规律了吗每一条都包含动作、目标文件、验证命令三要素。验证命令必须是可执行的不能是“检查是否正确”这种主观描述。这一步做扎实后面循环才能自动判定成败。实操心得写清单时我会刻意让每一步的改动不超过 50 行代码。超过这个量验证失败时你很难定位是哪一行出的问题。宁可拆成五步也不要一步到位。3.2 验证环节的三种武器验证是循环的“裁判”裁判不公循环就废了。我一般准备三种验证手段按成本从低到高排列。第一种是静态检查包括类型检查、lint、格式化。这类工具跑得飞快几秒钟出结果适合放在每一轮循环的最前面。TypeScript 项目里tsc --noEmit是标配配合 ESLint 能拦下大量低级错误。第二种是单元测试。这是循环的主力裁判。关键是要让 AI 自己写测试——你给它一个函数需求让它先写测试再写实现这叫测试驱动。测试通过这一轮就算过。第三种是快照对比。对于 UI 组件、API 响应这类输出用快照测试能捕捉到细微的意外改动。Jest 和 Vitest 都内置了快照功能toMatchSnapshot()一行搞定。验证类型工具示例耗时适用阶段静态检查tsc、eslint、prettier秒级每轮开头单元测试vitest、jest秒到分钟每轮核心快照对比jest snapshot秒级UI/API 改动集成测试playwright、supertest分钟级里程碑节点注意验证命令一定要在循环开始前手动跑通一次。我踩过的坑是项目本身测试就是红的结果 AI 每轮都“验证失败”白白空转十几轮。3.3 失败记忆的结构化Reflect 阶段最容易被忽略但它决定了循环能不能收敛。我的做法是维护一个loop-log.md每轮失败都追加一条结构化记录## Round 3 - 失败 - 失败步骤替换 Feed.tsx 时间显示 - 验证命令npm run typecheck - 报错信息Type string is not assignable to type Date - 根因分析formatRelativeTime 返回 string但 Feed 组件期望 Date - 修正方向在调用处包一层 new Date()或修改函数签名这份日志会在下一轮 Plan 时作为上下文喂给模型。实测下来有了失败记忆同一个错误重复出现的概率能降一大半。模型不是不会改是它记不住上次为什么错。3.4 循环的终止条件循环不能无限转必须设终止条件。我一般设三个验证全绿、达到最大轮次通常 8 到 10 轮、连续两轮无进展。前两个好理解第三个是防止模型陷入死循环——如果连续两轮报错信息几乎一样说明它卡住了这时候应该停下来人工介入而不是继续烧 token。4. 实操过程与核心环节实现从零跑通一个循环4.1 环境准备与工具安装先把地基打好。我以 Claude Code 为主执行器Cursor 为审查端Codex 为备选方案生成器来演示。Claude Code 的安装官方推荐用 npm 全局装npm install -g anthropic-ai/claude-code装完在项目根目录跑claude就能进交互模式。第一次用需要配置 API 凭证按提示走就行。这里有个国内用户常遇到的问题网络环境导致登录卡住。我的经验是提前把代理相关的环境变量配好或者用支持自定义 endpoint 的方式接入。具体配置因环境而异核心是保证claude命令能正常发起请求。Codex 的安装类似它更偏向 CLI 和 IDE 插件两种形态。CLI 版本适合脚本化调用插件版本适合在编辑器里随手用。安装包从官方渠道获取注意版本匹配你的 Node 环境。Cursor 直接官网下载安装包装完在设置里把语言改成中文——搜索locale或者language选zh-cn重启即可。很多人问 Cursor 怎么设置中文回复其实分两层界面汉化是上面这个设置而让 AI 用中文回复是在对话里明确说“请用中文回答”或者在项目根目录放一个.cursorrules文件写死语言偏好。4.2 搭建循环的目录结构我在项目里固定建一个.loop/目录结构如下.loop/ ├── tasks.md # 任务清单 ├── loop-log.md # 失败记忆 ├── verify.sh # 统一验证脚本 └── prompts/ ├── plan.md # 规划阶段提示词 ├── act.md # 执行阶段提示词 └── reflect.md # 反思阶段提示词verify.sh是整个循环的心脏它把所有验证命令串起来返回统一的退出码#!/bin/bash set -e echo 类型检查 npx tsc --noEmit echo Lint npx eslint src --max-warnings 0 echo 单元测试 npx vitest run echo 全部通过 这个脚本的好处是无论循环里哪一步验证方式都统一。AI 只需要跑bash .loop/verify.sh看退出码就知道过没过。4.3 一轮完整循环的现场记录我拿一个真实任务演示给一个 React 项目加“相对时间显示”功能。Round 1 - Plan我把需求丢给 Claude Code让它读tasks.md的模板生成任务清单。它输出了 4 条任务我人工审了一遍把第二条的验证命令从“检查显示正确”改成具体的快照测试命令。Round 1 - Act模型按第一条任务在date.ts里写了formatRelativeTime。写完立刻跑verify.sh类型检查过了但它没写测试vitest 报“没有测试文件”。验证失败。Round 1 - Reflect我在loop-log.md记下“缺少测试文件”。下一轮 Plan 时这条记录被喂回去模型主动补上了测试。Round 2 - Act补测试跑验证测试通过。进入第二条任务。Round 2 - Verify替换 Feed.tsx 的调用类型检查报错——返回 string 但期望 Date。这正是我前面举例的那个坑。Round 3 - Reflect Act记录根因模型在调用处包了new Date()验证通过。整个任务跑了 5 轮总耗时约 12 分钟其中我人工介入两次审清单、看 diff。如果纯手动这个任务加上写测试、调试我估计要 40 分钟以上。4.4 参数选择与轮次控制最大轮次设多少合适我的经验公式是任务步骤数 × 1.5向上取整最低 5 轮。4 步任务就设 6 轮。这个系数留出了试错空间又不至于无限空转。每轮之间的间隔如果是自动循环建议加一个 2 到 3 秒的延迟。原因很实际文件系统写入和 git 状态更新需要时间跑太快偶尔会读到旧文件。这个坑我在早期版本踩过表现为“明明改了却验证不过”排查半天才发现是时序问题。5. 常见问题与排查技巧实录5.1 循环跑不起来的典型症状用这套方法我整理了一份高频问题速查表基本都是实测踩出来的症状可能原因排查方向每轮都验证失败项目基线测试本身是红的先手动跑 verify.sh 确认基线模型反复改同一个错失败记忆没喂回去检查 loop-log 是否进入上下文改动越来越大任务粒度太粗拆分 tasks.md单步不超 50 行验证命令超时集成测试混进了每轮循环把慢测试挪到里程碑节点上下文爆掉日志和 diff 全量塞入只保留最近 3 轮记录5.2 关于工具协同的几个坑Claude Code 和 Cursor 同时开着改同一个文件是灾难。我踩过一次两边各改各的git diff 一团乱。正确做法是同一时间只有一个工具持有写权限。我的习惯是 Claude Code 跑自动循环时Cursor 只读不写等循环停下来再人工审查。Codex 接入其他模型做备选方案时要注意输出格式的统一。不同模型的代码风格差异很大如果不加约束循环里会混进各种命名习惯。解决办法是在prompts/act.md里写死代码规范比如“所有函数用 camelCase所有常量用 UPPER_SNAKE_CASE”。5.3 独家避坑技巧第一个技巧给验证脚本加超时。用timeout 120 bash .loop/verify.sh防止某个测试卡死拖垮整个循环。我遇到过 watch 模式的测试被误触发一直不退出循环直接挂起。第二个技巧每轮循环前自动 git commit。这样任何一轮改崩了都能一键回滚。命令很简单在循环脚本里加git add -A git commit -m loop round $N。回滚时git reset --hard HEAD~1就行。第三个技巧用 diff 大小做健康度指标。如果某一轮 diff 突然超过 200 行八成是模型跑偏了应该立即中断人工检查。正常的小步循环每轮 diff 应该在 10 到 50 行之间。第四个技巧提示词里明确“不要做什么”。模型很爱自作主张比如顺手重构无关代码、升级依赖版本。在act.md里加一句“只修改任务清单指定的文件禁止改动其他文件”能省掉大量意外。5.4 循环工程的边界最后说点实在的Loop Engineering 不是银弹。它最适合有明确验证标准的任务——写函数、修 bug、加测试、重构有测试覆盖的模块。对于“设计一个新架构”“做一个产品决策”这类没有客观验证标准的任务循环反而会空转。这时候应该退回到人工主导把 AI 当参谋而不是执行者。我个人的判断标准是如果这个任务你能写出一个自动化的通过/失败判定就适合循环写不出来就别硬套。这个标准帮我省下了大量无效尝试。这套循环我跑了小半年最大的体会是AI 编程的上限不取决于模型多强而取决于你给它搭的跑道多稳。跑道搭好了中等模型也能跑出稳定产出跑道没搭好再强的模型也是随机漫步。后面我打算把这套结构进一步脚本化让它能一键启动、自动记录、失败自动回滚到时候再分享新的进展。
阅读完成 · 觉得有帮助？
