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 里是显而易见的选择，对于每秒变化好几次的数据却是错误的选择。

写入文章元数据会触发缓存失效。只要编辑器开着，同步数据就在持续写入，于是每一次写入都会清掉那篇文章的缓存查询。实际情况是，一个人编辑一个页面，就足以让站点的持久对象缓存在整个编辑会话期间不停地被清空。

关于文章元数据，这是一个很好的普适教训。它是一个键值存储，绑定在它所挂靠的内容的缓存生命周期上，用来存放随文章一起变化的属性是合适的。它不是用来存放高频状态的草稿空间。

被测量出来的修复，以及那个决定

贡献者在八种托管环境中测试了存储策略。性能分析得出的结论是，由瞬态支撑的专用表比既有实现快大约 52%，而纯粹的专用表快大约 37%。在存在持久对象缓存的情况下，两种基于瞬态的策略都降到了每次分发一次数据库查询。

最终选择的是带瞬态的自定义表。然后，就在同一天，这个功能被抽走了。

移除公告列出的理由是「对表面积、竞态条件、服务器负载、内存效率，以及模糊测试中发现的反复出现的缺陷的担忧」，并说这个决定是「为了给用户交付一个稳定可靠的 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 化，包括那些注册了旧式自定义栏目的站点，这是最可能让老插件暴露问题的变化。

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 功能确实交付了，它支持带提及的区块级评论，覆盖的是评审流程而不是同时输入。