# 首轮需求访谈决策 ## 文档效力 本文记录首个餐饮试点经过访谈确认的需求。若与早期 PRD、原型或数据文档冲突，以本文为准，后续实现应同步采用这些规则。 ## 产品目标 第一优先级是帮助经营者获得真实订单，覆盖普通套餐和私厨定制。产品方的获利、运营和平台化目标不得损害经营者的实际使用效果。 ## 客户身份 - 品牌、服务、作品和公开反馈允许匿名浏览。 - 客户首次下单时通过 `wx.login` 建立无感微信身份，不要求注册账号或设置密码。 - 后端通过 OpenID 识别客户，客户端不得指定其他客户身份。 - 联系方式仍由客户主动填写，用于实际履约。 - “我的订单”只展示当前 OpenID 创建的订单，不支持通过手机号查询其他微信账号的订单。 ## 普通套餐订单 - 客户选择套餐和数量，页面展示单价和预计总价。 - 预计总价不代表支付或最终应收金额，最终线下结算。 - 保存套餐名称、单价、数量和小计快照，历史订单不受以后调价影响。 - 支持自取和配送。 - 自取填写期望取餐时间。 - 配送填写地点、宿舍楼/具体位置、期望送达时间和可选备注。 - 页面展示可编辑的配送范围说明；第一版不做地图围栏或自动可达判断。 - 客户可选择微信联系、电话联系或无需联系。 - 提交表示经营者已经收到订单请求，不表示订单已确认或已支付。 - 无法满足套餐、时间或配送要求时，经营者再联系客户。 ## 私厨定制需求 - 私厨无法标准化报价，由经营者人工评估、沟通和报价。 - 必填：称呼、手机号或微信号至少一项、期望日期、用餐人数、用餐地点或区域。 - 选填：预算范围、口味偏好、忌口/过敏信息、菜品偏好和补充说明。 - 私厨不自动计算总价，不公开报价和沟通过程。 ## 客户侧状态与操作 客户侧统一展示： ```text 已收到 -> 沟通中 -> 已确认 -> 已完成 \-> 已取消 ``` - “已确认”只表示经营者接受履约，不表示已经支付。 - 客户仅可在“已收到”状态取消。 - 客户不能直接编辑已提交订单；需要修改时取消后重新提交，或联系经营者。 - 私厨只展示粗粒度状态，不要求经营者录入菜单、报价和沟通细节。 ## 后台处理 - 区分普通套餐订单和私厨需求。 - 支持未读标记、状态更新和内部备忘。 - 支持预设标签和管理员自定义标签，一个订单可使用多个标签。 - 建议预设标签：普通套餐、私厨、配送、自取、熟客、重点跟进。 - 标签、备忘、报价和内部沟通内容不得返回客户接口。 - 后台订单可靠落库、未读数和待处理数属于 P0。 - 微信订阅消息属于 P1；仅在主体、服务类目和模板允许时启用，发送失败不得影响订单落库。 ## 数据模型增量 `Booking` 增加或明确： ```text customer_user_id request_type package | private_chef contact_preference wechat | phone | none fulfillment_type pickup | delivery | null requested_time delivery_address estimated_amount 单位为分，仅普通套餐预计金额 extra_data 受控行业扩展字段 is_read status received | contacting | confirmed | completed | cancelled ``` 新增： - `CustomerUser`：保存 OpenID 和登录时间。 - `BookingItem`：保存套餐名称、单价、数量和小计快照。 - `Tag`、`BookingTag`：保存预设/自定义标签及订单关联。 `Booking` 不包含 `paid` 或 `payment_status`。未来支付仍使用独立的 `Order`、`Payment` 和 `Refund` 模型。 ## API 增量 ```text POST /api/customer/session/wechat GET /api/customer/bookings GET /api/customer/bookings/:id POST /api/customer/bookings/:id/cancel PATCH /api/admin/bookings/:id/read GET /api/admin/tags POST /api/admin/tags PUT /api/admin/bookings/:id/tags ``` 所有客户订单接口必须使用服务端登录态解析 OpenID。只有 `received` 状态允许客户取消。 ## 待确认项 普通套餐采用固定菜单、每日菜单，还是“固定套餐 + 每日可用状态”，仍需朋友结合真实维护习惯确认。第一版不得提前实现复杂每日菜单、库存或截止时间规则。