把 WordPress 交给 AI 操作有三条路：免费的站内 MCP 插件、平台自带的 MCP 服务、自己搭网关。选哪条不取决于功能多少，取决于你愿意给出多少权限。
最近半年 WordPress 生态里冒出一批「MCP 插件」，把站点本身变成一台能被 AI 调用的服务器。加上平台自带 MCP 服务的托管方案、以及自己写一层网关的做法，现在实际有三条路可走。结论先给：先想清楚愿意让 AI 干到哪一步，再回头选工具，顺序反了会出事。
配图：ZKUI 编辑部
第一条：免费的站内 MCP 插件
代表是 HandyMCP 和 WPVibe 这类，纯 PHP 跑在自己的站上，不需要中转服务、不需要另开账号，AI 客户端直连你的域名。功能层面已经相当完整：文章的增删改、区块与 Elementor 页面、WooCommerce 商品、表单、媒体库、SEO 标题与描述，甚至主题文件的草稿预览。
它们真正值得看的是权限设计。HandyMCP 默认把改动记成草稿、保留最近 20 次可回滚的操作、可以按工具组开关并设为只读；WPVibe 走 WordPress 自带的应用密码，危险操作会弹审批面板，写主题文件时先克隆一份到沙箱再让你预览。这些机制不是花架子——它们决定了出事的时候你是「一键回滚」还是「重装站点」。
第二条：平台自带的 MCP 服务
托管建站平台和部分商业插件会直接内置 MCP 端点，开箱即用，配置最少。代价是权限模型由对方决定，你能调的通常只有开关。这条路适合「只想让 AI 写文章、改文案」的轻量需求；一旦涉及用户、订单、站点设置，就要去看它给的令牌到底继承了谁的权限。
第三条：自己搭一层网关
用一台小机器跑 MCP 网关，只对外开放白名单里的几个接口，WordPress 那边用应用密码或自建 REST 路由对接。工作量大，但能做的事也最细：按 IP 限流、按动作审计、把危险工具彻底摘掉。适合多站点、有合规要求、或者要给客户交付的场景。
无论走哪条，这四条底线别破
- MCP 令牌等于账号。10 月 30 日 AI Engine 插件那个 CVE-2026-110732 就是例子：OAuth 注册接口没设防，攻击者能拿到管理员级令牌。给 AI 的账号，不要用超级管理员。
- 默认草稿，发布要二次确认。让 AI 直接发到线上，等于把「审稿」这一步删了。
- 开审计日志，并且定期看。不看日志的审计等于没开。
- 改之前能回滚。文件、数据库、主题，至少有两样能一键还原。
对站长的实际影响
这条链路真正的门槛不是「能不能接上」，而是「接上之后敢不敢让它干活」。建议的上手顺序是：先只开「读」和「草稿」两类工具，跑两周看它写的东西像不像人话；确认没问题，再放开媒体库和 SEO 字段；商品、订单、用户这三类，除非你有完整的备份和审计，否则先别给。
本文根据公开报道整理，主要参考：WordPress 插件库 HandyMCP、WPVibe 说明页，HOL 安全公告（2026-10-30）。
