价格变了？先把证据看清楚。
把页面变化、计费变化和运行失败分开处理，让自动化缩小检查范围，再把需要判断的地方交给人。
- 我的参与
- 确定计费口径与异常处理方式，借助 AI 修改脚本、核对表和操作说明。
- 关键判断
- 人工值与机器值不同时先查来源和历史；已确认结果要写回比较基线。
- 实际交付
- 补齐基线，修正复核分支和去重逻辑，保留人工判断与异常状态。
- 验证结果
- 修正后的定向复测未再检出对应变化；全量检查仍有网络与同步问题。
最初比较错了东西
第一次完整测试给出了一串“价格变化”。逐个打开官方来源核对后，我发现变化来自页面布局、脚本和动态内容，没有一条计费规则真的变了。
系统照着最初的要求找出了网页变化，但网页变化并不等于价格变化。因此，我重新定义它究竟应该比较什么。
把网页变成可比较的证据
我把监控对象收窄到明确的计费项，保留来源、采集时间、价格、币种、单位及适用条件。缺字段或单位无法对齐时，不直接给出变化结论。
- 采集读取已确认的来源。
- 校验检查字段与时效。
- 标准化统一比较单位。
- 比较形成候选变化。
- 复核核对证据与影响。
一次运行失败，不能写成没有变化
数值缺失、页面结构改变和来源冲突，都需要作为明确的状态保留下来。系统可以提交候选结果，也可以报告失败；不能把没有读到证据解释成价格未变。
当前状态
每个计费项的最新证据、运行状态，以及受保护的人工审核字段。
审计历史
只记录已经确认的变化，以及背后的证据、决定和时间。
刷新可以更新机器提取的字段，但不能覆盖人工确认、备注或是否接受新基线的决定。否则每次自动运行，都可能把上一次认真做出的判断抹掉。
一个价格，三种不同解释
合成教学示例，不是供应商报价或实际监控结果。
| 观察 | 比较结论 | 下一步 |
|---|---|---|
| 每千单位 10 → 每千单位 12 | 同口径下的涨价候选 | 复核来源与生效日期 |
| 每千单位 10 → 每百单位 10 | 单位变了，原始数字不能直接比较 | 先换算，再复核 |
| 10 → 字段缺失 | 观察不完整 | 记录失败，保留已确认基线 |
我负责的判断与交付
我负责定义监控对象、重建数据结构、决定系统必须在哪里停下，并根据测试暴露的问题修改规则。AI 帮我写和修改脚本、整理字段及调试流程。
交付还包括操作说明：什么时候需要人介入、要检查什么、未处理完的情况应该留在哪里。基线和提醒都要等审核后才更新。
修正与复测结果
当时，一组已经确认并通知的价格再次进入审核。我沿历史记录找到漏写的基线，补齐脚本、价格明细和机器列，关闭原审核记录与重复候选，并修改复核分支和去重逻辑。
修正后的定向复测未再检出对应变化；全量检查仍遇到网络与同步问题，记录中单独保留了失败状态。这次验证覆盖了对应问题的修正，没有据此声称整轮运行全部正常。
官方页面会变，新的计费方式会出现，解析规则也会过期。人工复核是流程的一部分，系统不需要假装自己已经知道答案。
相关工作与笔记
接着看一次具体修正：已确认的价格重复报错后，我追查记录、补齐基线并修改去重逻辑。