企业官网建设流程全解析

1. 从“会写代码”到“会设计循环”：Loop Engineering 到底在解决什么问题

这两年 AI 编程工具迭代得飞快，Claude Code、Codex、Cursor 一个接一个地冒出来，很多人第一反应是“装哪个”“哪个免费额度多”“国内手机号能不能注册”。但真正把这类工具用进日常开发的人会发现，工具本身只是入场券，决定产出质量的是另一件事——你怎么设计它和代码库之间的循环。这就是 Loop Engineering 想聊的核心。

我先把话说直白一点：Loop Engineering 不是某个官方框架，也不是某个具体产品的功能名，它更像是一种工程实践思路。传统写代码，循环是for、while，是程序内部的执行结构；而在 AI 辅助开发里，循环变成了“你给模型一个任务 → 模型读代码、改代码、跑测试 → 你看结果 → 再给下一轮指令”这样一个闭环。这个闭环设计得好不好，直接决定了你是十分钟搞定一个重构，还是折腾两小时还在原地打转。

为什么现在要专门聊这个？因为大多数人用 Claude Code、Codex、Cursor 的方式还停留在“问答式”：问一句、答一句、复制粘贴。这种方式在写小函数时还行，一旦涉及跨文件改动、依赖升级、测试补齐，就会立刻暴露问题——模型看不到全貌、上下文被截断、改完一处崩三处。Loop Engineering 要解决的，就是把这个“问答”升级成“可控的迭代循环”，让每一轮改动都有明确的输入、可验证的输出、以及可回滚的边界。

这篇文章适合谁看？如果你已经装过 Claude Code 或者用过 Cursor，但总觉得“它好像没那么神”，那这篇就是写给你的。如果你还没上手，也没关系，我会把安装、配置、循环设计、实战踩坑都串起来讲，你照着抄作业就行。核心关键词我会自然带出来：Loop Engineering、Claude Code、Codex、Cursor、Harness Engineering，这几个词基本构成了当前 AI 编程工作流的主干。

先说清楚一个前提：这类工具的能力边界，取决于你给它的“跑道”有多宽。跑道太窄，它只能做补全；跑道设计得好，它能自己跑测试、自己修 bug、自己提交。Loop Engineering 干的就是修跑道这件事。

2. 核心概念拆解：Loop、Harness 与三种主流工具的定位差异

2.1 什么是 Loop Engineering 里的“循环”

在 AI 编程语境下，一个完整的循环通常包含四个阶段：感知（读代码/读报错）→ 决策（规划改动）→ 执行（写代码/跑命令）→ 验证（测试/类型检查）。这四个阶段每转一圈，代码库就向前推进一步。Loop Engineering 的核心工作，就是让这四个阶段尽可能自动化、可观测、可中断。

我举个具体例子。假设你要给一个 Python 项目加一个缓存层。问答式做法是：你问“帮我加个 Redis 缓存”，模型给你一段代码，你手动贴进去，然后自己跑测试。循环式做法是：你告诉 Claude Code“给services/user.py的get_user加缓存，用项目里已有的cache模块，加完后跑pytest tests/test_user.py”。模型会自己读文件、找模块、改代码、执行测试，如果测试挂了，它会在同一轮里继续修，直到通过或者卡住向你求助。

差别在哪？差别在于验证环节被纳入了循环。没有验证的循环是开环，模型改完就撒手；有验证的循环是闭环，模型必须对结果负责。这就是 Loop Engineering 最朴素也最重要的一条原则。

2.2 Harness Engineering：给循环搭一个“测试台”

Harness 这个词在工程里原本指测试夹具、测试台架。Harness Engineering 放到这里，指的是为 AI 编程循环搭建一套支撑设施：包括但不限于项目规则文件、测试命令、lint 配置、权限白名单、上下文裁剪策略。

你可以把 Harness 理解成“给模型准备的工位”。工位上有没有说明书（项目规范）、有没有质检员（测试）、有没有工具箱（可调用的命令），直接决定模型能不能独立干活。很多人抱怨 Codex 或 Claude Code “改着改着就乱改”，八成是 Harness 没搭好——模型不知道你的代码风格、不知道哪些文件不能碰、不知道改完该跑什么命令。

一个最小可用的 Harness 至少包含三样东西：

• 项目规则文件：Claude Code 用CLAUDE.md，Codex 用AGENTS.md，Cursor 用.cursorrules或项目规则。里面写清楚技术栈、目录结构、命名规范、禁止事项。
• 可执行的验证命令：测试、类型检查、lint，最好一条命令能跑完。
• 权限边界：哪些目录可写、哪些命令可执行、哪些操作需要人工确认。

这三样搭好，循环才转得起来。否则模型每轮都要重新猜你的意图，效率极低。

2.3 Claude Code、Codex、Cursor 在循环里的角色差异

这三个工具经常被放在一起比较，但它们在 Loop Engineering 里的定位其实不一样。

Claude Code 的循环最“重”，它倾向于自己规划、自己执行、自己验证，适合把一整块任务丢给它。Codex 更像一个外包工程师，你给需求它交付，中间过程你不太需要盯。Cursor 则是“副驾驶”，循环的每一圈你都在场，适合需要频繁微调的场景。

理解这个差异很重要，因为 Loop Engineering 不是一套通用模板，而是要根据工具特性调整循环的粒度。用 Cursor 时循环可以很碎，几行代码一轮；用 Claude Code 时循环要相对完整，一个功能一轮。搞反了就会很难受——用 Claude Code 做碎活会觉得它啰嗦，用 Cursor 做大重构会觉得它力不从心。

3. 环境搭建实操：从安装到跑通第一个循环

3.1 Claude Code 的安装与初始化配置

Claude Code 目前有终端版和桌面版两条路。终端版通过 npm 安装最省事，前提是本机有 Node.js 环境（建议 18 以上）。

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

装完之后在项目根目录执行claude，第一次会引导你完成登录和初始化。这里有个实操心得：一定要在项目根目录启动，而不是在 home 目录。因为 Claude Code 会以当前目录为工作区读取上下文，在 home 目录启动它会去扫你整个用户目录，既慢又容易读到无关文件。

初始化时会生成一个CLAUDE.md，这是 Harness 的核心文件。我的建议是不要让它自动生成完就不管了，手动补上这几块内容：

# 项目说明 - 技术栈：Python 3.11 + FastAPI + SQLAlchemy - 测试命令：pytest -q - 类型检查：mypy app/ - 代码风格：black + isort，行宽 100 # 禁止事项 - 不要修改 migrations/ 下的历史迁移文件 - 不要直接改 .env，配置走 config.py - 提交前必须跑通 pytest

这份文件看起来简单，但它直接决定了模型每轮循环的“行为准则”。我试过不写测试命令，结果模型改完代码自己瞎猜怎么验证，浪费好几轮。写清楚之后，它改完会主动跑pytest -q，效率完全不一样。

Ubuntu 环境下如果遇到权限问题，通常是 npm 全局目录的权限，用npm config set prefix指到用户目录即可，不建议直接sudo npm install -g，后面升级会踩坑。VS Code 用户可以直接装 Claude Code 的官方扩展，配置和终端版共用同一份CLAUDE.md。

3.2 Codex 的安装与配置文件解析

Codex 的安装分云端和本地两种。本地版同样依赖 Node 环境，安装命令类似：

npm install -g @openai/codex

Windows 桌面版用户如果遇到安装包问题，优先确认系统架构（x64 还是 arm64）和 Node 版本。Codex 的配置文件一般是~/.codex/config.toml或项目级的AGENTS.md。配置文件里几个关键项值得说：

• model：指定使用的模型，不同模型在代码任务上的表现差异明显。
• approval_mode：控制哪些操作需要人工确认。新手建议先用需要确认的模式，跑顺了再放开。
• sandbox：沙箱模式，限制文件写入范围，防止模型误改系统文件。

Codex 接入第三方模型（比如 DeepSeek）是很多人关心的点。配置上一般是在 config 里改 base_url 和 api_key，但要注意：不同模型对工具调用的支持程度不一样，有些模型不支持 function calling，接进来之后 Codex 的 Agent 能力会大打折扣，只能当普通对话用。这个坑我踩过，接完发现它不会自己读文件了，排查半天才意识到是模型能力问题。

3.3 Cursor 的中文设置与注册注意事项

Cursor 是编辑器形态，安装就是下载安装包一路下一步。新手最常问的两个问题：怎么设置中文回复、注册时手机号怎么填。

中文回复分两层。一层是界面语言，在设置里搜 “language” 改成中文即可。另一层是模型回复语言，这个界面设置管不了，得在 Rules 里加一句：

Always respond in Chinese (Simplified).

加在 User Rules 或项目 Rules 里都行。我建议加在项目 Rules，因为不同项目你可能想要不同语言。实测下来，光改界面语言模型还是回英文，必须显式在规则里声明。

注册方面，Cursor 支持多种方式，具体能不能用某个地区的手机号，取决于它当时的注册策略，这个会变。我的建议是优先用邮箱注册，省去手机号的麻烦。免费额度方面，Cursor 的免费档有每月的补全和对话次数限制，重度使用基本不够，但用来体验循环工作流完全够。

3.4 跑通第一个最小循环

环境搭好后，别急着上大项目。先拿一个小任务跑通完整循环，建立手感。我通常用这个练手任务：给一个已有函数补单元测试，并让测试通过。

步骤是这样的：

1. 在项目里找一个没有测试的纯函数。
2. 对 Claude Code 说：“给utils/format.py的format_duration补单元测试，覆盖 0 秒、59 秒、60 秒、3600 秒四个边界，测试文件放tests/test_format.py，写完跑 pytest 确认通过。”
3. 观察它的循环：读文件 → 写测试 → 跑 pytest → 如果失败就修 → 再跑。
4. 检查最终结果，看测试是否真的覆盖了边界。

这个任务小，但完整走了一遍“感知-决策-执行-验证”。跑通之后你对循环的节奏就有感觉了。我第一次跑的时候，模型把 60 秒的期望值写错了，但它自己跑测试发现失败，第二轮就改对了——这就是闭环的价值，开环的话这个错误就留给你了。

4. 循环设计的核心方法论：粒度、上下文与验证

4.1 循环粒度怎么定：大循环 vs 小循环

循环粒度是 Loop Engineering 里最需要经验判断的地方。粒度太粗，模型一轮要干太多事，容易跑偏；粒度太细，你光下指令就累死了。

我的经验法则是：一轮循环的产出，应该是一个可以独立验证的最小单元。什么叫可独立验证？就是改完之后你能明确说“对”或“不对”。比如“给这个函数加参数校验”是可验证的，“优化一下这个模块”就不可验证。

具体到不同任务：

• 单文件小改动：一轮一个函数或一个方法，Cursor 里几行一轮都行。
• 跨文件重构：一轮一个明确的改动目标，比如“把UserService里的数据库调用抽到UserRepository”，改完跑测试。
• 新功能开发：拆成“定义接口 → 实现 → 补测试 → 接路由”几轮，每轮一个可验证产出。

我见过最常见的错误是“一句话丢一个大需求”。比如“帮我做个用户登录系统”，模型会给你一堆代码，但质量参差不齐，你还得逐行审。拆成几轮之后，每轮产出都可控，返工成本低得多。

4.2 上下文管理：让模型看到该看的，屏蔽不该看的

上下文是循环的燃料。给多了，模型注意力被稀释，还费 token；给少了，它看不到关键信息，改出来的东西对不上。

Claude Code 和 Codex 都会自动读相关文件，但自动读取不一定准。我的做法是主动指路：在指令里明确说“参考services/order.py的写法”或者“不要动legacy/目录”。这比让模型自己猜高效得多。

还有一个技巧是用规则文件做长期上下文。把项目里反复出现的约定写进CLAUDE.md或AGENTS.md，这样每轮循环它都会带上，不用你每次重复。比如“所有数据库操作必须走 repository 层”“错误统一用AppError抛出”，写一次管很久。

上下文裁剪也要注意。大项目里模型读文件很容易读一堆无关的，导致关键信息被挤掉。可以在规则里写明“优先读app/下的文件，忽略node_modules/、dist/、venv/”。这些目录本来也不该进上下文。

4.3 验证环节：闭环的灵魂

没有验证的循环等于没有循环。验证手段按可靠性排序，大概是：自动化测试 > 类型检查 > lint > 人工目测。理想情况下每轮循环至少跑前两样。

为什么测试最重要？因为它是唯一能真正证明“行为正确”的手段。类型检查能保证接口对得上，但保证不了逻辑对。lint 只管风格。人工目测最不可靠，你盯十行代码还行，盯一百行必然漏。

实操上，我会在规则文件里写死验证命令，并要求模型每轮改完必须跑。Claude Code 支持在CLAUDE.md里定义命令，Codex 类似。如果项目还没有测试，那第一轮循环的任务就是“补测试”，而不是“改功能”。先把验证能力建起来，后面的循环才有意义。

有个细节：测试跑得慢会拖垮循环节奏。如果全量测试要五分钟，每轮都跑不现实。我的做法是让模型只跑相关测试文件，比如pytest tests/test_user.py -q，全量测试留到循环结束前跑一次。这个策略要写进规则，否则模型可能每轮都跑全量。

5. 项目实战：用循环方式完成一次真实重构

5.1 任务背景与循环规划

假设我们有一个 FastAPI 项目，services/user.py里混了数据库访问、业务逻辑、缓存操作，文件快 500 行了。目标是把它拆成repository（数据访问）、service（业务逻辑）、cache（缓存）三层。

这种重构如果问答式做，基本是灾难——模型看不到全貌，改一处崩一处。用循环方式，我会这样规划：

• 第 1 轮：让模型读user.py，输出一份拆分方案，不写代码。
• 第 2 轮：创建repositories/user_repository.py，把数据库访问搬过去，跑测试。
• 第 3 轮：创建services/user_service.py，把业务逻辑搬过去，跑测试。
• 第 4 轮：把缓存操作抽到cache/user_cache.py，跑测试。
• 第 5 轮：更新调用方，跑全量测试。

每轮都有明确产出和验证点。第 1 轮不写代码很关键，让模型先规划，你能提前发现它的理解偏差，避免它闷头改错方向。

5.2 关键轮次的指令设计与执行记录

第 2 轮的指令我是这么写的：

读services/user.py，把其中所有直接使用db.session的数据库操作抽到新建的repositories/user_repository.py。repository 只做数据访问，不包含业务判断。保持函数签名不变，services/user.py里改为调用 repository。改完跑pytest tests/test_user.py -q，失败就修到通过。

这条指令有几个要点：明确输入文件、明确输出文件、明确职责边界（“不包含业务判断”）、明确验证命令、明确失败处理策略（“修到通过”）。这五点写全，模型基本不会跑偏。

执行时我盯着它的循环：它先读了user.py，然后创建 repository 文件，把db.session.query(...)这类调用搬过去，再回user.py改调用。跑测试时挂了一个，因为有个查询用了joinedload，搬过去之后 import 没补。它自己发现报错，第二轮补了 import，测试通过。

这个过程如果人工做，大概二十分钟；模型跑了大概三分钟，我审代码花了两分钟。效率提升是实打实的，但前提是循环设计对了。

5.3 循环中的回滚与中断策略

循环不是一路向前就完事，回滚能力是安全网。我的习惯是每轮循环前确保工作区干净（git status无未提交改动），这样任何一轮出问题都能git checkout .一键回滚。

Claude Code 和 Codex 在执行破坏性操作前一般会请求确认，但别完全依赖它。我遇到过模型想删一个“看起来没用”的文件，其实是被动态 import 的。所以规则文件里我会写：“删除任何文件前必须明确说明理由并等待确认。”

中断策略也很重要。如果模型连续两三轮都在同一个错误上打转，别让它继续烧 token，直接中断，人工介入看看是不是上下文给错了。我踩过的坑是：模型一直改不对一个测试，我让它自己修了五轮，最后发现是我在指令里把期望值写错了。循环卡住时，先怀疑自己的输入，再怀疑模型。

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

6.1 工具类问题速查

6.2 循环类问题排查思路

工具问题好查，循环问题更隐蔽。我总结了几条排查思路：

症状一：模型改的代码风格和项目不一致。八成是规则文件没写清楚风格约定。补上“用 black 格式化，行宽 100”这类具体规则。

症状二：模型反复改同一个地方改不对。先看指令有没有歧义，再看上下文是不是缺了关键文件。有时候是模型没读到某个基类，导致它不知道方法签名。

症状三：改完 A 功能，B 功能挂了。这是典型的验证不足。要么测试覆盖不够，要么没跑全量测试。补测试，并在循环结束前强制跑一次全量。

症状四：模型“自作主张”改了不该改的文件。规则文件里加禁止清单，明确哪些目录不能碰。

6.3 几条踩坑换来的经验

第一条：规则文件是活的，要持续维护。每次发现模型犯同类错误，就往规则里加一条。我的CLAUDE.md从最初十行涨到现在六十多行，每一条都是踩坑换来的。

第二条：别让模型一次改太多文件。一轮循环涉及的文件超过五个，出错概率陡增。宁可多分几轮。

第三条：验证命令要快。慢测试会让人不自觉地跳过验证，闭环就破了。用-k或指定文件的方式跑相关测试。

第四条：保留人工审查环节。循环再顺，最终代码也得人看。模型能保证测试通过，保证不了设计合理。我一般每轮循环后花一两分钟扫一眼 diff，发现问题早，返工少。

第五条：不同工具别混用同一套循环。Cursor 适合碎循环，Claude Code 适合整循环，硬套同一套节奏会别扭。根据工具特性调整，才是 Loop Engineering 的正确姿势。

这套东西说到底，核心就一句话：把 AI 编程从“问答”变成“可控迭代”。工具会一直变，Claude Code 会升级，Codex 会出新版，Cursor 会加功能，但循环设计的思路是通用的。把粒度、上下文、验证这三件事想清楚，换什么工具都能快速上手。我自己从最早用 Cursor 补全，到后来用 Claude Code 跑重构，最大的体会就是：模型能力固然重要，但你给它搭的跑道，才是决定它能跑多远的关键。