一、项目背景

某街道办长者食堂，覆盖周边十几个社区。老人吃饭靠子女代订或者自己到现场排，餐量全靠食堂阿姨估，天天做多剩一地、做少不够吃。更麻烦的是特殊病种，糖尿病要控糖、高血压要低盐，这些饮食禁忌以前全凭打菜师傅记性，配错一次就是事。独居老人要是哪天没来吃，也没人知道是不是出了状况。街道想抓服务质量，手里却连一份像样的就餐数据都没有，考核只能看照片，谁都不服气。

我们刚接手时，食堂一周能剩出整整一桶米饭，阿姨说"宁可多不可少"，但倒掉的都是钱。另一边，有个独居大爷连续三天没出现，邻居还是收废品的大姐偶然撞见才发现的。这两件事让我们下定决心，系统必须把"吃没吃""吃对了没"这两件事钉死，而不是只管收钱。

二、落地场景

我们给每位老人建了档案，子女或本人能在小程序上订餐，病种和饮食禁忌做成标签，点餐时自动校验，控糖餐、低盐餐分开备。食堂根据预订和历史数据做餐量预测和备餐，社区志愿者负责配送和到店核销，独居老人连续两天没订餐，系统自动发漏餐预警推给网格员上门看一眼。这样一来，食堂知道做多少，子女知道老人吃没吃，街道知道服务覆盖到谁。

配送这块我们花了不少心思，志愿者住哪、能跑几个点，得按片区聚合再排，不然跨社区跑空车。核销也不是扫一下就完，系统会比对预订人和实际就餐人，防止冒领和错领。街道管理员打开看板，能看到每个社区的就餐覆盖率、病种分布，哪片独居老人多、哪片配送缺口大，一目了然。

三、关键技术挑战与解决思路

禁忌校验是第一道关。我们把病种标签和菜品做了映射表，点餐时命中禁忌直接拦下并提示替换菜，避免师傅手误。餐量预测是最容易翻车的地方，最早我们按历史均值估，结果周一和雨天差太多，备多了剩、备少了不够。后来把天气、节假日、社区活动都做成因子喂进去，误差才明显收窄。

配送排班也不能拍脑袋，志愿者住哪、能跑几个点，得按片区聚合再排，不然跨社区跑空车。漏餐预警的阈值要保守，宁可多跑一趟也别漏掉真有事的老人。我们还踩过一个坑：预警最早只发给食堂，食堂忙起来根本没人看，后来改成直接推给对应的网格员手机，并带上门话术，处置率才上来。

案例片段（已脱敏）： 病种标签与点餐校验的核心逻辑如下：python def check_meal(elder, meal):    forbid = DIET_MAP.get(elder.disease, [])   # 病种对应禁忌食材    hit = [m for m in meal.items if m in forbid]    if hit:        return False, f"含禁忌食材：{hit}，建议替换低盐套餐B"    return True, "ok"上线八周，因禁忌误配被拦截 41 次，事后回访无一例实际误食；漏餐预警触发 56 次，其中 9 次确为独居老人异常。

推广这套系统本身也有坑。食堂阿姨一开始抵触，觉得多此一举，录入病种标签嫌麻烦，我们没硬推，而是用数字说话：剩餐减少意味着她少挨经理骂，餐量预测准了她就不用提前两小时来备菜。后来她反而成了最积极的推广员，主动提醒老人点餐。这让我们明白，to B 系统的落地阻力往往不在技术，而在有没有帮一线算清那本账，账算明白了，阻力自然散了。

四、效果数据

餐量误差率从约百分之十八降到百分之七以内，剩餐和不够吃同时缓解，倒掉的米饭从一周一桶变成零星。禁忌误配率趋近于零，八周里拦截的 41 次差错，回访确认没有一例真正发生。配送准时率稳定在九成三以上。漏餐预警累计触发 56 次，其中 9 次确实发现了独居老人的异常情况，网格员及时上门处置。街道第一次有了按社区、按病种的就餐覆盖率报表，考核从看照片变成看数据，食堂阿姨也从"凭感觉"变成了"看预测"。

五、可复用经验总结

长者助餐这件事，安全冗余比成本更重要，禁忌校验宁可拦错也不能放过，我们宁可多弹一次提示，也不让一勺高糖菜端上桌。餐量预测别迷信均值，社区场景里天气和节假日的影响比你想的大，因子加进去立竿见影。漏餐预警的阈值要偏保守，多跑一趟的成本，远小于漏掉一次意外，而且预警一定要推给会行动的人，推错对象等于没推。说实话，这套系统真正难的不是算法，是把食堂、子女、志愿者、网格员四方的协作流程捋顺，技术只是把已经说好的规矩固化下来，规矩本身得人来定准。

数据反过来也喂了运营。哪类病种在哪些社区集中，一眼就能看出，街道据此协调社区卫生服务中心做进社区讲座，食堂顺势推对应的控糖低盐套餐，就餐率和健康管理的联动，比单做食堂有意义得多。系统产生的数据，最后长出了当初谁都没想到的用处。

结语

我们后来补了一个家属端的小功能，子女能看到老人本周吃了几顿、剩了几顿，投诉一下子少了很多。服务的透明度，有时候比服务本身更让人安心，这点我们后来在好几个养老项目里都复用上了。