內容批次作業怎麼交給 AI：五百篇補 meta、十九張封面圖的實際做法
☰ 目錄 table-of-contents.md
網站經營到一定規模之後，會遇到一種很尷尬的工作：不難，但量大到人工做不完。全站五百多篇文章要補 meta description，一篇三分鐘也要跑掉二十幾個小時；十九篇待發文章缺封面圖，一張一張生成再轉檔上傳，一個下午就沒了。這些事沒有技術含量，但不做又確實會影響成效。
這正是批次型 Skill 的守備範圍。它跟前面談過的維運檢查不太一樣，維運是「定期跑同一份清單」，內容生產是「對一大批對象做同一件事」，兩者踩的坑也不同。這篇談後者，包含我們自己批次跑壞過一次的完整經過。
先弄清楚哪些能批次，哪些只是看起來能
批次作業最大的風險是規模。錯一次的成本乘上數量，就從小失誤變成事故。我們的分法是看「錯了要花多少力氣救回來」：
| 工作 | 批次難度 | 出錯的救援成本 |
|---|---|---|
| 補 meta description | 低 | 低，改回去就好，且有備份 |
| 產封面圖 | 低 | 低，重生成即可，只是花錢 |
| 補 excerpt | 中 | 低，但要注意別讓它變成正文截斷 |
| 加內部連結 | 中 | 中，插錯位置會破壞 HTML 結構 |
| 改寫既有正文 | 高 | 高，內容被動過很難察覺，也很難逐篇校對 |
最後一列是紅線。讓語言模型批次改寫既有內容，它會順手「優化」你沒要求它動的地方，包含標籤結構與事實敘述，而且改得很自然，逐篇比對之前不會發現。要做這件事的話，讓它只回傳決策不回傳內容，寫入前用程式硬性驗證標籤序列與去標點的骨架有沒有變。
批次 Skill 的核心是先產一個給人看
這是我們今年學到最貴的一課，而且是這個月剛發生的。
要幫十九篇待發文章補封面圖，流程都寫好了：組 prompt、呼叫生成、轉 WebP、部署、寫回資料庫。跑之前我只確認了尺寸規格，沒有實際打開站上既有的封面圖看一眼。批次跑完才發現，站上的調性是明亮的真人商業攝影，暖色調、有人在工作場景裡；而我生出來的十九張全部是深色無人的物件特寫。規格完全正確，風格完全不對，整批重做。
後來的流程多了一個步驟，而且是不能跳的：批次之前先產一個樣本，人看過再放行。這一步只花幾十秒，省下的是整批重跑的時間與費用。第二次重做的時候先產了一張，確認風格對了才跑剩下十八張，一次過關。
寫進 Skill 裡大概是這樣：
## 執行順序
1. 先讀取現有的 3 個樣本（既有封面圖、既有 meta、既有 excerpt），歸納目前的風格
2. 產出第 1 筆，停下來，把結果呈現給使用者確認
3. 使用者確認後才處理剩餘項目
4. 每處理 10 筆回報一次進度
## 不要做的事
不要在未確認樣本的情況下跑完整批。
不要為了效率跳過第 2 步。
批次改動一定要有退路
第二個原則是備份，而且要備份到批次作業之外的地方。我們的習慣是在動任何欄位之前，先把原值撈出來寫成一份 JSON 存到專案以外的目錄，檔名帶日期。這件事寫進 Skill 的成本很低，但少了它就等於在沒有安全網的情況下改五百筆資料。
## 動任何欄位之前
1. 撈出所有將被修改的欄位原值
2. 存成 /root/<欄位名>-backup-<日期>.json
3. 確認備份檔存在且筆數正確，才開始寫入實際跑起來大概像這樣：先備份、再改、最後抽驗幾筆確認。改完之後如果發現方向錯了，把 JSON 讀回去覆寫就結束了，不用去翻資料庫的備份。
資料層的兩個坑
批次處理 WordPress 或任何 CMS 的內容，有兩個技術細節常常卡住人。
存成 JSON 的中文欄位搜不到。很多欄位（標籤、FAQ、自訂欄位）是以 JSON 形式存進資料庫的，而 JSON 編碼預設會把中文轉成 \u 開頭的跳脫序列。這代表你用 SQL 的 LIKE 去搜中文關鍵字，永遠搜不到，而且不會報錯，只會回傳零筆，看起來像是「真的沒有」。正確做法是把欄位讀出來解碼之後再比對，或改用資料庫的 JSON 函式。
算位置的時候位元組與字元混用。要判斷某段內容在全文的哪個位置，常見寫法是拿字串搜尋函式的回傳值去除以總長度。問題是前者算的是位元組，後者常常算的是字元數，而中文在 UTF-8 佔三個位元組，結果就是算出超過百分之百的位置。這個錯誤不會讓程式崩潰，只會讓你的判斷邏輯默默失準。
成本要先算過
批次作業的費用是線性成長的，跑之前值得先算。以圖片生成為例，中等品質一張大約零點零三美元，十九張約零點五五美元，這個量級不用猶豫。但如果對象是五百篇文章而且每篇都要呼叫模型，數字就完全不同了，先跑十筆量測實際用量再乘上去比較保險。
省成本的方向通常不是換便宜的模型，是減少不必要的呼叫：能用程式判斷的不要問模型、能一次處理十筆的不要跑十次、把固定不變的部分寫成腳本讓它輸出結果而不是讓模型現場產生。
什麼時候不該批次
有兩種情況我們會選擇一筆一筆做。
第一種是每筆的判斷差異很大的工作。例如替不同主題的文章挑內部連結，看起來是同一件事，實際上每篇的合適對象都不同，批次跑出來的結果多半是硬湊的。這種工作比較適合的做法是讓 Skill 產出候選清單，人來挑。
第二種是對外可見且不可逆的動作，例如發布、寄信、推播。這類工作即使流程完全一樣，也建議保留人工確認的那一步，因為錯誤沒有退路。內容排程的相關做法我們在WordPress Cron Job 改造指南裡有談到排程與確認的分界。
從哪一項開始
建議從「純新增、不動既有內容」的工作開始，補 meta 與產封面圖都是很好的起點，因為它們不會破壞現有的東西，錯了也只是重做。等流程跑順了，再往需要判斷的工作推進。
做完之後記得回頭看一件事：這批東西的品質，跟你自己一篇一篇做的差多少。如果差很多，通常不是模型不行，是 Skill 裡的標準寫得不夠具體。批次作業的品質上限，等於你把判斷標準寫清楚的程度。
這些做法我們實際用在客戶的站上，成品可以看作品案例，像立朋工業、集羽珠寶、辰羿起重這幾個都是 WordPress 做的，維運也一起接手。
如果你的網站內容量已經到了人工維護跟不上的程度，想把這類批次工作標準化又擔心改壞既有內容，這正是我們AI 自動化開發在幫客戶處理的事。跟我們聊聊你手上積著的是哪一批。
延伸閱讀
RoamerHost 幫你把開源 AI 與自動化工具一鍵代管：獨立 Docker、自動 SSL、24/7 監控，60 秒上線。省下租機器、裝環境、顧維運的力氣，訂閱就能開始用。
▶立即免費註冊常見問題
可以讓 AI 批次改寫既有的文章內容嗎？
批次跑之前最該做的一件事是什麼？
批次改動要怎麼留退路？
為什麼用 SQL 搜中文關鍵字都搜不到？
批次作業的成本怎麼估？
這個主題的完整脈絡、選型比較與導入建議，都整理在指南裡。
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。