一个印度家庭厨房的午餐订单，为什么要用工具来管？

一个家庭厨房，每月固定客户大约18到24人。这个规模小到能记住每个人的口味，却也大到让每天的临时变动变成一件麻烦事。

这是印度北方邦乔达摩菩提那加尔区诺伊达的一个朋友家的家庭生意。他的母亲和姐姐每天为那些离家在外工作的人准备午餐。这些客户不想每天中午都吃餐厅外卖，他们想要一份简单的、能送到办公室的家常饭。

需要说明的是，素材中明确标注：以下家庭故事为虚构化叙述，客户数量和消息均为示例，真实的卖家反馈仍待收集。

做饭本身不是难题。难的是那些不断涌来的WhatsApp消息。

一条消息，牵动四个环节

"阿姨，明天不要午饭。""周五请多送两份。""我要回家三天。"这些消息在做饭和打包两个环节之间抵达。有人得记住这个变动，更新午餐数量，通知配送帮手，月底还要对账。

漏掉一条取消消息，就会多打包一份午餐。漏掉一条加餐请求，就有人吃不上饭。而到了月底，"那三天我没要"又变成另一段需要翻找的聊天记录。

开发者Taqui为这个厨房做了一个叫TiffinTally的工具。它的核心思路很直接：让请求、审批后的变动、打包清单和月度账单保持连接。客户继续用WhatsApp，厨房则在消息抵达之后获得一个更清晰的管理方式。

AI只起草，不拍板

系统的工作流从一个仪表盘开始。它显示选定的服务日期、已确认的餐食总数，以及等待审核的请求。界面被设计成厨房笔记本的样子，而不是堆满无关图表的控制台。

卖家通过二维码连接厨房手机，把联系人关联到客户记录。来自已关联客户的消息可以被捕获以供审核。卖家能一边看原始消息，一边看系统建议的变动，核对日期和数量，然后编辑或批准。不清晰的请求会被标记为需要关注。

这里有一条明确的分界线：AI负责生成草稿，但不负责批准订单。

系统配置的模型是Gemma 4 31B IT，通过Backboard使用其OpenRouter提供商访问。它从原始消息中提取建议的餐食变动，并附上支撑引文。应用会拿这些引文和原始消息比对——一个看起来自信但证据无效的答案，不会变成已批准的订单。

TypeSafe的JEV（固定版本jev-1.13.0）独立对请求进行分类：这是暂停、数量变更，还是模糊不清？它是否明确替换了常规安排？是否缺少必要细节？当两个模型出现分歧或不确定时，会变成一条审核警告。JEV是另一个信号，不是Gemma正确的保证。

两个模型都使用Backboard SDK，各自拥有独立线程，记忆功能关闭。

语音消息也进同一条流水线

不是每个客户都会打字说明变动。WhatsApp语音路径使用ElevenLabs Scribe v2把语音笔记转成文字，文字随后进入同一套审核流程。这一集成目前用模拟API测试完成，真实的客户语音笔记走查尚未进行。

客户记录保存姓名、打包备注和日程安排。手动提案处理那些通过电话或当面告知、而非WhatsApp发来的变动。设置项保存厨房时区、规划时间、截止时间和客户上限。价格与配送设置则录入每位客户约定的餐费率、账单编号、楼栋和配送备注。

已批准的变动汇入每日打包数量。卖家在交接前会最终确定一个版本的清单。如果当前打包事实发生变化，就需要一份新清单。一份待处理的草稿不能悄悄改变实际打包的内容。

账单不可篡改，路线不做GPS

账单本显示来自已定稿清单的带日期数量和费用。跳过与加餐会核对进总额，不会把同一顿跳过的饭扣两次。约定的半份收费可以作为带日期的调整项录入，并附上原因。已发出的账单保存为不可变版本，修订版会引用上一版账单，并提醒客户不要两边都付。

分享功能会打开一个WhatsApp编辑窗口供卖家审核发送。它不会把账单标记为已付，也不能证明配送已经发生。

Ramesh模式按卖家录入的楼栋或路线对正餐数量进行分组。取消的停靠点单独出现在"今日不送"下面。未分配的配送保持可见，而不是消失。配送帮手拿到的是实用的交接摘要，不是整个账单工作区。这是基于楼栋的分组，不是GPS路线优化。

预测板块是建议性的，不能改变已确认的餐食。计划中的TabPFN路径使用历史餐食变动和结构化消息信号。托管预测集成和真实历史验证尚未完成，所以开发者没有声称拥有一个可用的需求预测。

技术栈方面，应用使用Next.js、React、TypeScript、Tailwind CSS和shadcn/ui。TanStack Query负责读取和操作后的数据刷新。Better Auth提供Google登录。Zod校验输入和模型输出。持久层目标为MongoDB Atlas，使用按卖家划分的记录、修订检查、事务和请求回执。

开发者表示，一次已批准的虚构实时测试通过Gemma/JEV组合产出了一个经过验证的审核候选。这检验的是集成，而不是真实客户对话中的准确率。