企业官网建设流程全解析

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

大多数人接触 AI 编程工具的第一天，脑子里装的都是"提示词怎么写"。写了两周之后你会发现，真正卡住你的根本不是某一句提示词够不够精妙，而是整个流程跑不起来：改完一个文件忘了跑测试，跑完测试忘了看报错，看完报错又忘了刚才改的是哪一行。一次两次靠脑子记还行，任务一多、上下文一长，人就成了整个系统里最不可靠的那个环节。

Loop Engineering 这个词最近被反复提起，本质上说的就是这件事：把"人盯着 AI 一步步干活"变成"设计一套能自己转起来的回路"。回路里有几个固定角色——执行者负责动手，验证者负责挑刺，反馈通道负责把挑出来的问题送回执行者手里，直到满足退出条件为止。听起来像软件工程里的 CI/CD，但对象从"人写的代码"换成了"AI 生成的代码"，节奏也从"提交一次跑一次"变成了"每轮对话都在跑"。

我自己的体会是，Loop Engineering 的价值不在于让 AI 更聪明，而在于让 AI 的产出变得可验证、可复现、可收敛。没有回路的 AI 编程，就像让一个实习生闭着眼睛改代码，改完还不给你看 diff。有了回路，你至少知道每一轮改了什么、为什么改、改完有没有变好。

这篇内容会围绕 Loop Engineering 的完整落地来讲，涉及 Claude Code、Codex、Cursor 这几个主流工具在回路里各自扮演什么角色，怎么搭一套能跑通的 harness，以及我在实际项目里踩过的那些坑。不管你是刚装好 Claude Code 的新手，还是已经在用 Cursor 写了大半年代码的老手，应该都能从里面找到能直接抄的部分。

2. 回路里的四个角色：谁执行、谁验证、谁反馈、谁喊停

在动手搭之前，得先把回路的结构想清楚。很多人一上来就急着配工具、装插件，结果搭出来的东西跑两轮就散了，根本原因是没想明白每个环节的职责边界。

2.1 执行者：不是"最强的模型"，而是"最合适的模型"

执行者就是真正动手改代码的那个角色。这里有个特别常见的误区：很多人默认执行者一定要用最强的模型，觉得越贵越好。实际跑下来完全不是这么回事。

执行者的核心要求是稳定、可控、上下文管理清晰。它需要能准确理解任务边界，不会自作主张改一堆无关文件，也不会因为上下文太长就开始胡编。Claude Code 在这方面的表现比较突出，它的文件操作是显式的，每次改动你都能看到具体动了哪些文件、哪些行，这对回路来说非常关键——因为验证者需要知道"这一轮到底改了什么"。

Codex 作为执行者也有它的优势，尤其是在纯代码生成任务上，它的输出往往更"干净"，不会带太多解释性文字。但它的上下文窗口管理策略和 Claude Code 不太一样，长任务里需要更频繁地做状态同步。

我的建议是：执行者选你用得最熟的那个。因为回路跑起来之后，你需要频繁地介入、调整、看日志，工具越熟，调试成本越低。新手可以从 Claude Code 入手，它的交互反馈比较友好；如果你已经在用 Codex 写代码，那就继续用 Codex，没必要为了"追新"换工具。

2.2 验证者：回路的灵魂，也是最容易被忽略的角色

验证者是整个回路里最容易被敷衍的一环。很多人搭回路的时候，执行者配得特别认真，验证者就随便写个"检查一下有没有报错"，结果回路跑起来形同虚设。

验证者要做的事情比"看有没有报错"复杂得多。它至少要覆盖三层：

• 语法层：代码能不能跑，有没有明显的类型错误、未定义变量、导入缺失。这一层用编译器、linter、类型检查器就能搞定，成本最低。
• 逻辑层：改动有没有实现预期功能，边界条件处理了没有，异常路径覆盖了没有。这一层需要测试用例，最好是执行者改代码之前就存在的测试。
• 意图层：改动有没有偏离原始需求，有没有引入不必要的复杂度，有没有破坏原有的设计约定。这一层最难自动化，通常需要人来看，但可以通过让验证者输出"改动摘要 + 风险点"来降低人的阅读成本。

我见过太多人把验证者写成"跑一下测试"，然后测试挂了也不看具体哪条挂了，直接让执行者"再改改"。这不是回路，这是碰运气。

2.3 反馈通道：把"哪里错了"说清楚，比"错了"重要一百倍

反馈通道的质量直接决定回路能不能收敛。一个糟糕的反馈是"测试没通过，你再改改"；一个好的反馈是"第 3 个测试用例失败，期望返回 200 实际返回 500，错误堆栈指向 user_service.py 第 47 行的空指针解引用"。

后者之所以好，是因为它给了执行者足够的信息去定位问题，而不是让它盲目地猜。在 Claude Code 里，你可以直接把测试输出粘贴回去，它会自己解析堆栈；在 Codex 里，你可能需要把关键行摘出来，因为它对超长输出的处理策略不同。

这里有个实操技巧：反馈里永远带上"上一轮改了什么"。因为执行者的上下文是有限的，跑了几轮之后它可能已经忘了自己第一轮改过什么。把 diff 摘要附在反馈里，能显著降低它"改回去"或者"改重复"的概率。

2.4 退出条件：什么时候停，比什么时候开始更难判断

退出条件设得太松，回路会一直跑，烧钱又烧时间；设得太紧，回路会在问题还没解决的时候就停，你还得手动重启。

我一般会设三层退出条件：

1. 硬性条件：所有测试通过 + 类型检查通过 + lint 通过。这是底线，不满足绝不退出。
2. 软性条件：连续两轮改动幅度小于某个阈值（比如 diff 行数少于 5 行），说明已经收敛了，可以停。
3. 兜底条件：轮次上限，比如最多跑 10 轮。防止回路陷入死循环，尤其是当问题本身无解的时候。

这三层条件要同时配置，任何一层触发都可以退出。实际跑下来，大部分任务在第 3 到第 5 轮就收敛了，跑到 10 轮的通常是需求本身有问题，需要人介入重新拆解。

3. 用 Claude Code 搭一套最小可跑回路

理论说完了，直接上实操。这一节我用 Claude Code 搭一套最小可跑的回路，跑通之后你再往里面加东西。

3.1 环境准备：装完之后先别急着写代码

Claude Code 的安装本身不复杂，但有几个细节新手特别容易忽略。

首先是 Node 版本。Claude Code 对 Node 版本有要求，太老的版本会直接报错。装之前先跑node -v确认一下，建议用 18 以上的 LTS 版本。如果你机器上有多个 Node 版本，用 nvm 切一下，别用系统自带的那个。

其次是工作目录。Claude Code 默认会在你启动它的目录下操作文件，所以一定要在项目根目录启动，不要在 home 目录或者桌面启动。我见过有人在家目录启动，结果 Claude Code 把整个 home 目录当成了项目上下文，读了一堆无关文件，token 直接爆掉。

启动之后第一件事是让它读一下项目结构，你可以直接说"先看一下这个项目的目录结构和主要文件，不要改任何东西"。这一步的目的是让它建立上下文，同时你也能观察它读文件的方式对不对。

注意：Claude Code 在读取文件时会消耗 token，项目越大消耗越快。如果项目里有 node_modules、dist、.git 这类目录，提前在配置里排除掉，能省不少钱。

3.2 把任务拆成"可验证的小块"

回路能不能跑起来，很大程度上取决于任务拆得够不够细。一个"帮我实现用户登录功能"的任务，扔给回路基本跑不动，因为验证者根本不知道从哪验起。

正确的拆法是拆到"每一块都有明确的输入输出和验证方式"。比如用户登录可以拆成：

• 定义用户数据模型（验证：模型文件存在，字段完整）
• 实现密码哈希函数（验证：单元测试通过，相同输入输出一致）
• 实现登录接口（验证：接口测试通过，正确密码返回 token，错误密码返回 401）
• 实现 token 生成和校验（验证：token 能生成、能校验、过期能识别）

每一块都是一个独立的回路单元，跑完一块再跑下一块。这样即使某一块卡住了，也不会影响其他部分，而且验证者的工作变得非常明确。

3.3 写一个"验证脚本"，而不是靠嘴说

这是整个回路里最值得投入时间的地方。不要指望用自然语言告诉 Claude Code"你验证一下"，它验证的质量完全取决于你怎么描述。更好的做法是写一个真正的验证脚本，让回路去跑这个脚本。

比如针对"实现密码哈希函数"这一块，你可以先写一个测试文件：

# test_password.py import pytest from auth.password import hash_password, verify_password def test_hash_consistency(): h1 = hash_password("test123") h2 = hash_password("test123") assert h1 == h2, "相同输入应产生相同哈希" def test_hash_different_input(): h1 = hash_password("test123") h2 = hash_password("test456") assert h1 != h2, "不同输入应产生不同哈希" def test_verify_correct(): h = hash_password("test123") assert verify_password("test123", h) is True def test_verify_wrong(): h = hash_password("test123") assert verify_password("wrong", h) is False

然后回路里的验证步骤就变成一句话："跑pytest test_password.py，如果失败，把失败信息反馈给执行者。"这样验证标准是客观的，不依赖模型的理解。

3.4 跑第一轮：观察它怎么"想"

第一轮不要急着让它改代码，先让它说出计划。你可以这样下指令：

"我要实现密码哈希功能，文件放在 auth/password.py。先不要写代码，告诉我你打算怎么做，包括用什么库、函数签名是什么、边界条件怎么处理。"

这一步的价值在于，你能提前发现它的方案有没有问题。比如它可能打算用 md5，你一看就知道不对，直接纠正；如果等它写完再发现，就得多跑一轮回路。

确认方案没问题之后，再让它动手。动手的时候要求它每改一个文件就说明改了什么，这样你能实时跟踪进度，也方便后面写反馈。

3.5 反馈怎么写才能让它真的改对

第一轮跑完，测试大概率不会全过。这时候反馈的写法就很重要了。

差的反馈："测试没通过，再改改。"

好的反馈：

"跑了pytest test_password.py，4 个用例里 2 个失败：

• test_verify_correct 失败：期望 True，实际 False。看起来是 verify_password 里的比较逻辑有问题。
• test_hash_different_input 失败：两个不同输入产生了相同哈希，可能是 salt 没加或者加错了。 其他两个用例通过。请只修改 auth/password.py，不要动测试文件。"

这个反馈里包含了：跑了什么、哪些失败、失败的具体表现、你的初步判断、修改范围限制。执行者拿到这个，基本一轮就能改对。

提示：反馈里明确"不要动测试文件"非常重要。否则执行者可能会去改测试来"让测试通过"，这是回路里最危险的行为之一。

4. Codex 和 Cursor 在回路里的分工：别指望一个工具干所有事

很多人纠结"到底用 Claude Code 还是 Codex 还是 Cursor"，其实这个问题本身就问错了。这三个工具在回路里的定位完全不同，用对了是互补，用错了是互相拖累。

4.1 Codex 适合当"批量执行器"，不适合当"交互式调试器"

Codex 的强项是批量生成代码。你给它一个明确的任务描述，它能一次性产出大量代码，而且风格比较统一。在回路里，它适合承担"执行者"的角色，尤其是当任务比较独立、不需要频繁交互的时候。

但 Codex 不太适合做交互式调试。它的反馈循环没有 Claude Code 那么即时，你改一句它回一句的节奏比较慢。所以如果你的回路需要频繁地"改一点、看一下、再改一点"，Codex 不是最佳选择。

我的用法是：用 Codex 做初版生成，用 Claude Code 做迭代调试。比如一个新模块，先让 Codex 按需求生成一版完整代码，然后切到 Claude Code 里跑测试、修 bug、调边界。这样两边都发挥了自己的长处。

4.2 Cursor 的价值在"人机协同编辑"，不在"全自动回路"

Cursor 和前面两个的定位差别最大。它本质上是一个增强版的编辑器，AI 是嵌在编辑体验里的。它的强项是"你写一半它补一半"、"你选中一段它帮你改"，这种协同编辑的体验是 Claude Code 和 Codex 给不了的。

但在全自动回路里，Cursor 的角色比较尴尬。因为回路需要的是"无人值守地跑"，而 Cursor 的设计哲学是"人在环路中"。你很难让 Cursor 自己跑一个完整的"改代码-跑测试-看结果-再改"的循环，它更适合你在回路卡住的时候，手动介入去调那几行关键代码。

所以我的建议是：回路用 Claude Code 或 Codex 跑，卡住的时候切到 Cursor 手动调。Cursor 的中文设置、汉化这些配置问题，网上教程很多，这里不展开，重点是你得想清楚它在你的工作流里到底承担什么。

4.3 三个工具的能力对照

这张表不是让你选一个，而是让你知道什么时候该切哪个。回路跑得顺的时候用 Claude Code，需要大批量产出的时候切 Codex，卡在某个细节上手动调的时候开 Cursor。

5. Harness Engineering：把回路"工程化"的关键一层

前面讲的都是"怎么让回路跑起来"，这一节讲"怎么让回路跑得稳、跑得久、跑得可维护"。这就是 Harness Engineering 要解决的问题。

5.1 什么是 harness，为什么它比模型更重要

Harness 直译是"马具"，在 AI 编程语境里，它指的是包裹在模型外面的那一层工程结构：任务怎么拆、上下文怎么管、验证怎么做、失败怎么重试、日志怎么记、成本怎么控。

很多人把注意力全放在"用哪个模型"上，觉得换个更强的模型就能解决问题。实际跑下来你会发现，同一个模型，harness 搭得好和搭得差，产出质量能差出好几倍。模型是发动机，harness 是底盘和传动系统，发动机再强，底盘不行也跑不快。

一个完整的 harness 至少包含这几块：

• 任务队列：待处理的任务列表，每个任务有明确的输入、输出、验证方式
• 上下文管理：每个任务需要哪些文件、哪些历史信息，怎么裁剪、怎么注入
• 验证执行器：跑测试、跑 lint、跑类型检查的统一入口
• 反馈格式化：把验证结果整理成执行者能理解的格式
• 状态持久化：每一轮的改动、验证结果、反馈都记下来，方便回溯
• 成本控制：token 消耗、轮次上限、超时退出

5.2 上下文管理：回路里最容易失控的地方

上下文管理是 harness 里最容易被低估的部分。回路跑起来之后，每一轮都会往上下文里塞东西：上一轮的 diff、验证结果、反馈、新的文件内容。几轮下来，上下文就爆了。

我的做法是分层管理上下文：

• 常驻层：项目结构、核心约定、当前任务的原始需求。这部分每轮都带，但内容要精简。
• 滚动层：最近 2 到 3 轮的 diff 和验证结果。这部分每轮更新，旧的丢掉。
• 按需层：当前正在改的文件内容。这部分只在需要的时候注入，改完就撤。

这样能把上下文控制在合理范围内，同时保证执行者始终能看到"最近发生了什么"和"当前要改什么"。

注意：不要把所有历史都塞进上下文，指望模型自己"记住"。模型的记忆是不可靠的，而且上下文越长，它越容易忽略中间部分的内容。主动裁剪比被动依赖更靠谱。

5.3 失败重试：不是所有失败都值得重试

回路跑起来之后，失败是常态。但不是所有失败都应该触发重试。

我一般把失败分成三类：

• 可重试失败：测试挂了、lint 报错、类型不匹配。这类失败有明确的错误信息，执行者拿到反馈后大概率能改对，值得重试。
• 需人工介入的失败：需求本身有歧义、验证标准不明确、连续多轮改动方向都不对。这类失败重试再多也没用，得人来重新拆任务。
• 环境失败：依赖没装、端口被占、网络超时。这类失败跟代码无关，修环境就行，不用走回路。

Harness 里要能区分这三类，可重试的自动重试，需人工的挂起等介入，环境问题直接报错退出。不加区分地一律重试，只会浪费时间和 token。

5.4 日志：回路跑完之后，你得能复盘

日志这件事，跑的时候觉得没用，出问题的时候觉得救命。

我要求 harness 记录每一轮的：任务 ID、轮次、执行者改动的文件列表、diff 摘要、验证结果、反馈内容、token 消耗、耗时。这些信息在复盘的时候特别有用，你能看出哪类任务容易卡、哪个环节最费 token、哪种反馈格式最有效。

日志不用搞得很复杂，一个结构化的 JSON 文件就行，每轮追加一条。跑完之后用脚本统计一下，很快就能发现规律。

6. 实战：用回路重构一个"半成品"模块

光讲理论没意思，这一节用一个真实场景走一遍完整流程。场景是：手上有一个半成品的数据处理模块，功能能跑但边界处理很烂，测试覆盖率不到 30%，想用回路把它重构到测试覆盖率 80% 以上。

6.1 先摸清现状，别急着让 AI 动手

第一步不是让 AI 改代码，而是让它读代码并输出一份现状报告。指令可以这样写：

"读一下 data_processor 目录下的所有文件，输出一份报告，包含：每个文件的职责、主要函数列表、当前测试覆盖了哪些函数、哪些函数完全没有测试、你判断哪些地方边界处理有问题。不要改任何代码。"

这一步的价值在于，你能拿到一份结构化的现状描述，同时也能验证 AI 对代码的理解对不对。如果它读错了，后面全白搭。

6.2 按"风险 × 改动量"排优先级

拿到现状报告之后，不要按文件顺序一个个改，而是按优先级排。我的排序逻辑是：

• 高风险 + 小改动：优先做。比如一个核心函数缺了空值检查，改两行就能修，收益大风险小。
• 高风险 + 大改动：排第二。比如核心逻辑需要重写，改动大但必须做。
• 低风险 + 小改动：排第三。顺手做掉。
• 低风险 + 大改动：最后做，或者干脆不做。投入产出比太低。

这个排序逻辑要明确写进 harness 的任务队列里，让回路按这个顺序跑。

6.3 每一轮只做一件事

回路跑起来之后，最容易犯的错是"一轮改太多"。一轮改三个函数，测试挂了，你根本不知道是哪个函数的问题。

我的做法是每一轮只改一个函数，或者一个明确的逻辑单元。改完立刻跑测试，通过了再进下一个。这样虽然轮次多，但每轮的问题都很清晰，调试成本低。

具体到操作上，你可以在指令里明确限制："这一轮只修改parse_date函数，其他函数不要动。"执行者拿到这个限制，改动范围就锁死了。

6.4 测试先行的具体操作

重构场景下，测试先行特别重要。因为你要改的是已有代码，如果没有测试兜底，改完你都不知道有没有改坏。

具体操作是：先让 AI 为待改函数补测试，测试通过之后再改函数本身。补测试的时候要求它覆盖：正常输入、边界输入（空值、极值、特殊字符）、异常输入（类型错误、格式错误）。

补完测试跑一遍，确认测试能过（说明测试写对了），然后再让 AI 改函数。改完之后再跑一遍测试，如果挂了，说明改动引入了问题，反馈回去继续改。

这个流程看起来慢，但实际跑下来比"改完再补测试"快得多，因为问题在最早的时候就被发现了。

6.5 一个真实的踩坑记录

说个我实际踩过的坑。有一次重构一个日期解析函数，AI 补的测试里有一个用例是parse_date("2024-02-30")，期望返回 None。测试通过了，函数也改完了，看起来一切正常。

结果上线之后发现，生产环境里有大量2024-02-29这种闰年日期，函数返回了 None，导致数据丢失。原因是 AI 补测试的时候只考虑了"非法日期返回 None"，没考虑"合法但特殊的日期要正常解析"。

这个坑的教训是：AI 补的测试，你要自己过一遍。它补的测试往往覆盖了它想到的情况，但想不到的情况它也不会补。尤其是业务相关的边界，只有你知道哪些日期是合法的、哪些是特殊的。

后来我在 harness 里加了一条规则：AI 补完测试之后，必须输出一份"测试覆盖的场景列表"，我人工确认一遍再继续。这个规则加进去之后，类似的坑就再没踩过。

7. 回路跑不动的时候，先检查这五个地方

回路搭起来之后，跑不动是常态。这一节列几个我遇到最多的问题，以及对应的排查思路。

7.1 执行者"改错地方"：上下文注入有问题

表现是执行者改了不该改的文件，或者改了一个跟任务无关的函数。原因通常是上下文里塞了太多无关文件，执行者分不清哪些是当前任务相关的。

排查方法：看 harness 的日志，确认这一轮注入了哪些文件。如果注入了超过 5 个文件，大概率是上下文太杂了。解决方法是精简注入范围，只给当前任务直接相关的文件。

7.2 验证者"验了个寂寞"：验证标准太模糊

表现是验证通过了，但实际功能是坏的。原因通常是验证标准写得太模糊，比如"检查代码是否正确"这种，AI 随便看看就说过。

排查方法：把验证标准改成可执行的脚本或明确的检查项。比如"跑 pytest 且全部通过"、"跑 mypy 且无错误"、"检查函数签名是否为def parse_date(s: str) -> Optional[date]"。标准越具体，验证越可靠。

7.3 回路"原地打转"：反馈没有新信息

表现是跑了好几轮，改动来回横跳，问题始终没解决。原因通常是反馈里没有新信息，执行者每轮拿到的反馈都差不多，只能瞎猜。

排查方法：看日志里每轮的反馈内容，如果连续几轮反馈几乎一样，说明验证环节没有提供新的诊断信息。解决方法是让验证者输出更详细的失败信息，比如具体的错误堆栈、失败的输入值、期望值和实际值的对比。

7.4 成本"悄悄失控"：没有轮次和 token 上限

表现是跑了一晚上，第二天发现账单爆了。原因是没有设轮次上限和 token 上限，回路一直在跑。

排查方法：在 harness 里加硬性上限，轮次不超过 10 轮，单任务 token 不超过某个值，超了就挂起等人工确认。这个上限要根据任务复杂度调整，简单的任务 3 轮就够，复杂的可以放宽到 15 轮。

7.5 人"被排除在外"：没有介入点

表现是回路跑着跑着方向完全偏了，但人一直没发现，等发现的时候已经跑了很多轮。

排查方法：在 harness 里设几个"检查点"，比如每 3 轮暂停一次，输出当前状态让人确认。确认没问题再继续，有问题就调整方向。这个检查点不用太频繁，否则就失去了自动化的意义，但也不能没有。

8. 一些跑久了才明白的经验

回路这东西，跑得越多，越会发现一些反直觉的地方。

第一，不是所有任务都值得搭回路。一次性任务、探索性任务、需求还在变的任务，搭回路反而是负担。回路适合的是"目标明确、验证清晰、需要反复迭代"的任务。判断标准很简单：如果这个任务你手动做也就十分钟，那就别搭回路了。

第二，回路的瓶颈往往不在模型，而在验证。模型再强，验证跟不上，回路就跑不出高质量的结果。我花在写验证脚本上的时间，比花在调提示词上的时间多得多，但回报也大得多。

第三，反馈的质量比反馈的数量重要。与其跑十轮模糊的反馈，不如跑三轮精准的反馈。每一轮反馈都要让执行者拿到新的、具体的信息，否则就是浪费。

第四，人始终要在环路里，只是位置变了。Loop Engineering 不是把人踢出去，而是把人从"每一步都盯着"变成"设计回路、设检查点、处理异常"。人的价值在于判断，不在于执行。

第五，工具会变，回路的思路不会变。Claude Code、Codex、Cursor 这些工具，版本更新很快，功能也在变。但"执行-验证-反馈-退出"这个基本结构是稳定的。把思路搞清楚，换工具的时候迁移成本很低。

最后分享一个我一直在用的小技巧：每次搭新回路的时候，先用一个"玩具任务"跑通全流程。比如写一个只有两个函数的模块，跑一遍完整的回路，确认每个环节都通了，再上真实任务。这样能把环境问题、配置问题、流程问题在低成本的情况下暴露出来，比直接上真实任务踩坑划算得多。