1. 从标题拆解 Loop Engineering 到底在讲什么第一次看到“Loop Engineering”这个词很多人会以为是某种新的编程语言或者框架。其实不是。它描述的是一套围绕 AI 编程助手构建“自动化循环工作流”的工程方法论。核心思路很简单不再把 Claude Code、Codex、Cursor 这类工具当成“问一句答一句”的聊天窗口而是把它们嵌入一个可重复、可验证、可迭代的闭环里让 AI 自己跑完“理解任务→生成代码→执行验证→根据反馈修正”的完整循环。我接触这套东西的契机很实际。早前用 Claude Code 写一个数据处理脚本第一版跑通了但边界条件没处理。我手动改了三次每次都要重新描述上下文效率很低。后来我把“运行测试→捕获报错→把报错喂回给模型→让它自己改”这个流程固定下来发现大部分小问题它能在两三轮内自己修好。这就是 Loop Engineering 的雏形——你设计的不是一段代码而是一个让 AI 持续自我修正的循环结构。这个教程适合几类人一是已经在用 Claude Code、Codex、Cursor 但还停留在“手动复制粘贴”阶段的开发者二是想把这些工具接入自己项目工作流、做自动化提效的工程师三是对 Harness Engineering 这个概念感兴趣、想搞清楚“脚手架”和“循环”怎么配合的人。不管你之前有没有用过这些工具只要你能跑命令行、能看懂基本的项目结构这篇内容都能让你搭出一套可用的循环工作流。需要先厘清一个容易混淆的点Loop Engineering 和 Harness Engineering 不是一回事但经常一起出现。Harness 指的是“脚手架”——你给 AI 准备的工具集、上下文、约束条件、验证手段相当于给它搭一个能安全干活的工作台。Loop 指的是“循环”——你让这个工作台自动运转起来的控制逻辑。Harness 是静态的准备工作Loop 是动态的运行机制。两者配合才能让 AI 编程助手从“辅助工具”变成“自动化流水线”。注意Loop Engineering 不是让 AI 完全替代你。它的价值在于把重复性的“生成-验证-修正”环节自动化让你把精力放在架构决策和关键逻辑上。指望它一键生成整个项目大概率会失望。2. 核心工具选型与 Harness 搭建思路2.1 Claude Code、Codex、Cursor 在循环里各扮演什么角色这三个工具虽然都能写代码但在 Loop Engineering 的框架里定位不同。我自己的用法是这样的Claude Code适合做“循环里的主力执行者”。它的命令行交互模式天然适合被脚本调用你可以用管道把任务描述传进去它输出代码或修改建议然后你的脚本捕获输出、执行验证、再把结果传回去。它的上下文窗口够大能hold住中等规模的项目文件。Codex更适合做“单点补全和快速验证”。它的响应速度快适合在循环里做小粒度的代码生成比如“根据这个函数签名补全实现”或者“把这个报错信息翻译成修复建议”。但它的上下文保持能力相对弱一些不适合做长链条的循环控制。Cursor的定位偏向“交互式开发环境”。它的优势在于编辑器集成和实时预览适合在循环的“人工审查”环节使用。你可以让循环自动跑几轮然后在 Cursor 里打开结果做最终确认和微调。它不太适合被脚本直接调用做自动化循环但作为循环的“终点站”很合适。工具选型没有绝对标准。我的建议是如果你刚开始搭循环先用 Claude Code 做主力因为它对命令行友好、输出格式稳定。等循环跑通了再考虑把 Codex 接进来做加速把 Cursor 接进来做审查。2.2 Harness 的三个必备组件Harness 这个词听起来抽象拆开看就三样东西第一是上下文供给。AI 在循环里每一轮都需要知道“当前项目长什么样”。这包括项目结构、关键文件内容、依赖列表、最近的修改记录。我通常会在项目根目录放一个context.md里面写清楚项目目标、技术栈、目录说明、已知约束。循环每一轮开始时脚本会把这个文件的内容拼进提示词里。第二是验证手段。循环要能自动判断“这一轮的结果是好是坏”。最直接的方式是跑测试。如果项目有单元测试就让循环每轮结束后执行pytest或npm test捕获退出码和报错信息。如果没有测试至少要有一个 lint 检查或者语法检查。没有验证手段的循环等于空转。第三是反馈通道。验证结果要能传回给 AI。这通常通过把报错信息、测试输出、diff 结果写入一个临时文件然后在下一轮提示词里引用这个文件来实现。反馈信息的质量直接决定循环的收敛速度——报错信息越具体AI 修正得越准。实操心得Harness 搭建最容易被忽略的是“上下文供给”的更新。很多人搭好循环后就不管了结果 AI 一直在用旧的上下文做决策。我的做法是每轮循环结束后自动把本轮修改的文件列表追加到context.md末尾这样下一轮 AI 能看到“上一轮改了什么”。2.3 循环控制的基本逻辑一个最小可用的循环控制逻辑大概长这样#!/bin/bash MAX_ROUNDS5 ROUND0 while [ $ROUND -lt $MAX_ROUNDS ]; do ROUND$((ROUND 1)) echo Round $ROUND # 构建提示词 cat context.md prompt.txt echo --- prompt.txt echo 上一轮验证结果 prompt.txt cat last_result.txt prompt.txt 2/dev/null # 调用 Claude Code claude --prompt $(cat prompt.txt) output.txt # 执行验证 npm test last_result.txt 21 EXIT_CODE$? if [ $EXIT_CODE -eq 0 ]; then echo 验证通过循环结束 break fi done这段脚本的逻辑很直白读上下文、调 AI、跑验证、判断是否继续。实际使用中你需要根据项目情况调整验证命令和提示词模板。关键点是设置最大轮数——没有这个限制循环可能陷入死胡同反复改同一个错误。3. 从零搭建一个可运行的 Loop 工作流3.1 环境准备与工具安装先把基础环境搭好。我假设你在 macOS 或 Linux 环境下操作Windows 用户建议用 WSL。Claude Code 的安装方式是通过 npm 全局安装npm install -g anthropic-ai/claude-code安装完成后在项目目录下运行claude会进入交互模式。首次使用需要配置 API 密钥这个在官方文档里有详细说明。如果你在国内网络环境下遇到连接问题可以配置代理或者使用兼容的 API 端点具体方式因环境而异。Codex 的安装类似npm install -g openai/codex-cliCursor 是图形化编辑器从官网下载安装包即可。安装完成后建议在设置里把语言改成中文方便后续操作。Cursor 的中文设置路径是Settings → General → Language → 中文简体。注意安装过程中如果遇到权限报错在命令前加sudo或者检查 npm 的全局目录权限。不要用--force强行安装容易留下残留文件。3.2 项目结构初始化循环工作流需要一个清晰的项目结构。我通常这样组织project/ ├── context.md # 上下文供给文件 ├── prompt_template.txt # 提示词模板 ├── loop.sh # 循环控制脚本 ├── last_result.txt # 上一轮验证结果 ├── src/ # 源代码目录 ├── tests/ # 测试目录 └── logs/ # 循环日志context.md的内容模板# 项目上下文 ## 项目目标 实现一个用户数据清洗脚本输入 CSV 文件输出清洗后的 JSON。 ## 技术栈 - Python 3.11 - pandas - pytest ## 目录说明 - src/cleaner.py主逻辑 - tests/test_cleaner.py单元测试 ## 已知约束 - 输入 CSV 可能包含空行和重复行 - 输出 JSON 需要保留原始列名 - 所有异常需要被捕获并记录到日志 ## 修改历史 每轮循环后自动追加这个文件是循环的“记忆”。AI 每一轮都会读它所以内容要准确、简洁、无歧义。3.3 提示词模板的设计要点提示词模板决定了 AI 在循环里“怎么干活”。我的模板通常包含四段第一段是角色定义。告诉 AI 它在循环里扮演什么角色比如“你是一个自动化代码修复助手你的任务是根据验证结果修改代码直到测试全部通过”。第二段是当前状态。引用context.md的内容让 AI 知道项目现状。第三段是上一轮结果。引用last_result.txt让 AI 知道上一轮哪里出了问题。第四段是输出要求。明确告诉 AI 输出格式比如“只输出需要修改的文件的完整内容不要输出解释文字”。这一点很关键——如果 AI 输出一堆解释你的脚本很难解析。你是一个自动化代码修复助手。根据以下项目上下文和上一轮验证结果 修改代码使测试全部通过。 ## 项目上下文 {{context}} ## 上一轮验证结果 {{last_result}} ## 输出要求 只输出需要修改的文件的完整内容格式为 FILE: 文件路径 文件内容 END 3.4 验证环节的配置验证是循环的“裁判”。我一般配三层验证第一层是语法检查。Python 用python -m py_compileJavaScript 用node --check。这一层最快能在 AI 输出格式错误时立刻拦截。第二层是单元测试。用 pytest 或 jest 跑测试套件捕获退出码和报错信息。这一层是主要判断依据。第三层是集成检查。如果项目有端到端的流程跑一个最小集成用例。这一层最慢但能发现单元测试覆盖不到的问题。# 三层验证的脚本示例 python -m py_compile src/*.py if [ $? -ne 0 ]; then echo 语法检查失败 last_result.txt exit 1 fi pytest tests/ -v last_result.txt 21 if [ $? -ne 0 ]; then echo 单元测试失败 last_result.txt exit 1 fi python -m src.integration_check last_result.txt 21实操心得验证脚本的输出要尽量精简。pytest 的-v模式输出很长AI 读起来费劲。我通常用--tbshort只输出关键报错或者自己写一个过滤脚本只保留失败用例的名称和报错行。4. 实战用 Loop 自动修复一个数据清洗脚本4.1 初始代码与测试用例假设我们有一个数据清洗脚本src/cleaner.py初始版本如下import pandas as pd import json def clean_data(input_path, output_path): df pd.read_csv(input_path) df df.drop_duplicates() df df.dropna() result df.to_dict(orientrecords) with open(output_path, w) as f: json.dump(result, f) return len(result)对应的测试用例tests/test_cleaner.pyimport pytest import pandas as pd import json import os from src.cleaner import clean_data def test_basic_cleaning(tmp_path): input_file tmp_path / input.csv output_file tmp_path / output.json input_file.write_text(name,age\nAlice,30\nBob,\nAlice,30\n) count clean_data(str(input_file), str(output_file)) assert count 1 with open(output_file) as f: data json.load(f) assert data[0][name] Alice这个测试会失败因为初始代码没有处理空值行的逻辑——dropna()会删掉 Bob 那行但 Alice 的重复行也会被删最终只剩一条记录count 应该是 1。但初始代码的dropna()在drop_duplicates()之后执行顺序有问题。4.2 第一轮循环AI 的初次修正运行循环脚本后第一轮 AI 收到的提示词里包含了测试报错信息。它输出的修改版本import pandas as pd import json def clean_data(input_path, output_path): df pd.read_csv(input_path) df df.dropna() df df.drop_duplicates() result df.to_dict(orientrecords) with open(output_path, w) as f: json.dump(result, f) return len(result)它把dropna()和drop_duplicates()的顺序调换了。这个修改是对的——先去空值再去重才能保证 Alice 的重复行被正确删除。测试通过。但这里有个隐患如果 CSV 里有完全空白的行dropna()默认会删掉任何包含空值的行可能误删有效数据。这个问题在当前测试用例里没暴露但在实际使用中会出现。4.3 第二轮循环处理边界情况我在context.md里追加了一条约束“输入 CSV 可能包含完全空白的行这些行应该被删除但包含部分空值的行应该保留”。然后手动往测试用例里加了一个新用例def test_partial_null_kept(tmp_path): input_file tmp_path / input.csv output_file tmp_path / output.json input_file.write_text(name,age\nAlice,30\n,\nBob,\n) count clean_data(str(input_file), str(output_file)) assert count 2第二轮循环里AI 根据新约束和新测试报错把代码改成了def clean_data(input_path, output_path): df pd.read_csv(input_path) df df.dropna(howall) df df.drop_duplicates() result df.to_dict(orientrecords) with open(output_path, w) as f: json.dump(result, f) return len(result)dropna(howall)只删除全空行保留部分空值的行。测试通过。4.4 循环收敛的判断与人工介入时机这个例子跑了两轮就收敛了。实际项目中我遇到过跑七八轮还在反复改同一个地方的情况。这时候需要人工介入通常有三种原因一是上下文不足。AI 不知道某个约束反复做出错误假设。解决办法是在context.md里补充说明。二是测试用例本身有问题。测试断言写错了AI 怎么改都过不了。这时候要人工检查测试逻辑。三是任务太复杂。一个循环里塞了太多目标AI 顾此失彼。解决办法是把大任务拆成多个小循环每个循环只解决一个具体问题。注意循环不是跑得越久越好。我一般设置最大轮数为 5超过 5 轮还没收敛就停下来人工检查。继续跑下去大概率是在浪费 token。5. 常见问题排查与避坑指南5.1 循环不收敛的典型原因现象可能原因排查方法每轮修改后测试报错不变提示词里没有包含报错信息检查last_result.txt是否被正确引用AI 反复修改同一个文件但问题依旧上下文缺少关键约束在context.md里补充约束说明测试通过但实际功能不对测试覆盖不足增加边界用例和集成测试循环跑了几轮后 AI 输出格式混乱提示词太长超出上下文窗口精简context.md只保留必要信息每轮修改的文件越来越多任务粒度过大拆分成多个小循环5.2 工具使用中的高频问题Claude Code 找不到命令安装后如果提示command not found检查 npm 全局 bin 目录是否在 PATH 里。用npm config get prefix查看全局目录然后把这个目录下的bin加到 PATH。Codex 登录不上国内网络环境下可能需要配置 API 端点。检查配置文件里的 endpoint 设置确保指向可访问的地址。如果使用兼容 API确认模型名称和参数格式匹配。Cursor 中文设置不生效Cursor 的语言设置需要重启编辑器才能生效。如果设置后界面还是英文尝试CtrlShiftP打开命令面板输入Configure Display Language选择中文后重启。循环脚本权限不足在 Linux 或 macOS 下loop.sh需要执行权限。运行chmod x loop.sh后再执行。5.3 提升循环效率的实操技巧技巧一用 diff 而不是全量输出。让 AI 只输出修改的部分而不是整个文件。这样解析更快token 消耗更少。提示词里加一句“只输出修改的代码片段用 unified diff 格式”。技巧二缓存不变的上下文。如果项目结构没变不需要每轮都重新读取所有文件。把不变的上下文缓存起来只更新变化的部分。技巧三并行验证。语法检查和单元测试可以并行跑节省时间。用把两个命令放到后台然后wait等待结果。技巧四日志分级。循环日志按轮次分文件存储方便回溯。我通常用logs/round_1.log、logs/round_2.log这样的命名。技巧五设置 token 预算。每轮循环消耗的 token 要记录超过预算就停止。这个在 API 计费模式下尤其重要。5.4 什么任务适合放进循环不是所有任务都适合用 Loop Engineering 处理。我的经验是适合的有明确验证标准的任务比如“让测试通过”、“修复 lint 报错”、“把函数返回值类型改对”。这类任务 AI 能通过验证结果判断自己做得对不对。不适合的需要主观判断的任务比如“让代码更优雅”、“优化性能”。这类任务没有明确的验证标准循环容易空转。需要拆分的大型重构任务。一个循环里塞太多目标AI 会迷失。拆成“先改接口”、“再改实现”、“最后改测试”多个小循环。6. 从单循环到多循环的进阶思路单循环跑通之后可以往多循环协作的方向扩展。我目前实践过两种模式串行多循环第一个循环负责生成代码第二个循环负责写测试第三个循环负责跑集成验证。每个循环有独立的上下文和验证标准前一个循环的输出作为后一个循环的输入。这种模式适合从零构建项目的场景。并行多循环多个循环同时处理不同的模块各自独立验证最后合并。这种模式适合大型项目的模块化开发但需要处理好模块间的接口约定否则合并时会冲突。多循环的协调成本比单循环高很多。我的建议是先把单循环跑稳确认验证环节可靠、提示词模板有效、收敛速度可接受再考虑扩展。否则多循环只会放大单循环里已有的问题。实操心得多循环协作时循环之间的“接口”要定义清楚。我通常用一个interface.md文件描述模块间的输入输出约定每个循环的上下文里都引用这个文件。这样即使多个循环并行跑产出的代码也能对得上。最后分享一个我在实际使用中总结的小技巧循环的提示词里加一句“如果你认为当前任务无法通过修改代码解决输出CANNOT_FIX并说明原因”。这样当 AI 遇到死胡同时会主动退出而不是反复做无效修改。这个机制帮我省了不少 token也让我能更快发现是任务定义有问题还是代码本身有坑。