diff --git a/changelogs-v2/2026-06/17_新建订单第3步基本信息_聊天解析接口+来源标签人数档全走v3字典-管理后台.md b/changelogs-v2/2026-06/17_新建订单第3步基本信息_聊天解析接口+来源标签人数档全走v3字典-管理后台.md
new file mode 100644
index 0000000..a6f89a2
--- /dev/null
+++ b/changelogs-v2/2026-06/17_新建订单第3步基本信息_聊天解析接口+来源标签人数档全走v3字典-管理后台.md
@@ -0,0 +1,70 @@
+# 【新增接口 + 前端对接·管理后台】新建订单第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。