编者按：AI 生成内容的「垃圾化」，往往被归因于提示词不够好、模型不够强，或上下文不够完整。但这篇文章提出了一个更接近工程系统的判断：问题不在输入侧，而在输出侧。

作者认为，很多人已经反复尝试过改写 prompt、升级模型、开启记忆、堆叠上下文文件，但 AI slop 仍会反复出现。原因在于，这些方法都在优化「生成」本身，却没有建立一套稳定的质量控制机制。就像工厂不会只依赖工人的手感来决定产品是否出厂，AI 输出也不应从模型直接流向用户，而缺少测试、评分与拦截。

文章的核心方案，是在 Hermes 这个开源 Agent 中搭建一套 eval loop：先定义什么是「好输出」，再把标准转化为可量化的评分体系，并在发布前、运行时和生产环境中持续检测。无论是内容创作中的空洞表达，还是产品中的幻觉答案、格式错误和体验退化，本质上都是未经测量的 AI 输出直接抵达受众。

因此，真正重要的不是再写一个更长的提示词，而是补上一层缺失的质量系统。测试案例、评分指标、阈值、回归测试、审批按钮和生产环境监控，共同构成了这套机制。它让「AI 输出质量」从一种主观感觉，变成一个可以观察、比较和修复的数字。

以下为原文：

有些人似乎总能持续交付最好的软件、写出精彩的内容，或者生成惊艳的图像，这背后是有原因的。

他们采用了 eval loop，而你还没有。

你试过更好的提示词，换过更贵的模型，写过更长的指令，打开了记忆功能，也搭建过像小说一样庞大的上下文文件，但 AI 垃圾内容还是会一次次出现。

它之所以反复出现，是因为你一直在修补一个本来就没有坏掉的层。

AI 垃圾内容不是提示词问题，而是系统问题。就像一家工厂不断发出有缺陷的产品，问题并不在某个工人，而在质量控制机制：没有人在产品离开大楼之前检查它。

所以，这篇文章要搭建的就是这套机制。读完之后，你将拥有一个可以在 Hermes 这个开源 Agent 中运行的 eval loop：它会在每个输出发布前，按照你的标准进行评分；在发布后继续监测真实输出表现；并把每一次失败都转化为新的测试，让质量底线自动抬高。

我们会一步一步把它搭起来。最终的收益很具体：你可以得到真正干净、可信的输出，不必在半夜重新逐字检查；你会拥有一个可以直观看到的质量分数；那些 AI 垃圾内容会在出门前就被拦下，而不是等你的受众来发现。

你将从这篇文章中带走这些东西：

为什么更好的提示词、更大的模型和记忆功能，始终无法彻底消灭 AI 垃圾内容；以及真正起作用的是哪一层；

AI 垃圾内容藏在你工作中的两个地方：内容输出和产品输出；以及为什么两者的修复方式其实完全一样；

用大白话解释什么是 eval loop：这个很少有人日常运行的质量层，以及为什么从来没人提醒你去搭建它；

一个本周就能搭起来的质量基准，既适用于内容，也适用于产品：具体要衡量什么，以及屏幕上的哪个数字才算「好」；

一套完整的搭建步骤：如何用 Hermes 已经提供的组件——skills、memory、cron 和审批按钮——把整个循环串起来，让质量闸门自动运行，不再依赖你手动把关。

如果你是冲着「5 个解决 AI 垃圾内容的提示词」来的，那这篇不是。

那类东西确实存在，但它们并不真正有效。这篇讲的是有效的版本。

你几乎什么都试过了，除了真正该试的那一个东西。

先简单回顾一下你已经做过什么：你改写过提示词，三次、四次；你加入了示例，加入了人设，加入了一长串「不要这样做」的清单。你升级到了前沿模型，每个 token 多花了 5 倍的钱，结果输出只是变得更自信了，却并没有变得不那么空泛。你打开了记忆功能，搭建了上下文文件，把你的品牌语气、过往作品、风格指南都喂给了它。

这些操作中的每一个，都会给你换来几次不错的生成结果。然后，AI 垃圾内容又会慢慢爬回来。

因为所有这些，都是输入侧的修补。你一直在打磨那个「生成」的东西，却忽视了真正应该负责「拦截」的东西。再好的枪，如果只是朝黑暗中开火，也依然什么都打不中。

AI 垃圾内容是一个输出侧问题。问题不在于模型不能产出好作品，而在于你没有办法在它到达重要的人面前，提前分辨哪些是好作品，哪些是坏作品。

你没有 eval loop，没有质量基准，没有记分牌。所以你一直是在盲调。你改了一个提示词，感觉它好像变好了，但感觉不是测量，感觉也拦不住接下来 50 次生成里藏着的那一次糟糕输出。

于是你开始责怪自己，责怪提示词，责怪 Agent 设置，责怪上下文工程。但真正缺失的，是一整层你从来没有被教过的 AI 工作方式。而读完这篇文章后，这一层会在你自己的机器上、在 Hermes 里跑起来。

为什么更好的提示词解决不了这个问题，以及为什么大家仍然一直在尝试

提示词是一种假设，输出是结果，而 eval 是唯一能把两者闭环连接起来的东西。

没有这个闭环，你就会永远停留在猜测里。你调整假设，肉眼看一条结果，然后宣布胜利。你永远不会发现，同一个提示词其实有 30% 的时间会产出垃圾，因为你每次只看眼前这一条输出。

模型是非确定性的。同一个提示词运行两次，会给出两个不同答案。这意味着，即便是一个「完美」的提示词，也会在某个比例的运行中产出 AI 垃圾内容。而在客户或用户真正看到它之前，你根本不知道是哪一次。

所以，一个完美提示词并不是质量保证，它只是一次胜率稍高的掷硬币。而你现在是在把每一次掷硬币的结果都直接发出去。

大家之所以一直把希望寄托在提示词上，原因很简单：提示词是你唯一看得见的杠杆。你可以编辑它，而编辑它会让你产生一种掌控感。

测量则是隐形的。没有人卖给你一门关于测量的课程，也没有人会发一条病毒式传播的帖子，标题叫「这个 eval suite 让我的输出质量提升了 10 倍」。于是，整个讨论都被困在了那个单独使用时根本解决不了问题的杠杆上。

那些 AI 输出始终干净的人，并不是比你更会写提示词。他们只是多了一个你没有的杠杆：他们会在每个输出发布前，用一套标准去衡量它。正是这种衡量机制，让他们的提示词看起来像魔法。

AI 垃圾内容藏在两个地方

AI 垃圾内容只藏在两个地方，而几乎所有人都只盯着其中一个。

第一个地方，是你的内容输出。

推文、文章、邮件、落地页、帖子，任何你用 AI 生成并以自己名义发布的东西，都属于这一类。

这里的 AI 垃圾内容，看起来往往是「技术上没错，但完全空心」的作品。它听起来像时间线上每一个 AI 账号发出来的东西：外表正确，内里空洞。

它会在公开场合失效，而你甚至说不清为什么，因为你按下发送键时，每一篇单独看起来都还可以。

第二个地方，是你的产品输出。

你上线的 AI 功能、Agent、聊天机器人、客服回复器、信息抽取流水线，任何用户真正会接触到的东西，都属于这一类。

这里的 AI 垃圾内容，可能表现为一个带着绝对自信的错误答案，一个幻觉出来的数字，一个损坏的 JSON 输出，一种不符合品牌的语气，或者一个在演示时表现很好、却在三次部署之后悄悄退化的输出。

它不会在公开场合立刻死掉。它会在沉默中扩散。每个用户都得到一个稍差一点的体验，而大多数人永远不会告诉你。他们只会离开。

这两者是同一种病，解法也相同。

内容垃圾和产品垃圾，本质上都是未经测量的 AI 输出，中间没有任何质量闸门，就直接被送到了受众面前。

唯一的区别，是风险和可见度。内容垃圾会让你在公开场合尴尬，产品垃圾则会悄悄消耗你的业务。而我们将在 Hermes 里搭建的这个循环，会用同一个 skill 来给两者打分。这样，你就可以用一套质量系统管理所有生成内容，而不是为不同场景维护两套系统。

eval loop 到底是什么

eval loop，就是一个可重复运行的测试。它会在 AI 输出发布前和发布后，自动将其与你定义的标准进行对照，并给出评分。

就这么简单。这就是全部。而它正是大多数 AI 构建者缺失的那一层。

软件工程师很早就拥有这套机制，它叫测试。你绝不会在没有测试的情况下直接发布代码，然后祈祷它能在生产环境里正常运行。但这正是现在整个行业发布 AI 输出的方式：从模型直接到用户，全靠感觉和祈祷。

几乎没有人拥有 eval loop，原因其实和人群结构有关。今天使用 AI 构建东西的人，很多来自内容、销售、产品、创业，而不是工程背景。所以，「为你的输出写测试」从来不在他们的工具箱里。eval 听起来像是「真正的工程师」才会用的基础设施，而最需要它的人，反而会下意识觉得自己没有资格使用它。

你可以把它理解为一种面向非确定性系统的单元测试。你测试的不是代码能不能运行，而是输出是否足够好。你要在足够多的案例上进行测试，确保某一次糟糕生成不会轻易藏过去。

一个 eval loop 会运行在三个地方。接下来我们要搭建的系统，会把它放进这三个环节里：

发布前，用保存好的案例集测试你的新提示词或新模型，确认它没有变差。这就是回归测试，用来防止一个改动修好了一处问题，却悄悄弄坏了另外三处。

运行时，在输出生成的过程中进行评分，并让条件逻辑在失败结果抵达用户之前拦下它。这就是护栏。

生产环境中，持续抽样真实执行结果并进行评分，这样你能在质量开始下降的当天就发现问题，而不是等到一周后客户来投诉。

第一种，你甚至可以用电子表格搭起来。但如果想让这三种测试持续运行，同时又不把它变成你的第二份工作，这正是我们要把它放进 Agent 里的原因。

一旦质量变成一个数字，AI 垃圾内容就不再是你反复产生的一种感觉，而会变成一个可以修复的 bug。你无法调试一种感觉，但你可以调试一个从 0.82 掉到 0.61 的分数。

基准：你接下来要搭建的三个部分

一个 benchmark 有三个组成部分。无论你是在评估内容，还是在评估产品，它们都是同样的三件事：

把这三件事搭起来，你就拥有了一个质量闸门。少掉任何一个，你拥有的都只是一个愿望。接下来这一节会说明，每个部分里应该放什么，然后我们会把这三部分全部接入 Hermes。

对于内容来说，你的测试案例就是你的黄金标准。

找出你最好的 20 到 50 篇作品：那些真正表现好的内容，那些被收藏的帖子，那些你愿意完整署上自己名字的文章。这就是「好」的样子。你不是在凭空发明一套标准，而是在提取你已经在最好状态下达到过的标准。

对于内容来说，你的指标就是一套评分量表。

一个分数是否可靠，取决于它背后的评分量表是否可靠。所以，你要把自己真正相信的「好内容标准」编码进去。对于内容，我会从四个标准给每一篇作品打分：

它是否解释了某件具体事情该怎么做，而不是只提供一种感觉；读者明天就能采取行动。

目标受众是否都能看懂；没有术语墙，也没有只有圈内人才懂的表达。

它是否结构清晰、可复用、按步骤展开，而不只是励志。

它是否足够新颖；读者此前并不知道这件事可以这样做。

覆盖在这四个标准之上的元标准是：读者会不会收藏这篇内容，并在之后回来照着执行？

如果答案是否定的，那无论文字读起来多干净，它都是 AI 垃圾内容。

关键在于评分量表本身。一个模糊的量表，比如「这篇内容好吗？有吸引力吗？」，只会产生模糊的分数。一个具体的量表，比如「这篇内容是否至少包含一个可以直接复制使用的模板或操作手册？」，才会产生你可以信任的分数。只有当你真的把自己的品味写下来，judge 才能继承你的品味。

对于产品来说，测试案例来自你的日志。

你要从日志、真实用户会话中提取你的功能真正遇到的输入，而不是只拿上线当天测试过的三个 happy path 示例。真正会击穿系统的，往往是那些奇怪的案例，而这些奇怪案例都藏在你的日志里。

对于产品来说，指标要匹配任务本身。

针对每一个输入，定义什么样的输出才算正确，然后让指标与任务类型匹配。如果只有一个正确标签，就用精确匹配；如果结构必须成立，就用验证器；如果输出是开放式的，就用语义相似度加 judge。指标只需要做到一件事：返回一个数字。因为只有数字，才能放进阈值里。

对于内容和产品来说，阈值就是你要守住的那条线。

0.7 是一个合理的起点。任何低于 0.7 的内容，都必须在发布前被重做或丢弃，没有例外。阈值只有在你永远不会因为「我挺喜欢这条」就放过一个 0.6 的结果时，才真正有效。它的意义，就是把深夜里那个带着自我投射的判断从决策中拿掉。

这就是 benchmark。现在，我们要让它自己运行起来。

在 Hermes 里搭建这个循环

Hermes 并没有自带一个 eval 按钮，也没有一个叫「质量」的仪表盘，让你点击「开启 AI 垃圾内容防护」。

但 Hermes 给你的东西其实更好：它给了你 eval loop 的原始组件。你只需要把这些基础能力组装一次，就能真正拥有它。

这些组件包括：它能自己编写并复用的 skills，会跨会话增长的持久记忆，内置的 cron，可以发送到任何平台的交付能力，Slack 里的审批按钮，以及写进核心机制里的自我改进习惯。

Hermes 称自己为「会和你一起成长的 Agent」。而这种成长，正是我们要搭建的循环。

所以，我们开始接线。一共六步。

第一步，把 Hermes 部署到它能够触达你的地方。

安装 Hermes，并把它接入 Telegram。这一点比听起来更重要，因为质量闸门只有在能够打断你时才真正有效。Hermes 可以运行在 20 多个渠道上，并能在 Slack 和 Telegram 中原生推送审批按钮。也就是说，Agent 可以在后台完成工作，并在需要你做决定时轻轻拍一下你的肩膀。

第二步，把你的黄金标准加载进记忆。

Hermes 拥有可以跨会话增长的持久记忆，并支持完整的跨会话召回。所以，你 benchmark 中那 20 到 50 篇最好的作品，只需要放进去一次，就会一直保留在那里。

这部分内容通常会分散在截图、旧草稿和零散文件里。但在这里，它会成为 Agent 的长期记忆，是可查询的，也是评分时用来对照的 ground truth。

第三步，把你的评分量表变成一个 judge skill。

这是整个系统的核心。你只需要用自然语言告诉 Hermes 一次：创建一个 skill，接收一段输出和你的评分量表，然后针对每一项标准返回一个 0 到 1 的分数，并附上一句理由。

这就是 LLM-as-a-judge：让一个 Agent 来评估你的 LLM 输出。配合一套清晰锋利的评分量表，模型会成为一个比你更稳定的批评者。因为它没有自尊心，也不会舍不得删掉那句你暗自得意的句子。

之所以要把它做成 skill，而不是一次性的提示词，是因为 Hermes 的 skills 本质上是程序性记忆。Agent 会编写它们、保存它们，并反复复用它们。你只需要把自己的品味编码一次，它就可以持续为之后的每一次输出打分。

而且，skills 是会复利的。Nous 发现，拥有 20 多个自创建 skills 的 Agent，在完成类似任务时速度会提高 40%，因为它们不再需要反复重新发现流程。你的 judge 也会在运行得越多时，变得越锋利。

第四步，把测试套件做成一个 skill，而不是一张表格。

你的测试案例和指标函数，会一起变成一个由 Hermes 保存并进行版本管理的 skill。指标库则根据具体任务来决定：分类任务用精确匹配；抽取任务用正则表达式；结构化输出用 JSON 校验器，以及 key-value 校验器；生成式输出则用语义相似度。

对于那些开放式任务，就使用你的 judge skill。Hermes 会自己编写评分代码。你只需要描述任务，它就会搭建相应的指标。所有这些都放在一个地方，由 Agent 自己管理，而不是散落在一张你迟早会找不到的表格里。

第五步，用回归测试和审批按钮守住发布关口。

这是整个系统里杠杆最高的习惯，也是最没人能长期手动坚持的习惯。所以，我们把它交给 Agent。

把流程接好之后，任何改动——新的提示词、替换的模型、调整过的流水线——都会自动触发测试套件。Hermes 会重新跑一遍所有案例，计算相较于基线的分数变化，然后不会悄悄发布，而是会在 Slack 里提醒你：「分数从 0.81 降到了 0.74，有两个案例出现回退，要批准吗？」

只有当你点击审批按钮之后，它才会继续推进。

你可以用 /goal 把它持续锁定在这个任务上，让 Agent 跨多轮对话始终围绕同一个目标执行。对于更大的任务，它的多 Agent 看板还能把运行流程拆解开来，并行评分，再安排执行时间。

这样，质量闸门就会变成一个常驻流程，而不是一件你必须记得手动去做的事。

第六步，用 cron 监测生产环境，并完成闭环。

Hermes 内置 cron，可以把结果发送到任何平台。因此，你可以安排一个定时任务，抽样真实执行结果，用同一个 judge skill 给它们打分，并在分数跌破标准线的那一刻私信提醒你。

这样，你能在质量开始下降的当天就发现问题，而不是等到一周后客户来投诉。

「eval 分数下降了」，这是一个你可以立刻处理的问题；「某个客户好像有点不高兴」，则不是。

接下来，是让整个系统开始复利的关键部分。

当你在 Slack 里对某个糟糕输出点下 thumbs-down，Hermes 会把它写回测试套件 skill，作为一个新的测试案例。那次失败的运行会变成一个永久检查项。

而且，由于自我改进是 Hermes 的核心机制，而不是后来外挂上去的功能，这套测试套件会每周自动变得更坚固。

你睡觉的时候，质量底线也在继续抬高。

这套系统真正跑起来之后，好的状态会非常具体：一篇内容如果在你的评分量表中低于 0.7，就永远不会被发布。一次产品改动如果让任何指标跌破基线，就会阻止部署，直到你亲自批准。

而生产环境中的分数线会保持平稳，或者持续上升。它开始下跌的那一天，就是 Hermes 提醒你的那一天，而不是等到一周后用户流失数据才显现出来。

没人想听的部分

你的 AI 输出之所以不稳定，不是因为你不会写提示词，也不是因为模型还不够聪明。

而是因为你只运行了生成步骤，却没有运行质量步骤。你搭建的是半套系统，却一直在责怪那半套真正起作用的部分。

修复方式不是换一个更好的提示词，而是补上缺失的那一层。

定义什么是好，把它变成一个数字，用这个数字评估每一次输出，拦住所有低于标准线的结果，并完成闭环，让质量底线每周自动抬高。

现在，这一层不再是某个「以后再做」的项目，而是在你自己的机器上、通过一个 Agent、用六个步骤就能跑起来的系统。

做到这一点之后，AI 垃圾内容就不再是随机发生在你身上的东西，而会变成每次出门前都能被你拦下的东西。就像一家真正的工厂，会在缺陷产品抵达客户之前就把它截住。

提示词从来不是系统。

eval loop 才是系统。Hermes 是它运行的地方。

现在，你已经拥有它了。

[原文链接]