1. 从“写提示词”到“搭循环”Loop Engineering 到底在解决什么问题大多数人接触 AI 编程工具第一步都是学怎么写提示词。你花半小时打磨一段描述把需求、约束、示例全塞进去然后回车等结果。一次不满意改几个字再试。这个模式在单轮任务里够用但一旦任务变成“给整个项目加一层缓存”“把二十个接口的错误处理统一重构”“把测试覆盖率从 40% 拉到 80%”单轮提示词就彻底不够看了。原因很直接这类任务的完成路径不是线性的。你需要先让工具理解现状再让它提出方案然后执行一部分检查结果发现偏差调整方向再执行下一部分。这个“理解—执行—检查—调整”的往复过程就是循环。Loop Engineering 这个说法本质上就是把注意力从“怎么把一句话写好”转移到“怎么设计一个能自己转起来的循环”。我自己的体会是提示词工程解决的是“单次沟通质量”循环工程解决的是“多轮任务收敛”。前者像你跟装修师傅说清楚你要什么风格后者像你设计一套施工流程让师傅每天干完活能自己对照图纸检查发现问题能自己返工而不是每贴一块砖都来问你。这个区别在 Claude Code、Codex、Cursor 这类工具上体现得特别明显。它们都支持多轮对话但“支持多轮”和“能跑循环”是两回事。多轮是你手动一轮一轮喂循环是你设计好触发条件、检查标准、退出机制让工具在给定边界内自己迭代。前者你累后者你省心但前期设计要到位。这篇内容适合两类人一类是已经用过这些工具、但每次复杂任务都要盯着屏幕手动救火的另一类是刚开始接触、想一开始就建立正确工作方式的。我会把循环设计的核心要素拆开讲然后给一套可以直接套用的实战流程最后说几个我踩过的坑。2. 循环工程的四个核心构件触发、执行、校验、退出2.1 触发条件什么信号让循环开始转循环不能凭空启动得有个明确的触发信号。在 AI 编程工具的场景里触发条件通常有三类。第一类是任务描述触发。你给出一段任务说明工具解析后判断需要进入多轮执行。比如你说“把这个模块的所有同步调用改成异步”工具识别到这是一个批量改造任务自动进入循环模式。Claude Code 在这块做得比较自然它会在执行前先列一个待办清单然后逐项推进。第二类是文件变更触发。你改了一个核心文件工具检测到变更后自动运行相关检查。这个在 Cursor 里可以通过配置实现比如保存时触发 lint 和类型检查检查不通过就进入修复循环。第三类是定时或手动触发。比如你设定每完成一个功能点就跑一次测试测试不过就回到修复步骤。这个更接近传统 CI 的思路只不过执行者从脚本变成了 AI。我建议新手从第一类开始因为它的边界最清晰。你给一个明确任务工具跑完就停不会无限循环。等熟悉了再尝试后两类。2.2 执行单元每一轮循环到底做什么执行单元是循环的“身体”。设计得不好循环就会变成空转。一个好的执行单元应该满足三个条件目标单一、可验证、有明确产出。目标单一的意思是一轮循环只做一件事。比如“给这个函数加参数校验”是一件事“给这个函数加参数校验并补充单元测试并更新文档”就是三件事。后者应该拆成三轮。我见过太多人把一堆任务塞进一轮结果工具做了一半就迷失了你还得手动拆开重来。可验证的意思是执行结果能被客观判断。比如“代码能编译通过”是可验证的“代码写得好”是不可验证的。循环工程里所有校验标准都必须是机器能判断的否则循环就没法自动收敛。有明确产出的意思是每轮循环结束后要么代码变了要么生成了报告要么更新了状态。如果一轮跑完什么都没变那这轮就是无效循环需要检查触发条件或执行单元的设计。2.3 校验机制怎么判断这一轮做对了校验是循环的“眼睛”。没有校验的循环就是盲目迭代跑一百轮也是白跑。校验机制分三个层次。最基础的是语法和编译校验。代码能不能通过解析能不能编译这是底线。Claude Code 和 Codex 在执行完代码修改后通常会自动跑一次编译或语法检查不通过就自己修。中间层是测试校验。单元测试、集成测试跑一遍看通过率。这个层次能发现逻辑错误但前提是你得有测试。很多项目测试覆盖不全这时候循环的校验能力就打折扣了。最高层是行为校验。比如你改了一个接口实际调用一下看返回是否符合预期。这个层次最接近真实需求但实现成本也最高。我的做法是关键路径用行为校验非关键路径用测试校验兜底。注意校验标准一定要在循环开始前就定好不能边跑边改。我吃过这个亏一开始说“测试通过就行”跑了几轮发现测试太松又临时加标准结果前面几轮的产出全部要重新评估浪费了大量时间。2.4 退出条件什么时候停下来退出条件是循环的“刹车”。没有退出条件的循环就是死循环轻则烧 token重则把代码改得面目全非。常见的退出条件有四种。第一种是目标达成比如所有测试通过、所有待办项完成。第二种是达到最大轮次比如设定最多跑十轮跑完就停不管有没有完成。第三种是连续无进展比如连续三轮校验结果没有改善说明当前策略走不通需要人工介入。第四种是遇到不可恢复错误比如依赖缺失、权限不足这种继续跑也没用。我的经验是至少同时设置两种退出条件。目标达成是理想情况最大轮次是兜底。连续无进展这个条件特别有用它能帮你发现“工具在瞎忙”的情况。有一次我让工具优化一段查询逻辑它跑了六轮每轮都说“已优化”但性能测试结果纹丝不动。后来我加了连续无进展检测第三轮就停了省了大量时间。3. 在 Claude Code 里搭一个最小可用循环3.1 环境准备安装与基础配置Claude Code 的安装方式取决于你的系统。在 macOS 和 Linux 上通常通过包管理器安装在 Windows 上可以用官方提供的安装包或者通过 WSL 运行。安装完成后第一次运行需要完成认证配置。配置环节有几个容易忽略的点。第一是工作目录Claude Code 默认在当前目录下工作如果你在错误的目录启动它会去改错误的文件。我习惯在项目根目录启动并且启动前先确认一下当前路径。第二是权限设置默认情况下工具会询问是否允许执行某些操作如果你在跑循环频繁的询问会打断流程。可以在配置里预设允许的操作范围但要注意别放得太宽否则工具可能改到你不想改的地方。第三是模型选择。不同模型在代码任务上的表现差异明显复杂重构任务建议用能力更强的模型简单任务可以用轻量模型省成本。这个在配置文件里可以切换。3.2 任务拆解把大目标切成循环能吃的粒度Claude Code 支持直接给一个复杂任务它会自己拆解。但我的建议是你自己先拆一遍。原因很简单工具拆解的逻辑你不一定认同等它拆完再调整成本比你自己拆高。拆解的原则是“一轮一个可验证单元”。比如“给用户模块加缓存”这个任务我会拆成第一轮分析现有用户模块的查询热点输出一份热点列表第二轮针对排名第一的热点加缓存跑测试第三轮针对排名第二的热点加缓存跑测试以此类推。每一轮的任务描述里我会明确写清楚这一轮的目标是什么、产出是什么、怎么验证。比如第二轮我会写“给 getUserById 方法加一层内存缓存缓存过期时间 5 分钟加完后跑 UserServiceTest确保所有用例通过”。3.3 循环脚本用自然语言描述迭代逻辑Claude Code 本身没有“循环脚本”这个概念但你可以用自然语言把循环逻辑描述给它。比如你可以说“接下来你要重复执行以下流程直到所有热点都处理完选择一个未处理的热点加缓存跑测试如果测试不通过就修复直到通过然后标记该热点为已处理继续下一个。”这段话里包含了触发条件有未处理热点、执行单元加缓存跑测试、校验机制测试通过、退出条件所有热点处理完。工具会按照这个逻辑一轮一轮跑。实测下来这种自然语言循环描述在 Claude Code 上效果不错但有两个前提。第一是任务边界要清晰别让它自己判断“哪些算热点”你最好先给它一个明确列表。第二是每轮的产出要落盘比如让它把处理进度写到一个 markdown 文件里这样即使中途中断下次也能接着跑。3.4 中断与恢复循环跑一半挂了怎么办循环跑到一半中断是常事可能是网络问题可能是工具自己卡住了也可能是你手动停了。关键是中断后能恢复。我的做法是让工具在每轮结束时更新一个进度文件记录哪些做完了、哪些没做、当前卡在哪里。恢复的时候先让它读这个文件然后从断点继续。这个习惯看起来麻烦但能省掉大量重复劳动。还有一个技巧是分阶段提交。每完成一个逻辑单元就提交一次代码这样即使后面跑崩了前面的成果不会丢。Claude Code 可以配置成每轮结束后自动提交提交信息由它生成。我一般会检查一下提交信息是否准确不准确就手动改。4. Codex 与 Cursor 的循环能力对比与组合用法4.1 Codex 的循环特点强在代码生成弱在状态保持Codex 在单轮代码生成上表现很强给它一个明确的函数签名和需求描述它能写出质量不错的实现。但在多轮循环上它的状态保持能力相对弱一些。所谓状态保持就是它能不能记住前几轮做了什么、当前进度到哪了。我的应对方式是外部化状态。不让 Codex 自己记而是把状态写到一个文件里每轮开始前让它先读这个文件。比如我做一个数据迁移任务会建一个 progress.md里面列出所有待迁移的表每迁完一张就打个勾。下一轮开始前我让 Codex 先读这个文件它就知道该迁哪张了。Codex 的另一个特点是对配置文件的依赖比较强。它的行为很大程度上受配置文件影响配置文件写得好循环就顺写得模糊循环就容易跑偏。我建议花时间把配置文件里的任务描述、约束条件、输出格式都写清楚。4.2 Cursor 的循环优势编辑器集成带来的实时反馈Cursor 最大的优势是它深度集成在编辑器里能实时看到代码变化。这个特性在循环场景下特别有用因为你可以随时打断、随时调整。Cursor 的循环通常通过两种方式实现。一种是对话式循环你在聊天窗口里描述任务它执行你看结果不满意就继续对话。这种方式灵活但需要你盯着。另一种是规则式循环你配置一些规则比如保存时自动跑 lint、提交前自动跑测试它按规则执行。这种方式省心但前期配置麻烦。我自己的用法是混合大任务用对话式边做边看小任务用规则式配好就不管了。Cursor 的中文设置也值得一提如果你习惯中文界面可以在设置里把语言改成中文这样菜单和提示都是中文的对新手友好很多。4.3 三者组合什么场景用哪个工具这三个工具不是互斥的可以组合用。我的分工是这样的。探索性任务用 Cursor。比如我不确定一个重构该怎么下手先在 Cursor 里跟它聊几轮让它给几个方案我选一个。这个阶段不需要严格循环需要的是快速试错。批量执行任务用 Claude Code。方案定了要批量改几十个文件用 Claude Code 跑循环。它的任务拆解和进度管理比较成熟适合这种重复性工作。单点生成任务用 Codex。比如我需要一个特定算法的实现直接把需求给 Codex它生成我检查。这种任务不需要循环一轮就够。组合用的关键是状态传递。在 Cursor 里探索出的方案要能带到 Claude Code 里执行。我的做法是把方案写成一份 markdown 文档包含任务列表、每项的标准、验证方式然后让 Claude Code 读这份文档来跑循环。5. 循环跑偏的典型症状与排查路径5.1 症状一每轮都说“已完成”但实际没变化这是最常见的跑偏症状。工具每轮结束都报告“任务已完成”但你一看代码跟上一轮一模一样。排查路径是这样的。第一步检查校验机制是否真的在跑。有时候工具说“测试通过”但实际上它根本没跑测试只是根据代码内容推测应该能通过。你可以在任务描述里明确要求它输出测试命令和实际输出这样就能确认。第二步检查执行单元是否太模糊。如果任务描述是“优化这段代码”工具可能觉得改个变量名也算优化。改成“把这段代码的时间复杂度从 O(n²) 降到 O(n)”它就有明确目标了。第三步检查是否有隐藏的阻塞。有时候工具想改但改不了比如文件被锁定、依赖缺失它可能不报错但也不执行。让它输出每轮的具体操作日志就能发现这类问题。5.2 症状二循环停不下来一直跑工具一直跑不退出token 哗哗烧。这个症状通常是因为退出条件没设好。先检查最大轮次有没有设。如果没设工具可能觉得任务永远没完成一直跑。设一个合理的上限比如十轮或二十轮。再检查目标达成条件是否可达。有时候你设的条件本身就不可能满足比如要求“所有测试通过”但有一个测试本来就是坏的。工具会一直尝试修复那个坏测试修不好就继续试。这种情况要么先修好那个测试要么把条件改成“除已知失败用例外全部通过”。最后检查连续无进展检测有没有开。如果工具连续几轮做同样的事、得到同样的结果说明它卡住了需要人工介入。这个检测能帮你及时止损。5.3 症状三改着改着把无关代码也改了工具在修复一个 bug 的过程中顺手把旁边的代码也“优化”了结果引入了新问题。这个症状的根源是任务边界不清晰。应对方式是明确限定修改范围。在任务描述里写清楚“只修改 X 文件里的 Y 函数不要动其他文件”。如果工具需要跨文件修改让它先列出要改的文件清单你确认后再动手。还有一个技巧是用版本控制兜底。每轮开始前提交一次如果这轮改坏了直接回滚。Claude Code 和 Cursor 都支持跟 git 集成可以配置成每轮自动提交。5.4 症状四循环结果不稳定同样任务两次跑结果不一样这个症状在涉及代码生成的循环里很常见。同样的任务今天跑和明天跑结果可能不同。原因是生成过程有随机性。应对方式有两个。一是固定随机种子如果工具支持的话。二是把关键决策固化。比如不要让工具自己决定“用哪种缓存策略”你在任务描述里直接指定“用 LRU 缓存容量 1000”。决策越少结果越稳定。我的经验是对于需要稳定复现的任务尽量把工具的自由度压低。让它做执行别让它做决策。决策你来定执行它来跑。6. 让循环真正省心的几个实操习惯6.1 进度文件循环的“记忆”进度文件是我用得最多的技巧。格式很简单就是一个 markdown 列表每项前面有个复选框。工具每完成一项就打个勾没完成的不打。下一轮开始前先读这个文件找到第一个没打勾的项从那里继续。这个文件的好处是不管循环因为什么原因中断恢复的时候都有据可查。而且你能随时打开文件看一眼进度不用去翻聊天记录。我一般会把进度文件放在项目根目录命名成 PROGRESS.md。内容除了任务列表还会记录每轮的关键决策和遇到的问题。这样即使换一个工具来跑它读了这个文件也能接上。6.2 小步提交每轮一个 commit每轮循环结束后提交一次代码提交信息写清楚这轮做了什么。这样做有三个好处。第一出问题能快速回滚到上一个正常状态。第二能清晰看到每轮的变更方便 review。第三如果循环跑崩了前面的成果不会丢。提交信息我一般让工具生成但会检查一遍。好的提交信息应该说明“做了什么”和“为什么”而不只是“修改了文件”。6.3 人工检查点别让循环完全无人值守虽然叫循环工程但完全不看是不行的。我习惯在几个关键节点设人工检查点。比如任务拆解完成后检查一遍确认拆得合理第一轮跑完后检查一遍确认方向对中间每隔几轮抽查一次确认没有跑偏。这些检查点花不了多少时间但能避免大方向错误。我见过有人让循环跑了一晚上第二天发现方向从一开始就错了全部白跑。这种损失完全可以避免。6.4 成本控制循环的 token 消耗怎么管循环跑起来 token 消耗是单轮的好几倍。控制成本有几个办法。一是用轻量模型跑简单轮次只在复杂轮次用强模型。二是压缩上下文每轮只传必要的信息不要把整个对话历史都带上。三是设最大轮次防止无限跑。我一般会先估算一下任务大概需要多少轮然后设一个比估算多 50% 的上限。比如估计要跑十轮就设十五轮上限。这样既给了容错空间又不会无限跑。7. 从单次提示到循环思维一个实际重构案例的完整复盘7.1 任务背景与初始方案我接手过一个老项目里面有个订单查询模块代码写得很乱一个方法三百多行嵌套了七八层 if-else查询逻辑和业务逻辑混在一起。我的目标是把它重构成清晰的分层结构查询归查询业务归业务。初始方案很简单把代码贴给工具说“帮我重构这段代码”。结果工具给了一版重构后的代码确实比原来清晰但有几个问题。第一它改了一些业务逻辑的细节我没注意到后来测试才发现。第二它只重构了这一个方法但同样的模式在项目里还有十几处。第三重构后的代码没有测试覆盖我不敢直接上线。这次尝试让我意识到单次提示搞不定这种任务。需要循环。7.2 循环设计拆成可验证的小步骤我重新设计了流程。第一步让工具扫描整个项目找出所有类似模式的代码输出一份清单。第二步针对清单里的每一项让工具先写测试测试要覆盖现有行为。第三步跑测试确认测试通过说明测试确实捕捉到了现有行为。第四步重构代码。第五步再跑测试确认重构没有改变行为。第六步标记该项完成继续下一项。这个流程里测试是核心。没有测试重构就没有安全网。所以我花了不少时间在第二步确保测试质量。有些地方现有代码行为不明确我就让工具先分析代码逻辑推断出预期行为再写测试。7.3 执行过程中的三次调整第一次调整是在扫描阶段。工具最初找出了二十多处但我一看有些是误报有些是重复的。我让它重新扫描加了更精确的匹配条件最后确定是十四处。第二次调整是在测试阶段。有几处代码的现有行为本身就是 bug测试写出来是“验证 bug 存在”。这种测试没有意义。我让工具把这些地方标记出来先修 bug 再重构。修 bug 的过程也走了一遍循环。第三次调整是在重构阶段。工具重构完第一处后我发现它的重构风格跟我预期的不一样。我给了它一个示例说明我希望的重构后结构它后面就按这个风格来了。这个调整很关键如果不及时纠正十四处都会按错误风格重构。7.4 最终结果与时间账十四处全部重构完总共跑了大概四十轮循环。其中扫描两轮写测试十四轮跑测试十四轮重构十四轮加上一些修复轮次。总耗时大概六个小时其中我实际盯着的时间大概一个半小时其余时间是工具在跑。如果手动做我估计需要两到三天。循环工程把时间压缩到了半天而且质量更稳定因为有测试兜底。当然前期设计花了不少时间但这个投入是值得的因为同样的流程可以复用到其他重构任务上。8. 循环工程的边界哪些任务不适合跑循环8.1 需求本身不明确的任务如果连你自己都不清楚要做什么循环是跑不起来的。循环的前提是有明确目标和明确校验标准。需求不明确的时候应该先做需求梳理用对话式的方式跟工具聊聊清楚了再设计循环。我见过有人让工具“把这个项目优化一下”然后期待循环能自动搞定。这种任务工具根本不知道从哪下手跑几轮就会开始瞎改。正确的做法是先定义“优化”具体指什么是性能、可读性、还是可维护性然后针对具体维度设计循环。8.2 需要大量人工判断的任务有些任务的关键决策需要人的经验和审美比如 UI 设计、架构选型、命名风格。这些任务可以让工具执行但决策得人来做。循环可以跑但每个决策点都要停下来等人确认这样循环的意义就不大了。我的判断标准是如果任务里超过三成的步骤需要人工判断就不适合跑循环用对话式更合适。8.3 一次性任务如果任务只做一次以后不会再做那设计循环的成本可能高于收益。循环工程的价值在于复用同样的流程跑十次设计成本就被摊薄了。只跑一次的话直接手动做可能更快。判断标准是这个任务模式会不会重复出现。会就值得设计循环不会就手动做。8.4 高风险任务涉及生产环境、涉及资金、涉及用户数据的任务我建议不要完全交给循环。循环可以辅助但关键步骤要人工确认。比如数据库迁移可以让循环生成迁移脚本但执行迁移必须人工来。风险控制的原则是循环可以犯错但犯错的代价要可控。如果犯错的代价不可控就不要让循环碰。9. 我踩过的几个坑和对应的解法9.1 坑一任务描述里用了模糊词我早期写任务描述喜欢用“优化”“改进”“整理”这类词。结果工具的理解跟我的理解经常不一致。我说“优化这段代码”它可能理解为“改改变量名”我理解为“降低复杂度”。解法是用可量化的词。不说“优化性能”说“把响应时间从 500ms 降到 100ms 以内”。不说“改进可读性”说“把方法长度从 300 行降到 50 行以内每个方法只做一件事”。量化之后工具的执行方向就明确了校验也有依据了。9.2 坑二没设最大轮次跑了一晚上有一次我让工具做一个批量任务忘了设最大轮次。第二天早上发现它跑了两百多轮token 消耗远超预期而且后面一百多轮都是无效循环因为任务其实在第五十轮就完成了但工具没识别出来。解法是永远设最大轮次。不管任务看起来多简单都设一个上限。我现在默认设二十轮复杂任务设五十轮。到上限就停人工检查后再决定要不要继续。9.3 坑三校验标准太松循环空转有一次我设的校验标准是“代码能编译通过”。结果工具每轮改一点都能编译通过但实际功能没进展。跑了十几轮代码改得面目全非功能还是原来的样子。解法是校验标准要跟任务目标对齐。任务是加功能校验标准就应该是“新功能的测试通过”而不是“代码能编译”。任务是修 bug校验标准就应该是“复现 bug 的测试从失败变成通过”。校验标准离任务目标越近循环越有效。9.4 坑四中途改了校验标准有一次循环跑到一半我发现原来的校验标准太松就临时加严了。结果前面几轮的产出全部不符合新标准需要重新评估。工具也懵了因为它按旧标准跑了几轮突然标准变了它不知道该怎么调整。解法是校验标准在循环开始前定死。如果确实需要调整就停掉当前循环重新设计重新开始。不要在循环中途改标准那样只会让循环混乱。9.5 坑五没做版本控制改坏了回不去早期我跑循环不提交代码结果有一次工具把一个核心文件改坏了我想回滚却发现没有可回滚的版本。只能手动一点点改回来花了好几个小时。解法是循环开始前先提交一次然后每轮结束提交一次。这样任何时候出问题都能回滚到上一个正常状态。版本控制是循环工程的安全带不能省。10. 循环工程的进阶方向从手动设计到半自动演化10.1 循环模板化把常用流程固化成模板跑多了之后你会发现有些循环流程是重复的。比如“扫描—写测试—重构—验证”这个流程在多个重构任务里都用到了。这时候可以把它固化成模板下次直接套用。模板里包含任务描述的结构、校验标准的写法、进度文件的格式、退出条件的设置。用的时候只需要填具体内容不用每次重新设计。我目前积累了五六个模板覆盖重构、迁移、批量修复、测试补充等场景。10.2 循环嵌套大循环里套小循环复杂任务可以设计成嵌套循环。外层循环处理大阶段内层循环处理每个阶段里的具体项。比如一个大型迁移任务外层循环遍历所有模块内层循环处理每个模块里的所有文件。嵌套循环的关键是状态隔离。内层循环的状态不要污染外层外层的进度文件要能反映内层的完成情况。我一般让内层循环结束后更新外层进度文件这样外层能感知到内层的进展。10.3 循环自适应根据上轮结果调整下轮策略进阶玩法是让循环根据上轮结果自动调整策略。比如上轮测试失败了这轮就多给一些调试信息上轮成功了这轮就加快节奏。这个需要工具支持条件分支目前 Claude Code 和 Cursor 都能通过自然语言描述实现简单的自适应逻辑。我的做法是在任务描述里加一段“如果上轮结果是 X则本轮采取 Y 策略”的说明。工具会按这个逻辑执行。实测下来简单的自适应能提升循环效率但太复杂的自适应反而容易让工具困惑建议从简单规则开始。10.4 循环的可观测性让过程透明循环跑起来之后你不在旁边盯着怎么知道它跑得好不好这就需要可观测性。我的做法是让工具每轮输出一份简报包含本轮做了什么、结果如何、下轮计划。这些简报汇总到一个文件里我随时可以翻看。简报不用太长三五句话就行。关键是让过程透明出问题能快速定位是哪一轮出的。没有简报的话循环就是个黑盒出问题只能从头查。11. 关于工具选择我的真实建议Claude Code、Codex、Cursor 这三个工具我都用了不短的时间。如果只能选一个跑循环我选 Claude Code因为它的任务拆解和进度管理最成熟适合循环场景。如果只能选一个做探索我选 Cursor因为编辑器集成带来的实时反馈无可替代。Codex 适合做单点生成循环能力相对弱一些但代码生成质量不错。不过工具选择不是最重要的。我见过用 Cursor 跑出漂亮循环的人也见过用 Claude Code 把循环跑成一团乱麻的人。差别不在工具在循环设计。触发条件清不清晰、执行单元单不单一、校验标准严不严格、退出条件完不完整这些才是决定循环成败的关键。如果你刚开始接触循环工程我的建议是先用一个小任务练手。找一个你熟悉的、边界清晰的任务比如“给这个工具类补充单元测试”按本文的流程设计一个循环跑一遍。跑完复盘一下哪些地方设计得好哪些地方需要改进。跑三五个任务之后你就有一套自己的循环设计方法了。最后分享一个我最近在用的技巧把每次循环的设计和结果记录下来形成一个循环日志。日志里记任务类型、循环设计、跑了多少轮、结果如何、遇到什么问题。积累多了之后你会发现某些任务类型的循环设计有规律可循下次直接套用就行。这个日志现在是我最值钱的资产之一比任何教程都实用。