AI 批量發文的品質關卡：發布前 12 項檢查、前台驗收與修後再查

太長不看版： 用 AI 大量發文，錯誤很少是「某一篇寫爛了」，幾乎都是模板或流程的問題，一出錯就是十幾篇一起錯。我們接手的一個影音內容站，每天好幾個人同時發、每人約 30 篇，最後收斂成一套做法：發布前跑 12 個檢查項，發布後用真實瀏覽器打開前台、等 5 秒、捲到底，自動修正腳本修完一定要再跑一次檢查，任一項命中就不准發。另外三條驗證紀律：看真實 DOM 不看原始 HTML、用對 UA、背景分頁跑出來的「影片不能播」要用前景分頁複查。

批量發文的錯是模板性的，一錯就是十幾篇

1 個模板或流程缺陷，就會讓當天經過同一條流程的十幾篇文章一起出錯，所以要靠固定檢查項而不是逐篇人工審稿。

那個影音內容站的發文量是這樣的（以下做法是 2026 年 10 月在那裡整理出來的）：好幾位編輯同時用 AI 輔助產出，每人一天大約 30 篇。這種量下，任何一個步驟有缺陷，例如素材清洗少一道、編輯器把某種圖片語法吃掉、某個圖床網域掛了，都不會只影響一篇，而是當天經過同一條流程的所有文章。

這件事改變了品質管理的思路。逐篇人工審稿在這個量下做不完，而且人眼最容易漏的，就是重複出現的小錯，看到第五篇就習慣了。比較有效的做法是反過來：把「曾經出過的錯」整理成固定的檢查項，每篇都跑一遍，跑不過就不發。檢查項是從事故裡長出來的，不是從理論推出來的，所以清單會越來越長，但每一項都對應一次真實發生過的問題。

這也是 Google 在意的地方。它的生成式 AI 內容指引↗並不反對用 AI 寫，但講得很清楚：如果用生成工具大量產出沒有替使用者增加價值的頁面，可能會落入垃圾內容政策↗裡的「濫用大規模內容」。一批帶著生成殘留、圖片破掉、結尾離題的文章，在使用者眼中就是低品質的大量頁面，不管它是怎麼產生的。品質關卡擋的就是這種批次。

發布前 12 項檢查清單（通用版）

AI 批量發文的發布前檢查清單共 12 項，分成內容一致性、生成殘留、媒體語法三組，每一項都來自實際出過的事故。

下面是我們實際在用的 12 項，順序照「內容對不對、有沒有生成殘留、媒體語法對不對」分成 3 個分組。每一項都是在那個站上真的出過事才加進來的。

內容與分類

1. 分類／頻道對不對。 批量發文最常見的是整批被丟進同一個預設分類，或沿用上一批的設定。
2. 標題和正文一致。 AI 有時改了標題角度，正文還在講原本的題目。也有人工改了標題、正文沒跟著動。
3. 素材來源殘留的品牌名。 素材裡的其他網站名稱、品牌名、浮水印文字被帶進正文，讀者會以為是那個品牌的內容，也可能讓整篇看起來像搬運。
4. 孤兒標題。 一個小標題下面什麼都沒有，通常是生成到一半被截斷，或段落被清洗規則整段刪掉。
5. 重複句。 同一句話在文中出現兩次以上，常見於分段生成後拼接。

生成殘留

6. 生成標記殘留。 像 [[…]] 這種提示詞或模板佔位符留在正文裡。
7. 文末垃圾。 文章結尾多出離題的新聞、AI 分析腔的總結、說教句、「歡迎在留言區分享你的看法」這類評論引導，或檔名殘渣。

圖片與影片語法

8. 引用式圖片語法。 ![x][1] 這種寫法在某些編輯器或前台渲染器不會被轉成圖片，前台直接露出原始碼。
9. 失效的圖床網域。 圖片網址指向已經停用的圖床，後台看得到網址，前台是破圖。
10. 第一張圖漏了 !。 少一個驚嘆號，圖片就變成一條普通連結。
11. 圖片 ALT 不能是檔名。 IMG_2041.jpg 當 ALT，對讀者和搜尋引擎都沒有資訊。
12. 影片網址只留站內路徑。 只存 /videos… 開頭的路徑，不寫死網域。影片網域一換或一失效，寫死網域的整批文章就同時壞掉。

如果你的站不是影音站，第 8 到 12 項可以換成你自己的媒體格式，但分組的邏輯照用：內容一致性、生成殘留、媒體語法，這三類錯的成因不同，檢查方式也不同。前兩組大多能用文字比對抓，第三組有一部分只有在前台才看得出來，下一節講。

為什麼後台看不出來：只有前台會露出的錯

批量發文的圖片與影片錯誤後台看不出來：資料沒問題、壞在渲染層，因此發布前檢查之外，必須再加一道看前台成品的驗收。

我們在那個站上學到最貴的一課是：後台編輯框看起來正常，不代表前台正常。 引用式圖片 ![x][1] 在編輯框裡就是一行看起來合理的 markdown，存檔也不會報錯，但前台渲染出來是一串原始碼。失效的影片網域也一樣，後台只看到一個網址字串，要真的在前台按播放才知道它連不到。

這兩種錯有個共同點：它們在「資料」層面沒問題，壞在「渲染」層面。只檢查資料的關卡永遠抓不到它們。發布前的 12 項因此只是第一道，發布後還要有一道直接看前台成品的驗收，兩道各擋不同的錯，缺一道就有一類錯會穩定漏掉。

前台驗收的另一個好處是它會順便抓到「12 項以外」的新型錯誤。清單只能擋已知的問題，前台驗收是唯一能看到未知問題的地方。每次前台抓到清單沒列的錯，就把它補進清單，這張清單就是這樣一路長到 12 個檢查項的。

發布後前台驗收：真實瀏覽器、等 5 秒、捲到底

批量發文的前台驗收要用真實瀏覽器打開文章、等 5 秒、捲到底，再核對圖片張數、檢查原始碼外露並實際點播影片。

我們的前台驗收步驟很短，但每一步都有原因：

1. 用真實瀏覽器打開文章頁，不是用 curl，也不是看後台預覽。
2. 等 5 秒，讓延遲載入的圖片、JS 掛上去的播放器都出來。
3. 捲到底，延遲載入的圖片要捲到才會載，只看首屏會漏掉下半篇的破圖。
4. 數圖片張數，跟後台的圖片數對得上。
5. 看有沒有原始碼外露，例如 ![、[[、]( 這類字元出現在正文。
6. 影片點一下，確認真的會動，不是只有一個播放器外框。

這一套不需要每篇都人工做。量大的時候可以用瀏覽器自動化跑，但要注意自動化本身也會誤判（後面驗證紀律那一節會講）。比較穩的做法是自動化全量跑、人工每批抽幾篇看，兩邊的結果互相對照。抽樣的結論只代表抽到的那幾篇，這一點在大型網站 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 項檢查做在發布前，永遠比整批發完再修省事。

---

了解我們的廣告策略與投放服務 →