当AI内容生产系统遇上Loop Engineering，一场关于自我迭代的极限测试正在上演。本文作者构建了一套包含6个AI角色、44个评分维度的智能系统，通过质量闭环、策略闭环和调度闭环的三重验证，揭秘如何让AI系统实现真正的自主进化。从判断标准设定到反馈机制设计，从角色边界划分到退出条件建立，这套方法论正在重新定义人机协作的边界。

我建了一套内容生产系统，6 个 AI 角色、44 个评分维度、5 套审查标准。这篇文章是它的 v4。

六月全网都在聊 Loop Engineering。大部分人讨论它「是不是营销造词」。我直接搭了一套系统跑了一遍，结论在这篇文章里。

内容生产只是我选的验证场景。把它换成代码审查、客户支持、数据分析——底层的设计逻辑是一样的。

Loop Engineering：三个必须回答的问题

一个能自我迭代的 AI 系统，核心是设计反馈闭环。

当我需要写一个 prompt 时候，会让 AI 帮我查漏补缺，当代码 bug 的时候会让 AI 分析原因和解决方案。我总结过去的 AI coding 项目，“我”的角色已经变成了一个点“同意”+copy 的中转角色。

那个时候我就想，既然都是 AI 做决策，能不能不用“我”作为衔接，而是由 AI 自主对接。能不能不是我来优化、迭代 prompt，能不能不是我来分层补充记忆

一个反馈闭环需要回答三个问题：

1. 判断标准在哪？ ——系统凭什么判断”这次做得好不好”？没有标准就没有反馈，没有反馈就没有迭代。
2. 反馈怎么回来？ ——判断结果怎么变成下一次的改进信号？判断了但不反馈，等于没判断。
3. 循环在哪停下来？ ——无限迭代等于死循环。退出条件是什么？

这三个问题对应闭环的三个要素：标准、反馈、边界。缺任何一个，loop 就转不起来。

下面是内容系统里的具体验证。

验证一：质量闭环——Checker ↔ Builder 循环

通用问题

AI 生成内容的质量一致性不足。同一个 prompt，有的产出 80 分，有的不及格。单次优化（改 prompt、加要求）能解决个案，解决不了系统性的质量波动——因为你每次都在重新告诉 AI “什么是好”，AI 不会自己记住。

Loop Engineering 方案

把”判断”和”执行”拆成两个独立 agent，让它们构成一个反馈闭环。

Checker 对照评分标准逐项审查，只读不写——它告诉你哪有问题、为什么、怎么改，但不能自己动手。Builder 按意见修改，只改不评——改得好不好，下一轮 Checker 说了算。

同一个 agent 既审稿又改稿：自己写的自己审，”我写的当然没问题”，一个 agent 无法容纳两套标准。审稿形同虚设。拆开之后，Checker 没有修改权限，Builder 没有自我评价的资格——闭环在角色边界上就被强制运转起来了。

退出条件：审稿 3 轮、改稿 4 轮上限。过了上限升级人工。同一问题连续 2 轮无改善也升级。没有退出条件的 loop 不是工程，是死循环。

内容系统中的实现

6 个角色按”判断权”拆开：

Checker 审稿的依据是 rubrics——5 套评分标准共 44 个维度。每个维度具体到可执行。举例，公众号”AI 味检测”维度：

不出现以下表达：一句话总结 / 总而言之 / 希望对你有帮助 / 在当今时代 / 随着 AI 技术的发展 / 值得注意的是 / 综上所述；不出现连续排比句（3 个及以上相同句式）

这些 rubrics 来自我已有的 Content System 知识库——写作风格规范、平台适配矩阵、改稿原则。rubrics 是闭环的燃料，没有标准就没法判断，没法判断就没法迭代。

这篇文章你读到的是 v4。v1 到 v4 之间，Checker 打回了三轮——标题超长、”不是而是”高频出现、核心概念缺失。每一轮 Builder 的修改和 Checker 的复查，就是质量闭环在真实运转。

验证二：策略闭环——复盘 → 选题池循环

通用问题

系统能产出内容，但不知道”应该产什么”。每次选题靠人的直觉——人的直觉不稳定，而且不会因为做了 10 次就自动变准。

Loop Engineering 方案

把每一次产出后的真实数据收集回来，和预期做对比，把偏差反馈回决策模型。

三个环节：输出 → 测量 → 反馈。发布前有预期（预估阅读量/互动率），发布后有真实数据，对比后的偏差用来调整下一次的决策权重。哪个话题方向数据好？什么内容类型互动高？什么平台转化强？——系统通过积累自己的”经验”来变准。

内容系统中的实现

选题发现 agent 不只是一次性”找 5 个话题”。它维护着一个带权重的打分模型——受众匹配度、差异化空间、素材可得性、传播潜力、转化潜力，每项 1-10 分。

但打分模型的初始权重只是假设。真正的校准来自另一端的复盘 agent：每篇文章发布 3 天后，自动拉数据，用 ECNS 框架归因（Emotion 情绪入口 / Content 方法 / Narrative 叙事证据 / Stir 议题感），生成复盘卡片，反馈回选题池。

打分模型初始权重 → 选题 → 发布 → 数据回来 → 复盘诊断 → 更新权重 → 下一次选题更精准。 这个闭环跑 10 次之后，系统对”什么值得写”的判断来自 10 篇文章的真实表现数据，不是初始假设。

首次选题发现产出了 5 个候选——那是初始假设。第 10 次选题发现的精度，取决于这中间的 9 次数据反馈。

验证三：调度闭环——让系统自己转动

通用问题

闭环设计好了，但每次要人手去触发——选题要手动跑、复盘要手动做。这不是闭环，是需要人推着走的流水线。

Loop Engineering 方案

定时调度 + 状态追踪。闭环的每一步由时间驱动而非人力驱动。同时需要一个全局状态文件，让每个 agent 在执行前知道”上一次发生了什么””现在该做什么”。

内容系统中的实现

两个定时任务：选题发现每 3 天自动运行，复盘每天自动检查是否有发布满 3 天且未复盘的文章。

一个全局状态文件追踪全链路——从选题池到生产循环到发布记录到复盘状态，外加 N 天验证目标（4 篇底稿 / 4 篇长文 / 4-8 条小红书 / 2 个可沉淀案例）。

N 天后，系统用一个更外层的问题来验证自己：“某个账号”整体定位，能不能通过实操内容达成真正的目标？ 如果不能，调整定位——这是系统最外层的 feedback loop。

三个闭环的嵌套关系

质量闭环（Checker↔Builder）

→ 解决”单篇不翻车”

→ 运行在每篇文章内部，分钟/小时级

策略闭环（复盘→选题池）

→ 解决”方向不跑偏”

→ 运行在多篇文章之间，天/周级

定位闭环（30天验证）

→ 解决”系统服务于正确目标”

→ 运行在整个系统之上，月级

内环保证执行质量，中环调整方向策略，外环验证系统目标。 三个闭环的时间尺度和作用层级不同，但设计逻辑一致：判断标准 → 反馈机制 → 退出条件。

Loop Engineering 的通用原则

如果你想把 loop engineering 用到自己的领域——不只是内容生产——这三条原则可以复用：

原则一：先建标准，再建闭环。 闭环的前提是有量化标准可以”反馈”。没有可量化的标准，闭环就是空转。标准不需要完美——快速迭代才是 AI 时代的第一序列真理。rubrics 的第一版是空模板，但它提供了一个可以迭代的起点。

原则二：用角色边界强制反馈，不要靠人的自觉。 让同一个 agent 既执行又判断，结果一定是自我合理化。用工具权限、角色职责、流程关卡把”判断”和”执行”物理隔开——闭环靠系统顶层的结构设计。

原则三：每个闭环必须设退出条件。 无限迭代 = 死循环。审稿 3 轮上限、改稿 4 轮上限、30 天验证周期——每个闭环都有明确的”到这里停，升级人工判断”的边界。loop 的价值是迭代，迭代的目的是进化，进化的目的是打造一个内外循环的可进化系统。

Loop Engineering 的当前边界

这套方法论有几个我还没解决的问题——不是内容系统的问题，是 loop engineering 本身的限制：

• 单模型同频偏差。 Checker 和 Builder 虽然拆开了，但它们用的是同一个底层大模型。模型共有的盲区，拆角色解决不了。多模型交叉验证（Checker 用模型 A、Builder 用模型 B）可能是一个解法，我更希望的是每个角色下的大模型基座都可以互换，以抹平大模型差异带来的系统依赖。比如这周ChatGPT是撰稿角色，DeepSeek是审稿角色；下周Claude是审稿角色，DeepSeek是撰稿角色。
• 标准覆盖的盲区。 44 个维度能检查”标题是否够短””是否用了 AI 句式”，检查不了”这段话读起来有没有灵魂”。所有基于规则的闭环都有一个上限——规则检查不到的东西，闭环也迭代不到。哪些判断应该留在闭环外、由人来做——这个边界需要持续校准。
• 长周期闭环的数据依赖。 策略闭环和定位闭环依赖真实发布数据。如果 30 天内只发了 2 篇文章，策略闭环的样本量不足以产生有意义的反馈。小样本下的 loop engineering 基本就不太可能了。
• 反馈闭环的数量控制。 当前三个闭环已经有较大的协调成本。每个闭环对应一个需要解决的问题，一个系统应该设几个闭环？多了协调成本爆炸，少了覆盖不够。这个 trade-off 的量化方法我还没有。

以上是基于一次实验的个人观察。内容系统是验证案例，如果想要了解更多细节，请关注或留言，后续会有更多的细节分享