资格条件判定
这项能力到底在做什么
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[生成未满足条件和建议动作]
F --> G[交给提醒 流转和留痕流程]
它最后会把什么交给下游流程
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. 它也不等同于价格政策核对”价格政策核对是在核对价格口径是否符合政策；
资格条件判定是在判断“当前对象是否有资格享受、参加、触发某件事”。