结论：有条件通过
业务方向可行，现有菜单、点餐入口、消费订单、取餐和退款能力可继续复用；但客户评审版不能直接作为开发方案，必须补齐拼团活动、报名聚合、状态机、支付/退款和并发关团设计。
系统边界
继续复用
- 餐厅、档口、菜品、菜谱和餐次
- 手机端选餐入口和购物车交互
- 成团后的正式消费订单
- 取餐、核销、查询及适用的退款能力
必须新增
- 拼团活动及规则快照
- 员工报名与报名菜品快照
- 关团状态机、事务锁和幂等控制
- 正式订单转换、失败补偿和通知记录
拼团活动和报名记录不是第二套正式订单系统，而是正式消费订单形成前的意向聚合层。
Tigers｜真实风险
1. 支付与成团口径未确定
报名不付款会产生爽约；报名即付款会触发未成团批量退款；冻结后扣款体验最好，但改造量可能最大。
动作：先确认报名、成团、扣款、退款四个时点。
2. 当前下单会立即形成正式订单
直接复用会让未成团报名提前进入订单、备餐统计以及支付/退款链路。
动作：增加独立报名层，不用普通未支付订单代替拼团报名。
3. 关团并发与重复执行
截止时最后报名、用户取消、定时关团和人工操作可能同时发生，造成重复成团、重复转单或退款。
动作：活动级事务锁、条件更新、唯一业务号和可重试任务。
4. 最低人数统计粒度不清
需要明确按人、份、单、菜品还是套餐成团；一人多份和多人不同菜会得到完全不同的结果。
动作：首期限定固定套餐，按去重员工人数成团。
5. 未成团不等同于普通退款
未成团可能发生在正式订单形成前；已成团取消还涉及报名截止、备餐开始和退款截止。
动作：分开定义撤销报名、未成团释放/退款、正式订单取消退款。
6. 菜品库存与报名人数竞态
报名若不占库存，成团时集中转单可能超过限量；严格限量场景应升级为上线阻断。
动作：固定套餐使用活动配额，通用拼团设计预占量。
7. 通知不是单一渠道配置
小程序消息需要授权，短信有成本，企业微信需要身份映射和应用权限。
动作：结果页作为必达通道，外部消息仅提醒并支持重发。
Elephants｜尚未充分讨论
- 成团后食堂能否人工撤销，谁承担退款
- 截止后能否加人、换菜、减少份数
- 代报名人数是否计入成团人数
- 未取餐是否退款、是否计入爽约
- 多账户支付如何原路退款及处理有效期
- 后厨按人数还是菜品份数备餐
- 菜单变价或下架后的报名快照处理
- 同餐次多场活动是否允许重复报名
Paper Tigers｜首期不必过度建设
不建第二套正式订单
只增加活动/报名聚合层，成团后继续复用消费订单。
不引入团长角色
食堂管理员发起、员工报名即可形成闭环。
不做高频实时推送
首期页面刷新或低频轮询足以支撑试点。
不支持复杂混拼
跨餐厅、跨餐次、多菜单分别成团留到后续。
上线前行动
| 动作 | 责任方 | 完成条件 |
|---|---|---|
| 确认支付/结算模式 | 产品、客户、财务 | 写清报名、成团、扣款、退款四个时点 |
| 确认成团统计粒度 | 产品、客户、食堂运营 | 明确按人/份/套餐及重复报名规则 |
| 输出状态机与异常矩阵 | 产品、后端、测试 | 覆盖报名、取消、关团、转单、退款、通知失败 |
| 确认技术数据模型 | 后端、DBA | 活动、报名、报名项、任务记录和唯一键通过评审 |
| 验证订单/退款边界 | 后端、测试、财务 | 选定支付方式完成真实测试环境闭环 |
| 小范围试运行 | 项目、食堂运营 | 一个餐厅、一个餐段、一个固定套餐、一周 |
推荐首期范围
食堂管理员发起活动；一场活动对应一个餐厅、一个日期、一个餐次和一个固定套餐。
按去重员工数判断成团；截止前允许撤销，截止后员工不能自行修改。
系统自动且只执行一次关团；成团后生成或关联正式消费订单。
未成团不进入后厨备餐；手机结果页必达，消息通知作为提醒。
后台查看活动人数、菜品份数、异常转单和退款结果。
最终建议
可以做，但不能按“只加最低人数、三个状态和通知”直接开发。
先完成支付模型、成团口径、状态机和异常矩阵，再进入原型和开发评估。试点完成“报名 → 临界人数 → 并发关团 → 正式订单 → 取消/退款 → 后厨统计”的真实测试环境验证后，再扩展多套餐、代报名、顺延和多支付渠道。