个人品牌核心与行业扩展策略

1. 目标

产品长期服务的是“个人品牌经营者”，而不是某一个行业。不同职业可以有不同的服务字段和业务流程，但都建立在同一套品牌基础能力之上。第一版以餐饮摊主和私厨为试点，餐饮字段不能写死成所有预约都必须填写的字段。

2. 三层模型

品牌核心层

所有行业共享：品牌资料、服务项目、作品/案例、预约或咨询、客户反馈、内容管理后台。

行业配置层

行业可以配置服务分类、预约字段、字段顺序和必填规则、预约说明、状态文案、作品分类和联系前需要收集的信息。

示例：私厨需要人数、地点、预算、口味和忌口；摄影师需要拍摄类型、人数、地点、日期和交付需求；咨询师需要咨询主题、方式和可接受时段。

行业流程层

只有真实需求证明流程不同，才增加行业专属状态或步骤。第一版不实现流程编排，只使用通用预约状态和可扩展文案。

3. 数据设计原则

品牌名称、服务名称、客户联系方式、期望日期等高频字段保持结构化，便于校验和查询。
行业字段使用受控扩展，不让前端提交任意键名。
第一版可使用 bookings.extra_data JSON 存储行业字段；字段定义由后端配置决定。
建议支持的字段类型：text、textarea、number、date、select、multiselect。
暂不实现插件系统、行业代码复制和通用字段配置后台。

未来可增加 industry_profiles、booking_field_definitions，并让每个品牌选择一个行业模板。模板只提供默认值，不能覆盖品牌已经修改的内容。

4. 餐饮试点落地

通用字段仍放在 bookings：称呼、联系方式、服务、期望日期、备注。餐饮字段放入受控扩展数据：

{
  "guest_count": 6,
  "location": "杭州市西湖区",
  "budget_range": "500-800",
  "taste_preferences": ["家常", "微辣"],
  "allergy_notes": "对花生过敏",
  "dish_preferences": "希望有一道鱼和一道汤"
}

第一版可以固定餐饮字段配置，不需要开发字段配置后台；但 API 必须校验字段名、类型和必填规则。

5. 稳定的核心接口

不同行业都应复用：获取品牌、获取服务和作品、提交预约/咨询、管理员处理预约、提交反馈、审核反馈。行业差异通过配置、扩展数据和状态文案表达。

6. 决策规则

新增行业需求时先判断：这是所有品牌需要的能力，还是行业字段；是否需要查询统计；流程是否真的不同；是否已有第二个真实客户验证；是否影响预约和支付边界。没有重复真实需求时，优先使用配置或 extra_data，不增加行业专用表和页面。

2.8 KiB Raw Permalink Blame History