智能审批系统设计方案：规则、流程与证据的分层落地

做过几个审批类系统之后，我越来越觉得"智能审批系统设计方案"这几个字里，最容易被误读的就是"智能"两个字。不少团队第一反应是接个大模型、做意图识别、上文本分类，仿佛不挂点算法就不叫智能。可真实的现场是：一张报销单进来，先得判断它属于哪个费用类别、金额有没有超部门预算、发票号是不是重复报销、供应商在不在黑名单、审批人是不是在休假、跨级审批要不要触发……这些判断里，八九成是确定性的规则，只有剩下的一两成需要概率模型去做模糊判断。所以一份能真正落地的智能审批系统设计方案，重点不在模型多花哨，而在于把规则、流程、证据这三件事的分层做对：确定的事用规则秒判，模糊的事用模型给建议，关键节点上让人做最终决定。这套东西适合谁看？正在从零搭审批中台的研发、被业务方天天催着改规则的后端、以及想把AI塞进流程却不确定从哪下手的产品同学，都能在里面找到可以直接抄的部分。

1. 为什么"智能审批"不能一上来就堆模型

1.1 审批系统的本质是三件事：规则、流程、证据

我习惯把审批系统拆成三根柱子来看。规则决定这张单子往哪走、要不要自动通过、要不要加签；流程决定它在谁手里停、停多久、超时之后找谁；证据是这张单子凭什么被这么判——表单字段、附件、发票、历史记录、模型给出的理由。三者是互相咬合的，规则写得再漂亮，流程变量传不过去就是废的；模型判断再准，证据链留不下来，出了问题照样说不清。

拿最常见的差旅报销举例。员工提交时填了城市、天数、金额、发票张数，这些是证据的原始素材；系统要判断"住宿费是否超过该城市标准"，这是规则；判断完之后要流转到直属主管，再到大区财务，这是流程。这三件事各自的变更频率完全不同：流程半年不动一次，规则可能每周都改，证据的格式则跟着业务单据走。把变更频率差异这么大的东西揉在一个模块里写，后面的维护成本会非常难看。所以设计的第一步不是画架构图，而是先把这三件事在代码和配置上分开，让规则可以单独发布、单独回滚，流程引擎不感知具体业务字段。

生活化的类比就是小区门禁：门禁卡权限是规则，刷卡进闸机的顺序是流程，卡本身和刷卡记录是证据。你不会因为想换个权限策略，就把整个闸机拆了重装。

1.2 一个常见的失败路径：把AI放在最前面

我见过一个典型做法：某公司的技术团队接到需求，说审批太慢，要"智能化"。团队很兴奋，直接上了一个文本分类模型，把申请事由自动归类，再叠一个大模型做"是否通过"的预测。上线两周就出问题。第一，模型对没见过的表述归类不稳，同类事项被分到不同类别，走的审批链路完全不一样；第二，模型说"建议通过"但给不出人话级别的理由，财务不认；第三，也是最要命的，事后追溯的时候，只能看到"模型判定通过"，看不到当时用的哪个版本、输入是什么、阈值是多少。

这就是把AI放在最前面的代价。审批这个场景对三件事的要求特别高：可解释、可回溯、可申诉。黑盒模型在这三点上天生吃亏。所以我的经验是，AI应该放在两个位置：一是"辅助输入"，比如从发票图片里把金额、日期、税号抽出来，减少人工录入；二是"辅助决策"，给出建议、置信度和理由，但不做最终裁决。最终裁决权必须落在规则引擎的确定性输出或人的手上，这条线一旦模糊，后面全是扯皮。

1.3 分层设计：把"智能"拆成四层

我一般把整个系统拆成四层，从上到下依次是感知层、判断层、编排层、证据层。感知层负责把非结构化输入变成结构化字段，OCR、表格识别、字段抽取都属于这一层；判断层是规则引擎加评分模型，输出的是"通过/驳回/转人工"以及分值；编排层管流程流转、节点寻址、超时补偿；证据层负责把所有输入输出、规则版本、模型版本、人工操作全部留痕。

这个分层的价值在于，每层的变更都不会把其他层拖下水。业务方要改一条金额阈值，只需要在判断层发一个新版本的决策表；要加一个审批节点，只动编排层；OCR供应商换了，只动感知层。反过来，如果一开始就做成一个大泥球，改一条规则要连带着改流程定义、改前端表单、改数据库字段，那这个系统活不过半年。

2. 整体架构与核心选型拆解

2.1 五层架构与各自的职责边界

在四层的基础上再加一个接入层，就构成了我常用的一套完整结构。接入层处理各种来源的单据——Web端提交、移动端提交、外部系统推送、批量导入，做的是协议适配和鉴权；表单层负责动态表单渲染和字段校验；流程层、决策层、数据审计层就是上面说的那些。这里最容易踩的坑是边界越界：决策层直接去写业务库，或者流程层里塞了一堆业务if-else。

我给团队的硬规矩是：决策层只做纯函数式的判断，输入是一个上下文对象，输出是一个决策结果，不产生任何副作用；流程层只认决策结果和路由规则，不关心里面是怎么算出来的；所有写操作统一由业务服务层来落库，决策和流程只发事件。这样做的直接好处是决策逻辑可以拿去做单元测试和影子回放，不需要起整个流程实例。我实测过，把决策抽成纯函数之后，一条规则改动的回归测试时间从半小时压到三分钟，因为可以直接拿历史单据样本批量跑。

2.2 规则引擎还是硬编码 if-else：什么时候该上引擎

这个问题我被问过不下二十次。结论不是"一定要上引擎"，而是看三个指标：规则条数、变更频率、变更的人是谁。规则少于三十条、半年都不改一次、只有研发能改，那就老老实实写 if-else，可读性最好、性能最高、调试最方便。反过来，规则上百条、每周都有人来提需求、业务方希望自己维护，那就必须上规则引擎或者决策表。

上引擎之后有两个工程细节必须提前想清楚。一是表达式求值的性能，规则引擎在低并发下看不出问题，但审批系统的流量往往集中在上午九点到十一点，瞬时并发拉起来之后，脚本重复编译会成为瓶颈，所以一定要做表达式缓存和 JIT 预热。二是规则的可控性，运营改规则时容易写出死循环或者空指针的表达式，需要在发布前做静态校验，比如禁止在条件里调用外部服务、禁止出现无界循环，并且给每次求值加上超时熔断，单次决策超过 200 毫秒直接降级到默认策略并告警。

2.3 流程引擎选型：状态机、BPMN 还是事件编排

流程这块的选型经常被过度纠结。我的判断标准很简单：审批节点是固定模板还是动态生成，分支逻辑是显式可画还是隐式散落。节点固定、分支多、需要业务方看图说话，选 BPMN 类引擎；节点根据金额、部门、事项类型动态拼装，不同单据链路差异极大，用轻量状态机加配置化路由会更灵活；跨多个系统、需要异步等待外部回调，那就走事件驱动编排。

BPMN 引擎的问题是重，流程定义要走部署流程，改一个节点顺序就得重新部署一版，而且流程变量和业务字段容易混在一起；自研状态机的问题是容易越写越乱，尤其是加签、转办、撤回、退回这些操作，每个都能把状态图炸开。我自己的折中是：流程定义用配置化的 JSON 描述，节点类型限定在审批、抄送、条件分支、自动任务四种，状态流转由一个专门的状态机服务统一管理，所有操作都走同一个状态迁移入口，任何非法迁移直接拒绝。这样既保留了灵活性，又把复杂度收敛在一个地方。

2.4 单据数据模型：别把业务字段塞进流程变量

这一条是我踩坑之后总结出来最贵的教训。早期图省事，把报销金额、城市、发票号全塞进流程变量，引擎每次流转都要序列化反序列化一大坨 JSON，单量一上来，数据库的流程变量表直接爆掉，而且改一个字段类型还要处理历史数据的兼容。正确做法是业务数据只存业务表，流程变量里最多放路由必需的几个字段，比如金额档位、事项大类、所属组织，用 businessKey 关联到业务单据。

注意：流程变量的序列化格式一旦上线就很难改。新增字段可以，删改字段几乎等于一次数据迁移。所以设计之初就要把变量控制在十个以内，且全部是不可变的基础类型。

3. 核心细节：决策表、评分卡与AI辅助节点的实现

3.1 决策表怎么设计才不打架

决策表的核心是命中策略。常见的三种：首次命中、全部命中、按优先级命中。首次命中适合互斥的规则，比如按金额区间分层，命中一条就停；全部命中适合收集型场景，比如把所有风险提示都攒起来给人看；优先级命中适合有覆盖关系的规则，比如"黑名单供应商"优先级高于"金额超限"。

我一般用"优先级 + 首次命中"的组合，表结构就是条件列加动作列，条件列里支持等于、区间、包含、正则几种操作符。写决策表最容易出的问题是规则重叠且优先级相同，上线后同一条单据两次跑到不同的分支。解决办法是在发布前做冲突检测：把所有规则的条件下拉成区间，两两求交集，交集非空且优先级相同就拒绝发布。

下面这张表是差旅报销自动通过的一个简化版决策表，可以直接照着填：

兜底规则一定要有，我见过太多表漏配兜底，结果条件都不命中，系统直接抛异常，单据卡在中间态。

3.2 评分卡与阈值：分数怎么算、阈值怎么定

规则能覆盖大部分场景，但总有一些"感觉不太对但说不上哪里不对"的单子，这时候需要评分卡。我常用的四个维度是：金额偏离度、历史违规次数、供应商风险、提交时间异常。每个维度先归一化到 0 到 1，再加权求和。

具体算法可以这样定：金额偏离度取"本次金额 / 同岗位同事项近 90 天均值"，超过 2 倍记 1 分，1 到 2 倍线性映射，低于 1 倍记 0；历史违规次数用1 - exp(-n/2)平滑，n 是近一年违规次数；供应商风险取黑名单比例和注册年限的加权；提交时间异常看是否在非工作时段集中提交。权重我一般设成 0.35、0.3、0.25、0.1，这个分配不是拍脑袋，是拿历史样本做过逻辑回归之后按系数绝对值归一化得来的，换业务场景要重新拟合。

阈值的定法更值得说。设自动通过阈值为 T，超过 T 自动通过，低于 T 转人工。这里有个成本权衡：误放行一单的平均损失记为 C1，人工复核一单的成本记为 C2。假设日均单量 5000，人工复核成本 8 元一单，误放行平均损失 400 元一单。如果 T 设得太低，自动通过率上去了，但误放行率也上去了。拿验证集跑一遍能画出曲线：T=0.6 时自动通过率 62%，误放行率 1.8%，期望成本是5000 × (0.38 × 8 + 0.62 × 0.018 × 400) ≈ 5000 × (3.04 + 4.46) ≈ 37500元；T=0.75 时自动通过率 45%，误放行率 0.5%，期望成本是5000 × (0.55 × 8 + 0.45 × 0.005 × 400) ≈ 5000 × (4.4 + 0.9) ≈ 26500元。这个例子里 0.75 更划算。算完这一步，再结合人工产能上限做二次修正——如果人工一天只能处理 2000 单，那自动通过率就不能低于 60%，阈值得往回调。

3.3 AI辅助节点的四种务实用法

我在实际项目里用得比较稳的是四类。第一类是OCR字段抽取，重点不是识别率多高，而是要有字段级置信度，低于阈值就回退到人工录入，并且把原图和识别框一起展示出来，让人一眼能核对。第二类是事项文本分类，把自由填写的事由归到标准类别，用来决定走哪条审批链路，这类任务用轻量模型就够，关键是给一个"其他/不确定"的出口，别硬分。第三类是相似历史案例召回，把当前单据的向量和历史上已审批的单据做相似度检索，把人家的审批意见和当时的处理方式推给当前审批人，这个功能对提升审批一致性特别有效。第四类是异常检测，用金额、频次、时间的分布做离群判断，只做提示不做拦截。

提示：OCR 这类感知层能力，一定要做"字段级降级"。整张图识别失败和某个字段识别失败是两回事，前者转人工整单录入，后者只让人补那一个框，体验差别非常大。

3.4 人机协同：AI给建议，人做决定

界面上我给的建议卡片包含四样东西：建议结论、支撑理由、置信度、一键采纳按钮。理由必须是自然语言加可点击的证据链接，比如"该供应商近半年有 2 次延迟交付记录，点击查看"。只给结论不给理由的模型输出，审批人是不会用的，用了也不敢担责。

这里有个心理学上的坑叫自动化偏见：一旦界面上出现"建议通过"，审批人点通过的比例会显著上升，哪怕理由并不充分。我的应对是，对于模型置信度处于中间区间的单据，不显示倾向性结论，只显示风险点和历史对比，把判断权真正交回去。另外，人工修改的每一条记录都要回流成样本，标注"人工最终结论"和"修改原因"，这批数据是后续迭代模型最值钱的东西，比任何公开数据集都贴近真实分布。

4. 实操过程：从0到1搭一个可运行的最小闭环

4.1 表结构设计

最小闭环需要五张表：审批实例、审批任务、规则配置、决策日志、证据附件。核心字段如下，可以直接拿去改。

CREATE TABLE approval_instance ( id BIGINT PRIMARY KEY, biz_key VARCHAR(64) NOT NULL COMMENT '业务唯一键，用于幂等', biz_type VARCHAR(32) NOT NULL COMMENT '事项类型', applicant_id BIGINT NOT NULL, org_id BIGINT NOT NULL, amount DECIMAL(18,2) NOT NULL COMMENT '金额统一用DECIMAL', status TINYINT NOT NULL COMMENT '0草稿 1审批中 2通过 3驳回 4撤回', rule_version VARCHAR(32) NOT NULL COMMENT '提交时锁定的规则版本', created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, UNIQUE KEY uk_biz (biz_type, biz_key) ); CREATE TABLE approval_task ( id BIGINT PRIMARY KEY, instance_id BIGINT NOT NULL, node_code VARCHAR(64) NOT NULL, assignee_id BIGINT NOT NULL, task_status TINYINT NOT NULL COMMENT '0待办 1已办 2超时 3转办', due_at DATETIME NULL, finished_at DATETIME NULL, KEY idx_assignee (assignee_id, task_status) ); CREATE TABLE decision_log ( id BIGINT PRIMARY KEY, instance_id BIGINT NOT NULL, rule_version VARCHAR(32) NOT NULL, input_snapshot JSON NOT NULL COMMENT '决策输入快照', output_result JSON NOT NULL COMMENT '决策输出', cost_ms INT NOT NULL, created_at DATETIME NOT NULL );

金额字段用 DECIMAL 而不是 DOUBLE，这是常识但每年都有人栽。biz_key上加唯一索引是幂等的第一道闸门，重复提交直接靠数据库拦住，比在应用层查一遍再插入可靠得多。rule_version在提交时锁定，保证同一张单据在流转过程中不会被新规则影响，这一点在事后回放时非常关键。

4.2 决策执行的核心代码

决策部分我写成纯函数，输入上下文，输出结果，不碰数据库，方便测试和影子回放。

from dataclasses import dataclass from decimal import Decimal @dataclass class DecisionContext: biz_type: str amount: Decimal violation_count: int supplier_risk: float submit_hour: int @dataclass class DecisionResult: action: str # auto_pass / manual / reject / escalate score: float hit_rule: str reason: str def evaluate(ctx: DecisionContext, rules: list, threshold: float) -> DecisionResult: # 1. 按优先级排序后首次命中 for rule in sorted(rules, key=lambda r: r.priority): if not rule.matcher(ctx): continue if rule.action in ("reject", "escalate"): return DecisionResult(rule.action, 1.0, rule.code, rule.reason) break # 命中可继续打分的规则，跳出走评分 # 2. 评分卡，权重来自离线拟合 score = ( 0.35 * normalize_amount(ctx.amount) + 0.30 * smooth_violation(ctx.violation_count) + 0.25 * ctx.supplier_risk + 0.10 * (1.0 if ctx.submit_hour in (0, 1, 2, 3, 4, 5) else 0.0) ) action = "auto_pass" if score >= threshold else "manual" return DecisionResult(action, round(score, 4), "SCORE_CARD", f"综合评分 {score:.2f}") def smooth_violation(n: int) -> float: import math return 1 - math.exp(-n / 2)

这里有个细节值得说：命中拒绝类规则后直接返回，命中通过类规则后不直接返回而是继续走评分卡，这样高风险的单子不会被一条宽松的金额规则放过去。规则的顺序和短路逻辑是决策表正确性的核心，写错一个break位置，可能导致整批单据误放行。

4.3 流程编排的关键工程细节

流程这块，我要求团队必须处理四件事：幂等、重试、超时、一致性。幂等靠业务唯一键加去重表；重试针对的是外部回调，指数退避，最多五次，超过进死信队列人工介入；超时靠一个定时扫描任务，扫出due_at已过且状态待办的任务，自动转办或者提醒；一致性最容易出事，流程推进和业务状态更新必须有一个明确的先后，我的做法是先落业务状态、再推进流程，中间用本地消息表兜住，流程推进失败可以由补偿任务重放。

注意：撤回和退回这两个操作是状态机的重灾区。撤回只允许在下一节点未处理前发生，退回要区分"退回到发起人"和"退回到上一节点"，这两者的状态迁移路径完全不同，一定要在状态机里显式定义，不要用"状态回滚"这种偷懒写法。

4.4 灰度上线与回滚策略

规则上线绝对不能全量直发。我的节奏是三步：第一步影子模式，新规则在旁路跑，只记录结果不生效，跑三天，对比新旧规则的判定差异率，差异超过 15% 就先查原因；第二步小流量，按单据 ID 哈希取 5% 走新规则，观察一周的自动通过率、人工复核率、驳回率三个指标有没有异常波动；第三步逐步放量到 25%、50%、100%。每一步都要保留一键回滚的能力，回滚不是重新发布旧规则，而是把规则版本指针切回去，秒级生效。

5. 常见问题与排查技巧实录

5.1 常见问题速查表

5.2 几个踩过的坑

坑一：用浮点数算钱。早期用 double 存金额，0.1 加 0.2 得到 0.30000000000000004，累计到几千条单据之后，汇总报表和明细差了几毛钱，财务那边直接打回来。后来全链路改成 DECIMAL，数据库、代码、前端三处统一精度，舍入规则统一成四舍五入，问题才彻底消失。这件事教会我，金额相关的字段在数据模型评审时就要单独列出来过一遍。

坑二：审批人离职导致单据永久挂起。组织架构里的人员状态没同步，任务派给了一个已离职账号，待办列表里看不见，超时扫描又只提醒不转办。后来加了两道保险：一是任务创建时校验审批人状态，不合法就走上级代理；二是超时扫描发现连续两次提醒无响应，自动转给该节点的备选审批人。

坑三：时区导致跨天判断错误。提交时间异常这个特征用的是服务器本地时间，而业务方看的是另一个时区，结果一批正常时段的单子被标记成凌晨提交。所有涉及时间的判断统一存 UTC，展示层再转本地时区，这个约定写进了开发规范。

坑四：规则优先级配错导致全量转人工。有一次运营把一条兜底规则的优先级从 90 改成了 5，结果所有单据第一跳就命中兜底，自动通过率瞬间归零，人工队列直接爆掉。后来加了发布前的冲突检测和优先级合理性校验，兜底规则的优先级锁定不可编辑。

提示：所有跟"钱、人、时间"相关的字段，都值得在评审会上单独拎出来确认一遍精度、时区和空值处理。这三类问题的修复成本远高于预防成本。

6. 性能、权限与审计的落地细节

6.1 性能预算怎么算

审批系统的流量特征非常明显：日均单量不算大，但集中在上班后的两三个小时。假设日均 5 万单，上午九点到十一点占 40%，也就是 2 万单在两小时内完成，平均 2.8 QPS。但审批系统不是均匀到达，提交往往跟着业务动作批量触发，所以要乘一个 5 倍的峰值系数，实际按 15 QPS 设计，再留一倍余量按 30 QPS 压测。

单次请求的耗时预算这样分：接入和鉴权 10 毫秒，单据校验 20 毫秒，决策执行 50 毫秒，落库和发事件 30 毫秒，总计控制在 110 毫秒以内，P99 不超过 200 毫秒。决策执行这 50 毫秒是大头，所以规则集要按事项类型分组加载，不要每次全量遍历；表达式编译结果缓存起来；对高频查询的组织架构、预算余额做本地缓存加短 TTL。压测的时候特别要关注规则条数从 50 条涨到 200 条时的耗时曲线，很多系统在这个区间会出现非线性劣化。

6.2 权限模型怎么设计

审批系统的权限分两层：功能权限和数据权限。功能权限用标准的角色模型，比如发起人、审批人、财务复核、管理员，每个角色能访问哪些菜单和接口。数据权限才是真正麻烦的地方，同一个人看不同的单据，可见范围不一样——自己提交的全可见，本部门的看摘要，跨部门的只能看统计。我的做法是在查询层统一注入数据范围条件，范围由"组织树 + 金额区间 + 事项类型"三者组合决定，配置成策略表，避免在每段 SQL 里手写过滤条件。

审批人寻址是另一个容易出问题的点。常见的寻址方式有四种：指定人、角色、主管链、发起人自选。主管链要处理代理、兼职、跨部门汇报这些边界情况，我的经验是把寻址逻辑单独抽成一个服务，输入是节点定义和单据上下文，输出是审批人列表，找不到人时按"上级代理 → 节点管理员 → 系统兜底池"三级降级，绝不返回空。

6.3 审计留痕：能回放才叫留痕

审计这件事，很多系统做到"记录操作日志"就停了，但真正出事的时候，你需要的是完整回放：当时输入是什么、用的哪版规则、哪版模型、中间每个判断的输出是什么、谁在什么时间改了什么。所以我在决策日志里存的是输入快照加输出快照，而不是只存一个结论。快照的字段要做裁剪，只留决策实际用到的字段，避免日志表膨胀。

存储上，决策日志按月份分区，热数据保留三个月在线，冷数据归档到对象存储，保留期按业务要求定。日志本身要防篡改，可以用哈希链的方式，每条日志带上一条的哈希，定期做完整性校验。这套东西平时看不出价值，一旦有争议单据要复盘，能不能在十分钟内把整条链路还原出来，就是系统成熟度的分水岭。

我在实际项目里最深的一个体会是，智能审批系统的复杂度从来不在"智能"上，而在"边界"上——规则和流程的边界、人和机器的边界、实时和补偿的边界。把这些边界划清楚，哪怕模型暂时不上，系统也能跑得很稳；边界划不清楚，模型再准也是一地鸡毛。所以如果让我给正在起步的团队一句建议，那就是先把规则版本化、决策可回放、流程可补偿这三件事做扎实，剩下的智能，慢慢加都不迟。