外掛更新頁面跳出十幾個待更新項目，你點一個、等它跑完、再點下一個，同一個動作要重複做十幾次；手上如果不只一個網站，而是十個、二十個要維護的客戶站，這串點擊就要再乘上二十倍。後台介面設計給人一次處理一件事，批次操作從來就不是它的強項。
WP-CLI 就是為了解決這個問題而生的命令列工具，你在終端機打一句 WP-CLI指令，就能對成百上千筆資料下同一個動作，不必在後台一頁一頁點。WP-CLI 的指令文件目前列出 51 個父指令，涵蓋文章、外掛、佈景主題、使用者、資料庫等各種管理對象，最新穩定版來到 2.12.0，已經是許多代管商與資深維運者管理 WordPress 站台的標準配備。學會之後，原本要花一整個下午逐筆點擊才能做完的維護工作，常常一行指令、幾秒鐘就跑完。
日常維運最常碰到的批次需求，不外乎整批修改文章、整批更新外掛與佈景主題、整批管理使用者帳號，還有資料庫內容的安全取代（網域搬遷那種整個環境要重來一次的做法，是另一個獨立的主題，這裡不細談）。動手之前，先搞懂一句 WP-CLI指令是怎麼組成的，這是每一種批次手法共通的基礎邏輯。
WP-CLI 是什麼？
WP-CLI 是 WordPress 專案維護的命令列工具，你不用打開瀏覽器登入後台，直接在終端機輸入指令，就能操作文章、外掛、佈景主題、使用者、資料庫這些原本要在網頁介面上一步步點的項目。一句 WP-CLI指令固定由三層組成：父指令、子指令、參數。以 wp plugin update akismet 為例，plugin 是父指令（代表你要操作的對象是外掛），update 是子指令（代表你要對外掛做的動作是更新），akismet 則是這個動作要套用的目標。多數 WordPress 管理任務都能對應到某組父指令與子指令的組合，wp post、wp theme、wp user、wp db、wp cron、wp site 這些父指令底下，各自再展開好幾支子指令。
參數則分成兩種寫法，混著用最容易出錯。有序參數直接接在子指令後面，用角括號 <id> 表示，像 wp post delete 123 裡的 123 就是有序參數，代表這篇文章的 ID；具名參數用 --field=value 這種等號寫法，像 wp post list --post_type=page，代表你在篩選條件裡指定文章類型是頁面。有序參數靠位置決定意思，具名參數靠名字決定意思，兩者可以在同一句指令裡並用。
後台介面被設計成「一次做一件事」，你點一篇文章、改一個欄位、按一次儲存。命令列能做到後台做不到的事，其實就在批次這兩個字，把同一個動作套用到一整份清單上，而不是逐筆點擊。做法通常是先用某個子指令的 --format=ids 之類的旗標，篩出一份符合條件的 ID 清單，再把這份清單接到管線或 xargs，讓後面的指令針對清單裡每一筆各跑一次。這個「先列清單、再逐一代入」的模式，是整批操作文章、外掛、使用者、資料庫時共用的同一套邏輯。
開始動手之前，環境需要具備幾個前提：能透過 SSH 或終端機存取伺服器、PHP 版本在 7.2.24 以上、WordPress 已經安裝好。這幾項多數代管主機都內建，是能安心執行批次指令的基本門檻。
安裝三步驟，以及鎖定目標網站的路徑與網址參數
安裝 WP-CLI 只要三個步驟：下載執行檔、賦予執行權限、搬到系統路徑裡改名成 wp。
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wpCode language: Bash (bash)裝完之後跑一次 wp --info，畫面會列出目前的 PHP 版本、WP-CLI 版本等環境資訊，看到這張表就代表安裝成功。這部分不是這篇的重點，快速帶過即可；真正該花時間搞懂的是 --path 與 --url 這兩個全域參數。
批次操作最容易出的包，不是指令打錯，而是在錯的網站上執行了正確的指令。共用主機上常常一台伺服器同時裝了好幾個 WordPress，如果你人還停在上一個專案的資料夾，卻對著這個目錄下了一句整批刪除或整批取代，改到的就是別人的網站。--path=<path> 用來明確指定這句指令要操作哪個 WordPress 安裝目錄，等於幫指令釘死作用範圍；如果站台是 multisite 環境，還要加上 --url=<url> 指定這句指令要假裝針對哪一個子站發出請求，因為同一份程式碼底下可能同時服務好幾個網域。下指令前先跑一次 pwd 確認自己現在真的站在哪個目錄，是共用主機上最基本、也最容易被跳過的習慣。
如果同一個資料夾底下常常要下同一組參數，可以寫進專案設定檔 wp-cli.yml，例如寫入 path: wp-core 這一行，之後在這個資料夾裡下的每一句指令都會自動帶入這個 --path，不用每次手動打。WP-CLI 會依序讀取 wp-cli.local.yml、當前目錄或上層目錄的 wp-cli.yml，以及使用者家目錄下的 ~/.wp-cli/config.yml，設定檔存在的目的，就是讓正確的路徑與網址變成預設值，不必每次都靠人手動記得帶。
文章批次更新與刪除，從一份 ID 清單開始
整批操作文章的第一步，永遠是先篩出一份符合條件的 ID 清單，依分類、作者、狀態、發布日期，把要處理的目標從全站文章裡撈出來。有了這份清單，後面不管是整批改標題、整批換分類、整批加自訂欄位，還是整批刪除，做法都是同一套，把清單餵給下一個指令，讓它針對清單裡每一筆各跑一次，而不是打開後台一篇篇找、一篇篇改。
用 wp post list 篩出目標文章的 ID 清單
wp post list 依 WP_Query 的參數過濾文章，平常在後台文章列表用的分類、作者、狀態、日期這些篩選條件，這裡都能用參數指定，例如 wp post list --author=2 篩出作者 ID 為 2 的文章。差別在於輸出格式，後台看到的是排版好的表格，wp post list 卻可以決定要不要把結果整理成給下一個指令消化的樣子，這一點才是批次操作真正用得到的地方。
--format 可以選 table、csv、ids、json、count、yaml，其中 table 是給人看的，ids 才是給下游指令用的，wp post list --field=ID 會直接逐行印出文章 ID；wp post list --post_type=page,post --format=ids 則是把頁面與文章的 ID 一次列出來，用空白分隔成一整行字串。需要更完整的資料時，wp post list --post_type=post --posts_per_page=5 --format=json 能輸出結構化的 JSON，方便寫成腳本進一步處理。篩選條件與輸出格式是兩件獨立的事，先想清楚要篩哪些文章，再決定要用哪種格式接到下一步。
用管線把單一指令套用到整批文章
篩出清單之後，下一步是把它接到 xargs，讓同一句指令對清單裡的每一個 ID 各執行一次。WP-CLI 的指令文件示範的做法是這樣：
wp post generate --format=ids | xargs -d ' ' -I % wp post meta add % foo barCode language: Bash (bash)這句指令先用 --format=ids 拿到一份用空白分隔的 ID 清單，xargs -d ' ' -I % 再把清單裡每一個 ID 依序代入 % 的位置，重複執行後面那句 wp post meta add % foo bar。這個「先列清單、再用 xargs 逐一代入」的模式，不是只能用在 post meta add 上，而是能套用到任何吃單一 ID 的子指令，例如想整批刪除某個分類下的舊文，先用 wp post list --category_name=old-notice --format=ids 依分類代稱篩出清單，接上 xargs -d ' ' -I % wp post delete % --force；想整批把一批文章狀態改成草稿，同樣先篩清單，再接上 wp post update。篩選負責決定「要動哪些」，xargs 負責決定「怎麼逐一套用」，把這兩件事分開想清楚，批次操作才不容易出錯。
文章分類、標籤與自訂欄位的批次修改
延續同一套手法，最常見的整批需求有三種：整批改分類、整批加自訂欄位、整批刪除。整批加自訂欄位可以用 wp post meta update <id> <key> <value> 更新單篇文章的自訂欄位，搭配前一節的 xargs 手法，就能把同一個自訂欄位一次寫進整批文章。
整批刪除則要留意 --force 這個旗標，wp post delete <id> --force 會略過移到資源回收桶的步驟，直接刪除，適合清掉舊文或測試資料；不加這個旗標，文章預設只會被丟進垃圾桶。資料庫層級的改動動手前務必先備份，這是任何批次操作前都該有的基本習慣。另外，不是每件事都要靠管線組合才能整批處理，WP-CLI 在 GitHub 專案首頁的範例裡，wp transient delete --all 這種帶 --all 開關的寫法，本身就內建「處理全部項目」的邏輯，很多子指令都有類似的 --all，遇到需求對得上時，直接用內建的 --all 會比自己組管線更簡單。
外掛與佈景主題各自對應一組批次更新指令
外掛與佈景主題的批次管理指令結構幾乎一樣，wp plugin 與 wp theme 平行對應，逐一安裝的基本操作多數人都已經會，這裡把重點放在批次更新，也就是一次處理全站所有需要更新的項目，而不是進後台一個個點更新。
全站外掛一次更新，用排除名單保留特定版本
wp plugin update --all 會一次更新所有偵測到有新版本的外掛，執行過程中 WordPress 會自動開啟維護模式，逐一下載更新，全部跑完之後再關閉維護模式，執行結果會整理成一張表格，欄位包括外掛名稱、舊版本、新版本、更新狀態，跟後台批次更新頁面看到的資訊差不多，只是不用一直盯著畫面點。佈景主題的整批更新則對應 wp theme update --all，用法一致。
實務上很少會希望全部外掛都更新，某個外掛的新版本可能還沒驗證過跟現有站台相容，這時候就用 --exclude 排除掉不想動的項目，例如 wp plugin update --all --exclude=akismet 會更新除了 Akismet 以外的所有外掛，其餘照常處理。如果想控制更新的幅度而不是整個排除，--minor 只做次版本更新、--patch 只做修訂版更新，兩者都能讓你在「全部更新」跟「完全不動」之間留一個折衷選項。
更新前，先用 –dry-run 預覽變動範圍
整批更新外掛最怕的不是更新失敗，而是不知道會動到什麼就下下去，手上這台站可能裝了三十幾個外掛，一次全部更新，萬一某個外掛新版本跟主題衝突，得先花時間排查是哪一個造成的。--dry-run 就是為了避開這種狀況存在的安全閥，指令文件的說明是「預覽哪些外掛會被更新」，只列出清單、不真的執行，先跑一次看看清單，確認名單裡沒有需要特別留意的項目，再拿掉這個旗標真的執行更新。
這個習慣特別適合排進維護排程之前先手動跑一次核對，把 wp plugin update --all --dry-run 的輸出存下來，跟上次的清單比對有沒有新增什麼意料之外的外掛要更新，確認沒問題之後，正式排程才放心讓它全自動跑。
使用者帳號可以批次建立、批次修改與重設密碼
使用者帳號的批次需求大致落在兩種情境：一次匯入一批新帳號，例如客戶端要求批次開放多位使用者的編輯權限、或是公司有一波員工到職；另一種是整批調整既有帳號的角色權限或重設密碼，例如發生安全事件後，需要強制全站使用者重設密碼。這兩種都不是進後台一個個新增帳號、一個個改角色能有效率完成的事。
用 CSV 檔案一次建立整批帳號
wp user import-csv 讀一份 CSV 檔案，一次建立多個帳號。指令文件範例的 CSV 欄位是帳號、電子郵件、顯示名稱、角色，寫法像是 user_login,user_email,display_name,role 這樣的表頭，每一列對應一個要建立的帳號，指令本身很單純，wp user import-csv /path/to/users.csv，跑完就會依 CSV 內容逐列建立帳號，不用在後台新增使用者頁面一筆筆手動輸入。
如果 CSV 裡的帳號或信箱剛好跟站上既有使用者重複，預設會被視為更新既有帳號的資料，不會另外建立一個重複帳號；不想動到已經存在的帳號，就加上 --skip-update，讓匯入只處理真正的新帳號，既有的維持原樣。想讓新帳號一建立就自動收到帳號密碼通知信，可以加上 --send-email，省去事後還要逐一手動通知每個人帳密的麻煩，一次匯入幾十個新帳號時，這個差別會很明顯。
批次調整角色權限與重設密碼
跟前面文章批次操作同一套邏輯，先用 wp user list 篩出目標帳號，再搭配管線套用到後面的指令。wp user list --role=administrator --format=csv 可以篩出特定角色的帳號並輸出成 CSV，也支援 --field=ID 只印帳號 ID，或用 --fields=display_name,user_email 限定輸出欄位，方便核對名單。
篩出清單之後，wp user update <user> --role=<role> 用來更新角色，這裡的 <user> 可以傳帳號、電子郵件或 ID，彈性比想像中大；wp user update <user> --user_pass=<new-pass> 則是重設密碼，文件範例 wp user update 123 --display_name=Mary --user_pass=marypass 示範一次改兩個欄位。批次做法就是先用 wp user list --role=<role> --field=ID 篩出目標帳號的 ID 清單，再用前面提過的管線加 xargs 手法，把每個 ID 逐一代入 wp user update，一次把一批帳號的角色降級，或在安全事件後強制整批重設密碼。
資料庫內容批次取代的用途不只是搬家
search-replace 最常被知道的用法是網域搬遷，把整個站台從測試網址搬到正式網址時，拿它一次取代資料庫裡所有出現的舊網域（細節見另一篇專講 WP-CLI 搬家的文章）。日常維運更常用到的其實是更貼近內容維護的取代情境：整批修正一個重複出現的錯字、統一某個過時的說法、抽換某個 shortcode 的寫法、更新頁尾的版權年份。search-replace 沒有復原鍵，一旦跑錯範圍或改到不該改的欄位，就沒有一鍵回滾能救，怎麼安全地大範圍改資料庫，比搬家情境更值得花篇幅講清楚。
–dry-run 與 –skip-columns 先降低誤動風險
--dry-run 在這裡的作用跟前面外掛更新一樣，跑完整個搜尋取代的流程，顯示一份報告，但不會真的寫進資料庫。第一次對正式站資料庫下 search-replace 之前，只要先跑一次 --dry-run，看報告裡列出的變動筆數跟預期的範圍對不對，就是最基本的自保動作。
另一個容易被忽略的旗標是 --skip-columns=guid。guid 是每篇文章的唯一識別，WordPress 的搬站文件明講不要更動這個欄位的內容，一旦被取代掉，許多 RSS 閱讀器會把舊文章當成新內容重新顯示一次，WP-CLI 指令文件的範例 wp search-replace 'http://example.test' 'http://example.com' --skip-columns=guid 就是示範跳過這個欄位不動。想確認哪些欄位真的有變動，可以加上 --report-changed-only，只回報真的被改到的欄位；需要事後核對每一筆被改了什麼，--log[=<file>] 會把改動內容都記下來，只是這個選項會明顯拖慢執行速度，大範圍取代時要有心理準備。
限定資料表與欄位範圍的精準取代
比起大海撈針式地全庫下手，把取代範圍縮小到「只動這幾張表」通常更安全。指令寫法是在 <old> <new> 後面加上要限定的資料表名稱，例如 wp search-replace 'foo' 'bar' wp_posts wp_postmeta wp_terms --dry-run，這句就只會在文章、文章自訂欄位、詞彙這三張表裡執行，不會動到使用者、選項等其他資料表。資料表名稱也支援萬用字元，'wp_*options'、'wp_post*' 這種寫法可以一次涵蓋多張相關的表，不用一張張手動列。
除了直接指定要動的表，也能反過來用 --skip-tables=<tables> 排除不想動的表；欄位層級同樣可以用 --include-columns=<columns> 進一步限定只處理特定欄位。範圍縮得越小，出錯之後要收拾的範圍也越小，尤其是第一次對正式站資料庫下手時，先從最小範圍開始測試，確認邏輯沒問題再逐步放寬。
正規表示式取代與效能的取捨
有些情境是格式類似但寫法不完全一樣，例如同一個 shortcode 出現好幾種不同參數的寫法，這種時候單純的字串比對做不到，才需要 --regex 這個旗標。文件範例 wp search-replace '\[foo id="([0-9]+)"' '[bar id="\1"' --regex --regex-flags='i' 示範了怎麼用正規表示式不分大小寫地取代 shortcode 的參數寫法。
不過指令文件也明白寫著，開啟 --regex 會讓執行時間拉長約 15 到 20 倍，資料量大的站台跑起來差距會很明顯。這代表 --regex 不該是預設選項，只有在確定字串比對做不到、真的需要模式比對的情境才開啟，其餘能用一般字串取代解決的，就沒必要多付這筆效能代價。
資料庫備份、核心更新與快取清理可以串成一支排程腳本
前面每一節都是單獨介紹的指令，批次操作真正的價值要到能排程自動跑才體現得出來。把備份、更新核心程式、清快取串成一份最小可行的例行維護邏輯：先備份，再更新核心程式，最後清一次快取，把原本要人手動一條條下的指令，交給系統定期自己跑。
匯出指定資料表，加快備份速度
批次操作動手前先備份是基本習慣，wp db export 底層呼叫的是 mysqldump，不特別指定檔名的話，預設會輸出成 {dbname}-{Y-m-d}-{random-hash}.sql 這種帶日期與隨機雜湊的檔名，方便辨識是哪一次的備份。
每次都全庫匯出速度會比較慢，如果只是要備份某幾張特定的表，可以用 --tables=<tables> 指定，例如 wp db export --tables=wp_options,wp_users 就只會匯出這兩張表；反過來想排除某些不需要的表，則用 --exclude_tables=<tables>。需要把匯出結果直接接給其他指令處理，而不是先存成檔案，wp db export - 可以把內容直接輸出到標準輸出，方便串進更大的腳本流程裡。
把多道指令寫進腳本，交給 crontab 定期執行
一份最小可行的維護腳本，邏輯大致是這樣：先匯出備份，接著跑 wp core update 更新核心程式、wp core update-db 更新資料庫結構，再用 wp cache flush 清一次快取，最後用 wp cron event run --due-now 把所有現在已經到期、卻還沒被觸發的排程事件補跑一次，文件範例的輸出會逐一列出被觸發的 hook 名稱與各自耗時。把這幾句指令依序寫進一支 shell script，再用 crontab -e 新增一行時間表達式加上這支腳本的路徑，就能讓系統定期自動執行，不用再靠人手動一條條敲。
wp core update 有時候會遇到「Another update is currently in progress」這則錯誤訊息，通常是前一次更新中斷、鎖定沒被正常釋放造成的。指令文件給的排除方式是先確認真的沒有其他更新正在進行中，再執行 wp option delete core_updater.lock 解除鎖定。想限制核心更新的幅度，--minor 可以讓 wp core update 只做次版本更新，不會跳到有較大改動的主版本，排程腳本裡若不想無人值守地跳大版本更新，這個旗標值得加上。
多個網站環境，用別名一次下同一組指令
同時管理本機、測試站、正式站這三種環境，或代管好幾個客戶的網站，每次下指令前都要先切換到對的目錄、確認對的資料庫連線，是另一種容易出錯的重複勞動。WP-CLI 用別名（alias）解決這件事，在 wp-cli.yml 裡先定義好每個環境的連線資訊，之後下指令只要在前面掛上對應的別名，就會自動指到正確的環境。
參照 WP-CLI 手冊的設定檔範例（主機與路徑換成 example.com），寫法是這樣：
@staging:
ssh: [email protected]
user: wpcli
path: /srv/www/staging
@production:
ssh: [email protected]:2222
user: wpcli
path: /srv/www/production
@both:
- @staging
- @productionCode language: YAML (yaml)定義好這些別名之後，wp @staging rewrite flush 就只會對測試站執行這句指令，不用先手動登入測試站的伺服器再敲指令；wp @both plugin update --all 則會對 @both 底下列出的兩個環境各跑一次同一句指令，一次把測試站與正式站的外掛都更新完，不用切兩次環境重複下兩次指令。
除了指到某個別名，--ssh=[<user>@]<host>[:<port>][<path>] 這個參數也能讓你不用先登入 SSH，直接對遠端主機執行指令，等於把「登入伺服器」這個步驟也一併省掉。--ssh 除了一般的 SSH 連線，也支援 docker:、docker-compose:、docker-compose-run:、vagrant 這幾種連線類型前綴，讓 WP-CLI 直接對容器或虛擬機裡跑的 WordPress 執行指令，管理容器化的開發環境時特別方便。
WP-CLI 也能呼叫 AI 生成文字與圖片
呼應 WordPress 7.0 核心加入的 AI Client 與 Connectors 連線設定，WP-CLI 也在推進對應的 wp ai 與 wp connectors 這兩組指令：wp ai 可以直接從終端機呼叫已經連接好的 AI 供應商，像是 OpenAI、Anthropic、Google 這些，生成文字或圖片；wp connectors 則負責管理這些 AI 連線本身的設定。這兩組指令綁定的是 WP-CLI 尚未正式釋出的下一個大版本，本文前面提到的 2.12.0 穩定版還沒有內建，要先用 wp cli update --nightly 切到開發版（或等正式版釋出），並且對應的 AI 供應商外掛已經在後台設定好連線金鑰，才有辦法實際跑起來。
動手之前，先用 wp ai status 確認目前環境支援哪些 AI 能力，這句指令會列出一張表格，顯示「文字生成」、「圖片生成」各自是不是已經可以使用。文字生成的用法是 wp ai generate text "Explain WordPress in one sentence"，直接在終端機生成一段文字，也可以額外指定 --model、--provider、--temperature 這些參數，控制要用哪個供應商的哪個模型、以及生成結果的變化程度。
放進批次維運的情境裡，實際用得到的地方是幫媒體庫裡的圖片補齊替代文字，wp ai generate text "Generate alt text for this image" --image=42 可以針對媒體庫裡 ID 為 42 的附件，生成一段描述當作替代文字，跟前面文章批次操作同一個邏輯，先篩出一批缺替代文字的圖片 ID，再逐一代入這句指令，就能把整批圖片的替代文字補齊，不用一張張手動打字。圖片生成則是 wp ai generate image "A minimalist WordPress logo" --destination-file=wp-logo.png，會依提示詞生成圖片並存成檔案。想確認目前設定了哪些供應商連線，wp connectors list 會列出每個供應商目前的連線狀態，像是已連接或尚未安裝；要查單一供應商的連線細節，則用 wp connectors get openai 這樣的寫法。這裡要提醒的是，這組指令產出的文字或圖片仍需要人工把關再上線，不是拿來自動發布內容用的。
高風險指令上線前，這幾個安全習慣不能省
前面每一節介紹的都是單一指令怎麼用，但批次操作沒有復原鍵，一個打錯的 ID 範圍、一個忘記加的篩選條件，就可能整批改錯或整批刪錯，而且往往是等到事後才發現。
能加 --dry-run 的指令，像 search-replace、plugin update，批次執行前只要先跑一次預覽，多花幾秒鐘看一次報告，確認變動範圍跟預期一致，就比事後回頭排查哪裡出錯省時間得多。牽涉到資料庫層級的操作，像 search-replace、db import，或是任何整批刪除的指令，動手之前一定要先跑一次 wp db export 留一份備份，wp db import 是直接執行 SQL 查詢覆蓋既有資料，本身沒有內建確認或復原機制，一旦匯入下去，前一個版本的資料就回不去了，備份是唯一的保險。
正式站之外，先在測試站把整個腳本邏輯完整跑過一次，確認每一步的輸出都符合預期，是另一個經常被省略、卻最該堅持的順序。共用主機上，下指令前先用 pwd 確認自己在哪個目錄，或是明確在指令裡帶上 --path，直接把作用範圍釘死，避免因為站錯資料夾而改到別人的網站。--allow-root 這個旗標則只在容器化或 CI 流程這類真的必要的情境才加上，一般環境下沒有理由讓 WP-CLI 用最高權限的帳號執行，習慣性地把 --allow-root 帶著跑，等於把原本該有的一道防線也拿掉了。
批次操作省下的不是幾分鐘的點擊時間，而是讓原本得花一整天巡邏才做得完的維護工作，變成一份可以重複執行、也可以排程自動跑的流程。這篇示範的每一組 WP-CLI指令，拆開來看都不難，難的是養成先篩清單、先預覽、先備份的順序，這個順序一旦建立起來，套用到任何一種批次任務都通用，不只是這篇提到的這幾種情境。下次面對後台介面點不完的重複工作時，先想一句指令能不能把它變成批次動作，往往比繼續逐筆點擊更值得。