系统难度与我们的实现
旅行服务的“库存”是一段可履约的时间。 同一服务商品可以配置小时制、全天制和不同服务日期。推荐时要理解商品，预订时要处理真实排期，商家还要能持续维护这些信息。
| 难点 | 项目中的具体实现 | 体现的能力 |
|---|---|---|
| AI 对话需要连接业务 | 接入通义千问，结合会话历史，提取推荐关键词，再查询商品搜索视图生成卡片 | 大模型接入、会话系统与业务服务编排 |
| 境外服务有时区差异 | 按服务城市时区校验日期和服务窗口，转换成 UTC 时间用于订单占用 | 时间模型与跨地区预约业务设计 |
| 套餐不是普通规格 | 区分小时和全天套餐，维护时长、天数、可服务日期、时间窗口与价格 | 复杂商品建模和商家配置工具 |
| 多人可能争抢同一时段 | 按套餐和日期加 Redis 锁，再检查重叠订单；跨日套餐按排序后的日期取得锁 | 并发控制与预约状态设计 |
| 预占不能永久阻塞资源 | 订单带预占过期时间；RabbitMQ 延时消息触发超时取消，排期计算区分有效预占和已过期订单 | 异步任务和资源生命周期处理 |
| 两类数据库需要协同 | MySQL 承担订单主记录与索引；MongoDB 保存套餐、订单快照和会话；失败写入记录同步状态并进入补偿任务 | 数据分层、状态追踪与补偿机制 |
| 用户、商家、运营各有任务 | 用户端查询与预约、商家端维护商品与套餐、管理端处理审核及运营 | 多端产品交付和业务权限建模 |
产品与业务界面
以下为项目商家 PWA 的源码组件隔离预览。使用原有组件与样式，仅替换接口为本地只读演示数据，禁用保存和上传。截图中的标题、地区、价格与日期用于说明配置，不代表真实报价或订单；不是线上运行截图。
商品：从地区到履约资源
商品表单将服务国家、城市、描述与车辆品牌、车型、乘客容量、行李容量放在同一业务对象中，并维护车辆行驶证、车辆照片、司机资料及驾驶证。前台看到的服务，背后需要商家维护完整的履约信息。
套餐：小时制与全天制
同一商品下建立不同套餐。小时制用分钟表达套餐时长，全天制使用服务天数；价格以分提交。服务端还会核对商家归属、有效日期和服务窗口，不能只依赖前端表单。
时间、日期与价格
配置入口同时涉及服务开始和结束时间、套餐时长、服务日期及价格。当前截图中的日期选择器属于源码内固定日期的演示控件；真实日期范围、连续天数和占用判断以服务端规则为依据。
系统架构
| 层级 | 分工 |
|---|---|
| 用户端 | uni-app 页面和 App / 小程序适配；会话、商品与预约入口 |
| 商家移动端 | React PWA 的商品、套餐与商家工作页面；产品配置接口已经接入，部分订单和消息页面仍为演示数据 |
| 管理后台 | Vue / Element UI，商家管理、旅行订单、分享内容审核及运营维护 |
| 业务服务 | Spring Boot 的用户、商家与管理模块；共享排期计算、鉴权、订单与同步任务 |
| AI 服务 | 通义千问接入、关键词提取、会话持久化、语言识别及翻译检索 |
| 数据与基础设施 | MySQL、MongoDB、Redis 与 RabbitMQ，共同支撑查询、预占和异步补偿 |
技术基础包含既有 mall 框架；工程价值体现在旅行业务扩展、多端组织、AI 集成、排期与订单规则，以及迁移和补偿工作。App 上架、小程序发布状态及当前线上环境需结合对应版本核对。
多端协同与后台管理
让供给端维护可销售的服务
商家服务端根据当前商家身份核对商品和套餐归属。服务时区从商品所在城市取得，减少前端任意填写造成的时间口径差异。商家端要把地区、车辆、司机、套餐和日期配置连起来，用户端才能获得有业务意义的服务信息。
| 角色 | 工作范围 |
|---|---|
| 旅行用户 | 提出需求、查看推荐商品、选择服务套餐与时间、确认或取消预约 |
| 商家 | 维护车辆和司机资料，配置商品、服务窗口、小时或全天套餐及可服务日期 |
| 运营人员 | 管理商家资料、旅行订单、内容审核和业务记录 |
| 系统任务 | 处理预占过期、同步失败与扩展数据补偿 |
将页面状态与服务端规则接起来
共享排期计算把城市时区、服务日期、每日服务窗口和已有订单转换成日期摘要及小时格。它区分待确认、待服务、服务中和空闲状态，并计算占用情况，供不同管理和商家入口使用。
这项能力的难点在于统一规则：用户的日期选择、商家的套餐配置、后台的排期视图，都要理解同一份服务时间与订单状态。
关键工程实现
AI：从对话到真实商品卡片
- 用户端发送消息与会话编号，服务端读取对应历史对话。
- 通义千问服务构造旅行助手提示词和最近对话，识别
[PRODUCT:关键词]推荐标记。 - 业务服务优先使用 AI 关键词，缺失时从用户消息兜底提取。
- 翻译服务提供中、英、泰、日语言路径，搜索 MongoDB 商品视图，只查询启用且可搜索的套餐。
- 卡片中的商品编号、套餐编号、图片、价格和规格来自商品数据，随消息保存并返回；无结果时使用默认候选，异常时返回降级回复。
这里体现的是对话与业务目录的集成能力。当前推荐卡片并不等于所选日期仍可预订，也没有核对到 AI 自动下单链路；用户预约时仍由订单服务重新校验服务时间和冲突。语言翻译和模型输出的实际质量需要单独评测。
预约：校验、预占、确认与超时
创建预约时，后端核对套餐状态、服务日期、开始时间、计费类型和时区。小时套餐不能超出服务窗口，全天套餐要检查覆盖日期。取得日期锁后再次检查重叠订单，再创建带预占过期时间的订单。
订单确认和取消都校验所属用户及当前状态。超时消息按条件更新订单，已发生状态变化的记录不会被重复取消；排期查询只计算尚未过期的待确认订单及有效服务订单。
这套机制用于协调同一套餐上的并发预约。本次未执行在线下单、压力测试或真实支付，不将源码中的锁和过期机制描述为已证明的生产容量或完整支付结果。
数据：主记录、快照与补偿任务
MySQL 保存可查询和更新的订单主记录，MongoDB 保存订单扩展、商品套餐快照和操作日志。商品修改之后，订单仍需要保留当时的服务和套餐信息。
扩展数据保存失败时，记录失败状态并建立同步任务；任务服务定期读取待处理记录，重放指定类型的写入，保存重试次数、下一次重试时间及错误信息。它将跨库写入异常转化为可追踪的后续工作，避免把“有两个数据库”误当成天然一致。
这项项目体现的能力
| 能力 | 与行项目中的体现 |
|---|---|
| AI 业务集成 | 会话历史、大模型回复、推荐关键词、真实商品卡片与异常降级 |
| 行业业务建模 | 国家城市、车辆司机、小时及全天套餐、服务日期、时间窗口与预约 |
| 多端工程交付 | 用户端 uni-app、商家 React PWA、Vue 管理端与 Spring Boot 服务 |
| 跨地区时间处理 | 城市时区、本地服务时间、UTC 订单区间、跨日服务校验 |
| 并发与异步系统 | 日期锁、区间冲突检查、预占有效期及消息触发取消 |
| 数据演进与恢复 | 主表索引、文档快照、同步状态、补偿任务和操作记录 |
| 长期维护能力 | 共享排期核心、模块化服务、订单文本与日志规范，以及已有针对性测试 |
我们的能力是把模型、界面和业务规则组织成可继续迭代的产品系统。 大模型负责语言交互，商品和订单服务负责业务事实，商家与运营工具承担实际工作。
资料与说明
- 工程依据：
miles-link的mall-app、mall-pwa、mall-admin、mall-api及模块维护资料；本次核对版本cea15c9，工作区未改动。 - 六张原始界面截图来自两组商家源码组件的隔离预览，另有五张按实际代码绘制的工程图；展示图共八张。
- 本次检查源码和界面交互，未连接业务数据库，未调用在线 AI 服务，未执行支付、发布或真实预约。仓库历史测试报告与本次验证区分使用。
- 旧通用商城截图未纳入案例。商家订单和消息页面的演示数据、日期控件的固定示例、App 与小程序发布状态及模型实际效果，不表述为线上验证结果。
- 与行商家 PWA 的当前公开页面标题为“与行出境”，展示邮箱 / 手机号与密码登录、注册和 Google 登录入口。2026-10-08 匿名访问仅核对登录页，未进入受保护的业务页面。
- 当前版本业务实拍及可核对的经营结果，可在取得资料后替换补充；本版不使用无法验证的营收、订单量或效率提升数字。