一句话定义：Evaluator-Optimizer（评估-优化循环）是一种把「产出」和「验收」拆成两个角色的协作模式——一个模型负责给答案，另一个模型专门找毛病，前者按意见改，来回几轮，直到评审过关或达到轮数上限。
它怎么运转的
想象装修。设计师出方案，监理挑刺：这面墙不能动，水电走线不合规。设计师改完再交，监理再看。房子最后好不好，往往不取决于设计师多有名，而取决于监理敢不敢说、懂不懂行。
落到系统里，有三个关键点：
1. 评审要给可操作的反馈。「感觉不太行」没用，「第二段结论缺少数据支撑、第三步没考虑边界情况」才有用。
2. 必须有终止条件。通常是评审判定通过，或者达到设定的最大轮数，避免无限来回。
3. 优化方要真的改。最怕的是换个说法把原答案重写一遍，看起来迭代了，其实原地踏步。
这套模式最大的特点，也是它最大的软肋：效果几乎完全由评审者的严格程度决定。评审宽松，循环就退化成走过场；评审只会打「7 分」，优化方根本不知道该改什么。所以实践中真正花功夫的地方，往往不是写主模型，而是把评审标准写清楚——甚至给出打分维度和具体检查清单。
和相邻概念的区别
| 模式 | 谁挑错 | 反馈从哪来 | 典型定位 |
|---|---|---|---|
| AI 词典：Chain-of-Thought">Chain-of-Thought（思维链） | 没人挑 | 无 | 单次推理多想几步 |
| Reflection（自我反思） | 模型自己 | 自我批评 | 单轮自我纠错 |
| Evaluator-Optimizer | 独立评审者 | 明确的评审意见 | 跨多轮迭代打磨 |
| RAG（检索增强生成） | 没人挑 | 外部知识库 | 解决「知识从哪来」 |
和 Reflection 最大的差别在于角色分离：同一个模型既写又评，容易陷入「我写的肯定没问题」的盲区，也很难跳出原有思路；换一个独立评审者，甚至换个不同模型，挑错的视角才会真正变化。而 Chain-of-Thought 是单次生成内部的思考，Evaluator-Optimizer 是外部反馈驱动的多轮循环，前者省事，后者更贵但更稳。
对实际工作的意义
对从业者来说，这是性价比很高的质量提升手段，尤其适合翻译、代码生成、结构化抽取、文案打磨这类「好坏标准比较明确」的任务。标准越清晰，收益越大；反过来，如果任务本身没有客观好坏（比如纯创意发散），评审者很容易变成「为了改而改」，越改越平庸。
成本也要算清楚：轮数翻倍，token 和时间基本也翻倍。常见做法是只用在高价值、错误代价高的环节，或者让评审者在发现问题时才触发下一轮。
对普通职场人，有个立刻能用的启发：让 AI 写完东西后，别只说「再优化一下」，而是自己扮演 Evaluator——「这份周报缺少量化结果，把第三部分的指标补上」。具体的挑刺，比笼统的「再想想」有效得多。
各家模型和框架对这种循环的支持方式不同，具体接口和参数以官方文档为准。