一、项目背景 我们给一个社区养老项目做助餐系统，目标是让辖区里的老人能吃上热乎饭。需求很分散，老人大多不会用手机，订餐靠子女或者社区专员电话登记，忌口和特殊饮食要求全靠人记。配送最早靠志愿者自觉接单，谁有空谁去，结果三公里的范围跑了五六趟，热餐送到都凉了，冷餐老人又吃不得，投诉不少。志愿者也排不开，周末和饭点永远缺人。我们接手时，覆盖的老人数量卡在很低的位置上不去，不是需求少，是送不过来、也排不顺。

厨房出餐我们接了预计完成时间，配送出发窗口跟着它走，而不是固定几点发，遇到某餐准备慢就延后出发，保证送到老人手里还是热的。

老人档案这块我们下了功夫，忌口和软食要求一旦录错就是安全问题，所以系统强制二次确认并同步给厨房和配送，宁可多一步也不放过，这类错误容不得。

二、落地场景 第一块是订餐与忌口登记，社区专员或子女帮老人下单，系统记录忌口、软食、少油等要求，形成老人用餐档案。第二块是集中烹饪与分装配送，中央厨房按订单 aggregate 出每餐总量，分装后交给配送。第三块是志愿者路线排班，系统按片区把订单聚合成几条路线，志愿者认领整条路线而不是零散单。第四块是到点送达核验，送达时扫码确认，老人或家属签字。最后是异常缺餐补偿，某条路线送不过来时自动触发邻近路线补位或餐补。

志愿者侧我们还做了能力匹配，会开车的认领远路线，腿脚方便的认领爬楼多的老楼，系统只建议人不强制，保留志愿者的主动性，配合度反而高。

三、关键技术挑战与解决思路 需求归集是第一关。老人不会下单不能当成没需求，我们用专员代下单加电话兜底，把分散需求汇到系统里，忌口错一个就是安全隐患，所以档案强制校验。路线排班最讲究，我们按地理片区把订单聚合，一条路线覆盖一片，志愿者一趟带十几份，而不是满城乱跑。保温送达靠时间窗，系统给每条路线算最优出发时间，确保饭在窗口内到。核验留痕我们用扫码加拍照，缺餐时有据可查，也能倒逼配送不漏户。

社区侧反馈也变了，之前老人家属总担心漏餐，现在手机能看见路线和送达时间，投诉少了一大半，项目在街道里的口碑起来后，主动来登记的老人多了。

需求归集还有个难点是临时加单，老人临时想加一份或者取消，系统要能即时改路线而不打乱其他配送，我们做了增量重排，只动受影响的那条路线而非全量重算，否则饭点临时变动会让整个调度雪崩，这个增量思路是现场跑了几周后才磨出来的，比一开始的全量重排稳得多。再就是雨天路面慢，我们给路线预留了弹性时间，不卡死到点，否则一趟堵了后面全晚，老人等凉饭的投诉又会回来。

四、效果数据 上线约四个月，送达准时率从之前的约七成提升到约九成五，餐温达标率同步上来了，冷餐投诉基本归零。志愿者利用率提高，同样的人数覆盖的老人数量涨了约四成，因为一趟带一片不再空跑。缺餐率降到极低，偶发送不过来的情况靠自动补位兜住，没有再出现老人没饭吃。覆盖老人总数翻了近一倍，项目终于能规模化了。

志愿者规模起来后，我们做了简单的激励看板，谁跑的路线多、好评多一目了然，不是为考核是为让踏实的人被看见，反而比发补贴更能留住人。

五、可复用经验总结 助餐配送最怕路线排不开，热餐凉了等于白送还惹投诉，我们早期靠志愿者自觉接单，效率极低还覆盖不上。按片区聚合订单再规划路线，一趟带一片，这比零散派单强太多。老人不会用手机不能当没需求，代下单加电话兜底把需求汇进来，忌口必须强制登记，错不得。我后来觉得，这类公益配送，系统价值不在酷炫，在于把谁送哪片、几点到、漏了谁这件事钉死，志愿者才敢接、老人才安心。

公益类配送，别指望志愿者无私奉献扛全部，把路线和时段规划好，让人少跑冤枉路，愿意来的人才能长期留下，系统做的是把辛苦活变轻松活。

助餐这件事，系统能算清楚路线和时段，但离不开人愿意跑，我们把辛苦活变轻松活，志愿者才留得住。

结语 现在这个项目把片区路线当成排班基础，近期在接厨房出餐时间的预测，让配送出发窗口更准。

案例片段（已脱敏）： 路线聚合排班片段（伪码）：zones := clusterByGeo(orders, radiusKm=1.5)   // 按片区聚合 for z in zones {    route := planRoute(z.Orders)              // 一片一条路线    vol := assignVolunteer(route)              // 认领整条路线    depart := bestDepart(route, window=hotMeal)    schedule(route, vol, depart) }上线前志愿者平均一趟送 3 到 4 份，覆盖密度低；聚合后一条路线平均带 12 到 15 份，同人数下覆盖老人数量涨了约四成，空跑里程降了一半多。