太长不看版： 用 AI 大量发文，错误很少是「某一篇写烂了」，几乎都是模板或流程的问题，一出错就是十几篇一起错。我们接手的一个视频内容站，每天好几个人同时发、每人约 30 篇，最后收敛成一套做法：发布前跑 12 个检查项，发布后用真实浏览器打开前台、等 5 秒、滚动到底，自动修正脚本修完一定要再跑一次检查，任一项命中就不准发。另外三条验证纪律：看真实 DOM 不看原始 HTML、用对 UA、非当前标签页跑出来的「视频不能播」要用当前标签页复查。
批量发文的错是模板性的，一错就是十几篇
1 个模板或流程缺陷，就会让当天经过同一条流程的十几篇文章一起出错，所以要靠固定检查项而不是逐篇人工审稿。
那个视频内容站的发文量是这样的（以下做法是 2026 年 10 月在那里整理出来的）：好几位编辑同时用 AI 辅助产出，每人一天大约 30 篇。这种量下，任何一个步骤有缺陷，例如素材清洗少一道、编辑器把某种图片语法吃掉、某个图床域名挂了，都不会只影响一篇，而是当天经过同一条流程的所有文章。
这件事改变了质量管理的思路。逐篇人工审稿在这个量下做不完，而且人眼最容易漏的正好是重复出现的小错，看到第五篇就习惯了。比较有效的做法是反过来：把「曾经出过的错」整理成固定的检查项，每篇都跑一遍，跑不过就不发。检查项是从事故里长出来的，不是从理论推出来的，所以清单会越来越长，但每一项都对应一次真实发生过的问题。
这也是 Google 在意的地方。它的生成式 AI 内容指引↗并不反对用 AI 写，但讲得很清楚：如果用生成工具大量产出没有替用户增加价值的页面，可能会落入垃圾内容政策↗里的「滥用大规模内容」。一批带着生成残留、图片破掉、结尾离题的文章，在用户眼中就是低质量的大量页面，不管它是怎么产生的。质量关卡挡的就是这种批量。
发布前 12 项检查清单（通用版）
AI 批量发文的发布前检查清单共 12 项，分成内容一致性、生成残留、媒体语法三组，每一项都来自实际出过的事故。
下面是我们实际在用的 12 项，顺序照「内容对不对、有没有生成残留、媒体语法对不对」分成 3 个分组。每一项都是在那个站上真的出过事才加进来的。
内容与分类
- 分类／频道对不对。 批量发文最常见的是整批被丢进同一个默认分类，或沿用上一批的设置。
- 标题和正文一致。 AI 有时改了标题角度，正文还在讲原本的题目。也有人工改了标题、正文没跟着动。
- 素材来源残留的品牌名。 素材里的其他网站名称、品牌名、水印文本被带进正文，读者会以为是那个品牌的内容，也可能让整篇看起来像搬运。
- 孤儿标题。 一个小标题下面什么都没有，通常是生成到一半被截断，或段落被清洗规则整段删掉。
- 重复句。 同一句话在文中出现两次以上，常见于分段生成后拼接。
生成残留
- 生成标记残留。 像
[[…]]这种提示词或模板占位符留在正文里。 - 文末垃圾。 文章结尾多出离题的新闻、AI 分析腔的总结、说教句、「欢迎在留言区分享你的看法」这类评论引导，或文件名残渣。
图片与视频语法
- 引用式图片语法。
![x][1]这种写法在某些编辑器或前台渲染器不会被转成图片，前台直接露出源代码。 - 失效的图床域名。 图片网址指向已经停用的图床，后台看得到网址，前台是裂图。
- 第一张图漏了
!。 少一个惊叹号，图片就变成一条普通链接。 - 图片 ALT 不能是文件名。
IMG_2041.jpg当 ALT，对读者和搜索引擎都没有信息。 - 视频网址只留站内路径。 只存
/videos…开头的路径，不写死域名。视频域名一换或一失效，写死域名的整批文章就同时坏掉。
如果你的站不是视频站，第 8 到 12 项可以换成你自己的媒体格式，但分组的逻辑照用：内容一致性、生成残留、媒体语法，这三类错的成因不同，检查方式也不同。前两组大多能用文本比对抓，第三组有一部分只有在前台才看得出来，下一节讲。
为什么后台看不出来：只有前台会露出的错
批量发文的图片和视频错误后台看不出来，因为数据没问题、坏在渲染层，所以发布前检查之外，必须再加一道看前台成品的验收。
我们在那个站上学到最贵的一课是：后台编辑框看起来正常，不代表前台正常。 引用式图片 ![x][1] 在编辑框里就是一行看起来合理的 markdown，保存也不会报错，但前台渲染出来是一串源代码。失效的视频域名也一样，后台只看到一个网址字符串，要真的在前台按播放才知道它连不到。
这两种错有个共同点：它们在「数据」层面没问题，坏在「渲染」层面。只检查数据的关卡永远抓不到它们。发布前的 12 项因此只是第一道，发布后还要有一道直接看前台成品的验收，两道各挡不同的错，缺一道就有一类错会稳定漏掉。
前台验收的另一个好处是它会顺便抓到「12 项以外」的新型错误。清单只能挡已知的问题，前台验收是唯一能看到未知问题的地方。每次前台抓到清单没列的错，就把它补进清单，这张清单就是这样一路长到 12 个检查项的。
| 关卡 | 什么时候跑 | 挡得住 | 挡不住 |
|---|---|---|---|
| 发布前 12 项 | 保存送出前 | 生成残留、品牌名残留、语法错 | 渲染后才坏的图片与视频 |
| 修后检查（lint） | 每次自动修正之后 | 修正规则没涵盖的变体、修正造成的新错 | 一样挡不住渲染层的错 |
| 前台验收 | 发布后 | 裂图、源代码外露、视频不能播、清单外的新错 | 量大时只能靠自动化＋抽样 |
发布后前台验收：真实浏览器、等 5 秒、滚动到底
批量发文的前台验收要用真实浏览器打开文章、等 5 秒、滚动到底，再核对图片数量、检查源码外露并实际点播视频。
我们的前台验收步骤很短，但每一步都有原因：
- 用真实浏览器打开文章页，不是用 curl，也不是看后台预览。
- 等 5 秒，让延迟加载的图片、JS 挂上去的播放器都出来。
- 滚动到底，延迟加载的图片要滚动到才会加载，只看首屏会漏掉下半篇的裂图。
- 数图片张数，跟后台的图片数对得上。
- 看有没有源代码外露，例如
![、[[、](这类字符出现在正文。 - 视频点一下，确认真的会动，不是只有一个播放器外框。
这一套不需要每篇都人工做。量大的时候可以用浏览器自动化跑，但要注意自动化本身也会误判（后面验证纪律那一节会讲）。比较稳的做法是自动化全量跑、人工每批抽几篇看，两边的结果互相对照。抽样的结论只代表抽到的那几篇，这一点在大型网站 SEO 分工与验收节奏那篇有更完整的说明。
自动修正一定要配修后检查
批量发文的自动修正脚本一定要接一支独立的修后检查（lint），用发布前 12 项重新扫描，任一项命中就不准发布。
发现模板性错误之后，自然的反应是写一个脚本批量修。我们也这样做了，然后在 2026 年 10 月 15 日踩到一次：修正脚本跑完自报 30 篇里 30 篇零问题，人工验收还是抓到 2 篇有漏，等于自报 100% 通过、实际漏网约 7%。脚本没有说谎，它只是回报「我修了哪些」，没有回头确认「修完之后还有没有」。
这两件事要分开。修正脚本回答的是「我做了什么」，检查脚本回答的是「现在长什么样」。只修不查，修正脚本的覆盖范围有多大，你看到的「零问题」就有多大，规则没涵盖到的变体会被当成不存在。做法是让修正之后一定接一个独立的 lint，用发布前那 12 项重新扫一遍，任一项命中就不准发布。lint 最好跟修正脚本分开写，至少不要共用同一组比对规则，否则两边会一起漏掉同一种变体。
还有一个容易忽略的细节：修正脚本本身也会制造新错。例如清掉文末垃圾的规则写太宽，会把正文最后一段正常内容也删掉，留下孤儿标题。修后检查会把这种副作用抓出来，这也是它不能省的原因。
改已上线文章前，先想清楚两件事
批量修改已上线文章前要先确认两个副作用：后台保存会重置发布时间，也会清空没一并回写的字段（如标签）。
批量修正如果动到已经上线的文章，要多注意两个副作用，都是我们在那个站的后台实际遇过的：
- 后台保存会重设发布时间。 一篇旧文重新保存之后可能变成「今天发布」，排序、sitemap 的时间与读者看到的日期都会跟着变。
- 保存会清空漏带的字段。 如果修正流程只回写正文、没有把标签（tags）一起带上，保存后标签就没了。对标签页很多的站，这会连带影响聚合页的内容量，标签页怎么治理可以看标签页 SEO 审计那篇。
改已上线的文章之前，先跟负责后台的人讲清楚会动到哪些字段、保存会发生什么事，再决定是直接改、只改数据库，还是干脆不动。如果一批坏文章修不完，比较干净的选项是先把它们从索引里拿掉再慢慢修。Google 和 Yandex 都支持用 robots meta 的 noindex↗，不必整批删文。哪些该留、哪些该合并或删除，判断方式在大量内容剪枝那篇。
真实 DOM、对的 UA、当前标签页
前台验收自动化要避开三种误判：看浏览器执行后的真实 DOM、使用对的 UA，以及用前台标签页复查后台标签页跑出的“视频不能播”。
前台验收用自动化跑的时候，有三种误判我们都实际碰过。
第一，看真实 DOM，不看原始 HTML。 播放器和部分内容是 JS 挂上去的，原始 HTML 里根本没有。我们曾经用 fetch 抓页面、再用 DOMParser 解析，判定「这页没有播放器」，结果误报了 1 次：播放器在浏览器运行 JS 之后才出现。结构化数据↗也一样，要用浏览器确认，不能只看源代码。
第二，用对 UA。 有些后台的 WAF 会挡非浏览器的 UA，脚本拿到的是拦截页，不是文章。反过来，想知道 Google 看到什么版本，抓站时要用 Googlebot 的 UA，看到的才是 Google 那一份。
第三，非当前标签页会被浏览器降速。 自动化同时开很多标签页验视频播放，非当前标签页的计时器和媒体播放会被浏览器节流，跑出一堆「视频不能播」。这些结果要用当前标签页一篇一篇复查，大部分是假的。
最后一条是数字纪律：验收报告里的每个数字都附上来源和拉取时间，查不到就写查不到，不估、不沿用上一轮的数字。「30/30 零问题」那次如果有附上「这是修正脚本的自报、不是独立检查的结果」，就不会被当成验收通过。我们自己内容验收脚本的设计思路，写在24 个网站的 SEO↗ 验收横断面那篇。
这篇是大型网站 SEO 指南的其中一章，六个工作面的全貌和接手第一周的处理顺序都整理在那里。
常见问题
AI 写的文章会被 Google 惩罚吗？
Google 的立场是看内容对用户有没有帮助，不看怎么产生的。风险在于「大量产出没有附加价值的页面」，这在垃圾内容政策里叫滥用大规模内容。Bing 的网站管理员指南↗也把自动产生、没有价值的内容列为要避免的做法。带着生成残留、裂图、离题结尾的批量文章，最容易被归到这一类。
12 项一定要全部做吗？
不一定照抄，但建议照三组的结构建自己的清单：内容一致性、生成残留、媒体语法。媒体那组要换成你的站实际用的格式。重点是每一项都对应一次真实发生过的错，而且任一项命中就不发，而不是扣分后照发。
已经有自动修正脚本，还需要另外的检查吗？
需要。修正脚本只知道自己修了什么，不知道规则以外的变体。我们遇过修正脚本自报 30 篇全部零问题、人工验收仍抓到 2 篇的情况。修完之后要用独立的 lint 再扫一次。
前台验收用 curl 抓页面可以吗？
不够。curl 拿到的是原始 HTML，JS 挂上去的播放器、延迟加载的图片都看不到，还可能被 WAF 挡。要用真实浏览器、等加载完成、滚动到底，用当前标签页看视频有没有在播。
大量发文的站通常同时有索引、标签页、剪枝这几个问题要一起顾，流量真的掉下来时可以照流量下降诊断步骤一步一步排查。如果你想把这整套流程交给熟悉大型站的团队，可以看看我们的 SEO 网站代运营怎么接手。12 项检查做在发布前，永远比整批发完再修省事。
相关文章
- strategy内容剪枝怎么做：大型网站的 A／B／C 分层、四条红线与重复内容合并上万篇的大型网站做内容剪枝，先用 16 个月数据分 A／B／C 三层，再守住四条红线：不删文、不批量 410、不整批 noindex、不承诺剪完就有流量。重复内容只认视频 hash，不认标题。附一个 1 万多篇视频内容站的实际分层数字。
- strategy大型网站索引管理：页型规范表、sitemap 四条规矩、镜像与多域名怎么处理网址几十万的内容站，收录率低多半不是内容不够，而是该进索引的页和不该进的页混在一起。本文整理我们实际在用的页型规范表、sitemap 四条规矩、canonical 与 301 的写法、镜像域名三种处理方式，以及只对 Google noindex 的做法和风险。
- strategy大型网站 SEO 怎么做：六个共同特征、六条原则，和一套能照着走的方法网址上万、镜像域名一堆、Google 之外还要顾 Yandex 和 Bing、标签页失控、每天批量发文、改动要靠别人排期。这篇整理大型网站 SEO 的共同特征与六条基本原则，再用六章摘要带你找到索引、剪枝、标签、诊断、分工、发文质量的完整做法。