1. 从“会写代码”到“会设计循环”Loop Engineering 到底在解决什么问题这两年 AI 编程工具迭代得飞快Claude Code、Codex、Cursor 一个接一个地冒出来很多人第一反应是“装哪个”“哪个免费额度多”“国内手机号能不能注册”。但真正把这类工具用进日常开发的人会发现工具本身只是入场券决定产出质量的是另一件事——你怎么设计它和代码库之间的循环。这就是 Loop Engineering 想聊的核心。我先把话说直白一点Loop Engineering 不是某个官方框架也不是某个具体产品的功能名它更像是一种工程实践思路。传统写代码循环是for、while是程序内部的执行结构而在 AI 辅助开发里循环变成了“你给模型一个任务 → 模型读代码、改代码、跑测试 → 你看结果 → 再给下一轮指令”这样一个闭环。这个闭环设计得好不好直接决定了你是十分钟搞定一个重构还是折腾两小时还在原地打转。为什么现在要专门聊这个因为大多数人用 Claude Code、Codex、Cursor 的方式还停留在“问答式”问一句、答一句、复制粘贴。这种方式在写小函数时还行一旦涉及跨文件改动、依赖升级、测试补齐就会立刻暴露问题——模型看不到全貌、上下文被截断、改完一处崩三处。Loop Engineering 要解决的就是把这个“问答”升级成“可控的迭代循环”让每一轮改动都有明确的输入、可验证的输出、以及可回滚的边界。这篇文章适合谁看如果你已经装过 Claude Code 或者用过 Cursor但总觉得“它好像没那么神”那这篇就是写给你的。如果你还没上手也没关系我会把安装、配置、循环设计、实战踩坑都串起来讲你照着抄作业就行。核心关键词我会自然带出来Loop Engineering、Claude Code、Codex、Cursor、Harness Engineering这几个词基本构成了当前 AI 编程工作流的主干。先说清楚一个前提这类工具的能力边界取决于你给它的“跑道”有多宽。跑道太窄它只能做补全跑道设计得好它能自己跑测试、自己修 bug、自己提交。Loop Engineering 干的就是修跑道这件事。2. 核心概念拆解Loop、Harness 与三种主流工具的定位差异2.1 什么是 Loop Engineering 里的“循环”在 AI 编程语境下一个完整的循环通常包含四个阶段感知读代码/读报错→ 决策规划改动→ 执行写代码/跑命令→ 验证测试/类型检查。这四个阶段每转一圈代码库就向前推进一步。Loop Engineering 的核心工作就是让这四个阶段尽可能自动化、可观测、可中断。我举个具体例子。假设你要给一个 Python 项目加一个缓存层。问答式做法是你问“帮我加个 Redis 缓存”模型给你一段代码你手动贴进去然后自己跑测试。循环式做法是你告诉 Claude Code“给services/user.py的get_user加缓存用项目里已有的cache模块加完后跑pytest tests/test_user.py”。模型会自己读文件、找模块、改代码、执行测试如果测试挂了它会在同一轮里继续修直到通过或者卡住向你求助。差别在哪差别在于验证环节被纳入了循环。没有验证的循环是开环模型改完就撒手有验证的循环是闭环模型必须对结果负责。这就是 Loop Engineering 最朴素也最重要的一条原则。2.2 Harness Engineering给循环搭一个“测试台”Harness 这个词在工程里原本指测试夹具、测试台架。Harness Engineering 放到这里指的是为 AI 编程循环搭建一套支撑设施包括但不限于项目规则文件、测试命令、lint 配置、权限白名单、上下文裁剪策略。你可以把 Harness 理解成“给模型准备的工位”。工位上有没有说明书项目规范、有没有质检员测试、有没有工具箱可调用的命令直接决定模型能不能独立干活。很多人抱怨 Codex 或 Claude Code “改着改着就乱改”八成是 Harness 没搭好——模型不知道你的代码风格、不知道哪些文件不能碰、不知道改完该跑什么命令。一个最小可用的 Harness 至少包含三样东西项目规则文件Claude Code 用CLAUDE.mdCodex 用AGENTS.mdCursor 用.cursorrules或项目规则。里面写清楚技术栈、目录结构、命名规范、禁止事项。可执行的验证命令测试、类型检查、lint最好一条命令能跑完。权限边界哪些目录可写、哪些命令可执行、哪些操作需要人工确认。这三样搭好循环才转得起来。否则模型每轮都要重新猜你的意图效率极低。2.3 Claude Code、Codex、Cursor 在循环里的角色差异这三个工具经常被放在一起比较但它们在 Loop Engineering 里的定位其实不一样。工具主要形态循环特点适合场景Claude Code终端/桌面 Agent自主性强能读多文件、跑命令、多轮自修跨文件重构、复杂任务、需要跑测试的改动Codex云端/本地 Agent任务式擅长独立完成一个明确目标独立功能开发、脚本编写、批量修改Cursor编辑器集成人在环中实时补全对话Agent 模式日常编码、边写边改、需要即时反馈Claude Code 的循环最“重”它倾向于自己规划、自己执行、自己验证适合把一整块任务丢给它。Codex 更像一个外包工程师你给需求它交付中间过程你不太需要盯。Cursor 则是“副驾驶”循环的每一圈你都在场适合需要频繁微调的场景。理解这个差异很重要因为 Loop Engineering 不是一套通用模板而是要根据工具特性调整循环的粒度。用 Cursor 时循环可以很碎几行代码一轮用 Claude Code 时循环要相对完整一个功能一轮。搞反了就会很难受——用 Claude Code 做碎活会觉得它啰嗦用 Cursor 做大重构会觉得它力不从心。3. 环境搭建实操从安装到跑通第一个循环3.1 Claude Code 的安装与初始化配置Claude Code 目前有终端版和桌面版两条路。终端版通过 npm 安装最省事前提是本机有 Node.js 环境建议 18 以上。npm install -g anthropic-ai/claude-code装完之后在项目根目录执行claude第一次会引导你完成登录和初始化。这里有个实操心得一定要在项目根目录启动而不是在 home 目录。因为 Claude Code 会以当前目录为工作区读取上下文在 home 目录启动它会去扫你整个用户目录既慢又容易读到无关文件。初始化时会生成一个CLAUDE.md这是 Harness 的核心文件。我的建议是不要让它自动生成完就不管了手动补上这几块内容# 项目说明 - 技术栈Python 3.11 FastAPI SQLAlchemy - 测试命令pytest -q - 类型检查mypy app/ - 代码风格black isort行宽 100 # 禁止事项 - 不要修改 migrations/ 下的历史迁移文件 - 不要直接改 .env配置走 config.py - 提交前必须跑通 pytest这份文件看起来简单但它直接决定了模型每轮循环的“行为准则”。我试过不写测试命令结果模型改完代码自己瞎猜怎么验证浪费好几轮。写清楚之后它改完会主动跑pytest -q效率完全不一样。Ubuntu 环境下如果遇到权限问题通常是 npm 全局目录的权限用npm config set prefix指到用户目录即可不建议直接sudo npm install -g后面升级会踩坑。VS Code 用户可以直接装 Claude Code 的官方扩展配置和终端版共用同一份CLAUDE.md。3.2 Codex 的安装与配置文件解析Codex 的安装分云端和本地两种。本地版同样依赖 Node 环境安装命令类似npm install -g openai/codexWindows 桌面版用户如果遇到安装包问题优先确认系统架构x64 还是 arm64和 Node 版本。Codex 的配置文件一般是~/.codex/config.toml或项目级的AGENTS.md。配置文件里几个关键项值得说model指定使用的模型不同模型在代码任务上的表现差异明显。approval_mode控制哪些操作需要人工确认。新手建议先用需要确认的模式跑顺了再放开。sandbox沙箱模式限制文件写入范围防止模型误改系统文件。Codex 接入第三方模型比如 DeepSeek是很多人关心的点。配置上一般是在 config 里改 base_url 和 api_key但要注意不同模型对工具调用的支持程度不一样有些模型不支持 function calling接进来之后 Codex 的 Agent 能力会大打折扣只能当普通对话用。这个坑我踩过接完发现它不会自己读文件了排查半天才意识到是模型能力问题。3.3 Cursor 的中文设置与注册注意事项Cursor 是编辑器形态安装就是下载安装包一路下一步。新手最常问的两个问题怎么设置中文回复、注册时手机号怎么填。中文回复分两层。一层是界面语言在设置里搜 “language” 改成中文即可。另一层是模型回复语言这个界面设置管不了得在 Rules 里加一句Always respond in Chinese (Simplified).加在 User Rules 或项目 Rules 里都行。我建议加在项目 Rules因为不同项目你可能想要不同语言。实测下来光改界面语言模型还是回英文必须显式在规则里声明。注册方面Cursor 支持多种方式具体能不能用某个地区的手机号取决于它当时的注册策略这个会变。我的建议是优先用邮箱注册省去手机号的麻烦。免费额度方面Cursor 的免费档有每月的补全和对话次数限制重度使用基本不够但用来体验循环工作流完全够。3.4 跑通第一个最小循环环境搭好后别急着上大项目。先拿一个小任务跑通完整循环建立手感。我通常用这个练手任务给一个已有函数补单元测试并让测试通过。步骤是这样的在项目里找一个没有测试的纯函数。对 Claude Code 说“给utils/format.py的format_duration补单元测试覆盖 0 秒、59 秒、60 秒、3600 秒四个边界测试文件放tests/test_format.py写完跑 pytest 确认通过。”观察它的循环读文件 → 写测试 → 跑 pytest → 如果失败就修 → 再跑。检查最终结果看测试是否真的覆盖了边界。这个任务小但完整走了一遍“感知-决策-执行-验证”。跑通之后你对循环的节奏就有感觉了。我第一次跑的时候模型把 60 秒的期望值写错了但它自己跑测试发现失败第二轮就改对了——这就是闭环的价值开环的话这个错误就留给你了。4. 循环设计的核心方法论粒度、上下文与验证4.1 循环粒度怎么定大循环 vs 小循环循环粒度是 Loop Engineering 里最需要经验判断的地方。粒度太粗模型一轮要干太多事容易跑偏粒度太细你光下指令就累死了。我的经验法则是一轮循环的产出应该是一个可以独立验证的最小单元。什么叫可独立验证就是改完之后你能明确说“对”或“不对”。比如“给这个函数加参数校验”是可验证的“优化一下这个模块”就不可验证。具体到不同任务单文件小改动一轮一个函数或一个方法Cursor 里几行一轮都行。跨文件重构一轮一个明确的改动目标比如“把UserService里的数据库调用抽到UserRepository”改完跑测试。新功能开发拆成“定义接口 → 实现 → 补测试 → 接路由”几轮每轮一个可验证产出。我见过最常见的错误是“一句话丢一个大需求”。比如“帮我做个用户登录系统”模型会给你一堆代码但质量参差不齐你还得逐行审。拆成几轮之后每轮产出都可控返工成本低得多。4.2 上下文管理让模型看到该看的屏蔽不该看的上下文是循环的燃料。给多了模型注意力被稀释还费 token给少了它看不到关键信息改出来的东西对不上。Claude Code 和 Codex 都会自动读相关文件但自动读取不一定准。我的做法是主动指路在指令里明确说“参考services/order.py的写法”或者“不要动legacy/目录”。这比让模型自己猜高效得多。还有一个技巧是用规则文件做长期上下文。把项目里反复出现的约定写进CLAUDE.md或AGENTS.md这样每轮循环它都会带上不用你每次重复。比如“所有数据库操作必须走 repository 层”“错误统一用AppError抛出”写一次管很久。上下文裁剪也要注意。大项目里模型读文件很容易读一堆无关的导致关键信息被挤掉。可以在规则里写明“优先读app/下的文件忽略node_modules/、dist/、venv/”。这些目录本来也不该进上下文。4.3 验证环节闭环的灵魂没有验证的循环等于没有循环。验证手段按可靠性排序大概是自动化测试 类型检查 lint 人工目测。理想情况下每轮循环至少跑前两样。为什么测试最重要因为它是唯一能真正证明“行为正确”的手段。类型检查能保证接口对得上但保证不了逻辑对。lint 只管风格。人工目测最不可靠你盯十行代码还行盯一百行必然漏。实操上我会在规则文件里写死验证命令并要求模型每轮改完必须跑。Claude Code 支持在CLAUDE.md里定义命令Codex 类似。如果项目还没有测试那第一轮循环的任务就是“补测试”而不是“改功能”。先把验证能力建起来后面的循环才有意义。有个细节测试跑得慢会拖垮循环节奏。如果全量测试要五分钟每轮都跑不现实。我的做法是让模型只跑相关测试文件比如pytest tests/test_user.py -q全量测试留到循环结束前跑一次。这个策略要写进规则否则模型可能每轮都跑全量。5. 项目实战用循环方式完成一次真实重构5.1 任务背景与循环规划假设我们有一个 FastAPI 项目services/user.py里混了数据库访问、业务逻辑、缓存操作文件快 500 行了。目标是把它拆成repository数据访问、service业务逻辑、cache缓存三层。这种重构如果问答式做基本是灾难——模型看不到全貌改一处崩一处。用循环方式我会这样规划第 1 轮让模型读user.py输出一份拆分方案不写代码。第 2 轮创建repositories/user_repository.py把数据库访问搬过去跑测试。第 3 轮创建services/user_service.py把业务逻辑搬过去跑测试。第 4 轮把缓存操作抽到cache/user_cache.py跑测试。第 5 轮更新调用方跑全量测试。每轮都有明确产出和验证点。第 1 轮不写代码很关键让模型先规划你能提前发现它的理解偏差避免它闷头改错方向。5.2 关键轮次的指令设计与执行记录第 2 轮的指令我是这么写的读services/user.py把其中所有直接使用db.session的数据库操作抽到新建的repositories/user_repository.py。repository 只做数据访问不包含业务判断。保持函数签名不变services/user.py里改为调用 repository。改完跑pytest tests/test_user.py -q失败就修到通过。这条指令有几个要点明确输入文件、明确输出文件、明确职责边界“不包含业务判断”、明确验证命令、明确失败处理策略“修到通过”。这五点写全模型基本不会跑偏。执行时我盯着它的循环它先读了user.py然后创建 repository 文件把db.session.query(...)这类调用搬过去再回user.py改调用。跑测试时挂了一个因为有个查询用了joinedload搬过去之后 import 没补。它自己发现报错第二轮补了 import测试通过。这个过程如果人工做大概二十分钟模型跑了大概三分钟我审代码花了两分钟。效率提升是实打实的但前提是循环设计对了。5.3 循环中的回滚与中断策略循环不是一路向前就完事回滚能力是安全网。我的习惯是每轮循环前确保工作区干净git status无未提交改动这样任何一轮出问题都能git checkout .一键回滚。Claude Code 和 Codex 在执行破坏性操作前一般会请求确认但别完全依赖它。我遇到过模型想删一个“看起来没用”的文件其实是被动态 import 的。所以规则文件里我会写“删除任何文件前必须明确说明理由并等待确认。”中断策略也很重要。如果模型连续两三轮都在同一个错误上打转别让它继续烧 token直接中断人工介入看看是不是上下文给错了。我踩过的坑是模型一直改不对一个测试我让它自己修了五轮最后发现是我在指令里把期望值写错了。循环卡住时先怀疑自己的输入再怀疑模型。6. 常见问题与排查技巧实录6.1 工具类问题速查现象可能原因处理方式Claude Code 启动后读不到项目文件启动目录不对在项目根目录启动检查CLAUDE.md位置Codex 无法加载组织设置配置或账号状态问题检查 config.toml重新登录确认账号权限Codex 登录不上网络或凭证过期重新走登录流程检查凭证文件Cursor 回复仍是英文只改了界面语言在 Rules 里加 “Always respond in Chinese”Cursor 响应慢上下文过大或模型负载精简打开的文件换轻量模型模型改完不跑测试规则里没写验证命令在规则文件里明确测试命令6.2 循环类问题排查思路工具问题好查循环问题更隐蔽。我总结了几条排查思路症状一模型改的代码风格和项目不一致。八成是规则文件没写清楚风格约定。补上“用 black 格式化行宽 100”这类具体规则。症状二模型反复改同一个地方改不对。先看指令有没有歧义再看上下文是不是缺了关键文件。有时候是模型没读到某个基类导致它不知道方法签名。症状三改完 A 功能B 功能挂了。这是典型的验证不足。要么测试覆盖不够要么没跑全量测试。补测试并在循环结束前强制跑一次全量。症状四模型“自作主张”改了不该改的文件。规则文件里加禁止清单明确哪些目录不能碰。6.3 几条踩坑换来的经验第一条规则文件是活的要持续维护。每次发现模型犯同类错误就往规则里加一条。我的CLAUDE.md从最初十行涨到现在六十多行每一条都是踩坑换来的。第二条别让模型一次改太多文件。一轮循环涉及的文件超过五个出错概率陡增。宁可多分几轮。第三条验证命令要快。慢测试会让人不自觉地跳过验证闭环就破了。用-k或指定文件的方式跑相关测试。第四条保留人工审查环节。循环再顺最终代码也得人看。模型能保证测试通过保证不了设计合理。我一般每轮循环后花一两分钟扫一眼 diff发现问题早返工少。第五条不同工具别混用同一套循环。Cursor 适合碎循环Claude Code 适合整循环硬套同一套节奏会别扭。根据工具特性调整才是 Loop Engineering 的正确姿势。这套东西说到底核心就一句话把 AI 编程从“问答”变成“可控迭代”。工具会一直变Claude Code 会升级Codex 会出新版Cursor 会加功能但循环设计的思路是通用的。把粒度、上下文、验证这三件事想清楚换什么工具都能快速上手。我自己从最早用 Cursor 补全到后来用 Claude Code 跑重构最大的体会就是模型能力固然重要但你给它搭的跑道才是决定它能跑多远的关键。