后续规划

规划原则

后续迭代不追求"功能更多"，而是补强当前体系的薄弱环节。优先级判定基于三个维度：

1. 价值：对商家或客户的真实价值，不是技术新颖度
2. 成本：实施难度、维护负担、运营成本
3. 风险：是否引入新的合规、安全或体验风险

按这三个维度划分为短期（0-3 个月）、中期（3-12 个月）、长期（12+ 个月）三阶段。

短期：补强当前体系（P0）

短期目标是让现有功能更扎实，而不是堆新模块。

失败会话归因是短期内最有价值的改进。当前系统记录了转人工原因，但没有自动归类到具体改进方向。新版本应该输出：

本周 fallback 的根因分布：

• 知识缺失（35%）：缺少"夜宵高峰配送"、"团餐折扣规则"
• Prompt 边界（22%）：模型在"是否有素食"问题上越权回答
• 工具失败（18%）：订单查询接口超时
• 转人工过晚（25%）：客户已表达 2 次不满才触发规则 #4

这样 fallback 不再只是数字，而是可执行的改进清单。

中期：扩展能力边界（P1）

中期目标是让系统适应更复杂的真实业务场景，但保持产品边界清晰。

图片异常识别是中期的争议点。它能显著降低工单处理成本（客户上传照片 → AI 判断"洒漏""异物""分量不足"），但如果用"AI 自动赔付"会带来法律风险。设计原则是：

• AI 只描述"看到什么"，不裁决"应该赔多少"
• 图片识别结果作为工单字段写入，由老板拍板
• 客户侧明确知道"老板会根据图片决定处理方式"

多店铺不是 SaaS 化的开始，而是从"单店参考实施"升级到"小型连锁 3-10 家"。SaaS 化需要计费、自助注册、客户成功，这些超出当前作品范围。

长期：从客服系统到运营助手（P2）

长期方向不是做一个通用聊天机器人，而是做餐饮客服运营助手。系统应能理解：

• 订单（菜品、金额、骑手、时段）
• 菜品（成分、过敏原、库存、定价）
• 履约（出餐、配送、骑手协同）
• 售后（投诉、赔付、回访）
• 客户情绪（投诉、满意、流失风险）

并把这些维度的数据反哺经营决策。例如：

长期愿景下，AI 客服不再是"聊天框"，而是老板的运营副驾：

[客服 AI]               ←→         [运营 AI]
处理客户咨询                       生成经营建议
触发转人工                         分析趋势
建工单                             推荐 SOP 改进
                ↑
                │
        [共享数据底座]
   订单 / 菜品 / 客户 / 工单

不在规划内的事

明确不做的事，避免规划范围扩大：

这些事不是技术上做不到，而是和系统定位不符或风险大于价值。任何后续提议都要先回答："为什么不在不做清单里？"

不同时间线的人才需求

各阶段对人员的需求也不同：

中小商家场景下，团队不应过度膨胀。如果系统从单店扩展到 100+ 店仍需要 50 人团队，说明产品复杂度失控。

改进节奏建议

建议每季度做一次完整的 roadmap 评审：

1. 回顾上季度交付项的实际效果（看 30 天复盘数据）
2. 重新评估短中长期项目的优先级（基于真实数据，不是直觉）
3. 砍掉不再有价值的项目（比如发现某个 P1 实际无人使用）
4. 引入新发现的高价值项目（来自客服一线反馈）

每月做一次小评审，重点是短期 P0 项目是否按预期交付。月度评审不引入新方向，只调整已有项目的执行细节。

与现有体系的关系

后续规划不是替换现有体系，而是在现有体系上增量扩展：

• 短期项目 = 完善现有的转人工 / 知识库 / 看板模块
• 中期项目 = 在现有数据模型上扩展新表（多店、订单同步、图片）
• 长期项目 = 把现有客服数据底座升级为运营数据底座

每一阶段的改进都不会推翻前一阶段。这种演进式而非革命式的规划，让中小商家不会因为"系统升级"而业务中断。