我如何在自己的AI管道中发现了多客户博客质量漂移（并在一个下午内解决了它）

太长不看

一位客户给我发来了一张他们每周 SEO 健康报告的截图。报告上写着"36 天未发布自动博客"。这是错的——我的自动发布定时任务一直每周运行两次，全程都在发送成功通知邮件。于是我开始追查这个监测漏洞。结果发现的不是一个问题，而是两个：

1. 监测漏洞。 审计程序读取了错误的表。修复只花了 15 分钟，外加从 Sanity 回填了 79 行数据。2. 真实的内容质量漂移。 在修复第 1 个问题的过程中，我审计了过去 30 天流水线发出的每一篇博客文章。6 个客户共 48 篇文章中，有 35 篇未达到质量底线。 字数太少、缺少主图、零内链、没有 TL;DR 或 FAQ 标题。

修复方案在同一天下午上线：在发布路径中加入一个质量门，凡是没有主图、字数低于 1,500、缺少 TL;DR 标题、缺少 FAQ 标题、或内链少于 3 条的文章，一律拒绝发布。我还写了一个跨客户审计脚本，每晚扫描所有客户的 Sanity 项目，并将失败清单发到我的邮箱。

这篇文章是事后复盘。如果你也在跨多个客户运行内容流水线，同样的漂移很可能正在发生。以下是我发现它的过程，以及我做出的改变。

我在运行什么

作为背景介绍——我运营一套 AI 驱动的内容流水线，负责向六个客户网站发布长篇 SEO 博客文章。每个客户都有自己独立的 Sanity CMS 项目。文章由一个定时任务每周发布两次，流程如下：

1. 拉取该客户在 Search Console 中的"冲刺距离"关键词（排名第 5 到第 20 位，且有真实曝光量）。2. 使用特定文案风格（Halbert、Hopkins、Wiebe、Ogilvy 等）通过 Claude 写一篇 2,500 字的文章。3. 进行 E-E-A-T 评分和违禁词过滤。如果文章得分低于 10 分中的 7 分，则返回重写，最多重试 2 次。4. 获取一张主图和 2 张正文图，添加水印后上传至 Sanity。5. 将文档发布到 Sanity，客户的 Next.js 网站在下次页面请求时即可获取。6. 向 Facebook、Instagram、Threads 和 LinkedIn 发送社交预告。

这套流水线我已经运行了大约 4 个月。过去 45 天里，大约有 90 篇文章经由它发布。整个流程在 Windows 任务计划程序上无人值守运行。每次运行后我会收到一封摘要邮件。关于背后框架的更多内容，请参阅服务页面。

第一次客户投诉

客户最先指出的问题是那份周一的 SEO 健康报告。报告的核心数字显示"36 天未发布自动博客"——但他们不到一周前才收到过我的成功通知邮件。他们的疑问本质上是：这两者，哪个在撒谎？

当两条证据相互矛盾时，正确的做法是找到它们各自读取的表，然后检查表里实际存放了什么。于是我追查了报告代码：

const pubRes = await pool.query(` SELECT domain, MAX(completed_at) AS last_pub FROM content_tasks WHERE status = 'published' AND completed_at IS NOT NULL GROUP BY domain `);

它读取的是 `content_tasks`。然后我追查了自动发布定时任务。自动发布定时任务写入的是 `seo_alerts` 和 `distribution_tasks`，不写入 `content_tasks`。成功邮件是真实的。审计程序读取的是一张定时任务从未触碰过的表。

这个差距已经存在了 36 天，原因是那是最后一次有人通过仪表盘界面发布内容——仪表盘走的是另一条路径，那条路径确实会写入 `content_tasks`。一个多月以来，仪表盘路径一直处于闲置状态，因为所有发布工作都已切换到定时任务。

修复 #1： 我在自动发布脚本的成功分支中加入了一条 `INSERT INTO content_tasks (...)` 调用，以便未来的运行被正确追踪。然后我写了一个一次性脚本，从每个客户的 Sanity 项目中回填了过去 45 天的数据。共写入 79 行。审计指标现在与实际情况吻合。

这大约花了 25 分钟和三条 SQL 查询。

更深层的问题

在检查 Sanity 以构建回填数据的过程中，客户发来了第二条消息。他们点进了一篇最近的博客文章，发现内容单薄——不到 500 字，没有主图，没有内链，没有 TL;DR，没有 FAQ。他们说："这就是我在各个客户之间一直看到的质量漂移。为什么？"

现在有两件事已经很清楚：

• 这篇文章确实存在于 Sanity 中。
• 自动发布定时任务的质量门会拒绝它。每一道门都应该拦住它：字数低于 2,500、没有图片、没有内链、没有 FAQ 标题。

那么它是怎么发布出去的？

我直接查询 Sanity 来查看文档 ID。自动发布定时任务使用确定性前缀：`blog-autopub-{timestamp}`。这篇单薄的文章有一个不同的前缀：`blog-{domain-with-dashes}-{slug}`。这个命名模式来自另一个文件——仪表盘库中的 `sanity-publish.ts`，被仪表盘的"发布到 Sanity"按钮所调用。

同一个 Sanity 项目存在两条并行的发布路径，而且只有其中一条强制执行质量门：

路径 文档 ID 前缀 E-E-A-T 图片 字数底线 TL;DR + FAQ

------ --------------- --------- ------- ------------ -------------

定时任务 `blog-autopublish.cjs` `blog-autopub-...` 是 是 是（2,500） 是

仪表盘 `sanity-publish.ts` `blog-{domain}-{slug}` 否 否 否 否

仪表盘路径是一个遗留产物，来自早于定时任务的旧内容工作流。它依然可用。任何点击仪表盘中"发布到 Sanity"按钮的人，都可以将一篇 200 字的草稿直接发布到客户的正式域名，完全不经过任何检查。这种架构盲区在大多数多客户配置中可能都存在——关于我如何看待流水线门控的设计理念，请参阅我的 AI 自动化服务页面。

让我意外的审计结果

在修复质量门之前，我想先了解漂移的范围。于是我写了一个 200 行的审计脚本：查询每个客户的 Sanity 项目、对过去 30 天的每篇文章按质量底线打分，并写出一份 Markdown 报告。首次运行拉取了 6 个客户共 48 篇文章。

其中 35 篇未达到底线。 不只是那几篇明显走了绕过路径的文章。细分如下：

• 3 篇绕过路径文章 — 单薄、无图、无标题。正是客户指出的那种模式。
• 32 篇定时任务路径文章 — 大多数失败原因是"内链 < 3"和"无 TL;DR 标题"。少数是"无主图"（尤其是 CinCin 过去 30 天的每一篇文章）。

定时任务一直在其 Markdown 输出中写入 TL;DR 段落，但 Markdown 转 PortableText 的转换过程将标题样式丢掉了。内链也是同样的问题——内链在 Markdown 中存在，但转换过程丢弃了 Sanity 渲染实际链接所需的 `markDef` 条目。还有一个客户的 `blogPost` schema 专门使用 `heroImage` 字段（其他客户的 `post` schema 使用 `mainImage`）——当图片上传步骤静默失败时，发布流程继续执行，导致文章没有图片。

所以定时任务的质量门评分的是源 Markdown，但落到 Sanity 里的文档并不总是保留了 Markdown 的质量。质量门说"内容合格"，而发布出去的文档却"不够合格"。

我做出的改变

三件事，按顺序执行。

1. 共享库中的质量门

我在仪表盘的 `sanity-publish.ts` 库中添加了一个 `validateContentMeetsProtocol()` 函数。它在任何 Sanity mutate POST 之前运行。如果内容没有主图、字数低于 1,500、内链少于 3 条、没有 TL;DR 标题，或没有 FAQ 标题，发布调用将返回 `success: false, error: 'blocked_quality_gate: ...'`，数据库行被标记为 `status = 'blocked_quality_gate'`。文章永远不会到达 Sanity。

底线有意低于我定时任务 2,500 字的目标，因为手工整理的内容有时候确实合理地落在 1,600 到 2,000 字之间。这道门的目的是拦住单薄的垃圾内容，而不是惩罚边界情况。

环境变量绕过选项仅供真正的紧急热修复使用——但每次绕过都会被记录。对于我为客户运营的更广泛流水线设计，同样的门控理念适用于我们交付的每一项服务。

2. 跨客户每夜审计

我写了 `blog-quality-audit-all-clients.cjs`。它每夜扫描每个客户的 Sanity 项目，对每篇文章按同一协议打分，写出 Markdown 报告，并在任何客户有失败文章时给我发送摘要邮件。如果全部通过，则不发邮件。默认静默。

脚本还会为每个失败项打上来源路径标签（`AUTOPUB`、`BYPASS` 或 `OTHER`），让我一眼就能判断是哪条流水线出了问题。今天首次运行捕获了 32 篇定时任务路径的失败文章，否则我永远不会注意到它们。关于更广泛的 AI 自动化系统详见此处。

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

我列了一份定时任务本身的后续修复清单：修复 Markdown 转 PortableText 的转换以保留链接 `markDef` 和标题样式；将 `heroImage` 字段的图片上传步骤改为失败时中断，而不是静默地发布一篇无图文章；如果没有任何实时来源返回图片，则强制使用品牌默认备用图。这些修复将在未来几天内落地，届时审计脚本会告诉我每个客户的失败数何时降到零。

如果你在运行 AI 内容流水线，这件事为什么重要

如果你跨多个网站批量发布 AI 生成的内容，以下是我用代价换来的经验：

1. 每条发布路径都需要相同的门。 如果你同时有定时任务、仪表盘按钮和 CLI 脚本，这三者都需要相同的最低质量验证。否则，垃圾内容就会从没有防守的那条路流出去。将质量门集中放在一个共享库中，让三者都调用它。2. 对来源进行评分，不等于对目标进行评分。 如果你的门评分的是 Markdown，但你的 CMS 转换步骤静默地丢弃了内容，那你的门形同虚设。也要对目标文档进行评分——这正是审计脚本为我做的事。3. 审计遥测必须是跨客户的。 各客户独立的仪表盘会掩盖跨客户的回归问题。"过去 30 天每篇文章都没有图片"这个规律，在我同时查询所有客户之前一直是不可见的。4. 监测漏洞和质量漏洞从外部看起来是一样的。 "仪表盘显示零篇文章"和"文章全都很差"，看起来都像"流水线坏了"。唯一能分辨的方法，是直接读取仪表盘读取的那张表，然后对流水线实际产出的文档进行抽样。5. 在信任质量门之前，先建立审计机制。 质量门会失效打开（fail open）。审计会捕获质量门遗漏的内容。两者都要有。

整套方案——质量门、审计、回填、事后复盘——大约花了 4 小时专注工作。大部分时间是读代码，而不是写代码。审计脚本将在未来 24 小时内捕获下一次漂移，而不是等到 6 周之后。

FAQ

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

运行两个独立层。第一层是在每条发布路径设置质量门——一个函数，除非文章满足清晰的质量底线（字数、主图、内链、FAQ 标题），否则拒绝发布。第二层是跨客户审计，每日扫描你的正式 CMS，并在任何文章不达标时通知你。质量门会静默失效；审计会发现它们。

内容流水线中的监测漏洞和质量漂移有什么区别？

监测漏洞意味着你的仪表盘或审计程序读取了错误的来源，导致它报告了不真实的失败，或隐藏了真实存在的失败。质量漂移意味着内容本身在退化——即使你的仪表盘说一切正常。从外部看，两者一模一样（"流水线好像有问题"）。要区分它们，需要对流水线实际产出的文档进行抽样，并与仪表盘的声明进行对比。

如何判断我的 AI 内容流水线是否存在多条发布路径？

检查 CMS 中的文档 ID。大多数自动化脚本使用确定性前缀（时间戳、slug、文档类型标签）。如果你在同一内容类型下发现多个不同的前缀模式，那么你很可能有多条发布路径，而且其中至少有一条没有执行与其他路径相同的门控。

我应该对 AI 生成的博客内容强制执行的最低质量底线是什么？

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

AI 生成的正式内容应该多久审计一次？

对于多客户配置，每夜是正确的节奏。对六个项目每夜运行一次 Sanity 查询的成本几乎为零，而一篇文章错过发布一周，在第 2 天发现比在第 30 天发现要便宜得多。如果你只运行一个网站，每周一次就够了。如果你运行的客户超过六个，你可能需要一套真正的监控系统，而不是一个 shell 脚本。

审计邮件应该包含什么内容？

只需包含足以判断是否需要行动的信息。我包含一张每客户汇总表，显示文章总数、通过数和失败数，外加几个失败 slug 的示例。如果全部通过，脚本则不发送邮件。沉默即成功信号。完整的每篇文章详情写入 Markdown 报告文件，只有当摘要告诉我需要查看时才打开。

如何修复已经不达标的正式文章？

不要删除它们——那会丢失数据和链接权重。将 CMS 中文章的 slug 修改为 `archived-{original-slug}-{date}` 前缀，这样文章就不再以其正式 URL 对外提供服务，但仍然可以恢复。该 URL 将返回 404（或者，如果有一篇符合质量门的同 slug 文章，则该文章正常提供服务）。对于有可衡量流量或外部链接的文章，添加一个 301 跳转到相关枢纽页面或符合质量门的版本。今天下午我用这种方法归档了 6 篇正式文章，用一个一次性脚本通过每个项目的 Sanity mutate API 完成，耗时约 5 分钟。

下一步

如果你想要这个审计脚本用于自己的流水线，请通过联系页面给我发信，我会分享源码。大约 200 行 Node.js 代码，除了 Sanity REST API 和可选的 Resend 邮件 key 之外，没有任何依赖。

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