案例 · CASE / FULFILLMENT
把「还能不能到」变成一个能追问的问题。
履约解释 Agent · 一个企业 AI 实践。它不替人承诺交期，它把「为什么掉队」和「还能怎么救」摊开，让承诺仍然由人来做。
履约洞察的难点从来不是数据不够，而是数据不回答「为什么」。这个 Agent 的位置很窄：在确定性计算之上加一层可追问的解释，把人的注意力从「查数据」挪到「做取舍」。
01 / 现场 · 问题长什么样
履约问题在系统里是被拆开的：需求在计划系统、库存在仓储系统、在途在物流表、产能在线边排产、例外散在邮件里。每一块都准，合起来却没人能回答一个具体问题——这张订单那天能不能到；如果不能，是哪一环先掉的。
于是每天的履约会变成同一件事：先花一半时间对齐口径，再用剩下的一半做判断。真正稀缺的从来不是数据，而是把数据翻译成一句能追下去的因果。
02 / 边界 · 谁负责哪一段
这条边界不是技术限制，是责任划分：模型可以建议，不能承担。所以它被写死在结构里，而不是写在文档里。
- 确定性逻辑算清楚：净需求、可用量、在途、产能约束。这部分不能交给模型——它必须每次算出同一个数。
- AI解释与归纳：把异常串成原因，捞出历史相似案例，给出「还能怎么救」的几个选项和各自的代价。
- 人承诺与审批：对客户的交期承诺、对资源的重新分配。这两件事错了要赔钱，也必须有人签字。
03 / 验收 · 怎么算做对了
不看「预测准确率提升了多少」——那是上一个时代的问题。看三件事：会议里对齐口径的时间是否下降；结论是否能追到具体一环；人的取舍是否变得更晚、但更准。
第一条可以被观察到，第二条可以被抽查，第三条只有当事人自己知道。所以验收必须由人来做，不能由模型自评。
04 / 复盘 · 如果重做
先后顺序会反一下：先做「能被追问的解释」，再做「更准的预测」。解释错了当场就被抓住，预测错了要等一个周期才知道——前者能快速校准，后者只能靠运气。
还有一条：把边界写进产品，而不是写进文档。文档里的边界会被下一个需求冲掉，产品里的边界会挡住它。