Scenario 25: Uber/滴滴 打车平台
V1 — 1人用：纯前端地图+预估价格
Section titled “V1 — 1人用：纯前端地图+预估价格”你想做一个打车应用原型，体验地图选点和价格预估。
你要解决什么
Section titled “你要解决什么”- Leaflet地图展示
- 手动输入或点选起终点
- 显示直线距离和预估价格
- 不同车型（快车/专车）价格对比
给AI的Prompt
Section titled “给AI的Prompt”用HTML+CSS+JS+Leaflet做一个打车页面。地图全屏，底部浮层操作区。 用户点击地图选择起点（绿色标记）和终点（红色标记），画直线连接。 计算直线距离（Haversine公式），预估价格=起步价8元+每公里2.5元（快车） 或起步价15元+每公里4元（专车）。底部显示两种车型的预估价格和预计时间。 历史叫车记录存localStorage（起终点、价格、时间）。支持地址搜索框 （用Nominatim免费API反查坐标）。
- 地图点选起终点标记正确
- 距离计算和价格预估合理
- 两种车型价格对比展示
- 地址搜索返回正确位置
你学到了什么
Section titled “你学到了什么”- Leaflet地图集成 → Module: 地图API
- Haversine距离公式 → Module: 地理计算
- 地理编码 → Module: 位置服务
V2 — 10人用：乘客发单+司机接单
Section titled “V2 — 10人用：乘客发单+司机接单”需要真实的发单和接单流程，乘客和司机双端。
你要解决什么
Section titled “你要解决什么”- 乘客发起叫车请求
- 司机列表和简单匹配（最近的空闲司机）
- 司机接单/拒单
- 订单状态流转
给AI的Prompt
Section titled “给AI的Prompt”Go+Gin后端，SQLite。用户表（id, name, role: rider/driver, lat, lng）， 订单表（id, rider_id, driver_id, pickup_lat/lng, dest_lat/lng, status, price, created_at）。 乘客叫车：POST /api/orders（起终点坐标），系统查找最近的空闲司机 （Haversine距离排序，取最近3个）。推送给最近司机（轮询模拟）， 司机接单POST /api/orders/:id/accept 或拒单。 订单状态：waiting→accepted→picked_up→completed→rated。 司机端页面：显示附近订单，一键接单。乘客端：等待接单动画，显示司机信息。
- 叫车后匹配到最近空闲司机
- 司机接单后订单状态更新
- 订单状态流转完整
- 乘客端显示司机信息
你学到了什么
Section titled “你学到了什么”- 地理位置匹配 → Module: LBS基础
- 订单状态机 → Module: 状态机设计
- 双端交互设计 → Module: 多角色系统
V3 — 100人用：实时位置+PostGIS
Section titled “V3 — 100人用：实时位置+PostGIS”需要实时追踪司机位置，用空间数据库高效查询附近司机。
你要解决什么
Section titled “你要解决什么”- WebSocket实时上报司机位置
- PostGIS空间查询（范围内的司机）
- 实时地图展示司机位置
- 行程实时追踪
给AI的Prompt
Section titled “给AI的Prompt”PostgreSQL + PostGIS扩展。司机位置表（driver_id, location GEOGRAPHY(Point, 4326), status, updated_at）。司机端WebSocket每5秒上报位置，更新数据库。 匹配查询：ST_DWithin(location, ST_MakePoint(lng,lat)::geography, 3000) 查找3公里内空闲司机，按距离排序。GIST索引加速空间查询。 乘客端WebSocket：接单后实时推送司机位置（每3秒），地图上显示司机移动轨迹。 行程追踪：接单后记录司机轨迹点（存表），行程结束后根据实际轨迹计算里程和费用。 实际距离用轨迹点累加（非直线距离）。
- WebSocket位置上报稳定
- PostGIS范围查询正确返回附近司机
- 乘客端实时看到司机移动
- 实际里程计算基于真实轨迹
你学到了什么
Section titled “你学到了什么”- PostGIS空间查询 → Module: 地理信息系统
- WebSocket实时通信 → Module: 实时推送
- 轨迹里程计算 → Module: GPS数据处理
V4 — 1000人用：动态定价+ETA预估
Section titled “V4 — 1000人用：动态定价+ETA预估”高峰期供不应求，需要动态调价平衡供需。
你要解决什么
Section titled “你要解决什么”- 供需比计算（某区域的乘客请求数/空闲司机数）
- 动态溢价系数
- 预估到达时间（ETA）
- 价格透明度（展示溢价原因）
给AI的Prompt
Section titled “给AI的Prompt”区域划分：将城市划分为网格（每格1km x 1km，用geohash前6位）。 供需计算：每个网格统计最近5分钟的叫车请求数和空闲司机数，计算供需比。 动态定价：供需比>2时开始溢价，系数=min(供需比0.5, 3.0)，即最高3倍。 价格=基础价溢价系数，前端明确展示”当前需求较高，价格上浮X倍”。 ETA预估：根据司机到起点的直线距离，乘以道路系数1.4（模拟实际路程）， 除以平均车速30km/h，得到预估分钟数。Redis缓存各区域的供需数据（30秒TTL）。
- 供需比正确反映区域热度
- 溢价系数不超过上限3倍
- 价格页面清晰展示溢价原因
- ETA预估误差<30%
你学到了什么
Section titled “你学到了什么”- Geohash区域划分 → Module: 空间索引
- 动态定价算法 → Module: 定价策略
- 供需平衡 → Module: 市场机制
V5 — 1万人用：多因子匹配+订单状态机
Section titled “V5 — 1万人用：多因子匹配+订单状态机”简单的”最近司机”匹配不够，需要综合多个因素分配最优司机。
你要解决什么
Section titled “你要解决什么”- 多因子匹配评分（距离+评分+顺路+接单率）
- 完整的订单状态机（含取消、异常、投诉）
- 司机调度优化（减少空驶率）
- 服务质量监控
给AI的Prompt
Section titled “给AI的Prompt”多因子匹配：对候选司机打分，score = 距离分0.4 + 评分分0.2 + 顺路分0.3 + 接单率0.1。 距离分：3km内100分，线性递减到0分（10km）。评分分：司机评分20。 顺路分：司机当前行驶方向与去接乘客方向的夹角，<30度100分，线性递减。 接单率：最近50单的接单率100。取得分最高的司机派单。 订单状态机完整版：waiting→matched→driver_arriving→picked_up→in_trip→completed。 异常状态：cancelled_by_rider, cancelled_by_driver, no_driver_found, disputed。 取消规则：司机接单前免费取消，接单后3分钟内免费，超过收取5元取消费。 质量监控：差评订单自动触发回访，投诉工单系统。
- 多因子打分合理，最优司机被分配
- 所有状态流转路径正确
- 取消规则按时间正确计费
- 差评触发自动回访流程
你学到了什么
Section titled “你学到了什么”- 多因子评分模型 → Module: 匹配算法
- 复杂状态机 → Module: 状态机设计进阶
- 服务质量管理 → Module: SLA管理
V6 — 10万+用户：全城调度+拼车
Section titled “V6 — 10万+用户：全城调度+拼车”全城海量订单，需要全局最优调度和拼车降本。
你要解决什么
Section titled “你要解决什么”- 区域分片调度（城市分区，区域内独立调度）
- 跨区域调度（边界区域的司机共享）
- 拼车算法（顺路匹配+动态拼单）
- 热力图预测+运力预调度
给AI的Prompt
Section titled “给AI的Prompt”区域分片：城市按行政区分片，每个分片独立的调度服务实例。 边界处理：边界2km范围内的司机同时注册到相邻分片，跨区订单两个分片协调。 拼车算法：新订单进来，检查是否可拼入已有行程——条件：顺路度>70%（新增绕路<30%）， 车内<3人，预计延长时间<10分钟。拼车价格=独乘价*0.7。 热力图预测：用前几周同时段数据，预测未来30分钟各区域的订单量。 运力预调度：预测高需求区域提前引导空闲司机前往（推送”前往XX区域接单奖励+5元”）。 全局Dashboard：实时订单热力图、运力分布、平均等待时间、拼车率。
- 分片调度各区域独立运行
- 跨区域订单正确协调
- 拼车匹配顺路度计算准确
- 预测引导后高需求区域等待时间下降
- 热力图实时更新延迟<1分钟
你学到了什么
Section titled “你学到了什么”- 分片调度架构 → Module: 分布式调度
- 拼车算法 → Module: 路径优化
- 需求预测 → Module: 时序预测