重评触发判定
这项能力到底在做什么
Section titled “这项能力到底在做什么”重评触发判定，简单说，就是当某个对象原本已经有一版评估结论、评级结果、审核状态、健康分、风险级别或资格判断之后，系统持续判断它在什么时间点、什么事件条件下必须重新评估，而不是一直沿用旧结论。
很多流程真正容易出问题的，不是第一次评估做得不认真，而是第一次评完以后，后面的变化没有及时触发重评。
常见情况通常是这样：
- 客户风险等级已经很久没更新
- 供应商评分是去年做的，今年环境早变了
- 病人方案评估需要复查，却没人知道何时必须重评
- 学员状态发生明显变化，但仍按旧结论安排路径
- 某类资格判断本该因事件变化重新触发，却一直沿用老结果
重评触发判定真正解决的，不是重评动作本身，而是先把“什么时候必须重新看一遍、为什么现在该重评”结构化地挂清楚。
它通常接收什么输入
Section titled “它通常接收什么输入”这项能力接进来的，通常不是一条单独事件，而是一份历史评估结果加上一组持续变化的上下文。
常见输入包括：
- 当前评估结论或评级结果
- 上次评估时间
- 对象近期行为变化
- 状态更新事件
- 到期周期规则
- 触发重评的阈值规则
一起带进来的上下文，常见还有这些：
- 对象类别
- 当前风险或重要程度
- 最近是否发生重大异常
- 是否存在人工豁免
- 重评窗口和最晚时限
- 重评所需资料是否已齐
这些上下文很关键。因为重评触发判定不是只看“时间到了没”，而是要知道：
- 是周期到期触发
- 还是状态变化触发
- 还是高风险事件触发
- 当前有没有理由继续沿用旧结论
它能输出什么结果
Section titled “它能输出什么结果”重评触发判定最后交出去的，不应该只是一句“建议复核”，而应该是一份结构化触发结果。
常见输出包括：
| 输出项 | 说明 |
|---|---|
| 触发结论 | 当前是否必须、应当或暂不需要重评 |
| 触发原因 | 到期、事件变化、阈值异常或组合条件命中 |
| 紧急程度 | 现在是否接近最晚重评时点 |
| 影响说明 | 继续沿用旧结论会带来什么风险 |
| 前置条件 | 重评前还缺哪些资料或动作 |
| 建议动作 | 立即重评、预约重评、继续观察或升级人工确认 |
这样下游拿到的，就不是一句模糊的“最好看一下”，而是一份关于“为什么现在必须重新评估”的明确说明。
它在内部是怎么跑起来的
Section titled “它在内部是怎么跑起来的”重评触发判定真正难的地方，不是做重评，而是同时把上次结论、时间规则和近期变化一起看。
它在内部通常会经过下面这条链。
1. 先识别当前对象和上次评估基线
Section titled “1. 先识别当前对象和上次评估基线”系统先判断：
- 当前对象是什么
- 上次评估结论是什么
- 上次评估发生在什么时候
2. 再识别触发条件
Section titled “2. 再识别触发条件”到了这一步，系统会一起看：
- 周期是否临近或到期
- 是否发生重大行为变化
- 是否出现异常事件
- 是否命中组合阈值
3. 再判断重评优先级和最晚窗口
Section titled “3. 再判断重评优先级和最晚窗口”真正有价值的，不是知道“理论上该重评”，
而是明确：
- 现在就要重评
- 近期应排入重评计划
- 还是可继续观察
4. 再输出对下游的影响
Section titled “4. 再输出对下游的影响”系统会继续说明：
- 如果不重评，哪些动作应受限
- 当前是否应提醒业务人员
- 是否需要先补齐资料再进入重评
5. 最后把结果交给提醒、预审和审批流程
Section titled “5. 最后把结果交给提醒、预审和审批流程”重评触发判定之后，系统往往还会继续接到：
- 资料预审与缺项校验
- 任务提醒
- 审批提交流转
- 风险预警
这样重评不会只停在一个红点提醒上。
重评触发判定的详细内部流程图
Section titled “重评触发判定的详细内部流程图”flowchart TB
A[输入上次评估结果和对象近期状态] --> B[识别周期 到期和事件触发条件]
B --> C[判断当前是否命中重评门槛]
C --> D[判断紧急程度和最晚重评窗口]
D --> E[输出触发原因 影响说明和建议动作]
E --> F[交给提醒 预审 审批和风险流程]
它最后会把什么交给下游流程
Section titled “它最后会把什么交给下游流程”重评触发判定真正交给下游的，不只是一个布尔结果，而是一份关于当前重评必要性的说明。
常见会交出去这些内容：
- 触发结论
- 触发原因
- 紧急程度
- 影响说明
- 前置条件
- 建议动作
这样后面的流程才能继续做：
- 安排重评
- 提醒跟进
- 限制继续办理
- 先补资料
- 升级人工确认
它怎么接入业务才真正有价值
Section titled “它怎么接入业务才真正有价值”重评触发判定最怕的，不是评估多，而是旧结论被长期沿用到已经不适用。
真正常见、也最有价值的接法，一般有下面几种：
1. 接在对象状态会随时间或行为变化的场景里
Section titled “1. 接在对象状态会随时间或行为变化的场景里”只要结论不是一劳永逸，这项能力就很值钱。
2. 接在错误沿用旧结论成本高的流程里
Section titled “2. 接在错误沿用旧结论成本高的流程里”只要会带来风险、误判或资源错配，就特别需要它。
3. 接在周期规则和事件规则会同时触发的场景里
Section titled “3. 接在周期规则和事件规则会同时触发的场景里”这种时候最适合把时间触发和事件触发统一判断。
4. 接在重评前还需要补资料或审批的流程里
Section titled “4. 接在重评前还需要补资料或审批的流程里”因为它不仅判断“要不要重评”，还要把后续动作接起来。
什么情况下必须转人工
Section titled “什么情况下必须转人工”重评触发判定虽然适合自动化，但下面这些情况最好让人工介入：
- 触发规则本身存在争议
- 当前对象涉及重大法律、财务或医疗责任
- 上次评估结论缺少可追溯依据
- 重评触发与业务策略冲突需要管理层拍板
- 当前状态数据明显不完整或不可靠
真正稳的做法，不是让系统替人完成所有重评判断，而是让系统先把大多数应重评对象及时拉出来，把高风险灰区交给人。
为什么这项能力站得住
Section titled “为什么这项能力站得住”重评触发判定之所以值得单独成为一项通用能力，是因为企业里很多“为什么还按旧结论处理”的问题，本质上都不是第一次评错了，而是该重评的时候没有被及时触发。
1. 它解决的是旧结论继续沿用过久的问题
Section titled “1. 它解决的是旧结论继续沿用过久的问题”这类问题会在风险评级、资格审核、供应商评估、服务分层和健康分级里反复出现。
2. 它能明显减少本该复查却长期无人触发的情况
Section titled “2. 它能明显减少本该复查却长期无人触发的情况”越早挂清重评触发点，下游越稳。
3. 它边界清楚，不等同于寿命到期预测
Section titled “3. 它边界清楚，不等同于寿命到期预测”寿命到期预测更偏某个对象或资料何时接近生命周期边界；
重评触发判定更偏某个已存在评估结论是否必须重新评估。
4. 它也不等同于资格条件判定
Section titled “4. 它也不等同于资格条件判定”资格条件判定更偏当前是否满足进入门槛；
重评触发判定更偏原有结论何时应该重新判断。