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

第一次误报

我一开始比较错了东西

最初的计划很直接：定时保存每个公开价格页，和上一次的版本比较，只要不同就发提醒。

但网页不是价格表。里面还有导航、公告、脚本、推荐内容和页面布局。这些东西随时会动，计费规则却可能完全没变。

就算把爬虫做得更准，它比较的仍然是错误的对象。在继续调代码之前，我得先定义一条能在不同运行批次之间稳定对应的价格记录。

定义记录

网页是证据，不是比较对象

最后，我为每一个计费项保存一条确认过的记录。为了让下一次运行还能准确对应，它至少需要这些信息：

如果来源访问失败、单位解析不出来，或者两条记录无法对应，系统只能输出“需要审核”。它不能擅自把不确定写成“价格已变化”。

差点出错

一条记录不能代表整次运行

接下来暴露的问题在通知逻辑。每个服务都能单独上报结果，于是某一项检查成功时，系统可能发出“没有问题”，但其他服务可能还没结束，甚至已经失败。

这条消息对单行记录没错，对整次运行却是错的。我把通知从单条记录里移除，另外加了一层运行汇总。

只有三个条件同时满足，系统才能说一切正常：所有必需步骤都已完成、没有失败项，也没有候选结果还在等待审核。

只有完整运行结束后，“没有变化”才算一个有效结果。

保护审核状态

刷新不能覆盖人工决定

审核表里还有一个不太显眼的问题。刷新可以更新系统提取的字段，但不能覆盖人工确认、备注，或者是否接受新基线的决定。

每次运行都追加一整份重复记录也不行。表格很快被噪音塞满，最新状态反而更难找。

我把数据拆成了两部分。一条记录保存每个计费项的当前状态，人工审核字段受到保护。另一张审计日志只记录已经由人确认的变化。

谁来决定

分工要看出错的后果

真正有用的问题不是“智能体能不能做”，而是“如果这个判断错了，会发生什么”。

系统可以提交一个候选结果，也可以提交一次失败。只有经过人确认的变化，才能进入基线。

最后上线的版本

真正跑通的版本，做得更少

最后的流程只读取我批准过的来源，提取一组固定的计费项，和已经确认的基线比较，再把失败或候选结果送进审核队列。基线和提醒都要等审核后才会更新。

我负责定义监控对象、重建数据结构、决定系统必须在哪里停下，以及根据测试暴露的问题重新改规则。

AI 帮我写和修改脚本、整理字段、调试流程。它不负责判断什么才算一次已经确认的变化。

我还补了操作说明：什么时候需要人介入、要检查什么、没处理完的情况应该留在哪里。否则这个流程只会在我站在旁边解释时才有用。

五个检查

现在我先问五个问题

1. 来源证据从哪里来？
2. 对象系统比较的稳定单位是什么？
3. 输出这是事实、候选结果，还是一次失败？
4. 负责人谁有权确认它？
5. 证明系统如何证明整次运行确实完成了？

我不会用“完全不需要人”来判断这类自动化做得好不好。我更在意的是：需要人工检查的东西是不是少了，同时失败和不确定性有没有被如实保留下来。

官方页面会改，新的计费方式会出现，解析规则也会过期。审核队列就是这些例外暂时停下来的地方，系统不需要假装自己已经知道答案。