价格监控已经自动化，我为什么还要人工复核？

当时，我在维护第三方服务价格监控时，遇到了一组重复出现的变化：四条价格已经核对、确认并通知，下一周巡检却又报了出来。

检查一开始把注意力放在人工核对值上。我指出这些值是按官网当时的按量价格填的，不能先认定人填错了。沿历史记录回查，才发现确认后的价格没有完整写回基线。

这轮工作中，我负责确定比较口径、判断异常怎样处理，并借助 AI 修改脚本、核对表和操作说明。重复提醒只是表面问题，要修的是确认结果怎样进入下一次运行。

比较对象从网页换成计费项

早期版本按网页内容做差异比较，找到的变化里混着布局、脚本和动态内容。它们会变，计费规则未必变。

我把比较对象缩小到计费项：哪个服务、什么用法、多少数值、按什么单位、适用什么套餐。网页保留为证据，一条经过确认的计费记录作为比较基线。

这轮整理里，我还把一个服务的月付、年付套餐额度拆成两条。两种套餐包含的额度不同，放在同一行就没有稳定的比较对象。这种拆分增加了维护记录的工作，却是后续判断变化的前提。

来源打不开、单位无法对应的情况，先进入待核查，不直接确认为价格变化。

先查历史，再补基线

后续回查时，我们找到了此前已经确认并通知的记录。人工值没有错，脚本、价格明细和机器列仍保留旧基线，才让同一变化再次进入审核。

这次收口包含几个具体动作：按已经确认的结果同步这些位置，关闭原有审核记录及重复候选，再检查机器值与人工核对值是否一致。我没有把“提醒消失了”当成检查结束。

修复后的定向复测没有再检测到对应变化。全量检查仍遇到了网络和同步问题，记录中把两者分开，没有把局部复测当成整轮任务全部完成。

不只补数值，也修复核逻辑

仅把这一次旧值补上，还不足以解释下次该怎样处理。

当时复核脚本有一处判断需要改：人工核对值已经与官方来源一致，并不意味着可以跳过。如果机器基线仍旧，这恰好说明确认结果还需要应用到基线。只有机器当前值也已与官方一致，才符合对应的跳过条件。

重复候选的识别也作了调整。同一条待处理变化，不应该只因为通知状态变了，就被当成另一条新变化。去重不再依赖“是否已通知”。

这两项修改落进了复核脚本。操作要求也补清楚：人确认以后，需要同步脚本基线、价格明细和机器列，并关闭对应审核记录。确认仍由人负责，通知状态不再被用来替代后续处理。

刷新不能把人工判断冲掉

另一项需要保护的是人工核对值和备注。普通刷新只更新机器负责的字段；如果要开始全新一轮核对，需要明确处理人工列，而不是每次同步都清空。

行结构变动时，还要防止旧的人工值跟着行号移到另一个计费项。机器数据、人工判断和对象的对应关系，需要一起保留。

我把当前状态与历史记录分开：前者用来找待处理项，后者保留确认依据和修改过程。这样，再次出现差异时，可以像这次一样回查，而不是只剩下两列互不相同的数字。

通知要把人带到正确的问题上

这轮还修过一条误导性的通知。它写着“抓取记录为空”，实际原因是某个计费项解析失败。记录存在，消息却把人带向了错误的位置。

我保留原有调度和接收设置，把提示改为说明存在抓取异常或待确认项，并指向相应记录。整轮是否正常，则根据运行汇总判断：必需步骤是否结束、是否有失败、是否还有待核查内容，不能拿某一个服务的成功代替全部结果。

这轮最终留下的修正不只是几条新价格，还包括比较对象、复核分支、去重方式、人工字段保护和通知文案。它们解决的是不同原因造成的返工。

后续如果要继续减少人工投入，我会先分清：哪些时间花在理解套餐、单位和条件，哪些只是系统漏写、错配或重复提醒造成的收尾。前一类需要判断，后一类已有具体的修复对象。

本文依据 当次工作记录与历史验证结果整理，AI 辅助了实现和核对，供应商数值及内部人员已省略。项目后来调整过运行方式，本文不作为现行操作手册。