网文AI管线自动巡检：如何判定异常是否需要人工介入

网文AI管线自动巡检：如何判定异常是否需要人工介入

上周维护 trae-novel 这个网文自动生成项目，遇到2026年8月的第7次自动巡检，有个细节挺有意思：上一次巡检标记的那个"章338生成失败缺口"，这次再查已经自己愈合了，而且整个管线没用人碰，2.4小时里又稳稳产出了7章。

做AI生成类项目的人大概都懂这种纠结：巡检一跑，告警一堆，到底哪个真得人去处理，哪个是系统自己就能恢复的瞬时波动？这次巡检的完整决策过程，正好能拆开看看。

我巡检的第一步永远是先把基线拿到手，再谈当前状态。这次我做了三件事：读上次的巡检记录，拿到基线——上次项目完成347章，标了一个章338生成失败的缺口；探活采集当前状态，后端健康检查返回 health=200，服务活着；拉全量数据，包括当前完成章节数、活跃任务状态、最近日志和失败章节列表。

比对下来核心指标的变化是：

指标	上次基线（09:12）	当前值（11:34）	变化
完成章节数	347	354	+7
失败章节数	1（章338）	0	自愈
后端健康状态	200	200	稳定
当前活跃任务	章338生成中	章355生成中（progress=70%）	持续推进

之前标的章338失败缺口确实自愈了：当前 failed=0、连续完成章节数 last_consecutive_completed=354、失败章节列表 failed_chapters 为空。从10:58到11:34的监控日志看，也没出现重启、告警级异常、pending任务重置这些情况，进一步坐实了管线稳定。这里有个早年的坑：老版本巡检逻辑会把历史失败的标记一直挂着，直到手动清除，后来改成每次巡检都全量拉失败列表，只标当前真实存在的异常，免得把"已经自愈的历史问题"当成现在的故障。

这次巡检一共收到3条异常标记，但最终我都判成"不需要人工介入"，靠的是三个维度的阈值：

故障连续性。11:26探活出现过1次瞬时失败，但我的规则是连续失败3次才触发重启告警，这一次顶多算网络抖动，跳过。

业务影响。质检模块标了章349、章353两个"关注级"问题，但只是内容有点小瑕疵，不算生成失败；而且后面的章354质检拿了97分（合格线80分），说明质量已经回到正常水平。这类只做记录，不告警。

进度停滞。当前活跃任务在生成章355，进度卡在70%超过30分钟，但章号已经从349推进到了355，说明任务在正常走，只是单章生成慢，不是卡点。

大部分AI生成类的异常都是瞬时的：网络抖一下、模型响应慢、单章内容质量小波动。只要不连续触发、不影响整体进度、不出现生成失败，都不值得人去插手。

回到这次巡检，我最深的体会是：巡检本质上是在做异常噪音过滤。系统大部分时候跑得挺稳，我们要做的不是逮住每个小波动就动手，而是把真正需要人处理的故障挑出来。章338那个自愈的缺口就是提醒——给系统一点自我恢复的时间，往往比盲目介入更高效。

---

做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。

这篇里提到的坑，都是真金白银踩出来的。
如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作
——可以在评论区说说你的场景，我看看能不能自动化掉。