第 13 章：流程审批：制度化的人机协同
13.1 工程问题的本质：把决策权制度化
许多业务操作不是一次调用，而是一条审批流程：发起 → 字段收集 → 逐级审批 → 业务生效。审批的工程本质是把"该由谁、在什么条件下、以什么顺序决策"制度化——不是临时找一个领导签字，而是把决策责任、决策顺序、决策记录固化为可执行的流程。
设计原理： 流程制度化的三个要件：状态可追踪（流程进行到哪一步）、迁移有守卫（每一步由谁批准、前提是否满足）、全程可追溯（谁在何时做了什么决定）。三者分别对应状态机、链式 Gate、签字留痕。
13.2 定义与实例分离：改流程与跑流程互不干扰
流程定义（审批链、必填字段、时限、守卫条件）存储在配置表，流程实例（运行态）存储实例表。定义可训练、实例不可回改。
原理： 定义与实例分离解决"改流程"与"跑流程"的冲突：线上进行中的流程不能被中途改变规则（实例不可回改），新流程按新定义执行（定义更新影响后续实例）。这保证了审批的确定性——用户在发起流程时看到的规则，就是审批时执行的规则。若定义与实例耦合，审批结果将无法预期。
13.3 三道发起校验：谁可以发起
流程发起前执行发起者三道校验：角色（starter_roles）、部门（starter_depts）、启动方式（initiation，manual/event/auto）。
原理： 审批流程的资源是"决策注意力"，发起门槛决定决策注意力的分配效率。三道校验是准入控制：不是所有人都有权发起所有流程（角色/部门），也不是所有发起方式都被允许（自动化触发的流程与人工发起受不同约束）。发起即决策链的起点，起点不可控则整链不可信。
13.4 链式 Gate：迁移守卫
每一步推进前校验 5 维前序完整性：前序审批签字、必填字段、关联实体状态、时间窗口、SOD 隔离（审批者与发起者非同一人）。
原理： 链式 Gate 回答"这一审批动作是否具备合法性前提"。它模拟人工审批的实践——接手者检查前序完整性：上一步真的批了吗？该带的数据齐了吗？被审的实体状态对吗？超时了吗？自己和发起者是不是同一个人？守卫缺失时，审批就会在错误前提上做决定——例如"图纸还没生效就审批通过"，或"审批人自己发起又自己审批"。
条件表达式无法解析时视为必需（保守策略）：守卫不确定时，宁可信其有。
13.5 签字留痕：决策的不可抵赖
每次推进记录审批人、角色、时间与动作，形成审批签字链。对话中的流程：字段收集阶段跨轮收集必填字段，待审批阶段"同意"推进审批、留言补充上下文。
原理： 签字留痕使审批从"一次操作"变为"一份记录"。每一签都是一次责任声明——谁、在何时、基于什么数据、批准了什么。流程单据的展示（申请字段 + 审批签字链）使"谁在何时审批"随时可查，这是审批结果可被业务系统采信的前提。留言机制则支持多人协作中的信息补充，且明确留言为过程性数据、不进入知识库。
13.6 治理之治理：审批链本身可训练
审批链本身可训练：流程定义的训练（新建/修改流程）同样走审批链，训练审批链来自该流程类型的定义行（可训练），无定义兜底 manager 单级。
原理： 若治理规则本身不可治理，治理就会被绕过——业务方可以直接改审批链绕过审批。治理之治理保证：修改审批规则的权力本身也受审批约束。这一递归在何处停止？在硬规则处停止——SOD 与硬规则不可训练（第 12 章），构成递归治理的地基。
13.7 工作流模式与审批完整生命周期
13.7.1 工作流模式：流程不止顺序
简单的审批链是线性顺序，但真实业务需要更丰富的流程形态。工作流领域沉淀了一批通用模式（process patterns），其思想可指导流程定义的设计：
| 模式 | 语义 | 在框架中的对应 |
|---|---|---|
| 顺序（Sequence） | 步骤逐一执行 | 审批链逐级推进（默认形态） |
| 并行分叉（Parallel Split） | 一步拆为多路并行 | 多审批人同步骤审批 |
| 同步汇合（Synchronization） | 多路完成后才继续 | 链式 Gate 前序签字全齐才推进 |
| 多选（Multi-choice） | 条件满足才执行某支 | 条件式守卫（amount>500000 才需第二级） |
| 回退（Redo / Loop） | 流程回退到前序步骤 | 审批驳回后流程重回字段/上一级 |
原理： 工作流模式的工程价值是"用已沉淀的形态表达流程，而非每次发明"。模式提供了命名与语义——团队沟通"这一步是并行分叉"比"这一步要让两个人同时看"更精确；模式也提供了实现检验——"同步汇合"必须有汇合条件（前序全批），否则就是错误实现。框架的链式 Gate 守卫（前序签字全齐）正是同步汇合模式的正确定义。
13.7.2 审批完整生命周期：推进之外的动作
审批不止"同意推进"，完整生命周期还包括：
| 动作 | 语义 | 设计要求 |
|---|---|---|
| 同意（approve） | 当前步骤通过 | 角色校验 + 前序守卫 + 签字留痕 |
| 驳回（reject） | 否决当前步骤 | 须明确拒绝理由，流程回到前序或终止 |
| 留言（comment） | 补充上下文，不改变状态 | 过程性数据，不进入知识库 |
| 撤回（recall） | 发起人撤销未完成流程 | 仅在未推进到终态前允许，须留痕 |
| 超时处理（timeout） | 超过时限未审批 | 链式 Gate 时间窗口守卫，超时即阻断/升级 |
原理： 审批生命周期不完整，会导致"只能前进不能后退"的僵化流程——业务上一旦出现错误审批或信息遗漏，没有出口。驳回、撤回、留言、超时四类动作补全了流程的可逆性与可解释性：可逆（错误可纠正）与可解释（每个动作留痕）。设计检验：流程定义应显式声明每个动作的权限与结果状态——哪些角色可驳回、驳回后回退到哪一步、超时如何处理，都应可配置而非隐式。
13.8 失败模式与权衡
| 失败形态 | 根因 | 设计应对 |
|---|---|---|
| 审批在错误前提上决定 | 前序未批 / 数据缺失 | 链式 Gate 5 维守卫 |
| 单人闭环舞弊 | 审批者即发起者 | SOD 隔离校验 |
| 流程定义中途变化 | 定义与实例耦合 | 定义/实例分离，实例不可回改 |
| 审批推进无通知 | 通知链路断裂 | 事件总线解耦（见 16.4 节） |
权衡： 审批的确定性以"流程更慢"为代价（逐级、逐守卫）。框架的调节手段：字段收集的引导语、审批链步数与角色均可训练——业务方在"效率"与"制衡"之间拥有调节权，但调节本身受治理约束。
13.9 本章小结
- 审批的工程本质是把决策权制度化：状态可追踪、迁移有守卫、全程可追溯；
- 定义与实例分离保证审批规则的确定性；
- 三道发起校验是决策链起点的准入控制；
- 链式 Gate 的 5 维守卫防止在错误前提下决策；
- 治理之治理使审批规则本身受审批约束，递归止于硬规则。