基于阈值的路由：实现灵活审批规则

为什么硬编码的审批规则会失效

硬编码的审批规则一开始看起来没问题。开发人员添加了几条条件，工作流开始运行，团队继续进行其他工作。

问题在于业务发生变化时会显现出来。财务提高了支出限额，某个地区实施了不同的政策，或某个部门需要对特定请求增加审批人。看似小的更新现在意味着要修改应用逻辑、进行测试并等待发布。

这种延迟代价很高。本应几分钟完成的策略更新，当它依赖技术工作时可能要花费几天。在此期间，员工按旧规则执行，审批停滞，经理通过电子邮件或聊天处理例外。

隐藏的例外会让情况更糟。随着时间推移，团队会添加一次性规则，例如“如果金额超过 5,000 且部门为 Sales，则发给 Director A”或“如果请求来自欧洲，则跳过此步骤”。当这些规则深藏在工作流中时，只有少数人能看到它们。

于是简单的问题变得难以回答：

• 谁批准超过某个金额的采购？
• 市场部和运营部遵循相同的政策吗？
• 另一个地区会怎样处理？
• 上个季度添加了哪个例外？

当没人能看到完整的规则集时，错误便随之而来。有人以为自己遵循了政策，但应用仍在使用旧规则。新的经理会看到本不该由他们处理的请求，而真正的审批人被排除在外。

这就是为什么在审批策略经常变化时，基于阈值的路由更有效。与其把规则当作应用的固定部分，不如将它们存为可审阅和更新的业务数据。

想象一条简单的差旅报销政策：1,000 以下的请求交给团队组长，1,000 到 10,000 的请求交给部门主管，超出部分交给财务。如果这些限制在下个月变化，业务不应为了保持审批流转而必须找开发人员。

把策略写死会把普通的政策更新变成软件项目。这才是真正的成本。

基于阈值的路由意味着什么

基于阈值的路由意味着审批路径根据你事先定义的值发生变化。阈值只是一个边界，例如金额超过 $1,000、来自财务部的请求，或在欧洲发生的采购。

你不把这些规则直接写进应用，而是将它们存储在表格中。工作流读取表格，找到匹配的规则，并将请求发送给正确的人。

一个基本设置可能像这样：

• $500 以下的请求发给团队组长。
• $500 到 $5,000 的请求发给部门经理。
• $5,000 以上的请求发给主管。
• HR 请求走一条路径，IT 请求走另一条。
• 北美和 EMEA 可以有不同的审批人。

流程保持不变，但控制它的数值可以变化。

将逻辑与策略分离

这是关键思想。逻辑是那部分会说“检查规则并选择第一个匹配项”。策略数据是规则本身：金额区间、部门、地区、审批人和优先级。

当逻辑和策略混在一起时，即使是小变更也可能需要开发人员去修改工作流。分离后，工作流保持稳定，只有规则行在变更。

例如，如果 APAC 的销售现在在 $3,000 以上需要主管审批（而不是 $5,000），你只需更新表中的一条记录，而不是重建整个审批流程。

这更易于管理，因为策略的变动频率通常高于流程结构的变动。团队重组、预算调整和地区负责人变更都更适合用表来处理，而不是硬编码条件。

在像 AppMaster 这样的无代码平台中，这通常意味着创建一个规则表，并让业务流程在运行时检查它。这个模型对非技术团队也很容易理解，因为它与现实中书写政策的方式一致：如果匹配此条件，就发到这里。

你的规则表应该包含什么

一个好的规则表应该能回答一个简单问题：当请求满足这些条件时，谁需要审批？

如果路由依赖于隐藏在代码中的值，每次策略更新都会变成重建。表格让这些变更可见且易于管理。

实用的规则表通常以描述请求的字段开始：

• amount（金额）
• currency（货币）
• department（部门）
• region（地区）
• request type（请求类型）
• approver role（审批角色）

金额和货币重要，因为相同的数字在不同预算或国家含义不同。5,000 USD 可能走一条路径，而 5,000 EUR 或 500,000 JPY 可能需要另一条。

部门和地区反映了公司真实的运作方式。财务、HR 与运营通常即便在相同支出下也有不同的审批路径。地区也会影响审批人，当地规则或经理可能不同。

请求类型是另一个有用的过滤项。差旅、软件采购、供应商付款和折扣审批可能需要不同的审核人。没有这个字段，不相关的请求可能会使用同一条规则。

对于审批人，存储角色而不是姓名。使用诸如 Department Manager、Regional Director 或 Finance Controller 这样的值。当有人换岗时，你只需更新角色分配一次，而不是编辑每条规则。

添加开始和结束日期也很有用。这样可以覆盖某天开始生效的政策、预算季的临时规则或下季度计划的变更。你可以保留历史记录，同时避免过期规则仍然生效。

优先级字段也值得添加。例如“EU + Finance + 超过 10,000”的规则通常应胜过“所有部门 + 超过 10,000”这种更宽泛的规则。明确的优先级能保持路由可预测。

如何构建表结构

保持结构简单：一行代表一条审批规则。

如果营销在欧洲的费用超过 $2,000 需要区域经理审批，那就记录在一条记录里。每行意义明确时，设置更容易更新、测试和审计。

主表应只关注两件事：触发规则的条件和告诉工作流下一步该做什么的结果。这使业务用户和构建流程的人都易于阅读。

一个实用布局

一个清晰的表通常包含以下字段：

• 规则 ID 或规则名称
• 启用状态，以及可选的开始和结束日期
• 条件字段，例如最小金额、最大金额、部门、地区和请求类型
• 结果字段，例如审批角色、审批人或下一步操作
• 优先级和默认规则标志

对于条件列，尽量使用精确字段而非自由文本。部门 ID 比每次手动输入 “Finance” 更安全。地区代码、请求类型和成本中心同理。用于部门、地区和审批角色的小型查找表可以避免拼写错误并简化筛选。

对于结果列，决定工作流应返回什么。在一些团队中，规则应指向具体人员；在另一些团队中，应路由到角色（例如 Regional Manager 或 Finance Director）。选定一种方法并保持一致。

优先级很重要，因为可能有多条规则匹配同一请求。不要依赖行顺序或创建时间。添加一个数值优先级字段并定义其工作方式，例如 1 表示最先检查，100 表示最晚检查。

你还需要一个回退规则。这是针对未被任何特定行覆盖的情况的安全网。默认规则可以将未匹配的请求发送给运营经理或管理员审核队列。没有回退规则，某些请求可能找不到去向。

如果在 AppMaster 中构建，这些表可以可视化编辑，这样策略变更就变成了数据层面的更新，而不是硬编码的工作流分支。

如何设置

从决策而不是表格开始。写下工作流需要回答的具体问题：超过 $5,000 的采购是否需要经理审批？财务是否审查来自销售的所有事项？来自某个地区的请求是否走不同路径？

一旦这些选择明确，基于阈值的路由就容易得多，因为你是把策略存储起来，而不是在事后猜测逻辑。

一个简单设置通常遵循五个步骤。

首先，创建一个审批规则表，包含影响路由的字段。常见列包括 amount_min、amount_max、department、region、approver_role、priority 和 active_status。

第二，决定哪些字段可以留空。空的部门或地区可以表示“此规则适用于所有情况”，当没有更具体的匹配时生效。

第三，从最具体的规则到最通用的规则依次添加。一条“Sales + Europe + 超过 $10,000”的规则应在像“任何部门 + 任何地区 + 超过 $10,000”之前被检查。

第四，上线前用真实示例测试。使用边界情况，例如恰好 $5,000、缺失部门数据或某个地区没有自定义规则等。

第五，限制谁可以编辑表格。策略变更应当容易执行，但不应对所有人开放。

这里有一个简单示例。来自北美 HR 的 $12,000 请求可能首先匹配“HR 超过 $10,000”的规则，发送给 HR 总监。如果不存在 HR 专属规则，系统可以回退到更宽泛的规则，例如“任何部门超过 $10,000”，将其发送给财务。

顺序比许多团队预期的更重要。如果宽泛规则放在特定规则之上，错误的人会收到请求，人们会失去对系统的信任。

上线前为规则变更指定一名负责人，保留一份简短的策略文档，并在每次更新后再次测试。小的路由变更可能产生大影响。

一个简单的实际例子

想象一家公司使用同一个采购请求表单供所有团队使用。每个请求包含金额、部门和地区。系统将这些值与规则表进行比对并选择合适的审批人。

假设公司有两个部门：Marketing 和 IT。两者都可能提交 $4,000 的请求，但审批路径不必相同。

现在比较两个相同金额的请求。美国地区的 Marketing 的 $4,000 请求会发给 Marketing Manager。而美国地区的 IT 的 $4,000 请求因为 IT 的阈值更低，会跳过 IT Manager，直接发给 CTO。

地区也会改变结果。美国的一条 $2,500 Marketing 请求会发给 Marketing Manager，但同样金额在欧盟会发给 Regional Marketing Lead。表单保持不变，只有匹配的规则在变化。

这就是规则表的真正价值：策略存在于数据中，而不是工作流逻辑里。

如果公司在下个月更新策略，你无需重建整个流程。例如 IT 决定现在 $2,000 以上的请求交给 CTO，你只需编辑一行：

• 旧规则：IT, US, $3,001+, CTO
• 新规则：IT, US, $2,001+, CTO

其他一切继续正常。新请求会立即遵循新政策，而应用结构保持不变。

常见的错误要避免

基于阈值的路由最难的部分往往不是核心思路，而是后来出现的那些混乱的边界情况，当策略变更且没人记得为什么某个请求流向了错误的人时问题就出现了。

一个常见错误是存在重叠规则却没有明确的优先级。你可能有一条规则将所有 Marketing 超过 $3,000 的请求发给部门主管，另一条规则将任何超过 $5,000 的请求发给财务。$6,000 的 Marketing 请求会同时匹配两条规则，系统需要一个明确的胜出者。把优先级放在规则表中，而不是隐藏在工作流逻辑里。

另一个错误是把具体人写死在规则里而不是角色或小组。姓名会变，团队会变，某人休假或调岗。如果规则写着“发给 Maria Lopez”，每次人员变动你都要编辑规则。将审批路由到角色（比如 Regional Finance Manager 或 Sales Director），然后把角色映射到当前人员，会更安全。

缺少回退路径会导致静默失败。迟早会有请求因为金额异常、部门是新建的或字段为空而不匹配任何规则。那时，工作流仍应有安全措施，比如发到默认队列或管理员团队。

地区例外也是薄弱环节。一种在某国有效的政策，在另一国可能因当地支出限额、税务规则或报告需求而不适用。如果你只测试了一个地区，可能会漏掉 EU、US 或 APAC 应该走不同路径的情况。

基于时间的规则也容易被忘记。如果你为季末、预算冻结或专项项目创建临时规则，请确保它有开始和结束日期。过期规则应自动停止生效，否则旧例外会继续存在并把请求导向错误路径。

上线前的最终检查

在启用基于阈值的路由前，从真实用户的角度审查一遍。每个请求都应到达正确的审批人，且不需要任何猜测。

保持最终审查的简洁性。

检查每个常规请求是否只有一条明确的匹配规则。如果两条规则同时适用，用户将得到不一致的结果。

确保存在回退路径。缺失的部门、新的地区或异常金额应仍能被发送到安全的地方。

确认策略更新可以在不依赖开发的情况下进行。如果财务或运营需要更改限额、日期或审批人，他们应能在表中编辑记录，而不是申请代码更改。

测试生效日期，而不仅是数值。昨天的政策和下个月生效的政策在生效日期设置正确时都应表现如预期。

用简明语言在一页上书写路由逻辑。如果经理无法清楚解释，大概说明太复杂了。

一个有用的最终测试是创建五个示例请求，覆盖正常情况、边界情况和过期政策情况。如果团队在运行前能预测结果，说明设置很可能已准备好；如果不能，就应该简化规则。

下一步

从小处开始。选择一个今天造成最多延迟或混乱的审批流程，例如一定金额以上的采购请求或按部门的费用报销。先构建该流程，使用真实案例测试，然后再加入更多规则类型。

这种方法能让路由模型更值得信赖。人们可以看到规则如何工作、例外出现在哪里以及在设置扩展前需要改什么。

第一次上线应回答四个基本问题：

• 优先自动化哪种请求类型？
• 哪些字段控制路由，例如金额、部门或地区？
• 目前谁在审批每种情况？
• 当策略变更时谁来更新规则？

最后一点非常重要。如果没人明确负责策略更新，工作流会慢慢偏离实际业务运作。指定一名或一个小团队负责审查规则变更、批准编辑并记录策略变更原因。

同时，设定审查计划也很有帮助。如果策略经常变化，建议每月审查；如果流程稳定，季度审查即可。一次简短的审查可以在旧阈值、缺失部门或地区例外导致延误前发现问题。

让审查保持实用。问几个简单问题：审批是否到了正确的人手中？是否有团队结构变动？当前限额是否仍符合财务政策？是否存在过多的人工覆盖？

如果你想可视化构建，AppMaster 很适合创建规则表、路由流程和供非技术人员更新策略的管理界面。由于它为完整的无代码应用设计，当业务团队希望直接管理审批变更而不是每次都找开发时，它会很有用。

当一个流程运行良好后，在下一个流程中复用相同模式。小而清晰的步骤通常比一次性重构更有效。