企业官网建设流程全解析

1. 从“写提示词”到“搭回路”：Loop Engineering 到底在解决什么问题

如果你最近半年一直在用 Claude Code、Codex、Cursor 这类 AI 编程工具，大概率经历过这样一个阶段：一开始觉得“哇，一句话就能生成一个函数”，用着用着却发现，真正拖慢效率的不是模型不够聪明，而是你每次都要重新解释一遍上下文、重新纠正一遍它跑偏的方向、重新检查一遍它有没有偷偷改坏别的文件。单次对话的质量再高，也架不住一天几十次的重复劳动。

Loop Engineering（回路工程）要解决的，就是这个“重复劳动”的问题。它不是一个具体的工具，也不是某个官方术语，而是这两年在一线 AI 编程实践里逐渐沉淀出来的一套方法论：把 AI 编程工具从“一次性问答”改造成“可循环、可自检、可收敛”的工作回路。你可以把它理解成给 AI 装了一条流水线——输入需求、执行、验证、反馈、修正，然后自动进入下一轮，直到结果达标或者触发人工介入。

这套东西为什么现在突然被反复提起？因为 Claude Code、Codex、Cursor 这些工具的能力边界已经变了。早期的 AI 补全只能做“行内建议”，现在的 Agent 模式可以自己读文件、跑命令、改代码、看报错、再改。能力越强，越需要一套“约束 + 反馈”的机制，否则它跑得越快，翻车越狠。Loop Engineering 的核心，就是设计这套机制。

这篇文章适合三类人看：第一类是把 Claude Code 或 Codex 当日常主力、但总觉得“用得不顺手”的开发者；第二类是刚开始接触 Agent 编程、想少走弯路的入门者；第三类是团队里负责搭工具链、想让多人协作时 AI 输出更稳定的人。我会从回路的基本结构讲起，然后落到 Claude Code、Codex、Cursor 三个工具的具体配置和实战，最后讲几个我踩过的坑和收敛技巧。全程不吹概念，只讲能直接抄作业的东西。

2. 一条完整回路的四个环节：感知、执行、验证、收敛

2.1 为什么“单次对话”注定不稳定

先想清楚一个事：为什么你直接跟 AI 说“帮我重构这个模块”，结果往往不理想？因为单次对话里，AI 拿到的信息是静态的——你给的那段代码、你写的那句话。它不知道这个模块被谁调用、不知道项目的测试怎么跑、不知道改完之后会不会破坏别的功能。它只能基于“当前看到的”做最合理的猜测，而猜测在复杂项目里几乎必然出错。

Loop Engineering 的第一个洞察就是：把“一次性给足信息”换成“让 AI 自己分步获取信息”。不是你在提示词里塞一大堆上下文，而是让 AI 在回路里主动去读文件、跑测试、看日志。这就像你带新人，你不会一次性把所有背景讲完，而是告诉他“你先去看 README，然后跑一下测试，遇到问题再来问我”。回路的价值，在于让 AI 有了“自己去看、自己去试”的机会。

2.2 感知环节：让 AI 拿到“活的上下文”

感知环节要解决的是“AI 现在知道什么”。在 Claude Code 里，这一步靠的是它自动读取项目文件的能力；在 Codex 里，靠的是你把相关文件显式加入上下文；在 Cursor 里，靠的是 @ 引用和代码库索引。但光有工具能力不够，你得设计“它该感知什么”。

我的做法是给项目根目录放一个AGENTS.md或者CLAUDE.md，里面写清楚三件事：项目结构（哪些目录是核心、哪些是生成物）、常用命令（怎么跑测试、怎么起本地服务）、以及硬性约束（比如“不要改 migrations 目录”“所有新代码必须有类型标注”）。这个文件就是 AI 的“入职手册”，每次回路启动它都会先读一遍。实测下来，光这一步就能把跑偏率降低一半以上。

2.3 执行与验证：让“跑一遍”成为默认动作

执行环节的关键不是“让 AI 写代码”，而是“让 AI 写完必须自己验证”。很多人用 Claude Code 只让它写，不让它跑，结果就是 AI 自信满满地交出一堆编译不过的代码。正确的回路设计是：写完 → 跑测试 → 看报错 → 自己修 → 再跑，直到通过。

在 Claude Code 里，你可以在提示词里明确要求“修改完成后运行npm test，如果有失败项，自行分析并修复，最多迭代三轮”。在 Codex 里，可以配置它执行命令的权限，让它能跑测试但不能碰生产配置。在 Cursor 里，Agent 模式本身就支持终端执行，你要做的是在.cursorrules里写清楚“验证优先”的原则。验证环节是回路的“刹车”，没有它，AI 跑得越快越危险。

2.4 收敛：什么时候该停，什么时候该叫人

收敛是 Loop Engineering 里最容易被忽略、但最重要的一环。回路不能无限循环，你得定义“什么算完成”。常见的收敛条件有三类：测试全绿、lint 无报错、以及人工确认关键逻辑。前两个可以自动判断，第三个必须留给人。

我一般会在提示词里写死：“如果连续两轮修复后测试仍失败，停止修改，输出当前状态和你的判断，等待人工介入。”这条规则救过我很多次——有几次 AI 陷入“改了 A 坏了 B、改了 B 坏了 A”的死循环，如果没有这个刹车，它能自己折腾半小时。收敛条件就是回路的“退出机制”，设计回路时第一件事就该想清楚它。

3. Claude Code 里的回路搭建：从 CLAUDE.md 到自动迭代

3.1 CLAUDE.md 怎么写才真正起作用

Claude Code 启动时会自动读取项目根目录的CLAUDE.md，这是它感知项目的主要入口。但很多人写的CLAUDE.md要么太笼统（“这是一个 React 项目”），要么太啰嗦（把整个架构文档贴进去）。我的经验是：只写 AI 会反复用到、且容易搞错的信息。

具体来说，我会分四块写。第一块是“项目速览”，三句话讲清楚这是什么、用什么技术栈、核心目录在哪。第二块是“命令清单”，把dev、test、lint、build的真实命令列出来，注意要写实际能跑通的，别写文档里的理想命令。第三块是“硬约束”，比如“不要修改src/generated/下的文件”“所有 API 调用必须走src/api/client.ts”。第四块是“常见陷阱”，比如“测试环境需要先跑docker compose up -d db”。

这里有个细节：CLAUDE.md不要写太长，控制在 100 行以内。太长了 AI 反而抓不住重点，而且每次回路启动都要读一遍，浪费上下文窗口。我见过有人写了 500 行的CLAUDE.md，结果 AI 该错还是错，因为关键约束被淹没在废话里了。

3.2 用“任务清单”驱动多轮迭代

Claude Code 有个很好用的模式：让它先输出一个任务清单，然后逐项执行。这其实就是把一个大回路拆成多个小回路。比如你说“帮我把用户模块从 JavaScript 迁移到 TypeScript”，它可能会输出：1）安装类型依赖；2）重命名文件；3）逐个添加类型；4）修复类型错误；5）跑测试。

这个清单的价值在于：它把“隐式的计划”变成了“显式的契约”。你可以先审一遍清单，觉得不对就让它改，改完再执行。执行过程中，每完成一项它都会标记，你随时能看到进度。如果某一项卡住了，你可以针对性地给提示，而不是让它从头再来。

我实测下来，这种“清单驱动”的方式比直接让它干活稳定得多。因为 AI 在多轮迭代里容易“忘记”最初的目标，而清单是一个持续存在的锚点。你甚至可以在CLAUDE.md里写一条规则：“处理复杂任务时，先输出任务清单并等待确认。”

3.3 让 Claude Code 自己跑测试并修复

这是回路工程里最爽的一环。Claude Code 支持执行终端命令，你可以直接让它“修改后运行测试，失败就自己修”。但要注意几个坑。

第一个坑是权限。默认情况下 Claude Code 执行命令会问你，如果你在回路里频繁跑测试，每次都要确认会很烦。可以在配置里把常用的测试命令加入白名单，但千万别把rm、git push这类危险命令加进去。我一般只白名单npm test、pytest、go test这类只读或幂等的命令。

第二个坑是输出太长。测试失败时输出可能几百行，AI 读起来费劲还容易抓错重点。我的做法是在命令里加过滤，比如npm test 2>&1 | tail -50，只让它看最后 50 行。或者用--reporter=dot这类精简输出。让 AI 看关键信息，比让它看全部信息更有效。

第三个坑是死循环。前面提过，一定要设迭代上限。我一般写“最多修复三轮，三轮后仍失败就停下来报告”。这个数字不是拍脑袋的，实测三轮覆盖了绝大多数常见错误，超过三轮基本就是设计问题，需要人来判断了。

3.4 一个真实的迁移任务回路拆解

举个我上周刚做的例子：把一个 Express 项目的路由层从回调风格改成 async/await。我的回路是这样设计的。

第一步，感知：让 Claude Code 先读routes/目录下所有文件，输出一个清单，列出每个文件用了多少回调、有没有嵌套。第二步，执行：让它逐个文件改，每改完一个就跑该文件对应的测试。第三步，验证：全部改完后跑一次全量测试，看有没有回归。第四步，收敛：如果有测试失败，让它分析是改错了还是测试本身要更新，改错就修，测试要更新就说明理由后更新。

整个过程我基本没怎么干预，只在它报告“某个测试失败但不确定是代码问题还是测试问题”时介入了一次。最后统计下来，12 个文件、约 40 处回调，总共花了不到 20 分钟，比我手动改快了好几倍，而且没引入回归。这就是回路工程的价值——不是 AI 多聪明，而是流程设计得好。

4. Codex 的回路配置：配置文件、模型选择与国内可用性

4.1 Codex 配置文件到底该改哪几项

Codex 的配置比 Claude Code 稍微复杂一点，因为它有 CLI 和 IDE 插件两种形态，配置文件位置也不一样。CLI 版一般在~/.codex/config或者项目级的.codex/目录下。我重点讲几个真正影响回路效果的配置项。

第一个是模型选择。Codex 支持切换不同的底层模型，不同模型在“指令遵循”和“代码质量”上差异明显。做回路的时候，我倾向于选指令遵循强的模型，因为回路依赖它严格执行“先测试再提交”这类规则。具体选哪个要看你的账号权限和实际测试，建议拿同一个任务在几个模型上各跑一遍，对比谁更听话。

第二个是审批模式。Codex 有“建议模式”和“自动模式”，回路场景下建议用自动模式，但要把危险操作排除。配置里可以设置哪些命令需要人工确认，哪些直接执行。我的原则是：读操作全自动，写操作（改文件）自动，但涉及网络请求、删除、推送的操作必须确认。

第三个是上下文管理。Codex 不会自动读取所有文件，你得告诉它哪些文件相关。可以在配置里设置默认包含的目录，比如src/、tests/，排除node_modules/、dist/。这个设置直接决定了回路里 AI 的“视野”，设窄了它看不到关键文件，设宽了它被噪音干扰。

4.2 国内使用 Codex 的现实问题与绕行思路

热词里有一堆“codex国内能用吗”“codex登录不上”“codex无法加载组织设置”，说明这是很多人的真实痛点。我不谈网络层面的东西，只讲工程上怎么让回路在受限环境下依然能跑。

核心思路是：把对在线服务的依赖降到最低，把回路的关键环节本地化。比如验证环节，测试和 lint 完全可以在本地跑，不依赖任何在线服务。感知环节，项目结构和约束可以写在本地配置文件里。真正需要在线能力的只有“生成”这一步。

具体做法是：把回路设计成“生成靠在线、验证靠本地、收敛靠规则”。这样即使在线部分不稳定，你的回路也不会完全瘫痪。另外，配置文件尽量用项目级而不是全局级，这样换环境时不用重新配。我见过有人把所有配置放在全局，结果换台机器就全乱了。

还有一个实用技巧：把常用的提示词模板存成文件，比如prompts/refactor.md、prompts/fix-test.md，用的时候直接引用。这样既省得每次重写，也方便团队共享。Codex 支持从文件读取提示词，这个功能在搭回路时特别有用。

4.3 用 Codex 做“批量小任务”的回路设计

Codex 特别适合做那种“重复性高、单个任务简单”的活，比如给一批函数加类型标注、给一批接口加错误处理、把一批console.log换成正式日志。这类任务的回路设计和 Claude Code 不太一样。

我的做法是：先让 Codex 扫描出所有需要改的位置，生成一个清单文件（比如todo.md）。然后写一个循环脚本，每次读清单里的一项，让 Codex 处理，处理完跑测试，通过就标记完成，不通过就记录问题。这个脚本可以用 shell 写，也可以用 Python 写，核心就是“读一项、做一项、验一项、记一项”。

这个模式的好处是：单个任务的失败不会影响整体。如果某一项 Codex 反复搞不定，脚本会跳过它继续下一项，最后你只需要人工处理那几个“钉子户”。我实测下来，100 个这样的小任务，通常 90 个能自动过，剩下 10 个人工处理，总时间比全手动省 70% 以上。

4.4 Codex 配置文件的常见报错与排查

热词里“codex配置文件解析”出现频率很高，说明很多人卡在配置这一步。我总结几个最常见的报错和排查思路。

报错一：配置不生效。先确认你改的是正确层级的配置文件——项目级会覆盖全局级，如果你在项目里改了但没生效，可能是全局配置里有冲突项。排查方法是把全局配置临时清空，只留项目配置，看是否生效。

报错二：命令执行被拒。这通常是审批模式设得太严，或者命令不在白名单里。检查配置里的approval相关字段，确认你要跑的命令在允许列表内。注意有些配置项是“允许列表”和“拒绝列表”并存的，拒绝优先级更高。

报错三：上下文里文件太多导致响应慢。这是配置里默认包含目录设太宽了。把node_modules、.git、dist、build这些排除掉，只留源码和测试目录。如果项目很大，还可以按模块拆分，每次只让 Codex 看当前模块。

排查配置问题的通用思路是：从最小可用配置开始，逐项加，加到出问题为止。别一上来就抄一份复杂配置，出了问题你根本不知道是哪一项导致的。

5. Cursor 的回路实践：中文设置、规则文件与 Agent 模式

5.1 Cursor 中文回复设置的正确姿势

热词里“cursor设置中文回复”“cursor中文怎么设置”“cursor怎么设置成中文”反复出现，说明这是刚上手的人最关心的问题。我直接说结论：Cursor 的界面语言和 AI 回复语言是两回事，要分开设置。

界面语言在设置里找Display Language，选中文即可，这个只影响菜单和按钮。AI 回复语言要在规则文件里控制，也就是.cursorrules或者项目级的规则配置。你可以在规则里写一句“所有回复使用简体中文”，这样 AI 就会用中文跟你交流。但要注意，代码注释和变量名建议还是用英文，否则团队协作时会有麻烦。

还有一个细节：如果你在.cursorrules里写了中文回复，但 AI 还是偶尔蹦英文，通常是因为你的提问本身是英文，或者上下文里有大量英文代码。解决办法是在规则里写得更强硬一点，比如“无论输入语言是什么，回复一律使用简体中文”。实测这样基本能稳定。

5.2 .cursorrules 里该写什么才能撑起一条回路

.cursorrules是 Cursor 的“项目宪法”，它决定了 AI 在这个项目里的行为方式。搭回路的话，我建议至少写这几块。

第一块是“角色与目标”，告诉 AI 它在这个项目里扮演什么角色，比如“你是一个熟悉 React + TypeScript 的前端工程师，目标是保持代码风格一致、测试覆盖率不下降”。第二块是“技术约束”，列出技术栈版本、必须用的库、禁止用的库。第三块是“工作流程”，这是回路的核心，写清楚“修改代码前先读相关文件”“修改后必须跑测试”“测试失败先分析再修”。

第四块是“输出规范”，比如“解释用中文、代码用英文注释”“不要输出大段无关代码”“修改点用列表列出”。第五块是“禁止事项”，比如“不要改配置文件”“不要动 migrations”“不要引入新依赖除非明确要求”。这五块写下来大概 50 到 80 行，足够撑起一条稳定的回路。

有个坑要注意：.cursorrules不是越长越好。我试过写 200 行，结果 AI 反而抓不住重点，该遵守的没遵守。后来精简到 60 行，效果反而更好。规则要“少而硬”，每条都是真正会触发的约束，别写一堆永远不会用到的条款。

5.3 Agent 模式下的回路：让 Cursor 自己读、自己改、自己验

Cursor 的 Agent 模式（也叫 Composer）是搭回路的主力。它支持多文件编辑、终端执行、以及基于报错的自动修复。用好的关键，在于你怎么“起手”。

我的习惯是：先给一个明确的目标，然后让它自己规划步骤。比如“把utils/下的日期处理函数统一成 dayjs，先列出涉及的文件和函数，再逐个改，每改完一个跑相关测试”。这样它会先输出一个计划，你确认后再执行。执行过程中它会自己读文件、改代码、跑测试，遇到失败会尝试修复。

这里有个提效技巧：把常用的验证命令做成 npm script，比如npm run verify同时跑 lint 和 test。然后在提示词里直接说“改完跑npm run verify”。这样比让它自己拼命令更稳，也更快。我还会在.cursorrules里写“验证命令统一用npm run verify”，避免它每次用不同的命令。

另一个技巧是善用@引用。Cursor 里可以用@file、@folder、@codebase来指定上下文。搭回路时，我一般会@上相关的测试文件，这样 AI 改代码时能直接看到测试期望，减少“改完才发现测试挂了”的情况。这个动作很小，但效果很明显。

5.4 Cursor 免费额度与回路成本控制

热词里“cursor免费额度是多少”“cursor grok额度”说明大家很关心成本。我不给具体数字（因为政策会变），只讲怎么在回路里控制消耗。

核心原则是：把贵的操作留给关键环节，把便宜的操作放在循环里。比如“生成代码”是贵的，“跑测试”是便宜的。所以回路设计上，尽量让 AI 少生成、多验证。具体做法是：提示词写清楚，让它一次改到位，而不是反复小改。反复小改会消耗大量额度，而且容易越改越乱。

另一个做法是：把大任务拆成小任务，每个小任务单独开一个会话。Cursor 的上下文是累积的，会话越长消耗越大。做完一个任务就开新会话，能有效控制成本。我一般一个任务控制在 10 轮对话以内，超过就说明任务拆得不够细。

还有个小技巧：用 Cursor 的“应用”功能而不是“重新生成”。当 AI 给出修改建议时，点“应用”直接改文件，比让它重新生成一遍省额度。这个操作很多人不知道，其实能省不少。

6. 回路跑不通时的排查链路：从现象到根因

6.1 现象一：AI 反复改同一个地方却改不对

这是最常见的回路故障。表现是 AI 改了 A，测试挂了，它改回 A，测试又挂，来回折腾。根因通常有三个：一是它没理解测试在测什么，二是它没看到某个关键文件，三是任务本身有歧义。

排查顺序是：先看它有没有读测试文件。如果没读，就在提示词里明确@上测试文件。再看它有没有读被调用方。很多时候它只改了函数本身，没改调用方，导致类型不匹配。最后看任务描述是不是有歧义，比如“优化这个函数”就很模糊，改成“把这个函数的时间复杂度从 O(n²) 降到 O(n)”就明确多了。

我的经验是：80% 的“改不对”都是上下文不足导致的，而不是 AI 能力问题。补上下文比换模型有效得多。

6.2 现象二：测试通过但功能实际是坏的

这个更危险，因为回路会“假收敛”。表现是测试全绿，但手动一跑发现功能不对。根因通常是测试覆盖不足，或者 AI 改了测试来“迎合”代码。

排查方法是：检查 AI 有没有修改测试文件。如果它改了测试，一定要人工审一遍，看是合理的更新还是“作弊”。我一般会在规则里写“除非明确要求，不要修改测试文件”，从源头堵住这个问题。另外，关键功能要有集成测试或端到端测试，光靠单元测试容易被绕过。

还有个做法是：在回路最后加一步“人工抽检”。让 AI 输出它改了哪些文件、每个文件改了什么、为什么这么改。你花两分钟扫一遍，能发现很多自动验证发现不了的问题。

6.3 现象三：回路跑着跑着上下文爆了

长回路跑到后面，AI 开始“忘事”，之前说过的约束不遵守了，或者重复问已经回答过的问题。这是上下文窗口满了。排查方法是看会话长度，如果超过几十轮，基本就是这个问题。

解决办法有两个：一是拆任务，把长回路拆成几个短回路，每个短回路独立开会话。二是做“上下文压缩”，让 AI 在关键节点输出一个摘要，然后开新会话时把摘要带进去。我一般用第一种，因为更简单可靠。

还有个预防措施：在回路设计时就控制单次任务的范围。一个回路只做一件事，做完就收。别想着一个回路解决所有问题，那样必然爆上下文。

6.4 现象四：命令执行卡住或超时

回路里跑测试或构建时，偶尔会卡住。原因可能是命令在等输入、在下载依赖、或者真的死循环了。排查方法是先看命令本身在终端里跑要多久，如果终端里很快但 AI 跑就卡，那可能是权限或环境问题。

预防措施是给命令加超时，比如timeout 300 npm test。另外，把需要交互的命令改成非交互模式，比如npm install --yes。还有，确保 AI 执行命令的工作目录是对的，有时候它会在错误的目录跑命令，导致找不到文件。

我踩过最坑的一次是 AI 跑npm test时卡在 watch 模式，因为项目配置里 test 默认是 watch。后来我在规则里写死“测试命令用npm test -- --watch=false”，问题就解决了。这种坑不踩一次根本想不到，所以规则文件要持续迭代，遇到一次坑就补一条规则。

7. 让回路真正收敛的几个实战心得

7.1 收敛条件要“可判定”，不能靠感觉

“改好了”这种描述没法自动判定。收敛条件必须是机器能判断的，比如“测试全绿”“lint 零报错”“构建成功”。如果某个目标没法自动判定，就把它拆成可判定的子目标。比如“代码质量提升”没法判定，但“圈复杂度低于 10”“没有 any 类型”可以判定。

我一般会在回路开始时就把收敛条件写清楚，让 AI 知道“做到什么程度算完”。这样它不会无限优化，也不会过早停止。收敛条件写得好，回路效率能提升一大截。

7.2 给回路设“预算”，防止无限消耗

除了迭代次数上限，还要设时间预算和 token 预算。比如“这个任务最多跑 15 分钟”“最多消耗 5 万 token”。超了就停下来报告，让人来判断。这个预算不是限制 AI，而是保护你的钱包和时间。

实测下来，大部分任务在预算内都能完成，超预算的往往是任务本身有问题，需要重新拆解。所以超预算不是坏事，它是一个信号，告诉你“这个任务需要人工介入了”。

7.3 规则文件要“活”，持续迭代

.cursorrules、CLAUDE.md这些文件不是写一次就完事的。每次回路出问题，都应该问一句“是不是规则没写清楚”，如果是，就补一条。我现在的规则文件是迭代了十几版的结果，每一条背后都是一次踩坑。

迭代的时候注意别把规则写矛盾了。比如一条说“优先用函数式”，另一条说“复杂逻辑用类”，AI 就懵了。规则之间要一致，有冲突就合并或删掉一条。定期 review 规则文件，把过时的删掉，把新踩的坑补上。

7.4 人工介入点要“前置”，别等崩了才管

回路不是全自动就好。好的回路设计，是在关键节点主动停下来让人确认，而不是等它跑崩了才介入。比如“修改数据库 schema 前必须确认”“引入新依赖前必须确认”“删除文件前必须确认”。这些点前置了，能避免大部分严重问题。

我的做法是在规则里列一个“必须确认清单”，AI 遇到清单里的操作就停下来问。这个清单不用长，五到十条就够，覆盖那些“一旦错了很难回滚”的操作。剩下的常规操作让它自动跑，效率和质量就平衡了。

7.5 团队协作时，回路要“可共享”

一个人用回路和团队用回路是两回事。团队用的话，规则文件、提示词模板、验证脚本都要进版本控制，让每个人拿到的是同一套。新人入职，clone 下来就能用，不用重新配。

另外，团队里要有人负责维护这套回路。规则文件会随着项目演进过时，验证脚本会随着依赖升级失效，需要定期更新。我一般建议每个 sprint 花半小时 review 一次回路配置，把这段时间踩的坑补进去。这个投入很小，但回报很大。

8. 回路工程的边界：哪些事不该交给回路

8.1 架构决策别交给回路

回路擅长的是“在既定框架内执行”，不擅长“决定框架本身”。比如“这个模块该不该拆”“该用哪种状态管理”“数据库该怎么设计”，这些决策需要人来拍板。你可以让 AI 提供选项和分析，但最终决定必须是人做的。

我见过有人让 AI 自己决定架构，结果它选了一个当时看起来合理、但和项目长期方向冲突的方案，后面返工成本极高。架构决策的代价是“不可逆”的，而回路的价值在于“可迭代”，两者不匹配。

8.2 涉及安全和合规的改动别全自动

任何涉及权限、加密、用户数据、支付逻辑的改动，都不应该让回路全自动完成。这些地方的错误代价太高，必须有人工 review。回路可以做“生成候选方案”这一步，但“应用方案”必须人工确认。

我的做法是在规则里明确列出“敏感目录”，AI 对这些目录只能读不能写，要改就输出建议，由人来改。这样既利用了 AI 的分析能力，又守住了安全底线。

8.3 探索性任务别硬套回路

回路适合“目标明确、可验证”的任务。如果任务本身还在探索阶段，比如“试试看能不能用某个新库”“调研一下这个方案的可行性”，硬套回路反而低效。这种任务更适合开放式对话，让 AI 帮你快速试错，而不是设计一套收敛机制。

判断标准很简单：你能不能写出明确的收敛条件。能写，就用回路；写不出，就用对话。别为了用回路而用回路。

9. 我踩过的三个真实坑和对应的解法

9.1 坑一：规则文件写太满，AI 反而“看不见”关键约束

早期我在.cursorrules里写了将近 200 行，把能想到的约束全写进去了。结果 AI 经常违反其中最重要的几条，比如“不要改测试文件”。后来我做了个实验，把规则精简到 60 行，只留最关键的，违反率反而下降了。

原因是 AI 的注意力是有限的，规则太多它会“平均分配”，导致每条都不够重视。精简之后，剩下的每条都是高频触发的，AI 反而记得牢。所以规则文件的原则是：宁可少写，不可写满。只写那些“不写就会出错”的规则。

9.2 坑二：验证命令不统一，导致回路结果不可复现

有段时间我让 AI 自己决定跑什么命令验证，结果它有时跑npm test，有时跑jest，有时跑npm run test:unit。不同命令覆盖的范围不一样，导致有时候“通过”了但实际有问题。后来我统一成npm run verify，把所有验证都收口到一个命令，问题就没了。

这个坑的教训是：回路里的每个动作都应该是确定的。命令、路径、参数，能固定就固定。不确定性越多，回路越不可靠。现在我的规则里会明确写“验证统一用npm run verify，不要用其他命令”。

9.3 坑三：没设迭代上限，AI 陷入“改 A 坏 B”的死循环

有一次让 AI 修一个类型错误，它改了 A 文件，导致 B 文件报错，改 B 又导致 A 报错，来回折腾了十几轮，消耗了大量额度还没解决。后来我加了“最多三轮”的限制，三轮后停下来报告，我一看就发现是类型定义本身有问题，手动改一行就解决了。

这个坑让我明白：回路必须有“退出机制”。没有退出机制的回路，遇到死循环就是灾难。现在我的所有回路都设了迭代上限，而且上限设得比较保守，宁可多介入几次，也不让它空转。

10. 回路工程的下一步：从个人技巧到团队基建

回路工程现在还是个“个人技巧”居多，每个人有自己的规则文件、自己的提示词模板、自己的验证脚本。但我观察到，它正在往“团队基建”的方向走。一些团队开始把回路配置当成项目的一部分来维护，有专门的目录、有 review 流程、有版本管理。

这个趋势是必然的。因为 AI 编程工具的能力还在快速提升，单次生成的质量会越来越高，但“如何组织多轮生成、如何验证、如何收敛”这些问题不会自动消失。反而因为工具更强了，回路的杠杆效应更大——一个好的回路能让强工具发挥出十倍价值，一个坏的回路能让强工具变成灾难。

如果你现在还在“每次手动写提示词”的阶段，我建议从最小回路开始：先写一个CLAUDE.md或.cursorrules，把项目结构和验证命令写清楚。然后找一个重复性高的任务，设计一条简单的回路，跑通它。跑通之后，再逐步加规则、加验证、加收敛条件。别一上来就搞复杂回路，那样容易挫败。

回路工程的核心不是工具，是思维。它要求你把“跟 AI 对话”这件事，从“一次性交互”重新理解成“一个可设计、可优化、可复用的系统”。这个思维转变一旦完成，你会发现不只是 AI 编程，很多和 AI 协作的场景都能用同样的思路去优化。这大概是我做这件事最大的收获。