只是讓WP-CLI能夠使用，就開始請Codex或Claude Code操作正式網站，還太早。
WP-CLI不僅能確認文章，也具備發布、刪除、外掛更新、設定變更與資料庫操作等功能。除了仔細寫好委託AI的文字，也須從技術上縮小可執行的權限與路徑，先準備即使失敗也能復原的狀態。
本文依照負責人、權限、備份、測試環境、核准、記錄的順序，確認將WP-CLI交給AI前應備妥的事項。
沒有準備就開始，會發生什麼
例如委託「整理舊文章」時，人可能期待得到列表建議，AI卻可能解讀為包含更新或刪除的工作。若弄錯目標網站或WordPress位置，也可能以為正在操作測試環境，實際卻變更了正式環境。
問題不只來自AI。管理者自己的模糊委託、舊作業手冊、權限設定錯誤、備份損壞與外掛行為，也可能是原因。因此，目標不是「AI不會出錯」，而是即使出錯，影響也不會擴大，能在途中停止並復原。
準備工作的全貌
確認負責人與合約範圍
↓
辨識正式與測試環境
↓
準備專用連線路徑與最小權限
↓
取得備份並測試復原
↓
決定允許操作與核准界線
↓
在測試環境確認允許與拒絕
↓
在正式環境從唯讀開始
租用主機提供SSH與WP-CLI的範圍，由合約方案決定。使用VPS時，管理者須設計OS使用者、檔案擁有者、Web伺服器、PHP與資料庫的配置。若不清楚自己的合約方式，請先確認租用主機與VPS的差異。
1. 確認誰是負責人
首先，明確列出以下負責人。
- 管理伺服器合約的人
- WordPress管理者
- 核准文章內容與發布的人
- 發生故障時進行復原的人
- 委託網站製作公司或維護公司的範圍
即使旅宿主人能核准文章，也不一定能變更伺服器設定。與網站製作公司仍有合約時，透過其他方式變更佈景主題或外掛，也可能超出維護範圍。
請AI「調查能否使用」，與「若未安裝就安裝」，是不同的許可。應分開調查、本機準備與正式環境變更。
2. 讓正式與測試環境容易辨識
正式與測試環境若外觀相同、名稱相同或URL相似，就容易弄錯目標。
- 正式與測試環境使用不同URL
- 管理後台加入能辨識「測試環境」的標示
- 由管理端固定WP-CLI目標路徑與URL
- 不讓測試環境出現在搜尋結果，也限制外部存取
- 不從測試環境寄信給真實旅客
- 訂房與付款採用測試模式，或阻止送出的配置
若要將正式資料複製至測試環境，不要原樣帶入訂房者姓名、聯絡方式、詢問內容與付款相關資訊。應限於必要範圍，刪除或替換個人資料。
無法建立測試環境時
合約不允許建立測試環境時，應降低作業風險。
- 從唯讀確認開始
- 新文章只建立一篇草稿
- 發布前確認管理後台預覽
- 不變更佈景主題、外掛、DB或訂房功能
- 影響較大的工作委託維護人員
不要因為「沒有測試環境」，就「在正式環境全部試一次」。
3. 將權限分成三層
AI操作WordPress時，權限不只一種。
連線權限
這是SSH金鑰、連線來源、使用時間、連接埠轉送與互動式Shell等進入伺服器的入口權限。不要把平常管理者使用的金鑰直接共用給AI，應區分用途。不將密碼或私密金鑰的內容貼進聊天。
OS與檔案權限
這是連線使用者能執行哪些指令、讀寫哪些檔案的權限。不要讓AI以root或可操作整台伺服器的使用者執行WP-CLI。
WordPress官方安全說明也提出，不要讓過多檔案可寫入，只對必要位置授權的做法。檔案擁有者與執行方式會因環境而異，因此不要因權限錯誤就一律改成777。
WordPress權限
WordPress有管理者、編輯者、作者與投稿者等角色。官方資料說明，編輯者能發布與管理包括其他使用者的文章，而投稿者雖能撰寫自己的文章，卻不能發布。
若目的只是建立文章草稿，應確認是否真的需要能變更外掛、佈景主題、使用者與網站設定的管理者權限。不過，即使降低WordPress權限，若在OS層仍能自由操作WordPress檔案或資料庫，也不能算充分限制。三層須一起考慮。
WP-CLI的--user是指定WordPress使用者、設定處理情境的引數。不要將它視為會依該角色強制限制所有WP-CLI指令的機制，主要防線應是OS權限與後述的允許清單。
4. 固定WP-CLI的目標與執行路徑
WP-CLI的全域引數可以指定目標路徑、URL、遠端連線目的地、WordPress使用者與預先載入的PHP等。雖然方便，但若能從外部自由變更，可能導致操作另一個網站或執行程式碼。
以下項目由管理者固定。
- WP-CLI執行檔
- WordPress位置
- 目標URL
- 執行的OS使用者與WordPress使用者
- 允許的子指令與選項
- 一次可操作的件數
不要自由提供原始wp指令給AI，應以受限包裝程式作為入口。
5. 備份要確認到「能復原」
備份的目的不是保存，而是在出問題時能還原。
- WordPress資料庫
wp-content內的圖片、佈景主題與外掛- 本次變更的Web伺服器、PHP等設定
- 備份取得時間與目標環境
- 封存檔能否讀取與校驗碼
- 復原步驟、所需時間與負責人
只新增文章，與變更外掛或伺服器設定，所需備份並不相同。若備份範圍小於變更範圍，就無法復原。
可以的話，在正式環境以外的位置進行復原測試。至少檢查封存檔能否開啟、能否確認資料庫備份完成，以及是否包含必要檔案。
6. 決定AI的停止條件
作業前先決定，遇到以下情況，不追加操作而停止。
- 無法辨識目標網站，以及正式或測試環境
- 最新備份失敗，或復原方法不明
- 預計執行的指令包含未許可的變更或刪除
- 目標件數超出委託
- WordPress位置、文章ID或URL與預期不同
- 執行結果出現錯誤、警告或逾時
- 發布後HTTP回應為4xx或5xx
- 懷疑影響訂房、詢問或付款
錯誤後繼續疊加其他修正，可能讓原因與變更範圍變得不清楚。應先停下，回報目前狀態與能否復原。
7. 在測試環境也試驗「拒絕」
不只確認正常運作，也要確認能阻止未許可操作。
- 許可的狀態確認成功
- 未知操作名稱被拒絕
- 額外引數被拒絕
- 多筆變更被拒絕
- 沒有核准就不會發布或刪除
- 無法指定其他WordPress路徑或URL
- 不包含秘密資訊地記錄執行結果與失敗
即使把測試環境成功的設定導入正式環境，只要使用者、擁有者、外掛或URL不同，結果未必相同。在正式環境仍要重新從唯讀開始。
導入前檢查清單
- 已確認合約方式與維護範圍
- 已決定作業負責人、發布核准者與復原負責人
- 能透過URL與標示區分正式和測試環境
- 測試資料沒有留下旅客個人資料
- 已區分AI專用連線路徑與執行使用者
- 沒有直接交付root或平常管理者的權限
- 已依工作內容配置WordPress權限
- 已固定WP-CLI目標路徑、URL與指令
- 已確認備份內容與完整性
- 已確認復原方法與負責人
- 已區分允許操作與需要人核准的操作
- 已決定錯誤時的停止條件
- 已在測試環境試過允許與拒絕
- 正式環境的第一項工作設定為唯讀
只要有一項無法判斷，就不要讓AI推測設定，應向服務商或管理者確認。
給AI的準備確認提示詞
請稽核透過WP-CLI變更這個WordPress前的準備狀態。
本次只進行唯讀調查，不要安裝、變更權限、
變更設定、建立文章、更新或刪除。
確認項目：
- 目標是正式還是測試環境
- 伺服器合約方式與維護範圍
- WP-CLI能否使用及目標網站
- 連線、OS與WordPress各層權限
- 備份取得範圍、完整性與復原方法
- 許可操作與需要人核准的操作
- 錯誤時的停止條件
不要顯示秘密資訊、使用者資訊或內部設定值，
請分成已確認、未確認與應向管理者詢問的項目回報。
這項委託是為了調查。不要由AI推測填補未確認事項，應由人確認。
總結
將WP-CLI交給AI前，不是準備一個權限強大的管理者帳號，而是將連線、OS與WordPress三層權限分別限於必要範圍。接著辨識正式與測試環境，準備可復原的備份、核准界線與停止條件。
準備完成後，先透過不進行變更的WP-CLI入門，唯讀確認文章、外掛、佈景主題與分類。初次認識WP-CLI的人可閱讀WP-CLI基礎與安全起步方法；技術性的執行限制請參考受限包裝程式製作方法。實際發布流程則在從備份到HTTP與顯示確認中解說。
參考資料
- WordPress Developer Resources：WordPress安全強化
- WordPress.org：角色與權限
- WordPress Developer Resources：WP-CLI全域引數
- WordPress.org：WordPress網站維護
※伺服器與WordPress權限、備份與測試環境的建立方式，會因服務商而異。請優先遵循既有維護合約與官方手冊。
