风险预警该触发却没触发，先别急着改阈值。把“没提醒”拆成可核对的时间点和对象，确认指标数据是否真的进入系统、风险条目是否满足规则条件，再核对阈值口径。逐项用同一时点的原始数据回算，能复现差异的那一项才是根因；修复后回放历史数据验证，并补上阈值变更与漏报复核机制。
要点总览（TL;DR）
- 漏报先分流：确认指标数据是否写入、风险条目状态与负责人是否满足规则条件、规则是否启用或被覆盖，前三项都正常才归入阈值判定问题。
- 阈值错位集中在五类：指标定义与取数范围不一致、比较方向与边界值写错、统计周期与评估时点错位、分级区间重叠或留空档、生效范围与优先级未覆盖。
- 每类假设都用应触发时点的原始数据回算，能复现差异的才认定为根因；回算不出来的假设保留观察，不写进修复方案。
- 修复时先固定配置快照，一次只改一处，批量或全局规则先在单项目或测试范围回放验证，结果与预期不符立即暂停并回到信号核查。
- 验证看历史回放是否在应触发时点产生提醒、接收人是否正确，再观察一个完整评估周期确认无误报激增，并建立阈值变更评审与定期回算抽查。
漏报的表现与影响范围界定
“该触发没触发”是一句结论，不是可排查的事实。诊断第一步是把这句话还原成具体症状：哪条风险、哪个指标、应该在什么时点、以什么方式提醒谁，实际发生了什么。症状记录越具体，后续回算的基准越可靠。
漏报通常有三种表现，排查方向不同：
- 完全无提醒：应触发时点前后都没有任何通知或状态变化，优先怀疑信号未进入或规则未生效。
- 延迟提醒：提醒出现，但晚于应触发时点，常见于统计周期与评估时点错位、数据刷新滞后。
- 提醒到错误对象：提醒发出了，但接收人不是该风险的负责人或关注人，属于生效范围与接收人配置问题。
界定范围时，逐项记录以下信息，形成一张漏报症状记录表：
| 记录项 | 填写内容 | 用途 |
|---|---|---|
| 风险条目 | 风险编号、名称、负责人、所属项目 | 确认规则是否应覆盖该条目 |
| 涉及指标 | 指标名称、数据来源、取数口径 | 后续回算的输入 |
| 应触发时点 | 按规则定义推算出的准确时间 | 回算基准 |
| 实际表现 | 无提醒／延迟多久／提醒给了谁 | 区分症状类型 |
| 发现时点 | 由谁、通过什么途径发现 | 评估漏报持续时间 |
同时区分单条漏报与批量漏报。只有一条风险漏报，更可能是该条目的字段状态、负责人或数据缺失导致；同一规则下多条风险同时漏报，或同一指标在多个项目都未触发，则指向规则配置的共性问题，例如阈值口径、生效范围或优先级覆盖。这个判断决定后续排查是逐条核对还是直接审查规则本身。
先分清是信号缺失还是阈值判定问题
在动阈值之前，必须先排除上游原因。阈值判定发生在数据写入和条件匹配之后，如果指标数据根本没进来，或者风险条目的状态不满足规则生效条件，改阈值不会让预警恢复，反而会掩盖真正的问题。建议按以下顺序分流：
- 查数据是否写入：在应触发时点附近，查看该指标是否有记录、数值是否为空、更新频率是否符合预期。数据断更、采集失败、手工录入遗漏都会造成“数值看起来没超标”的假象。
- 查条目字段状态：规则通常只对特定状态、特定负责人、特定项目范围的风险生效。确认该风险条目当时的状态是否在规则覆盖范围内，负责人字段是否为空或指向了已离职、已转岗人员。
- 查规则自身状态：规则是否处于启用状态，是否被停用、被更高优先级规则覆盖，或命中了静默、免打扰设置。
- 确认信号存在且条件满足：只有前三步都通过——数据在、字段对、规则启用——才把问题归入阈值判定类，进入口径核对。
| 分流结论 | 典型证据 | 下一步 |
|---|---|---|
| 信号缺失 | 应触发时点无数据记录、数值为空、更新中断 | 修复数据采集或录入，暂不动阈值 |
| 条件未满足 | 条目状态、负责人、项目范围不在规则覆盖内 | 核对规则生效范围，确认是否为预期设计 |
| 规则未生效 | 规则停用、被高优先级规则覆盖、处于静默期 | 恢复规则或调整优先级，记录变更原因 |
| 阈值判定问题 | 数据在、条件满足、规则启用，仍未触发 | 进入阈值口径逐项回算 |
分流表的价值在于把“猜”变成“排除”。每排除一类原因，剩余假设的范围就缩小一次；如果跳过这一步直接调阈值，很可能出现改了阈值仍然漏报、或者误报激增的情况。
阈值设置的常见错位与验证证据
确认信号和条件都正常后，阈值问题通常集中在五类口径错位上。每一类都要用同一时点的原始数据回算，能复现差异的才认定为根因，回算不出来的假设只能保留观察，不能直接当结论写进修复方案。
| 错位类型 | 典型表现 | 回算方法与判定证据 |
|---|---|---|
| 指标定义与取数范围不一致 | 规则统计的是全部任务，报表口径只算未关闭任务；数据源不同导致数值偏差 | 用规则配置的过滤条件和数据源重算该时点数值，与预警判定所用数值对比，差异可复现即为根因 |
| 比较方向与边界值错误 | 大于写成小于；数值恰好等于阈值时未触发 | 取应触发时点的实际值与阈值，按配置的比较符手工判断，确认方向是否写反、边界是否含等于 |
| 统计周期与评估时点错位 | 按周聚合的数据按日判断；评估发生在数据刷新之前 | 核对规则聚合周期与评估执行时间，用同一周期口径重算，确认评估时点数据是否已就绪 |
| 阈值数值与分级不匹配 | 预警级别区间重叠或留有空档，数值落在空档内不触发任何级别 | 列出各级别区间上下限，把实际值代入区间判断，确认是否落入未覆盖区间 |
| 生效范围、优先级与静默设置 | 规则未覆盖该风险所属项目；被高优先级规则拦截；处于静默窗口 | 核对规则的适用范围清单、优先级顺序与静默时段，确认该条目在应触发时点是否被排除 |
回算时坚持三个原则：使用应触发时点的原始数据，不用当前数据倒推；使用规则配置的口径，不用报表口径替代；一次只验证一个假设，避免多个变量同时变化导致无法归因。对于批量漏报，优先验证生效范围与优先级，因为这两类问题最容易同时影响多条风险。
回算结果建议记录为“假设—证据—结论”三列：假设写清怀疑哪类错位，证据附上原始数值和计算过程，结论标注“已复现”“未复现”或“证据不足”。这份记录既是修复依据，也是后续复盘的材料。
按排查顺序处置并控制改动风险
确认根因后，修复的原则是影响面从小到大、一次只改一处。阈值和规则往往被多条风险共用，一次改多个参数会让验证失去对照，出问题时也难以回退。
- 固定配置快照：修改前导出或截图当前规则的阈值、比较符、统计周期、生效范围、优先级和静默设置，记录修改时间和操作人。快照是回退和对比的依据。
- 从影响面最小的一项开始：如果根因是单条规则的比较符写反，先改这一条；如果涉及分级区间，先改一个级别验证效果，再推广到其余级别。
- 批量或全局规则先小范围验证：涉及多项目共用的阈值时，先在单个项目或测试范围启用，用历史数据回放确认触发结果符合预期，再扩大到全量。
- 设定停止点：回算或回放结果与预期不符时立即暂停，回到信号核查环节重新分流，不在错误方向上继续叠加修改。
- 完整留痕：记录谁改的、改了什么、依据哪条回算证据、影响哪些风险条目。留痕让后续漏报复盘能追溯到每一次变更。
在 ONES 中，风险条目与项目计划、里程碑基线关联，计划与执行的偏差可用于识别风险；版本对比能力可以追溯变更细节。处置阶段可以把阈值修改的原因、回算证据和影响范围记录在对应工作项或变更记录中，让规则调整与风险条目的状态变化保持可追溯，便于事后核对某次漏报是否与某次配置变更相关。
需要提醒的是，修改阈值本身会改变预警的敏感度。放宽阈值可能消除误报但增加漏报，收紧阈值则相反。每次修改都应明确这次调整要解决的是漏报还是误报，避免为了消除一次漏报而引入一批误报。
修复后的验证与漏报复发预防
修改完成不等于问题解决，验证要回答两个问题：应触发时点是否真的产生了提醒，提醒对象是否正确。验证通过的标准建议明确为：
- 历史回放通过：用漏报发生前后的历史数据重新执行规则，应触发时点产生提醒，接收人为该风险负责人或指定关注人。
- 边界值验证通过：构造等于阈值、略高于、略低于阈值的数值，确认触发行为与设计一致。
- 完整周期观察：观察一个完整评估周期，确认同类风险正常触发，且没有出现误报激增。
- 批量场景抽检：对共用该规则的其他风险条目抽检，确认修复没有改变它们的触发行为。
复发预防的重点是把这次排查沉淀为机制，而不是依赖个人记忆：
- 阈值变更评审：阈值、比较符、统计周期、生效范围的修改走评审，说明变更原因和预期影响，避免随手调整。
- 定期回算抽查：按固定周期抽取若干风险条目，用原始数据回算阈值判定，发现口径漂移及时纠正。
- 漏报事件记录：每次漏报记录症状、根因、证据和修复方式，形成可复用的排查条目，下次遇到类似表现可以直接对照。
- 状态变化联动复核：风险条目状态、负责人、所属项目发生变化时，复核相关规则的生效范围是否仍然覆盖，避免因组织调整造成规则失效。
对于需要持续跟踪的风险，ONES 的风险驱动管理思路和 AI 辅助分析可围绕项目进展、工时投入、缺陷分布与资源配置生成进展分析和根因判断，帮助管理者在风险扩大前介入；这类分析依赖项目数据的完整录入，适合作为阈值预警之外的补充观察手段，不能替代对阈值口径本身的核对。
常见问题
数据在、规则也启用，回算却复现不出差异，接下来该查什么？
回算复现不出差异，说明当前掌握的假设还不足以解释漏报，此时不宜直接改阈值。可以补查三类信息：一是应触发时点前后数据是否存在短暂断更或延迟写入，回算时用的是补录后的数据；二是规则评估的实际执行时间是否早于数据刷新完成；三是该风险条目在应触发时点是否发生过状态、负责人或所属项目的变更，导致规则覆盖关系临时改变。把回算的时间粒度缩小到小时级，往往能定位到日级回算看不到的时序问题。
批量漏报和单条漏报的排查顺序有什么不同？
单条漏报优先查该条目自身：字段是否为空、状态是否在规则覆盖范围、负责人是否有效，多数情况属于个案数据问题。批量漏报则应先审查规则本身，重点看生效范围清单、优先级顺序和静默时段，因为这三类配置最容易同时影响同一规则下的多条风险。批量场景下逐条核对数据效率很低，先确认规则是否被更高优先级规则拦截或未覆盖相关项目，能更快缩小范围。
为了消除漏报把阈值调宽，为什么反而可能带来新问题？
阈值调整会同时改变预警的敏感度。放宽阈值可以让边界附近的判定更容易触发，但也会让原本不该提醒的数值进入预警区间，带来误报；收紧阈值则相反，误报减少而漏报风险上升。每次修改前应明确这次要解决的是漏报还是误报，并用历史数据回放确认修改后的触发结果，避免为了消除一次漏报引入一批误报。修改后观察一个完整评估周期，是判断敏感度是否合适的必要步骤。
风险条目状态或负责人发生变更后，预警规则需要重新核对吗？
需要。规则通常按状态、负责人、所属项目等条件确定生效范围，组织调整、人员转岗或项目归属变化都可能让原本覆盖的条目落到规则之外，表现为该触发却没触发。建议在风险条目状态、负责人或所属项目变更时，同步复核相关规则的生效范围是否仍然覆盖，并把这次复核记录在变更留痕中，便于后续漏报排查时对照时间线。
阈值修复上线后，怎样判断预警是真的恢复了？
建议用四项标准判断：用漏报发生前后的历史数据回放，确认应触发时点产生提醒且接收人正确；构造等于阈值、略高、略低于阈值的数值，确认边界触发行为与设计一致；观察一个完整评估周期，确认同类风险正常触发且没有误报激增；对共用该规则的其他风险条目抽检，确认修复没有改变它们的触发行为。四项都通过，才能认为预警恢复。
