← Build 实验室
BUILD测试中
Order Allocation · ATP
缺货分配：AI 语境 + Allocation Rule
当 600 件库存面对 1,000 件客户需求时，让 AI 识别停线、战略客户和可延迟语境，再由可解释分配规则生成候选方案。
要回答的问题库存不足时，AI 能否把散落在客户沟通中的优先级语境转成可审计参数，而不直接替业务决定谁拿货？
可运行演示AI 增强现有工作Hybrid · AI + 确定性逻辑人工复核
工业语境与系统边界
邻接场景 · Order Allocation · ATP
AI 与规则、Solver 或代码协作
集成边界：稀缺库存分配仿真；策略是示例候选，不代表企业分配合同或真实 ATP 执行。
SHORTAGE ALLOCATION
库存短缺时，AI 可以理解客户语境，但不能直接决定谁拿货。
系统把停线风险、战略属性和灵活性变成受限参数，再由确定性规则守住 600 件硬上限。
01 · 短缺情境
只有 600 件库存，三个客户合计需求 1,000 件。
短缺 400 件没有“自动正确答案”；关键是把业务后果透明地带进候选方案。
可用库存600硬上限
总需求1,000缺口 400
最终责任HUMANSupply Planner
证据深度
验证这个结论。
限制必须保持可见；实现细节可以深入查看，但不能阻塞 Demo 主流程。验证 2026-10-21 · 构建 6e89290 · 未测 2 项 / 阻塞 3 项展开全量记录
- 未测8 条路由 × 3 视口（1440×900 / 720×900 / 390×844）的横向溢出、Tab 焦点 outline、#evidence 深链、正文对比度抽样（仅记录数值，阈值未定）
- 未测对比度阈值判定：首轮只记录实测数值，WCAG 阈值待真实分布确认
- 阻塞读屏（screen reader）
原因：当前无读屏执行环境
- 阻塞原生 200% 浏览器缩放
原因：headless 视口不能替代原生缩放，需人工验证
- 阻塞视觉构图接受
原因：需人眼评审；当前会话无视觉模型能力
- 所有客户、需求和优先级均为模拟数据。
- 规则只是用于展示的候选 Allocation Policy，不代表真实企业合同或客户分级政策。
- AI 不直接返回最终分配数量；总量和硬约束由代码强制执行。
- 正式客户取舍必须由人负责，尤其涉及战略客户与合同承诺时。
实现方式
一个短缺分配实验：三个客户同时争夺有限库存。AI 从客户说明中提取 stop-line risk、strategic status 和 flexibility；确定性分配器基于硬保障与权重分配 600 件可用库存，最终客户取舍由人确认。AI Runtime 输出 customerId、lineStopRisk、strategic、flexible 三类受限字段；回退路径使用固定模拟语境。分配器先满足停线风险客户的最低保障，再根据战略权重和剩余需求按比例分配，且总量永远不超过 600。
可复用模式
可扩展到 scarce component allocation、订单抢占、ATP 配额和战略客户缺货管理。
证据与来源
- Demo交互式短缺分配 Demo
600 件库存会在三个客户之间产生可视化流向，并留下明确未满足需求。
- 架构AI / Allocation / Human 边界
AI 提取客户语境；分配器算数量；高影响客户取舍由人确认。
- 源码