正在加载，请稍候
2026 年 8 月 Google spam update 与 AI slop 反噬同时发生，内容自动化的环境彻底变了。这篇聊边界：节奏可以自动，内容生产不能全自动，以及一个随机 tick 调度器的最小实现。
2026 年 8 月 22 日，Google 上线当月 spam update；同一周，Spotify、LinkedIn 在清理 AI slop，AI 实验室开始购买 2022 年前的旧书给训练数据"避雷"。内容自动化的环境变了，但"全盘停掉"也不是答案。这篇聊边界：什么该自动，什么不该。
第一个信号来自搜索引擎。Search Engine Journal 报道，Google 8 月 spam update 在 8 月 22 日前后上线，同期生成式 UI 进入 AI Overviews，Reddit 的 ChatGPT 引用份额在下降。这是 2024 年以来"打击规模化低质内容"思路的延续：不是禁掉自动化，而是惩罚没有增量价值的批量生产。
第二个信号来自内容平台。SEJ 评论文章观察到，Spotify 和 LinkedIn 都在清理 AI slop，SEO 行业被迫在"把 AI 当捷径"和"把 AI 当编辑助理"之间做选择。第三个信号更隐蔽：AI 实验室开始买 2022 年以前的书籍来避开 AI 生成文本污染训练集，同时悄悄建设文本水印能力——机器在识别机器，内容规模化整体进入逆风期。
自动化的对象应该是发布流程，不是内容生产。把"写完-审完-发布-推送"这段流程自动化，收益明确且风险可控；把"选题-撰写-配图"也交给流水线，就是在制造 AI slop——AI 提交 1721 行 diff 后审查者直接关掉 PR，问题不在速度，在产出不可审。
为什么固定时刻批量发布会变成机器信号？没有一条官方规则叫"你必须随机时间发"，但工程上，每天 10:00 准时发一篇、每周三 16:00 固定更新，这种稳定可预测的模式配合正文薄弱、同主题重复，很容易被归入自动生成聚类的判断。国内搜索的劲风、飓风、蓝天算法分别处理低质聚合、跨站采集与软文堆砌，发布规律性是判断"自动生成站"的辅助特征之一。我们的判断是：固定时刻本身不是惩罚项，它是放大器——内容越薄，发布越规律，风险越高。
自动化最容易犯的错是"反正自动了，多发几篇"。我们沿用的参数是：单日 blog 不超过 2 篇、case 不超过 1 篇；单周 blog 8–10 篇、case 不超过 3 篇。上限的意义不是保守，是避免整站呈现"稳定高产"的采集站特征。今天没有就绪内容就不发，调度器空转比硬发一篇低质稿更健康——自动化省下的时间，最后往往会花在治理上，388 个 PR 背后的成本拐点是同一笔账。
内容侧同样要设边界。AI 的正确位置是编辑助理：生成初稿、做资料整理、给结构建议；人工负责判断、补一手数据、写"我们实际怎么做的"段落。这和我们在用 AGENTS.md 管住 AI 生成的 PR里的经验一致：给工具的自主权越大，越需要显式的约束。2026 年还在用 AI 当流水线、直接批量出稿的站点，会被平台和搜索引擎两头夹击。
每天凌晨生成当天 3–6 个发布时刻，均匀分布在 08:00–23:00，加随机偏移。tick 数量按权重采样：3 个、4 个、5 个、6 个的概率分别是 0.3、0.3、0.25、0.15，不会形成可学习的周期。
每个 tick 触发时扫描 draft 队列，只发"质量就绪"且最旧的一篇；队列空就空转，不补发。发布时刻服务于内容，而不是内容迁就时刻。
沿用上文参数：日上限 blog≤2、case≤1；周上限 blog 8–10、case≤3。上限写进调度器，而不是靠人自觉。
每篇发布后立即走 IndexNow 和百度主动推送。飓风类算法看首发率：谁先被抓到算谁原创。我们每天主动推送上限 50 个 URL，远用不完。
下面是一个可跑的 TypeScript 骨架，核心是三个函数：按权重采样 tick 数量、生成当天随机时刻、到点执行时先做幂等和上限检查。
type Tick = { hour: number; minute: number };
const WEIGHTS = [0.3, 0.3, 0.25, 0.15]; // 3,4,5,6 个 tick 的概率
function pickTickCount(): number {
const r = Math.random();
if (r < 0.3) return 3;
if (r < 0.6) return 4;
if (r < 0.85) return 5;
return 6;
}
function genTicks(count: number, start = 8, end = 23): Tick[] {
const set = new Set<number>();
while (set.size < count) {
// 分钟粒度随机，不刻意避开整点
const m = Math.floor(Math.random() * (end - start) * 60) + start * 60;
set.add(m);
}
return [...set].sort((a, b) => a - b)
.map((m) => ({ hour: Math.floor(m / 60), minute: m % 60 }));
}
async function runTick(now: Date): Promise<void> {
if (await alreadyPublishedToday(now)) return; // 幂等：同日不重复发
if (await todayReachedLimit(now)) return; // 日上限 blog ≤ 2, case ≤ 1
const draft = await oldestReadyDraft(); // 质量门禁 + 最旧优先
if (!draft) return; // 队列空，空转
await publishPost(draft);
await pushIndexNowAndBaidu(draft); // 首发率
}上线时注意两点：调度进程用北京时间做时区锚定；当天 tick 列表要落库，防止进程重启后重新生成导致一天发两轮。
第一版发布器就是固定时刻：每天 10:00 和 16:00 各发一篇。两周后巡检发现两个问题：同一天出现多篇同主题文章撞车，正文文本指纹高度相似；标题和 SEO Title 几乎一样的姊妹文反复出现。根源是多人各自创作、到点就发，缺少前置检查。
改成随机 tick 之后，撞车没有消失——因为随机时刻不解决内容重复，只解决节奏信号。最终是"随机 tick + 发布前同日检查 + 同主题查重"三个动作合在一起才把问题压住。
另一个坑在运营侧。内容团队习惯了可预期性，随机时刻让他们不适。我们在后台加了一个"今日 tick 窗口"展示（09:12 / 14:47 / 20:03 这种），问题才缓解。调度器是给人用的，不是给服务器用的。
还有一条反面经验：动态调度救不了 AI 灌水。如果正文本身是模型批量生成的同质段落，发布时间再随机也会被 AI slop 反噬。2026 年的做法是把 AI 当编辑助理——生成初稿、人工补判断、加一手数据——而不是让它当流水线。
不能直接影响。它降低的是"机器行为"特征信号，只有配合内容质量、首发率、内链结构才有意义。把随机 tick 当成排名开关是误解。
因为固定表会被学习，而且人工维护成本高。用真随机 + 幂等检查，进程重启也不会重复发，比维护一张静态表更省事。
不适合。新闻资讯站有时效性压力，必须抢首发；只有内容产出相对稳定、以常青词为主的 B 端技术站才适合。产品页和案例页也不建议走随机，它们有明确的更新语义。
不会。发布总量上限没变，只是时刻变了，爬虫抓取压力不变。真正浪费预算的是大量低质页面，不是发布时间。
分两步：先加"同日查重 + 日/周上限"，把重复风险压下来；再改成随机 tick。一次性全改，运营侧和内容侧都会不适应，容易回滚。