DoorDash 如何避免送错菜：商家出餐与骑手取货双重核验

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 可见题目只给问题方向和 check 提示，没有要求机器学习。以下是多层运营/产品方案，非题目完整标准答案。
• 错菜包含商家装袋内容错、同店拿错袋、骑手交付错地址/顾客三种不同失误，必须分别测量，否则单一模型难找根因。
• 不要求打开密封袋检查隐私和食品安全；袋内内容验证应在商家封袋前完成，骑手只核外部可见标识。

解题路线

1. 把链路拆成 merchant pack → seal → pickup → drop-off，给每一步一个可核对的订单/袋 ID。商家封袋前按订单清单逐项勾选或扫码，封袋标签附短订单码、袋数与取货窗口。
2. 骑手取货时扫描袋码，与 App 当前 order_id 与 bag_count 匹配；多订单同骑手时用颜色/序号区分。不能扫码时提供有记录的人工确认，不能让超时直接绕过核验。
3. 交付时再核目标地址/顾客短码，避免把正确袋送给错误顾客。对多袋缺失、商家替换商品、标签损坏定义阻塞与客服/商家确认流程。
4. 记录每个 checkpoint 的错配与最终客户投诉，分阶段灰度并看取货耗时、骑手等待、商家操作成本和订单完成率；避免减少错单却让所有订单显著变慢。

手动走一遍

同一餐厅同时有 O123 和 O128，骑手接两单。商家封袋前确认 O123 的两袋及内容，标签分别 O123-1/2；骑手若只扫到一袋，App 阻止标记已取货并提示寻找第二袋。到达顾客处再次核订单短码，避免把 O128 的袋递给 O123 顾客。代码与标签格式只是训练示例。

规模与取舍

每单新增常数次确认/扫码，服务端状态约 O(订单袋数)；运营成本取决于商家每单额外秒数、骑手等待与扫码失败率。先在高错单商家/多袋订单试点，再用每千单错单率、投诉/退款率和取货 P95 评估净收益。

易错点与追问

容易失分的边界

• 只在骑手端扫码无法发现密封袋内商家装错菜；需要封袋前内容检查。
• 只靠预测高风险订单而没有明确的操作检查点，会缺少可执行拦截动作；题目提示强调出货 check。
• 用完整姓名/地址打印在袋上增加隐私风险；短码和必要信息足够即可。
• 强制检查不提供标签破损/网络断连的恢复路径，会造成取货阻塞与大量假阳性。

继续深挖

• 若商家没有扫码硬件，可先做 App 内图片/短码核对或双人检查，比较误差率与单单耗时再投资设备。
• 若还想用 ML，可预测高风险订单给加严检查，但模型要先有准确错单标签，并评估漏判、误判与不同商家规模的公平性。