1.1 总体结论

建议采用：

一期以 C 档“手动附近导览”为兜底，以 A 档“前台伴随导览”为核心验证能力；暂不做 B 档真后台持续定位；音频采用服务端预生成并支持离线下载。

这个组合符合微信小程序的真实能力边界，也符合阿里地区“弱网、长距离、车上和徒步中使用、用户不适合频繁阅读”的场景。

但不能把 A 档描述成“持续稳定自动导航”，也不能把 B 档简单理解为“调用一个 API 就能解决后台导览”。微信小程序位置回调、后台存活、系统省电策略、用户授权和审核都存在不确定性。

1.2 对现有 C/A/B 三档方案的判断

关键技术边界

1. wx.getLocation 适合用户主动获取当前位置。
2. 前台持续位置更新应基于 wx.startLocationUpdate 配合 wx.onLocationChange，不能依赖不存在的原生 geofence API。
3. 位置更新频率由微信、设备、系统和定位环境决定，不能对业务承诺“每 1—2 秒稳定回调”。
4. 页面切后台或锁屏后，前台位置回调可能停止，A 档不能等同于后台服务。
5. wx.startLocationUpdateBackground 即使技术上可调用，也涉及单独授权、类目和审核要求，不能作为一期基础依赖。
6. 播放音频可采用 wx.createInnerAudioContext 进行页面内播放；如果要支持切后台继续播放，应评估 wx.getBackgroundAudioManager() 的适用性、平台审核及机型兼容性，不能只在配置文件中声明能力后视为可靠。

1.3 团队研究中存在的盲区

盲区一：把“有位置回调”想当然地等同于“能稳定自动播报”

位置回调可能受到以下因素影响：

• GPS 在峡谷、山体、建筑附近产生漂移；
• 用户拒绝或关闭定位授权；
• 页面进入后台；
• 系统省电策略限制；
• 设备定位能力差；
• 微信运行时暂停或重启小程序；
• 位置回调间隔变长或暂时中断。

因此，自动播报必须设计成“尽力而为”，并提供：

• 当前导览状态；
• 最近一次定位时间；
• 手动点播入口；
• 漏播后的附近点位列表；
• 重复播放控制；
• 离线包状态。

盲区二：只设计“进入围栏”，没有设计“离开、重复和方向”

单纯判断“当前位置距离 POI 小于 300 米”会产生误播：

• GPS 在边界内外来回跳；
• 车辆经过同一位置时重复触发；
• 用户实际远离 POI，但位置仍落在圆形范围内；
• 多个点位围栏重叠；
• 用户在景点内停留时反复回调。

至少需要：

• 进入阈值；
• 离开阈值；
• 连续确认；
• 冷却时间；
• 已播状态；
• 同时命中时的优先级；
• 前进方向或线路顺序判断。

盲区三：音频生成完成不等于内容可上线

宗教文化内容的风险不在 TTS 技术，而在：

• 把传说说成史实；
• 把民间说法说成宗教权威结论；
• 把“转山起点”等未经核实说法写成确定事实；
• 过度商业化或消费信仰；
• 藏语、汉语翻译的语义偏差。

音频生成前必须经过内容审核，不应让后台修改后自动无审核上线。

盲区四：只看播放量，无法证明商业价值

“自动播放次数多”不等于功能有效。需要同时回答：

1. 用户是否愿意使用；
2. 用户是否真的听完；
3. 位置触发是否准确；
4. 音频是否带来停留和线路使用；
5. 是否促进商户咨询、预订或其他转化；
6. 相比普通图文页面，是否值得持续投入。

2. 完整产品方案

2.1 产品定位

产品名称建议：

阿里路上·位置语音导览

核心承诺不是“任何时候自动讲解”，而是：

用户选择线路并开启导览后，在小程序前台保持打开时，系统会根据当前位置，尽量在接近已配置点位时播放简短讲解；无网时可播放已下载的离线音频。

一期重点验证三个假设：

2.2 功能范围

一期功能

一期明确不做

• 页面关闭后的长期持续定位；
• 锁屏后保证自动触发；
• 全地区任意位置自动识别；
• 实时语音合成；
• 没有经过核实的景点事实自动生成；
• 复杂的语音问答；
• 依赖在线地图或实时道路规划的复杂导航。

2.3 三类用户旅程

A. 自驾游客

推荐使用方式

1. 到达塔尔钦或出发前；
2. 选择“塔尔钦周边”或具体线路；
3. 下载离线音频包；
4. 将手机放在车载支架上；
5. 点击“开启伴随导览”；
6. 前台保持导览页；
7. 接近点位时自动播放；
8. 音频结束后展示“附近住宿 / 餐饮 / 补给 / 交通”；
9. 到达服务点后可进入商户详情或发起咨询。

设计重点

• 不要求司机频繁操作；
• 自动播放前有短提示音；
• 播放中只显示大字号标题和暂停按钮；
• 提供“本次不再自动播报”；
• 不把手机操作设计成驾驶任务；
• 页面提示“请由乘客操作，驾驶中勿操作手机”。

B. 徒步转山用户

推荐使用方式

1. 进入转山相关页面；
2. 选择已有的 21 个点位体系或后台配置线路；
3. 下载音频包；
4. 开启“徒步导览”；
5. 进入点位围栏后播放 30—90 秒讲解；
6. 页面显示点位名称、简短说明和当前位置状态；
7. 用户可手动点播漏掉的点位；
8. 结合已有 kora-checkin、kora-track、kora-timer 使用。

设计重点

• 弱网下优先播放本地音频；
• 低频定位，降低耗电；
• 不要求持续看屏幕；
• 高海拔环境下避免强制连续操作；
• 点位触发与打卡能力解耦，不能因定位失败影响打卡。

C. 朝圣者

推荐使用方式

1. 进入线路导览；
2. 选择语言和讲解风格；
3. 下载音频包；
4. 以手动点播和低打扰自动播报为主；
5. 讲解用词尊重、克制；
6. 对宗教相关内容明确区分“当地传说”“资料记载”“平台整理”；
7. 用户可关闭商业推荐，仅保留导览。

设计重点

• 不强制推送商业内容；
• 不把宗教活动当作娱乐化内容；
• 不用“必看、正统、最灵验”等未经依据的表述；
• 支持完全关闭自动播报。

2.4 页面结构

建议页面结构如下：

导览首页
├── 选择线路
├── 附近有什么
├── 开启伴随导览
├── 离线音频包
└── 导览说明与授权状态

线路详情页
├── 线路简介
├── 点位列表
├── 已下载状态
├── 开始导览
└── 查看全部讲解

伴随导览页
├── 当前状态
│   ├── 导览中
│   ├── 等待定位
│   ├── 已暂停
│   └── 定位异常
├── 当前点位 / 下一个点位
├── 播放控制
├── 本次已听
├── 附近点位
├── 手动点播
└── 关闭自动播报

点位详情页
├── 标题
├── 图片
├── 音频播放
├── 文稿
├── 内容来源说明
├── 相关商户
└── 反馈入口

离线包管理页
├── 线路包列表
├── 下载进度
├── 占用空间
├── 删除离线包
└── 更新提示

2.5 授权与首次使用流程

首次使用流程

点击“开启伴随导览”
→ 展示功能说明
→ 请求用户授权位置
→ 授权成功
→ 选择线路
→ 检查音频包
→ 建议下载离线包
→ 用户确认后启动前台导览

授权文案建议

开启位置导览后，小程序会在您打开导览页面时，根据当前位置判断附近是否有已配置的讲解点位。位置主要用于本次导览，不用于展示您的精确行程。关闭页面或退出导览后，前台导览会停止。

如果用户拒绝授权：

• 不循环弹窗；
• 展示“去设置”引导；
• 保留手动浏览和点播；
• C 档允许用户重新发起授权；
• 页面明确提示“未授权时无法自动判断附近点位”。

2.6 自动触发交互

状态机

未开启
  ↓
等待授权
  ↓
等待定位
  ↓
导览运行中
  ├── 命中候选点位 → 连续确认
  ├── 进入围栏 → 检查冷却 → 播放
  ├── 音频播放中 → 不触发其他点位
  ├── 定位异常 → 展示异常状态
  ├── 页面切后台 → 暂停自动定位并提示
  └── 用户手动关闭 → 结束导览

播放前提示

不建议无提示突然播放。可以采用：

1. 轻提示音；
2. 页面顶部显示“即将讲解：××”；
3. 0.5—1 秒后开始播放；
4. 用户可以点击“跳过”。

如果手机正在播放其他音频，应明确处理：

• 默认不强行打断其他媒体；
• 若音频播放失败，展示手动播放按钮；
• 不承诺兼容所有第三方音频场景。

防重复规则

建议默认配置：

• 同一点位自动播放冷却：6 小时；
• 同一点位手动点播不影响自动播放冷却，或由后台配置；
• 用户主动点击“重新播放”时允许立即播放；
• 同一导览会话内同一点位只自动播放一次；
• 播放未开始、音频加载失败，不计为成功播放；
• 播放超过设定时长比例，例如 30%，才计为“有效开始”。

具体时长和阈值必须由 A 端配置，不写死。

2.7 省电模式

提供三档：

这里的“降低频率”只能作为业务侧处理策略，不能声称可以控制微信底层 GPS 回调频率。实现上可以：

• 收到回调后不每次都执行完整查询；
• 对位置做最小移动距离判断；
• 对围栏计算做节流；
• 暂停图片预加载；
• 仅下载当前线路音频；
• 低端机关闭复杂动效。

3. 技术方案

3.1 总体架构

A端内容管理
  ├── POI管理
  ├── 线路管理
  ├── 讲解稿管理
  ├── 音频生成与审核
  └── 发布管理
          ↓
服务端 API / CDN
  ├── POI与线路接口
  ├── 内容版本接口
  ├── 音频清单接口
  ├── 埋点接口
  └── 商户承接接口
          ↓
微信小程序
  ├── C档 getLocation
  ├── A档 startLocationUpdate + onLocationChange
  ├── 本地围栏计算
  ├── 本地播放与缓存
  └── analytics_events 埋点

定位判断应尽量在小程序本地完成：

• 减少弱网依赖；
• 降低服务端请求量；
• 避免频繁上传位置；
• 不保存用户完整轨迹；
• 不把每次位置变化作为服务端查询请求。

3.2 数据模型

现有 pois 表无独立经纬度列，应优先补充结构化字段，不建议长期把坐标放在 meta JSON 中。

POI 表

pois
----
id
name
aliases
poi_type
industry
latitude
longitude
coordinate_system       -- gcj02 / 其他，必须统一
anchor_distance_km
trigger_profile_id
content_status
is_test
is_active
meta
created_at
updated_at

线路表

guide_routes
------------
id
name
route_type              -- kora / self_drive / scenic_area 等
description
cover_image
status
version
is_test
created_at
updated_at

线路点位关系表

guide_route_pois
---------------
id
route_id
poi_id
sequence_no
distance_from_start_km
trigger_enabled
auto_play_enabled
priority
is_test

讲解稿版本表

guide_scripts
-------------
id
poi_id
route_id                -- 可为空，支持同一 POI 在不同线路采用不同讲解
language
script_type             -- standard / short / long / religious_note
title
body
duration_target_sec
source_note
brand_creation_flag
review_status           -- draft / pending_review / approved / rejected / archived
version
effective_from
effective_to
is_test
created_by
reviewed_by
created_at
updated_at

音频版本表

guide_audios
------------
id
script_id
language
voice_type              -- tts / human
voice_name
audio_url
cdn_key
duration_sec
file_size
sha256
audio_format
generation_status
review_status
version
created_at
updated_at

离线包表

guide_packages
--------------
id
route_id
package_version
manifest_url
total_size
poi_count
status
min_app_version
created_at

离线包清单

guide_package_items
-------------------
id
package_id
poi_id
audio_id
audio_url
file_size
sha256
required

播放记录表

guide_play_records
------------------
id
anonymous_user_id
device_id_hash
route_id
poi_id
trigger_type            -- auto / manual / nearby
session_id
audio_version
started_at
completed_at
listen_duration_sec
play_status
is_offline
is_test

不建议保存用户的完整实时轨迹。若需要分析路线，只保留匿名化、聚合化后的事件数据。

3.3 坐标与距离计算

坐标要求

• 统一使用微信地图相关场景适用的坐标体系；
• wx.getLocation 建议明确请求 type: 'gcj02'；
• POI 坐标必须和用户坐标使用同一坐标系；
• 不允许把百度坐标、WGS84、GCJ-02 混用；
• 生产数据和测试数据分开，测试数据使用 is_test=true。

球面距离计算

采用 Haversine 公式：

a = sin²((lat2-lat1)/2)
  + cos(lat1) × cos(lat2) × sin²((lon2-lon1)/2)

c = 2 × atan2(√a, √(1-a))

distance = R × c

其中：

• 纬度、经度先转换为弧度；
• 地球半径 R 可取约 6,371,000 米；
• 前端只计算已下载线路或附近候选 POI；
• 不要每次位置回调都请求服务端全量 POI。

围栏配置

不建议所有点位都固定 300 米。建议后台配置：

上述数值是初始测试建议，不是固定产品规则。真实值应通过测试和埋点调整。

3.4 围栏触发算法

基础状态

每个 POI 保存：

outside
candidate
inside
played
cooldown

推荐逻辑

1. 收到位置回调；
2. 计算当前位置与候选 POI 距离；
3. 对距离进行漂移处理；
4. 若连续多次位于进入半径内，标记为候选；
5. 若达到连续确认条件，进入围栏；
6. 检查：
7. 是否已播放；
8. 是否处于冷却期；
9. 是否有可用音频；
10. 是否有其他点位正在播放；
11. 是否满足线路顺序和优先级；
12. 满足条件后播放；
13. 只有音频真正开始播放，才记录触发成功；
14. 距离超过离开半径后重置状态。

进入和离开阈值

设置滞回区，避免边界抖动：

进入半径：300 米
离开半径：400 米

只有距离大于离开半径，才认为离开围栏。

连续确认

建议默认：

• 连续 2 次或 3 次位置判断命中；
• 或在连续一段时间内保持命中；
• 具体采用“次数”还是“时间”由测试决定。

不能只依赖一次 GPS 定位结果。

漂移处理

可采用以下策略：

• 忽略明显异常的瞬时大位移；
• 比较相邻位置时间和距离，识别不合理跳跃；
• 记录 accuracy，当定位精度明显较差时延迟自动播报；
• 对高不确定性位置只展示“附近点位”，不自动播放；
• 采用最近若干次位置的简单平滑，而不是盲目使用单点坐标。

微信位置回调是否始终提供可用的精度字段、不同设备表现如何，需要真机验证，不能只依赖开发者工具。

多点位同时命中

优先级建议：

1. 当前线路中顺序更靠前且未播放的点位；
2. 距离更近的点位；
3. priority 更高的点位；
4. 音频更短、适合当前场景的点位；
5. 其他点位保留在“附近有什么”列表。

播放中不自动打断。用户可手动切换。

3.5 音频管线

内容到音频的流程

A端编辑讲解稿
→ 保存草稿
→ 人工审核
→ 审核通过
→ TTS生成
→ 质检音频
→ 生成音频版本与校验值
→ 上传对象存储/CDN
→ 形成线路离线包manifest
→ 发布

版本规则

文案变更时必须生成新版本：

POI：冈仁波齐某点位
文稿版本：script_v3
音频版本：audio_v3
线路包版本：route_package_v5

客户端不要只按照 POI ID 缓存音频，而要按照：

route_id + poi_id + audio_version + language

进行缓存，否则内容更新后可能继续播放旧音频。

音频格式

一期建议：

• MP3 或平台兼容的压缩音频；
• 单条音频控制在 30—120 秒；
• 语音前后留适当静音；
• 音量统一；
• CDN 使用 HTTPS；
• 文件名不包含未经处理的用户输入；
• 通过 wx.downloadFile 下载；
• 下载完成后保存到小程序本地文件系统；
• 播放前检查文件存在性和版本。

小程序本地文件容量及不同系统行为应通过真机验证，不能把“10 个点位约 20MB”作为所有设备都可靠支持的硬承诺。

离线包策略

建议采用“清单 + 按需下载 + 手动完整下载”两种方式：

完整下载

• 用户主动点击“下载整条线路”；
• 展示大小和预计耗时；
• 建议在 Wi-Fi 或充电时下载；
• 支持暂停、失败重试、删除。

按需下载

• 用户开始线路时只下载前几个点位；
• 在有网时继续后台式地分段下载；
• 但不承诺小程序退出后仍会持续完成；
• 如果用户未下载，进入无网环境后只能播放已缓存内容。

音频不可用时

按以下降级：

1. 播放本地已缓存音频；
2. 尝试 CDN 在线播放；
3. 展示文字稿；
4. 展示“重新下载”；
5. 记录音频失败原因。

3.6 弱网与无网设计

埋点缓存应设置上限和过期策略，避免占用过多本地空间。

3.7 前台定位实现边界

A 档流程

用户点击开启
→ wx.startLocationUpdate
→ wx.onLocationChange 注册回调
→ 本地距离计算
→ 本地围栏状态机
→ 命中后播放音频
→ 记录埋点

需要处理：

• wx.startLocationUpdate 调用失败；
• 用户未授权；
• 页面隐藏；
• 页面销毁；
• 用户从系统设置中撤回权限；
• 回调长时间未到达；
• 位置精度不满足要求；
• 音频正在播放；
• 重复启动监听。

页面退出时应主动停止本次监听，避免形成逻辑泄漏。具体是否调用 wx.stopLocationUpdate，应结合同一小程序其他页面的定位使用方式统一管理。

3.8 埋点设计和指标体系

现有 analytics_events 可以扩展事件，不必新建一套完全独立的埋点系统。

核心事件

位置事件不应逐条上传。建议只上报脱敏后的触发结果和聚合数据。

指标分层

1. 功能使用指标

2. 体验质量指标

3. 业务价值指标

如何证明功能有效

建议分为三种比较：

比较一：自动触发和手动点播

比较两者的：

• 有效开始率；
• 25% 收听率；
• 完播率；
• 用户主动关闭率；
• 商户点击率。

如果自动触发的误播率明显高于手动点播，应优先优化围栏，而不是继续扩大点位数量。

比较二：导览用户与非导览用户

在同一线路或同一时间段内，比较：

• 线路页停留；
• 点位详情浏览；
• 商户进入；
• 咨询；
• 留资；
• 复访。

需要控制用户来源和线路差异，避免把高意向用户天然更愿意使用导览误判为功能效果。

比较三：功能版本前后

一期上线前建立基线，上线后观察：

• 内容页有效阅读；
• 商户导流；
• 线路页留存；
• 线索有效对话建立率。

如果样本量不足，不应直接得出强因果结论，应明确标记为相关性观察。

一期继续投入门槛

建议设置为“由样本验证后确定”的门槛，不凭空承诺绝对数值。可以采用以下判定框架：

4. 内容方案

4.1 讲解稿总体原则

每个点位建议至少维护三种内容：

1. 标准版：60—90 秒，适合自动触发；
2. 短版：20—40 秒，适合路过、低电量和高频点位；
3. 详情版：120—180 秒，适合用户主动点播。

一期不建议每点位都做 300—600 字的长稿。300—600 字普通中文播报可能需要约 1—3 分钟，车辆经过一个点位时可能听不完，自动触发更适合短讲解。

4.2 可直接套用的讲解稿模板

标准版模板

【开场定位】
你现在经过的是【点位名称】。它位于【地理位置/线路位置】，
从这里可以看到【可验证的景观或环境特征】。

【核心记忆点】
这里最值得留意的是【一个事实/一个现象/一个故事】。
根据【资料来源/当地说法/公开记录】，人们常常这样理解它：
【口语化表达】。

【文化说明】
关于这个地方，当地流传着【传说或民间说法】。
这属于【传说/民间叙事/平台整理】，不代表宗教权威解释。
如果你正在徒步或转山，可以留意【可观察的自然或人文细节】。

【旅行提示】
接下来前往【下一点位/服务点】大约需要【后台确认后的距离或时间】。
高原环境下请注意【饮水、保暖、节奏、安全】。

【结束】
如果想再听一遍，可以在当前点位页面手动播放。

短版模板

你现在经过的是【点位名称】。
这里最值得注意的是【一个可验证事实或景观特征】。
当地也流传着【简短传说】，这是民间说法，不代表宗教权威解释。
请注意【一句安全提示】。

商业承接版模板

讲解到这里。如果你接下来需要【住宿/餐饮/补给/交通】，
可以查看附近的【商户类型】。平台展示的是已配置的服务信息，
建议提前确认营业时间、价格和实际接待情况。

商业承接不宜插入每条宗教文化讲解中，建议在音频结束后的卡片区域呈现，避免破坏内容氛围。

4.3 口语化标准

应该使用

• 短句；
• 一句话一个信息点；
• “你现在看到的是……”；
• “当地常有人这样说……”；
• “资料中记载……”；
• “如果你抬头看，可以留意……”；
• 适合听觉理解的重复和转折。

不建议使用

• 过长的书面句；
• 连续堆砌年代、人物和地名；
• 未核实的“最早、唯一、正宗、起点”；
• “这里一定会”“所有人都认为”；
• 过度神秘化、夸大灵验；
• 将创作内容伪装成历史资料。

审核标签

每条内容建议添加：

4.4 首批点位清单建议

材料只明确：

• 塔尔钦周边首批考虑 10 个 POI；
• 已有冈仁波齐转山 21 个点位体系雏形；
• 具体 10 个 POI 名称和准确坐标，材料未涉及。

因此，首批不应擅自编造点位名称。建议按照以下结构选择：

首批上线前应完成：

• 坐标实地或可信来源核验；
• 点位是否可到达；
• 是否存在多个同名地点；
• 是否适合车辆或徒步触发；
• 是否有足够可信的讲解资料；
• 是否存在宗教文化敏感性。

4.5 讲解稿示例

以下示例仅用于展示写法，不代表对具体点位事实的确认。

示例一：自然地标类

你现在经过的是一处可以远眺高山和开阔谷地的路段。这里最值得留意的，不只是眼前的山形，也包括高原光线带来的层次变化：天气晴朗时，远处山体的颜色会随着云影不断变化。当地人常用自己的方式理解这片山地，这些说法属于地方叙事和民间记忆，不代表宗教权威解释。经过这里时，请注意风力和路面情况，不要为了拍照走到道路边缘。

示例二：宗教文化相关点位

你现在接近的是【点位名称】。关于这里，当地流传着一些与神山、行走和祈愿有关的故事。今天的讲解只是对公开资料和地方说法的整理，不代表宗教权威解释，也不替代任何宗教仪轨。无论你是徒步、朝圣还是旅行经过，都可以保持安静、尊重当地习惯，并根据自己的身体状态调整速度。高原环境变化较快，请提前准备饮水和保暖衣物。

4.6 内容生产流程

资料收集
→ 事实与传说分层
→ 口语化改写
→ 本地顾问/实地人员校核
→ 敏感内容人工审核
→ TTS生成
→ 音频试听
→ 小范围试播
→ 发布
→ 用户反馈与版本迭代

内容后台必须支持：

• 草稿、审核、发布、撤回；
• 文案版本对比；
• 音频重新生成；
• 变更记录；
• 审核人和审核时间；
• 敏感词或敏感点位标识；
• 内容来源说明。

5. 分期计划与阶段性触发条件

5.1 一期：MVP 验证

目标

验证：

1. 用户是否理解并愿意开启导览；
2. A 档前台定位是否在真实环境下可用；
3. 预生成音频和离线播放是否可靠；
4. 自动播放是否比单纯图文更有效；
5. 是否能产生商户导流。

范围

• 塔尔钦周边约 10 个 POI；
• 具体点位由实地核验后确定；
• 讲解稿短版和标准版；
• TTS 预生成；
• C 档附近导览；
• A 档前台伴随导览；
• 离线音频包；
• 本地围栏计算；
• 基础埋点；
• 低端机降级；
• 现有转山页面资产复用。

一周原型要求修正

“一周内出原型”可以，但原型应分为：

• 第 1—2 天：页面流程和授权流程；
• 第 3—4 天：静态点位、距离计算、播放；
• 第 5 天：轨迹模拟和异常状态；
• 第 6 天：真机弱网、切后台、锁屏测试；
• 第 7 天：问题修复和演示。

开发者工具模拟位置只能验证基本逻辑，不能证明真实 GPS、耗电、弱网、后台和音频兼容性。

一期验收

5.2 二期：扩大线路和内容质量

进入条件

满足以下大部分条件后进入：

• 自动触发能够稳定发生；
• 误播和重复播放可控；
• 用户有实际收听行为；
• 离线包下载和播放失败率可接受；
• 有明确商户承接点击；
• 内容审核流程可以持续运转。

二期内容

• 扩大到完整转山线路；
• 增加更多自驾线路；
• 引入短版、标准版、详情版；
• 增加语言版本，但具体语言和语音供应能力需先验证；
• 对重点点位进行真人录音试点；
• 加入音频评分和问题反馈；
• 结合 kora-checkin、kora-track 做点位完成展示；
• 对商户点位加入服务提示；
• 优化线路顺序和点位推荐。

5.3 三期：后台能力与精品内容

进入条件

只有在以下条件成立时才考虑：

• 前台 A 档已证明用户确实需要自动触发；
• 用户对持续定位有明确需求；
• 平台有足够的合规与审核资源；
• 商业价值足以覆盖后台定位的开发和维护成本；
• 经过微信平台类目、权限和审核可行性评估；
• 真机验证 iOS、安卓和低端机表现。

三期方向

• 评估 wx.startLocationUpdateBackground 的申请和审核可行性；
• 评估后台播放能力及系统兼容性；
• 真人录音和多语言版本；
• 精品线路内容；
• 线路专题和会员内容；
• 旅行安全提示；
• 基于用户主动选择的个性化导览。

三期仍不能向用户承诺“任何时候、所有设备、锁屏后必然自动播报”。

6. 风险清单与应对方案

6.1 技术风险

6.2 内容风险

6.3 体验风险

6.4 合规风险

7. 商业价值与北极星指标

7.1 对平台的商业价值

价值一：形成差异化内容入口

一般旅游小程序主要提供：

• 景点介绍；
• 酒店和餐饮；
• 交通服务；
• 路线信息。

位置语音导览把这些内容和“人在路上”的真实场景连接起来，尤其适合阿里地区长距离、自驾和徒步环境。

价值二：提升用户驻留和复访

语音内容不要求用户持续看屏幕，适合车上和徒步过程中使用。若内容质量稳定，可以提高：

• 单次使用时长；
• 线路页面停留；
• 点位详情浏览；
• 再次进入小程序的概率。

价值三：承接商户业务

点位讲解结束后可以承接：

• 温泉酒店；
• 牦牛运输；
• 藏餐；
• 景区服务；
• 补给和交通；
• 客服咨询。

但商业承接要以“场景相关、用户需要”为前提，不能把每条讲解都强行变成广告。

价值四：沉淀可复用内容资产

一份经过审核的讲解稿，可以复用于：

• 小程序音频；
• 图文详情；
• 线路卡片；
• 视频旁白；
• 商户或景区宣传；
• 真人录音版本；
• 多语言版本。

价值五：服务北极星指标

现有 CRM 的北极星指标是“有效对话建立率”。导览功能可以作为上游入口，验证：

位置触发
→ 有效收听
→ 相关服务展示
→ 商户详情
→ 咨询/留资
→ 有效对话建立

7.2 建议的北极星指标

不建议把“自动播放次数”作为北极星指标。建议定义：

有效导览用户产生的有效收听点位数，并进一步观察其带来的有效对话建立率。

可以拆成两个层级：

产品北极星指标

有效导览用户
= 开启导览
+ 至少一次音频成功开始
+ 收听达到设定有效比例
+ 非测试用户

核心指标：

人均有效收听点位数
= 有效收听点位总数 / 有效导览用户数

商业北极星指标

导览来源有效对话建立率
= 导览来源有效对话数 / 有效导览用户数

其中“有效对话”应沿用 CRM 既有定义，不重新发明一套口径。

7.3 指标看板建议

产品漏斗

进入导览页
→ 选择线路
→ 授权成功
→ 开启导览
→ 下载离线包
→ 触发点位
→ 音频开始
→ 有效收听
→ 完播
→ 查看相关服务
→ 商户进入
→ 建立有效对话

看板维度

• 线路；
• 点位；
• 自动 / 手动；
• 在线 / 离线；
• 安卓 / iOS；
• 设备性能档位；
• 自驾 / 徒步 / 朝圣用户选择；
• 内容版本；
• 音频版本；
• 是否使用离线包。

重点诊断组合

7.4 最终投资判断

建议采用以下决策原则：

1. 先证明“有效收听”成立，再扩大点位数量。
2. 先证明“自动触发准确”成立，再考虑后台定位。
3. 先证明“导览能带来相关业务行为”，再投入真人录音和大规模多语言。
4. 如果用户喜欢内容但不产生商业转化，也不应立即判定功能失败，应区分内容价值和商业承接问题。
5. 如果技术稳定性、内容质量和商业转化均不成立，应停止扩大范围，回到“手动附近导览+高质量内容”这一更简单的产品形态。

最终建议的落地顺序是：

真实点位核验
→ C档附近导览
→ A档前台伴随导览
→ 离线音频
→ 围栏与播放质量优化
→ 商户承接
→ 真人录音和扩大线路
→ 评估B档后台能力

这条路径能在微信小程序真实边界内快速验证产品价值，同时避免把项目过早押注在后台定位、复杂语音能力或未经核实的宗教文化内容上。