上一篇谈加拿大市场难在哪里，我写到温哥华餐厅柜台后的几台外卖平板：不同平台接单，POS 又是另一套系统。门店看似只有一个收银台，背后却有不同的交易和结算流程。
如果每个服务商再各加一个 AI，店长会得到甚么？
外卖平台分析订单，会员系统分析回购，POS 分析销售。每个都可以给答案，但店长仍要自己把它们拼起来。
在轻 POS和数据中台两篇里，我谈过门店终端的责任边界，以及跨店资料如何治理。接下来的问题是：终端变轻、数据逐步整合之后，AI 应该放在哪里？
AI 可以出现在 POS 画面上，但模型、数据和业务规则，不必全部住在 POS 里。
先分清楚：算力、数据、决策
「把 AI 放进 POS」这句话，常把三个问题混在一起。
第一，模型在哪里运行？ 在店内设备、云端，还是外部供应商的服务上？这影响反应时间、成本和断网后的表现。
第二，它相信哪份数据？ 菜单、价格、库存、订单状态和顾客身份，分别由哪个系统最后确认？模型再强，也不能自行猜一个库存或编一个优惠规则。
第三，谁有权执行？ AI 建议调整备货、回复投诉或退款，最后由谁确认？执行后能否追踪，出错能否撤回？
这三件事可以分开设计。店员在 POS 上看到一个提醒，分析可能由云端完成，价格由交易中枢确认，最后由店长批准。
智能能力可以分散，但同一项业务事实，要有明确的权威来源。 价格、库存和会员身份可以由不同系统负责；重点是大家知道应该相信谁，以及资料何时更新。
轻 POS、交易中枢、数据底座与外部 AI，各负责甚么？
我会先按责任分工，再决定模型部署位置。
| 部分 | 应保留的责任 | 与 AI 的关系 |
|---|---|---|
| 轻 POS／门店终端 | 现场交易、履约、操作入口与必要的离线能力 | 显示相关提醒，接收确认；有需要时可做本地推论 |
| 交易中枢 | 订单、商品、支付、会员与渠道规则 | 提供当前业务状态，验证 AI 建议，执行获准的操作 |
| 数据底座／数据中台 | 身份、指标、历史、资料权限与追踪 | 提供可比较、可追溯的数据，供分析与预测使用 |
| 外部 AI 服务商 | 语音、视觉、翻译、摘要等专业能力 | 提供模型能力，按约定的资料和权限边界工作 |
这四部分不是四个必须依次建好的系统，也不是四个固定的部署地点。数据中台负责治理数据，AI 服务使用它；模型可以在别处运行。
有些企业会加店内伺服器或区域节点，处理本地资料和较即时的工作。是否需要这一层，要看网络、设备和营运要求，不能只用门店数量决定。
决定部署位置，先看四个维度
反应时间（延迟）。 收银和出餐操作不能一直等待。语音辨识、现场提示等能力，应按实际测得的反应时间选择部署方式；跨店周报则未必需要即时完成。本地部署可以减少网络往返，但实际反应时间，仍要看设备算力、模型大小和系统负载。
离线表现。 云端 AI 暂时不可用时，门店仍要能结账和出单。有些本地模型可以继续运作，但它使用的价格、库存和规则也要有更新与失效机制。离线是否可靠，不只看模型在哪里，更要看断网后，必要资料和业务流程能否继续运作。
隐私（资料边界）。 哪些录音、影像、顾客或员工资料可以送到哪个服务商，应按用途和权限定清楚。资料留在店内也需要管理，并不会因为本地部署就自动解决所有问题。出海之后，不同市场对录音、影像和顾客资料的要求可能不同。集团要先定清楚资料可以交给谁、用来做甚么，不能让每间门店各自决定。
跨店学习（分析范围）。 单店的备货建议可能只需要本店历史；跨店比较则需要共同指标和更多资料。部署位置应跟着所需的资料和能力决定，不能假设所有智能都必须上云。要看跨店规律，关键是取得口径一致的跨店资料，而不是把模型塞进每一台 POS。分析可以集中完成，再把结果送回门店。
场景一：交易异常，先判断再回到负责人
某渠道的订单突然失败，或退款比例开始上升，店员通常只看到眼前那张订单。
交易中枢可以把平台、门店和支付状态放在一起。简单的缺栏位、超时或金额不一致，可以先用明确规则检查；AI 则协助整理异常模式、归纳可能原因，或判断哪些事件值得优先跟进。
结果应回到负责人的工作清单：哪间店、哪个渠道、哪些订单、需要谁确认。只在仪表板上显示「可能有异常」，营运人员仍然要自己重新找一次。
涉及退款、改价或会员权益时，执行仍要经过业务规则和权限验证。模型的推测不能直接变成财务操作。
场景二：备货与跨店分析，让建议有依据
店长准备明天的备货，可能需要看销售历史、现有库存、外卖需求和已知活动。总部则想知道，为甚么相似门店的浪费率差这么多。
AI 可以协助预测和比较，但前提是商品、门店、退款和营业额的定义对得上。把三份不同口径的报表交给模型，不会自动得到一个可信的共同答案。
建议也要交代依据和限制：用了哪段历史、库存何时更新、哪些因素尚未纳入。店长确认或调整后，系统再记录实际结果，下一次才知道建议是否有用。
这里的价值，不是生成一份很长的分析，而是在订货之前给出一个能被检查、能被调整的建议。
场景三：评价与回访，把不同服务商的资料拼起来
外卖订单上升，会员回购下降，差评又集中在「出餐慢」。
外卖服务商看到渠道表现，会员服务商看到回购，评价工具看到顾客情绪。各自在自己的资料范围内分析，都有价值。但管理者需要知道：这些变化是否有关？订单增长是否来自短期促销？同一时段的厨房是否已经超出负荷？
这个判断需要跨渠道资料和共同的门店、时间及商品定义。能可靠对应的资料才作关联；串不起来的地方，要保留不确定性，不能让 AI 补出一个原因。
然后才是行动：把可能的出餐问题交给营运跟进，生成评价回复草稿，或在顾客同意及渠道规则允许的范围内安排回访。
这承接了把评价变成营运数据与谁掌握顾客关系两篇的方向。AI 可以帮餐厅连起线索，核心沟通和品牌承诺仍要有人确认。
服务商的 AI 可以各有专长，集团要能看全局
支付商擅长交易异常，会员服务商擅长分群，外卖整合商熟悉平台订单。企业没有必要把所有模型都自己训练一次。
但服务商的分析能力受它能取得的资料限制。它能否作跨店、跨渠道判断，要看整合范围，不能只看产品名称。
集团可以外购 AI 能力，也可以由合作伙伴提供跨渠道分析。需要守住的是：资料定义、权限、操作记录和历史能否延续，换服务商后是否仍能使用。
门店智能应该跟着数据和规则走，而不是绑在某一块硬件或某一个模型上。
终端变轻，AI 才有机会看得更清楚
轻 POS 本身不会让 AI 变聪明。真正起作用的，是终端责任减少后，交易规则和资料来源能被整理清楚，AI 才有机会取得较完整的营运脉络。
店员可以在 POS 上看到当前需要的提醒；店长在订货时看到备货建议；总部在开会前收到需要跟进的门店清单。背后可能用了不同模型，但前线不用因此多学几套操作。
语音点餐也是一样：入口可以在门店设备上，辨识可以由本地或外部服务完成，菜单、价格、售罄与优惠则要由业务系统确认。画面在哪里，和智能由谁提供，是两回事。
建议怎样变成行动？先分风险，再验收
- 低风险：自动整理。 分类评价、摘要报表、整理异常订单。
- 中风险：提出建议，由负责人确认。 备货量、排班需求、促销时段或可能的营运原因。
- 高风险：明确批准后执行。 改价、退款、补偿、会员权益、薪酬和品牌承诺。
每个建议都要知道交给谁、用了甚么资料、谁确认，以及结果如何。否则再好的分析，也只是停在画面上的一段文字。
产品验收时，我会用一个忙碌班次问四件事：
- 断网十五分钟，或 AI 服务不可用，结账与出单能否照常完成？
- 不同门店查询同一项总部规则，答案是否来自同一个来源？本地差异是否能说清楚？
- 更换 AI 服务商，前线是否仍能沿用原本流程，历史与操作记录是否保留？
- AI 给错建议时，谁能处理、能否撤回操作、是否找得到当时的依据？
这些比聊天框能回答多少问题，更能说明它是否准备好进入门店。
结语：AI 的判断，要回到门店
AI 可以在店内、云端或服务商的系统里运行。它需要可信的资料来源，也需要一条通往确认、执行和追踪结果的路。
门店终端继续完成交易与履约，交易中枢守住业务规则，数据底座提供可理解的历史，服务商提供专业能力。AI 的建议最后回到店员、店长或总部正在做的工作里。
AI 不必住在 POS 里，但它的判断，必须回到门店。
开始设计下一个 AI 功能之前，先说清楚：它会在甚么时间，用哪一组可信数据，帮助哪一个角色完成哪一个决定？
