企业官网建设流程全解析

1. 先搞清楚 Loop Engineering 到底在解决什么问题

1.1 从“写代码”到“设计循环”的思维转变

大多数人第一次接触 Claude Code、Codex、Cursor 这类工具时，脑子里想的还是“我该怎么把需求描述清楚，让它一次给我生成对的代码”。这个思路在简单任务上没问题，但一旦任务复杂起来——比如重构一个模块、修一个跨文件的 bug、给项目补一套测试——你就会发现，单次对话根本搞不定。模型会漏掉上下文，会忘记之前的约束，会在第三轮对话时把你第一轮说的规范抛到脑后。

Loop Engineering 要解决的就是这个问题。它的核心思想是：不要指望一次对话解决问题，而是设计一个可重复、可收敛的循环，让 AI 在每一轮迭代中逐步逼近目标。这个循环包含几个关键要素——明确的目标定义、可验证的中间产物、反馈信号的提取、以及循环终止条件的设定。

打个比方，传统用法像是你找一个装修师傅，跟他说“帮我装个厨房”，然后指望他一次搞定。Loop Engineering 则是你先画好图纸，定好验收标准，然后让师傅先做水电、你检查、再做柜体、你再检查，每一轮都有明确的交付物和检查点。区别不在于师傅的手艺，而在于你有没有设计好这个协作流程。

这个思维转变之所以重要，是因为当前所有主流 AI 编程工具——不管是 Claude Code、Codex 还是 Cursor——本质上都是“回合制”的。你给一个输入，它给一个输出，然后等你下一步指令。它们不会自己规划一个多步骤的长期任务并持续执行。Loop Engineering 就是在这个约束下，人为地构建出一个“外循环”，把 AI 的单次能力串联成持续的生产力。

1.2 三类工具的定位差异与循环设计的关系

在展开具体实操之前，有必要先厘清 Claude Code、Codex、Cursor 这三个工具在 Loop Engineering 中的定位差异。这不是为了比较优劣，而是因为它们的交互模式不同，对应的循环设计策略也不一样。

Claude Code 是终端里的 agent 型工具，它能直接读写文件、执行命令、查看输出。这意味着你的循环可以设计得比较“重”——让它自己跑测试、自己看报错、自己改代码。它的优势在于闭环能力强，你可以在一个循环里让它完成“改代码 → 跑测试 → 看结果 → 再改”的完整链路。

Codex 更偏向于代码生成和补全，它的交互更轻量，适合在循环中承担“生成候选方案”的角色。你可以把它理解为循环中的一个“提案者”，它给出几个可能的实现方向，然后由你来筛选和验证。

Cursor 则是 IDE 内的集成体验，它的优势在于上下文感知——它能直接看到你当前打开的文件、光标位置、最近的编辑历史。这让它非常适合做“微循环”——你在写代码的过程中，它实时给出建议，你接受或拒绝，然后继续。这种循环的周期极短，可能只有几秒钟。

理解这些差异之后，你在设计循环时就能有的放矢：用 Claude Code 做重循环（跨文件重构、自动化测试修复），用 Codex 做方案生成，用 Cursor 做实时微调。三者不是互斥的，而是可以在不同粒度的循环中配合使用。

1.3 一个典型的 Loop Engineering 场景长什么样

为了让你有个具体的画面，我描述一个我自己经常用的场景：给一个已有的 Python 项目补单元测试。

传统做法是：我打开 Cursor，选中一个函数，让 AI 生成测试，然后手动检查、手动运行、手动修。这个过程重复十几次，每次都要我手动介入。

Loop Engineering 的做法是：我先写一个脚本，这个脚本做三件事——调用 Claude Code 为指定文件生成测试、运行 pytest、把失败的测试结果收集起来。然后我设计一个循环：如果测试全部通过，就进入下一个文件；如果有失败，就把失败信息喂回给 Claude Code，让它修复，再跑一遍。这个循环最多跑五轮，五轮之后如果还有失败，就停下来让我人工介入。

这个循环一旦搭好，我就可以去喝杯咖啡，回来的时候可能十个文件的测试都补完了。我需要做的只是最后 review 一遍生成的测试代码，确认没有逻辑问题。这就是 Loop Engineering 的威力——它把“我盯着 AI 干活”变成了“我设计好流程，AI 自己干活”。

2. 搭建循环前必须想清楚的几个关键决策

2.1 目标的可验证性决定了循环能不能收敛

这是最容易被忽略但最致命的一点。如果你给 AI 的目标是“把这个模块重构得更优雅”，那这个循环永远不会收敛，因为“优雅”没有客观标准。每一轮 AI 都会给你一个不同的版本，你也没法判断哪个更好。

正确的做法是把目标转化成可验证的形式。比如“把这个模块重构得让所有单元测试通过，且函数平均长度不超过 30 行，且没有循环复杂度超过 10 的函数”。这三个条件都是可以自动检查的。你的循环就可以设计成：AI 改代码 → 跑测试 → 跑静态分析 → 检查三个条件是否满足 → 不满足就把具体哪个条件没达标喂回去。

我踩过的一个坑是：早期我让 AI 优化 SQL 查询性能，目标是“让这个查询更快”。结果 AI 每轮都给我不同的索引建议，我没法判断哪个真的更快，因为我没有实际的执行计划对比。后来我改成“让这个查询的 EXPLAIN 输出中 type 列不出现 ALL，且 rows 估算值低于 1000”，循环立刻就收敛了，三轮就搞定了。

注意：可验证性不等于可自动化。有些目标你可以人工验证，但没法写成脚本。这种情况下循环的周期会变长，因为每轮都需要你介入。能自动化的尽量自动化，不能自动化的要明确标记出人工检查点。

2.2 反馈信号的质量比循环次数更重要

很多人设计循环时只关注“跑多少轮”，却忽略了每轮喂回去的反馈信号质量。如果你只是把“测试失败了”这个信息喂回去，AI 只能瞎猜哪里出了问题。但如果你把完整的报错堆栈、失败的断言、相关的代码片段都整理好喂回去，AI 的修复成功率会高很多。

我自己的做法是写一个反馈收集脚本，它做以下几件事：提取失败的测试名称和断言信息、截取报错堆栈中涉及项目代码的部分（过滤掉框架内部的堆栈）、找到失败测试对应的源文件和相关依赖、把这些信息格式化成一段结构化的文本。这段文本就是下一轮循环的输入。

这个脚本大概长这样：

import subprocess import re import json def collect_feedback(test_output): """从 pytest 输出中提取结构化反馈""" feedback = { "failed_tests": [], "error_summary": "", "relevant_files": [] } # 提取失败的测试 fail_pattern = r"FAILED ([\w/\.]+)::(\w+)" for match in re.finditer(fail_pattern, test_output): feedback["failed_tests"].append({ "file": match.group(1), "test": match.group(2) }) # 提取断言错误 assert_pattern = r"AssertionError: (.+?)(?=\n\n|\Z)" assert_match = re.search(assert_pattern, test_output, re.DOTALL) if assert_match: feedback["error_summary"] = assert_match.group(1)[:500] return feedback # 运行测试并收集反馈 result = subprocess.run( ["pytest", "-v", "--tb=short"], capture_output=True, text=True ) feedback = collect_feedback(result.stdout + result.stderr) print(json.dumps(feedback, indent=2))

这个脚本的关键在于--tb=short参数，它让 pytest 输出更简洁的堆栈信息，避免把大量框架内部代码喂给 AI 造成干扰。实测下来，用结构化反馈的修复成功率比直接贴原始输出高出不少。

2.3 循环终止条件的设计：什么时候该停

没有终止条件的循环就是死循环。你需要设定明确的停止规则，通常包括三类：

第一类是成功条件——目标达成了，循环自然结束。比如所有测试通过、静态检查无报错。

第二类是失败条件——连续 N 轮没有进展，或者错误数量在增加。这时候继续跑下去只是浪费 token，应该停下来人工介入。我一般设 N=3，也就是连续三轮错误数量没有减少就停。

第三类是预算条件——总轮次上限或总 token 消耗上限。这个是为了防止意外情况，比如某个 bug 导致 AI 陷入某种奇怪的循环，每轮都在做微小改动但永远不收敛。我一般设总轮次上限为 10 轮。

这三类条件要同时设置，任何一个触发就停止。停止之后不是直接放弃，而是把当前状态、已经尝试过的方案、失败的原因整理成一份报告，方便你人工分析。

3. 从零搭建一个可复用的 Loop Engineering 工作流

3.1 环境准备与工具链配置

在开始搭循环之前，你需要确保基础环境是通的。这里我假设你用的是 macOS 或 Linux，Windows 用户建议用 WSL2，因为很多命令行工具在原生 Windows 上会有兼容性问题。

首先是 Claude Code 的安装。它目前主要通过 npm 分发：

# 确保 Node.js 版本在 18 以上 node --version # 全局安装 npm install -g @anthropic-ai/claude-code # 验证安装 claude --version

安装完成后，你需要在项目目录下初始化配置。Claude Code 会读取项目根目录的CLAUDE.md文件作为项目级指令，这个文件非常重要，它相当于你给 AI 的“项目说明书”。我通常会在里面写清楚：项目用什么语言和框架、代码风格要求、测试怎么跑、有哪些禁止修改的文件。

# 项目指令 ## 技术栈 - Python 3.11 + FastAPI - 测试框架：pytest - 代码风格：black + isort ## 常用命令 - 跑测试：`pytest -v --tb=short` - 格式化：`black . && isort .` - 类型检查：`mypy src/` ## 约束 - 不要修改 `migrations/` 目录下的文件 - 所有新函数必须有类型注解 - 测试文件放在 `tests/` 目录，命名规则 `test_*.py`

Codex 的配置类似，它读取的是codex.md或项目根目录的.codex配置。Cursor 则是在 IDE 设置里配置项目规则，也可以通过.cursorrules文件来定义。

这里有个实操心得：三个工具的配置文件内容尽量保持一致。这样你在不同工具之间切换时，AI 的行为不会有太大差异。我自己的做法是维护一个ai-instructions.md作为单一事实来源，然后用软链接或脚本同步到各个工具对应的配置文件。

3.2 设计循环的骨架：一个可复用的脚本模板

下面是我自己用的循环脚本模板，用 Python 写的，你可以直接拿去改。它的核心逻辑是：读任务列表 → 对每个任务执行循环 → 每轮收集反馈 → 判断是否继续 → 输出报告。

import subprocess import json import time from pathlib import Path from dataclasses import dataclass, field @dataclass class LoopState: task: str max_rounds: int = 10 max_stale_rounds: int = 3 current_round: int = 0 stale_count: int = 0 last_error_count: int = 999 history: list = field(default_factory=list) def run_claude_code(prompt: str, project_dir: str) -> str: """调用 Claude Code 执行任务""" result = subprocess.run( ["claude", "-p", prompt, "--output-format", "text"], capture_output=True, text=True, cwd=project_dir, timeout=300 ) return result.stdout def run_tests(project_dir: str) -> tuple: """运行测试，返回 (是否通过, 错误数量, 输出)""" result = subprocess.run( ["pytest", "-v", "--tb=short", "-q"], capture_output=True, text=True, cwd=project_dir ) output = result.stdout + result.stderr passed = result.returncode == 0 # 统计失败数量 import re fail_count = len(re.findall(r"FAILED", output)) return passed, fail_count, output def build_fix_prompt(task: str, test_output: str, history: list) -> str: """构建修复提示词""" # 截取关键错误信息 error_section = test_output[-3000:] if len(test_output) > 3000 else test_output # 整理历史尝试 history_summary = "" if history: history_summary = "\n\n之前尝试过的方案（避免重复）：\n" for i, h in enumerate(history[-3:], 1): history_summary += f"{i}. {h['action'][:200]}\n" prompt = f"""当前任务：{task} 测试输出如下：

{error_section}

{history_summary} 请分析失败原因并修复代码。只修改必要的文件，不要做无关改动。 修复后简要说明你改了什么。""" return prompt def run_loop(task: str, project_dir: str): """执行主循环""" state = LoopState(task=task) while state.current_round < state.max_rounds: state.current_round += 1 print(f"\n=== 第 {state.current_round} 轮 ===") # 第一轮直接执行任务，后续轮次修复 if state.current_round == 1: prompt = f"请完成以下任务：{task}\n\n完成后运行测试验证。" else: passed, _, output = run_tests(project_dir) prompt = build_fix_prompt(task, output, state.history) # 调用 AI response = run_claude_code(prompt, project_dir) state.history.append({"action": response, "round": state.current_round}) # 验证结果 passed, error_count, output = run_tests(project_dir) if passed: print(f"任务完成！共用了 {state.current_round} 轮") return True # 检查是否有进展 if error_count >= state.last_error_count: state.stale_count += 1 print(f"无进展，连续 {state.stale_count} 轮") else: state.stale_count = 0 state.last_error_count = error_count if state.stale_count >= state.max_stale_rounds: print(f"连续 {state.max_stale_rounds} 轮无进展，停止") break print(f"循环结束，任务未完成。当前错误数：{state.last_error_count}") return False if __name__ == "__main__": import sys task = sys.argv[1] if len(sys.argv) > 1 else "修复所有失败的测试" project_dir = sys.argv[2] if len(sys.argv) > 2 else "." run_loop(task, project_dir)

这个脚本的关键设计点有几个：max_stale_rounds防止在同一个错误上反复挣扎；history记录之前的尝试，避免 AI 重复同样的错误方案；build_fix_prompt里只截取最后 3000 字符的输出，避免 prompt 过长导致关键信息被稀释。

3.3 提示词工程在循环中的特殊考量

在单次对话中，提示词的质量影响的是单次输出的质量。但在循环中，提示词的质量影响的是整个循环的收敛速度。这是因为每一轮的提示词都建立在前一轮的结果之上，如果某一轮的提示词有歧义，AI 可能会往错误的方向走，后续几轮都在纠正这个错误。

我在循环中用的提示词有几个固定模式。第一个是“约束前置”——把最重要的约束放在提示词最前面，因为模型对开头和结尾的内容注意力最高。比如“不要修改测试文件”这个约束，如果放在中间，AI 经常忽略；放在第一行，遵守率明显提高。

第二个是“失败聚焦”——不要笼统地说“修复问题”，而是明确指出“第 3 个测试失败了，断言是 X，期望 Y 实际 Z”。信息越具体，AI 的修复越精准。

第三个是“变更说明”——要求 AI 在修改后简要说明改了什么。这个说明会进入下一轮的历史记录，帮助 AI 避免重复尝试。实测下来，加了变更说明之后，循环的平均轮次从 6 轮降到了 4 轮左右。

提示：如果你的循环涉及多个文件，建议在提示词里明确列出允许修改的文件列表。不加限制的话，AI 有时候会“顺手”改一些不相关的文件，导致循环的变更范围失控。

4. 实战：用 Loop Engineering 完成一个真实的重构任务

4.1 任务定义与验收标准

我拿一个真实的小项目来演示。这个项目是一个 Flask 写的短链接服务，代码能跑，但结构比较乱——所有逻辑都堆在app.py里，没有分层，没有测试。我的重构目标是：

1. 把路由、业务逻辑、数据访问分成三层
2. 给业务逻辑层补单元测试，覆盖率不低于 80%
3. 所有测试通过
4. 不改变对外 API 的行为

这四个条件里，第 1 条和第 4 条需要人工判断，第 2 条和第 3 条可以自动验证。所以我的循环设计是：自动循环负责第 2、3 条，每完成一个模块的重构后暂停，让我人工检查第 1、4 条。

验收标准我写成了一个 checklist：

## 重构验收清单 ### 自动验证 - [ ] pytest 全部通过 - [ ] 业务逻辑层覆盖率 >= 80% - [ ] 无 import 错误 - [ ] black 格式化无变更 ### 人工验证 - [ ] 路由层只负责请求解析和响应构造 - [ ] 业务逻辑层不直接操作数据库 - [ ] 数据访问层不包含业务判断 - [ ] API 响应格式与重构前一致

这个 checklist 就是循环的“目标函数”。每一轮循环结束后，自动验证部分由脚本检查，人工验证部分由我快速过一遍。

4.2 第一轮：让 AI 理解现状并制定计划

第一轮不要直接让 AI 改代码，而是让它先分析现状、输出重构计划。这一步很多人会跳过，觉得浪费时间，但实际上它能大幅提高后续循环的效率。因为 AI 在分析阶段会读取所有相关文件，建立起对项目的整体理解，这个理解会保留在后续轮次的上下文中。

我的第一轮提示词是这样的：

请分析当前项目的代码结构，输出一份重构计划。 要求： 1. 列出当前所有函数及其职责 2. 指出哪些函数承担了多个职责，需要拆分 3. 提出三层架构的具体划分方案 4. 给出重构的步骤顺序，说明为什么按这个顺序 不要修改任何代码，只输出分析结果。

Claude Code 跑完这一轮后，输出了一份挺详细的分析。它识别出app.py里有 12 个函数，其中create_shortlink这个函数同时做了参数校验、生成短码、写数据库、返回响应四件事。它建议的拆分顺序是：先抽数据访问层（因为最独立），再抽业务逻辑层，最后整理路由层。

这个顺序是合理的，因为数据访问层的接口一旦定下来，业务逻辑层就可以基于这些接口来写，最后路由层只是调用业务逻辑层。如果顺序反过来，先改路由层，那业务逻辑层的接口还没定，路由层改了也白改。

4.3 第二到第五轮：逐层重构的循环执行

第二轮开始，我让循环自动执行数据访问层的抽取。提示词是：

根据之前的重构计划，现在执行第一步：抽取数据访问层。 要求： 1. 创建 `data/` 目录，把所有数据库操作移进去 2. 每个数据库操作封装成一个函数，函数名要体现操作意图 3. 保持原有的数据库连接方式不变 4. 修改 `app.py` 中的调用，改为调用新的数据访问函数 5. 修改后运行 `pytest` 确认没有引入错误 只修改必要的文件。

这一轮跑完，Claude Code 创建了data/shortlink_repo.py，把 4 个数据库操作抽了出来。但跑测试的时候发现有两个测试失败了，因为原来的测试直接 mock 了app.py里的数据库调用，现在调用路径变了，mock 失效了。

这就是循环的价值所在——如果没有自动跑测试，这个问题可能要等到最后才发现。循环自动捕获了失败，并在第三轮把失败信息喂回去，让 AI 修复了测试的 mock 路径。

第三到第五轮类似，分别抽取了业务逻辑层、整理了路由层、补了单元测试。每一轮都是“AI 改代码 → 跑测试 → 失败则修复 → 再跑”的循环。到第五轮结束时，所有自动验证项都通过了。

这里有个细节值得说：在补单元测试的那一轮，我特意在提示词里加了“每个测试只测一个行为，测试名要描述被测行为”。不加这个约束的话，AI 倾向于写那种一个测试里塞很多断言的“大测试”，这种测试失败了很难定位问题。

4.4 人工检查点的设置与执行

自动循环跑完后，我花大概十五分钟做了人工检查。检查的内容就是之前 checklist 里的人工验证项。我发现了一个问题：业务逻辑层的一个函数里直接用了request对象来获取当前用户，这违反了“业务逻辑层不依赖 Web 框架”的原则。

这个问题自动检查发现不了，因为代码能跑、测试能过。但它是一个架构层面的隐患——如果以后要把业务逻辑复用到 CLI 工具里，这个request依赖就会出问题。

我把这个问题记录下来，然后开了一轮“定向修复”循环，提示词是：

业务逻辑层的 `create_link` 函数直接使用了 Flask 的 `request` 对象， 这违反了分层原则。请把用户信息的获取移到路由层，通过参数传给业务逻辑层。 修改后确保所有测试仍然通过。

这一轮跑完，问题解决了。整个重构任务从开始到结束，自动循环跑了 6 轮，人工介入 2 次，总共花了大概两个小时。如果纯手工做，我估计要一整天。

5. 循环跑不起来时的排查思路

5.1 常见失败模式与对应解法

循环跑不起来有很多种原因，我整理了一个排查表，按出现频率排序：

这个表里最值得说的是“错误数来回波动”这一行。我遇到过好几次这种情况：AI 第一轮修了 A 问题但引入了 B 问题，第二轮修了 B 问题但 A 问题又回来了。这是因为 AI 没有记住之前的尝试，在同一个坑里反复横跳。

解法是在提示词里加入历史尝试的摘要，明确告诉它“你之前试过 X 方案，导致了 Y 问题，不要再试”。这个改动之后，波动问题基本消失了。

5.2 反馈信号提取的实操技巧

反馈信号的质量直接决定循环效率。我总结了几个提取技巧：

第一，过滤噪音。测试输出里有很多无关信息，比如框架的启动日志、警告信息、通过的测试列表。这些都要过滤掉，只保留失败相关的部分。我的做法是用--tb=short减少堆栈长度，用-q减少输出量，然后用正则提取关键部分。

第二，保留上下文。光有报错信息不够，还要保留报错位置前后的代码。我一般会提取报错文件的相关函数完整代码，附在反馈里。这样 AI 不用再去读文件，直接就能看到问题所在。

第三，结构化格式。不要直接把原始输出贴给 AI，而是整理成结构化的格式。比如：

失败测试：test_create_link_duplicate 失败位置：tests/test_business.py:45 断言：assert response.status_code == 409 实际结果：500 相关代码： ```python def create_link(url, user_id): # ... 省略 ... existing = repo.find_by_url(url) if existing: return {"error": "duplicate"}, 409 # ... 省略 ...

这种格式比原始输出清晰得多，AI 能快速定位问题。 ### 5.3 循环效率的优化经验 跑了一段时间之后，我总结出几个提升循环效率的经验： **批量处理相似任务**。如果你有十个文件要补测试，不要一个文件跑一个循环，而是把十个文件放在一个循环里，每轮处理一个。这样 AI 在循环中积累的上下文可以复用，后面的文件处理速度会更快。 **预热上下文**。在循环开始前，先让 AI 读一遍项目的关键文件（README、主要源文件、测试文件），把理解建立起来。这个预热步骤大概花一轮的时间，但能让后续每一轮都更精准。 **控制单轮变更量**。一轮里让 AI 改太多东西，出错了很难定位是哪个改动导致的。我一般控制单轮变更在 50 行以内，超过的话就拆成多轮。 **善用缓存**。Claude Code 和 Codex 都支持 prompt 缓存，相同的上下文部分不会重复计费。所以在循环中保持系统提示词和项目上下文不变，只改变任务相关的部分，能显著降低成本。 ## 6. 把循环思维扩展到日常开发 ### 6.1 从“用工具”到“设计流程”的升级 Loop Engineering 的价值不只在于完成某个具体任务，更在于它改变了你和 AI 协作的方式。当你习惯了设计循环之后，你会发现自己开始用“流程”的视角来看待所有重复性的开发工作。 比如 code review。以前我是一段一段看，看到问题就提。现在我设计一个循环：让 AI 先扫一遍代码，列出所有可疑点；我筛选出真正的问题；让 AI 针对每个问题给出修复建议；我确认后让它改。这个循环跑下来，review 的效率提高了不少，而且不容易漏掉问题。 再比如写文档。以前是手动写，现在设计一个循环：AI 读代码生成初稿 → 我标注不准确的地方 → AI 修改 → 我再检查。循环几轮之后，文档质量就上来了。 这种思维转变的核心是：**把 AI 看作循环中的一个环节，而不是一个独立的工具**。你设计的是整个流程，AI 只是其中负责某类工作的一个节点。 ### 6.2 循环的边界：什么时候不该用 Loop Engineering 不是万能的。有些场景下，设计循环的成本比直接手动做还高。我总结了几条判断标准： 任务只做一次，且不复杂——直接手动做，别设计循环。设计循环本身要花时间，如果任务本身只要十分钟，设计循环要半小时，那就不划算。 目标无法验证——比如“让代码更可读”，这种没有客观标准的目标，循环没法收敛。这种任务适合单次对话，你看着结果判断。 需要创造性决策——比如“设计一个新的架构”，这种任务需要人的判断，循环只能辅助，不能主导。 涉及外部依赖——比如“修复生产环境的 bug”，这种任务的风险太高，不适合让 AI 自动循环，必须人工逐步确认。 我自己的原则是：**重复性高、可验证、低风险的任务用循环；一次性、主观性强、高风险的任务用单次对话**。 ### 6.3 后续可以怎么扩展这套方法 这套循环框架搭好之后，可以往几个方向扩展。 第一个方向是**多工具协同**。现在的循环主要用 Claude Code 跑，但你可以设计一个更复杂的循环：Codex 生成候选方案 → Claude Code 实现 → Cursor 做实时检查。三个工具各司其职，形成一个更完整的流水线。 第二个方向是**循环的嵌套**。大循环里套小循环。比如外层循环负责“完成整个模块的重构”，内层循环负责“修复当前这个测试”。内层循环收敛后，外层循环继续。 第三个方向是**循环的持久化**。把循环的状态存到文件里，这样即使中途中断，下次可以从中断点继续。这对于长时间运行的循环特别有用。 第四个方向是**循环的监控**。加一个简单的 dashboard，实时显示当前轮次、错误数变化、token 消耗。这样你能直观地看到循环是在收敛还是在发散。 我自己目前用到第二个方向比较多，嵌套循环在处理复杂任务时确实更灵活。第三个方向还在摸索，主要是状态序列化和恢复的逻辑比较繁琐，但一旦做好，对于跨天的大任务会很有帮助。 最后分享一个我踩过的坑：**不要在循环里让 AI 自己决定什么时候停**。我早期试过在提示词里写“如果你觉得任务完成了就输出 DONE”，结果 AI 经常在任务没完成时就输出 DONE，或者在任务完成后还在继续改。终止条件必须由外部脚本判断，不能交给 AI 自己判断。这个教训让我在后续所有循环里都坚持用客观的验证条件来控制终止。