面对茶饮行业营销活动中的突发缺冰问题，产品经理不应只构建预测功能，而应设计可执行的决策流程。本文提出从风险预演到储备签约、监测行权的五阶段方案，并借助本体建模与AI辅助，将应急响应转化为有准备的经营决策，为复杂业务产品设计提供全新思路。

最近的一次茶饮行业的同行交流中，讨论到秋天的第一杯奶茶营销事件，一个很有画面感的场景代入了话题。

“秋天第一杯奶茶”活动当天，销量快速冲高。企业并非毫无准备：此前已经做过需求预估，也让仓库多生产、储备了一批冰块。但下午2点左右，部分门店还是把冰用光了。没有冰，很多现制饮品就无法继续销售；等供应链临时找资源、谈价格、验资质、安排车辆，销售高峰早已过去。

讨论中有人提出：茶饮行业当天缺冰，某些需求错峰的餐饮中央厨房或食品级制冰设施可能仍有闲置产能。能否在活动前就把这些产能找出来，付一笔不高的保留费，真正出现缺口时再调用？

这个设想听起来像“跨企业借冰”，但从产品经理视角看，它暴露的是一个更值得讨论的问题：面对复杂业务，我们经常把需求做成一个功能，却没有把它设计成一项可以完成的决策。

坦白说，不少产品经理的解决思路是：先模拟缺货，再让AI搜索周边富余产能，最后生成一套紧急协调方案。这个判断错在把“找到资源”误当成“资源可以调用”。继续推演，我们不难发现，这个方案在会议室里很顺，放到下午2点的现场却几乎不可执行——供应商来不及核验，价格来不及谈，车辆和质量责任也没有人敢临时拍板。

后来，我们把方案倒过来设计：活动前先估算风险敞口，提前筛选、谈判并签下备用产能；活动当天不再从零找资源，只判断风险是否达到约定阈值，以及应该调用多少。这个调整也成为我对复杂业务产品的一次重要认识：产品不是把分析做得更聪明，而是把采取行动的条件提前准备好。

一、如果把需求写成“做一个预测功能”，产品已经输了一半

听到“下午2点缺冰”，产品经理最容易写出三类需求：提高销量预测准确率、增加库存预警、建设供应链看板。

这些功能都有用，却没有直接解决问题。

第一，预测只能告诉企业“可能缺多少”，不会自动创造新的制冰产能。原有仓库即使提前加班，仍然存在设备、空间和人员上限。

第二，预警时间不等于行动时间。下午1点发现3点会缺冰，如果外部供应商尚未通过食品资质核验、合同尚未签署、车辆尚未预留，这条预警只是更早地通知大家“来不及了”。

第三，冰块不是普通库存。它受制于生产节拍、融损、运输半径、食品安全、批次质量和到达时点。仓库里“有40吨”与高风险门店在耗尽前“能收到40吨”，完全是两件事。

第四，内部库存优化存在边界。跨仓调拨、提高班次、调整门店配给可以减少一部分缺口，但如果全网总产能不足，再精细的内部排程也只是重新分配短缺。

所以，这个产品需求不应定义为“预测冰块需求”，而应定义为：

在营销活动前识别最大风险敞口，准备可执行的备用资源；活动当天根据实时缺口，在最晚决策点前启动预案。

前者交付一个数字，后者交付一项经营决策。

二、产品经理要建模的，不是页面，而是决策世界

当问题涉及门店、商品、活动、库存、产能、供应商、合同、运输和审批时，用一张宽表很难表达真实业务。

例如，同一座制冰设施在不同时间段具有不同可用产能；同一家供应商可能有产能，却缺少某个区域需要的资质；一份备用协议又同时受保留时段、最大吨数、行权价和交付SLA约束。这里的关键并不是字段多，而是对象之间的关系会随时间和状态发生变化。

这正是“本体”适合介入的地方。

在 Palantir 的官方定义里，本体不仅包含对象、属性和关系等语义元素，也包含动作、函数和动态权限等可执行元素。换句话说，本体不是给数据画一张好看的关系图，而是把现实业务翻译成“可以理解、可以计算、可以行动”的数字世界。

针对“第一杯奶茶”保供场景，我会优先定义十类核心对象：

1. 营销活动：活动时间、覆盖区域、目标销量和当前进度；
2. 门店：商圈、等级、实时销量、冰量和可补给时窗；
3. 菜单商品：售价、贡献毛利、单杯耗冰量和适用门店；
4. 冰块库存与批次：数量、质量状态、位置和预计融损；
5. 制冰设施：最大产能、当前负荷、生产节拍和停机状态；
6. 产能时段：某设施在某段时间可承诺的吨数和价格；
7. 外部合作方：服务区域、可靠性、错峰程度和合作状态；
8. 质量资质：有效期、适用区域、批次证明和验收规则；
9. 备用产能协议：保留吨数、保留费、行权价、窗口和SLA；
10. 风险敞口与行权订单：缺口、耗尽时间、影响门店、审批与执行状态。

这些对象连接后，产品才能回答一连串过去分散在不同部门的问题：某场活动会影响哪些商品和门店？这些商品消耗什么物料？内部库存、产能和在途何时耗尽？哪些外部设施在相同时间有富余产能？它们是否具备资质？合同是否有效？现在调用哪一组合最合算？

产品经理的工作也因此从“给页面排字段”，转向“定义业务对象、关系、规则和动作”。

三、把事后救火，改造成五阶段决策产品

我把这个产品流程拆成五个阶段。

1. 风险预演：先算清最坏会缺多少

活动前，根据历史活动、营销目标、门店分层、分时销量、单杯耗冰、自有库存、制冰节拍、在途和融损，运行高、中、低三种情景。

输出不只是全天缺口，而应包括：哪个区域、哪些门店、在什么时间开始耗尽；内部调节能够覆盖多少；潜在损失是多少；最晚应在什么时间采取行动。

2. 储备签约：把“可能找到”变成“届时可以调用”

AI 可以帮助搜索需求错峰的资源，但搜索结果不能直接进入应急方案。产品还要组织采购、质量、法务和财务完成资质验证、价格谈判与合同签署。

协议至少应包含容量保留费、行权价格、可调用窗口、部分行权、响应时限、交付SLA、质量证明和违约替补。到这一步，外部闲置产能才从一条线索变成企业可支配的“产能期权”。

3. 敞口监测：区分“最坏情景”与“风险正在形成”

活动当天，系统持续读取POS销量、门店冰量、制冰产出、在途、融损和备用供应商状态，滚动计算风险敞口。

一个可执行的触发规则可以是：

预计耗尽时间＜备用产能到达时间＋安全缓冲，且缺口超过内部调节能力。

这比“库存低于安全值就预警”更接近真实决策，因为它同时考虑缺口规模和资源到达所需时间。

4. 触发行权：调用已经谈好的方案

达到阈值后，系统给出建议行权吨数和供应商组合，由供应链负责人确认，采购、质量和财务按预设权限快速会签。随后生成提货、质检、运输、门店优先级和分配计划。

在早期POC中，不必急着自动写回ERP、WMS或采购系统。先生成一份可审核的“行动包”，让业务人员验证建议是否可执行，比展示一个自动下单按钮更重要。

5. 跟踪复盘：让下一次预案更便宜、更准确

洪峰结束后，系统核算供应商兑现率、实际行权量、未使用容量、门店恢复时间、避免损失和应急成本，再调整下一次的储备吨数、触发阈值和合同条款。

至此，产品才形成“预演—准备—监测—行动—学习”的闭环。

四、一组演示数据，怎样帮助产品团队验证逻辑

为了验证上述设计，我们不妨使用一组数据做演示假设：600家门店，活动高位情景下需要189吨冰，自有库存、产能和确认在途可支持147吨，潜在缺口42吨。企业事前签下40吨备用产能，支付0.6万元容量保留费；风险形成后调用其中36吨，再叠加3吨内部调节。

这组数字不代表任何真实企业，但它能让团队把产品逻辑跑通：无预案时，42吨缺口会影响多少门店；仅靠内部调拨能覆盖多少；购买备用产能后，剩余缺口、交付时点和贡献毛利风险如何变化。

ROI也不能用“保住的营业收入”直接减成本。更稳妥的口径是：

净保护价值＝恢复销售杯数×单杯贡献毛利－容量保留费－行权费－物流、质检、加班与协调成本。

如果风险最终没有发生，企业损失的是容量保留费；如果风险发生，则比较行权总成本与可避免的贡献毛利损失。这种设计本质上是在回答：企业愿意花多少钱，购买一次营销洪峰的确定性？

五、这个产品最容易踩的五个坑

1. 把资源搜索当成资源可用。 AI找到一家有闲置产能的企业，不代表对方愿意合作，也不代表资质、距离和交付时间合格。搜索只是候选发现，核验和签约才是可用性证明。
2. 把“更多数据”当成“更好决策”。 第一版不需要接入全部系统。只要POS、库存、产能、在途、门店和备用资源六类数据能够支撑最小闭环，就可以先验证。
3. 让大模型自由计算关键数字。 缺口吨数、耗尽时间、行权量和ROI应由确定性规则或算法计算；大模型负责理解问题、调用工具、组织证据和解释方案。
4. 忽略跨企业权限边界。 共享合作不等于共享全部数据。茶饮企业只需知道某个产能时段是否可保留、资质是否有效、价格与SLA是什么，不需要读取合作方完整的生产经营数据。
5. 一开始就追求自动执行。 采购、质量和财务动作涉及责任。POC阶段应保留人工确认、模拟行权和证据链，先证明“建议可信、动作可行”，再讨论受控写回。

六、怎么做第一版MVP

小切口导入，不用做一套宏大的供应链平台，而会限定为：一个营销活动、一个区域、一类关键物料、三种需求情景、两到三家备用资源。

用4 个星期的冲刺周期，快速交付四个核心页面：活动风险敞口、备用资源组合、方案沙箱、行动与证据卡。验收也只看四件事：

1. 能否用历史活动回放，在实际断货前给出足够行动时间；
2. 每一个缺口和建议能否追溯到销量、库存、产能、规则和合同；
3. 能否比较“无预案、内部调节、备用产能”三种方案；
4. 业务人员能否根据输出完成一次模拟会签、行权和配送安排。

这四项通过后，再逐步接入实时数据、更多物料和生产系统。否则，接再多接口也只是把一个尚未验证的判断自动化。

结语：产品经理真正设计的是“组织如何做决定”

“秋天第一杯奶茶”是一个极端营销事件，却照出了许多企业软件的共同问题：系统记录了库存，预测了需求，也发出了预警，但当管理者问“现在应该调用哪项资源、为什么、谁来批准、会挽回多少损失”时，答案仍然散落在人和微信群里。

本体的价值，不是让AI更会聊天，也不是把关系画得更复杂。它把活动、门店、商品、物料、产能、供应商、合同、风险和行动组织成同一个业务世界，让AI能够沿着真实关系分析，并在权限和规则内推动行动。

对产品经理来说，这也是一次视角变化：

不要只问“用户还需要一个什么功能”，而要问“为了完成这项决策，系统还缺少哪个对象、哪条关系、哪项规则和哪个动作”。

当产品能够提前发现风险、准备选择，并在窗口关闭前触发行动，它交付的才不只是信息，而是经营确定性。