运营商防骚扰名单查询 API：外呼风控为什么不能只存一个 can_call？

外呼系统做号码风险筛查时，最容易犯的错误不是少查一次，而是把用户退订、联系频率、风险查询结果和接口异常全部压缩成一个 can_call。本文以运营商防骚扰名单查询 API 为例，讨论 level 为什么更适合作为本次筛查策略保存、`forbid` 枚举不完整时如何避免错误映射，以及查询失败、地区信息和业务决策应该如何分层处理，从而建立一套更容易解释和维护的外呼风险模型。