# 【新增接口 + 前端对接·管理后台】新建订单第3步「基本信息」：聊天解析接口落地 + 订单来源/标签/人数档统一走 order-v3 与数据字典

> 页面：管理后台 → 新建订单(order-v2/new) 第3步「基本信息」 | 服务：hl-order-service-v3 | PR #3933(聊天解析) + order_create_source 字典补值(运营) | 已合并 dev-v3 + 部署测试服 | 负责：mmg
> 背景：wx 走查第3步,提出 4 点——①订单来源该用字典 ②聊天记录解析后端没接口 ③人数只有成人/儿童缺小童/幼童 ④订单标签该用字典。逐项核实后结论如下。

## ⚠️ 总结论：order-v3 建单接口早已支持来源/标签/4 档人数,这页只需切到 v3 + 用现成字典；后端唯一新增是「聊天解析」接口

**关键**：后台新建订单的「正路」是 **`POST /v3/admin/order`(OrderCreateReqVO)**,它已内置 `createSource`(订单来源)、`tags`(订单标签)、`adultCount/childCount/youngChildCount/babyCount`(成人/儿童/小童/婴儿 4 档)。当前页面硬编码来源/标签、只露 2 档人数,是因为**还在用 order-v2 老建单接口 `/admin/order/create`**(没有这些字段)。→ 前端切到 v3 建单即可,后端这三项零改。

## 1. 🆕 聊天记录解析接口(本次唯一后端新增,PR #3933)

**`POST /v3/admin/order/parse-from-chat`**(经网关 9443,/v3/admin/** 已放行)

- 入参：`{ "text": "客户微信聊天原文(≤2000字)" }`
- 出参 `Result<OrderChatParseRespVO>`(字段名对齐建单 VO,解析不出的留 null,不报错)：

| 字段 | 类型 | 说明 |
|---|---|---|
| customerName | String | 联系人(如「王女士」) |
| customerPhone | String | 11 位手机号(自动去空格/横线归一) |
| adultCount | Integer | 成人数(夫妻/N大/一家N口 推) |
| childCount | Integer | 儿童数(N岁孩子/N小 推) |
| youngChildCount | Integer | 小童数(有明确线索才填) |
| babyCount | Integer | 婴儿数(有明确线索才填) |
| departureDate | LocalDate | 出发日期(5月18日/5.18/2026-05-18,只给月日取最近未来) |
| destinationHint | String | 目的地线索(如「西藏」,供参考) |
| customerRemark | String | 备注/特殊诉求 |

- 实现：**regex**(项目暂无 LLM 集成,先做 regex,准确率有限但把逻辑从前端收口到后端)。前端把弹窗「开始解析」改调此接口,解析结果回填表单各字段(用户可改)。
- 请求示例:
```
POST /v3/admin/order/parse-from-chat
{ "text": "客户：王女士 138 1234 5678\n我们一家三口（夫妻+6岁孩子）想去西藏5月18日出发。希望住高一点的酒店，孩子有点过敏。" }
```
- 想要更高准确率的「真 AI 解析」需另开通大模型(通义/OpenAI),作为后续独立项。

## 2. 订单来源 → 数据字典 `order_create_source`(已补至 5 值)

- 字典 `order_create_source` 现有 5 值(本次补的 3 个 + 原 2 个)：

| dictValue | dictLabel |
|---|---|
| CONSULTANT | 定制师创建(≈定制师代下单) |
| CUSTOMER | C端客户自下单(≈小程序自营) |
| B2B | 同行报名 |
| REPURCHASE | 老客户复购 |
| OTHER | 其他 |

- 前端「订单来源」下拉**改为读字典** `GET /admin/dict/data/order_create_source`(渲染 label,提交 dictValue),建单时把选中的 code 传 `createSource`(走 v3 建单接口)。**不要再硬编码这 5 个**。
- 注:label 措辞如需精确对齐(定制师代下单/小程序自营)可在字典管理页改,字典驱动即生效。正式环境需运营把这 3 个值同样加到 order_create_source 字典(测试服已加)。

## 3. 小童/幼童 → 人数档 4 档已是字典 `traveler_type` + v3 建单已收 4 个 count

- 出行人/人员类型早就是字典 **`traveler_type`**:`ADULT=成人 / CHILD=儿童 / YOUNG_CHILD=小童 / BABY=婴儿`(另有 `traveler_type_age_rule` 年龄规则字典)。
- order-v3 建单 VO 已有 `adultCount / childCount / youngChildCount(小童) / babyCount(婴儿)` 四个数量字段,且真落库、团期人数也按它算。计价(价格日历/班期)也支持 4 档价。
- → 前端第3步把人数从「成人/儿童」2 档扩成**4 档输入**(按 `traveler_type` 字典渲染),建单传 4 个 count。**后端零改**。

## 4. 订单标签 → v3 建单已支持 `tags`(写 order_tag PERSONAL)

- order-v3 建单 VO 有 `tags`(String 列表),建单时写入 `order_tag` 表 tag_type=PERSONAL(个人标签,只对自己可见)。
- → 前端「给订单打标签」选中的标签名放进 `tags` 数组随建单提交(走 v3 建单接口)。预设标签(VIP客户/需要哄/老吐槽党…)若要做成可维护的预设清单,可另建一个 dict(如 order_personal_tag)或用 OrderTag 预置;当前后端接受任意标签名,前端硬编码预设也能直接用。

## 前端 TODO 清单(mmg)
1. 第3步「开始解析」→ 调 `POST /v3/admin/order/parse-from-chat`,回填表单。
2. 建单整体切到 `POST /v3/admin/order`(若还在用 v2 `/admin/order/create`),以拿到 createSource/tags/4 档 count 能力。
3. 订单来源下拉 → 读 `order_create_source` 字典,提交 code。
4. 人数 → 4 档(按 traveler_type 字典),提交 adult/child/youngChild/baby count。
5. 订单标签 → 选中标签名进 tags 数组提交。

> 说明:②是后端新增已实测;①字典已补(正式待运营加值);③④是 v3 建单 + 现成字典,后端无新增,核心是前端切 v3。
