AI 技能里的故障排除和站点健康检查，先跑哪个

后台的 AI 技能里，故障排除和站点健康检查该先跑哪个——没有异常时先跑站点健康检查建立基线，出现异常时再走故障排除。这两个技能常被当成一回事，其实输入输出都不同：健康检查面向全站做一次巡检，读的是配置与状态，产出是一份待修清单；故障排除针对一个已经发生的问题，读的是日志与最近变更，产出是一段定位结论。顺序颠倒时最常见的结果是——健康检查跑完拿到一堆历史遗留项，但没人知道其中哪一项和眼下的故障有关。

两类技能解决的问题不同

技能系统覆盖内容规划、SEO 分析、批量操作、站点健康检查、故障排除、模板开发与 API 开发。健康检查属于「主动巡检」，它不假定站点有问题，检查的是栏目结构、发布配置、备份是否可用、静态文件与附件是否完整、搜索相关开关是否设好、权限分组是否过宽。故障排除属于「被动定位」，它从一个现象出发：页面打不开、发布后不生效、接口调用报错、样式丢失，然后回看最近的改动与日志。

先建立基线再处理异常

基线的价值在于比较。跑过一次健康检查，你知道站点在正常状态下有哪些待办、哪些配置一直开着；下一次异常时，只要看当前现象与基线的差项，就能把范围收到最近改过的部分。没有基线的站点，故障排除只能靠猜，常见的做法是把所有可能都试一遍，耗时且容易在过程中改出第二个问题。

节奏上建议：新站上线后先跑一次健康检查，把结果按「必须修」「可以观察」两类分开；之后按栏目更新量决定周期，内容密集的时段缩短间隔。故障排除则不设周期，出现现象再跑。

巡检结果怎么转成待办

健康检查给出的清单要能落到动作上，否则只是一次报告。转成待办的方法是为每一项指定负责人与判断标准，例如：备份项写成「恢复一次并记录耗时」，权限项写成「列出可发布用户组并核对最近改动」，配置项写成「改完在前台验证」。写不出来的一律退回，重新问一句这项检查到底在防什么。

批量处理待办时借助批量操作类技能，把同类改动合并执行，但要逐类核对而不是整批放行。SEO 与内容类待办按栏目优先级排，先处理影响可读与可索引的部分，再处理锦上添花的配置。

写操作为什么要回合级确认

后台能力开放给 AI 客户端调用时，走的是 MCP 接口，工具面按意图目录收敛。收敛的意义在于调用范围可核对：能做什么、不能做什么，有一份清楚的目录，而不是散落的接口。高危域（备份、升级、多站点管理这类全站级操作）默认关闭，需要时显式开启。

在此基础上，写操作要按回合级审批合并确认：把这一轮里 AI 打算执行的多个改动汇总成一次确认，人看的是这一批合起来会造成什么结果，而不是逐条点同意。内容批量改栏目、批量替换关键词这类动作，一旦散开确认，很容易在十几个「同意」之后才发现方向错了。

内置的 AI Chat 智能对话在这里承担的是查询与解释角色：问它当前状态、让它解释某项检查的含义、把日志片段拿给它分析。真正改动站点内容的动作仍要经过审批，智能体可以编排调用，但决定权留在人这一侧，这也是把内容、SEO、运维、商务各域工具集拆开管理的原因。

常见问题

健康检查会不会漏掉正在发生的问题？ 会。它按预设项巡检，不负责发现未知现象。有明确异常时先走故障排除，之后把暴露出来的检查项补进基线。

多久跑一次健康检查合适？ 以变更频率为准。栏目与权限频繁调整的时段缩短周期，稳定运行期按季度也可以，前提是每次改动都留了记录。

能不能让 AI 直接执行修复？ 可以执行读与低风险写操作，全站级操作要显式开启并按回合确认。默认状态保持关闭，风险由配置决定而不是由模型判断。

待办清单越来越多怎么办？ 定期合并同类项，把「必须修」控制在可执行数量内，其余转成配置调整。清单长度本身不是目标，能被逐项关闭才有意义。