企业官网建设流程全解析

1. 从“会用工具”到“会造工具”：Loop Engineering 到底在解决什么问题

这两年 AI 编程工具迭代得飞快，Claude Code、Codex、Cursor 轮番上阵，很多人已经习惯了在终端里敲一句自然语言，让模型帮忙改代码、跑测试、提交 PR。但用久了你会发现一个很尴尬的现象：单次对话再强，它也只是一个“高级补全”。你让它改一个函数，它改得漂漂亮亮；你让它独立完成一个跨文件、跨模块、需要反复验证的中型任务，它就开始飘——上下文丢失、步骤跳跃、改完不测、测完不复盘。

Loop Engineering（循环工程）要解决的，正是这个断层。它不是某个具体工具，而是一套把 AI 编程助手从“单次问答”升级成“可循环、可验证、可收敛的自动化工作流”的工程方法论。你可以把它理解成：给 AI 装上一个“感知—决策—执行—验证—修正”的闭环，让它像一名真正的工程师那样，反复迭代直到任务达标，而不是交完差就撒手不管。

这套东西适合谁？三类人最该认真看。第一类是已经在用 Claude Code、Codex、Cursor 但只会“一问一答”的开发者，你的效率其实只发挥了工具的三成；第二类是想把 AI 编程接入自己项目流水线的团队技术负责人，你需要的是可复现的循环结构，而不是某个人的手感；第三类是刚上手这些工具的新人，与其零散地学一堆快捷键，不如先建立“循环”这个心智模型，后面所有工具都只是这个模型的不同实现。

我先把结论摆在这：Loop Engineering 的核心不是提示词写得多花哨，而是把任务拆成可验证的小步，让每一轮循环都有明确的输入、输出和判定标准。下面我会从整体设计、核心细节、实操落地、问题排查四个层面，把这套方法掰开揉碎讲清楚，中间会穿插 Claude Code、Codex、Cursor 的具体配置和踩坑记录。

2. 整体设计与思路拆解：为什么是“循环”而不是“对话”

2.1 单次对话的三个致命缺陷

先说说为什么“对话式编程”在真实项目里会翻车。我拿自己踩过的坑举例。

第一个缺陷是上下文漂移。你在一个会话里聊了二十轮，前面定义的接口规范、命名约定、目录结构，到第十五轮模型基本就记不清了。它开始自己发明字段名，把userId写成user_id，把异步改成同步。这不是模型笨，是上下文窗口的物理限制加上注意力衰减。

第二个缺陷是缺乏验证闭环。你让模型写个函数，它写完就宣布“完成”。但代码能不能跑、边界条件对不对、有没有破坏原有测试，它不知道也不关心。你得自己手动跑一遍，发现问题再贴回去，一来一回全是人工成本。

第三个缺陷是无法收敛。复杂任务往往需要试错，但对话模式下每次试错都是“推倒重来”，模型不会记住上一轮为什么失败。结果就是它在同一个坑里反复横跳，你越催它越乱。

Loop Engineering 的思路就是针对这三点下药：用结构化状态对抗上下文漂移，用自动验证补上闭环，用失败记忆实现收敛。

2.2 循环的四个基本阶段

一个标准的工程循环，我习惯拆成四段：Plan（规划）→ Act（执行）→ Verify（验证）→ Reflect（反思）。这四段不是线性走一遍就完，而是转圈，直到 Verify 通过或者达到最大轮次。

Plan 阶段负责把模糊需求拆成可执行的具体步骤，输出一份“任务清单”，每一条都要能被独立验证。Act 阶段按清单逐条执行，每次只做一件事，做完立刻进入 Verify。Verify 是关键，它必须是一个机器可判定的动作——跑测试、跑 lint、跑类型检查、对比输出快照，而不是“我觉得应该对了”。Reflect 阶段则把失败原因结构化地记录下来，喂回下一轮 Plan。

这里有个反直觉的点：循环的粒度要小。很多人一上来就让 AI“重构整个模块”，这是大忌。正确的做法是把任务切到“改一个函数 + 跑对应单测”这种粒度，一轮循环控制在几分钟内。粒度越小，验证越快，收敛越稳。

2.3 工具选型的底层逻辑

Claude Code、Codex、Cursor 这三个工具，在循环里扮演的角色其实不一样，选型要看你的循环跑在哪一层。

Claude Code 是终端原生的 agent，它天然适合做“执行器”——能直接读写文件、跑命令、看输出。它的优势在于工具调用能力强，适合放在 Act 和 Verify 阶段。Codex 更偏向代码生成和补全的底层能力，适合做 Plan 阶段的“方案生成器”，或者在循环里当“第二意见”来交叉验证。Cursor 是 IDE 集成，优势在于人机协同，适合你在 Reflect 阶段人工介入、审查 diff、做最终决策。

我的建议是：别指望一个工具包打天下。用 Claude Code 跑自动循环，用 Cursor 做人工审查关口，用 Codex 做方案备选，三者通过文件系统和 git 串起来。这就是所谓的 Harness Engineering（脚手架工程）——你搭的不是提示词，是一套让多个工具协同的“跑道”。

提示：循环工程里，工具之间的“接口”比工具本身更重要。文件格式、git 提交规范、测试命令的统一，这些才是让循环跑起来的地基。

3. 核心细节解析与实操要点：把循环真正搭起来

3.1 任务清单的写法：让每一步都可验证

循环能不能跑起来，八成取决于任务清单写得好不好。我见过太多人把清单写成“优化性能”“修复 bug”这种废话，模型看了只能瞎猜。好的清单长这样：

- [ ] 在 src/utils/date.ts 中新增 formatRelativeTime 函数 验证：npx vitest run src/utils/date.test.ts 全绿 - [ ] 将 src/components/Feed.tsx 第 42 行的硬编码时间替换为 formatRelativeTime 验证：npm run typecheck 无报错，且 Feed 组件快照测试通过 - [ ] 补充 formatRelativeTime 的边界用例（刚刚、1分钟前、1年前） 验证：新增 3 个测试用例且全部通过

看出规律了吗？每一条都包含动作、目标文件、验证命令三要素。验证命令必须是可执行的，不能是“检查是否正确”这种主观描述。这一步做扎实，后面循环才能自动判定成败。

实操心得：写清单时我会刻意让每一步的改动不超过 50 行代码。超过这个量，验证失败时你很难定位是哪一行出的问题。宁可拆成五步，也不要一步到位。

3.2 验证环节的三种武器

验证是循环的“裁判”，裁判不公，循环就废了。我一般准备三种验证手段，按成本从低到高排列。

第一种是静态检查，包括类型检查、lint、格式化。这类工具跑得飞快，几秒钟出结果，适合放在每一轮循环的最前面。TypeScript 项目里tsc --noEmit是标配，配合 ESLint 能拦下大量低级错误。

第二种是单元测试。这是循环的主力裁判。关键是要让 AI 自己写测试——你给它一个函数需求，让它先写测试再写实现，这叫测试驱动。测试通过，这一轮就算过。

第三种是快照对比。对于 UI 组件、API 响应这类输出，用快照测试能捕捉到细微的意外改动。Jest 和 Vitest 都内置了快照功能，toMatchSnapshot()一行搞定。

注意：验证命令一定要在循环开始前手动跑通一次。我踩过的坑是，项目本身测试就是红的，结果 AI 每轮都“验证失败”，白白空转十几轮。

3.3 失败记忆的结构化

Reflect 阶段最容易被忽略，但它决定了循环能不能收敛。我的做法是维护一个loop-log.md，每轮失败都追加一条结构化记录：

## Round 3 - 失败 - 失败步骤：替换 Feed.tsx 时间显示 - 验证命令：npm run typecheck - 报错信息：Type 'string' is not assignable to type 'Date' - 根因分析：formatRelativeTime 返回 string，但 Feed 组件期望 Date - 修正方向：在调用处包一层 new Date()，或修改函数签名

这份日志会在下一轮 Plan 时作为上下文喂给模型。实测下来，有了失败记忆，同一个错误重复出现的概率能降一大半。模型不是不会改，是它记不住上次为什么错。

3.4 循环的终止条件

循环不能无限转，必须设终止条件。我一般设三个：验证全绿、达到最大轮次（通常 8 到 10 轮）、连续两轮无进展。前两个好理解，第三个是防止模型陷入死循环——如果连续两轮报错信息几乎一样，说明它卡住了，这时候应该停下来人工介入，而不是继续烧 token。

4. 实操过程与核心环节实现：从零跑通一个循环

4.1 环境准备与工具安装

先把地基打好。我以 Claude Code 为主执行器，Cursor 为审查端，Codex 为备选方案生成器来演示。

Claude Code 的安装，官方推荐用 npm 全局装：

npm install -g @anthropic-ai/claude-code

装完在项目根目录跑claude就能进交互模式。第一次用需要配置 API 凭证，按提示走就行。这里有个国内用户常遇到的问题：网络环境导致登录卡住。我的经验是提前把代理相关的环境变量配好，或者用支持自定义 endpoint 的方式接入。具体配置因环境而异，核心是保证claude命令能正常发起请求。

Codex 的安装类似，它更偏向 CLI 和 IDE 插件两种形态。CLI 版本适合脚本化调用，插件版本适合在编辑器里随手用。安装包从官方渠道获取，注意版本匹配你的 Node 环境。

Cursor 直接官网下载安装包，装完在设置里把语言改成中文——搜索locale或者language，选zh-cn，重启即可。很多人问 Cursor 怎么设置中文回复，其实分两层：界面汉化是上面这个设置，而让 AI 用中文回复，是在对话里明确说“请用中文回答”，或者在项目根目录放一个.cursorrules文件写死语言偏好。

4.2 搭建循环的目录结构

我在项目里固定建一个.loop/目录，结构如下：

.loop/ ├── tasks.md # 任务清单 ├── loop-log.md # 失败记忆 ├── verify.sh # 统一验证脚本 └── prompts/ ├── plan.md # 规划阶段提示词 ├── act.md # 执行阶段提示词 └── reflect.md # 反思阶段提示词

verify.sh是整个循环的心脏，它把所有验证命令串起来，返回统一的退出码：

#!/bin/bash set -e echo "== 类型检查 ==" npx tsc --noEmit echo "== Lint ==" npx eslint src --max-warnings 0 echo "== 单元测试 ==" npx vitest run echo "== 全部通过 =="

这个脚本的好处是，无论循环里哪一步，验证方式都统一。AI 只需要跑bash .loop/verify.sh，看退出码就知道过没过。

4.3 一轮完整循环的现场记录

我拿一个真实任务演示：给一个 React 项目加“相对时间显示”功能。

Round 1 - Plan：我把需求丢给 Claude Code，让它读tasks.md的模板，生成任务清单。它输出了 4 条任务，我人工审了一遍，把第二条的验证命令从“检查显示正确”改成具体的快照测试命令。

Round 1 - Act：模型按第一条任务，在date.ts里写了formatRelativeTime。写完立刻跑verify.sh，类型检查过了，但它没写测试，vitest 报“没有测试文件”。验证失败。

Round 1 - Reflect：我在loop-log.md记下“缺少测试文件”。下一轮 Plan 时，这条记录被喂回去，模型主动补上了测试。

Round 2 - Act：补测试，跑验证，测试通过。进入第二条任务。

Round 2 - Verify：替换 Feed.tsx 的调用，类型检查报错——返回 string 但期望 Date。这正是我前面举例的那个坑。

Round 3 - Reflect + Act：记录根因，模型在调用处包了new Date()，验证通过。

整个任务跑了 5 轮，总耗时约 12 分钟，其中我人工介入两次（审清单、看 diff）。如果纯手动，这个任务加上写测试、调试，我估计要 40 分钟以上。

4.4 参数选择与轮次控制

最大轮次设多少合适？我的经验公式是：任务步骤数 × 1.5，向上取整，最低 5 轮。4 步任务就设 6 轮。这个系数留出了试错空间，又不至于无限空转。

每轮之间的间隔，如果是自动循环，建议加一个 2 到 3 秒的延迟。原因很实际：文件系统写入和 git 状态更新需要时间，跑太快偶尔会读到旧文件。这个坑我在早期版本踩过，表现为“明明改了却验证不过”，排查半天才发现是时序问题。

5. 常见问题与排查技巧实录

5.1 循环跑不起来的典型症状

用这套方法，我整理了一份高频问题速查表，基本都是实测踩出来的：

5.2 关于工具协同的几个坑

Claude Code 和 Cursor 同时开着改同一个文件，是灾难。我踩过一次，两边各改各的，git diff 一团乱。正确做法是同一时间只有一个工具持有写权限。我的习惯是 Claude Code 跑自动循环时，Cursor 只读不写，等循环停下来再人工审查。

Codex 接入其他模型做备选方案时，要注意输出格式的统一。不同模型的代码风格差异很大，如果不加约束，循环里会混进各种命名习惯。解决办法是在prompts/act.md里写死代码规范，比如“所有函数用 camelCase，所有常量用 UPPER_SNAKE_CASE”。

5.3 独家避坑技巧

第一个技巧：给验证脚本加超时。用timeout 120 bash .loop/verify.sh，防止某个测试卡死拖垮整个循环。我遇到过 watch 模式的测试被误触发，一直不退出，循环直接挂起。

第二个技巧：每轮循环前自动 git commit。这样任何一轮改崩了都能一键回滚。命令很简单，在循环脚本里加git add -A && git commit -m "loop round $N"。回滚时git reset --hard HEAD~1就行。

第三个技巧：用 diff 大小做健康度指标。如果某一轮 diff 突然超过 200 行，八成是模型跑偏了，应该立即中断人工检查。正常的小步循环，每轮 diff 应该在 10 到 50 行之间。

第四个技巧：提示词里明确“不要做什么”。模型很爱自作主张，比如顺手重构无关代码、升级依赖版本。在act.md里加一句“只修改任务清单指定的文件，禁止改动其他文件”，能省掉大量意外。

5.4 循环工程的边界

最后说点实在的：Loop Engineering 不是银弹。它最适合有明确验证标准的任务——写函数、修 bug、加测试、重构有测试覆盖的模块。对于“设计一个新架构”“做一个产品决策”这类没有客观验证标准的任务，循环反而会空转。这时候应该退回到人工主导，把 AI 当参谋而不是执行者。

我个人的判断标准是：如果这个任务你能写出一个自动化的通过/失败判定，就适合循环；写不出来，就别硬套。这个标准帮我省下了大量无效尝试。

这套循环我跑了小半年，最大的体会是：AI 编程的上限不取决于模型多强，而取决于你给它搭的跑道多稳。跑道搭好了，中等模型也能跑出稳定产出；跑道没搭好，再强的模型也是随机漫步。后面我打算把这套结构进一步脚本化，让它能一键启动、自动记录、失败自动回滚，到时候再分享新的进展。