TMS · Delivery Recovery
运输异常恢复：AI + Delivery Recovery
让 AI 从承运商更新中提取运输异常，再由确定性逻辑比较 ETA、增量成本与 Service Level，最终恢复方案由人确认。
可运行演示AI 增强现有工作Hybrid · AI + 确定性逻辑人工复核
工业语境与系统边界
场景实验 · TMS
AI 与规则、Solver 或代码协作
集成边界：运输异常恢复仿真；未连接承运商、TMS、实时 ETA、价格或路由服务。
这个 BUILD 证明了什么
这个实验产生了一个边界清晰、可以检查的结果。
一条“预计延误 2 天、72 小时后客户可能停线、允许拆单”的承运商更新会被转换成受限事件。系统随后计算四种恢复路径并显示 ETA、增量成本与按时覆盖率；AI 可以解释差异，但不会替物流负责人选择。
当物流异常首先出现在承运商邮件或文本更新中时，AI 能否加速异常理解与方案比较，同时不接管 ETA、成本和客户服务承诺的计算真相？
异常先由 AI 读懂，恢复结果仍由可验证的 ETA、成本与服务计算决定。
同一物流异常通常没有单一“最好答案”：更快、更便宜和更高客户保护之间需要明确 trade-off。
240 件关键物料原计划 Day 2 到达，现在预计延误。
客户 72 小时后可能停线；这不是“让 AI 猜路线”，而是先把异常事实送进恢复模型。
决策边界
谁负责什么？
AI / 确定性系统 / 人怎么分工
- 输入01定义问题
Build 从一个边界清晰的能力问题开始。
- 系统02运行实验
实现本身负责产生可测量的系统行为。
- 证据03检查结果
结论只限定在现有证据真正支持的范围内。
证据深度
验证这个结论。
限制必须保持可见；实现细节可以深入查看，但不能阻塞 Demo 主流程。验证 2026-10-21 · 构建 6e89290 · 未测 2 项 / 阻塞 3 项展开全量记录
- 未测8 条路由 × 3 视口（1440×900 / 720×900 / 390×844）的横向溢出、Tab 焦点 outline、#evidence 深链、正文对比度抽样（仅记录数值，阈值未定）
- 未测对比度阈值判定：首轮只记录实测数值，WCAG 阈值待真实分布确认
- 阻塞读屏（screen reader）
原因：当前无读屏执行环境
- 阻塞原生 200% 浏览器缩放
原因：headless 视口不能替代原生缩放，需人工验证
- 阻塞视觉构图接受
原因：需人眼评审；当前会话无视觉模型能力
- 所有货物、运输模式、ETA 和成本均为模拟数据，不代表真实承运商报价。
- AI 不计算或修改 ETA、成本、覆盖率，也不直接选择恢复方案。
- 当前没有建模海关、碳排、承运商容量、时区、航班班次、路线网络或真实 TMS 集成。
- Split Shipment 被简化为 80% 加急、20% 保持原路线，用于展示成本与服务之间的可解释权衡。
实现方式
一个聚焦的运输恢复实验：同一票 240 件关键物料原计划第 2 天到达，承运商通知预计延误 2 天，而客户 72 小时后存在停线风险。AI 只提取延误、原因、停线窗口与是否允许拆单；代码计算保持原路线、加急卡车、空运和 Split Shipment 四种恢复路径的 ETA、增量成本与按时覆盖率；最终选择保留给物流负责人。Demo 使用一票 240 件模拟关键物料。AI Runtime 只允许输出 delayDays、lineStopHours、splitAllowed 与 reason；失败时使用明确标记的规则回退。确定性恢复逻辑固定计算原路线、加急卡车、空运与 80/20 Split Shipment 的 ETA、增量成本和按时覆盖率，再把这些计算结果交给 AI 做不改变数字的简短权衡解释。
可复用模式
“非结构化物流异常 → 结构化事件 → 确定性恢复选项 → AI 解释 → 人工选择”的模式可扩展到海运延误、港口拥堵、天气异常和客户 Delivery Recovery。
证据与来源
- Demo交互式运输恢复 Demo
同一运输异常会生成多条可验证的恢复路径，并并列展示 ETA、成本和按时覆盖率。
- 架构AI → Recovery Logic → Human 边界
AI 结构化承运商事件并解释权衡；确定性代码计算运输结果；物流负责人承担最终方案选择。
- 源码