我如何在自己的 AI 流水线里抓到一次跨客户的博客质量漂移（并在一个下午内堵上）

TL;DR

一位客户指着他们每周的 SEO 报告说：报告显示自动博客已经停止发布。这是错的，我的发布任务一直按计划运行，也一直在发送成功通知。于是我开始追查这个度量漏洞，结果发现的不是一个问题，而是两个：

1. 度量漏洞。 报告读取的是发布任务从未写入的记录。2. 真实的内容质量漂移。 在修复第一个问题时，我审计了各客户博客最近发布的文章，其中有太多没有达到我自己的质量底线：字数单薄、缺少主图、内链太少、没有 TL;DR 或 FAQ 标题。

修复方案：在共享发布代码中加入一道质量门，文章必须有主图、至少 1,500 字、TL;DR 标题、FAQ 标题，以及至少 3 条内链，否则拒绝发布。我还建立了一个跨客户审计，按同一底线检查已发布的文章。

这篇文章就是这次复盘。如果你也在为多个客户跑内容流水线,同样的漂移多半正在你这里发生。下面是我如何抓到它的,以及我改了什么。

我当时跑的是什么

作为背景：我运营一条 AI 驱动的内容流水线，向多个客户网站发布长篇 SEO 文章。每个客户都有自己的 CMS 项目，文章按计划发布。流程如下：

1. 从 Search Console 拉取客户已经排在首页边缘、且有真实曝光量的关键词。2. 用 AI 模型起草长篇文章。3. 进行质量评分和违禁词过滤，把较弱的草稿退回重写。4. 加上主图和正文图片。5. 把文档发布到 CMS，客户网站随即获取。6. 排入社交预告。

整个流程无人值守运行，每次运行后会发送摘要。关于背后框架的更多内容，请参阅服务页面。

第一个投诉

客户最先指出的是每周 SEO 报告。报告的核心数字显示自动博客已经好几周没有发布，但他们最近才收到过发布成功通知。他们的疑问本质上是：这两者，哪个在撒谎？

当两条证据互相矛盾时，就去找它们读取的记录，检查里面实际存放了什么。于是我追查了报告代码。

报告是从一张追踪表统计发布次数的。按计划运行的发布任务从不写入这张表，它把运行记录写在别处。成功通知是真实的，报告读取的却是发布任务从未碰过的记录。

这个缺口可以追溯到最后一次有人通过旧仪表盘按钮发布内容的时间，那条路径会写入这张表。之后所有发布都转到了定时任务上。

修复 #1： 定时任务现在每次发布都会写入一条追踪记录，并用一次性的回填从 CMS 补齐了缺失的历史。报告现在与实际情况吻合。

更深一层的问题

在为回填检查 CMS 的过程中，客户又指出了另一件事：一篇最近的文章内容单薄，没有主图、没有内链、没有 TL;DR，也没有 FAQ。

到这里有两件事很清楚了:

• 这篇文章确实存在于 Sanity 里。
• 定时任务的质量检查本来会拒绝它：太短、没有图片、没有内链、没有 FAQ 标题。

那它是怎么发出去的?

我查看了 CMS 里的文档 ID。定时任务用一种固定模式命名文档，这篇单薄的文章用的却是另一种模式，而那种模式来自旧仪表盘的“发布”按钮。

同一批 CMS 项目存在两条发布路径，而只有其中一条执行质量门。

定时任务会做质量评分、图片检查、字数底线以及 TL;DR 和 FAQ 检查；仪表盘按钮一项都不做。

仪表盘路径是早于定时任务的旧工作流留下的产物，但依然可用。任何人点击那个按钮，都可以把一篇很短的草稿直接发布到客户的正式网站，完全不经过检查。这种盲区在很多多客户配置中可能都存在；关于我如何看待流水线门控，请参阅我的 AI 自动化服务页面。

让我意外的那次审计

在修补质量门之前，我想先了解漂移的范围。于是我写了一个审计脚本：查询每个客户的 CMS 项目，按质量底线给最近的文章打分，并写出报告。

失败的文章不只是那些明显走了绕过路径的。 细分如下：

• 绕过路径的文章： 单薄、无图、无标题。正是客户指出的那种模式。
• 定时任务路径的文章： 大多数失败原因是内链太少和缺少 TL;DR 标题，也有一些文章完全没有主图。

定时任务在 Markdown 输出中写了 TL;DR 段落，但 Markdown 转换为 CMS 格式时丢掉了标题样式。内链也一样：Markdown 里有，转换时却丢掉了 CMS 渲染链接所需的链接定义。另外在其中一个网站的 schema 上，图片上传失败并不会中断发布，于是文章在没有图片的情况下发了出去。

所以定时任务里的质量闸门评的是源 markdown,但最终落到 Sanity 的文档并不总是把 markdown 的质量带过去。闸门说"好内容";发出去的文档却"不够好"。

我改了什么

三件事,按顺序来。

1. 在共享库里加一道质量闸门

我在共享发布代码中加入了一个校验步骤，在任何写入 CMS 的操作之前运行。如果文章没有主图、字数低于 1,500、内链少于 3 条、没有 TL;DR 标题或没有 FAQ 标题，发布调用就会失败，并给出明确的“被质量门拦截”原因，文章永远不会到达 CMS。

这个底线有意低于定时任务自己的篇幅目标，因为精心编辑的内容有时合理地会短一些。它的目的是拦住单薄内容，而不是惩罚边界情况。

真正的紧急热修复可以走一个绕过选项。同样的门控理念适用于我们交付的每一项服务。

2. 跨客户审计

我写了一个审计，扫描每个客户的 CMS 项目，按同一协议给每篇文章打分，写出报告，只有出现失败时才发送摘要。全部通过时保持安静。

它还会为每个失败项标注发布它的路径，让我一眼就能判断是哪条流水线出了问题。关于我如何搭建 AI 自动化系统，详见此处。

3. 定时任务端的修复积压清单

我还给定时任务列了后续修复：把 Markdown 转换为 CMS 格式时保留标题样式和链接定义；主图上传失败时中断发布，而不是发布一篇无图文章；没有任何来源返回图片时，改用品牌默认图。审计会显示每个客户的失败数是否在下降。

如果你也在跑 AI 内容流水线,这件事为什么对你重要

如果你在跨多个站点批量发布 AI 生成的内容,以下这些是我用代价学到的:

1. 每条发布路径都需要同一道门。 如果你同时有定时任务、仪表盘按钮和 CLI 脚本，三者都需要相同的最低校验，否则单薄内容会从没有防守的那条路流出去。把质量门放在三者共同调用的共享代码里。2. 对来源评分，不等于对目标评分。 如果你的门评的是 Markdown，而转换到 CMS 的步骤丢了内容，那这道门就形同虚设。也要给已发布的文档打分。3. 审计要跨客户。 各客户独立的仪表盘会掩盖跨客户的回归。某个网站缺图的规律，在我同时查询所有客户之前一直看不见。4. 度量漏洞和质量漏洞从外面看一模一样。 “报告说零篇文章”和“文章很单薄”看起来都像“流水线坏了”。要分辨，就去读报告读取的那条记录，再抽样流水线实际产出的文档。5. 在信任质量门之前，先建立审计。 质量门可能失效放行，审计能抓住质量门漏掉的内容。两者都要有。

大部分工作是读代码，而不是写代码。审计的作用，是尽早抓住下一次漂移，而不是几周后才发现。

FAQ

如何防止 AI 生成的博客内容随时间出现质量漂移?

运行两个独立层。第一层是在每条发布路径设置质量门：一个函数，文章不满足明确的质量底线（字数、主图、内链、FAQ 标题）就拒绝发布。第二层是跨客户审计，定期扫描你的正式 CMS，并在任何文章不达标时提醒你。质量门可能静默失效；审计会发现。

内容流水线里的"度量 bug"和"质量漂移"有什么区别?

度量 bug 指的是你的仪表盘或审计在读错误的来源,所以它要么报告了不存在的失败,要么把真实的失败藏了起来。质量漂移指的是内容本身正在退化——即便你的仪表盘说一切正常。两者从外面看是一样的("流水线好像不对劲")。要分清楚,只能采样流水线实际产出的那些工件,把它们和仪表盘的说法做对比。

怎么判断我的 AI 内容流水线是不是有多条发布路径?

去看你 CMS 里的文档 ID。绝大多数自动化脚本用的都是确定性前缀(时间戳、slug、文档类型标签)。如果你在同一种内容类型下看到了多种明显不同的前缀模式,那你多半就有多条发布路径,而其中至少有一条没有执行和其它路径一样的闸门。

AI 生成的博客内容,我最少该设多高的质量底线?

对于以 SEO 为目标的内容，我的底线是：至少 1,500 字、一张主图、一个 TL;DR 或核心要点标题、一个 FAQ 标题，以及至少 3 条指向同一域名其他页面的内链。那是底线，不是目标。底线是为了阻止最严重的漂移，而不是定义什么是好内容。

多久审计一次线上 AI 生成的内容合适?

对于多客户配置，每天一次是合理的节奏。对几个 CMS 项目定期查询的成本很低，而一篇单薄的文章在第 2 天发现，比在第 30 天发现要便宜得多。如果只有一个网站，每周一次通常就够了。客户越多，就越应该从脚本升级到正式的监控系统。

审计邮件里应该写什么?

只需足够判断是否需要行动：每个客户一张表，显示文章总数、通过数和失败数，外加几个失败 slug 的示例。全部通过时什么都不发。沉默即成功信号。每篇文章的详细信息放进报告文件，只有摘要提示时才打开。

已经掉到质量底线之下的线上文章应该怎么补救?

不要删除它们，那会丢失数据和链接权重。一种做法是把 CMS 中文章的 slug 改为带日期的归档前缀，这样文章不再以正式 URL 提供服务，但仍可恢复。对于有可衡量流量或外部链接的文章，添加 301 跳转到相关枢纽页面或修正后的版本，而不是让 URL 返回 404。

下一步

如果你想在自己的流水线上加上这样的质量门和审计，欢迎通过联系页面联系我。

更大的教训是：自动化给你规模，却让你失去可见性。如果你看不到流水线昨晚发出了什么，你就不会注意到漂移，直到客户指着一篇单薄的文章问你为什么。审计现在就是替我看的那双眼睛。