1. 从写提示词到搭回路Loop Engineering 到底在解决什么问题大多数人接触 AI 编程工具的第一天脑子里装的都是提示词怎么写。写了两周之后你会发现真正卡住你的根本不是某一句提示词够不够精妙而是整个流程跑不起来改完一个文件忘了跑测试跑完测试忘了看报错看完报错又忘了刚才改的是哪一行。一次两次靠脑子记还行任务一多、上下文一长人就成了整个系统里最不可靠的那个环节。Loop Engineering 这个词最近被反复提起本质上说的就是这件事把人盯着 AI 一步步干活变成设计一套能自己转起来的回路。回路里有几个固定角色——执行者负责动手验证者负责挑刺反馈通道负责把挑出来的问题送回执行者手里直到满足退出条件为止。听起来像软件工程里的 CI/CD但对象从人写的代码换成了AI 生成的代码节奏也从提交一次跑一次变成了每轮对话都在跑。我自己的体会是Loop Engineering 的价值不在于让 AI 更聪明而在于让 AI 的产出变得可验证、可复现、可收敛。没有回路的 AI 编程就像让一个实习生闭着眼睛改代码改完还不给你看 diff。有了回路你至少知道每一轮改了什么、为什么改、改完有没有变好。这篇内容会围绕 Loop Engineering 的完整落地来讲涉及 Claude Code、Codex、Cursor 这几个主流工具在回路里各自扮演什么角色怎么搭一套能跑通的 harness以及我在实际项目里踩过的那些坑。不管你是刚装好 Claude Code 的新手还是已经在用 Cursor 写了大半年代码的老手应该都能从里面找到能直接抄的部分。2. 回路里的四个角色谁执行、谁验证、谁反馈、谁喊停在动手搭之前得先把回路的结构想清楚。很多人一上来就急着配工具、装插件结果搭出来的东西跑两轮就散了根本原因是没想明白每个环节的职责边界。2.1 执行者不是最强的模型而是最合适的模型执行者就是真正动手改代码的那个角色。这里有个特别常见的误区很多人默认执行者一定要用最强的模型觉得越贵越好。实际跑下来完全不是这么回事。执行者的核心要求是稳定、可控、上下文管理清晰。它需要能准确理解任务边界不会自作主张改一堆无关文件也不会因为上下文太长就开始胡编。Claude Code 在这方面的表现比较突出它的文件操作是显式的每次改动你都能看到具体动了哪些文件、哪些行这对回路来说非常关键——因为验证者需要知道这一轮到底改了什么。Codex 作为执行者也有它的优势尤其是在纯代码生成任务上它的输出往往更干净不会带太多解释性文字。但它的上下文窗口管理策略和 Claude Code 不太一样长任务里需要更频繁地做状态同步。我的建议是执行者选你用得最熟的那个。因为回路跑起来之后你需要频繁地介入、调整、看日志工具越熟调试成本越低。新手可以从 Claude Code 入手它的交互反馈比较友好如果你已经在用 Codex 写代码那就继续用 Codex没必要为了追新换工具。2.2 验证者回路的灵魂也是最容易被忽略的角色验证者是整个回路里最容易被敷衍的一环。很多人搭回路的时候执行者配得特别认真验证者就随便写个检查一下有没有报错结果回路跑起来形同虚设。验证者要做的事情比看有没有报错复杂得多。它至少要覆盖三层语法层代码能不能跑有没有明显的类型错误、未定义变量、导入缺失。这一层用编译器、linter、类型检查器就能搞定成本最低。逻辑层改动有没有实现预期功能边界条件处理了没有异常路径覆盖了没有。这一层需要测试用例最好是执行者改代码之前就存在的测试。意图层改动有没有偏离原始需求有没有引入不必要的复杂度有没有破坏原有的设计约定。这一层最难自动化通常需要人来看但可以通过让验证者输出改动摘要 风险点来降低人的阅读成本。我见过太多人把验证者写成跑一下测试然后测试挂了也不看具体哪条挂了直接让执行者再改改。这不是回路这是碰运气。2.3 反馈通道把哪里错了说清楚比错了重要一百倍反馈通道的质量直接决定回路能不能收敛。一个糟糕的反馈是测试没通过你再改改一个好的反馈是第 3 个测试用例失败期望返回 200 实际返回 500错误堆栈指向 user_service.py 第 47 行的空指针解引用。后者之所以好是因为它给了执行者足够的信息去定位问题而不是让它盲目地猜。在 Claude Code 里你可以直接把测试输出粘贴回去它会自己解析堆栈在 Codex 里你可能需要把关键行摘出来因为它对超长输出的处理策略不同。这里有个实操技巧反馈里永远带上上一轮改了什么。因为执行者的上下文是有限的跑了几轮之后它可能已经忘了自己第一轮改过什么。把 diff 摘要附在反馈里能显著降低它改回去或者改重复的概率。2.4 退出条件什么时候停比什么时候开始更难判断退出条件设得太松回路会一直跑烧钱又烧时间设得太紧回路会在问题还没解决的时候就停你还得手动重启。我一般会设三层退出条件硬性条件所有测试通过 类型检查通过 lint 通过。这是底线不满足绝不退出。软性条件连续两轮改动幅度小于某个阈值比如 diff 行数少于 5 行说明已经收敛了可以停。兜底条件轮次上限比如最多跑 10 轮。防止回路陷入死循环尤其是当问题本身无解的时候。这三层条件要同时配置任何一层触发都可以退出。实际跑下来大部分任务在第 3 到第 5 轮就收敛了跑到 10 轮的通常是需求本身有问题需要人介入重新拆解。3. 用 Claude Code 搭一套最小可跑回路理论说完了直接上实操。这一节我用 Claude Code 搭一套最小可跑的回路跑通之后你再往里面加东西。3.1 环境准备装完之后先别急着写代码Claude Code 的安装本身不复杂但有几个细节新手特别容易忽略。首先是 Node 版本。Claude Code 对 Node 版本有要求太老的版本会直接报错。装之前先跑node -v确认一下建议用 18 以上的 LTS 版本。如果你机器上有多个 Node 版本用 nvm 切一下别用系统自带的那个。其次是工作目录。Claude Code 默认会在你启动它的目录下操作文件所以一定要在项目根目录启动不要在 home 目录或者桌面启动。我见过有人在家目录启动结果 Claude Code 把整个 home 目录当成了项目上下文读了一堆无关文件token 直接爆掉。启动之后第一件事是让它读一下项目结构你可以直接说先看一下这个项目的目录结构和主要文件不要改任何东西。这一步的目的是让它建立上下文同时你也能观察它读文件的方式对不对。注意Claude Code 在读取文件时会消耗 token项目越大消耗越快。如果项目里有 node_modules、dist、.git 这类目录提前在配置里排除掉能省不少钱。3.2 把任务拆成可验证的小块回路能不能跑起来很大程度上取决于任务拆得够不够细。一个帮我实现用户登录功能的任务扔给回路基本跑不动因为验证者根本不知道从哪验起。正确的拆法是拆到每一块都有明确的输入输出和验证方式。比如用户登录可以拆成定义用户数据模型验证模型文件存在字段完整实现密码哈希函数验证单元测试通过相同输入输出一致实现登录接口验证接口测试通过正确密码返回 token错误密码返回 401实现 token 生成和校验验证token 能生成、能校验、过期能识别每一块都是一个独立的回路单元跑完一块再跑下一块。这样即使某一块卡住了也不会影响其他部分而且验证者的工作变得非常明确。3.3 写一个验证脚本而不是靠嘴说这是整个回路里最值得投入时间的地方。不要指望用自然语言告诉 Claude Code你验证一下它验证的质量完全取决于你怎么描述。更好的做法是写一个真正的验证脚本让回路去跑这个脚本。比如针对实现密码哈希函数这一块你可以先写一个测试文件# test_password.py import pytest from auth.password import hash_password, verify_password def test_hash_consistency(): h1 hash_password(test123) h2 hash_password(test123) assert h1 h2, 相同输入应产生相同哈希 def test_hash_different_input(): h1 hash_password(test123) h2 hash_password(test456) assert h1 ! h2, 不同输入应产生不同哈希 def test_verify_correct(): h hash_password(test123) assert verify_password(test123, h) is True def test_verify_wrong(): h hash_password(test123) assert verify_password(wrong, h) is False然后回路里的验证步骤就变成一句话跑pytest test_password.py如果失败把失败信息反馈给执行者。这样验证标准是客观的不依赖模型的理解。3.4 跑第一轮观察它怎么想第一轮不要急着让它改代码先让它说出计划。你可以这样下指令我要实现密码哈希功能文件放在 auth/password.py。先不要写代码告诉我你打算怎么做包括用什么库、函数签名是什么、边界条件怎么处理。这一步的价值在于你能提前发现它的方案有没有问题。比如它可能打算用 md5你一看就知道不对直接纠正如果等它写完再发现就得多跑一轮回路。确认方案没问题之后再让它动手。动手的时候要求它每改一个文件就说明改了什么这样你能实时跟踪进度也方便后面写反馈。3.5 反馈怎么写才能让它真的改对第一轮跑完测试大概率不会全过。这时候反馈的写法就很重要了。差的反馈测试没通过再改改。好的反馈跑了pytest test_password.py4 个用例里 2 个失败test_verify_correct 失败期望 True实际 False。看起来是 verify_password 里的比较逻辑有问题。test_hash_different_input 失败两个不同输入产生了相同哈希可能是 salt 没加或者加错了。 其他两个用例通过。请只修改 auth/password.py不要动测试文件。这个反馈里包含了跑了什么、哪些失败、失败的具体表现、你的初步判断、修改范围限制。执行者拿到这个基本一轮就能改对。提示反馈里明确不要动测试文件非常重要。否则执行者可能会去改测试来让测试通过这是回路里最危险的行为之一。4. Codex 和 Cursor 在回路里的分工别指望一个工具干所有事很多人纠结到底用 Claude Code 还是 Codex 还是 Cursor其实这个问题本身就问错了。这三个工具在回路里的定位完全不同用对了是互补用错了是互相拖累。4.1 Codex 适合当批量执行器不适合当交互式调试器Codex 的强项是批量生成代码。你给它一个明确的任务描述它能一次性产出大量代码而且风格比较统一。在回路里它适合承担执行者的角色尤其是当任务比较独立、不需要频繁交互的时候。但 Codex 不太适合做交互式调试。它的反馈循环没有 Claude Code 那么即时你改一句它回一句的节奏比较慢。所以如果你的回路需要频繁地改一点、看一下、再改一点Codex 不是最佳选择。我的用法是用 Codex 做初版生成用 Claude Code 做迭代调试。比如一个新模块先让 Codex 按需求生成一版完整代码然后切到 Claude Code 里跑测试、修 bug、调边界。这样两边都发挥了自己的长处。4.2 Cursor 的价值在人机协同编辑不在全自动回路Cursor 和前面两个的定位差别最大。它本质上是一个增强版的编辑器AI 是嵌在编辑体验里的。它的强项是你写一半它补一半、你选中一段它帮你改这种协同编辑的体验是 Claude Code 和 Codex 给不了的。但在全自动回路里Cursor 的角色比较尴尬。因为回路需要的是无人值守地跑而 Cursor 的设计哲学是人在环路中。你很难让 Cursor 自己跑一个完整的改代码-跑测试-看结果-再改的循环它更适合你在回路卡住的时候手动介入去调那几行关键代码。所以我的建议是回路用 Claude Code 或 Codex 跑卡住的时候切到 Cursor 手动调。Cursor 的中文设置、汉化这些配置问题网上教程很多这里不展开重点是你得想清楚它在你的工作流里到底承担什么。4.3 三个工具的能力对照维度Claude CodeCodexCursor回路中的定位交互式执行者批量执行者人工介入工具上下文管理显式、可控批量、需同步编辑器内、局部反馈循环速度快中快人工触发适合的任务迭代调试、边界处理初版生成、批量重构精细调整、局部修改自动化程度高高低学习成本中中低这张表不是让你选一个而是让你知道什么时候该切哪个。回路跑得顺的时候用 Claude Code需要大批量产出的时候切 Codex卡在某个细节上手动调的时候开 Cursor。5. Harness Engineering把回路工程化的关键一层前面讲的都是怎么让回路跑起来这一节讲怎么让回路跑得稳、跑得久、跑得可维护。这就是 Harness Engineering 要解决的问题。5.1 什么是 harness为什么它比模型更重要Harness 直译是马具在 AI 编程语境里它指的是包裹在模型外面的那一层工程结构任务怎么拆、上下文怎么管、验证怎么做、失败怎么重试、日志怎么记、成本怎么控。很多人把注意力全放在用哪个模型上觉得换个更强的模型就能解决问题。实际跑下来你会发现同一个模型harness 搭得好和搭得差产出质量能差出好几倍。模型是发动机harness 是底盘和传动系统发动机再强底盘不行也跑不快。一个完整的 harness 至少包含这几块任务队列待处理的任务列表每个任务有明确的输入、输出、验证方式上下文管理每个任务需要哪些文件、哪些历史信息怎么裁剪、怎么注入验证执行器跑测试、跑 lint、跑类型检查的统一入口反馈格式化把验证结果整理成执行者能理解的格式状态持久化每一轮的改动、验证结果、反馈都记下来方便回溯成本控制token 消耗、轮次上限、超时退出5.2 上下文管理回路里最容易失控的地方上下文管理是 harness 里最容易被低估的部分。回路跑起来之后每一轮都会往上下文里塞东西上一轮的 diff、验证结果、反馈、新的文件内容。几轮下来上下文就爆了。我的做法是分层管理上下文常驻层项目结构、核心约定、当前任务的原始需求。这部分每轮都带但内容要精简。滚动层最近 2 到 3 轮的 diff 和验证结果。这部分每轮更新旧的丢掉。按需层当前正在改的文件内容。这部分只在需要的时候注入改完就撤。这样能把上下文控制在合理范围内同时保证执行者始终能看到最近发生了什么和当前要改什么。注意不要把所有历史都塞进上下文指望模型自己记住。模型的记忆是不可靠的而且上下文越长它越容易忽略中间部分的内容。主动裁剪比被动依赖更靠谱。5.3 失败重试不是所有失败都值得重试回路跑起来之后失败是常态。但不是所有失败都应该触发重试。我一般把失败分成三类可重试失败测试挂了、lint 报错、类型不匹配。这类失败有明确的错误信息执行者拿到反馈后大概率能改对值得重试。需人工介入的失败需求本身有歧义、验证标准不明确、连续多轮改动方向都不对。这类失败重试再多也没用得人来重新拆任务。环境失败依赖没装、端口被占、网络超时。这类失败跟代码无关修环境就行不用走回路。Harness 里要能区分这三类可重试的自动重试需人工的挂起等介入环境问题直接报错退出。不加区分地一律重试只会浪费时间和 token。5.4 日志回路跑完之后你得能复盘日志这件事跑的时候觉得没用出问题的时候觉得救命。我要求 harness 记录每一轮的任务 ID、轮次、执行者改动的文件列表、diff 摘要、验证结果、反馈内容、token 消耗、耗时。这些信息在复盘的时候特别有用你能看出哪类任务容易卡、哪个环节最费 token、哪种反馈格式最有效。日志不用搞得很复杂一个结构化的 JSON 文件就行每轮追加一条。跑完之后用脚本统计一下很快就能发现规律。6. 实战用回路重构一个半成品模块光讲理论没意思这一节用一个真实场景走一遍完整流程。场景是手上有一个半成品的数据处理模块功能能跑但边界处理很烂测试覆盖率不到 30%想用回路把它重构到测试覆盖率 80% 以上。6.1 先摸清现状别急着让 AI 动手第一步不是让 AI 改代码而是让它读代码并输出一份现状报告。指令可以这样写读一下 data_processor 目录下的所有文件输出一份报告包含每个文件的职责、主要函数列表、当前测试覆盖了哪些函数、哪些函数完全没有测试、你判断哪些地方边界处理有问题。不要改任何代码。这一步的价值在于你能拿到一份结构化的现状描述同时也能验证 AI 对代码的理解对不对。如果它读错了后面全白搭。6.2 按风险 × 改动量排优先级拿到现状报告之后不要按文件顺序一个个改而是按优先级排。我的排序逻辑是高风险 小改动优先做。比如一个核心函数缺了空值检查改两行就能修收益大风险小。高风险 大改动排第二。比如核心逻辑需要重写改动大但必须做。低风险 小改动排第三。顺手做掉。低风险 大改动最后做或者干脆不做。投入产出比太低。这个排序逻辑要明确写进 harness 的任务队列里让回路按这个顺序跑。6.3 每一轮只做一件事回路跑起来之后最容易犯的错是一轮改太多。一轮改三个函数测试挂了你根本不知道是哪个函数的问题。我的做法是每一轮只改一个函数或者一个明确的逻辑单元。改完立刻跑测试通过了再进下一个。这样虽然轮次多但每轮的问题都很清晰调试成本低。具体到操作上你可以在指令里明确限制这一轮只修改parse_date函数其他函数不要动。执行者拿到这个限制改动范围就锁死了。6.4 测试先行的具体操作重构场景下测试先行特别重要。因为你要改的是已有代码如果没有测试兜底改完你都不知道有没有改坏。具体操作是先让 AI 为待改函数补测试测试通过之后再改函数本身。补测试的时候要求它覆盖正常输入、边界输入空值、极值、特殊字符、异常输入类型错误、格式错误。补完测试跑一遍确认测试能过说明测试写对了然后再让 AI 改函数。改完之后再跑一遍测试如果挂了说明改动引入了问题反馈回去继续改。这个流程看起来慢但实际跑下来比改完再补测试快得多因为问题在最早的时候就被发现了。6.5 一个真实的踩坑记录说个我实际踩过的坑。有一次重构一个日期解析函数AI 补的测试里有一个用例是parse_date(2024-02-30)期望返回 None。测试通过了函数也改完了看起来一切正常。结果上线之后发现生产环境里有大量2024-02-29这种闰年日期函数返回了 None导致数据丢失。原因是 AI 补测试的时候只考虑了非法日期返回 None没考虑合法但特殊的日期要正常解析。这个坑的教训是AI 补的测试你要自己过一遍。它补的测试往往覆盖了它想到的情况但想不到的情况它也不会补。尤其是业务相关的边界只有你知道哪些日期是合法的、哪些是特殊的。后来我在 harness 里加了一条规则AI 补完测试之后必须输出一份测试覆盖的场景列表我人工确认一遍再继续。这个规则加进去之后类似的坑就再没踩过。7. 回路跑不动的时候先检查这五个地方回路搭起来之后跑不动是常态。这一节列几个我遇到最多的问题以及对应的排查思路。7.1 执行者改错地方上下文注入有问题表现是执行者改了不该改的文件或者改了一个跟任务无关的函数。原因通常是上下文里塞了太多无关文件执行者分不清哪些是当前任务相关的。排查方法看 harness 的日志确认这一轮注入了哪些文件。如果注入了超过 5 个文件大概率是上下文太杂了。解决方法是精简注入范围只给当前任务直接相关的文件。7.2 验证者验了个寂寞验证标准太模糊表现是验证通过了但实际功能是坏的。原因通常是验证标准写得太模糊比如检查代码是否正确这种AI 随便看看就说过。排查方法把验证标准改成可执行的脚本或明确的检查项。比如跑 pytest 且全部通过、跑 mypy 且无错误、检查函数签名是否为def parse_date(s: str) - Optional[date]。标准越具体验证越可靠。7.3 回路原地打转反馈没有新信息表现是跑了好几轮改动来回横跳问题始终没解决。原因通常是反馈里没有新信息执行者每轮拿到的反馈都差不多只能瞎猜。排查方法看日志里每轮的反馈内容如果连续几轮反馈几乎一样说明验证环节没有提供新的诊断信息。解决方法是让验证者输出更详细的失败信息比如具体的错误堆栈、失败的输入值、期望值和实际值的对比。7.4 成本悄悄失控没有轮次和 token 上限表现是跑了一晚上第二天发现账单爆了。原因是没有设轮次上限和 token 上限回路一直在跑。排查方法在 harness 里加硬性上限轮次不超过 10 轮单任务 token 不超过某个值超了就挂起等人工确认。这个上限要根据任务复杂度调整简单的任务 3 轮就够复杂的可以放宽到 15 轮。7.5 人被排除在外没有介入点表现是回路跑着跑着方向完全偏了但人一直没发现等发现的时候已经跑了很多轮。排查方法在 harness 里设几个检查点比如每 3 轮暂停一次输出当前状态让人确认。确认没问题再继续有问题就调整方向。这个检查点不用太频繁否则就失去了自动化的意义但也不能没有。8. 一些跑久了才明白的经验回路这东西跑得越多越会发现一些反直觉的地方。第一不是所有任务都值得搭回路。一次性任务、探索性任务、需求还在变的任务搭回路反而是负担。回路适合的是目标明确、验证清晰、需要反复迭代的任务。判断标准很简单如果这个任务你手动做也就十分钟那就别搭回路了。第二回路的瓶颈往往不在模型而在验证。模型再强验证跟不上回路就跑不出高质量的结果。我花在写验证脚本上的时间比花在调提示词上的时间多得多但回报也大得多。第三反馈的质量比反馈的数量重要。与其跑十轮模糊的反馈不如跑三轮精准的反馈。每一轮反馈都要让执行者拿到新的、具体的信息否则就是浪费。第四人始终要在环路里只是位置变了。Loop Engineering 不是把人踢出去而是把人从每一步都盯着变成设计回路、设检查点、处理异常。人的价值在于判断不在于执行。第五工具会变回路的思路不会变。Claude Code、Codex、Cursor 这些工具版本更新很快功能也在变。但执行-验证-反馈-退出这个基本结构是稳定的。把思路搞清楚换工具的时候迁移成本很低。最后分享一个我一直在用的小技巧每次搭新回路的时候先用一个玩具任务跑通全流程。比如写一个只有两个函数的模块跑一遍完整的回路确认每个环节都通了再上真实任务。这样能把环境问题、配置问题、流程问题在低成本的情况下暴露出来比直接上真实任务踩坑划算得多。