物料冻结/解冻 AI 审批技能包

平台级项目 · 智造提效工坊 · 更新于 2026-08

背景与痛点

先解释下这是个什么活儿。在某大型家电集团的供应链里，物料冻结/解冻是高频动作：批次不良要锁料、产线切换要放行老料、降成本替代要封存旧型号。听起来就是按个按钮，实际上每单都要走核对流程：物料号抄对没有、属不属于必拦的印制板类、系统状态允不允许执行、是不是已有在途单、带后缀的版本号对不对。这些核对点散在品质、采购、计划几个部门老师傅的经验里，没有一张写全的清单。

结果就是两慢一乱。慢：一单人工核对 15 到 20 分钟，一批申请下来大半天没了。乱：判断口径看人，同一个申请，有人放有人拦，说不清谁对。我在品类管理岗上被这个流程磨了很久，直到摸透飞书平台的 Agent 能力，才动手收编它。

方案与实现

做法是在飞书上做一个自定义智能体技能包：用户用自然语言说「帮我把某某物料冻结，原因是批次不良」，剩下的交给系统。整个包的核心是 429 行 Python，从 1.0.0 迭代到 1.7.0，共 7 个版本。架构上一条铁律：大模型只负责「听懂人话」，所有规则判断都是确定性代码。模型从话里抽出物料号、申请类型、原因，然后一切交回给代码。

审批规则怎么结构化

我把散在各部门经验里的核对点逐条写成显式规则：物料号格式校验与后缀自动适配（衍生版本多，人工最易看漏）；N137 印制板类硬拦截——有专门管控要求，命中即转人工升级；防重复提交——先查在途单，同一物料已有生效流程就拒绝并告知单号。规则写进代码的那一刻，制度从文档变成了逻辑：

规则引擎的骨架（示意）：
check(物料号, 申请类型, 当前状态)
  ├─ 物料号格式校验 + 后缀自动适配
  ├─ N137 印制板类？ → 拦截，转人工升级
  ├─ 已有在途单？   → 拒绝，回单号
  └─ Oracle 状态核验 → 通过才放行执行

风险识别怎么做

原则是「高危不靠自觉」。模型解析出的每个字段先过一遍规则引擎，任何一条命中，流程立刻停下并说明原因。数据库层面再兜一道：执行前到 Oracle 里核验物料实时状态，状态不对同样终止。即便模型听岔了参数，后面每道闸都是代码在守。

和飞书的集成

三处咬合：飞书消息卡片做交互，执行前弹确认按钮，防误触；执行结果写回多维表格，谁、什么物料、什么类型、命中了什么规则、结果、时间戳，一行不落；异常情况回飞书消息说明原因。每个历史决定都能还原出当时的判断依据，后来审计复盘全靠它。

7 个版本，每版解决什么

这是我最想讲的部分。生产级 AI 应用不是设计出来的，是被真实使用一刀一刀改出来的。每一版都对应一次线上暴露的问题：

看规律会发现：前两版解决「能不能用」，中间几版解决「敢不敢用」，最后两版解决「别人能不能放心用」。从能用到可信的距离，比从零到能用的距离长得多。

创新点

一句话概括：把审批从「人找规则」变成「规则找人」。过去规则躺在文档库里，靠人翻、凭记忆、等老师傅把关；现在是规则以代码形态嵌在提交动作里，你话音刚落，所有核对已经跑完，该拦的当场拦下并说明依据。另一个坚持：AI 全程不拍板。模型做理解，代码做判断，人做确认——不是能力不够时的将就，是审批场景该有的分工。让模型「决定要不要冻结物料」，才是这类项目真正的风险源头。

价值与复盘

数字上：单单处理从 15-20 分钟降到 1 分钟以内，一批申请从小时级压到分钟级。更值钱的是两个软性变化：判断口径统一了——同一套代码，不因人而异；全程可审计——每个决定都带着当时的规则命中记录，随时能还原。

如果重来我会怎么做：

1. 第一天就建回归用例集——把历史单据脱敏后做成测试集。前四个版本的坑，本可以在线下先踩完。
2. 规则表外置成配置文件，改规则不改代码。现在拦截规则更新还要动代码发版，换人就没人接得住。
3. 上线先灰度并行两周：AI 判断和人工核对同时跑，比对一致率到 100% 再放手。我当时的并行期太短，v1.3 那次险情就与此有关。
4. 留痕从 v1.0 就该有，而不是最后两版才补。审计需求不会因为你还没推广就迟到。