熟悉的一个词我想先用一句话把它说清楚你不靠一次提示词拿到最终答案而是搭一个“AI干活-AI检查-不达标就退回重干”的闭环让结果在循环里自己长出来。这个套路这两年从大模型Agent项目里流行起来尤其在自动化编程、批量生成内容、数据处理这类场景里特别好用。网上关于Loop Engineering的资料大多是英文碎片要么讲概念讲得太玄要么直接甩一段代码让人照抄。这篇教程我想用保姆级的方式把从原理到实战的路完整走一遍新手跟着做能跑通老手也能顺手带走几张能直接用的检查表。开始之前先说好这篇教程不涉及任何一步到位的魔法Loop Engineering的核心特别朴素把事情拆成小块每个小块都挂一个“合格线”不合格就带着失败信息重新来一遍。你只要把这句话理解透了后面所有代码和配置都是它的变体。1. 什么是Loop Engineering先拆开再讲人话1.1 一句话定义Loop Engineering直译过来是“循环工程”但在真实项目里它更像一种组织AI工作流的方法论。你在一个任务里故意制造一个“执行—检查—反馈—再执行”的循环让AI自己拿着上一轮的不足继续修改直到满足预设标准才放行。它跟传统的多轮对话不一样后者是用户追问前者是系统自己判断“要不要再来一轮”。这件事听起来简单做起来却容易踩坑因为循环里的每一环都有隐藏的翻车点。我最早接触这个概念是在一个自动化写脚本的项目里。当时我天真地以为只要把任务描述写详细模型就能一次搞定。结果十个任务里有三四个会出现低级错误要么逻辑漏了一截要么输出格式不对。反复人工盯实在太累后来我搭了一个循环先生成初稿再做静态检查把检查结果回填回去重新生成。就这么一点改动成功率明显上来了。那时候我才意识到真正决定AI项目天花板的不是提示词写得漂不漂亮而是你有没有给错误留出“回头路”。1.2 循环三角执行、评估、控制一个完整的Loop由三块东西组成缺一块都转不起来。执行器负责干活的模块。它接收任务和上下文输出一个结果。在周报生成项目里执行器就是“根据数据生成周报”的那段调用在代码代理里执行器可能就是“根据需求修改文件”的动作。评估器负责打分的模块。它决定当前结果要不要继续循环。评估器可以是一个大模型判断也可以是一段确定性代码比如正则检查、格式校验、测试用例是否通过更常见的是两者结合。控制器负责发起和终止循环的模块。它会看评估器给出的分数和错误信息决定是重跑、改参数继续、还是直接放弃输出当前结果。控制器还要管住迭代上限防止AI在一个坑里反复横跳。这三者的关系我习惯理解成“干活的人、质检的人、车间主任”。干活的人只管埋头出活质检的人按标准挑毛病车间主任看了质检单决定返工还是放行。大多数做坏了的Loop项目问题不出在干活的人身上而是质检标准模糊或者车间主任没有喊停的魄力。1.3 为什么单次Prompt永远替代不了Loop有人会问我提示词写得好一点一次生成不香吗何必费劲搭循环。这话在简单任务上没错但一旦任务有了“正确性”要求单次Prompt的问题就暴露了。第一大模型生成是一次性的没有机会根据结果修正自己。第二你不知道生成结果离“合格”差多远因为缺少客观评估。第三就算结果不对你也只能人工改没法沉淀成可复用的流程。Loop的价值在于它把“改错”这件事从人工手里转移到了系统手里。每一次循环都是一次自我修正的机会而且修正的方向不是随机的而是由评估器提供的具体缺陷信息决定的。比如周报没写KPI评估器会明确指出“缺失KPI指标”下一轮生成时执行器就会带着这条信息去补。这种模式特别适合结果有明确标准、但一次生成很容易遗漏细节的任务。另外一个容易被忽视的点是Loop让我对结果有了掌控感。单次生成就像扔骰子你不知道会得到什么水平带循环的系统则像有个质检员站在流水线旁边他有明确的合格线不合格就是不给过。这种掌控感在批量生产内容的场景里尤其重要因为你要的不是一份惊艳的产出而是所有产出都在及格线以上。2. 动手前必须填好的四张表我不会一上来就甩代码。以我的经验Loop写毁了90%的原因是开工前没把需求说清楚。在搭循环之前你先要回答四个问题我把它们整理成了表格形式。你花半小时填完这几张表后面写代码就是按图索骥。2.1 第一张表任务边界表这张表用来回答“循环要解决什么问题、不解决什么问题”。很多项目的失败不是循环没搭好而是你指望一个循环解决所有问题。比如你想做批量产品文案边界是“让每篇文案都包含卖点、适用人群、价格信息三项”那就不该把“同义词润色”这种主观审美也塞进评估标准里。我习惯填三列项目填写内容示例输入内容循环开始时系统拿到什么产品规格表、历史周报模板输出产物每一轮执行器产出什么格式的结果Markdown周报、CSV表格、完整代码文件不做的事和任务相关但本次循环不管的事项不做创意方向颠覆、不做排版美化边界表的意义是防止评估器“过度执法”。你一旦让评估器去管不属于它职责的事循环就会陷入无谓的返工。我见过一个例子客户想让AI生成新闻稿却在评估标准里写了“语气要感人”结果每轮都因为不够感人被退回重写最后生成的东西反而越来越浮夸。边界清楚了评估器才有明确的发力方向。2.2 第二张表评判标准表评判标准表是整座大楼的地基。每一行就是一个检查项写清楚通过条件、权重、由谁来判断。我常用的格式长这样检查项通过条件判断方式权重格式完整包含标题、日期、正文三个区块正则/代码必须通过信息齐全覆盖指定三个卖点大模型判断必须通过语言通顺无明显病句大模型判断建议项长度合适全文在300字到500字之间代码判断必须通过注意权重那栏里我把检查项分成了“必须通过”和“建议项”。这个设计非常重要。循环里最怕的就是所有检查项都是硬性要求结果AI为了满足一个次要指标把更核心的内容改坏了。建议项在评估器里只做提示不参与“是否继续循环”的硬性判断除非它连续多轮都不过才升级为硬性拦截。什么时候用大模型判断什么时候用代码判断我有一条粗糙的经验凡是“客观存在性”问题比如字段有没有、格式对不对、数量够不够一律用代码判断因为这部分稳定又便宜凡是“语义质量”问题比如逻辑通不通、卖点覆盖全不全、语气合不合适再用大模型判断因为这部分需要理解能力。混着用能省下不少调用费用。2.3 第三张表循环控制表循环控制表回答的是“什么时候停”。这可能是Loop工程里最容易被新手忽略、却最容易出事故的一张表。一张典型的控制表包含四个参数参数含义推荐初始值最大循环轮数单个任务最多跑几轮3到5轮早停条件连续几轮结果完全相同则停止连续2轮相同质量阈值评分达到多少分可以放行0.8或按评分体系定退让策略达到上限后怎么办输出最后一轮结果并打标记早停条件这个参数我现在看着简单当初是踩过坑才加上的。有一段时间我的循环设置为“评分低于阈值就重跑”结果某个任务在第三轮和第四轮产出了一模一样的内容系统却还在傻乎乎地重试白白烧掉两轮调用费。后来我加上“连续两轮输出一致就停止”的早停条件这种无效重试才被止住。退让策略也值得想清楚。达到最大循环上限后你是放弃任务还是输出当前最好的结果我的建议通常是输出最后一轮结果但在结果里附一条注释说明这个结果未达到内部质量标准需要人工复核。这样既不会让流程卡死又保留了质量提示人工介入时也有据可查。2.4 第四张表状态记录表状态记录表用来持续追踪循环的运行情况。它不直接参与循环逻辑但长期运行的项目离开它就会变得一头雾水。最少要记录这些字段任务ID区分是哪条任务在跑循环。循环轮次当前跑到第几轮。评分明细每个检查项的得分和不通过原因。执行耗时从开始到本轮结束用了多久。Token消耗每一轮消耗的输入输出Token数。最终状态是正常通过、达到上限还是被人工中止。为什么状态记录这么重要因为Loop系统本质上是一个“黑箱”你看到的是第一轮输入和最终输出中间发生了什么全凭记录还原。我曾经排查一个越改越差的任务翻记录后发现是第三轮评估器给出了错误的负面反馈把原本能通过的输出硬生生打回了重做导致第四轮彻底跑偏。没有状态记录这种问题你根本没法定位。这四张表不是让你刻在文档里吃灰的而是让你在写代码时心里有数。下面两章我会用一个完整的实战项目把这四张表变成真正的代码。3. 保姆级搭建自动生成并自检周报的Loop项目3.1 项目背景和成品效果我先设计一个足够简单、但能完整展示Loop精髓的项目给AI一堆本周项目数据让它自动生成一份周报同时系统自检周报质量不合格就打回重写。为什么选周报因为周报的评估点非常典型格式、信息覆盖、长度、语气四类问题都具备。而且你大概率在工作中见过那种写得像流水账的周报要么忘了写KPI要么全篇没有重点。用Loop来治这个毛病效果立竿见影。成品跑起来后你会看到类似这样的流程日志round 1: score0.62, missing[kpi, summary], retry round 2: score0.85, missing[summary], retry round 3: score0.93, all_passedTrue, output_final第一轮周报缺了KPI和总结系统带着这个具体反馈重新生成第二轮补上了KPI但总结写得不够再次返回第三轮所有检查项都过了循环结束输出最终周报。整个过程中除了最开始的配置你不需要人工介入一次。这就是Loop最直观的价值把质量把控嵌进流程里。3.2 Step 1确定“什么算好”这个案例里我用代码定义了四道检查对应前文评判标准表里的几个典型项。我把模板放下面你可以直接抄到自己的文件里用。# checkers.py def check_format(text: str) - tuple[bool, str]: 检查周报是否包含标题、日期、正文区块 parts [【周报】, 日期, 本周进展, 下周计划] missing [p for p in parts if p not in text] return (len(missing) 0, f缺区块: {, .join(missing)} if missing else 格式完整) def check_kpi(text: str) - tuple[bool, str]: 检查周报是否包含KPI指标 # 这里用简单的关键词兜底正式项目建议让模型判断 if any(word in text for word in [KPI, 完成率, 产值, 营收]): return (True, KPI信息存在) return (False, 缺少KPI指标) def check_length(text: str) - tuple[bool, str]: 检查周报长度是否在合理区间 count len(text) if 150 count 800: return (True, f长度合适({count}字)) return (False, f长度异常({count}字需在150~800之间)) def check_summary(text: str) - tuple[bool, str]: 检查是否有整体总结使用关键词近似判断 if 总结 in text or 总体 in text or 整体 in text: return (True, 总结部分存在) return (False, 缺少总结语句)这些检查项里“缺区块”和“长度异常”是硬性拦截“缺少KPI”“缺少总结”也是硬性拦截但它们的判断方式可以升级成模型判断让识别更灵活。在这个案例里先用关键词规则目的是先把循环逻辑跑通。注意我在检查结果里返回的不是简单的“过/不过”而是一条带有具体缺失信息的字符串。这个细节是Loop能不能高效运转的关键。评估器不只要告诉AI“你不行”还要告诉AI“你哪里不行、差什么”。带着具体缺失信息重新生成比空泛地让AI“再改改”有效得多。3.3 Step 2执行器怎么写执行器的职责是接收“任务细节上一轮的反馈信息”输出一份新的周报文本。它本质上是一个拼接提示词的函数。为了方便演示我直接用OpenAI风格的通话接口但把调用部分封装成了一个普通函数你换成任意模型或者自部署模型都行。# executor.py from openai import OpenAI client OpenAI() SYSTEM_PROMPT 你是一个项目周报撰写助手。请根据用户提供的项目数据撰写一份简洁的周报。 周报需要包含以下几个固定区块 【周报】 日期XXXX 本周进展 - 具体事项及完成情况 下周计划 - 计划事项 总总结用一两句话概括本周整体情况。 要求信息密度高不写空话不要编造数据。周报全文字数控制在150到800字之间。 def build_user_prompt(project_data: dict, feedback: str) - str: prompt f本周项目数据如下\n{project_data}\n if feedback: prompt f\n上一轮检查发现的问题\n{feedback}\n prompt 请根据这些问题修改周报不要遗漏修改点。 else: prompt \n请直接生成第一版周报。 return prompt def run_executor(project_data: dict, feedback: str) - str: user_prompt build_user_prompt(project_data, feedback) resp client.chat.completions.create( modelgpt-4o-mini, # 替换为你能用的模型 temperature0.7, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], ) return resp.choices[0].message.content有几个地方我用过之后才体会到为什么需要这么写。一是feedback参数它在第一轮是空字符串从第二轮开始就带着上一轮的失分原因。二是temperature我故意设成0.7而不是0因为你希望AI在修改时有一点表达的多样性否则它会照着旧输出换个措辞继续交卷分数永远卡在及格线边缘。三是system prompt里明确写清了可以用“总总结”这种近似关键词让后面的规则检查器能匹配到。3.4 Step 3评估器怎么写评估器的职责是遍历所有检查项汇总成一份“评分反馈”的报告。# evaluator.py from checkers import check_format, check_kpi, check_length, check_summary def evaluate_report(text: str) - dict: checks [ check_format(text), check_kpi(text), check_length(text), check_summary(text), ] scores [] feedbacks [] for passed, message in checks: if passed: scores.append(1.0) else: scores.append(0.0) feedbacks.append(message) total_score sum(scores) / len(scores) return { score: total_score, passed: all(item[0] is True for item in checks), feedback: ; .join(feedbacks) if feedbacks else all checks passed, details: [msg for _, msg in checks], }这个评估器输出四个信息总分、是否全过、合并后的失败原因、每一项的检查详情。总分用于控制器的“是否达到阈值”passed用于“是否立即放行”feedback用于下一轮执行器的提示词拼接details用于状态记录表。写到这里我想专门提醒新手一句评估器不是越复杂越好。在项目初期用规则检查把格式、长度、硬信息覆盖这些基础项管住用模型只判断那些必须靠语义理解的项目已经能覆盖绝大多数场景。先跑起来再慢慢加复杂评估效率会高很多。我见过有人第一版就给周报配了五个大模型评估器每轮要烧好几块钱结果收益微乎其微。3.5 Step 4循环控制器怎么写控制器是整个Loop的发动机。它负责把执行器和评估器串起来并执行前文说的控制策略最大轮数、早停、阈值判断、最终输出。# controller.py from executor import run_executor from evaluator import evaluate_report MAX_ROUNDS 3 QUALITY_THRESHOLD 0.8 EARLY_STOP_ROUNDS 2 def run_loop(project_data: dict) - dict: history [] feedback last_output same_count 0 for round_idx in range(1, MAX_ROUNDS 1): output run_executor(project_data, feedback) result evaluate_report(output) # 记录本轮状态 history.append({ round: round_idx, score: result[score], feedback: result[feedback], output: output, }) if result[passed] or result[score] QUALITY_THRESHOLD: return {status: passed, round: round_idx, score: result[score], output: output, history: history} # 早停连续两轮输出完全相同认为再跑也不会有变化 if output last_output: same_count 1 else: same_count 0 if same_count EARLY_STOP_ROUNDS: return {status: early_stopped, round: round_idx, score: result[score], output: output, history: history} last_output output feedback result[feedback] # 超过最大轮数返回最后一轮结果并标记人工审查 final_result evaluate_report(last_output) if last_output else {score: 0, feedback: empty, details: []} return {status: max_rounds_reached, round: MAX_ROUNDS, score: final_result[score], output: last_output, history: history}控制器的核心逻辑就这么三件事判断是否放行、判断是否早停、判断是否打上限标。你注意到我用了“score QUALITY_THRESHOLD”和“passed”双重条件这是因为有的任务允许“有瑕疵但总体分数够了就放行”有的任务则要求每项必须全过。周报这类内容任务我建议阈值定在0.8同时必须有passed兜底代码生成类任务则应该以passed为主不能只看分数。早停判断我放在“未通过”的判断之后保证只有不合格且重复的输出才触发早停。有个细节值得说比较输出文本是否完全相等在周报这种有固定模板的任务里是有效的但如果你做的是开放式创意写作内容合理变化但质量未达标完全相等就很难触发。这种情况可以改成“连续两轮评分完全一致且没有新的反馈项”也能起到近似效果。3.6 Step 5跑通后的关键参数调节代码写完拿一组模拟数据跑一遍你会对Loop的运行规律有直观感受。我随便写一组数据示例project_data { 本周完成: [完成登录接口开发, 修复3个前端缺陷, 开始性能优化方案设计], 下周计划: [完成性能优化改造, 评审接口重构方案], 风险: [性能测试环境资源不足], } result run_loop(project_data) print(result[status], result[score])如果一切正常默认三轮内就能跑出一个及格的周报。跑通之后我会建议你按下面顺序去调参而不是一上来就动每轮调用的大模型优先调评估标准。如果结果经常“卡在某个分数上不去”往往是检查项太宽松或太严格。太宽松会让AI提前通过太严格会让循环空洞地烧轮数。再调最大轮数。轮数不是越多越好。生产环境里我通常设3轮最多5轮。超过5轮还在反复改基本说明任务定义有问题或者评估反馈信息不够具体。最后调阈值。阈值调高会增加返工率调低会增加次品率。你可以拿历史数据画出“第几轮通过/最终分数”的分布再选一个平衡点。4. 项目实战批量生成产品文案并持续改进的完整案例4.1 场景设定与难点周报项目属于“单任务单循环”一次只处理一个产出。实际工作里更常见的是“批量任务每个都要循环”比如给一百个产品各生成一篇上架文案要求每篇都覆盖卖点、使用场景、规格参数并且不能出现模糊表述。这个案例的难点不在单个文案怎么生成而在批量场景下怎么控制成本、保证稳定。单篇跑循环没问题一百篇一起跑有的任务可能两轮就过有的任务可能五轮都不达标你要能接受“任务完成时间差异大”这件事。同时批量场景里评估器不能太贵否则一百篇乘上平均三轮调用费用会非常可观。所以我这个实战案例会重点展示两件事一是如何用“确定性规则一个轻量模型评估”的组合控制批量生成的单篇成本二是如何把“通过率”和“平均轮数”当作核心运营指标你心里要有一本账。4.2 简易代码骨架我先定义一个产品数据结构和评估规则然后写一个批量控制循环。# batch_loop.py import json import time from executor import run_executor from evaluator import evaluate_report # 模拟产品数据 products [ {id: 1, name: 便携榨汁杯, selling_points: [无线充电, 350ml容量, 六叶刀头], price: 199}, {id: 2, name: 降噪耳机, selling_points: [主动降噪, 30小时续航, 蓝牙5.3], price: 499}, # 实际项目里这里会有几十上百条 ] def generate_one(product: dict, max_rounds: int 3) - dict: feedback history [] for round_idx in range(1, max_rounds 1): prompt f请为以下产品撰写上架文案必须包含卖点、使用场景、规格参数{json.dumps(product, ensure_asciiFalse)} if feedback: prompt f\n上一轮问题{feedback}\n请针对性修改。 text run_executor({name: product[name]}, feedback) # 复用第3章的执行器 result evaluate_report(text) history.append({round: round_idx, score: result[score]}) if result[passed]: return {id: product[id], status: ok, rounds: round_idx, history: history} feedback result[feedback] return {id: product[id], status: timeout, rounds: max_rounds, history: history} def batch_run(products: list[dict]) - dict: stats {total: len(products), ok: 0, timeout: 0, rounds: 0} results [] for product in products: start_time time.time() res generate_one(product) res[elapsed] round(time.time() - start_time, 2) results.append(res) if res[status] ok: stats[ok] 1 else: stats[timeout] 1 stats[rounds] res[rounds] stats[avg_rounds] round(stats[rounds] / stats[total], 2) return {stats: stats, results: results}跑完之后你会得到一组统计数字比如总通过率90%平均轮数2.3轮。这两个指标就是后续优化Loop的抓手。通过率低说明评估标准或执行器不行平均轮数高说明反馈信息不够精确或任务难度过高。4.3 三种文案的循环走向对比我把三种典型结果列成一张表方便你直观感受Loop在不同情况下的行为差异产品第一轮得分问题第二轮得分第三轮结果最终状态便携榨汁杯0.75缺使用场景0.92全部通过通过2轮降噪耳机0.5缺卖点细节、缺规格参数0.77规格仍不全超时3轮无线充电器0.92全部通过无需重跑通过1轮第一行产品属于典型“反馈有效”的情况评估器明确说“缺使用场景”第二轮补上后直接通过。第二行产品属于“反馈不够具体”的情况评估器说“缺规格参数”但文案里其实提到了续航和接口就是没按标准格式写所以第三轮仍然评分不高。这提醒你当任务失败率偏高时不要急着加轮数先看看评估器的反馈是不是足够“可执行”。第三行产品代表了另一种常见情况任务简单第一轮就过了。这种任务在批量场景里占比不少所以没必要对每个任务都预设五轮循环三轮就够用了。4.4 上线前要盯死的三个指标批量Loop一旦上线你已经不关心单个文本长什么样了而是盯三件事通过率最终状态为“ok”的任务占总任务数的比例。低于80%说明流程有系统性问题不是某一条文案的偶然质量问题。平均轮数全部任务完成消耗的循环轮数均值。这个值直接对应调用成本平均多一轮费用就按比例上涨。超时率达到上限轮数仍未通过的比例。超时率持续偏高说明你的评估标准或任务拆解有问题。我个人的经验是通过率不要追100%。在内容生成类任务里追100%的代价是平均轮数暴涨、整体成本失控而且最后几轮提升的往往只是表面格式。80%到90%通过率是比较健康的区间剩下的超时任务丢给人工处理反而更划算。5. 常见问题与排查技巧实录这部分是我实际跑Loop项目时踩过的坑每个问题我都给排查办法。你可以直接把它当急救手册用。5.1 死循环为什么AI一直在改但分数不动现象循环跑到最大轮数每一轮的分都在0.7上下浮动死活过不了阈值。我先给一张速查表现象特征大概率原因处理办法分数稳定但很低评估标准过严检查是否把“建议项”当成硬指标分数小幅波动反馈信息不够具体把“格式不完整”改成“缺少xxx字段”下一轮输出与上一轮完全相同模型无动力改变调整temperature增加改写指令某一检查项始终失败评估逻辑有bug单独打印该项的判定输入和输出最隐蔽的是第三种。你以为加了循环就是在让AI改进实际上如果反馈里全是抽象词汇比如“请加强文案吸引力让语言更生动”AI大概率会给你重写一版类似的因为这种反馈不指向任何可修改的具体缺陷。解决办法只有一个评估器的反馈必须落到具体事物上比如“第二段缺少适用人群描述”或“规格参数里没有电池容量”这样AI才知道要动哪里。5.2 评分不变但人工感觉明显变好了这是Loop工程里特别有意思也特别迷惑的现象。打分一直停在0.75但你肉眼可见输出质量在提高。遇到这种情况我的第一反应不是觉得循环没用而是评估器没测对维度。我拿周报项目来说如果评估器只查“有没有KPI关键词”AI只要把“KPI”三个字母混进文章里就算过即使这句话毫无信息量。评分不变恰恰说明你的评估维度停在表层。解决思路是升级评估器把关键词判断换成语义判断让模型去判断“KPI是否被有效解释”而不只是“KPI是否出现”。评估器永远赶不上输出的复杂度但你要保证它能捕捉到“你真正在意的那些改进”。5.3 越改越差AI在循环里自我损耗现象第一轮输出8分第二轮经过反馈反而7分第三轮6.5分分数一路下跌。这不是小概率事件而是Loop系统里最让人头疼的现象之一。最常见的元凶是反馈过度。当一轮输出已经接近合格评估器却把某个“建议项”当成大问题反馈回去AI为了讨好评估器牺牲了本来做得好的部分结果越改越四不像。对策有三个一是把非关键检查项设为只提示不拦截二是在每轮反馈里加一句“以下问题按优先级排列”三是设置“分数下降保护”——如果当前轮分数比上一轮低就忽略当前轮的反馈直接沿用上一轮输出继续下一轮。最后一个方法是我在生产项目里最常用的效果立竿见影。5.4 上下文越滚越脏反馈信息叠加成灾Loop天然的会把每一轮的反馈带回下一轮但如果所有历史反馈都堆在提示词里很快上下文就会超过限制而且一堆旧问题会让AI不知道重点到底在哪。我见过一个项目第三轮提示词里塞了前两轮加起来十多个问题点AI完全懵掉敷衍地逐个点一遍结果哪哪都没改好。我的习惯是每一轮只用上一轮的评估反馈不叠加历史反馈如果确实要把历史反馈带进去也要手动加上“已经解决”的标记并在新反馈中优先列出。保持反馈信息“短而新”比追求“全”更重要。5.5 费用和速度优化在循环和不循环之间找平衡循环的系统开销确实比单次调用高。我的优化顺序是这样的先用规则检查过滤掉约三成低级错误大模型评估只处理规则查不出来的语义问题。对简单任务降低最大轮数比如文案类任务只跑两轮。简单任务本身一次通过率就高多给轮数是在浪费钱。把评估和生成拆成两个模型生成用能力强的模型评估用便宜的小模型。很多场景下小模型的评判能力跟大模型差距不大成本却低得多。按这个顺序优化一轮之后我做过的批量项目单均价能降下40%到50%而且通过率基本不掉。Loop不是越多越好每一轮都要花钱所以“用最少的轮数拿到达标结果”本身就是Loop工程的一个重要优化目标。6. 我自己的几个工作习惯6.1 每一轮都留痕不管项目多着急我一定会让每轮循环把输出、评分、反馈、耗时存下来哪怕先存在本地JSON文件里也行。这份运行日志在调试期价值巨大因为Loop的问题几乎都是“看中间轮次才能定位”的只有最终输出根本无从下手。留痕成本不高但能省下大量排查时间。6.2 每种循环都配上限循环本身没有错但失控的循环是小钱钱的粉碎机。我给所有循环项目开工前就定死最大轮数、单任务预算、整批预算超出就自动熔断。比如一批一百条文案的批量项目预算不够两轮的时候就直接降级成单次生成不让任何人丝滑地踩进费用坑。6.3 没有评估就没有循环这句话是我给自己立的规矩任何任务只要想上Loop必须先想清楚合格的判断标准并且写成可操作的检查项。没有评估器的循环那不是循环是碰运气。哪怕评估器一开始粗糙一点也没关系先有再优化比没有强太多。实际做的时候我经常先用人工挑五份输出看一眼共同的缺陷模式再把这些缺陷模式固化成评估器规则这样出来的评估器比凭空设计的接地气得多。6.4 用“审计后缀”收尾所谓审计后缀就是在最终输出末尾附一行系统记录第几轮通过、最终评分、评估器判定细节。用户可能不需要看到这行但调试时需要后续追溯时需要。我在周报项目里会自动把“第2轮通过评分0.92”这种后缀加到输出末尾的注释里方便核验。生产环境你想隐藏的话存数据库即可逻辑一样。6.5 扩展思路把Loop用到大模型之外最后分享一个我最近在实验的方向把Loop工程的思想用在非大模型场景里。比如数据清洗任务先跑一轮规则清洗再用统计异常检测当评估器异常率高了就换一版清洗参数继续跑再比如配置调优任务先随机生成一组参数再用历史指标当评估器不达标就换参数重试。Loop的内核是通用的任何“干一次可能不完美但能判断好坏”的任务都可以用循环来提高稳定性。这个思路一旦打开你会发现它能用的地方远比想象中多。我在实际搭建Loop系统时最深的体会是这个工程方法不会让AI一下子变得多聪明但它会让一个本来只能偶尔出精品的模型稳定地产出可用的成果。稳定有时候比惊艳更难得。希望这篇教程能让你少走点我走过的弯路动手把自己的第一个Loop搭起来。