数字化工厂物料齐套高效模型：口径、算法与工程落地

1. 先把“齐套”这件事说透：它到底在算什么

做数字化工厂这几年，我被问得最多的问题不是MES怎么上、看板怎么做，而是“为什么计划排得好好的，一到上线就缺件停线”。追到根子上，几乎都指向同一个词——物料齐套。齐套率这个指标看起来简单，就是把“要的”和“有的”对一对，但真正落到系统里，它牵扯的是主数据、BOM、库存、在途、工单、替代料、共用料这一整条链路。我见过太多项目，看板上齐套率常年92%以上，车间却天天在找料，原因不是算错了，而是算的根本不是同一件事。

这篇内容我想聊的是物料齐套高效模型，也就是在数字化工厂的语境下，怎么把“某个工单/订单在某个时间点能不能开工”这件事，用一套可计算、可追溯、可预警的模型稳定地算出来。它解决的不是“有没有库存”这种表层问题，而是“这点库存到底该给谁、什么时候给、给了之后别人怎么办”的分配问题。适合三类人看：正在做MES/APS/供应链协同系统建设的产品和开发，负责生产计划与物料管控的业务骨干，以及想把工厂数据真正用起来的数字化推进负责人。哪怕你现在只会写SQL、对BOM只懂个大概，也能顺着往下看懂逻辑。

我先把一个常见误区摆出来：很多人把齐套理解成“库存大于需求”。这个判断在单工单、单物料、无共用料的理想场景下成立，一旦出现多个工单抢同一批料，或者存在替代料、在途、批次效期，这个判断立刻失效。举个我自己踩过的例子，某装配类工厂的工单A需要某型号端子3000只，库存账面上正好有3000只，系统判定齐套、放行开工。结果开工两小时后停线，因为这3000只里有2000只已经被更早交期的工单B预占，剩下1000只还是临近有效期的批次，质检不放行。系统没错，账也没错，错在于“齐套”这个词被简化成了一个比较运算，而它本质上是一个带时间维度、带优先级、带约束的资源分配问题。

所以在动手建模型之前，我建议先把三个问题回答清楚：齐套是按什么颗粒度算的（订单、工单还是工序）、供给侧的可用量到底包含哪些来源、需求侧的时间点按哪个日期卡。这三个问题不定，后面写再多代码都是返工。

1.1 齐套率的三种口径，混着用必然吵架

齐套率在工厂里是个高频词，但十个人可能有三种算法，开会时各说各的，最后变成扯皮。我一般会明确区分三种口径，并且规定每种口径只用在一个场景里。

第一种是工单齐套率，分母是计划期内的工单数，分子是完全齐套（所有物料行缺口为零）的工单数。这个口径最严格，也最贴近车间感受，适合用来考核“能不能按时开工”。它的缺点是颗粒度粗，一张工单缺一颗螺丝也算不齐套，容易让计划部门觉得冤枉。

第二种是物料行齐套率，分母是所有工单的物料需求行总数，分子是缺口为零的行数。这个口径对改善更敏感，能反映出“整体缺料面”有多大，适合做趋势监控和供应商管理。但它会掩盖关键件的影响，一张工单99行齐套、1行缺关键芯片，按行算齐套率99%，按工单算却是0%。

第三种是数量齐套率，按需求数量加权，公式是各物料行“可用量/需求量”的加权平均（权重取需求量占比），或者干脆用金额加权。这个口径适合给管理层看整体资源保障水平，但绝对不能用来判断某张工单能不能开工。

我的做法是三个都算、分场景用，但在系统里只保留一个决策口径——工单齐套，因为车间只认这个。其他两个作为辅助指标挂在分析页，避免一线和管理层拿不同数字对撞。这里有个细节：工单齐套的判定必须区分“完全齐套”“部分齐套可开工”“不可开工”三种状态，不能只有0和1。很多工厂的前段工序并不需要全部物料到齐就能干，硬按0/1判会把产能白白浪费掉。

1.2 为什么齐套是数字化工厂的“总闸门”

数字化工厂里系统一大堆，排产、执行、仓储、质量各自跑得挺欢，但只要齐套这一环算不准，上游排出来的计划就是空中楼阁，下游的看板就是自欺欺人。我习惯把齐套叫做“总闸门”，因为它是计划与执行之间唯一一个必须说真话的关口。计划说“我排了”，齐套说“料不够”，这时候要么改计划，要么追料，二选一，没有第三条路。

从影响范围看，齐套模型至少牵动四条线。第一条是交付线，齐套率每下降10个百分点，计划兑现率通常会跟着掉一截，缺件停线的工时损失会直接吃掉当月产出。第二条是库存线，齐套算不准的工厂，往往一边缺料一边高库存，因为计划不敢信系统，只能靠多备料保平安，库存周转率自然上不去。第三条是采购线，齐套模型能把缺口按供应商、按物料族聚合出来，采购才知道该催谁、催多少、什么时候必须到。第四条是线边线，齐套结果直接决定发料节奏，发早了线边堆积占地方，发晚了等着停线。

我更想强调的是它的间接价值：齐套模型是整个工厂里少数几个能把销售订单、生产工单、采购订单、库存批次这四类数据真正串起来的场景。很多工厂上了几年系统，数据还是各管一段，就是因为缺一个像齐套这样“必须跨域对齐才有意义”的业务抓手。你把这个模型做扎实了，主数据治理、BOM准确性、库存准确性这些老问题会被倒逼着解决一大半——因为齐套结果一错，问题就藏不住，谁的数据脏一目了然。

我个人的经验是，齐套模型不要一上来追求“全厂全物料实时”，那是个无底洞。先选一条产品线、一个车间，把从工单下达到齐套结果输出的链路跑通，跑三个月，把误判率压到5%以内，再往外扩。这个节奏比一次性铺开要稳得多，也更容易拿到业务部门的信任。

2. 模型的数据底座：这七类数据不干净，齐套就是空中楼阁

齐套模型说到底是个数据密集型的计算，它的输出质量几乎完全由输入决定。我见过太多团队把精力全砸在算法和前端上，结果数据源一塌糊涂，最后做出来一个“看起来很智能、用起来不敢信”的东西。这一节我把必需的数据分成七类，逐类讲清楚要什么、坑在哪、怎么校验。

先给个整体判断：齐套模型的输入可以粗暴分成骨架数据（相对静态，变更慢）和流量数据（每天甚至每小时都在动）。骨架数据错了，全盘皆错，而且很难通过事后校验发现；流量数据错了，通常表现为齐套率忽高忽低，容易被察觉。所以数据治理的优先级应该是先骨架、后流量。

2.1 主数据与BOM：齐套计算的骨架，错一层错一片

物料主数据是第一个要盯的。齐套计算至少依赖物料编码、基本单位、物料类型（自制/采购/委外/虚拟件）、是否关键件、默认仓库、批次管理标识、保质期这几个字段。最容易出事的是单位，采购单位是箱、库存单位是只、BOM用量单位是千只，三个单位换算关系只要有一个配错，齐套结果就整体偏移一个数量级。我做数据校验时有个笨办法但很有效：随机抽100个物料，把BOM用量、库存数量、采购在途三处的单位手工对一遍，错一个就全表排查。

BOM是第二个雷区，而且比物料主数据更隐蔽。多层BOM展开是齐套计算的核心动作，展开规则里几个点必须明确：虚拟件要不要穿透、委外件的料是谁的、替代料组怎么表达、生效日期和失效日期怎么卡、同一物料在不同层级重复出现时需求量是否累加。我遇到过一个典型案例，某产品的BOM里同一个紧固件在三个子装配层级都出现，系统的展开逻辑没做累加，只取了最后一层，导致需求量少算了三分之二，齐套率长期虚高，直到一次大盘点才暴露。

还有个高频问题是BOM版本与工单的对应关系。工单下达时用的是哪个BOM版本，齐套计算就必须用哪个版本，不能用“当前生效版本”去算历史工单。这个字段如果工单表里没存，后面根本补不回来。我在设计工单表时会强制要求写入BOM版本号和工艺路线版本号，哪怕当时用不上。

提示：BOM展开一定要做“展开结果快照”。每次齐套计算把展开后的物料需求行落一张表，带上计算批次号。这样后面出现争议时可以回溯“当时是按什么需求算的”，而不是拿现在的BOM去解释一个月前的结果。

2.2 供给侧与需求侧的口径统一，比算法重要十倍

供给侧要回答的问题是：到底哪些量算“可用”。库存账面数是最不可靠的一个数，我通常会把可用量拆成这么几块来算：

可用量 = 现有库存 − 已被更高优先级占用的量 − 质检冻结量 − 客户寄售/客供料 − 已发料未消耗（线边在制） + 已确认且能在需求日前到货的在途量 + 计划入库量（按可信度打折）

这个公式里每一项都有讲究。质检冻结量很多系统不单独记，混在库存里，结果算出来齐套、发料时被卡。线边已发未耗是最容易被忽略的一块，料已经发到车间但还没上线消耗，账上已经扣了，实际上还能用，如果不回冲，齐套率会偏低。在途可信度更是个技术活，采购订单上的预计到货日期往往是供应商随口给的，我一般会给在途打个折扣系数：已确认发货的按90%计入、已下单未发货的按50%计入、仅有采购申请的按0计入。这个系数可以根据历史到货准确率做校准，比拍脑袋强。

需求侧的核心是时间点。齐套判断必须挂一个日期，通常是工单的计划开工日。但光有开工日不够，还要考虑时间栅栏：物料需求日减去采购提前期，得到“最晚下单日”，超过这个日期还没下单，基本就是高风险缺口，要提前预警而不是等到齐套计算时才发现。这个逻辑做进模型后，缺口预警就能从“事后报警”变成“事前预警”，价值完全不同。

需求侧还有几个容易漏的量：损耗率（BOM里的固定损耗和变动损耗要不要计入需求）、最小包装倍数（需要1000只但只能按2000只一包买，实际占用是2000）、联副产品、试制/返工工单的额外需求。这些不在需求侧算清楚，齐套就会系统性偏乐观。

2.3 替代料与共用料：两个最容易埋雷的地方

替代料的处理难度被严重低估。业务上说的替代往往是“能用就行”，但系统必须明确替代关系是单向还是双向、是完全替代还是按比例替代、替代组内有没有优先级、替代料之间是否互斥。我见过最坑的一种情况：A可以替代B，B可以替代C，但A不能替代C，形成了一条链。如果模型只做一层替代匹配，算出来的齐套是假的。

我的处理方式是建一张替代关系表，字段包括主物料、替代物料、替代优先级、替代比例、生效日期、适用工厂/产线。计算时按优先级逐层尝试，并且替代料的占用要回写到主料维度，不然会出现主料显示齐套、替代料被悄悄吃光的情况。

共用料是齐套模型里真正的难点，也是我前面说的“资源分配问题”的核心。同一个电阻、同一卷胶带、同一个包材，几十张工单都要用，库存只有一批。这时候齐套不再是“够不够”的问题，而是“给谁”的问题。这个问题没有唯一正确答案，但有可接受的工程解，下一节我会详细讲分配算法。这里先说数据要求：共用料必须能识别出来（按物料维度统计需求工单数，超过阈值的标记为共用料），并且每张工单的优先级字段必须可靠——交期、客户等级、工单状态、是否急单，这些字段缺一个，分配结果就会被业务挑战。

3. 核心算法设计：从“能算”到“算得准、算得快”

数据齐了，接下来是算法。我先把结论放前面：齐套计算在工程上不需要多高深的算法，贪心加优先级就能解决80%的场景，追求全局最优反而会把系统做死。原因很实在——全局最优的解业务人员看不懂，看不懂就不认，不认就会绕开系统手工调，最后模型沦为摆设。可解释性在这里比最优性重要得多。

3.1 共用料分配：按优先级贪心，把规则摊在阳光下

共用料分配我用的是一套“排序—逐条扣减—记录分配明细”的流程，具体是这样的：

1. 把所有存在共用料需求的工单按优先级排序，排序键依次是：工单状态（已开工 > 已下达 > 已计划）、交期紧迫度（交期升序）、客户/订单等级、工单号（保证结果稳定可复现）。
2. 按排序顺序逐张工单处理，对每个物料行计算：需求量、当前可用量、缺口量。
3. 分配时从可用量里扣减，扣减量写入分配明细表，记录“哪张工单占用了哪个批次多少量”。
4. 可用量耗尽后，后续工单直接标记缺口，不再尝试。

这套逻辑的好处是结果可解释：任何一张工单被判定缺料，都能查到它的料被哪几张更优先的工单占走了。车间来吵架的时候，把分配明细一拉，问题当场说清。坏处是它不是全局最优，可能出现“为了保一张急单，牺牲了三张普通单”的情况。我的处理办法是把排序规则做成可配置的，并且加一条“关键件保护”规则：某些物料（比如长交期芯片）不参与普通贪心分配，单独按项目/订单锁定，避免被日常工单吃掉。

代码层面，这个流程用一段存储过程或者一段Python就能实现，核心是把“可用量”做成一个可变的余额池。我给个简化版的Python骨架，实际项目中会加上批次、效期、替代料组的处理：

def allocate(work_orders, material_balance): # work_orders 已按优先级排序 # material_balance: {material_code: available_qty} result = [] for wo in work_orders: for line in wo.demand_lines: mat = line.material_code need = line.required_qty avail = material_balance.get(mat, 0) allocated = min(need, avail) material_balance[mat] = avail - allocated result.append({ "wo_no": wo.wo_no, "material": mat, "required": need, "allocated": allocated, "shortage": need - allocated, "kitting_status": "FULL" if allocated >= need else ("PARTIAL" if allocated > 0 else "NONE") }) return result

这段代码简单到不像“模型”，但配上正确的排序规则和干净的数据，实际效果比一堆花哨算法都稳。我在一个日计划800张工单的车间跑过，全量计算耗时不到两分钟。

3.2 齐套日期预测与缺口分级，让预警真正有用

只告诉车间“缺料”是不够的，车间要的是“什么时候能齐”。所以齐套模型必须输出一个齐套日期预测。算法不复杂，但要把几个因素叠进去：

对每个缺口物料行，取以下日期中的最大值作为该行的预计齐套日：在途最近一批的预计到货日 + 检验周期、采购未下单物料的最晚下单日 + 采购提前期 + 检验周期、自制件按工单完工日推算。然后整张工单的齐套日取所有行的最大值——这就是“最短木板”原则，木桶能装多少水由最短的那块板决定，工单能不能开工由最晚到位的那个物料决定。

举个具体例子。某工单计划开工日是本月底，缺口物料有两项：连接器缺900只，采购在途600只，预计到货日比开工日早3天，检验周期2天，那么这行物料的有效齐套日是开工日前1天，勉强来得及；另一项结构件缺200件，尚未下单，采购提前期15天，今天距离开工日只剩10天，那么这行实际齐套日必然晚于开工日5天以上，整张工单的齐套日就被这一行拖后。系统输出的不是“缺2项物料”，而是“预计延期5天，卡点在结构件”，这才叫有用的信息。

缺口分级我一般分四级：红（缺口物料在开工日前无法到货，必须调整计划）、橙（能到货但无缓冲，任何延误都会影响开工）、黄（有缓冲但缓冲不足3天）、绿（齐套且缓冲充足）。分级阈值做成可配置，不同产品线可以设不同缓冲天数。这个分级直接推给计划员，他们的动作就变成了“红单必须今天处理，橙单盯一下，黄绿不用管”，工作量和优先级一下就清楚了。

3.3 增量计算与性能优化，别让看板转圈三分钟

齐套计算最大的性能陷阱是全量重算。十万级工单、每单平均60个物料行、多层BOM展开，如果每小时全量跑一次，数据库基本就废了。我踩过这个坑，早期版本全量计算一次要十几分钟，看板打开就是转圈，业务直接弃用。

优化的思路是增量触发 + 分层缓存。第一层是事件触发：工单下达、工单变更、库存异动超过阈值、在途到货确认、BOM变更，这些事件发生时只重算受影响的工单，用物料反查工单，通常一次只涉及几十到几百张。第二层是定时全量兜底：每天凌晨跑一次全量，修正增量计算积累的偏差。第三层是结果缓存：齐套结果表按计算批次存，前端只读结果表，不触发计算。

再往下还有几个细节能省大量时间。BOM展开结果做缓存，同一BOM版本在有效期内只展开一次，展开结果落表复用；可用量计算做成物化视图或者中间表，按小时刷新，不要每次查询都实时聚合库存和占用；分配算法用内存计算，先把相关物料和工单捞到内存里跑，跑完批量写回。这么一套下来，增量计算通常能压到秒级，全量也能控制在十分钟以内，看板体验就正常了。

注意：增量计算一定要做“对账机制”。每天全量跑完后，把全量结果和增量结果做差异比对，差异超过阈值的工单单独打标出来人工确认。没有对账的增量计算，跑着跑着就飘了。

4. 工程落地：一次完整的齐套计算链路长什么样

这一节我把前面的东西串起来，讲一遍从数据进来到结果出去的完整链路。我按实际项目里的分层来讲：数据层、计算层、服务层、呈现层。每一层我只讲关键设计和实际踩过的点，具体技术栈按你们团队熟悉的来就行，我用的是关系型数据库加一段Python计算服务，没有引入什么重型组件，跑得挺稳。

4.1 表结构设计：八张核心表撑起整个模型

我把核心表列一下，字段只写关键项。这套结构在几个项目里复用下来，改动不大。

这里有几个设计要点值得单独说。库存快照表一定要带快照时间，不能只存当前值，不然历史齐套结果无法复现。工单物料需求表是BOM展开的产物，必须带上来源层级和父件信息，排查“这个需求是从哪冒出来的”时非常好用。齐套结果表要带计算批次号，配合前面的需求快照，能做到完整的可追溯。

字段类型上有个小坑：数量字段用整数还是小数。离散制造大多用整数，但有些行业（化工、食品）按重量算，必须用高精度小数，用浮点数会积累误差，齐套判断出现“差0.0001判为不齐套”的尴尬。我一般统一用定点小数，位数按行业精度定。

4.2 计算链路与调度策略：把重活拆开跑

整条链路的执行顺序是这样的：先刷新库存快照和可用量中间表，然后捞出计划期内需要计算的工单（增量模式下只捞受影响的），逐单展开BOM生成需求行，接着按物料聚合并加载可用量，跑分配算法，最后把结果写回齐套结果表并推送预警。

调度上我分了三个任务。快照任务每小时跑一次，刷新库存和在途。增量任务由事件触发，工单变更或库存异动时执行，只算受影响工单。全量任务每天凌晨执行，做兜底和对账。三个任务的执行日志都要留，出问题时能定位到是哪一环慢了或者错了。

这里有个实操细节：增量任务的触发要做防抖。库存异动是很频繁的事件，如果每次异动都触发计算，系统会被自己压垮。我的做法是异动先写事件表，用一个每分钟执行的轻量任务批量捞取事件、合并受影响工单、统一触发一次计算。这样既保证时效，又不会被事件洪水淹没。

4.3 看板与预警：让结果落到人的动作上

模型算得再准，如果呈现方式不对，业务还是不用。我在看板上只放三类信息，别的都砍掉。

第一类是工单齐套总览，按车间、按产线、按计划日期分组，用红橙黄绿四色显示齐套状态和预计齐套日，支持钻取到单张工单的缺料明细。第二类是缺料明细清单，按物料聚合，显示“这个物料缺多少、影响多少张工单、最近到货日是哪天”，这张表直接给到采购和物控，他们拿着就能干活。第三类是共用料争抢视图，显示哪些物料存在多单争抢，以及当前的分配结果，这个视图主要是给计划员做协调用的。

预警我做了两个通道。一个是看板内的待办，每天早上一上班计划员打开就能看到红单清单，处理完打勾。另一个是定时推送，每天早上把红单和橙单汇总推给相关责任人，格式就是简单的一封汇总消息，不搞花哨。推送内容我特意做成“可执行”的：不是“你有32张工单缺料”，而是“这32张里有8张今天必须处理，卡点在X物料，建议动作是催单/改期/替代”。

踩过的一个坑是预警太多导致麻木。早期版本每天推两百多条，业务直接设了免打扰。后来我把规则收紧，只推红色和橙色，黄色绿色进看板不进推送，数量降到每天十几条，打开率立刻上来了。这个调整看着小，但对模型能不能真正用起来影响很大。

5. 踩坑实录：齐套模型上线后最常见的八个问题

这一节是我最想写的部分，因为前面讲的都是“应该怎么做”，而这里是“实际会怎么坏”。齐套模型有个特点：它不上线你永远不知道数据有多脏。上线第一个月基本就是问题排查月，我按数据类和逻辑类分开整理，附上排查思路。

5.1 数据类问题：九成的误判出在这里

问题一：齐套率虚高，车间却天天缺料。最典型的原因是库存被重复计入，多个仓库的同一批次、寄售库存、客供料混在一起算成可用。排查方法是对某张“齐套”工单做全链路跟踪，从分配明细倒查可用量来源，一项项核对。修复方式是明确可用量的计算口径，把客供料、寄售料、冻结料单独标记并排除。

问题二：某个物料长期显示充足，实际早就没了。大概率是单位换算问题，或者存在“已发料未消耗”没有回冲。排查时把该物料的采购单位、库存单位、BOM单位三个值拉出来对比，再看线边仓的数据。这类问题往往一查一个准，但如果不查，会一直误判下去。

问题三：在途永远是“明天到”。采购订单的预计到货日没有人维护，系统里全是历史遗留的乐观日期。解决方案是引入在途可信度系数，并且要求采购按周更新到货承诺，超过一定天数未更新的在途自动降权。这个规则上线时会有阻力，但坚持两个月后数据质量会明显好转。

问题四：替代料算不出齐套。检查替代关系表是否覆盖完整、替代方向是否正确、替代组的优先级是否配置。我遇到过一次，替代关系配反了，主料能替代替代料，但反过来不成立，导致按主料算永远缺料。这类问题靠单元测试能提前发现，建议把替代料场景做成固定用例，每次改逻辑都跑一遍。

5.2 逻辑类问题：模型本身要想清楚的地方

问题五：BOM版本切换导致历史工单齐套结果突变。这是逻辑设计问题，工单必须绑定下达时的BOM版本，齐套计算严格按绑定版本展开。如果工单表没有这个字段，只能在BOM表里靠生效日期推断，一旦BOM有多次变更就会算错。

问题六：虚拟件和委外件穿透错误。虚拟件应该在展开时穿透到最底层实际物料，委外件的料如果在供应商处，是否计入可用量要按业务约定明确。我见过把委外件在供应商处的库存也算进来的，结果齐套了但料拿不回来。

问题七：分段齐套没有做，导致产能浪费。总装类产品往往不需要全部物料到齐才能开工，前段工序可以先干。如果模型只输出“整单齐套/不齐套”，计划员就只能干等。解决办法是按工序分段定义齐套门槛，前段工序所需物料齐套即可先开工，后段物料单独跟踪。这个改造工作量不大，但对产能利用率的提升很明显。

问题八：急单插进来之后，原有分配全部失效。这是共用料分配的固有问题。我的处理方式是急单插入时触发重算，并在结果里输出“被挤占工单清单”，让计划员看到代价。有些工厂会把这条规则做成“急单需要审批”，本质上是让业务为插单付出可见的成本，而不是系统默默扛下来。

提示：上线初期建议保留一段“双轨运行”，系统算一遍、物控手工核一遍，每周对比差异，差异原因逐条归集。这个动作看着笨，但能在一个月内把模型的主要问题挖干净，比任何测试都有效。

6. 推进节奏：先看得见，再算得准，最后才谈控得住

技术上的事说完，聊点推进层面的。齐套模型这种跨域的东西，最容易死在推进节奏上——要么一上来就想做全厂全物料，铺了半年没结果；要么做出来没人用，成了汇报材料里的一张图。我自己的经验是分三步走，每步都有明确的交付物和验收标准。

第一步是看得见。目标很简单：把当前缺料状况如实呈现出来，算法用最朴素的，数据用一个车间一个产品线的，先让业务看到“原来我们缺的是这些、缺这么多”。这一步的验收标准是业务愿意每天打开看，并且能拿着缺料清单去催料。做到了，模型就有了存在的基础。

第二步是算得准。这时候才开始做替代料、共用料分配、齐套日期预测、增量计算。验收标准是误判率压到可接受范围，业务开始用齐套结果做开工决策，而不是只看一眼就关掉。这一步通常要两到三个月，中间会反复调规则，别急。

第三步是控得住。齐套结果开始反向影响排产和采购。排产时优先排齐套的工单，采购的补料优先级由齐套缺口驱动，急单插单要评估对现有齐套的冲击。到这一步，齐套模型才算真正嵌进了业务流程，而不是一个附加的报表。

还有个容易被忽略的点：齐套模型需要有人负责。它不是一个做完就交付的项目，而是一个需要持续调规则、校数据、处理争议的运营对象。我建议明确一个 owner，通常是物控或者计划口的骨干，每周看一次误判清单，每月校一次参数。没人管的模型，半年后一定不准。

最后分享一个我在实际项目里体会很深的事。齐套模型上线第一个月，业务部门最常说的话是“系统算得不对”。我没有去争辩，而是让他们每次说不对的时候，把单号和理由写下来。一个月攒了七十多条，逐条查完发现，其中五十多条是数据问题，十来条是规则没覆盖的特殊场景，真正算错的只有几条。把这些结果整理成一页纸发出去之后，质疑声基本就没了，反而开始有人主动来提规则补充。这件事让我明白，模型的可信度不是靠算法精度建立的，是靠每一次争议都被认真对待积累起来的。