JVS-Rules规则引擎视角：工厂里最该灵活的东西，偏偏被写死在代码里
说个制造业里特别常见但又特别让人窝火的事。
某电子制造企业的品质部，质检判定标准是按客户来的。A客户的允收标准是一个样，B客户是另一个样，而且每个客户隔三差五就会更新标准。
这些判定逻辑，被开发人员写进了质检系统的代码里。
结果就是——每次客户更新标准，品质部就得提需求给IT，IT排期开发、测试、上线。一个简单的判定条件修改，快的话一周，慢的话一个月。品质部的同事经常吐槽："客户今天改的标准，我们下个月才能用上。中间这段时间，全靠人工记忆和Excel表格兜着。"
这不是个案。几乎所有制造业企业的系统里，都藏着大量"写死在代码里"的业务规则。
而这些规则，恰恰是制造业日常运营中最需要灵活调整的部分。
一、制造业的业务规则，远比想象中复杂
先盘点一下，工厂里到底有多少业务规则在"裸奔"。
1. 质检判定规则
不同产品、不同客户、不同缺陷类型，对应的判定标准完全不同。有些是简单的"超差即不合格"，有些是多维度的综合判定——比如外观缺陷在A级产品中是致命缺陷，在C级产品中可能只是轻微缺陷。
再加上客户经常更新标准，这套规则的变化频率远超想象。
2. 报价与定价规则
原材料价格波动、客户等级、订单量阶梯、交期要求、运输距离……报价涉及的因素太多了。这些因素的交叉组合形成了一套复杂的计算规则，而且随着市场行情变化，规则本身也在不断调整。
3. 工艺参数校验规则
不同产品规格对应不同的工艺参数范围。温度上限多少、压力区间多少、转速范围多少——这些参数组合起来，构成了一个庞大的校验矩阵。产品型号一多，规则量就是指数级增长。
4. 预警与升级规则
设备温度超过某个阈值触发一级预警，超过另一个阈值触发二级预警甚至停线。不同设备、不同工序的预警规则不同。而且随着设备老化或工艺优化，这些阈值需要动态调整。
5. 排产约束规则
哪些产品不能在同一台设备上连续生产（换模成本太高）、哪些订单必须优先排（客户等级或交期约束）、哪些工序之间有先后依赖关系……这些约束条件构成了排产的核心规则体系。
这些规则有一个共同特点：数量多、变化快、逻辑复杂、且业务人员最清楚规则该怎么定。
但当它们被写死在代码里的时候，业务人员就成了"看客"——明知道规则该怎么改，却没有能力自己动手，只能等IT排期。
二、"写死在代码里"的代价
规则被硬编码在系统里，表面上看"也能用"，但代价是隐性的、长期积累的。
1. 响应速度跟不上业务变化
前面说了，一个简单的质检标准修改，走开发流程可能需要一两周。但在竞争激烈的制造业，客户给你一两周的响应窗口？很多时候，系统还没改好，业务已经用别的办法（手工表格、人工记忆）顶上去了。系统里的规则跟实际执行的规则脱节，数据准确性就出了问题。
2. 维护成本不断膨胀
代码里的规则越堆越多，时间一长，连开发人员自己都搞不清楚某条规则为什么存在、对应什么业务场景。老开发人员离职了，新来的人更不敢动——"这段代码不知道谁写的，但一直在跑，别碰它。"
这就是所谓的"代码腐化"。规则越堆越复杂，维护成本越来越高，但谁也说不清到底哪些规则还在生效、哪些已经是"僵尸代码"。
3. 业务人员和IT之间反复扯皮
业务说"这个规则早就该改了"，IT说"你提需求了啊，我在排期"。业务说"这个逻辑很简单，改一下不就行了"，IT说"没那么简单，涉及好几个模块的联动"。
这种沟通消耗，每天都在发生。根源在于：业务规则的变更，不应该走"系统开发"的流程，而应该走"规则配置"的流程。但规则写在代码里，就没有"配置"这个选项。
4. 规则的执行无法审计追溯
代码里的规则，执行结果可以查到，但"为什么这样判定"往往没有清晰的解释。出了问题要回溯的时候，需要开发人员去翻代码、查逻辑，效率极低。
在制造业的质量合规场景中，这一点尤其致命。客户来审核，问你"这批产品的判定依据是什么"，你总不能回答"请给我们开发人员三天时间查代码"。
三、规则引擎解决的核心问题
说白了就一句话：把业务规则从代码里抽出来，变成可以独立配置、独立管理、独立生效的"规则"。
业务人员在可视化界面上配置规则，配置完直接生效，不需要走开发流程。
听起来简单，但要做到好用，需要解决几个关键问题。
1. 可视化配置——让不懂代码的人也能配规则
规则引擎的配置界面必须足够直观。业务人员不需要理解什么是"代码"、什么是"编译"，他们只需要在界面上做选择、填数字、设条件。
常见的配置方式包括：
- 决策表：类似Excel表格，行是条件组合，列是输出结果。业务人员一看就懂。
- 决策树：树状结构，从根节点到叶节点，每一步是一个判断条件。适合层级化的判定逻辑。
- 评分卡：每个因素赋予一定分值，总分决定最终结果。适合风险评估、客户分级等场景。
这些方式都应该是"拖拽+填表"式的操作，而不是写代码。
2. 规则版本管理——改错了能回滚
业务规则会频繁调整，这就需要一个"版本管理"机制。谁在什么时候改了什么规则、改之前是什么版本、如果改错了怎么回滚——这些都需要清晰记录。
就像代码有Git一样，规则也需要有自己的版本控制。
3. 规则测试——配置完能先验证再上线
规则配好了，不能直接上生产。需要有个"测试环境"，拿历史数据跑一遍，看看新规则的输出跟预期是否一致。
尤其是质检判定这种影响大的规则，新规则上线前必须用历史数据做充分验证，确保不会出现"误判"或"漏判"。
4. 规则与系统的解耦——改规则不用动系统
规则引擎作为独立的组件，跟业务系统（质检系统、ERP、MES等）通过接口对接。系统负责数据采集和结果展示，规则引擎负责逻辑判断。两边各司其职。
这样一来，换一套规则不影响系统运行，升级系统也不影响规则逻辑。耦合度降下来，灵活性才能上去。
5. 执行记录可追溯——每条判定都有据可查
规则引擎执行每条规则时，应该完整记录：输入了什么数据、命中了哪条规则、为什么得出这个结果。
在质量审核、客户验厂、合规检查等场景中，这种可追溯性不是"锦上添花"，而是"必须有"。
四、制造业上规则引擎，从哪个场景开始
1. 先挑"变化最频繁"的规则
比如质检判定标准——客户经常改，IT疲于应对，业务人员苦不堪言。把这类规则迁移到规则引擎上，效果立竿见影。
2. 再挑"逻辑最复杂"的规则
比如报价计算——涉及十几个变量的交叉组合，用代码写出来又长又难维护。用决策表的方式呈现，业务人员一目了然，修改起来也方便。
3. 最后做"跨系统的统一规则中心"
当多个系统都需要用到同一套规则时（比如质检和售后都可能用到同一套缺陷判定标准），用规则引擎做统一管理，避免不同系统里的规则"各自为政"。
五、结语
制造业的系统里，到底有多少业务规则被写死在代码里？
可能比大多数人想象的要多得多。而每一条被写死的规则，都意味着一次潜在的响应延迟、一次沟通损耗、一次业务和IT之间的拉扯。
规则引擎的价值不在于它有多"高级"，而在于它解决了一个很朴素的问题：让业务规则回归业务人员手中。该改就改，改完就生效，不用等排期、不用改代码、不用走流程。
在制造业这个变化越来越快的时代，"灵活"本身就是一种竞争力。