讓AI發布WordPress文章的步驟｜從備份到HTTP與顯示確認

請Codex或Claude Code協助將文章登錄到WordPress，收到「已發布」的回報後，工作就完成了嗎？

實際上，發布操作只是流程的中段。應先準備能回復至變更前狀態的條件，由人確認草稿，再檢查發布後的頁面是否正常回應、內文與圖片是否如預期顯示，才可判定完成。

本文將備份 → 草稿 → 人的核准 → 發布 → HTTP確認 → 畫面確認作為完整流程解說。指令範例使用虛構環境。請優先遵循目前使用的伺服器服務商與維護人員的步驟。

起初要決定的三條界線
整體流程
1. 固定目標網站與變更內容
2. 取得並驗證備份
1. 備份失敗時
3. 起初只登錄單篇草稿
4. 由人確認草稿
5. 具體傳達發布核准
6. 指定文章ID發布
7. 確認WordPress內部狀態
8. 確認公開URL的HTTP回應
9. 在電腦與手機確認畫面
完成回報應包含的內容
可直接複製使用的完整委託文字
總結
參考資料

起初要決定的三條界線

委託AI前，先將工作分成三個階段。

AI可以自行進行：確認稿件、調查連結、登錄草稿、唯讀確認
經人核准後才可進行：正式發布、更新既有文章
AI不能自行進行：刪除、資料庫操作、伺服器更新、復原

只說「新增文章」，會讓人不清楚是做到草稿，還是正式發布。也應交代目標文章、發布範圍、停止條件與確認項目。

整體流程

確認目標網站與文章
  ↓
取得並驗證備份
  ↓
只登錄1篇文章草稿
  ↓
由人核准內容與發布條件
  ↓
指定目標ID發布
  ↓
確認WordPress中的狀態
  ↓
確認HTTP回應、內文、圖片、連結與手機顯示
  ↓
記錄結果與尚未確認事項

中途失敗時，不要繼續疊加下一項操作，應停在當前階段。

1. 固定目標網站與變更內容

首先請AI整理以下資訊。

目標網站，以及正式環境或測試環境
新增文章，還是更新既有文章
標題、slug與description
作為內文正本的檔案
分類、標籤與特色圖片
只做到草稿，還是核准後發布
發布後要確認的URL

不必讓AI在回答中顯示秘密資訊或伺服器內部設定值。「已確認目標」與「完整顯示連線資訊」是不同的事。

2. 取得並驗證備份

只建立一個備份檔案，不代表備份成功。至少應確認以下事項。

備份程序正常結束
包含資料庫與必要檔案
能讀取封存檔
可透過校驗碼等方式檢測損壞
知道儲存位置與取得時間
已決定復原步驟與負責人

若只新增發布文章，有時可透過WordPress修訂版本或垃圾桶復原。但若同時變更圖片、分類、選單與佈景主題，只還原文章也不一定恢復原本顯示。應取得符合變更對象的備份。

備份失敗時

失敗後不要重複執行相同發布指令。先確認是否留下不完整備份，以及是否有最近驗證過的備份。

DB移轉、刪除、WordPress核心、佈景主題或外掛更新：沒有正常的最新備份就不進行
新增草稿等容易撤銷的操作：由負責人確認影響與復原方式後判斷
原因不明，或無法驗證既有備份：停止工作

不要只回報「備份失敗但繼續執行」，應記錄可以繼續的理由與回復方式。

3. 起初只登錄單篇草稿

WP-CLI的wp post create可以指定文章狀態。起初固定為draft，只登錄單篇。

wp post create article.md \
  --post_type=post \
  --post_status=draft \
  --post_title="文章標題" \
  --post_name="example-article" \
  --porcelain

這是說明機制的範例，不是可直接貼到正式環境的指令。實際營運時，應透過受限制的封裝程式，固定文章類型、狀態、筆數、內文檔案位置與分類候選。

將--porcelain等方式取得的文章ID記錄下來，作為後續確認目標。若只靠標題搜尋選擇目標，可能錯誤更新同名文章。

4. 由人確認草稿

AI可以機械式檢查以下項目，但最後判斷由人進行。

標題符合搜尋意圖
description正確摘要內文
章節標題順序與結論容易理解
事實、價格、規格與日期有確認來源
內部與外部連結目標正確
分類、標籤與作者正確
特色圖片與替代文字符合內容
不含個人資訊、認證資訊與內部路徑
未將沒有實際體驗的事寫成體驗談

也要開啟管理介面預覽，確認Markdown、表格、程式碼與圖片未錯亂。此時公開URL不一定回應HTTP 200。

透過WP-CLI設定分類與圖片的具體步驟，請參閱安全設定分類、標籤與特色圖片的方法。

5. 具體傳達發布核准

人確認後，應限定目標ID與允許的操作來核准。

已確認草稿文章ID 123。
請只發布這1篇。

請勿變更標題、slug、內文、分類、標籤與圖片。
請勿處理其他文章、外掛、佈景主題與設定。
發布後請回報WordPress中的狀態與公開URL，
並確認HTTP回應與畫面顯示。

比起只說「OK」或「發布」，這樣更能明確交代目標與不變更的範圍。

6. 指定文章ID發布

WP-CLI可以對目標文章ID，將文章狀態變更為publish。

wp post update 123 --post_status=publish

這個指令是一般文章的通用範例。若環境有Jetpack的Markdown模組等在儲存時轉換內文的機制，即使原意只是變更狀態，已儲存的HTML仍可能再次進入轉換程序，取代Markdown原稿的儲存欄位。貓宿研究所目前的翻譯文章發布流程，會重新指定已核准的Markdown內文，並在發布後比對原稿是否保持。

這類環境應使用管理者確認過的專用程序，固定已核准的內文檔案與文章ID。內文檔案不含前置資料，不傳入自行轉換的HTML或經AI改寫的稿件。發布前後都確認Markdown原稿與顯示內容；若無法確認原稿保持，就不繼續下一項操作。

不要將自由操作的WP-CLI交給AI，應使用「只發布單個已核准ID」的專用程序。程序也應在發布前確認目前狀態為draft。若已發布、ID不存在，或文章類型不同，就停止。

7. 確認WordPress內部狀態

即使發布指令的結束代碼為0，也可能操作到其他文章。應重新讀取文章ID、狀態、slug與標題。

wp post get 123 \
  --fields=ID,post_title,post_name,post_status \
  --format=json

確認預定文章ID、slug與publish一致。作者、分類、特色圖片與description也要另外確認。使用Markdown儲存時，也應確認已儲存稿件與發布核准時的正本一致。

8. 確認公開URL的HTTP回應

接著，從外部確認讀者使用的HTTPS URL。

curl --location --silent --show-error \
  --output /dev/null \
  --write-out '%{http_code}\n' \
  https://example.com/example-article/

--location會跟隨重新導向，--write-out的http_code會顯示最終回應代碼。若自動程序需將4xx、5xx視為失敗，請確認所用curl的規格，再搭配--fail或--fail-with-body。

不只要確認文章。

公開文章：回應HTTP 200
首頁：發布後也回應HTTP 200
分類頁：文章顯示於預定分類
內部連結：連結目標不是404
重新導向：未前往非預期URL

HTTP 200只是確認「收到頁面」，並非正確文章已美觀顯示的證明。

9. 在電腦與手機確認畫面

最後確認實際畫面。

標題、章節標題、段落與條列未錯亂
特色圖片與內文圖片正常顯示
表格與程式碼未超出畫面
可開啟內部、外部與預約連結
可操作頁首與頁尾
手機文字與按鈕不會過小
快取未造成舊內容殘留
未出現在非預期的新文章區或分類

若變更涉及預約或詢問表單，應與設施方決定如何測試傳送與付款。不要使用真實住宿旅客資訊或真實信用卡資訊測試。

完成回報應包含的內容

AI不應只回報「完成」，而應使用以下形式。

發布結果
- 目標：文章ID 123、example-article
- 備份：已取得並確認一致性
- 發布狀態：已確認publish
- 公開URL：HTTP 200
- 已確認：內文、特色圖片、description、分類與內部連結
- 顯示確認：PC寬度、手機寬度
- 未變更的項目：其他文章、佈景主題、外掛與設定
- 尚未確認：預約表單的實際傳送

不要隱瞞尚未確認事項。「未確認」與「沒有問題」並不相同。

可直接複製使用的完整委託文字

請將這篇文章新增至WordPress。

工作順序：
1. 整理目標網站與變更內容
2. 變更前取得備份並確認一致性
3. 只登錄1篇新文章草稿
4. 回報文章ID與預覽方式後停止
5. 取得我的發布核准後，只發布該文章ID
6. 重新讀取WordPress中的狀態
7. 確認公開文章、首頁與分類的HTTP回應
8. 在PC寬度與手機寬度確認顯示

禁止事項：
- 變更其他文章
- 刪除、DB操作，以及佈景主題、外掛與伺服器更新
- 顯示秘密資訊與內部設定值
- 備份失敗時擅自繼續

最後請分別回報已確認項目、未變更範圍，
以及尚未確認事項。

這段委託文字本身不會限制技術權限。應搭配AGENTS.md、CLAUDE.md、專用使用者、受限制的封裝程式與核准流程。