验证优先级加权模型落地难点

给验证入口排优先级时，我最怕看到一张算得很整齐、却解释不清的打分表。可利用性、数据敏感度、修复成本各打 1—3 分，再加权排序，确实能让讨论不只靠直觉。但分数一旦写进台账，就很容易被当成“客观答案”。模型落地的难处，恰恰在于每一分背后的判断能不能经得起追问。

先看信息是否够用。一个入口公网可达，不等于已经确认能触达敏感数据；页面看起来像管理后台，也不能直接推断认证薄弱。我会把已验证的事实、客户提供的业务说明和仍待确认的推测分开记录。证据不足时，宁可标注“待确认”，也别用一个高分假装问题已经查清。

更棘手的是“修复成本”。它可以影响先做哪项验证，却不能被误当成风险大小：容易修的入口值得尽早核实、推动闭环，但这不代表修复困难的高影响入口可以一直往后放。权重怎么定，也应在验证前与客户说清楚；如果排序结果和业务判断冲突，应该回头检查依据，而不是硬替公式辩护。

我更愿意把加权结果当成讨论顺序的草稿，而不是自动派工指令。共享资产、第三方托管或明确排除的对象，不该因为分数高就进入主动验证；触发拦截、账号锁定或异常响应时，也要按停止条件处理。台账里留下评分依据、范围确认和状态变化，下一次复核才能知道：这个入口为什么排在这里，又为什么最终做了或没做。