上周 trae-novel 的自动化巡检任务触发了一次虚警：日志里出现了「重启」关键词，系统差点判定后端异常、触发重启流程。好在动手前先做了健康检查，后面又靠全量日志扫描和标记分类才避开误操作。这次经历把 AI 辅助运维里几个容易忽略的坑暴露出来了，也让我攒下一套能反复用的排查思路。

前置检查优先：先确认后端活着，再排查

这次巡检的第一优先级是跑后端健康检查，返回的 health=200 直接确认服务当前可用，等于先把最基础的可用性问题排除掉，后面所有排查都是在「后端活着」的前提下做的。

之前踩过没做前置检查的坑：有一次巡检直接去拉生成状态和日志，结果后端其实早宕了，查了半天都是历史残留的无效数据，白搭近 10 分钟。这次先跑健康检查的决策，直接把排查范围缩窄，不碰无效数据。

踩坑1：只看日志尾部，差点漏掉关键上下文

一开始查日志习惯性只看最后几十行，只看到最近的「提示-B」和「质检-关注-C」标记，一度以为没异常。后来改成全量扫描，才发现早前有多次历史重启、告警标记——只不过发生在更早的时间窗口，和当前问题无关。

更麻烦的是关键词歧义：全量扫描匹配「重启」时，第一次结果里混了大量「暂不重启」的文本——这是系统自动跳过重启流程的提示标记，本身是正常逻辑，但因为带了「重启」两个字，差点被误判成真实异常。这次踩坑让我认准一件事：日志排查不能只看最后几行，关键词匹配也不能只靠字面重合，必须结合上下文语义判断。

踩坑2：没做标记分类，历史数据干扰判断

找到所有「重启」相关匹配后，第二步做了分类：把所有日志标记分成三类——第一类是「提示-*」类的系统自动处理标记，比如「暂不重启」「提示-B」，都是已经正确执行、不用人工介入的流程；第二类是告警、重启、重置 pending 这类真实异常标记；第三类是质检关注类、需要跟进业务的标记。

分类完立刻拉时间窗口：最近 3 小时作为活跃排查窗口，之外的全归历史数据。最终确认：活跃窗口里只有系统提示和业务关注标记，没有真实异常标记，早前的异常标记都是更早就处理完的历史告警。

如果没做标记分类和时间窗口过滤，很可能把历史告警当当前问题，触发不该有的重启流程，影响正在跑的任务。

这次留下的 4 条经验

排查虽然最终没造成实际影响，但还是把 AI 辅助运维里几个共通问题暴露出来了，我整理了 4 条能复用的方法：

1. 前置检查优先：任何排查先做基础可用性检查（健康检查、接口连通性），确认基础环境正常再往下，别在无效数据上耗时间。
2. 全量扫描优于局部查看：日志别只看最后几行，尤其要查历史异常时，必须全量扫描才能拿到完整上下文，不漏关键信息。
3. 标记分类 + 时间窗口过滤：提前理清日志里的标记规则，不同类型做分类，再按时间窗口过滤历史数据，能大幅降低误判概率。
4. 关键词匹配要结合语义：别只靠字面关键词判异常，遇到歧义匹配（比如「暂不重启」匹配到「重启」）一定要结合上下文确认，避免误判。