wx/hl-api-changelog
1
0
派生 0
代码 工单 合并请求 Actions 软件包 项目 版本发布 百科 动态
hl-api-changelog/changelogs-v2/2026-06/17_新建订单第3步基本信息_聊天解析接口+来源标签人数档全走v3字典-管理后台.md

5.3 KiB
原始文件 Blame 文件历史

【新增接口 + 前端对接·管理后台】新建订单第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。