【社会服务】城驿达——城乡定制班车智能接客优化方案（复赛）

TRAE AI 创造力大赛 【大赛复赛专区】
1

【社会服务】城驿达——城乡定制班车智能接客优化方案

自己 / 团队介绍

大家好，我是一名计算机专业研二学生。Vibe Coding 半年左右，这次是组队参赛。

  • 队长（我）：负责整体架构设计、需求梳理、任务分配和时间把控
  • 队员：负责小程序具体代码实现

我们两人都是第一次用 TRAE 从零搭建一个完整产品。从初赛到复赛，经历了代码崩溃、推倒重来、深夜调试，最终把一个真实可用的微信小程序交到了评委面前。编程这件事，在 TRAE 的加持下，变得不再只是"能不能写出来"，而是"能不能想清楚"——这大概是我们最大的收获。

产品简介

是什么

城驿达是一款微信小程序，解决城乡定制班车"乘客等司机、司机找乘客"的双向等待痛点。提供从查询班次、在线预约、司机接客导航到行程跟踪的完整闭环。

面向谁

  • 核心用户：往返县城与省市的定制班车乘客
  • 次要用户：定制班车司机、运营调度员

完整功能与用户路径

乘客端完整流程：

登录（支持演示一键登录）
→ 选择路线（如：周至县 → 西安市）
→ 选择日期 + 班次
→ 填写姓名、人数、上车点
→ 确认预约（系统自动校验发车时间，过期班次不可预约）
→ 查看订单详情

司机端完整流程：

登录（演示一键登录，自动加载 3 位待接乘客）
→ 查看今日接客任务（乘客列表 + 上车点）
→ 点击"开始导航"
→ 系统自动生成 3 条接客路线方案（全排列 + 距离计算 + 排序）
→ 选择推荐路线，按最优顺序接客
→ 逐个标记"已接"→“已出发”→“已送达”

调度员端： 查看所有班次和订单状态，全局掌握运营情况。

完整功能清单：

模块 功能 状态
登录 微信手机号一键登录 + 三角色演示快捷入口 :white_check_mark:
路线 云数据库动态加载可用路线 :white_check_mark:
班次 按日期+路线查询，按需自动生成班次 :white_check_mark:
预约 在线预约 + 人数选择 + 上车点填写 :white_check_mark:
时间校验 已发车班次自动拒绝预约 :white_check_mark:
订单 查看/取消预约 :white_check_mark:
司机导航 全排列路径规划，3 条路线方案对比 :white_check_mark:
司机操作 标记接客/出发/送达状态 :white_check_mark:
演示数据 一键生成演示班次和订单（云数据库） :white_check_mark:
数据持久化 CloudBase 云数据库 + 云函数 :white_check_mark:

相比初赛 Demo 的升级

初赛 Demo 复赛成品
本地 localStorage 模拟数据 CloudBase 云数据库，数据真实持久化
无后端逻辑 7 个云函数（login / getRoutes / getSchedules / createBooking / getMyBookings / cancelBooking / seedDemoData）
过期班次仍可预约 发车时间校验，已发车班次自动拒绝
无演示入口，需手动输入 三角色一键演示登录，评委零门槛体验
司机导航页面缺失 全排列路径规划，3 条路线方案智能推荐
单一角色测试 乘客 + 司机 + 调度员三端完整闭环

产品演示视频

产品创作历程

灵感来源

想法源于我无数次真实的乘车体验。每次预约成功后，我都要凭经验估算出门时间，常常在路边干等二三十分钟；而司机师傅则要一边开车一边回忆乘客地址，偶尔还得停在路边翻手机找电话号码。这些日常的"小摩擦"就是灵感的来源。

从初赛到复赛的演进

初赛阶段，我们搭建了一个基于 localStorage 的 Demo，能跑通基本的预约流程，但数据不持久化、班次不会过期校验、司机端导航页面只有骨架没有实质内容。

复赛阶段，我们做了三件大事：

第一件：上云。 把数据从 localStorage 搬到 CloudBase 云数据库，写了 7 个云函数处理所有业务逻辑。这是整个复赛最大的技术跨越。

第二件：修 Bug。 初赛时，即使班次已经发车，乘客仍然可以预约——这在真实运营中会引发严重问题。复赛在 createBooking 云函数中加入了时间比对逻辑，已发车班次直接拒绝预约。

第三件：做完整。 司机端导航页面实现了全排列路径规划算法，自动生成 3 条接客路线方案，按总距离排序推荐最优路线。同时加入三角色演示登录，评委一键即可体验完整流程。

关键问题与解决思路

最惊险的一次： 当我们把代码从 localStorage 改到云数据库时，整个项目崩溃了。微信开发者工具模拟器一直运行，但界面一片空白，没有任何报错提示。排查了很久才发现，是因为多个页面同时调用了同一个云函数，而云函数返回的数据结构变了，前端没有同步适配。最终我们不得不回退到初赛代码，一行一行重新迁移，这次每改一个页面就测试一次，确保不再次崩溃。这个教训让我们深刻理解了"小步快跑、逐页验证"的重要性。

TRAE 实践过程

第一步：需求对齐与架构设计

向 TRAE 描述业务场景：周至县到西安市的班车服务，核心痛点是多点接客效率低、信息不透明。TRAE 快速生成了包含地图组件、多角色（乘客/司机/调度员）的基础框架，并帮助梳理了云函数架构（7 个云函数，每条对应一个独立业务逻辑）。

第二步：本地模拟 → 云端迁移

这是复赛最大的技术决策。初赛用 localStorage 跑通流程后，决定迁移到 CloudBase。TRAE 帮助完成了：

  • 7 个云函数的创建和编写
  • cloudbaserc.json 配置文件
  • 前端 api.js 统一调用封装
  • 数据库集合设计（routes / schedules / bookings）

第三步：司机智能导航算法

TRAE 帮助实现了司机端"智能规划接客路径"的完整算法：全排列枚举所有接客顺序 → 计算每条路线的总距离 → 排序取 Top 3 → 推荐最优路线。这是整个产品技术含量最高的模块。

第四步：UI/UX 细节打磨

经历了大量调参过程（padding、line-height、选择器优先级等），TRAE 展现了很好的迭代能力，不是机械执行，而是帮助梳理所有关联点，确保没有遗漏。

开发关键步骤截图

image
image2560×1380 377 KB

image
image2560×1380 428 KB

image
image2560×1380 426 KB

Session ID

  • 98330531869548:449d366720380b3f98c7fe7f2f754329_6a768a40885d2d2f3d7c89a4.6a768e54885d2d2f3d7c8a44.6a768e54885d2d2f3d7c8a42:TRAE SOLO..no_sid.no_ppe.T(2026/8/8 10:03:00)–代码报错后的修改
  • 98330531869548:7843670a99030a7211921311bb382ec7_6a768a40885d2d2f3d7c89a4.6a768b63885d2d2f3d7c8a2e.6a768b63885d2d2f3d7c8a2c:TRAE SOLO..no_sid.no_ppe.T(2026/8/8 09:50:27)–用于云函数的创建
  • 98330531869548:9b43bc4572e3c891091bbc03adc34277_6a768a40885d2d2f3d7c89a4.6a769545885d2d2f3d7c8a95.6a769545885d2d2f3d7c8a93:TRAE SOLO..no_sid.no_ppe.T(2026/8/8 10:32:37)–针对订单页面乱码的修改
  • 98330531869548:1c106195ff56949f0f1d41fa6d27a10c_6a768a40885d2d2f3d7c89a4.6a7699dd885d2d2f3d7c8abb.6a7699dd885d2d2f3d7c8ab9:TRAE SOLO..no_sid.no_ppe.T(2026/8/8 10:52:13)–用于增加演示的账号
  • 98330531869548:25d0248869a31989c4c2327a12f8eca5_6a768a40885d2d2f3d7c89a4.6a769c8c885d2d2f3d7c8b00.6a769c8c885d2d2f3d7c8afe:TRAE SOLO..no_sid.no_ppe.T(2026/8/8 11:03:40)–先给我修改的计划方案，等我确认后再修改代码
  • 98330531869548:c9391271e1b54cf26c582965c32fd6a1_6a768a40885d2d2f3d7c89a4.6a769fe8885d2d2f3d7c8b8d.6a769fe8885d2d2f3d7c8b8b:TRAE SOLO..no_sid.no_ppe.T(2026/8/8 11:18:00)–用于数据缓存有问题的debug

技术栈

层 技术
前端 微信小程序原生框架 + WXML + WXSS + JavaScript
后端 腾讯 CloudBase（云函数 + 云数据库）
数据库 CloudBase 文档型数据库（routes / schedules / bookings 三个集合）
算法 全排列枚举 + 距离计算 + 排序推荐（司机接客路径规划）

关键实现思路

  1. 班次懒加载机制：getSchedules 云函数首次查询某路线+日期时，自动根据路线信息和固定时间表生成 15 个班次并写入数据库，后续查询直接命中缓存
  2. 防重复预约：seedDemoData 云函数按"乘客名+司机+日期+时间"四元组去重，避免演示数据重复堆积
  3. 过期班次拦截：createBooking 云函数在创建订单前，比对当前时间与班次发车时间，已发车则拒绝预约

社会价值

当前城乡定制客运的预约工具基本只解决了"报名"问题，在"接客"环节存在明显功能空白。城驿达通过智能路线规划和状态同步，让司机和乘客的信息不对称大幅降低，直接提升城乡客运效率。

未来迭代规划

  1. WebSocket 实时位置共享：实现司机端与乘客端真正的数据互通，乘客可实时查看司机位置
  2. 发车倒计时提醒：距离发车不足 30 分钟，前端显示"即将发车"标签并锁定预约入口
  3. 运营数据看板：为调度员增加数据统计大屏，展示班次上座率、热门路线等