企业官网建设流程全解析

1. 先搞清楚 Loop Engineering 到底在解决什么问题

第一次听到“Loop Engineering”这个词，很多人会以为是某种新的编程语言或者框架。其实不是。它描述的是一类工程实践：让 AI 编程工具（比如 Claude Code、Codex、Cursor 这类）在一个可控的循环里反复执行“生成—验证—修正”的过程，直到产出满足预期为止。核心不在于工具本身，而在于你怎么设计这个循环的边界、退出条件和反馈机制。

我最初接触这个概念是在用 Claude Code 处理一个批量重构任务的时候。当时我让它改一个模块的接口签名，它改完第一遍，编译报错；我手动把报错贴回去，它改第二遍，又引入了新的类型不匹配；第三遍才通过。整个过程我像个传话筒一样在终端和编辑器之间来回切换。后来我意识到，这个“贴报错—等修改—再验证”的动作完全可以自动化，而 Loop Engineering 要解决的正是这个问题：把人的重复劳动从循环里抽出来，只保留关键的判断节点。

所以这篇内容适合三类人看：一是已经在用 Claude Code、Codex、Cursor 但还在手动复制粘贴报错的开发者；二是想把这些工具接入自己工作流、做批量任务处理的工程师；三是单纯好奇“循环工程”到底怎么落地、值不值得投入时间学习的人。我会从最基础的概念拆起，然后给出一套可以直接复现的实战方案，包括环境准备、循环设计、退出条件、常见故障排查。全程用我自己踩过的坑来说明，不堆砌术语。

需要先说明一点：Loop Engineering 不是某个官方产品名称，它更像是一个实践模式的统称。不同团队对它的定义有差异，但共同点都是围绕“自动化反馈循环”做文章。你不需要安装一个叫 Loop Engineering 的软件，而是要用现有的工具组合出一套循环机制。

2. 循环工程的核心构件：反馈信号、退出条件与状态保持

2.1 反馈信号从哪来，决定了循环能不能跑起来

一个循环要能自动运转，最关键的不是 AI 有多聪明，而是“它怎么知道自己做错了”。这就是反馈信号的来源问题。在编程场景里，反馈信号通常有三类：

第一类是静态检查结果，比如编译器的报错、类型检查器的输出、linter 的警告。这类信号最结构化，最容易解析，也最适合作为循环的驱动。比如 TypeScript 的tsc --noEmit输出就是标准的错误列表，你可以直接提取文件路径、行号、错误码。

第二类是测试结果，比如单元测试的通过/失败、集成测试的断言输出。这类信号比编译错误更接近业务正确性，但解析成本更高，因为测试框架的输出格式各不相同。

第三类是运行时行为，比如程序崩溃的堆栈、接口返回的异常状态码、日志里的错误关键字。这类信号最贴近真实问题，但也最不稳定，容易受环境影响。

我自己的做法是优先用第一类信号驱动循环，因为它的确定性最高。第二类作为补充，第三类只在必要时引入。原因很简单：循环每多跑一轮，消耗的是 token 和时间，如果反馈信号本身有噪声，循环就会在无效方向上反复横跳。

2.2 退出条件设计不好，循环就会变成死循环

退出条件是 Loop Engineering 里最容易被忽视、但最容易出事的部分。我见过有人写了个循环让 AI 修 bug，结果 AI 每轮都改一点点，改了二十轮还在改，最后 token 烧完了问题还在。这就是退出条件没设计好。

退出条件至少要包含三层：

• 成功退出：反馈信号显示目标达成，比如编译零错误、测试全绿。这是理想情况。
• 失败退出：达到最大轮次仍未成功，或者连续 N 轮反馈信号没有改善。这时候要停下来，把当前状态交回给人。
• 异常退出：工具本身报错、网络中断、文件被外部修改等。这类情况要有兜底处理，不能让它卡死。

我一般会把最大轮次设在 5 到 8 之间。超过这个数还没收敛，说明要么任务拆得不够细，要么反馈信号有问题，继续跑下去大概率是浪费。连续无改善的判定也很重要：如果第 3 轮和第 2 轮的报错数量一样、错误内容也基本一样，那就该停了。

2.3 状态保持：循环之间要传递什么

循环不是每一轮都从零开始。你需要决定哪些信息在轮次之间传递。最基础的传递内容是上一轮的反馈信号和 AI 的修改记录。更进阶的做法是维护一个“已尝试方案”列表，避免 AI 反复走同一条死路。

我在实际项目里会用两个文件来做状态保持：一个是loop-state.json，记录当前轮次、累计错误数、上次修改的文件列表；另一个是attempts.log，追加每一轮的反馈摘要和 AI 的关键改动。这两个文件不需要多复杂，但能让循环在中断后恢复，也方便事后复盘。

提示：状态文件不要放在会被 AI 修改的目录里，否则可能出现循环自己改自己状态的情况。我一般放在项目根目录下的.loop/文件夹，并在提示词里明确告诉 AI 不要动这个目录。

3. 用 Claude Code 搭一套最小可用的循环：从环境到跑通

3.1 环境准备里最容易忽略的两个细节

Claude Code 的安装本身不复杂，官方文档写得很清楚。但有两个细节是我踩过坑之后才注意到的。

第一个是工作目录的隔离。如果你直接在主项目目录里跑循环，AI 的修改会和你自己的未提交改动混在一起，一旦循环跑飞，回滚很麻烦。我的做法是每次循环前先创建一个独立的工作副本，比如用git worktree或者直接复制一份到临时目录。这样即使循环把代码改乱了，删掉副本就行，主项目不受影响。

第二个是权限配置。Claude Code 默认会询问是否允许执行某些操作，这在交互模式下没问题，但在自动化循环里会卡住。你需要提前配置好允许的操作范围，比如允许读写特定目录、允许执行测试命令。配置的时候要遵循最小权限原则，不要一股脑全放开。

# 创建独立工作副本的示例 git worktree add ../loop-workspace-$(date +%s) HEAD cd ../loop-workspace-*

3.2 循环脚本的骨架：一个可复用的 bash 结构

下面这个脚本是我用了几个项目之后沉淀下来的骨架，你可以直接改成自己的版本。它的逻辑很简单：跑检查、如果有错就把错误喂给 Claude Code、等它改完、再跑检查，直到通过或达到轮次上限。

#!/bin/bash MAX_ROUNDS=6 ROUND=0 STATE_DIR=".loop" mkdir -p "$STATE_DIR" while [ $ROUND -lt $MAX_ROUNDS ]; do ROUND=$((ROUND + 1)) echo "=== Round $ROUND ===" # 跑静态检查，把输出存下来 npx tsc --noEmit > "$STATE_DIR/check-output.txt" 2>&1 ERROR_COUNT=$(grep -c "error TS" "$STATE_DIR/check-output.txt" || true) if [ "$ERROR_COUNT" -eq 0 ]; then echo "Check passed at round $ROUND" break fi echo "Found $ERROR_COUNT errors, feeding to Claude Code" # 把错误和上下文喂给 Claude Code claude --print "以下是 TypeScript 编译错误，请修复。只修改必要的文件，不要重构无关代码。错误输出：$(cat $STATE_DIR/check-output.txt)" \ > "$STATE_DIR/claude-response-$ROUND.txt" 2>&1 # 记录本轮状态 echo "{\"round\": $ROUND, \"errors\": $ERROR_COUNT}" >> "$STATE_DIR/attempts.log" done if [ $ROUND -ge $MAX_ROUNDS ]; then echo "Max rounds reached, manual intervention needed" exit 1 fi

这个骨架有几个设计取舍值得说明。第一，我用--print模式而不是交互模式，因为循环里不需要人工确认。第二，提示词里明确说了“只修改必要的文件”，这是为了防止 AI 顺手重构导致改动范围失控。第三，每轮的响应都单独存文件，方便出问题时回溯。

3.3 提示词怎么写才能让循环收敛

循环能不能收敛，很大程度上取决于你喂给 AI 的提示词。我总结下来有三个要点：

第一，把反馈信号原样给它，不要自己总结。很多人喜欢把报错“翻译”一遍再给 AI，比如“有个类型不匹配的问题”。这样做反而丢失了关键信息。编译器报错里的文件路径、行号、错误码都是 AI 定位问题的重要线索，原样给它效果更好。

第二，明确约束修改范围。如果不加约束，AI 可能会顺手改一堆无关文件，导致下一轮出现新的错误。我通常会在提示词里写清楚“只修改报错涉及的文件”或者“不要改动 public API”。

第三，告诉它上一轮试过什么。如果这是第 3 轮以上，我会把前几轮的修改摘要附上，并说明“以下方案已经尝试过但没有解决，请换一个思路”。这能有效避免 AI 在原地打转。

注意：提示词长度要控制。把整个项目的代码都塞进去既浪费 token 又干扰判断。只给报错相关的文件和必要的上下文就够了。

4. Codex 与 Cursor 在循环里的角色差异

4.1 Codex 更适合做批量生成，不适合做精细修正

Codex 的强项是根据上下文生成代码片段，它在“从零写一个函数”这类任务上表现很好。但在循环修正场景里，它的表现不如 Claude Code。原因是 Codex 对错误反馈的响应粒度比较粗，你给它一段报错，它倾向于重写整个函数而不是做最小修改。这在循环里是个问题，因为每轮改动越大，引入新错误的风险越高。

我的做法是把 Codex 用在循环的“生成阶段”而不是“修正阶段”。比如循环的第一轮，让 Codex 根据接口定义生成初始实现，后续轮次交给 Claude Code 做修正。这样分工之后，整体收敛速度明显提升。

4.2 Cursor 的编辑器集成在循环里的独特价值

Cursor 和前面两个工具的区别在于它是编辑器原生的。这意味着它能直接利用编辑器里的诊断信息（比如波浪线报错），不需要你手动跑命令再解析输出。在 Loop Engineering 的语境下，这带来一个便利：你可以用 Cursor 的 diagnostic API 直接拿到结构化的错误列表，省掉解析文本的步骤。

但 Cursor 的自动化能力相对弱一些，它更偏向交互式使用。如果你想做全自动循环，Cursor 不是首选。我的用法是：循环跑完之后，用 Cursor 打开结果做人工审查，利用它的 diff 视图快速确认改动是否合理。它在这个环节的体验是最好的。

4.3 三个工具在循环不同阶段的配合方式

把这三个工具串起来，我目前的工作流是这样的：

这个分工不是固定的，你可以根据自己手头的工具和任务类型调整。关键是要理解每个工具在循环里的定位，不要指望一个工具包打天下。

5. 循环跑不起来时的排查链路

5.1 从“AI 没反应”到“AI 改错文件”的逐层定位

循环出问题的时候，症状往往很模糊，比如“跑了几轮没效果”。这时候需要一套系统的排查方法。我一般按下面的顺序逐层检查：

第一层：反馈信号是否正常。先手动跑一遍检查命令，确认它确实能输出错误。有时候是检查命令本身配置错了，导致循环以为没有错误，直接退出了。

第二层：AI 是否收到了正确的输入。查看claude-response-*.txt文件，确认 AI 的响应里有没有针对报错内容做修改。如果响应是空的或者答非所问，说明提示词有问题。

第三层：AI 的修改是否落到了文件上。有时候 AI 在响应里说了要改什么，但实际没有执行写文件操作。这通常是权限配置的问题，检查一下工作目录是否在允许范围内。

第四层：修改是否引入了新错误。对比每轮的check-output.txt，如果错误数量在增加，说明 AI 的修改方向有问题，需要调整提示词里的约束条件。

这个排查链路看起来简单，但实际用的时候能省很多时间。我见过有人循环跑不通就直接怀疑工具不行，其实大部分问题都出在反馈信号或提示词上。

5.2 几个高频故障的具体表现和修法

故障一：循环第一轮就退出，提示“check passed”。这通常是因为检查命令的退出码被错误处理了。比如grep -c在没匹配到内容时返回 1，如果脚本里用了set -e，就会直接退出。修法是在 grep 后面加|| true。

故障二：AI 每轮都改同一个文件，但错误不变。这是典型的“原地打转”。原因是提示词里没有告诉它上一轮试过什么。修法是在提示词里附上历史尝试记录，并明确要求换思路。

故障三：循环跑到一半卡住不动。可能是 AI 在等待人工确认。检查一下是否用了交互模式，或者权限配置里有没有需要确认的操作。改成--print模式并提前配好权限。

故障四：修改后的代码能编译但测试挂了。说明循环的反馈信号只覆盖了编译检查，没有覆盖测试。修法是把测试命令也加入检查环节，让反馈信号更完整。

5.3 怎么判断该继续循环还是该人工介入

这个问题没有绝对标准，但有几个信号可以参考：

• 如果连续两轮的错误数量没有下降，继续跑大概率是浪费。
• 如果错误类型从“类型不匹配”变成了“找不到模块”，说明修改引入了新问题，需要人工看一下。
• 如果 AI 的响应开始变得很短、很敷衍，可能是上下文太长了，需要清理状态重新开始。

我自己的习惯是设一个“三轮无改善就停”的规则。停下来之后不急着改代码，先看attempts.log，搞清楚卡在哪，再决定是调整提示词还是手动改。

6. 把循环工程用在实际项目里的几点经验

6.1 任务拆解粒度比循环本身更重要

我一开始做循环工程的时候，总想着让一个循环解决一个大任务，比如“把这个模块从 JavaScript 迁移到 TypeScript”。结果循环跑了十几轮都没收敛。后来我把任务拆成更小的单元：先迁移类型定义，再迁移工具函数，最后迁移业务逻辑。每个单元单独跑循环，基本都在三轮内完成。

这个经验的核心是：循环适合解决边界清晰的小问题，不适合解决模糊的大问题。你在设计循环之前，先问自己“这个任务的完成标准能不能用一条命令验证”。如果不能，就继续拆。

6.2 日志和状态文件要当成一等公民来对待

很多人做自动化的时候不重视日志，觉得跑通了就行。但在循环场景里，日志是你唯一的调试依据。我现在的做法是每轮都记录：轮次编号、错误数量、AI 修改的文件列表、耗时。这些信息在事后复盘时非常有用，能帮你判断循环的效率瓶颈在哪。

状态文件还有一个作用是支持断点续跑。如果循环跑到第 4 轮因为网络问题中断了，你可以从状态文件里恢复，不用从头再来。这在处理大项目的时候能省不少时间。

6.3 不要追求全自动，保留人工检查点

Loop Engineering 的目标是减少重复劳动，不是完全取代人。我见过有人追求“一键全自动”，结果循环把代码改得面目全非，回滚都困难。我的做法是在循环的关键节点保留人工检查：比如第一轮修改之后看一眼 diff，确认方向对了再让它继续跑。

这个检查点不需要很频繁，但要有。它能在循环跑偏的早期就发现问题，避免浪费更多轮次。从投入产出比来看，花三十秒看一眼 diff，比跑五轮无效循环再回滚要划算得多。

6.4 循环工程的边界：哪些任务不适合

不是所有任务都适合用循环来做。根据我的经验，以下几类任务不适合：

• 需要外部环境交互的任务，比如调试一个只在特定网络环境下出现的 bug。循环里的反馈信号不稳定，容易误判。
• 涉及主观判断的任务，比如 UI 设计调整。什么叫“好看”没法用命令验证，循环没有明确的退出条件。
• 改动范围不可控的任务，比如“优化整个项目的性能”。这类任务没有清晰的完成标准，循环容易失控。

适合循环的任务通常有这些特征：完成标准可自动化验证、改动范围可约束、反馈信号稳定。你在决定用循环之前，先对照这几条检查一下。

7. 关于循环工程的一些个人体会

用了几个月 Loop Engineering 之后，我最大的感受是：它的价值不在于让 AI 多干活，而在于逼你把任务定义清楚。一个循环能跑起来，前提是你能说清楚“什么叫做完了”和“怎么知道做错了”。这两个问题想明白了，即使不用 AI，你的工作流也会变得更清晰。

另一个体会是，工具的选择没有想象中那么重要。Claude Code、Codex、Cursor 各有各的强项，但循环的骨架是通用的。你把反馈信号、退出条件、状态保持这三件事设计好，换哪个工具都能跑。反过来，如果这三件事没设计好，用再贵的工具也是白搭。

最后分享一个我最近在用的技巧：在循环的提示词里加一句“如果你认为当前错误无法通过修改代码解决，请直接说明原因并停止”。这句话能有效避免 AI 在死路上硬撑，把问题交回给人来判断。实测下来，它让循环的无效轮次减少了大概三分之一。