顾客看板最容易被误解成“把后厨屏外放到门店电视上”。但真正做过现场的人都知道，顾客能看到的信息必须更少、更稳、更容易理解，否则要么暴露内部流程，要么让顾客越看越糊涂。
这篇文章主要参考了以下企业版源码入口：
enterprise/pos_order_tracking_display/models/pos_prep_display.pyenterprise/pos_order_tracking_display/models/pos_prep_state.pyenterprise/pos_order_tracking_display/controllers/main.py
一、这篇功能真正解决什么问题
pos_order_tracking_display 解决的是如何把后厨状态翻译成顾客能理解的公开状态。它没有把 preparation display 原样搬出去，而是重新定义了可见订单集、完成状态和推送入口。
二、核心链路怎么走
1. 顾客屏只关心“快好了”和“还没好”两层信息
_get_pos_orders() 会以 display 的最后两个 stage 为核心：最后一个 stage 表示完成，倒数第二个 stage 才会进入 done/Ready 集合；还没到这个阶段的订单进入 notDone/Almost there。这是一种刻意简化，而不是少做一步。
2. 可见性还受自动清屏控制
对于已经 ready 的订单，源码会计算 ordersCompletedReadyDate，再结合 auto_clear 与 clear_time_interval 判断是否继续显示。换句话说，顾客屏不是只管“何时出现”，还管“何时应该消失”。
3. 更新推送和公开访问是两套专门机制
_send_orders_to_customer_display() 用 bus 推送 NEW_ORDERS；change_state_stage() 在阶段变化后也会主动触发推送。对外访问则通过 /pos-order-tracking/ 路由和 access_token 提供初始数据。官方把公开显示做成了单独产品面，而不是厨房视图的附属页面。
三、新手最容易踩的坑
- 以为顾客屏应该展示所有厨房阶段，结果文案过多、用户无法理解。
- 以为订单 ready 后就该永久挂在屏上，忽略 auto clear 带来的现场秩序价值。
- 以为只要改了 prep state，顾客端自然会刷新；实际上需要显式发送顾客屏通知。
四、实战落地时最该盯的点
- 先设计好后厨 stage 与顾客语义之间的映射，别把内部状态名直接照搬到门店前厅。
- 如果门店说“顾客屏经常滞后”，先查
_send_orders_to_customer_display()有没有在状态变更后跑起来。 - access token 属于公开显示入口的一部分，部署时要把它当成门店公开大屏的访问凭证来管理。
五、结论
顾客取餐屏的价值，不是把厨房内部流程全摊开，而是把它重新压缩成顾客可读、可提醒、可自动收尾的一条公开状态流。这才是门店现场真正需要的显示逻辑。
DISCUSSION
评论区