WordPress 的 AI 团队拿到了 Matt Mullenweg 的批准，要把 MCP 做进核心，目标可能是 7.3。消息里最关键的一句不是「要做」，而是那句附加要求：尽一切可能避免引入新的漏洞。
MCP（Model Context Protocol）是让 AI 助手调用外部系统能力的标准协议。对 WordPress 来说，接入它意味着：AI 可以按标准接口读文章、改设置、装插件、查用户——不用你打开后台点鼠标。
这件事的来龙去脉
10 月初，MCP Adapter 插件进了 WordPress.org 插件目录，当时被描述为「实验性」。两周后，AI 团队在周报里说拿到了批准，要把 MCP 做成核心的原生能力，可能是 7.3 的目标，但没有发布承诺。
怎么落地还没定。摆在桌上的选项至少有三种：把适配器插件打包进核心；通过现有核心接口启用；或者只把特定部分做进核心。这三种方案的权限模型、升级路径、兼容性影响完全不同。
团队的早期数据也不太好看：在 28 个网站需求的测试里，七个 AI 智能体一共建了 193 个站，用 WordPress 的是零。另一组测试中，通过 MCP Adapter 操作一个已有站点，任务完成率同样为零。
为什么那句「避免新漏洞」是重点
MCP 的本质是「给外部程序开一个标准化的入口」。入口一旦开错，后果不是「AI 干得不好」，而是「谁都能进来干」。
回想这几周发生的事：UpdraftCentral 的连接密钥被窃，攻击者用它批量装后门，18 小时出现 99 种后门插件名；Rank Math 的正版安装包被植入恶意代码，11 小时窗口内数百客户受影响；LiteSpeed Cache 修了三个漏洞，两个能让未登录评论者在管理员浏览器里跑脚本。这些都不是「AI 的问题」，但它们说明同一个道理——WordPress 生态里任何一个能「远程操作站点」的通道，都是高价值目标。
MCP 会成为一个这样的通道，而且是官方的、被大量站点默认具备的。所以设计阶段最该回答的问题是：谁能连、连上能做什么、操作怎么审计、出错怎么回滚。
站长的现实预期
短期内不用等核心版。MCP Adapter 插件已经在目录里，WooCommerce 11.3 起默认启用商品和订单能力。想试的话现在就能试，但请按「临时开一个受控入口」的心态去做：
用单独的账号授权，只授予必要的角色；连接用完就断，不要长期挂着；给 AI 能做的操作划一个最小集，先只读，再逐步放开写；保留操作日志，任何批量改动都要能追溯。
还有一个更朴素的原则：发布权留在人手上。让 AI 写草稿、改元数据、补 alt 文本、批量整理标签，这些收益明确、出错可回退；让它直接发布，一次失误就是一个进了索引的垃圾页。
这类消息该怎么读
「拿到批准」不等于「下个版本就有」。WordPress 核心的决策链条长，一个提案从批准到落地常常跨越好几个版本，中间可能改方案、可能降级为插件、也可能搁置。
真正值得关注的时间点有三个：MCP 以什么形式进入核心（打包插件 /原生实现 /部分实现）；权限模型怎么设计（复用现有角色还是新建一套）；以及第一次真实的安全审计结果。前两个决定它能不能用，第三个决定它敢不敢用。
一个更长的判断
过去二十年，CMS 的竞争点是「谁能让人更容易地建站」。接下来几年的竞争点可能是「谁能让人（和 AI）更安全地改站」。
这两件事的技术要求不一样。前者拼的是编辑器体验和模板生态，后者拼的是接口设计、权限粒度和可观测性。WordPress 在第一个战场赢了很久，第二个战场才刚开始。
对站长来说，现在能做的准备很具体：把站点的用户角色理一遍，谁是什么权限、哪些账号其实不需要管理员；把插件清单理一遍，哪些真的在用、哪些装了没删；把备份验证一遍，不只是「有备份」，而是「试过能恢复」。这些事跟 MCP 无关，但 MCP 来了之后，它们会决定你的站是被 AI 帮了，还是被 AI 坑了。
本文根据公开报道整理，主要参考：WPWithin周报 Issue24、WP Weekly313期（MCP进核心进展）（2026-10-24）。厂商与项目的后续动作可能继续变化，涉及版本号和漏洞编号请以官方公告为准。
