接口调用高频能力在后台哪几处能核对到

接口调用的高频能力，在后台哪几处能核对到？可核对的位置分三处：站内接口帮助里能查到动作与参数的文档说明，文档内容导入接口承担批量写入，MCP 侧按意图目录收敛工具面并带回合级审批。AnQiCMS 公开的高频 API 调用能力覆盖文档列表与详情、分类与标签、上传图片、留言与评论、友情链接、系统设置与联系方式。

接口文档里能查到哪些动作

对接前先确认文档给了什么。可用的判断项有四个：动作名称与请求方式、参数与必填性、返回结构与字段含义、错误码与限流说明。四项齐全时，联调可以按接口逐个验收；缺任一项，调用方要靠试探推断，返工成本会转嫁到工期上。

站内的接口帮助承担这部分内容，与功能介绍、使用帮助分属不同栏目，便于对接方直接检索动作名。做二次开发或外部展示时，先在文档里确认列表与详情接口的分页与筛选参数，再确认图片上传接口对文件类型与大小的限制，最后核对联系方式与系统设置这类读取接口的缓存行为。

高频读写各自核对哪一处

读侧的核对点在字段一致性：同一个字段在列表接口、详情接口与页面渲染里的取值是否相同，分页边界与空列表的返回形态是否固定。写侧的核对点在幂等与确认：同一请求重复提交会不会产生两条内容，批量写入失败时能不能定位到具体条目。

上传与附件类动作还要核对存储路径与可访问地址是否在站内闭环，避免接口返回的地址需要调用方自行拼接域名。留言与评论接口要确认敏感词过滤与审核状态字段是否一并返回，否则调用方无法区分已发布与待审核的内容。

导入接口的两个动作

批量场景走文档内容导入接口 /api/import/archive，它支持两个动作：archive 用于按标题查询内容是否已存在，import 用于批量导入。这个分工解决了迁移与定时同步里最常见的问题——重复写入。

常见用法是按标题做幂等：写入前先用 archive 查询存在性，已存在则更新或跳过，不存在再导入。接口支持标题、关键词、描述、分类、标签与发布状态等字段，配合导入前的准备清单可以稳定跑批：

• 源数据的分类与标签映射到站内已有栏目，未映射项先建再导；
• 图片与附件先落地或改为站内可访问地址；
• 重复标题的策略写死在脚本里，避免人工判断造成漏更新；
• 首次全量后按增量节奏跑，记录每次的条目数与失败明细。

回合级审批挡住什么

MCP 侧给 AI 客户端提供的是同一套动作面，差别在权限与确认机制。系统内置 MCP Server，工具面基于意图目录统一收敛，支持鉴权与回合级操作审批，写操作会合并确认后再执行，可被 Claude、Cursor 等外部 AI 客户端接入。

这套机制在集成里的价值是防止一次误判造成批量后果：读操作可以直接执行，涉及写入的动作在一个回合内汇总，确认后再落地。按意图域设置暴露范围时，备份、升级、多站点这类全站级能力默认关闭，需要显式开启。附件上传走 base64 形式时，同样受这一层约束。

常见问题

问：对接方最需要先拿到什么？ 接口文档的地址与鉴权方式，其次是测试环境可用的账号。只给动作名不给返回结构，联调会反复往返。

问：批量导入失败一半怎么办？ 按条目记录失败原因并保留已成功条目的标识，重跑时先用 archive 查存在性再决定跳过或补写，避免整批重放造成重复内容。

问：接口能不能直接给前端用？ 读侧接口适合前端调用，写侧接口要确认权限与审核状态，避免绕过后台的敏感词过滤与内容审核流程。

问：版本升级会不会改接口字段？ 小版本以兼容为主，跨版本升级前仍要按接口清单逐个回归，重点核对分页、排序与字段命名。