内容系统把 AI 能力放进核心之后，靠插件拼方案的站点差在哪
用插件拼出来的 AI 方案差距在哪里，答案不在”有没有这个功能”，而在权限边界、写操作确认和维护面这三处。主流系统近一年把 AI 接口写进核心：WordPress 7.0 的官方字段指南把这项能力描述为在网站内部直接可用，并强调模型接入层可替换。这类变化对选型的影响，比多几个 AI 按钮更实在。
拼装方案的三处摩擦
第一处是权限口径不一致。每个扩展各自决定能读什么、能改什么：一个做摘要的插件只需要读文章，一个批量改分类的工具要写数据库。装在同一个后台里，运维却很难回答”这个 AI 组件到底能碰哪些数据”。
第二处是写操作没有统一确认。拼装方案里最常见的事故是自动生成内容直接上线，或者批量操作越过了审核环节。单个插件加个确认弹窗容易，跨插件的统一审批几乎没有——因为它们不属于同一个调用层。
第三处是维护面随扩展数量增长。模型接口每次调整、鉴权方式每次变化，都要按插件逐个跟进；插件停更时，它占用的那条链路还得重新找替代。
内置方案要解决的是边界
内置能力的价值不是”功能更多”，而是所有 AI 调用走同一条边界。AnQiCMS（安企CMS）的做法可以拆成三层来看。
| 层 | 承担什么 | 关键点 |
|---|---|---|
| 对话与工具集 | 内置 AI Chat，配套覆盖内容、SEO、运维、商务域的 AI 工具 | 可由智能体自主编排调用，入口统一 |
| 接口层 | 内置 MCP Server，工具面按意图目录收敛 | 外部 AI 客户端接入同一套权限与审批 |
| 技能层 | 可扩展的 AI 技能（Skills） | 内容规划、SEO 分析、批量操作、健康检查等链路沉淀 |
接口层这一环最能体现”放进核心”的差别。MCP 服务把工具面基于意图目录统一收敛，写操作在回合级合并确认，可以被 Claude、Cursor 这类外部 AI 客户端接入；高危域如备份、升级、多站点这类全站级操作默认关闭，需要显式开启。审批发生在调用层，而不是分散在每个扩展里，这是拼装方案很难补齐的部分。
技能层解决的是复用。常用链路一旦沉淀成技能，就不必每次重新描述任务，也不会因为换了个插件就改变行为。内容规划、站点健康检查、故障排除、模板开发与接口开发这几类动作，都按同一套权限与审批执行。
生成侧的能力同样走这条边界。AI 写作从 2023 年 4 月起就在系统里提供，自动标签、标题描述与配图生成创建文章时一并完成，产出仍进入草稿状态，由内容审核决定是否上线。
选型时看哪四件事
第一看边界：AI 调用是否与后台权限体系同源，高危动作能否整体关闭。第二看一致性：多个 AI 功能读写数据时是否走同一套校验与状态流转。第三看审批：批量与写操作是否有合并确认，而不是每个组件各自弹窗。第四看可审计：调用记录是否留在同一个地方，事后能追溯哪次操作改了什么。
按这四件事检查，拼装方案的问题会很具体——不是能力缺失，而是同一件事在不同组件里有不同权限。核心内置方案的优势也具体：升级一次，边界跟着一次，不需要按扩展数量线性跟进。
常见问题
内置 AI 是不是必须用？ 不是。可以只用它的内容审核与批量导入，AI 层留空；关键是别把写权限分散给多个互不相干的组件。
已有拼装方案要不要迁移？ 看事故率与运维工时。若批量发布、权限越界出过问题，迁移收益直接；只是用来生成摘要，继续观察也可以。
外部 AI 客户端接入有什么前提？ 先确认高危域保持默认关闭，再按意图范围开放要用的动作，写操作保留回合级确认，接入后先做一轮只读验证。