奶茶店状态图：先收钱，再查珍珠

Kevin Ngo 在推文里发了四张奶茶店业务图，用 JavaScript 画，基于 @poteto 的 /statechart skill，开源，制作工具是 Claude Opus 5.5。

statechart 是软件工程里描述状态变化的图。对象处在什么状态，什么事件触发它转移到下一个状态，哪些状态可以并行。奶茶店是个聪明的选题，读者不需要技术背景，也能立刻检查图对不对。

第一张图叫“the business of boba·I An order from the line to your hand”。流程从排队开始，点单，付款，制作，叫号，取餐。图里有一个分支：如果珍珠没了，退款。

点单流程状态图，从排队到取餐，包含付款后退款分支

有网友指出，退款检查只发生在付款之后。先收钱，再发现珍珠没了。这个顺序放在图里很显眼。另一位网友说，珍珠耗尽的分支说明有人真的在那条队里站过。

第二张图叫“the business of boba · II A day at the shop, 7 am to 9 pm”。早上 7 点准备，开门，安静，有人进来，忙起来，放学，高峰，晚上 9 点打烊。

奶茶店一天营业状态图，从早上 7 点准备到晚上 9 点打烊

有网友评论，高峰路径跳过四小时规则，是整家店里最真实的 bug。图没有解释四小时规则，但这个说法把现实里的妥协点出来了。

第三张图把店员和珍珠锅拆成两个并行状态。店员在空闲和做饮料之间切换，订单进来，除非正在煮珍珠，否则做饮料，摇匀封口，叫号，回到空闲。珍珠锅从满到不足，店员空闲时补新批次，珍珠变软后停用。

店员和珍珠锅两个并行状态图

这张图的信息量最大。它把“人”和“锅”分开，各自有状态，又互相触发。珍珠不够不是异常，是日常分支。补货要等店员空闲，这个约束在图里很清楚。

第四张图没有配说明，放在文末，方便对照。

推文中的第四张补充图

有网友在回复里总结，用 statechart skill 画奶茶店业务图，动手前先把状态问穿，少返工，需求没对齐别开写。这个说法比图本身更像经验。

还有网友问，有没有出现没预料到的状态，比如订单卡在已付款和制作之间。这个问题值得留着。状态图的价值常常不在画出来的部分，而在画的过程中被迫回答的分支。