ThinkLink 告警如何落地：从触发条件到恢复通知的完整检查

阈值之前，先写清楚要处理的事件

“温度高就发消息”还不足以成为一条可交付规则。需要说明哪个区域、哪台设备、什么单位、持续多久，以及通知后的动作。现场人员看到消息后，应该能知道先检查什么，而不是只收到一个没有位置和时间的数字。

建议把每条规则写成一句可验收的话：在指定范围内，当满足明确条件时产生告警；条件解除后恢复；由指定责任人接收。持续时间、阈值和提醒频率都是现场业务参数，不能从通用示例直接复制到正式项目。

确认触发器真正挂在有数据的对象上

ThinkLink 触发模型在所挂载对象收到上行数据、完成处理后执行。模型配置已保存，并不表示目标设备已经绑定该模型。先核对绑定对象和脚本依赖字段，再核对它调用的 RPC 是否具备对应能力。

若测量和执行来自不同设备，应按平台文档选择虚拟设备（资产）聚合数据的方案。不要把触发器挂到一台不产生所需测量值的执行设备上，再期待它自动读到另一台传感器的数据。跨设备控制需要独立验证数据关系和目标身份。

把发生、保持和恢复分开

读数在阈值附近波动时，使用同一个数值作为触发和恢复边界，可能导致频繁切换。可以按现场要求设计不同的触发与恢复阈值，并明确重复提醒策略。涉及时间窗口或历史状态的策略，应通过相应脚本和状态机制实现，不能只改消息文案。

离线告警还需要单独考虑：一个依赖新上行才执行的触发器，无法仅靠设备停止上报这件事再次运行。应使用适用的在线检查或定时检查方案，并根据上报周期设置判断条件。

通知组保存后，还要验证接收结果

当前通知组文档列出 email 和 WeCom WebHook 两种内置选择。邮件还依赖 SMTP 配置，通知组本身也需要启用并填写联系人。其他服务应按相应的自定义 RPC 或集成文档配置，不能把渠道名称当作已经安装并可用的能力。

测试时使用明确的测试接收渠道，发送包含设备别名、位置、时间、当前状态和处置建议的消息。分别查看触发执行、告警记录和接收端结果；通知组保存成功只是其中一个配置步骤。

用四次测试完成上线前检查

测试不应只覆盖一次超限。建议依次验证正常上报、进入告警、持续异常和恢复正常，记录每一步应产生几条告警、几次通知，以及谁能看到它们。这样能发现重复触发、恢复缺失和接收人配置错误。

交付时同时记录如何临时停用规则、谁维护阈值以及如何追查一次事件。若告警同时驱动设备动作，还要增加现场状态回读；消息发出不能代替执行设备已经完成动作的证据。

1. 正常数据不应产生意外告警。
2. 异常数据应触发指定事件和测试通知。
3. 持续异常按既定策略处理，不反复刷屏。
4. 恢复数据应解除状态，并按约定发送恢复通知。