很多后台系统都有一类重复任务：
定时打开页面，检查状态，截图，记录结果，发现异常再通知人处理。
刚开始，这件事很简单。
页面少、人员少、检查对象少，靠人工打开页面就能跑起来。
但当检查对象变多以后，问题会变得很明显：
每天都有人查，但异常还是会漏。 截图很多，但复盘时找不到关键证据。 表格每天都更新，但没人知道状态是从什么时候开始变的。 自动化任务失败后，只知道失败，不知道停在哪一步。
这类问题通常不是“人不够认真”，而是巡检任务没有被设计成工程化流程。
如果把巡检理解成“打开页面看一眼”，它一定会越来越累。
如果把巡检拆成状态机、证据链、任务边界和人工复核，它才有机会变成可复用工作流。
一、巡检不是动作，而是状态流转
很多低效巡检都有一个共同问题：
只记录结果，不记录状态流转。
比如表格里只有：
正常
异常
已处理
这三个状态看起来够用，实际很难复盘。
因为“异常”太粗了。
它没有说明：
- 是页面加载异常；
- 是任务中断；
- 是数据状态变化；
- 是需要人工确认；
- 是已经有人接手；
- 还是只是一次临时波动。
更合理的方式，是先把巡检抽象成状态机。
待检查 -> 检查中 -> 正常关闭
-> 观察中 -> 待复核 -> 已处理
-> 任务中断 -> 保留现场 -> 人工介入
这样一来，巡检就不是“看过没有”，而是“当前对象处在哪个状态”。
状态清楚以后，后面的日志、截图、通知、复核才有意义。
二、先定义巡检对象，不要直接写脚本
很多团队做自动化巡检时，会直接从脚本开始：
打开页面。 等待加载。 截图。 判断文本。 写入结果。
这当然能跑，但很容易变成一次性脚本。
更稳的做法，是先定义巡检对象。
一个巡检对象至少包括：
| 对象 | 说明 |
|---|---|
| target_id | 被检查对象的唯一标识 |
| target_type | 页面、任务、后台模块、数据看板等 |
| entry_url | 入口地址 |
| owner | 负责人 |
| check_policy | 检查策略 |
| last_status | 上一次状态 |
| current_status | 当前状态 |
| evidence | 证据集合 |
| next_action | 下一步动作 |
这样做的好处是，脚本不再只是执行动作，而是在更新一个对象的状态。
后面无论是人工检查、脚本巡检，还是规则判断，都围绕同一个对象进行。
三、一次有效巡检要留下证据链
巡检最容易出问题的地方，是证据不完整。
只有一句“异常了”，不够。 只有截图，也不够。 只有日志，但没有页面位置，也不够。
一次有效巡检，至少应该留下这些证据：
| 证据 | 用途 |
|---|---|
| 当前 URL | 说明任务停在哪个页面 |
| 截图 | 保留现场 |
| 时间 | 判断异常出现时间 |
| 执行人或执行器 | 区分人工和自动化 |
| 步骤名 | 判断任务中断位置 |
| 状态变化 | 对比上一次结果 |
| 异常备注 | 给人工复核上下文 |
| 下一步动作 | 避免重复处理 |
可以用一个简单结构记录：
{
"target_id": "dashboard_001",
"run_id": "run_20260701_001",
"step": "capture_status",
"current_url": "https://example.com/dashboard",
"previous_status": "normal",
"current_status": "warning",
"diff": "页面出现新的提示信息",
"screenshot": "/evidence/20260701/dashboard_001.png",
"next_action": "manual_review"
}
这段记录的重点不是 JSON 格式，而是把“状态、现场、步骤、动作”放在一起。
如果后面要复盘，至少不用从群消息和截图文件夹里重新拼现场。
四、自动化适合采集，不适合替代所有判断
后台巡检很容易被误解成“能不能全自动”。
但工程上更稳的拆法是三层：
第一层：自动采集。
这层适合脚本处理。
例如：
- 打开页面；
- 等待加载；
- 保存当前 URL；
- 截图；
- 记录页面标题；
- 抽取基础状态文本；
- 写入日志。
第二层：规则分流。
这层适合用固定规则处理。
例如：
- 状态无变化，自动关闭；
- 首次异常，进入观察；
- 连续异常，进入人工复核；
- 页面无法加载，保留现场；
- 任务中断，记录步骤名；
- 多次失败，暂停后续自动任务。
第三层：人工复核。
这层不建议完全自动化。
例如：
- 判断异常是否影响后续任务；
- 判断是否需要暂停流程；
- 判断是否合并多个相似异常；
- 判断是否需要调整检查策略；
- 判断是否需要通知负责人。
也就是说：
脚本负责采集。 规则负责分流。 人负责判断。
这比“全部人工”更省力，也比“全部自动化”更稳。
五、状态差异比当前状态更重要
很多巡检只关心当前状态：
现在是不是正常？
但真正能减少重复劳动的是另一个问题：
这次和上次相比发生了什么？
例如：
normal -> normal：只记录，不打扰人
normal -> warning：进入观察
warning -> warning：累计次数
warning -> error：升级复核
error -> normal：记录恢复
这就是状态差异。
如果没有差异记录，系统每天都会重复告诉你“我看过了”。
但你真正需要知道的是：
- 哪些对象状态变化了；
- 哪些对象连续异常；
- 哪些异常已经恢复；
- 哪些异常需要人处理；
- 哪些只是重复噪音。
可以把状态变化简单建模成：
previous_status + current_status + count + last_updated
这几个字段比单独写一个“正常 / 异常”有用得多。
六、巡检流程要有停止条件
低效巡检还有一个常见问题：没有停止条件。
只要有人不放心，就再查一次。 只要群里有人问，就重新打开页面。 只要发现异常，就所有人一起看。
结果是，真正需要处理的问题没有更快解决，普通状态却消耗了大量时间。
比较合理的分流规则可以这样写：
| 触发条件 | 动作 |
|---|---|
| 状态无变化 | 自动记录，不通知 |
| 首次异常 | 保存证据，进入观察 |
| 连续两次异常 | 进入人工复核 |
| 页面无法加载 | 记录 URL 和截图 |
| 任务中断 | 记录步骤名 |
| 已有人接手 | 不重复派单 |
| 人工复核完成 | 关闭本轮记录 |
这里的关键不是规则多复杂，而是避免每次都从零开始判断。
七、最小可用流程可以这样落地
不用一上来就做复杂系统。
可以先做一个最小版本：
第一步，列出巡检对象。
target_id
target_name
entry_url
owner
check_frequency
第二步，定义状态。
pending
running
normal
watching
warning
manual_review
closed
第三步，统一证据。
run_id
current_url
screenshot_path
step_name
log_path
note
第四步，设置分流规则。
no_change -> close
first_warning -> watching
repeated_warning -> manual_review
task_failed -> keep_evidence
manual_done -> closed
第五步，每周复盘。
重点看三个问题：
- 哪些检查对象反复异常；
- 哪些步骤最容易失败；
- 哪些人工检查其实可以被规则替代。
这套流程足够小，但能让巡检从“重复打开页面”变成“按状态推进”。
八、什么时候需要沉到工作流里
如果检查对象很少，表格加人工备注就够了。
但如果出现下面这些情况，就该考虑把巡检沉到固定工作流里：
- 检查对象持续增加；
- 不同成员轮流处理同一类任务；
- 截图、日志、备注分散在多个地方；
- 自动化任务已经参与部分检查；
- 异常需要人工复核；
- 负责人需要快速看到整体状态；
- 同类问题反复出现，但没有复盘记录。
这时继续靠聊天记录和表格，成本会越来越高。
更好的方式，是把检查对象、执行记录、截图证据、状态分级和人工复核放进同一套流程里。
有些团队会把这类流程沉淀到统一的 浏览器任务工作流 中。重点不是让工具替代判断，而是让每次执行都有对象、状态、证据和下一步动作。
工作流的价值不在于“自动点得更快”，而在于失败后能说清楚：
任务跑到了哪一步。 页面停在什么位置。 现场证据在哪里。 谁需要继续处理。
九、最后给一份工程化检查清单
如果你正在改造后台巡检流程，可以按这份清单自查：
- 是否定义了巡检对象；
- 是否有唯一 run_id；
- 是否记录 current_url；
- 是否保存截图；
- 是否记录步骤名；
- 是否记录上一次状态；
- 是否记录本次状态；
- 是否计算状态差异；
- 是否有异常分级；
- 是否有人工复核入口；
- 是否有停止条件；
- 是否能按 run_id 找回证据；
- 是否能知道任务停在哪一步；
- 是否每周复盘重复异常。
如果这些问题都答不上来，巡检大概率还是人工动作，而不是工程流程。
总结
后台状态巡检越做越累，通常不是检查频率不够。
而是巡检没有被建模。
没有状态机，就只能写“正常 / 异常”。 没有证据链，就只能靠人回忆。 没有步骤名，就不知道任务失败在哪。 没有分流规则，就会把所有问题都交给人。 没有复盘机制，下次异常还会从头开始。
真正要优化的，不是每天多查几遍。
而是把巡检拆成：
对象。 状态。 证据。 规则。 复核。 复盘。
当这几个对象固定下来以后，巡检才会从重复劳动变成可复用工作流。
