我們公司怎麼跑出 20+ AI 流程？系列第 4 篇：每日部落格 SEO 寫稿自動化 SOP，4 階段 pipeline、5 條品質紅線、3 個跳過寫稿的判斷條件

這篇文章就是我們公司的部落格 AI 寫稿自動化流程寫的，對，這篇文章本身就是它的產出。你現在讀的這段文字、文章結構、SEO meta、scheduled_at 排程、甚至這篇文章是「我們今天該不該寫」這個決定，都是這條 SOP 的一部分。

我們在系列第 4 篇做最徹底的 dog-fooding：把這條流程攤開、把它怎麼判斷「今天該寫幾篇」「該寫什麼」「該不該跳過」全部寫進這篇文章。中小企業老闆如果在評估「我能不能用 AI 養一條內容生產線」，這篇就是我們的內部版操作手冊。

4 階段 pipeline：盤點 → 候選 → 寫稿 → 入庫

我們的流程拆 4 個獨立階段，每階段都可以單獨跑、可以單獨失敗、可以單獨人工接手。這個拆法是我們在系列第 2 篇講排程治理 SOP 時學到的，把單一大型 LLM call 拆成多個小階段，可觀測性翻倍、出錯時 fallback 路徑明確。

階段 1：既有文章盤點（決定缺口）

每天早上 7:00（Asia/Taipei）cron 觸發，第一件事不是寫稿、是 SELECT。我們連到 PostgreSQL 撈最近 200 篇文章、按四類受眾與 7 個主題類別做分布統計、找缺口。這個 SELECT 本身不寫進 prompt，而是先用 plain code 做 group by 統計、把缺口算出來、只把「缺口分析結果」5-6 個欄位的摘要丟給 LLM。

為什麼這樣？因為 200 篇文章塞進 prompt 會佔 30K+ tokens、成本爆炸、而且 LLM 對「200 行 CSV 的分布統計」做得比 plain Python `Counter` 還差。能用 code 處理的決策一律不要丟 LLM，這是我們的內部第一條 cost-aware 原則。

階段 2：主題候選 + 查重

LLM 拿到「缺口分析 + 過去 7 天時事熱點 + 上週策略週報 Part C 條目」三組資料，輸出 8-12 個主題候選，每個帶上「受眾類別 / 服務 cover 等級 / 預估 SEO 流量 / 來源」5 個欄位。然後 plain code 對每個候選跑 ILIKE 查重 SQL， `WHERE title ILIKE '%關鍵字%' OR meta_focus_keyword ILIKE '%關鍵字%'`，撞文 > 70% 的候選自動踢。

查重是我們踩過最大的雷之一，v1 版本沒查重、一週內寫了兩篇近 90% 重合的「ChatGPT 定價解析」，Google 直接把舊文位置吃掉、新文 0 流量。查重不能是 LLM 自己判斷「這個有沒有寫過」，它沒有完整 ground truth；必須是 SQL 對 production DB 跑。

階段 3：寫稿（精品 vs 精簡兩條路）

我們有兩個寫稿模式：精品（120 nodes / 16K-20K 字 / 4 張 Unsplash 新圖）跟精簡（70 nodes / 4-6K 字 / 重用既有 cover）。今天哪個模式跑由「預算 + 排程飽和度 + 主題重要性」三個訊號決定。譬如本文是精簡模式，因為今天日跑的 cron 已經在 07:00 寫過一篇 #921、預算剩 $3 不到、加上系列文偏向精煉好讀。

階段 4：入庫 + 排程

INSERT 不是直接呼叫 Payload REST API、而是 raw SQL 寫進 posts table（jsonb content + scheduled_at + 6 大欄位）。為什麼跳過 Payload API？因為 Payload 的 afterChange hook 會觸發 revalidate， 我們不想在 INSERT 同一個 transaction 內等 revalidate（Cloudflare 邊緣延遲 30-90 秒）。我們用 cron `/api/publish-scheduled` 在 scheduled_at 觸發時統一 revalidate。

5 條品質紅線：違反任一條這篇就退件重寫

這 5 條是我們的內容 hard rules，LLM 寫完每一篇都會自跑 grep 驗證，全部 0 命中才能 INSERT。違反任一條就退件、prompt 補 example、重寫。

紅線 1：禁止「不是 X 而是 Y」否定對比句式

這條來自週報 feedback：『不是 X 而是 Y』在 AI 寫稿裡密度過高（每千字 4-6 次），人類讀者一秒辨識「這是 AI 寫的」。我們的 grep 規則：整篇文章內出現次數 ≤ 1 次。違反就 prompt 補例改寫。

紅線 2：「根據」最多 3 次

LLM 寫稿很愛用「根據 XXX 顯示」「根據統計」，超過 3 次整篇讀起來像論文摘要、會傷可讀性。我們改寫成「我們公司觀察」「業界數據」「XXX 報告指出（含 link）」。

紅線 3：H2 / H3 禁止「1. / 2. / 3.」編號開頭

這條也是週報 D-3 連續 7 期警示，編號 H2 / H3 會被 Google 判定為「清單型內容」、cannibalize 主關鍵字 SEO。我們有正則 lint：`^h[23]\s*[0-9]+\.` 命中就退。

紅線 4：媒體 prefix 必須 = 'media'

這條是 2026-04-26 incident 留下的硬規則，當時有一篇文章 INSERT 時 media 的 prefix 寫成 NULL，導致 /blog 路由全站 500 ms latency 飆 8 秒、Cloudflare cache miss 連續 3 小時。從那次起 prefix='media' 是 INSERT pre-check 的 P0 hard rule。

紅線 5：6 大欄位一個都不能漏

excerpt / meta_og_image_id / featured_image_id / scheduled_at / meta_focus_keyword / meta_description，這 6 欄漏一個 INSERT 就 fail（NOT NULL constraint）。但更關鍵的是 meta_focus_keyword：這是內部 SEO scoring 的主鍵，少這個 ranking dashboard 會把這篇文當「未分類」。

3 個「今天跳過寫稿」的判斷條件

這條 SOP 最關鍵的功能不是「會寫」、而是「會自決今天該不該寫、寫幾篇」。我們的 agent 過去 30 天有 8 天自決跳過、3 天自決寫 1 篇而非 3 篇。觸發條件 3 個：(a) 排程已飽和（未來 3 天 ≥ 9 篇）、(b) 候選主題撞既有文 > 70% 全部退、(c) 預算剩餘 < 單篇成本的 2 倍。

這個「會跳過」的能力，是我們公司過去 2 個月從週報 Part D 連續警示學到的，AI 寫稿的最大反效果是寫太多撞自己、cannibalize SEO、稀釋 topical authority，而非寫不好。讓 agent 有「不寫」的 option，比把它調教得會寫更重要。