开发“餐掌柜”那会儿，基于我盯着一堆餐饮客户的掌柜Excel表格，心里直犯嘀咕：这玩意儿到底能不能熬过三个月？项目结果，它活下来了，实战还活得挺好。基于原因不复杂——我们没做“万能系统”，掌柜只做了“扫码点餐+后厨同步”这一条窄路。项目

餐饮老板最怕什么？实战不是菜难吃，是基于服务员记错单。一个口头加菜，掌柜后厨做了，项目前台没录，实战月底对账能吵翻天。基于餐掌柜的掌柜解法很粗暴：顾客扫码，自己下单，项目后厨大屏自动弹单，菜品做完划掉，全程无人工传递。有个开面馆的老板跟我说，以前晚高峰他嗓子喊哑，现在他站在收银台边，看手机上的实时流水，像个局外人。这话听着心酸，但真实。

技术上没什么高深的。SaaS架构，多租户隔离，每个店铺一个虚拟空间，数据库里按tenant_id分表。难点在权限设计——店长能看毛利，服务员只能开台，收银员能退款但改不了菜品价格。我们花了三周磨这套规则，后来发现，权限细到“某个员工能不能给熟客打九折”这种程度，反而成了签单的杀手锏。

有个细节，现在想起来都乐。初期版本没有“并台”功能，两桌客人想拼桌，系统直接报错。厨师长打电话骂我们：“你们搞的是高科技还是添堵？”那天晚上，我们加了个“临时桌号”字段，允许两个桌号合并到一个订单里，后厨出菜按合并后的数量走。就这一个小改动，留住了三个连锁客户。

最坑的坑在数据同步。餐饮店网络时好时坏，断网时点单系统不能瘫。我们做了离线缓存：前端把订单存在本地SQLite，网络恢复后自动上传。但有一次，一个客户断网两小时，重连后上传了三百多条订单，服务器处理不过来，直接超时。改方案，改成增量同步加队列重试，才稳住。这种问题，书上不教，只能靠现场炸出来的教训。

现在餐掌柜有四千多家店在用，每月处理订单量过千万。但我不爱吹这些数字。我更在意的是，那个面馆老板现在能提前一小时下班，回家给孩子做饭。技术这东西，落到一碗热汤面上，才算真落地。SaaS项目没有银弹，就是把一个场景反复揉碎了，再拼起来，拼到老板觉得“这玩意儿比人靠谱”。

要说遗憾，也有。最初想加“智能推荐菜品”功能，算法模型都搭好了，结果老板们根本不看——他们更想要“哪个菜今天卖得不好，提醒我下架”。你看，我们以为的智能，和人家要的实用，差着一条街。后来把推荐改成“滞销预警”，使用率立刻翻倍。做SaaS，别自嗨，听客户的，哪怕他们说的不性感。

餐掌柜还在迭代，最近在琢磨“食材损耗预测”模块。能不能成，不敢打包票。但至少，我们知道怎么快速试错，怎么从骂声里找需求。这条路，走得粗糙，但踏实。