企业官网建设流程全解析

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

大多数人用 AI 编程工具的方式还停留在"一问一答"：打开对话框，敲一段提示词，等它吐出一段代码，复制粘贴，跑一下，报错了再回来问。这个模式在写小脚本、改单个函数时够用，但一旦面对"给整个项目加一套鉴权""把散落在十几个文件里的重复逻辑抽成公共模块""按新需求重构数据层"这类任务，就会立刻崩掉——因为这类任务的本质不是"生成一段代码"，而是"在一个真实代码库里，经过多轮读取、修改、验证、回退，最终让系统达到某个状态"。

Loop Engineering（循环工程）说的就是这件事：把 AI 编程工具从"单次问答的聊天机器人"改造成"能自己跑多轮、自己看结果、自己决定下一步的循环体"。这里的"循环"不是指写个for循环那么简单，而是指一个完整的感知—决策—执行—验证闭环：工具读取当前代码状态，决定改哪里，执行修改，运行测试或类型检查拿到反馈，再根据反馈决定是继续、修正还是停止。

为什么现在这个词突然火了？因为 Claude Code、Codex、Cursor 这几类工具的能力边界刚好卡在这个位置上。它们已经能读写文件、执行命令、看到报错，但默认行为仍然是"你说一句它做一步"。真正拉开效率差距的，是使用者有没有能力把这个默认的"单步执行"改造成"带反馈的自动循环"。同样一个重构任务，有人手动来回对话二十轮，有人搭好循环后只下一条指令、中间去泡杯咖啡，回来时测试已经全绿。差距不在模型，在循环的设计。

这篇内容适合三类人：一是已经在用 Claude Code / Codex / Cursor，但只会单轮对话、想突破效率瓶颈的开发者；二是准备把 AI 编程引入团队工作流、需要一套可复现方法的技术负责人；三是纯粹好奇"循环工程"这个词到底指什么、想搞清楚底层机制再决定要不要投入的学习者。我会从循环的四个基本构件讲起，然后落到 Claude Code、Codex、Cursor 三个工具上分别怎么搭，再讲实战里最容易翻车的几个点，最后给一套可以直接抄的循环模板。

需要先说明一点：下面涉及的工具安装、配置、命令，都是基于这些工具公开的常规使用方式整理的，具体版本行为可能随更新变化，实操时以你本地实际输出为准。我不建议你无脑照抄命令，而是理解每一步"为什么这么做"，这样工具升级了你也能自己调整。

2. 拆开一个循环：感知、决策、执行、验证四件套

2.1 为什么"循环"比"提示词"更接近工程本质

先讲个反直觉的结论：在 AI 编程这件事上，提示词的质量上限，远低于循环结构的质量上限。很多人花大量时间打磨一句"完美提示词"，试图让模型一次输出正确代码，但真实项目里"一次就对"几乎不可能——不是模型不行，是任务本身需要跟真实环境交互才能确定对错。你不知道那个函数被谁调用、不知道数据库字段实际叫什么、不知道测试会不会因为一个边界条件挂掉。这些信息只能通过"跑一遍看结果"获得。

循环工程的核心洞察就是：把"不确定性"交给循环去消化，而不是交给提示词去预测。你不需要在提示词里穷举所有情况，你只需要设计一个循环，让工具每跑一轮就缩小一点不确定性。这跟传统软件工程里"迭代开发""测试驱动"的思路是一脉相承的，只不过执行迭代的主体从人变成了 AI 工具。

一个健康的循环包含四个构件，缺一不可：

• 感知（Perceive）：工具能读到当前的真实状态——文件内容、目录结构、git 状态、上一步命令的输出。没有感知，循环就是瞎子。
• 决策（Decide）：基于感知到的状态，决定下一步做什么。这一步是模型的主场，但你可以通过规则、约束、上下文来引导。
• 执行（Act）：真正去改文件、跑命令、装依赖。执行必须有副作用，否则循环空转。
• 验证（Verify）：拿到执行结果，判断"是否更接近目标"。验证是循环的刹车和方向盘，没有验证的循环会一路狂奔到沟里。

很多人的"循环"之所以跑不起来，就是缺了验证这一环。他们让工具改完代码就结束，从不跑测试、不做类型检查、不对比预期输出，结果工具自信满满地交付了一堆跑不起来的代码。验证不是可选项，它是循环能自动收敛的前提。

2.2 感知层：让工具"看见"正确的上下文

感知层最容易被低估。新手常犯的错是：只把要改的那个文件丢给工具，结果工具改出来的代码跟项目里其他部分风格不一致、调用了不存在的函数、忽略了项目特有的约定。原因很简单——它没看见。

正确的做法是让工具在动手前先"侦察"。以 Claude Code 为例，它本身就有读取目录、搜索文件的能力，你可以在循环的第一步明确要求它先做侦察，比如让它列出相关目录、搜索某个函数的调用点、读一下项目的配置文件。这一步不产生任何修改，纯粹是建立上下文。

这里有个实操心得：侦察范围要"够用就好"，不要贪多。我见过有人让工具把整个src目录全读一遍，结果上下文塞满了无关代码，模型注意力被稀释，改出来的东西反而更差。比较稳的做法是分两步：先让它用搜索定位到相关文件（比如搜函数名、搜路由定义），再只读这几个文件。这样上下文既完整又聚焦。

感知层还有一个关键点：把"隐式知识"显式化。项目里总有一些约定俗成的规则——命名规范、错误处理方式、日志格式——这些不会写在代码注释里，但工具必须知道。解决办法是在项目根目录放一个约定文件（Claude Code 用CLAUDE.md，Cursor 用.cursorrules或项目规则文件，Codex 用对应的配置），把这些规则写进去。循环每一轮都会自动加载它，相当于给工具装了一份"项目说明书"。

2.3 决策层：用约束代替指令

决策层是模型发挥的地方，但"让它自由发挥"往往不是最优解。更稳的做法是用约束框定决策空间。举个具体例子：你要重构一个模块，与其说"帮我重构这个模块"，不如说"把这个模块里重复的校验逻辑抽成一个函数，保持现有函数签名不变，不要引入新依赖，改完确保现有测试通过"。后面这串约束把决策空间压得很小，模型出错概率大幅下降。

约束的另一个作用是防止循环跑偏。没有约束的循环很容易"过度发挥"——你让它修一个 bug，它顺手把整个文件重写了，还引入了三个新问题。加上"只改与目标相关的行""不要动公共接口""每次修改后必须能编译"这类约束，循环就会老实很多。

还有一个技巧是给循环设"检查点"。不要让工具一口气改十个文件，而是让它改一个、验证一个、再改下一个。这样一旦某一步出错，你能立刻定位，而不是面对一堆改动不知道哪里崩了。这跟 git 的小步提交是一个道理。

2.4 执行与验证：让循环自己知道"什么时候停"

执行层没什么玄机，就是让工具真的去改文件、跑命令。真正决定循环质量的是验证层。验证手段按可靠性从高到低排：

循环能不能自动收敛，取决于你有没有一个"机器可判断"的验证信号。有测试的项目，循环可以全自动跑；没测试的项目，你至少要有类型检查或编译，否则循环就是盲跑。这也是为什么我一直建议：想认真用循环工程，先把测试补上，哪怕只补核心路径的测试。测试不是给循环用的，是给你自己省心的。

验证层还要处理"失败怎么办"。一个成熟的循环在验证失败时不是直接停，而是带着失败信息回到决策层再跑一轮。比如测试报错说某个字段为 null，循环下一轮就应该去检查这个字段的赋值逻辑。这个"失败—反馈—重试"的机制，才是循环工程真正的威力所在。但要注意设重试上限，一般 3 到 5 轮还没收敛，就该停下来人工介入，否则容易陷入死循环烧额度。

3. Claude Code 上的循环搭建：从 CLAUDE.md 到多轮自动修复

3.1 为什么 Claude Code 特别适合做循环

Claude Code 的设计取向跟纯聊天工具不一样，它天生就是"在真实项目里干活"的形态：能读写文件、能执行 shell 命令、能看命令输出、能根据输出继续行动。这意味着循环的四个构件它都原生支持，你不需要额外搭脚手架，只需要把"怎么循环"这件事用配置和指令表达清楚。

它的另一个优势是上下文管理相对克制。它不会一股脑把所有文件塞进上下文，而是按需读取，这对长循环很关键——循环跑十几轮，如果每轮都塞满无关内容，很快就会撞上上下文上限。所以用 Claude Code 搭循环，重点不在"怎么让它能干活"，而在"怎么让它干得准、停得对"。

3.2 CLAUDE.md：循环的"项目宪法"

CLAUDE.md是放在项目根目录的一个 Markdown 文件，Claude Code 每次启动都会读它。你可以把它理解成循环的"项目宪法"——所有轮次都要遵守的规则写在这里。写得好，循环质量直接上一个台阶；不写，工具每轮都要重新猜你的项目约定。

一份实用的CLAUDE.md应该包含这几块内容：

# 项目约定 ## 技术栈 - 语言：TypeScript 5.x，Node 20 - 框架：Express + Prisma - 测试：Vitest，测试文件放在 __tests__ 目录 ## 代码规范 - 所有导出函数必须有 JSDoc 注释 - 错误处理统一用 AppError 类，不要直接 throw new Error - 数据库操作必须走 repository 层，不要在 service 里直接调 Prisma ## 循环规则 - 每次修改后必须运行 `npm run typecheck` 和 `npm test` - 如果测试失败，先读失败信息再改，不要盲目重试 - 单次修改不超过 3 个文件，超过就拆成多轮 - 不要修改 package.json 里的依赖版本，除非明确要求 ## 禁止事项 - 不要删除现有测试 - 不要修改 .env 和任何密钥文件 - 不要执行 git push

这份文件的价值在于：它把"你脑子里的隐性规则"变成了"循环每轮都能读到的显式约束"。我实测下来，加了CLAUDE.md之后，工具改出来的代码风格一致性明显提升，乱改依赖、乱删测试的情况基本消失。

有个细节要注意：CLAUDE.md不要写太长。我见过有人写了上千行，结果每轮都占掉大量上下文，反而挤掉了真正需要的代码内容。控制在 100 到 200 行以内，只写"每轮都必须遵守"的规则，项目背景介绍这类东西可以放到单独文档里按需引用。

3.3 用"任务清单 + 验证命令"驱动多轮修复

Claude Code 做循环最实用的模式是：给它一个任务清单，每完成一项就跑一次验证，失败就修，修完继续下一项。这个模式比"一句话让它干完所有事"稳得多。

具体怎么操作？你可以这样下指令：

请按以下清单逐项完成，每完成一项后运行 `npm run typecheck && npm test`， 如果失败就修复直到通过，再进入下一项： 1. 在 src/repository/user.ts 里新增 findActiveUsers 方法 2. 在 src/service/user.ts 里新增 getActiveUsers 业务方法，调用上面的 repository 3. 在 src/routes/user.ts 里新增 GET /users/active 路由 4. 为以上三处各补一个测试用例 每完成一项，用一句话汇报：改了什么文件、验证结果如何。

这段指令的关键在于：把大任务拆成有依赖顺序的小项，每项都有明确的验证点。工具会一项一项做，每做完一项跑一次验证，失败就自己修。你不需要盯着，它自己会循环。实测下来，这种模式下工具很少"跑飞"，因为它每一步都被验证卡着。

这里有个经验：验证命令要选"快"的。npm test如果跑全套要三分钟，循环十几轮就是大半小时。建议在循环里只跑相关测试，比如npm test -- user，全量测试留到最后跑一次。类型检查通常很快，可以每轮都跑。

3.4 循环卡住时的排查顺序

循环跑着跑着卡住是常事，表现是：工具反复改同一个地方，测试一直不过，或者它开始"绕圈"——改 A 导致 B 挂，改 B 又导致 A 挂。这时候别急着骂模型，按下面顺序排查：

1. 看验证信号是否明确。如果测试报错信息很模糊（比如只说"断言失败"不说期望值和实际值），工具就无从下手。先让测试输出更详细的信息。
2. 看上下文是否缺失。工具反复改错，往往是它没看到某个关键文件。手动把相关文件路径告诉它，或者让它先搜索一遍。
3. 看约束是否冲突。比如你要求"不改接口"又要求"改行为"，工具就会左右为难。检查一下约束之间有没有矛盾。
4. 看是否陷入局部最优。有时候工具在一个错误方向上越走越深，这时候需要人工介入，把它拉回正轨，或者干脆回滚重来。

我踩过最典型的一个坑是：测试里用了随机数据，导致每次跑结果不一样，工具以为是自己改错了，反复调整代码去"适配"随机结果。后来把测试数据固定下来，循环立刻就通了。验证信号必须稳定可复现，这是循环能收敛的底线。

4. Codex 与 Cursor 的循环玩法：不同工具的循环侧重

4.1 Codex：把循环写进配置和脚本

Codex 的形态跟 Claude Code 略有不同，它更偏向"可配置的自动化代理"。用它搭循环，重点在配置文件和外部脚本的配合。配置文件决定了它的行为边界（能读哪些目录、能执行哪些命令、超时多久），外部脚本则负责把"多轮循环"这件事串起来。

一个常见的做法是：写一个 shell 脚本，把"调用 Codex 处理任务 → 跑验证 → 如果失败就把失败信息喂回去再调用"这个流程包起来。伪代码大概是这样：

#!/bin/bash MAX_ROUNDS=5 ROUND=0 while [ $ROUND -lt $MAX_ROUNDS ]; do ROUND=$((ROUND + 1)) echo "=== 第 $ROUND 轮 ===" # 调用 Codex 执行任务，把上一轮的失败信息作为输入 codex run --task "$TASK" --context "$LAST_ERROR" # 跑验证 if npm run typecheck && npm test; then echo "验证通过，循环结束" exit 0 else LAST_ERROR=$(npm test 2>&1 | tail -50) echo "验证失败，进入下一轮" fi done echo "达到最大轮数仍未通过，需人工介入" exit 1

这个脚本的价值在于：它把"循环"这件事从工具内部搬到了外部，你能完全控制轮数、失败处理、日志。工具升级了、行为变了，你的循环逻辑不受影响。这也是为什么我推荐用 Codex 做循环时，尽量把控制权放在脚本层，而不是全指望工具自己"聪明"。

配置层面要注意几点：一是权限范围要收窄，只给它需要读写的目录，别把整个家目录都暴露出去；二是命令白名单，只允许执行你信任的命令（比如测试、类型检查），别让它随便跑rm；三是超时设置，单轮跑太久要能自动中断，否则一个卡死的命令会让整个循环挂住。

4.2 Cursor：把循环嵌进编辑器工作流

Cursor 的定位是"AI 优先的编辑器"，它的循环玩法跟前两者不太一样——它的循环是嵌在编辑体验里的。你不太可能用它跑一个无人值守的长循环，但你可以用它做"高频小循环"：改一点、看一眼、再改一点。

Cursor 里做循环的关键是用好它的规则文件和内联指令。规则文件（项目根目录的规则配置）相当于 Cursor 版的CLAUDE.md，把项目约定写进去，它每次生成都会参考。内联指令则是在你选中一段代码后，直接在编辑器里下指令，比如"把这个函数改成异步的，并更新所有调用点"。

Cursor 循环的典型节奏是：

1. 选中要改的代码块，下一条明确的修改指令
2. 看它生成的 diff，确认没问题就接受
3. 立刻跑一下相关测试或类型检查
4. 有问题就选中出错的地方，再下一条修正指令
5. 重复直到通过

这个循环的"轮"很短，可能几十秒一轮，但胜在反馈快、可控性强。适合那种"改一处、验证一处"的精细活。它的短板是不适合"一口气改二十个文件"的大任务——那种任务还是交给 Claude Code 或 Codex 更合适。

有个 Cursor 特有的技巧：用它的多文件编辑能力做"批量小循环"。比如你要给十个文件加同一段错误处理，可以一次性选中这十个文件，下一条指令让它统一加，然后跑一次类型检查。这相当于把十个小循环合并成一个大循环，效率高很多。但前提是这十个文件的上下文足够相似，否则容易改出不一致的结果。

4.3 三个工具的循环能力对比

把三个工具放在一起看，它们的循环侧重其实很清晰：

选哪个不是非此即彼。我自己的习惯是：大任务用 Claude Code 跑自动循环，需要严格控制的批量任务用 Codex 加脚本，日常小改用 Cursor 快速迭代。三者配合，覆盖从"改一行"到"重构一个模块"的全谱系。

5. 实战：给一个真实项目加"用户活跃度统计"功能

5.1 任务拆解与循环设计

光讲原理不够，拿一个具体任务走一遍。假设有个 Express + Prisma 的项目，现在要加一个"用户活跃度统计"功能：统计最近 7 天每天有多少活跃用户（有登录行为的用户），提供一个接口返回这个数据。

这个任务如果单轮对话做，大概率会翻车——它涉及数据库查询、业务逻辑、路由、测试四层，还涉及"活跃"的定义（什么算活跃）、时区处理（按哪个时区算"天"）这些容易含糊的点。用循环做，就要先拆解：

• 第 1 轮：侦察。让工具读一下现有的 repository、service、route 结构，看看项目里类似功能是怎么写的，确认"活跃"在现有代码里有没有定义。
• 第 2 轮：写 repository 层。加一个按日期分组统计的方法。
• 第 3 轮：写 service 层。处理时区、补全业务逻辑。
• 第 4 轮：写 route 层。加接口。
• 第 5 轮：补测试。
• 第 6 轮：全量验证。

每一轮都以"验证通过"为结束条件。这个拆解的关键是按依赖顺序排：repository 是 service 的基础，service 是 route 的基础，测试最后补。顺序错了，循环就会反复返工。

5.2 第一轮侦察：别急着让工具写代码

第一轮我通常不让工具写任何代码，只让它侦察。指令可以这样下：

先不要改任何代码。请完成以下侦察任务： 1. 列出 src/repository、src/service、src/routes 三个目录下的文件 2. 找到项目里已有的"按时间分组统计"的查询，把代码贴出来 3. 搜索代码库里有没有"活跃用户"或"active"相关的定义 4. 告诉我这个项目处理日期时区用的是什么方案 侦察完给我一份简报，不要动代码。

这一轮的价值在于：它把"项目现状"变成了循环的共享上下文。后面几轮工具都会记得这些信息，改出来的代码自然就跟现有风格一致。我实测过，跳过侦察直接让它写，出来的代码经常跟项目约定对不上，返工成本远高于侦察成本。

侦察完你可能会发现一些意外情况，比如项目里"活跃"已经有定义了（可能指"最近 30 天有操作"），那你的需求就要调整。侦察轮也是需求澄清轮，很多模糊点在这一轮就暴露了。

5.3 中间轮次：每轮一个验证点

从第二轮开始，每轮做一层，每轮结束跑一次验证。以 repository 层为例：

现在实现 repository 层。要求： - 在 src/repository/user.ts 里新增 countActiveUsersByDay 方法 - 入参：startDate、endDate - 返回：{ date: string, count: number }[] - 按项目现有风格写，参考你侦察到的分组统计写法 - 不要改其他文件 写完运行 `npm run typecheck`，通过后运行 `npm test -- user`。 如果失败，读失败信息修复，直到通过。

注意这里的约束："不要改其他文件"防止它顺手改别的；"参考侦察到的写法"保证风格一致；"通过后运行测试"给了明确的验证点。这一轮跑完，repository 层就是确定可用的，后面几轮可以放心依赖它。

service 层和 route 层同理，每层一个循环，每层一个验证点。这种"分层推进"的节奏，比"一口气写完所有层再验证"稳得多——后者一旦出错，你根本不知道是哪层的问题。

5.4 收尾轮：全量验证与边界检查

最后一轮做两件事：全量验证和边界检查。全量验证就是跑完整的测试套件加类型检查，确保没有回归。边界检查则是让工具自己审视一遍实现，找出可能的边界问题：

功能已实现。现在做收尾检查： 1. 运行完整测试套件 `npm test` 和 `npm run typecheck`，确保全绿 2. 检查以下边界情况是否处理： - 查询区间内某天完全没有活跃用户，返回结果里是否包含这一天（count 为 0） - 时区边界：跨天登录的记录是否算在正确的日期 - 空区间：startDate 晚于 endDate 时的行为 3. 如果发现未处理的边界，补上并加测试

这一轮经常能抓出真问题。我实测时，工具在边界检查里发现"某天无活跃用户时结果里缺这一天"——因为 SQL 的 group by 不会为没有数据的日期生成行。这个问题在正常测试里不一定暴露，但业务上就是错的。收尾轮的价值，就是把这类"测试覆盖不到但业务在意"的问题挖出来。

6. 循环工程最容易翻车的五个点

6.1 验证信号不稳定，循环永远收敛不了

这是最致命的坑。前面提过随机测试数据的例子，类似的还有：测试依赖外部网络（时通时不通）、测试依赖执行顺序（单独跑过、一起跑挂）、测试有竞态条件（偶尔失败）。这些都会让循环"以为"自己改错了，然后疯狂调整代码去适配一个本就不稳定的信号。

解决办法：循环里用的验证必须确定性可复现。外部依赖用 mock，随机数据用固定种子，有顺序依赖的测试拆开或加隔离。跑之前先手动跑三遍，确认结果稳定，再放进循环。这一步花的时间，会在后面几十轮循环里加倍省回来。

6.2 上下文越滚越大，最后撞上限

长循环跑到后面，上下文里堆满了历史修改、失败日志、读过的文件，很快就满了。满了之后工具会开始"遗忘"早期信息，行为变得不稳定。

对策有三：一是每轮只保留必要上下文，历史失败信息只留最近一两轮的；二是把稳定信息固化到配置文件（CLAUDE.md这类），不占对话上下文；三是长任务拆成多个短循环，每个短循环独立开新会话，通过文件或 git 传递状态。我一般单次循环不超过 10 轮，超过就拆。

6.3 约束太松，工具"过度发挥"

不给约束的循环，工具很容易"顺手"做一堆你没要求的事：重构无关代码、升级依赖、改配置、删"看起来没用"的代码。这些改动单看可能没错，但会让你的 diff 变得巨大，review 成本飙升，还容易引入回归。

对策是把约束写死：明确"只改哪些文件""不要动什么""单轮改动上限"。我习惯在每轮指令里都重复一遍关键约束，哪怕配置文件里已经写了——因为长循环里工具会"忘记"，重复一遍成本很低，收益很高。

6.4 没有回滚点，改坏了没法退

循环跑飞了，你想回滚，结果发现中间改了十几个文件，git 也没提交，只能手动一个个还原。这是没设回滚点的典型后果。

正确做法：每轮验证通过后提交一次。这样任何一轮出问题，git reset回上一轮就行。提交信息写清楚这轮做了什么，方便追溯。有人担心提交太碎，其实循环里的提交本来就是"工作存档"，最后合并时可以 squash。有回滚点的循环，才敢让它自动跑。

6.5 盲目信任工具的自评

有些工具在改完后会说"我已经完成了，测试通过"。别信。永远自己跑一遍验证。工具的自评是基于它"以为"的结果，不是真实执行的结果。我见过太多次工具说"测试通过"但实际根本没跑测试，或者跑的是错的命令。验证这件事，必须由你或你的脚本亲自执行，不能外包给工具的判断。

7. 一套可以直接抄的循环模板

把上面的经验固化成一个模板，你可以在自己的项目里改改用。核心结构是"侦察—分层实现—验证—收尾"四段，每段都有明确的输入输出。

第一段：侦察（1 轮）

先不改代码。侦察以下内容并给我简报： 1. 相关目录的文件列表 2. 项目里类似功能的实现（贴代码） 3. 与本次任务相关的现有约定、类型定义 4. 处理日期/时区/错误的方式

第二段：分层实现（N 轮，每层一轮）

实现第 X 层：<具体层名>。要求： - 只改 <具体文件>，不动其他文件 - 参考侦察到的现有写法 - 保持现有接口签名不变 - 写完运行 <类型检查命令>，通过后运行 <相关测试命令> - 失败就读失败信息修复，直到通过 - 完成后一句话汇报：改了什么、验证结果

第三段：收尾检查（1 轮）

功能已实现。做收尾： 1. 跑完整测试套件和类型检查，确保全绿 2. 检查边界情况：<列出你关心的边界> 3. 发现未处理的边界就补上并加测试 4. 汇报最终状态

第四段：人工 review（你来）

循环跑完不等于任务完成。你要亲自看一遍 diff，重点看：有没有改到不该改的文件、有没有引入新依赖、边界处理是否符合业务预期、测试是不是真的覆盖了核心路径。循环负责"跑通"，你负责"跑对"。

这套模板我用了大半年，覆盖过重构、加功能、修 bug、补测试几类任务，稳定性不错。它的精髓不在指令措辞，而在结构：先侦察建立上下文，再分层小步推进，每步验证，最后收尾查边界。你把这套结构吃透，换成任何工具、任何项目都能套。

最后分享一个我踩坑踩出来的小技巧：循环开始前，先手动把项目跑一遍测试，确认"起点是绿的"。如果起点就是红的，循环会分不清"是我改坏的"还是"本来就坏的"，直接懵掉。花两分钟确认起点干净，能省掉后面一堆麻烦。这个习惯看起来不起眼，但在我用循环工程处理过的几十个任务里，它帮我避开的返工次数，一只手数不过来。