WordPress 7.0 於 2026年5月20日發布，版本代號 Armstrong，比原訂 2026 年時程表上的日期晚了六週，而它是自 block editor 以來對代理商影響最大的一次核心發布。標題寫的是核心現在可以和生成式 AI 模型對話。更值得注意的細節是，核心現在還規定了外掛應該如何與這些模型對話，這悄悄改變了網站上每一個外掛能對自己地盤作出的假設。

對編輯者來說，看得見的變化並不多。多了一個 Command Palette、一個更整潔的儀表板、一個字型管理畫面，以及更好用的修訂版本。但對以維護網站為業的人來說，真正重要的變化藏在後台底下：options 資料表裡的一個憑證儲存區、一份網站能做哪些事的註冊表，以及一個把它們列出來的 REST 介面。這些都不是選配，因為它們是隨核心一起送到的，而不是隨某個人挑選的外掛送到的。

這是一份從業者角度的解讀。實際交付了什麼、發布前十二天被抽掉的是什麼以及為什麼、這次更新會弄壞什麼又不會弄壞什麼，以及面對一位剛讀到「AI 進入 WordPress」標題的客戶該怎麼說。

應該更新嗎？ 應該，但請一路更新到 7.1，而不是停在 7.0。WordPress 7.1 已於 2026年8月19日發布，7.0 後面也已經跟了四個維護版本。在管理員於「設定」再到 Connectors 儲存供應商金鑰之前，AI 功能都是靜止的，所以更新本身不會把你的任何內容送到任何地方。這次更新真正的風險是一般的外掛與佈景主題相容性，而不是 AI。

WordPress 7.0 實際交付了什麼

版本代號取自路易斯·阿姆斯壯，延續了專案用爵士樂手命名主要版本的慣例。發布公告提到超過 875 位貢獻者，以及超過 420 項增強與修正。

真正落地的清單短得剛好有用。核心得到了 AI Client，這是一個與供應商無關的 PHP 介面，用來把提示送給生成式模型。它在「設定」底下得到了 Connectors 畫面，管理員在這裡儲存供應商憑證。它也得到了 Abilities API 的 JavaScript 部分，其 PHP 部分早在 6.9 就已交付。

在編輯這一側，有按 Ctrl+K 或 Cmd+K 叫出的 Command Palette、現代化的儀表板、專用的字型管理頁面、可以視覺化拖曳瀏覽修訂版本的功能，以及新的 Heading、Breadcrumbs 與 Icons 區塊，還有相簿用的燈箱投影片。

沒有落地的，正好是整個版本原本圍繞著打造的那個功能。即時協作編輯在發布前十二天被移除。這個缺席，以及它背後的理由，比功能清單更能說明核心目前的狀態。

日期為什麼會挪動

發布原本訂在 2026年4月9日。它延到 5月20日，是因為協作編輯還沒準備好，而專案不願意就這樣把它送出去。路線說明文章明確寫著，延期的存在是「為了留出更多時間處理關於即時協作實作的測試回饋」，而且基於技術理由，開發週期在保留發布候選版本號的同時退回了 beta 階段。

這很不尋常。一個已經走到 RC 的主要版本退回 beta 是很強的訊號，而這是正確的決定。

AI Client：核心交付的是抽象層，不是模型

關於 WordPress 7.0 最重要的架構事實是，核心並不包含 AI 模型、API 金鑰，也不包含與任何供應商的關係。AI Client 開發說明直白地寫著「WordPress 核心不會直接內建任何 AI 供應商」。

核心交付的是一個一致的 PHP 介面。外掛呼叫 wp_ai_client_prompt()，取得一個 WP_AI_Client_Prompt_Builder 物件，串接 using_temperature() 或 using_model_preference() 之類的設定，最後以 generate_text() 或 generate_image() 收尾。錯誤以 WP_Error 回傳，請求走 WordPress 的 HTTP 傳輸層，整套東西都接進了掛鉤系統。

實務上的效果是，外掛作者不必再為每一家模型供應商各寫一次 HTTP 用戶端、重試迴圈、金鑰儲存畫面和設定頁。他們描述自己想要什麼，核心負責繞送。

這確實減少了重複的程式碼。它同時也是一次信任的集中，而這正是你在打開任何開關之前值得先想清楚的部分。

連接器是什麼

連接器是你的網站與某個外部服務之間被註冊下來的關係。在 7.0 裡，唯一的連接器類型是 AI 供應商，並且有三個旗艦供應商外掛分別涵蓋 Anthropic、Google 與 OpenAI，每一個都要單獨安裝。

Connectors API 開發說明描述了憑證是如何解析的。金鑰可以來自環境變數、PHP 常數或資料庫設定，並依這個順序檢查，選項名稱遵循 connectors_ai_{$id}_api_key 這個模式。

有一個細節值得每一位對網站負責的人留意。開發說明寫道，存放在資料庫裡的 API 金鑰「並未加密，只是在使用者介面中被遮蔽」，而加密被列為後續工作追蹤。如果你透過後台畫面設定金鑰，它就以明文躺在 wp_options 裡，而這個資料庫的每一份備份從此都含有一份會產生帳單的憑證。

如果你不寫程式，這代表什麼

對網站擁有者來說，這個變化沒有聽起來那麼複雜。在兩件事同時成立之前，不會有任何東西被生成、被摘要或被改寫：裝了某個供應商外掛，而且有人把一把可用的金鑰貼進「設定」再到 Connectors 裡。

在那之前，AI Client 只是一個休眠的函式庫。更新到 WordPress 7.0 不會把你的文章送給模型，不會在任何地方建立帳號，也不會產生帳單。

它真正做的，是降低你安裝下一個外掛時的門檻。一個過去必須向你索取金鑰的外掛，現在可以發現網站上已經設定好的金鑰並直接使用。這很方便，也正好是那種應該在它意外發生之前先寫下政策的事情。

Abilities API 與外掛設計為何改變

三年之後仍然重要的是 Abilities API，而它本身與 AI 並沒有必然關係。它是一份註冊表。外掛透過 wp_register_ability() 註冊一個具名的功能單元，形式為 namespace/ability-name，附上一段人類可讀的描述、輸入與輸出的 JSON Schema、一個執行回呼，以及一個選用的權限回呼。

官方文件把權限回呼呈現為一次普通的權限檢查，例如直接回傳 current_user_can( 'manage_options' )。這就是全部的安全模型，它的可靠程度不會超過外掛作者的判斷力。

一旦這些能力存在，別的東西就可以列舉它們。一個模型可以拿到這個特定網站能做哪些事的清單，以 schema 的形式，然後呼叫其中一項。用戶端的 Command Palette 同樣可以，這也正是該 API 的 JavaScript 部分與 Command Palette 在同一個版本落地的原因。

對外掛作者而言，設計上的後果是實際存在的。一個過去只能透過你自己的後台畫面、你自己的 nonce 和你自己的表單才能到達的功能，現在可能會被期待以能力的形式公開出來，並附上一份機器可讀的合約。那是另一種攻擊面，也是另一種文件負擔。

7.1 改變了什麼

WordPress 7.1 收緊了這份註冊表，而不是擴張它。7.1 的 Abilities 開發說明加入了驗證篩選器 wp_ability_validate_input 與 wp_ability_validate_output、一個在執行開始時觸發的動作 wp_ability_invoked，以及一個 public 中繼資料旗標，用來控制某項能力是否能透過 REST 在 /wp-json/wp-abilities/v1/abilities 被發現。

那份開發說明裡還有一句話，每一位寫記錄功能的外掛作者都該讀一讀。呼叫掛鉤拿到的是原始、未經正規化的輸入，因此開發者「應避免不加區分地記錄輸入，因為其中可能含有憑證、個人資訊或其他敏感資料」。

即時協作，以及它需要的那張資料表

協作編輯建立在 Yjs 這種無衝突複製資料型別之上，外面包了一層同步提供者抽象層。核心預設交付一個 HTTP 輪詢提供者，選它而不選 WebSocket 是因為它在任何主機上都能跑，而外掛可以透過篩選器替換傳輸層。

問題從來不在合併演算法，而在同步資料放在哪裡。最初的實作把它保存到文章中繼資料裡，這在 WordPress 裡是顯而易見的選擇，對於每秒變動好幾次的資料卻是錯誤的選擇。

寫入文章中繼資料會觸發快取失效。只要編輯器開著，同步資料就持續在寫入，於是每一次寫入都會清掉那篇文章的快取查詢。實際情況是，一個人編輯一個頁面，就足以讓網站的持久物件快取在整個工作階段期間不停被清空。

關於文章中繼資料，這是一個很好的通用教訓。它是一個鍵值儲存，綁在它所依附內容的快取生命週期上，用來存放隨文章一起變動的屬性是合適的。它不是拿來放高頻狀態的暫存空間。

被量測出來的修正，以及那個決定

貢獻者在八種代管環境中測試了儲存策略。效能分析得到的結論是，以 transient 為後盾的專用資料表比既有實作快大約 52%，而純粹的專用資料表快大約 37%。在有持久物件快取的情況下，兩種以 transient 為基礎的策略都降到每次派送一次資料庫查詢。

最後選的是搭配 transient 的自訂資料表。然後，就在同一天，這個功能被抽掉了。

移除公告列出的理由是「對表面積、競爭條件、伺服器負載、記憶體效率，以及模糊測試中發現的反覆出現的缺陷的疑慮」，並說這個決定是「為了替使用者交付一個穩定可靠的 WordPress 7.0 版本」而作出的。

目前的狀況

它在 7.1 裡也沒有交付。7.1 現場指南寫明，即時協作編輯「在 WordPress 7.1 週期中收到了大量測試與回饋，但並未在最終版本中啟用」。

Notes 這個相關但獨立的功能，用來在區塊層級留下註解，確實交付了，並且在 7.1 中透過豐富文字格式與 @ 提及得到改進。如果客戶要求在 WordPress 裡做到 Google 文件式的共同編輯，今天誠實的答案是：Notes 涵蓋了審閱流程，而同時輸入仍然不在核心裡。

後台的變化，以及它們會產生的客服工單

有兩處變化會帶來支援請求，而它們都不是缺陷。

按 Ctrl+K 或 Cmd+K 叫出的 Command Palette 一旦學會就非常快，但 Ctrl+K 在許多編輯器裡是插入連結的快速鍵，於是會有使用者回報說插入連結壞了。它沒有壞，是焦點所在的脈絡決定了哪一個處理常式勝出。

更大的一處是現代化的儀表板。任何用截圖訓練過員工的客戶，手上的訓練教材現在都過時了；任何靠特定 class 或 DOM 結構往後台畫面注入標記的外掛，都可能顯示得很奇怪。這屬於外觀問題而不是功能問題，但它會在更新當天、在每一個網站、對每一位使用者出現，這讓它成為整個版本裡對非開發者最顯眼的部分。

在你更新任何東西之前，替每個客戶預留一小時，寫一份附上新截圖的簡短書面說明。這比同一段解釋用電子郵件重複十五次要便宜。

真正要緊的相容性問題

版本號看起來像是一次破壞性發布，PHP 的要求卻不是。正如PHP 支援說明所闡述的，自 WordPress 7.0 起，受支援的最低 PHP 版本是 7.4，而建議的最低版本仍然是 8.3。對 PHP 7.2 與 7.3 的支援在這個版本中被取消。

這份說明也廢除了過去貼在較新 PHP 版本上的「beta」標籤，並記錄了 WordPress 6.9 與 7.0 對 PHP 8.5 的完整支援。

重點在於「受支援」與「合理」之間的差距。PHP 7.4 已於 2022 年 11 月結束生命週期，所以一個剛好卡在最低線上的網站，跑的是一個將近四年沒有收到安全性修補的直譯器。如果到了 2026 年你的代管還停在 7.4，那麼 WordPress 的版本並不是你最急迫的問題。

實務上的損壞遵循一個可預測的模式。被棄置的外掛最先出問題，尤其是那些操作後台 DOM 或編輯器 iframe 的外掛。把後台樣式寫死的自訂佈景主題會顯示錯亂。自帶 React 打包檔的頁面建構器是編輯器白畫面最常見的來源，同時通常也是修得最快的。

一套具體的更新流程

先做測試環境。 把正式環境連同資料庫複製到一個不會被索引、也不會寄信的環境。底下沒有一項值得在正式網站上直接做。

記錄基準。 記下 PHP 版本、外掛與佈景主題清單及各自版本，以及目前的 WordPress 版本。把客戶每天使用的兩三個後台畫面截圖存檔。

先只更新 WordPress。 保持外掛與佈景主題不動，然後走一遍前台、文章編輯器、網站編輯器、如果有 WooCommerce 就走一遍結帳，以及所有自訂後台畫面。這一步出現的失敗屬於核心或某個不相容的擴充功能，而把它和外掛更新分開，正是照這個順序做事的全部理由。

接著分小批更新外掛，每批之間重新測試，這樣一旦出現迴歸問題，嫌疑名單就很短。

去看錯誤記錄，而不是用肉眼看頁面。 來自淘汰呼叫的 PHP 通知未必會顯示出來，卻會安靜地把記錄檔填滿好幾個月。

讓 Connectors 畫面保持空白。 在沒有設定任何 AI 供應商的狀態下推出這次更新，把啟用某個供應商當成一次獨立、刻意、需要自己核准流程的變更。周邊的控管措施可以參考我們的WordPress 安全強化清單，更新之後該量測什麼則可以參考效能稽核指南。

治理：一個連接器被允許做什麼

這裡有一個由能力層製造出來、而沒有任何外掛作者能替你回答的問題。第三方外掛可以註冊一項能力，去讀取客戶紀錄、匯出使用者或編輯已發布的內容，而一個能存取註冊表的模型就可以呼叫它。權限回呼是一次權限檢查，所以模型是以當前登入者的權限在行動。

如果那個人是管理員，模型就能做管理員能做的事。這不是設計上的缺陷，這是設計照文件正常運作。但它確實意味著，網站上存在哪些連接器是一個資料保護層面的決定，而不是一項 IT 偏好。

CMS 裡的內容很少只是行銷文案。留言、表單送出、訂單紀錄與使用者個人檔案都是個人資料，把它們送給一個外部模型是一項你必須能夠說明理由的處理行為。英國資訊委員辦公室（ICO）的AI 與資料保護指引闡述了問責與透明方面的期待，包括證明在設計階段就顧及資料保護，以及讓治理的力度與用途相稱。

對一個客戶網站來說，務實的最低要求是一份簡短的書面政策：允許哪些連接器、誰可以新增連接器、哪些能力透過 REST 公開揭露，以及與供應商之間的資料保存立場是什麼。在有人貼上金鑰之前把它寫下來，因為在那之後，它就不再是政策，而是一份事故報告。

接下來排隊的是什麼

WordPress 7.1 於 2026年8月19日抵達，帶來了全域樣式裡的響應式設定、跨編輯器持續存在的管理工具列、一個像樣的媒體編輯視窗、Playlist 與 Tabs 區塊，以及前面已經提過的 Notes 改進。它也完成了文章編輯器的 iframe 化，包括那些註冊舊式 meta box 的網站，這是最可能讓老舊外掛露出問題的變化。

WordPress 7.2 計畫成為 2026 年最後一個主要版本。7.2 發布頁面把最終版本放在 2026年12月8日至10日這個區間，beta 從 10 月下旬開始。這份時程是計畫而不是既成事實，而這個專案今年已經挪動過一次主要版本的發布日期。

協作編輯仍然是未來某個版本的明顯候選，但它已經錯過兩次了，沒有人應該向客戶承諾一個日期。

這在商業上改變了什麼

有三段客戶對話會改變，其中只有一段是關於 AI 的。

第一段是更新對話。WordPress 7.0 與 7.1 值得當成一次帶測試環境驗證的代管更新來收費，因為 iframe 化的編輯器與後台重新設計確實會讓老舊擴充功能現形。把它當成附帶書面測試計畫的固定價格方案來賣，比把它吸進維護合約、然後在傍晚六點發現頁面建構器壞掉，既更誠實也更賺錢。

第二段是治理。連接器政策、能力審查與憑證處理，都是 2026 年 5 月之前並不存在的可計費顧問工作，而且它們更適合代理商，而不是內部的行銷團隊。

第三段是開發工作。AI Client 拿掉了在網站裡打造 AI 功能時無聊的那一半，它壓低了管線的價格，抬高了「知道什麼值得做」的價值。如果你正拿它跟客製化開發比較，我們關於WordPress 與客製化開發的比較說明了界線通常畫在哪裡，而我們關於WordPress 開發者費率的筆記則說明了這類工作應該值多少錢。

Mecanik 把核心版本升級、連接器治理與 AI 功能開發，當成我們WordPress 開發與AI 整合服務的一部分。我們看到的模式很一致：更新本身是例行公事，昂貴的意外來自三年沒人審查過的擴充功能。

常見問題

WordPress 7.0 是什麼時候發布的，為什麼會延期？ WordPress 7.0「Armstrong」於 2026年5月20日發布，比原訂時程上的 4月9日晚了六週。延期是為了處理關於即時協作編輯實作的測試回饋，而開發週期在走到發布候選之後退回了 beta。協作編輯最後於 2026年5月8日被從這個版本中移除。

WordPress 7.0 會把我的內容送給 AI 供應商嗎？ 不會。核心交付了 AI Client，但沒有內建任何 AI 供應商、模型或 API 金鑰。在管理員安裝供應商外掛，並在「設定」再到 Connectors 儲存一把可用憑證之前，不會有任何內容被送到任何地方。在那之前，AI Client 是一個既不花錢也不傳輸資料的休眠函式庫。

Abilities API 是拿來做什麼的？ 它是一份註冊表，讓外掛可以宣告一個具名的功能單元，帶有以 JSON Schema 描述的輸入與輸出、一個權限回呼和一個執行回呼。包括 AI 模型與 Command Palette 在內的其他軟體，就能據此列舉一個網站能做哪些事並呼叫它們。PHP 部分在 WordPress 6.9 交付，JavaScript 部分在 7.0 交付。

WordPress 7.0 需要哪個版本的 PHP？ 自 WordPress 7.0 起，受支援的最低版本是 PHP 7.4，這個版本取消了對 PHP 7.2 與 7.3 的支援。建議的最低版本仍然是 PHP 8.3。由於 PHP 7.4 已於 2022 年 11 月結束生命週期，只滿足最低線就等於在跑一個不再受支援的直譯器，所以請把 8.3 或更高當成真正的要求。

即時協作編輯現在能用了嗎？ 核心裡還不能。出於對競爭條件、伺服器負載與記憶體效率的疑慮，它在發布前十二天被從 WordPress 7.0 移除，在 WordPress 7.1 中同樣沒有啟用。獨立的 Notes 功能確實交付了，它支援帶提及的區塊層級註解，涵蓋的是審閱流程而不是同時輸入。