WordPress 开发社区抵制：将 AI 知识库功能纳入核心
WordPress 近期提出一项提案，计划将"Knowledge"自定义文章类型（Custom Post Type，下称 CPT）直接合并到 WordPress 核心中。该功能目前已在 Gutenberg 插件中以实验性功能存在，定位为网站指南与知识的集中存储库，供编辑、贡献者以及 AI 代理和工具调用。提案一出便遭到开发者社区的广泛质疑，普遍认为这一功能与用户实际需求脱节。
什么是自定义文章类型
当前 WordPress 内置的文章类型仅有两种：Posts（文章）和 Pages（页面）。通过安装 CPT 插件，站点所有者可以扩展出针对特定用途的新文章类型。例如 WooCommerce 插件使用名为"product"的自定义文章类型来管理商品。
Knowledge CPT 提案内容
Knowledge CPT 于 2026 年 2 月提出，一个月后以实验性功能集成到 Gutenberg 插件中，支持以下知识类型：
Site — 站点目标、定位、目标受众与行业背景，是任何工具或贡献者都可引用的基础信息。 Copy — 语调、文风、品牌个性与词汇偏好，相当于内置于 WordPress 的编辑风格指南。 Images — 偏好的图片风格、色彩、情绪与主题，包括应包含和应避免的内容。 Blocks — 各内容块类型的规则，例如规定段落块使用短句、图片块必须包含描述性 alt 文本。 Additional — 其他不便归类的内容，如无障碍要求、链接规范、格式约定等。
功能定位模糊引发争议
提案声称该功能的受益者涵盖人类用户、AI 代理、工具和插件等所有参与者。然而 GitHub 仓库的说明却明确将其定位为纯 AI 用途：
“Guidelines CPT 存储站点级编辑规则——品牌调性、文案标准、图片指南。这是站点所需的一种指令内容，但并非唯一类型。随着 AI 工具与 WordPress 的深度集成，站点需要存储多种持久化、结构化知识来指导代理与站点的交互。”
整篇技术文档中未提及任何面向人类用户的实用性说明。提案描述与实际技术规范之间存在明显落差，引发社区质疑：核心团队是否真正清楚这一功能的服务对象与使用场景？
开发者列举六大反对理由
在 Dynamic WordPress 闭门 Facebook 小组中，相关讨论共收获 29 条评论，几乎一边倒反对将该功能合并到核心。反对理由集中于以下几点：
- 应作为插件而非核心功能：此功能完全可以通过插件实现，无需写入核心；
- 核心已过于臃肿：增加的功能只会进一步加重 WordPress 的体积负担；
- 优先级排序失当：原生多语言支持被认为是更紧迫的缺失功能，且社区对此已有共识；
- 提案论证不充分：许多开发者怀疑该提案是否经过充分评估；
- 实为 AI 专属功能：多项证据表明该功能本质上并非面向人类用户；
- 利益分配不均：有声音指出该功能对 WordPress.com 上的企业用户价值更大，对普通 WordPress 用户益处有限。
值得注意的是，抵制声音并未止步于社交媒体。WordPress 官方公告下的评论区同样充满质疑。开发者 mrwweb 指出：
“虽然提案声称该功能同时服务于’作者侧和代理侧’应用，但给人的感觉是 AI/LLM 在主导这一功能的构想。此外，’大多数站点已有内容标准’这一基本假设并不准确。需求确实存在，但仅凭这一点似乎不足以支撑一个新的核心功能……我认为该功能有一定潜力，但更需要从更广泛的视角审视，尤其是人类用户的完整使用场景。”
Namith Jawahar 评论道：
“这看起来是不必要的越权。更好的做法是将决定权交给开发者，让他们为各自站点做出选择，而非强制向所有人推送一个文章类型。”
Aaron Jorbin 的态度相对温和，但也指出功能尚不完整：
“就现状而言，这显得不够完善。但它确实奠定了基础，如果利用 7.1 版本发布前剩余的时间，可以成为一个不错的功能。”
背景：WordPress 7.x 已非首次争议
这已是 WordPress 7.x 版本的第二次重大功能争议。此前 7.0 版本中的实时协作（Real-Time Collaboration，RTC）功能——Phase 3 协作阶段的核心特性——同样遭到开发者对必要性的质疑。
