网站出了故障，什么时候该让 AI 技能先查，什么时候该人工看日志

内容管理系统里的 AI 技能能参与故障排除到什么程度，和人工查日志怎么分工？可以这样切：AI 技能负责把分散的检查项串成线索——站点健康状态、后台配置、近期变更、报错集中在哪个模块；人工负责判断影响面并批准不可逆动作，比如删改数据、恢复备份、改动全站配置。分界线的价值在于既不必事事手工翻日志，也不会让自动程序替你做决定。

后台里的 AI 技能覆盖哪些域

AnQiCMS 的 AI 技能系统（Skills）覆盖内容规划、SEO 分析、批量操作、站点健康检查、故障排除、模板开发与 API 开发。故障相关的两类最实用：站点健康检查给出当前状态的横切面，故障排除把报错与配置项对上。技能不是黑箱助手，它调用的是后台已有的能力面，因此结果可复核。

配套的 AI Chat 智能对话让这套工具可以被自然语言驱动，也可由 AI Agent 自主编排调用，把「先查什么、再查什么」这条排查顺序固定下来。

MCP 接入后，审批拦在哪一步

系统内置 MCP Server，工具面按意图目录统一收敛，鉴权走令牌，写操作按回合级审批合并确认。这决定了 AI 参与运维的安全边界：读取类动作可以直接执行，改动类动作要成批确认后再落地。意图域还有一层 DefaultOff 规则——备份、升级、多站点这类全站级的高危域默认关闭，需要人工显式开启。也就是说，即使 AI 判断需要执行恢复动作，它也必须先遇到一道人为开关。

AI 先查适合哪些故障

• 表现明确但原因分散：页面变慢、某个栏目 500、登录失败率上升，需要同时看配置、日志与近期改动；
• 重复性巡检：每天确认备份任务是否成功、站点地图能否访问、待发布内容是否卡住；
• 变更前后比对：模板或配置改动后，让技能把健康检查项跑一遍，人工只看差异。

这些场景的共同点是不需要立刻改数据，AI 的输出用于缩小范围。

必须人工接管的三类场景

一是数据已经可能被破坏：涉及删除、批量覆盖、回收站清空、备份恢复的动作，必须由人确认对象与时间范围；二是安全事件：出现异常登录、文件被改动、可疑脚本注入时，先隔离与取证，不能让自动程序在证据上继续写；三是判定为不可逆的对外影响：全站配置变更、域名与跳转规则调整，出错面是所有访客。

恢复动作前的兜底顺序

排障中最容易犯的错误是边查边改。稳妥顺序是：先确认最近一次备份可用，再改配置，改完复现一次故障路径验证。备份要连同静态文件一起留，恢复要真的演练过，否则「有备份」只是日志里的一行成功记录。

常见问题

AI 技能能替我做夜间值守吗？ 可以承担巡检与初步定位，把异常汇总给人；但涉及改动仍需审批，值守的责任仍在人身上。

日志太长，AI 看不完怎么办？ 让技能先按时间窗与模块聚合，给出可疑片段和对应配置项，再由人工核对原始日志。定位靠聚合，结论靠原文。

开启高危域有什么前提？ 先确认备份可恢复、操作有审批记录、且明确哪些意图域需要暴露。默认关闭是防止误触，不是功能缺失。