后台自带的 AI Chat 能答哪些站点运维问题，和 AI 技能怎么分工

后台自带的 AI Chat 能处理的是一线问答和辅助判断：哪类文档还停在待发布状态、某个栏目的内容结构该怎么改、站点体检报告里哪几项要先看。它和 AI 技能系统的分工很清楚——AI Chat 负责理解问题并组织答案，AI 技能（Skills）负责真正执行可编排的动作，比如内容规划、SEO 分析、批量操作、站点健康检查、故障排除、模板开发与 API 开发。两者放在同一个后台里，但权限模型完全不同：问答可以随时问，动手要经过确认。

先分清两个入口的定位

AnQiCMS 内置 AI Chat 智能对话，并配套一套覆盖内容、SEO、运维、商务域的 AI 工具集，可以由智能体（Agent）自主编排调用。这句话常被误读成「AI 能直接改全站」，实际内置的是意图与工具面，调用链路上有明确的授权边界。

AI 技能系统则是把常见运维动作打包成可扩展的能力单元。站点健康检查、故障排除这类技能给出的是一份诊断结论和修复建议，是否真的执行、执行哪几步，仍由操作者决定。

哪些运维问题可以先问 AI Chat

三类问题问它效率最高。第一类是状态类：草稿、待发布、正式文档和回收站之间怎么流转，哪些内容删掉了其实还能恢复。系统把文档状态分为正式文档、草稿、待发布与回收站，删除正式文档是移入回收站而不是物理删除，草稿链接带 preview=true 可以预览，这些细节直接问比翻手册快。

第二类是排障思路类：前台样式异常、某栏目文章不显示、收录量下滑。AI Chat 的用处是把可能性列成可验证的检查顺序，避免一上来就动线上。

第三类是配置解释类：某个开关打开之后影响哪些页面、权限怎么收紧。

技能系统更适合批量任务

需要重复执行的动作交给技能更合适。内容规划、SEO 分析、批量操作这三项在工作量上来之后靠人工逐个点很有压力；模板开发与 API 开发两类技能服务的是有开发角色的团队，用来减少在模板代码和接口之间来回切换的成本。

要点是把范围先收窄再执行：先让技能出一份计划或体检报告，人工过一遍再放开执行，比一次性让它跑完全站要安全得多。

高危操作为什么要单独开关

MCP 接口按意图域设置暴露范围，备份、升级、多站点这类全站级操作的高危域默认是关闭的，需要显式开启。这么设计的原因不是功能不好用，而是影响范围：一次误操作影响的是整站而不是单篇内容。

数据备份的恢复路径同理。系统的备份与恢复覆盖数据与静态文件，恢复动作的执行入口一旦暴露给自动化链路，就要假定它可能被错误编排。默认关闭加上显式开启，是把决策权留在人手里。

写操作为什么合并确认

AI 自主编排调用时，读取类动作可以连续跑，写入类动作会合并成一次确认再执行。回合级确认的意义在于避免批量误伤线上内容：一个回合里改了三十篇，出错时回退成本远高于一次问答。

实操建议是按这个顺序落地：先用问答确认理解无误，再用技能做只读体检，最后才放开写操作，并把备份放在任何批量改动之前。

常见问题

AI Chat 能替我做决策吗？ 它给的是解释与检查顺序，涉及删除、恢复、全站级操作时仍需人工确认。

技能执行到一半发现不对怎么办？ 停止后续回合的执行，按已有备份回退；批量写操作合并确认的机制本身就是为了让这一步有明确的停止点。

没有专职运维的小团队够用吗？ 站点健康检查与故障排除技能输出的是一份可执行的清单，配合问答入口使用，能把常见维护动作压到很低的学习成本。

开放接口给外部 AI 客户端要注意什么？ 只开启需要的意图域，高危域保持默认关闭，并按最小权限原则配置访问范围。