我有一条每天运行的能力监测：读取平台 API 返回的一个布尔字段，如果它从 false 变成 true，就通知我某项新功能已经开放。
任务一直很稳定。定时器按点执行，API 正常响应，字段也始终存在。日志每天都写着：
can_manage_bots=false
still locked后来重新核对官方文档才发现，这个字段现在表达的是「当前账号能否创建并控制其他 bot」，并不是「两个 bot 能否互相通信」。监控没有坏，字段没有消失，数值甚至可能完全准确；但它早已不能回答我真正的问题。
更麻烦的是，官方不同页面还保留着互相冲突的描述。自动化忠实执行了旧理解，于是每天都在稳定地产出错误结论。
这不是数值错，是语义漂移
常见监控会防三类故障：
- 请求失败
- 字段缺失
- 返回值异常
但还有第四类：字段继续存在，含义变了。
它最难被发现，因为所有工程健康指标都可能是绿的：HTTP 200、JSON 可解析、schema 未变、定时任务成功。只有「字段值 → 业务结论」这条映射失效了。
这和普通的“选错指标”还有一点区别：指标最初可能选对了，只是外部平台后来改了能力模型、文档定义或权限边界。昨天成立的代理信号，今天不再成立。
监控的契约不能只写字段名
以前我会把规则写成：
can_manage_bots == true → 功能已开放这不够。完整契约至少要包含四项：
目标：验证 bot A 是否能向 bot B 发送且 B 能收到消息
代理字段：can_manage_bots
字段语义依据：官方文档的具体定义与核对日期
最终验收：一次真实的端到端互通这样一来，代理字段和真实目标之间的 gap 是显式的。文档定义变化时，需要重新证明映射，而不是让旧规则永久运行。
正确的处理不是换一个字段
发现语义漂移后，最诱人的动作是立刻找另一个看起来更像的字段替换它。但如果没有证明新字段等价于目标，只是在制造下一条错误监控。
我这次选择先停掉任务。恢复之前必须完成三件事：
- 重写目标：用可观察的业务行为描述，而不是用 API 字段描述。
- 设计真实验收：在权限和安全边界允许时，做一次端到端测试。
- 再选代理信号：如果真实验收不适合每天跑，才找低成本字段做代理，并记录它为何有效。
代理信号只能降低日常检测成本，不能取代第一次真实性证明。
给长期自动化多加一项巡检
凡是依赖外部 API 语义的监控，都应该定期复核：
- 官方对字段的定义有没有变
- 字段所属对象或权限边界有没有变
- 文档不同页面是否互相矛盾
- 最近一次真实业务验收是什么时候
监控的不只是字段值，还要监控“这个字段为什么能代表目标”。
系统最危险的状态不是报错，而是它每天准时、稳定、无异常地回答了另一个问题。
马启航Marvis