Appearance
黔游友 - 第一阶段详细技术方案
阶段：第一阶段基础版
目标：五一前上线，验证模式
核心模块：6个功能模块
通俗版：第一阶段要做的事
为什么第一阶段很重要？
我们不是在"做个小程序"，而是在搭建一个能赚钱的智能服务空间。
这6万投下去，我们要在五一前让5辆车变成"移动的智能门店"——游客上车，系统就开始服务；游客下车，我们已经赚到钱。
下面我把六件事重新讲清楚，每一件都会告诉你：做出来是什么样、游客得到什么、车队得到什么、为什么非做不可。
第一件事：车到景点，自动讲解
做出来是什么样？ 你的车开着，快到黄果树了，乘客手机"叮"一声弹出一条消息："前方500米就是黄果树瀑布，需要为您讲解吗？"点开，图文+语音同时出现，像请了个免费导游。
游客得到什么？ 不用自己查资料，不用竖着耳朵听司机喊"左边就是"，安安静静看风景，手机自动讲。
车队得到什么？ 你的车比别人多了一个"AI导游"。同样是跑一趟，乘客记住的是你的车。下次来贵州，还找你。
为什么非做不可？ 因为这是最直接的"体验升级"。游客上车最无聊的时间，被你变成了"涨知识的时间"。这点好感，后面会变成复购。
第二件事：建立自己的景点资料库
做出来是什么样？ 我们把你们跑的线路上的所有景点、服务区、特色村落，一个一个整理成档案：叫什么、有什么故事、有什么好吃的、最佳观赏点在哪儿。
游客得到什么？ 听到的不是百度百科那种干巴巴的词条，而是有温度的故事："这座风雨桥，传说是百年前一个苗族青年为等候心上人而建……"
车队得到什么？ 这个资料库，是你们独有的资产。别的车队想抄，抄不走你们这些年跑出来的经验。谁跑这条线跑得最多？你们。谁最懂这条线上的犄角旮旯？也是你们。
为什么非做不可？ 这是所有功能的基础。资料准，推荐才准；资料好，体验才好。智游黔东南花了大力气建6大主题31类数据，黄小西校准了9.9万项，我们规模小，但道理一样——数据才是真正的护城河。
第三件事：路上推荐买东西（不是推销）
做出来是什么样？ 车经过茶园，手机弹出一条消息："您现在看到的这片茶园，产的是本地明前茶。要不要带一盒尝尝？可以预订，下山后直接去店里拿。" 快到苗寨，弹出："寨子里有家银饰铺，三代人手艺，要不要预约个体验？"
游客得到什么？ 看到的、听到的、买到的是同一件事——刚才路过的地方、刚才听过的故事、现在就能带走的东西。这叫"情境式购物"，不是生硬的推销。
车队得到什么？ 每卖出一单，司机有分成，车队也有分成。而且这个钱不是从游客口袋里硬掏的，是游客本来就想买、你帮他省了事。司机多赚一份钱，车队多一个收入来源。
为什么非做不可？ 传统车队只赚车费，我们能赚"车费+导购佣金"。一趟跑下来，收入可能翻倍。而且这个模式一旦跑通，可以复制到所有线路。
第四件事：记下游客喜欢什么
做出来是什么样？ 系统会自动记：哪些讲解被多听了、哪些商品被多看了、哪些页面停留得久。这些数据不记名字，只记行为。
我们能得到什么？ 一个月后，我们就知道："走这条线的游客，对苗寨文化特别感兴趣，对茶园不太感冒。"有了这个，下次推荐就更准——给对的人推对的东西。
车队得到什么？ 你们手里的不是30辆车，而是30个"数据采集器"。跑得越多，数据越值钱。将来这些数据可以帮沿线商家做决策，甚至可以卖给文旅局做参考。
为什么非做不可？ 黄小西有9.9万项数据，智游黔东南有6大主题31类数据，我们才刚开始。但从第一天就开始存数据，是我们唯一能追上他们的办法。
第五件事：给司机一个赚钱工具
做出来是什么样？ 司机手机上有个小程序，点开就能看到今天赚了多少分成。乘客扫码上车，以后他买的每一单，司机都有份。
司机得到什么？ 以前跑一趟，就是车费。现在跑一趟，可能多赚几十上百。而且随时能看到钱，今天努力今天见，不画大饼。
车队得到什么？ 司机有动力，才会主动让乘客用系统。不用你催，他自己就学会了怎么引导乘客扫码。
为什么非做不可？ 这个系统能不能成，一半靠技术，一半靠司机。让司机赚到钱，他们就是你的推销员；让司机觉得麻烦，他们就是你的阻力。
第六件事：确保内容不出错
做出来是什么样？ 每个景点介绍、每个商品信息，上线前都要有人审核。初审一遍，终审一遍，错了的不让发。
游客得到什么？ 相信你的推荐。说"前方有酸汤鱼"，去了真的有；说"这家银饰三代手艺"，问了确实是真的。
车队得到什么？ 口碑。一次错，可能丢一个客人；一直对，客人会主动推荐你。
为什么非做不可？ 智游黔东南组织商务、网信、市监多个部门审核了73处内容，黄小西花了大力气校准9.9万项数据。他们为什么这么重视？因为一次"AI胡说八道"，可能毁掉用户一辈子的信任。我们规模小，更不能犯错。
这六件事合起来，是什么效果？
对游客： 上车→自动听故事→看到感兴趣的东西→随手买→下车时特产已经送到酒店。全程舒服、自然、不被打扰。
对司机： 引导乘客扫码→乘客买东西→马上看到分成→跑一趟多赚一份钱。动力十足，不用催。
对车队： 你的车从"运人的工具"变成了"移动的智能门店"。别的车队还在比价格，你已经在比体验、比收入。
对项目： 用6万块钱，在五一前把这条路跑通。有真实数据、有真实收入，后面要不要投11万做升级，大家看数据说话——谁出钱、谁占股，都清清楚楚。
最后一句
我们不是在"做个APP"，而是在给你的车装上"AI导游+自动赚钱"的引擎。6万块，不是成本，是投资。投下去，五一就能看到回报。
技术版：详细实现方案
以下是6个核心模块的技术实现细节，包括具体功能、技术实现路径、如何借鉴标杆平台经验、关键注意事项以及交付标准。这将帮助技术团队明确开发方向。
第一阶段模块架构
乘客体验层
LBS触发讲解景点资料库情境导购
↓
司机服务层
司机端界面分润统计扫码引导
平台支撑层
数据收集内容审核
模块一：LBS触发讲解
1.1 具体功能
- 当旅游车辆行驶至预先设定的景点或地标附近时，乘客端小程序自动推送该景点的语音介绍和文字简介
- 支持自动播放（可设置静音模式）和手动点击重播
- 讲解内容与景点位置精确匹配，误差控制在50米以内
1.2 技术实现路径
1. 地理围栏（Geofencing）设置
- 使用高德地图API或腾讯地图API创建圆形/多边形地理围栏，每个景点对应一个围栏
- 设定触发半径：一般景点建议200-300米，视道路情况调整，确保车辆在到达最佳观赏点前触发
2. 实时定位监控
- 小程序通过微信内置的
wx.startLocationUpdate或wx.onLocationChange获取车辆实时经纬度 - 将坐标上传至后端，后端比对当前坐标与所有景点围栏的距离关系
3. 触发逻辑
- 后端维护每个景点围栏的坐标和半径，当车辆坐标进入某个围栏且之前未触发过（避免重复触发），则下发该景点的讲解内容
- 可设置防重复触发机制：同一辆车经过同一景点时，24小时内只触发一次，或根据方向（上行/下行）区分
4. 内容推送
- 后端通过WebSocket或轮询方式通知小程序端有新讲解
- 小程序端播放音频（可使用微信小程序的
InnerAudioContext）和展示文字
5. 离线缓存
- 考虑山区信号不稳定，可将沿线主要景点的讲解内容预先缓存到小程序本地，触发时优先读取本地缓存
1.3 参考借鉴
- 智游黔东南：覆盖了307个关键场所，实现4618个VR全景。我们不需要VR，但可以借鉴其"关键场所覆盖"思路：先覆盖车队沿线的核心景点（约50-100个），再逐步扩展
- 黄小西：AI伴游具备实时问答，但第一阶段我们先做单向推送，为第二阶段智能问答打基础
1.4 难点与应对
| 难点 | 应对方案 |
|---|---|
| 定位漂移 | 在山区或隧道内GPS信号弱，可能导致误触发或不触发。应对：结合道路方向和车辆速度辅助判断；在隧道出口处设置触发点 |
| 触发时机 | 要确保乘客在最佳观赏点听到讲解。需实地测试调整围栏半径和位置 |
1.5 工作量估算
| 任务 | 工作量 |
|---|---|
| 地图围栏配置后台 | 2人天 |
| 定位与触发逻辑 | 3人天 |
| 小程序端音频播放与UI | 2人天 |
| 测试与优化 | 2人天 |
| 合计 | 9人天 |
1.6 交付标准
- 至少完成1条试点线路（如贵阳-黄果树-荔波）上的50个核心景点围栏配置
- 触发准确率≥90%（实地跟车测试20个景点，至少18次正确触发）
- 音频播放流畅，无卡顿
模块二：基础知识库
2.1 具体功能
- 建立一个结构化的景点/POI（兴趣点）数据库，包含每个景点的名称、简介（100-300字）、语音文件URL、图片、所属线路、经纬度、标签（如"自然风光""苗族文化""美食"等）
- 支持内容新增、修改、审核功能（后台管理）
2.2 技术实现路径
1. 数据库设计
- 使用MySQL创建
poi表，字段包括：id、name、description、audio_url、image_url、latitude、longitude、radius（触发半径）、line_id（所属线路）、tags、status（待审核/已通过）、created_at等 - 创建
line表存储线路信息
2. 内容采集
- 人工采集：由团队（可外包或司机协助）收集沿线景点信息，来源包括地方志、旅游局官网、导游词、实地考察
- 确保信息准确：需核对多个来源，避免错误
3. 后台管理界面
- 开发一个简单的web管理后台（可使用Vue+Element UI），供运营人员增删改查POI，并支持音频文件上传（存储至腾讯云COS或阿里云OSS）
- 实现审核流程：新录入内容状态为"待审核"，经指定人员审核通过后方可上线
4. API接口
- 为小程序端提供查询接口：根据景点ID获取详情；根据经纬度获取当前触发景点
2.3 参考借鉴
- 黄小西：团队花了大力气校准9.9万项本地数据，甚至自创"逻辑符号求解器"解决幻觉。我们规模小，但要学习其"人工校准"的核心方法：每个数据点必须经过验证，不能依赖单一来源
- 智游黔东南：6大主题31类数据架构，我们可以简化：第一阶段只建必要字段，但设计时要考虑未来扩展（如增加"民俗故事""特色美食"等子表）
2.4 难点与应对
| 难点 | 应对方案 |
|---|---|
| 内容准确性 | 错误信息会严重影响用户体验。应对：建立多级审核机制（采集→初审→终审），每个景点至少由两人复核 |
| 音频制作 | 需要录制专业语音，成本较高。应对：先用文本转语音（如阿里云语音合成）生成基础版，后期再替换真人录音；或邀请导游志愿者录制 |
2.5 工作量估算
| 任务 | 工作量 |
|---|---|
| 数据库设计与API | 2人天 |
| 后台管理界面 | 4人天 |
| 内容采集与录入（人工） | 5人天（可分包给实习生） |
| 合计 | 11人天 |
2.6 交付标准
- 至少完成试点线路50个POI的采集与录入，全部通过审核
- 后台管理可正常增删改查，支持音频上传
- API接口响应时间<200ms
模块三：情境导购
3.1 具体功能
- 根据车辆当前位置和行程阶段，向乘客推荐相关的商品或服务
- 例如：途经茶园时，推送茶叶商品卡片；临近苗寨时，推送银饰、苗绣体验；接近饭点时，推送沿途特色餐饮预订
- 用户点击商品卡片可查看详情并下单（微信支付），选择"到店自提"或"送达酒店"
3.2 技术实现路径
1. 商品与位置关联
- 在数据库中建立
product表，包含商品名称、描述、价格、图片、商家ID、关联的POI ID（可选）、触发标签（如"茶园""苗寨""餐饮"） - 同时建立
merchant表存储商家信息（名称、地址、联系人、分润比例）
2. 场景触发规则引擎
- 初期采用简单规则：当车辆进入某景点围栏时，查询与该景点标签匹配的商品，推送1-2个
- 也可设置时间触发：如11:00-13:00自动推送餐饮推荐
3. 下单流程
- 小程序内集成微信支付，实现商品购买
- 订单状态管理：待付款、待使用、已完成、退款等
- 为司机分润：订单完成后，按比例（如10%）自动计入司机账户（需司机端展示）
4. 商家通知
- 新订单通过短信或微信模板消息通知商家（第一阶段可先由人工电话确认，后期开发商家端小程序）
3.3 参考借鉴
- 黄小西酒店智能体：将酒店从"成本中心"变"运营中心"，销售周边好物。我们借鉴其"场景+商品"结合思路，但简化落地
- 智游黔东南：400户商家入驻，我们初期只需找5-10家沿线核心商家合作，跑通流程
3.4 难点与应对
| 难点 | 应对方案 |
|---|---|
| 商家合作 | 需要BD人员洽谈，确保商品有竞争力。应对：先找车队熟悉的商家，用"免佣金试用"吸引入驻 |
| 分润结算 | 司机、车队、平台三方分润需清晰。应对：后台设置分润规则，自动计算，按月结算 |
3.5 工作量估算
| 任务 | 工作量 |
|---|---|
| 商品系统数据库与API | 3人天 |
| 下单支付流程 | 4人天 |
| 后台订单管理 | 2人天 |
| 司机分润账户 | 2人天 |
| 合计 | 11人天 |
3.6 交付标准
- 至少接入3家合作商家，上线10个以上可售商品
- 完整走通"触发推荐→查看商品→下单支付→订单通知"流程
- 司机端可查看当日分润
模块四：数据收集
4.1 具体功能
- 记录用户行为数据，包括：页面访问、点击事件、停留时长、位置轨迹、下单行为等
- 为第二阶段用户画像、推荐算法、运营优化提供数据基础
4.2 技术实现路径
1. 埋点设计
- 确定关键事件：进入小程序、触发讲解、点击讲解播放、进入商品列表、查看商品详情、加入购物车、提交订单、支付成功、分享等
- 每个事件携带参数：用户ID（openId）、时间戳、位置、景点ID/商品ID等
2. 数据上报
- 小程序端通过wx.request上报至后端接口
- 可批量上报（每10条或每分钟）减少请求次数
3. 数据存储
- 使用MySQL存储事件表，或用MongoDB更灵活
- 设计事件表
user_behavior：id、openId、event_type、event_params（JSON）、location、created_at
4. 数据可视化（简单版）
- 开发简易后台看板，展示每日UV、PV、触发次数、下单转化率等关键指标
4.3 参考借鉴
- 智游黔东南：6大主题31类数据架构，我们目前不需要那么复杂，但要学习其"数据驱动"理念：从第一天开始就为数据资产打基础
- 黄小西：9.9万项校准数据也是逐步积累的，我们的小规模数据同样珍贵
4.4 难点与应对
| 难点 | 应对方案 |
|---|---|
| 数据隐私 | 必须遵守《个人信息保护法》，用户首次进入小程序需弹窗授权，明确告知收集数据用途 |
| 数据质量 | 需确保埋点无误，避免漏报或错报。应对：测试阶段重点验证数据上报准确性 |
4.5 工作量估算
| 任务 | 工作量 |
|---|---|
| 埋点设计与开发 | 2人天 |
| 数据上报接口 | 1人天 |
| 简易看板 | 2人天 |
| 合计 | 5人天 |
4.6 交付标准
- 小程序端所有关键事件埋点齐全
- 后台可查看近7天核心指标图表
- 数据表结构设计合理，便于后续分析
模块五：司机端界面
5.1 具体功能
为司机提供一个小程序（或在小程序内增加司机身份切换），主要功能：
- 查看当日累计分润、历史收益
- 引导乘客扫码（展示乘客端小程序码）
- 接收订单提醒（如有新订单需司机确认）
- 简单的培训资料（如何使用系统、常见问题）
5.2 技术实现路径
1. 司机账号体系
- 后台录入司机信息，生成唯一司机ID
- 司机首次登录需绑定手机号，关联到司机ID
2. 分润展示
- 从订单系统读取该司机关联的订单分润汇总，实时展示
- 支持按日/周/月筛选
3. 乘客引导码
- 生成乘客端小程序的专属二维码（可携带司机推荐参数），司机可保存到相册或直接展示给乘客扫码
- 乘客扫码后，系统记录该乘客与司机关联，后续订单分润归该司机
4. 订单提醒（可选）
- 若开通商家接单，司机可能需要确认订单。第一阶段可不做，或仅做消息通知
5.3 难点与应对
| 难点 | 应对方案 |
|---|---|
| 司机接受度 | 司机可能嫌麻烦不愿使用。应对：强调"扫码乘客，乘客下单你就有分成"，并设置简单的操作流程，最好一键扫码 |
| 分润计算准确性 | 必须确保分润逻辑无误，避免纠纷。应对：后台详细记录每笔订单的分润明细，支持司机查询 |
5.4 工作量估算
| 任务 | 工作量 |
|---|---|
| 司机端小程序页面开发 | 3人天 |
| 分润统计接口 | 2人天 |
| 二维码生成与绑定 | 1人天 |
| 合计 | 6人天 |
5.5 交付标准
- 司机可登录查看分润
- 能生成专属乘客码
- 分润数据与订单系统一致
模块六：内容审核
6.1 具体功能
- 确保所有推送给用户的讲解内容、商品信息准确无误，杜绝错误或不当内容
- 建立审核流程：内容录入→初审→终审→发布
6.2 技术实现路径
1. 审核状态设计
- 在POI表和商品表中增加
status字段：0待初审，1初审通过待终审，2已发布，3驳回 - 增加
reviewer_id、review_time等记录审核人
2. 审核界面
- 在后台管理系统中，为审核人员提供待审核列表，可查看内容详情并操作通过/驳回
- 驳回时需填写驳回原因
3. 审核流程
- 设立两个角色：初审员（可多人）、终审员（1-2人）
- 初审员对内容进行初步检查（格式、基本事实），终审员做最终确认
4. 内容来源标注
- 每条内容记录来源（如"XX旅游局官网""实地采访""导游口述"），便于追溯
6.3 参考借鉴
- 智游黔东南：组织商务、网信、市监等部门对平台内容开展全面审核，完善73处。我们虽无多部门，但可借鉴其"多重审核"理念
- 黄小西：通过数据校准解决AI幻觉，我们的人工审核正是数据校准的落地
6.4 难点与应对
| 难点 | 应对方案 |
|---|---|
| 审核标准 | 需要制定明确的审核清单（如无政治错误、无歧视、事实准确、语言通顺）。应对：初期由发起人、车队负责人共同制定标准 |
| 效率 | 内容多时审核可能成为瓶颈。应对：先严审核心景点，后续外包给兼职人员 |
6.5 工作量估算
| 任务 | 工作量 |
|---|---|
| 审核状态字段及后台功能 | 2人天 |
| 审核界面优化 | 1人天 |
| 合计 | 3人天 |
6.6 交付标准
- 所有上线内容均经过至少两级审核
- 后台可记录审核历史
- 发布的内容无事实错误（根据实地验证）
综合进度与资源分配
| 模块 | 工作量（人天） | 建议开始时间 | 依赖 |
|---|---|---|---|
| LBS触发讲解 | 9 | 第1周 | 地图API申请 |
| 基础知识库 | 11 | 第1周 | 无 |
| 情境导购 | 11 | 第2周 | 商品数据准备 |
| 数据收集 | 5 | 第1周 | 无 |
| 司机端界面 | 6 | 第3周 | 订单系统 |
| 内容审核 | 3 | 第2周 | 后台完成 |
总计约45人天，按3人团队计算，约3周可完成开发，留1周测试优化，正好赶上五一前上线。
关键成功要素总结
- 实地测试：所有模块必须在真实线路上测试，特别是LBS触发和商品推荐时机
- 内容准确性：宁可少而精，不可多而错
- 司机激励：分润要及时、透明，让司机成为推广主力
- 数据意识：埋点要全，为后续迭代提供依据