做 WordPress 站的人大概都经历过这种循环：想改个东西，切到后台，找到对应页面，点开，改完保存，再切回编辑器继续写代码。如果改动量大，这个来回切换能占掉半天。
有没有可能让 AI 直接改站？市面上已经有不少 WordPress MCP 插件在做这件事，但它们大多有一个共同点：要在你的站点上开一个 HTTP 接口，然后靠令牌或应用密码做鉴权。接口一旦暴露，就是个攻击面。
8 月 30 日出现在 GitHub 上的开源插件 shim-mcp，走了另一条路。它把 WP-CLI 本身当成传输层，不占用端口、不签发令牌、整个链路里没有 HTTP 请求。
先搞清楚：它跟别的插件差别在哪
这一点值得单独讲，因为很容易混淆。
不少 WordPress MCP 插件也提到了 WP-CLI。但在那些方案里，WP-CLI 是「AI 可以调用的一个工具」——模型通过一条经过鉴权的 HTTP 连接，请求远程服务器替你执行 wp 命令。能用，但连接仍然是远程的、仍然走 HTTP、仍然需要令牌。
shim-mcp 的做法是：WP-CLI 就是传输层本身。服务器作为一个本地进程运行在你的机器上，通过管道（STDIN/STDOUT）说 MCP 协议的 JSON-RPC。没有 HTTP 请求，没有需要签发或吊销的令牌，也没有任何东西在监听端口。
对一份你已经 checkout 到本地的站点代码来说，这个差别是本质性的——它不是把认证面「加固」了，而是把认证面整个去掉了。
56 项能力，覆盖 13 个域
shim-mcp 在插件里内置了 56 项能力（abilities），分布在 13 个域：
文章 6 项、页面 6 项、分类法 4 项、搜索 1 项、修订版本 2 项、媒体 5 项、用户 6 项、插件 4 项、菜单 7 项、小工具 3 项、评论 6 项、站点选项 3 项、系统 3 项。
具体能做什么？举几个例子：文章和页面都支持列表、读取、创建、更新、删除，以及正文批量替换文本（支持字面量或 PCRE 正则，还能预览而不保存）；媒体域管上传和媒体库；菜单域可以增删改菜单项；评论域支持审核。
能力不是靠「一个操作一个工具」堆出来的，而是通过三个元工具暴露：discover-abilities（发现）、get-ability-info（查详情）、execute-ability（执行）。客户端在运行时动态发现全部能力，不用为每个操作预置一个工具。
还有个设计值得一提：所有能力都通过 WordPress 自己的 wp_register_ability() 注册，走的是官方的 Abilities API。这意味着其他插件注册的能力也会被自动暴露出来，不需要额外写适配代码。
权限模型：这才是它最值得夸的地方
把一个 WordPress 站的操作权交给 AI，安全是绕不开的问题。shim-mcp 在这块做得相当扎实：
逐能力权限声明——每一项能力都声明了所需的 capability，并且有 permission_callback 做检查。
逐对象二次校验——凡是涉及具体对象的能力，在读取或修改之前，还会再校验一次针对该对象的 capability（edit_post、delete_post、read_post、edit_user、delete_user、edit_comment）。用作者的话说：一个贡献者的客户端改不了编辑的文章；持有 edit_posts 不等于能编辑「任意」一篇文章。
MCP 端点不带任何特权——订阅者拿到应用密码也做不了编辑的动作。插件从不提权、从不以其他用户身份运行、从不绕过 current_user_can()。
选项更新有黑名单——options/update 会拒绝一批可能被用来提权或锁死站点的设置：active_plugins、siteurl、home、default_role、users_can_register、wp_user_roles 等。作者说明这是针对「AI 客户端行为异常」的纵深防御，不是权限边界——因为调用方本身已经持有 manage_options 了。
写 wp-config.php 默认关闭——这是唯一危险的一项。修改调试常量的能力默认是拒绝的，除非你显式加上 define( 'SHIM_MCP_ALLOW_CONFIG_WRITES', true );。即便开了，在 DISALLOW_FILE_EDIT / DISALLOW_FILE_MODS 生效、文件不可写、或重写后的内容未通过健全性检查的情况下，它依然会拒绝。而且它不会在 web 根目录里留备份文件——理由很实在：一份可读的 wp-config.php 副本等于泄露数据库凭据。
插件能力有明确边界——只管已安装插件的列表、启用、停用和删除，安装新插件被刻意排除在外。
两种连法
本地（stdio，推荐）——这也是它存在的理由。三条命令：
git clone https://github.com/justadityaraj/shim-mcp.git wp-content/plugins/shim-mcp
wp plugin activate shim-mcp
wp shim-mcp serve --user=admin
然后在客户端注册。Claude Code 为例：
claude mcp add shim -- wp shim-mcp serve --user=admin --path=/full/path/to/wordpress
远程（HTTP）——针对你不在机器前面的站点。装好插件后，到 工具 → Shim MCP 点生成，创建应用程序密码，把页面上给出的配置片段复制到 AI 客户端即可。走的是 Streamable HTTP 传输，符合 MCP 规范，每次调用都会做 capability 校验。后台给 Claude Code、Claude Desktop、Cursor 都准备了现成片段。
⚠️ 上手前必须知道的三件事
第一，环境要求不低：需要 WordPress 6.9 或更高（因为 Abilities API 是从 6.9 进的核心）、PHP 8.0 或更高。WP-CLI 只在用 stdio 传输时才需要。注意 README 上的徽章标的是 6.7，但正文明确要求是 6.9+，以正文为准。
第二，它还很早期：截至本文写作时 48 颗星、0 个 fork，社区验证很少。更关键的是——作者明确说明它已提交 WordPress.org 插件目录但仍在等待审核，尚未获批。所以目前只能用 git clone 或手动上传 zip 的方式安装，装不了就是还没上架，不是你操作错了。
第三，生产环境慎用。如果一定要用，请照作者的操作建议来：全程 HTTPS（应用程序密码是以 HTTP Basic 凭据发送的）；把应用程序密码签给一个角色权限刚好够用的用户，不要默认给管理员密码；客户端不用了就从「工具 → Shim MCP」吊销密码；并且始终记住——任何带写能力的 MCP 客户端，其活动范围等同于该角色的一个已登录用户，要审它做了什么。
为什么叫「Shim」
作者取这个名字是有用意的。在系统编程里，shim 指的是夹在两个接口之间的薄适配层，让双方不必修改就能协同工作。这个插件正是如此：WordPress 说 Abilities API，AI 客户端说 MCP，它负责翻译，别的什么都不做。
这个命名其实是一份范围承诺：它不是 AI 产品，不捆绑聊天机器人、内容生成器、积分系统，也不想变成你的工作流中枢，不回传任何数据。它是适配器，不是设备——而且作者说，等 WordPress 核心原生支持 Abilities API 的那天，这个插件会变小，而不是变大。
对站长意味着什么
如果你是一个常年开着终端和编辑器的开发者，想在本地 WordPress 上用 Claude Code 或 Cursor 干活——就像它们操作你代码库的其他部分那样——这个插件瞄准的就是你。
「不开端口、不传令牌」这一点，让本地开发的接入成本几乎归零：不需要配置应用密码，不需要 OAuth 流程，也不用在防火墙上开洞。对本地站点来说，attack surface 直接从「需要防护」变成了「不存在」。
但它现在还处于早期阶段，也没进插件目录。建议在本地开发环境先试，摸清楚权限边界和行为之后，再考虑是否用在正式站点上。
关注「AI 智习室」，每天一条看得懂的 AI 情报。
