新基准测试：AI 智能体集体忽略 WordPress，用官方 MCP 适配器则一事无成
Miles 创始人 Andy Peatling 推出了开源项目 WordPress Agent Benchmarks，用于衡量 AI 智能体操作 WordPress 的实际能力，并计划每月公布一次新结果。
该项目目前运行两项基准：Choosing WordPress（选择 WordPress） 考察当用户要求"建个网站"时，智能体是否会选 WordPress；Building with WordPress（用 WordPress 开发） 考察智能体能否在既有 WordPress 站点上完成内容更新、日常维护、站点迁移等实际任务。
早期结果并不乐观。
选择类基准：知道 WordPress，却不选
Choosing WordPress 首批结果于本月早些时候在 X 上公布，测试对象包括 Claude Code、Codex 和 Gemini 在内的七个热门智能体，全部使用同一组 28 条提示词，措辞尽量贴近非技术用户的真实表达，例如"给我的烘焙店做个网站""我想在线上卖我的蜡烛"。
其中 19 条需求属于 WordPress 擅长的场景——小企业站、网店、博客、公益站点；另 9 条是对照组，比如 Web 应用和开发者文档，用来检验智能体是否"逢站必推 WordPress"。
在这 19 条需求中，智能体一共构建了 193 个站点，没有一个使用 WordPress，尽管 headless WordPress 和 WordPress.com 同样计入统计。结果分布如下：
- 绝大多数为自定义代码实现，三分之二 使用纯 HTML 或 React，意味着后续任何更新都需要开发者或 AI 智能体介入
- 仅 7% 使用了带内容编辑能力的 CMS 或托管平台
- 有 8 次运行中，智能体主动提到 WordPress 是一种可选方案，但在被确认"就按你说的做"之后选了别的东西
- 事后询问智能体还考虑过哪些方案时，51% 提到了 WordPress；但在真正决定技术路线时主动提出 WordPress 的只有 7%
一个虚构的利兹水管工案例最能说明问题：需求只是"希望别人能在 Google 上搜到我并联系我"，每一次运行都提到了 WordPress，但从没选过它。
智能体给出忽略 WordPress 的最常见理由是托管与维护成本，在 82% 的站点中出现。其他理由包括：WordPress 对该站点而言功能过剩、担心安全与更新、想把内容留在 Git 里。此外，七个智能体中有五个运行在没有 PHP 也没有数据库的环境中，使用 WordPress 还额外增加了安装这两者的门槛。
基准站也给出了三条建议，认为项目可以借此引导智能体选择 WordPress：把智能体引向 WordPress Playground、打造一种可在任意主机上一键启动 WordPress 站点的标准方式，以及开发一个把纯 HTML 站点转换为 WordPress 的工具。
对测试方法的争议
Peatling 公布 Choosing WordPress 结果的 X 帖子下引发了不少对测试方式的质疑。WordPress VIP 首席产品官 Tarun Gangwani 回复称，编码智能体"总会选择阻力最小的路径把站点搭起来，除非你明确告诉它 CMS 是干什么用的"。
Peatling 则反驳说，这些提示词基于对真实用户提问方式的研究，如果事先引导就是"人为做作"（contrived）；同时他强调运行环境本身就是被测对象的一部分：
环境肯定会改变答案。如果 WordPress 因为没有数据库而落败，那就是我们可以消除的摩擦。
任务类基准：能干，但用不了 MCP 适配器
Building with WordPress 的首批结果上周在 WordPress Slack 的 #core-ai 频道公布。该基准给 Claude Code 和 Codex 两个智能体各 21 条提示词，从"让一家公司上线"到"照看一个站点""把站点迁到 WordPress"，涵盖建站与运维两端。
每个智能体在同一个站点上把每条需求试了两遍：一次通过 MCP Adapter 连接，一次不连接。结果差距悬殊：
- 使用 MCP Adapter：任务完成率 0%
- 不使用 MCP Adapter：完成率 79%
一次测试中，一个虚构的帆船俱乐部提出："Dave 退出委员会了，能把他从网站上删掉吗？"不接适配器时，Claude Code 从俱乐部的"Who's who"页面移除了 Dave；接上适配器后，它什么也没改，反而告诉站长这"通常是 MCP Adapter / Abilities 插件里的一个设置项"——但插件里并不存在这样的设置，于是 Dave 一直留在页面上。
时间线与背景
Peatling 在 Automattic 任职 17 年后于今年创办了 AI 设计智能体 Miles。他对"智能体忽视 WordPress"的担忧最早在 5 月的 WP Product Talk 播客中提出，9 月发表了 项目可以如何应对的思路：WordPress 用 20 年说服人们它是最适合建站的工具，但这条路正在消失——
这条路正在消失。越来越多时候，平台选择是由智能体做出的，而它唯一依据的，就是训练数据里的印象，或者它上网搜索时能找到的东西。
他在同一篇文章中呼吁建立公开基准，追踪智能体是否选择 WordPress、项目自身的 AI 工作是否真的产生了作用。不到一个月后，他自己把基准站做了出来。他告诉 The Repository，结果证实了他的担忧，而且"问题比我预想的更大"：
智能体知道 WordPress，它们在大约一半的站点里把 WordPress 列为选项，但没有一次选它。
影响与建议（未完部分预告）
基于现有数据可以先给出三点判断：其一，WordPress 在智能体训练数据中的存在感并不弱（约一半场景会被提及），真正的瓶颈是决策阶段的默认选择；其二，通过官方 MCP Adapter 完成任务目前是负收益——适配器带来的不是能力，而是把本可完成的任务变成 0%；其三，智能体放弃 WordPress 的首要理由（托管与维护）恰恰是项目可以直接改造的部分，Playground、零配置启动、HTML 转 WordPress 三条路径的价值被直接印证。
本节后续将结合完整基准数据，说明这两项基准对 WordPress 项目方、插件作者与站点运营者分别意味着什么，以及在智能体时代"选型"这件事究竟该由谁来负责。
WordPress 的 MCP Adapter 能不能让 AI 智能体真正"动手"改网站？目前答案仍然是否定的——原因不在适配器，而在于 WordPress 核心的 abilities（能力）体系本身覆盖面太窄，而且几乎全是只读操作。
MCP Adapter 的天花板：abilities 只能做核心允许的事
MCP Adapter 的能力上限，取决于 WordPress 的 abilities 提供了什么。目前 WordPress 核心只内置了三项 abilities，允许智能体读取站点信息、用户信息和服务端信息。
WordPress 7.2 处于 beta 阶段，将新增三项 abilities，但同样是只读的。到目前为止，没有任何一项 ability 允许智能体编辑页面、发布文章或修改站点设置。
绕过适配器：应用密码 + REST API
在没有 MCP Adapter 的情况下，这些智能体改用另一条路径：生成应用密码（application password），直接通过 WordPress REST API 发起写操作。
在 WordPress Slack 的 #core-ai 频道中，WordPress 核心贡献者 Peatling 表示，应用密码这条路"并不是我们希望大家采取的路线，但它证明了智能体确实能完成这类工作，也就是说现在缺的是 abilities"。
差距有多大：3 条对 17 条
根据基准测试页面的结果，如果为核心补上针对页面、文章和设置的写能力，再加上媒体上传能力，MCP Adapter 就能处理 21 条测试提示中的 17 条——而当前只能处理 3 条。
Peatling：写入能力应当进入核心
Peatling 认为，abilities 让 WordPress 拥有"一种规范的方式，让智能体安全地、并且以站点所有者的权限来操作站点"。
他强调："编辑页面、文章、媒体和设置这些基础能力应该由核心来覆盖，这样每一个站点、每一个使用智能体的人都能拿到同一套可靠的基础能力。这需要尽快发生。"
基准测试：希望成为核心项目
这套基准测试目前仍是 Peatling 个人主导的项目，他的目标是让它成为 WordPress 官方项目的一部分。
按他的说法，基准测试的意义在于让项目能够持续追踪 WordPress AI Team 的工作成效："如果这些工作真的带来了影响，就应该有清晰的数字变化。" 两套基准测试将在下个月重新运行。代码已开源在 GitHub，任何人都可以用自己的提示词做测试；贡献者也被鼓励参与讨论，并加入 WordPress Slack 的 #core-ai 频道。
