CMS里的AI Chat、技能与MCP接入分别能做什么

CMS 里的 AI Chat、AI 技能和 MCP 接入分别能做什么？一句话分工：AI Chat 负责”在后台里对话并动手”，AI 技能（Skills）负责”把流程写成可复用的说明书”，MCP Server 负责”把后台能力开放给外部 AI 客户端调用”。三者不是三个独立产品，而是同一套工具面的三个入口；配错的常见后果是把入口当成能力，比如以为接入了 MCP 就自动会做 SEO 分析，实际上还需要技能与权限两层。

三层各自负责什么

AI Chat：对话入口背后的工具集

内置 AI Chat 智能对话配套一组 AI 工具，覆盖内容、SEO、运维、商务等域，可由智能体自主编排调用。实际使用时的差别在于”是否真的动手”：只能回答问题的入口价值有限，能直接落到建草稿、改分类、查统计这些动作上，才真正省下后台点击的时间。

适合作为优先验证点的是三类高频任务：批量建文与改状态、按栏目做内容规划、查站点健康与故障线索。这三类任务在后台手工做要跨多个页面，用对话入口串起来最直观。

技能（Skills）：把流程写成可复用的说明书

AI 技能系统提供可扩展的技能，覆盖内容规划、SEO 分析、批量操作、站点健康检查、故障排除、模板开发与 API 开发。它的价值不在”会说话”，而在把一次做对的方法固化下来：谁来做、按什么顺序、检查哪些点、失败怎么退回。

写技能时有两处约束。第一，技能正文里要写清调用的是哪个能力，而不是写一个具体接口路径，接口会变而能力相对稳定。第二，同一份技能要能在本地和线上环境都跑通，避免只在某台机器上成立的写法被反复引用。

MCP Server：意图目录与外部客户端接入

内置 MCP Server 的工具面基于意图目录统一收敛，支持 Bearer Token 鉴权与回合级操作审批，可被 Claude、Cursor 等外部 AI 客户端接入。这意味着后台能力可以在自己熟悉的客户端里调用，而不必在多个系统之间来回复制内容。

意图目录这一层的作用值得单独说：它把”能调什么”从散落的接口清单收敛成按业务域归类的意图，每个意图再对应到具体端点。这样做的好处是权限和暴露范围可以按域设置，需要收紧时改一处配置即可，不必逐个接口处理。

写操作的审批按回合组织：一轮对话里的多个写入会合并成一次确认，而不是每改一条就要点一次。这个设计针对的是批量场景——逐条确认会让审批本身成为负担，合并确认则保留了人在关键节点把关的位置。

权限边界：默认关闭与显式开启

MCP 接口按意图域设置暴露范围，备份、升级、多站点这类全站级操作所在的高危域默认关闭，需要显式开启才可调用。这里有一条容易误读的地方：能力可见不等于可调用，配置成只读的域即使出现在工具列表里，写入请求同样会被拦下。

配置顺序建议这样走：先只开放读取类意图跑通流程，确认外部客户端能正确取数；再按需开启内容写入，并在客户端侧确认审批提示真的会出现；高危域保持关闭，只有在明确要做整站操作时才临时开启，做完收回。

落地顺序与常见问题

先技能后接入：把内部流程写成技能并验证一次可复用，再接 MCP 让外部客户端调用，这样接入的是已经跑通的方法，而不是待验证的想法。

常见问题一：接了 MCP 却调不到某个能力？先看该意图域当前的暴露设置，高危域默认关闭是设计而非缺陷。

常见问题二：AI 会不会误删内容？写操作走回合级审批，且删除正式文档在系统里是移入回收站，可恢复；真正需要担心的是批量替换类操作，执行前应当先做备份。

常见问题三：技能和 MCP 要都上吗？只看后台用 AI Chat 就够用时，不必急着接外部客户端；当出现跨系统编排需求，或者要把固定流程交给外部客户端反复执行时，后两层的价值才显现。