1. 从“会写代码”到“会设计循环”：Loop Engineering 到底在解决什么问题
第一次听到 Loop Engineering 这个词，很多人会以为是某种新的编程语言或者框架。其实不是。它更像是一种工作方法论，核心就一句话：把 AI 编程工具从“一问一答的聊天框”改造成“能自己转起来的工程流水线”。你给它一个目标，它自己拆任务、自己写代码、自己跑测试、自己看报错、自己改，改完再跑，直到通过为止。这个“自己转起来”的过程，就是 Loop。
我最早接触这个概念是在用 Claude Code 做一个小工具的时候。当时我的做法很原始：在终端里敲一句需求，等它生成代码，我复制出来跑，报错了再贴回去让它改。来回折腾了十几次，人累得不行。后来我意识到，Claude Code 本身就能直接执行终端命令，我完全可以让它自己跑测试、自己看结果。把这一步打通之后，效率直接翻了好几倍。这就是 Loop Engineering 的雏形——让工具自己形成闭环，而不是你当那个来回搬运信息的人。
这套方法适合谁？我觉得三类人最该学。第一类是已经在用 Cursor、Claude Code、Codex 这类工具，但还停留在“复制粘贴”阶段的开发者；第二类是想把 AI 编程引入团队流程，但不知道怎么落地的技术负责人；第三类是对 Harness Engineering 感兴趣，想理解“怎么给 AI 搭一套可靠的运行框架”的人。不管你用的是哪家的工具，Loop 的思路是通用的。
需要先说明一点：Loop Engineering 不是一个官方标准术语，它更像是社区里对一类实践的归纳。不同人叫法不一样，有人叫 agentic workflow，有人叫 self-correcting loop，但内核是一致的——用工程化的手段，把 AI 的“生成-验证-修正”变成一个自动运转的循环。下面我会从设计思路、核心细节、实操过程、问题排查几个层面，把这套东西拆开讲清楚。
2. 整体设计思路：为什么是“循环”而不是“对话”
2.1 对话模式的三个致命瓶颈
大部分人用 AI 编程工具的方式，本质上是“对话模式”：我说一句，它回一句。这种方式在写小片段的时候没问题，但一旦任务稍微复杂一点，就会暴露三个瓶颈。
第一个瓶颈是上下文丢失。对话轮次一多，前面说过的约束条件它可能就忘了。你让它“用 Python 3.10 的语法”，改到第五轮它可能就用了 3.12 的新特性。第二个瓶颈是验证缺失。它生成的代码对不对，全靠你自己跑。你不跑，它永远不知道自己错了。第三个瓶颈是人工搬运。报错信息要你复制，测试结果要你粘贴，这个搬运过程既耗时又容易出错。
Loop Engineering 的设计初衷，就是针对这三个瓶颈。它的思路是：把验证环节交给工具自己，把修正环节也交给工具自己，人只负责设定目标和边界。
2.2 一个 Loop 的最小构成要素
我总结下来，一个能跑起来的 Loop 至少需要四个要素。
- 目标定义：用自然语言描述清楚“做完之后应该是什么样”。比如“写一个函数，输入一个整数数组，返回去重后的升序数组，并且附带单元测试”。
- 执行环境：AI 能直接操作的环境。Claude Code 可以直接执行终端命令，这是它能做 Loop 的关键。Cursor 的 Agent 模式也能在项目里读写文件、跑命令。
- 验证机制：一个客观的“对错判据”。最常见的就是测试用例。跑通了就是过了，跑不通就是没过，没有模糊空间。
- 循环控制：设定最大迭代次数和退出条件。不能让它在死循环里无限跑下去，烧钱又烧时间。
这四个要素里，验证机制是最容易被忽略但最重要的。很多人搭 Loop 失败，就是因为没有给 AI 一个明确的“你错了”的信号。它自己觉得写对了，你也看不出来，Loop 就空转了。
2.3 为什么选 Claude Code 作为主力工具
市面上能做 Loop 的工具不少，我主力用 Claude Code，原因有几个。第一，它对终端命令的支持是原生的，不需要额外配置就能让 AI 跑pytest、npm test这类命令。第二，它的项目上下文理解能力比较强，能同时看到多个文件的关系。第三，它的迭代速度在实测中比较稳定，不会因为轮次多了就明显变慢。
Cursor 我也用，它的优势在于 IDE 集成度高，写代码的时候补全体验好。但做 Loop 的时候，Cursor 的 Agent 模式有时候会“想太多”，在不需要的地方做多余改动。Codex 我主要用来做代码审查的补充，它的风格偏保守，适合当第二双眼睛。
提示：工具选型没有绝对的对错，关键是看它能不能满足“执行-验证-修正”这个闭环。如果一个工具只能生成代码不能执行命令，那它做 Loop 就很吃力。
3. 核心细节解析：Loop 的四个关键环节怎么落地
3.1 目标定义：把“模糊需求”翻译成“可验证任务”
这一步是很多人栽跟头的地方。你跟 AI 说“帮我优化一下这个模块”，它根本不知道什么叫“优化”。是提速？是减少内存？是提高可读性？目标不明确，Loop 就没有终点。
我的做法是把目标写成“验收标准”的形式。举个例子，不要说“优化排序函数”，而要说“把排序函数的执行时间从 200ms 降到 50ms 以内，同时保证现有测试全部通过”。这样 AI 就知道：跑测试是验证正确性，测时间是验证性能，两个都满足才算完成。
再比如，你要它修一个 bug，不要只说“修一下这个报错”，而要说“修复这个报错，并且新增一个测试用例覆盖这个场景，确保以后不会再出现”。这样 Loop 的退出条件就很清晰：新测试通过，旧测试不挂。
3.2 执行环境：让 AI 真正“动手”而不是“动嘴”
Claude Code 安装完之后，在项目根目录启动，它就能读取项目文件、执行终端命令。这一步的关键是给它足够的权限，但不要给过大的权限。
我一般会这样配置：允许它读写项目目录下的文件，允许它执行测试命令和构建命令，但不允许它执行rm -rf这类危险操作。Claude Code 在执行命令前会询问，你可以选择“本次允许”或“始终允许”。对于测试命令这种高频操作，我会选“始终允许”，减少打断。
Ubuntu 下配置 Claude Code 的时候，注意 Node 版本要够新。我踩过一次坑，Node 16 跑不起来，升到 20 之后正常。Windows 桌面版的话，建议用 WSL2 环境，原生 Windows 终端有时候会有路径问题。
3.3 验证机制：测试是 Loop 的“红绿灯”
没有测试的 Loop 就是瞎转。我要求自己在启动 Loop 之前，必须先有一个能跑的测试命令。哪怕只有一个测试用例也行，关键是它要能给出明确的通过或失败信号。
常见的验证命令有这么几类：
| 验证类型 | 典型命令 | 适用场景 |
|---|---|---|
| 单元测试 | pytest/npm test | 函数级逻辑验证 |
| 类型检查 | mypy/tsc --noEmit | 类型安全验证 |
| 代码规范 | eslint/ruff check | 风格一致性验证 |
| 构建验证 | npm run build/cargo build | 集成可用性验证 |
| 性能基准 | pytest-benchmark | 性能指标验证 |
我通常会把单元测试和类型检查组合起来用。单元测试保证逻辑对，类型检查保证接口对。两个都过了，我才认为这一轮是成功的。
3.4 循环控制：设好“刹车”再上路
Loop 最怕的就是无限循环。AI 改一版，测试挂了；再改一版，还挂；再改，还挂。如果不设上限，它能跑到你账户余额见底。
我的习惯是设两个限制：最大迭代次数 10 次，连续 3 次没有进展就停。“没有进展”的定义是测试通过数没有增加。如果它连续三轮都在原地打转，说明它卡住了，这时候需要人介入看看是不是目标定义有问题，或者缺了什么关键信息。
Claude Code 本身没有内置的迭代计数器，这个需要你在提示词里写清楚。比如：“最多尝试 10 次，如果 10 次之后测试还没全过，就停下来告诉我卡在哪里。”
4. 实操过程：从零搭一个能跑的 Loop
4.1 环境准备与工具安装
先说 Claude Code 的安装。官方文档里有详细的步骤，我这边说几个容易出问题的地方。安装命令本身不复杂，但网络环境有时候会抽风。如果下载卡住，可以试试换个时间段，或者用镜像源。
安装完成之后，第一次启动会让你登录。登录方式按提示走就行。登录成功之后，在项目目录下输入claude就能进入交互界面。
Codex 的安装类似，Windows 桌面版和命令行版都有。我建议先用命令行版熟悉流程，桌面版适合日常使用。Codex 登录不上是常见问题，大部分情况是网络波动，重试几次或者换个网络环境通常能解决。
Cursor 的安装最简单，下载安装包一路下一步就行。装完之后建议先设置中文回复，在设置里搜“language”就能找到。Cursor 注册的时候，国内手机号是可以用的，收验证码的时候注意看短信，有时候会延迟。
4.2 项目初始化：把 Loop 的“跑道”铺好
我拿一个真实的小项目举例：写一个命令行工具，功能是读取一个 CSV 文件，按指定列排序，输出到新文件。这个任务不大不小，正好适合演示 Loop。
第一步，创建项目目录，初始化 Git。Git 很重要，因为 Loop 过程中 AI 会改很多文件，有 Git 你随时能回滚。
mkdir csv-sorter cd csv-sorter git init第二步，写一个最简的测试文件。注意，这时候还没有实现代码，测试肯定是挂的。没关系，Loop 的目的就是让它从挂变过。
# test_sorter.py import pytest from sorter import sort_csv def test_sort_by_name(): data = [{"name": "Charlie", "age": "30"}, {"name": "Alice", "age": "25"}, {"name": "Bob", "age": "28"}] result = sort_csv(data, "name") assert [r["name"] for r in result] == ["Alice", "Bob", "Charlie"] def test_sort_by_age(): data = [{"name": "Charlie", "age": "30"}, {"name": "Alice", "age": "25"}, {"name": "Bob", "age": "28"}] result = sort_csv(data, "age") assert [r["age"] for r in result] == ["25", "28", "30"]第三步，确认测试命令能跑。这时候跑pytest会报ModuleNotFoundError，因为sorter.py还不存在。这个报错就是 Loop 的起点。
4.3 启动 Loop：让 AI 自己转起来
在项目目录下启动 Claude Code，输入这样的提示词：
项目里有一个 test_sorter.py，里面定义了两个测试。请实现 sorter.py，让这两个测试全部通过。你可以执行 pytest 来验证。最多尝试 10 次，如果 10 次之后还没通过，停下来告诉我卡在哪里。
接下来就是看它表演。它会先读测试文件，理解接口要求，然后写sorter.py，然后跑pytest，看结果，如果挂了就改，改完再跑。这个过程完全自动，你只需要在旁边看着。
我第一次跑的时候，它第三轮就过了。第一轮它写了个基础版本，test_sort_by_name过了但test_sort_by_age挂了，因为年龄是字符串，排序结果不对。第二轮它加了key=lambda x: int(x["age"])，两个都过了。第三轮它自己跑了一遍确认，然后告诉我完成了。
4.4 关键参数与配置说明
Claude Code 的配置文件在用户目录下，可以设置默认模型、超时时间等。我一般会把超时设长一点，因为跑测试有时候比较慢。具体路径和字段名参考官方文档，不同版本可能有差异。
Codex 的配置文件解析起来稍微复杂一点，它支持多套配置切换。如果你遇到“无法加载组织设置”的报错，通常是配置文件格式有问题，检查一下缩进和引号。
Cursor 的设置主要在图形界面里，中文设置、字体大小、快捷键这些都能调。响应速度慢的话，可以试试关掉一些不常用的插件，或者升级到付费版，免费额度用完之后速度会明显下降。
5. 常见问题与排查技巧实录
5.1 Loop 跑不起来？先查这三个地方
问题一：AI 不执行命令，只生成代码。这种情况通常是权限没开。Claude Code 第一次执行命令会询问，如果你选了“拒绝”，它后面就不会再尝试了。重新启动，遇到询问的时候选“允许”。
问题二：测试命令本身有问题。比如pytest没装，或者路径不对。先在终端里手动跑一遍测试命令，确认它能正常执行。手动都跑不通，AI 更跑不通。
问题三：目标定义太模糊。AI 不知道什么叫“完成”，就会一直改。回头检查你的提示词，确保退出条件是明确的、可验证的。
5.2 常见报错速查表
| 报错信息 | 可能原因 | 解决方法 |
|---|---|---|
ModuleNotFoundError | 依赖没装 | 先pip install或npm install |
command not found | 工具没装或 PATH 不对 | 检查安装步骤，确认 PATH 配置 |
Permission denied | 文件权限不足 | chmod改权限，或用管理员权限 |
Timeout | 命令执行超时 | 调大超时时间，或优化测试速度 |
Context limit exceeded | 上下文太长 | 拆分任务，减少单次输入量 |
cc switch local proxy failed | 本地代理配置冲突 | 检查代理设置，关闭冲突项 |
5.3 独家避坑经验
坑一：不要让 Loop 碰生产代码。我一开始图省事，直接在主分支上跑 Loop，结果它改了一堆不相关的文件。后来我学乖了，每次跑 Loop 都新开一个分支，跑完确认没问题再合并。
坑二：测试用例要覆盖边界情况。只测正常路径的话，AI 很容易写出“看起来对但边界会挂”的代码。空数组、单元素、重复元素这些情况都要写进测试里。
坑三：迭代次数不要设太多。我试过设 20 次，结果它在第 15 次的时候开始“胡乱改”，把之前对的逻辑也改坏了。10 次是个比较合理的上限，超过 10 次还没搞定，说明问题不在 AI 的执行力，而在任务的定义。
坑四：定期检查 Git 状态。Loop 跑的时候，AI 可能会创建一些临时文件。跑完之后git status看一眼，把不需要的文件清理掉，保持项目干净。
坑五：Codex 和 Claude Code 可以配合用。我有时候让 Claude Code 跑 Loop，跑完之后让 Codex 做一次代码审查。两个工具的视角不一样，经常能发现对方漏掉的问题。
6. 从 Loop 到 Harness：把单次循环变成工程能力
6.1 Harness Engineering 是什么
Loop 解决的是“单次任务怎么自动完成”，Harness Engineering 解决的是“怎么让这套东西稳定、可重复、可规模化”。Harness 原意是“马具”，引申为“控制框架”。在 AI 编程的语境里，它指的是围绕 AI 工具搭建的一整套运行环境、约束规则和验证体系。
举个例子，你一个人用 Claude Code 跑 Loop，这是个人效率工具。但如果你想让团队里五个人都用同一套 Loop 流程，就需要 Harness：统一的提示词模板、统一的测试规范、统一的代码审查标准、统一的回滚机制。这些东西加起来，就是 Harness。
6.2 从个人 Loop 到团队 Harness 的三个升级
第一个升级是提示词模板化。把常用的 Loop 提示词写成模板，比如“修 bug 模板”“加功能模板”“重构模板”，团队成员直接套用，减少沟通成本。
第二个升级是验证自动化。个人跑 Loop 的时候，测试命令可以手动敲。团队协作的时候，应该把测试集成到 CI 里，每次提交自动跑。这样 Loop 的验证环节就不依赖个人操作了。
第三个升级是结果可追溯。每次 Loop 跑了多少轮、改了什么文件、最终测试结果如何，这些信息应该记录下来。出问题的时候能回溯，也能用来优化提示词。
6.3 一个实际的 Harness 配置示例
我在团队里推行的一套配置是这样的：项目根目录放一个.loop文件夹，里面有三个文件。
prompt-template.md：提示词模板，包含目标定义、验证命令、迭代上限。verify.sh：验证脚本，把测试、类型检查、构建串起来，一条命令跑完。loop-log.md：Loop 日志，每次跑完记录轮次、耗时、结果。
Claude Code 启动的时候，提示词里引用prompt-template.md的内容，验证环节调用verify.sh，跑完把结果追加到loop-log.md。这样一套下来，Loop 就从“个人手艺”变成了“团队资产”。
7. 我个人的一些实操体会
Loop Engineering 这套东西，我用了大概半年，最大的感受是：它把 AI 编程从“抽卡”变成了“流水线”。以前用 AI 写代码，像抽卡，运气好一次过，运气不好改半天。现在有了 Loop，过程可控了，结果可预期了，心态也稳了。
但我也要说句实话：Loop 不是万能的。它适合那些目标明确、验证清晰的任务。如果你自己都不知道要什么，Loop 只会帮你更快地跑偏。所以我现在花在“定义目标”上的时间，比花在“跑 Loop”上的时间还多。
另外，工具在快速迭代，今天好用的配置明天可能就变了。保持关注官方文档和社区讨论，及时调整自己的流程。我踩过的那些坑，很多都是因为版本更新导致的配置变化。
最后分享一个小技巧：Loop 跑的时候，不要干等着。我一般会同时开两个终端，一个跑 Loop，一个做别的事情。Loop 跑完会有提示音，听到声音再回来看结果。这样时间利用率最高。
这个内容后续还可以这样扩展：把 Loop 和代码审查结合起来，让 AI 在 Loop 通过之后自动生成 PR 描述；或者把 Loop 和监控结合起来，线上报错自动触发修复 Loop。这些方向我还在摸索，有进展再分享。
