问题不在插件本身
插件本身已经在做有用的工作。薄弱点是围绕它们的使用路径。
- 应该先安装哪个插件？
- 哪些 add-on 是可选的？
- 哪个页面有最新的发布信息？
- 核心插件负责什么，哪些应该放在 add-on 里？
- 怎样判断这个生态还在维护？
对想在真实 WordPress 站点上尝试 MCP 的人来说，这些都不是小问题。如果设置路径不清楚，真正有用的部分就开始得太晚。
我们改了什么
- 我们清理了 Devenia 的插件页面，让核心插件和 add-on 用一致的方式解释同一个生态。
- 我们更新了过期的数量、发布说明和链接，避免旧页面听起来比主插件页面还新。
- 我们把 MCP Expose Abilities 页面重建为可维护的 Gutenberg 内容。
- 我们把安装路径讲得更清楚：先 Abilities API 和 MCP Adapter，再 MCP Expose Abilities，然后只安装站点真正需要的 add-on。
- 我们按 add-on 所控制的 WordPress 工作类型重新分组，让生态更容易扫读。
这种整理不是外观修饰。它会改变项目给人的感觉：是容易进入的系统，还是一堆强大但没有入口的工具。
当前生态的样子
当前 MCP Expose Abilities 页面记录了核心插件中的 67 个 WordPress 原生能力。整个维护中的栈现在包含 18 个已发布 add-on，以及超过 450 个已记录能力。
这并不表示每个站点都应该全部安装。重点正好相反。GeneratePress 站点不需要 Elementor 能力。没有 Brevo 的站点不需要 Brevo 能力。更小的安装面更容易理解，也更容易保持安全。
WordPress 核心工作：
编辑器和构建器工作：
运营工作：
这就是我们希望别人看到的更清楚的信息：从核心开始，只添加与站点匹配的部分，并让每个开放操作都有名称、可检查。
为什么这不只是技术细节
好的自动化不是从最长的功能列表开始。它从信任开始：你能否理解助手被允许做什么、这个能力为什么存在，以及正确的 WordPress 权限是否仍然适用？
这就是 add-on 模型重要的原因。它让站点开放一组聚焦的能力，而不是把所有 WordPress 操作都当成一扇全开或全关的大门。
对站点所有者或开发者来说，这意味着第一次有用测试之前少一些猜测。对 agent 工作流来说，这意味着工具更清楚、权限更干净、意外绕路更少。
更好的第一条路径
如果你现在要尝试这个生态，实用路径是：
1
2
3
4
5
这样，助手可以获得有用的 WordPress 访问能力，而不会让设置过程比它要节省的工作还复杂。
接下来做什么
我们会继续收紧插件周围的部分：更清楚的 onboarding、更好的发布说明、更强的页面链接，以及减少 GitHub、WordPress 和 Devenia 页面之间的漂移。
这不只是文档工作。它是为自动化栈做产品设计。强大的工具只有在人们知道从哪里开始、哪些操作安全时，才会更有用。
如果你想看当前概览，可以从 MCP Expose Abilities 开始。