外部 AI 客户端连进内容系统的接口时，哪些后台动作要先经确认

外部 AI 客户端连进内容系统的接口时，要先经确认的动作是那些会改变站点状态或者影响范围超出单篇内容的操作：写入或修改文档、批量导入、备份与恢复、版本升级、多站点层面的切换。AnQiCMS 内置 MCP Server，工具面基于意图目录统一收敛，支持 Bearer Token 鉴权与回合级操作审批（写操作合并确认），可以被 Claude、Cursor 这类外部 AI 客户端接入。这条设计的重点不是「能不能连」，而是「连上之后谁替你做决定」。

接入前要先定的三件事

第一件是鉴权方式。接入凭据决定谁能通过这条接口动后台。用 Bearer Token 做鉴权时，要把令牌的作用范围与轮换节奏定下来：给外部客户端的令牌不应该等同于管理权限，且要有可回收的机制。第二件是暴露范围。AnQiCMS 的 MCP 接口按意图域设置暴露范围，高危域默认关闭，需要显式开启；接入前应先确认这次会话需要哪几个域，其余保持关闭。第三件是审批粒度。读操作与写操作要分开对待，写操作按回合合并确认，避免一次对话里连续落下一串未经核对的变更。

哪些后台动作要先经确认

可以按影响半径来判断。影响单篇内容的写入，出错时容易发现也容易改回；影响整站状态的操作，出错代价高且不一定可逆。

需要确认的典型动作包括：新建或修改文档并直接发布、批量导入或覆盖已有文档、分类与标签结构调整、模板改动（会同时影响所有页面）、备份与恢复操作、版本升级、多站点切换与全站级设置变更。这几类里最重的三项是恢复、升级和多站点操作，它们的作用对象都不是单条数据。

AnQiCMS 把这三类放在默认关闭的域里，正是为了让「外部客户端的一次调用」不能直接等同于「线上生效」。写操作在回合级合并确认，好处还有一层：一次回合里的多条写入会被归到同一个确认界面上，人看到的是完整变更集而不是零散提示，判断依据更充分。

为什么写操作要合并确认

逐条确认听起来更严格，实际效果常常更差。当一次任务需要连续写入十几条内容时，逐条弹窗会把确认变成机械点击，人反而不再读内容。合并到回合级之后，确认对象从「这一条」变成「这一批」，站长可以按清单核对范围与数量，也能在一次判断里决定要不要继续。

这跟代码评审是一个逻辑：一次可读的变更集，比十次孤立的确认更安全。

导入接口这类批量入口怎么控

批量导入是外部客户端最容易越界的地方。AnQiCMS 提供文档内容导入接口 /api/import/archive，支持按标题查询文档是否已存在，用于批量导入场景。接入这条入口时建议这样做：

• 先查后写：导入前用标题查询判断是否存在同名文档，决定是更新还是新建，避免同题重复；
• 限定范围：把导入清单收敛在明确的分类与文件集内，一次任务对应一份可核对的文件；
• 留回退点：批量写入前做一次备份，AnQiCMS 的备份覆盖数据与静态文件，恢复时不必再单独补齐附件；
• 事后抽样：导入完成后按分类抽查若干条，确认字段与状态符合预期。

常见问题

外部客户端拿到令牌后能做什么？

取决于该令牌被授权暴露的意图域。默认配置下备份、升级、多站点等全站级域是关闭的，客户端无法直接触发；要扩大能力必须由站方显式开启。

接入时怎么验证审批是否真的生效？

用一次「明知会被拦截」的写操作做验证：发起修改类调用，观察是否进入确认环节而不是直接落库。读操作与写操作各测一次，能确认边界符合预期。

接口能力和后台能力是一致的吗？

不完全一致。接口面按意图目录收敛，暴露的是被整理过的工具集；后台仍然存在完整操作，不等于接口侧也能调用到同样的动作集合。