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

## 1. 目标

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

## 2. 三层模型

### 品牌核心层

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

### 行业配置层

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

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

### 行业流程层

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

## 3. 数据设计原则

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

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

## 4. 餐饮试点落地

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

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

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

## 5. 稳定的核心接口

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

## 6. 决策规则

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