forked from zhouruizhe/gmTouringMiniApp
181 lines
11 KiB
Markdown
181 lines
11 KiB
Markdown
# 附件总结与需求差异分析 V1.0
|
||
|
||
| 文档版本 | 创建日期 | 版本简述 |
|
||
|---|---|---|
|
||
| V1.0 | 2026-07-29 | 汇总三份附件，识别重叠、差异、冲突与当前 POC 范围 |
|
||
|
||
## 目录
|
||
|
||
- [分析口径](#分析口径)
|
||
- [三份附件摘要](#三份附件摘要)
|
||
- [共同需求主线](#共同需求主线)
|
||
- [附件差异](#附件差异)
|
||
- [主要冲突与处理建议](#主要冲突与处理建议)
|
||
- [需求缺口](#需求缺口)
|
||
- [当前范围建议](#当前范围建议)
|
||
|
||
## 分析口径
|
||
|
||
### 信息标记
|
||
|
||
| 标记 | 含义 |
|
||
|---|---|
|
||
| 已确认 | 用户在对话中明确指定，或附件中存在一致、明确的约束 |
|
||
| 资料事实 | 附件原文表达，不代表已完成业务或技术验证 |
|
||
| 产品细化 | 为使需求可开发、可测试而补充的建议规则，需评审确认 |
|
||
| 🔶 **假设** | 资料未提供，但为了形成初稿而采用的临时判断 |
|
||
| 🔵 **待确认** | 会影响范围、方案、排期或验收，不能由产品文档代替决策的问题 |
|
||
|
||
### 来源优先级
|
||
|
||
1. `S1`：POC 建设方案，最后修改时间最晚，直接定义 7 天 POC。
|
||
2. `S2`：16 页功能版 PPT，补充具体功能形态。
|
||
3. `S3`：46 页总规划 PPT，描述完整三期和运营方向。
|
||
|
||
## 三份附件摘要
|
||
|
||
### S1：POC 建设方案
|
||
|
||
S1 将当前项目定位为用于快速验证、效果展示和能力证明的智慧文旅全域导览 Demo，而非正式生产系统。建设主线为“地图 + 点位 + 线路 + 互动”，验证全域地图、POI 数字化展示、AI 问答与路线规划、互动打卡四类能力。
|
||
|
||
资料定义的核心演示过程为：打开地图 → 查看资源 → 查看 POI → 输入游玩需求 → AI 生成路线 → 地图展示路线 → 模拟打卡获得徽章。明确列出首页地图、POI 详情、AI 助手、路线结果、打卡徽章、个人中心六类页面，同时称“约 10 个页面”，但未说明其余页面或计数方式。
|
||
|
||
工期为 7 天，资源为前端 1 人、后端/AI 1 人、UI 设计支持。技术候选为小程序 + 地图 API、Node.js/Python、JSON/SQLite、大模型 API + 文旅知识库。S1 没有量化验收指标、数据样本规模、AI 合同、异常策略或正式交付清单。
|
||
|
||
### S2：16 页功能版规划
|
||
|
||
S2 聚焦功能演示，覆盖全域地图、分类、筛选、POI 详情、榜单、路线、AI 问答路线规划、打卡分享、游记、积分兑换、徽章、榜单挑战和优惠券。
|
||
|
||
它对地图交互的描述最具体：地图多级缩放和拖拽，核心地标默认高亮，POI 随缩放渐进展示；支持“吃、住、行、游、购、娱”分类以及景点、美食、住宿、活动、无障碍等组合筛选；POI 详情含图集、开放时间、简介、电话、票价、评分、标签及收藏、打卡、预约、导航等动作。
|
||
|
||
S2 还将 AI 路线输入细化为主题、时长、节奏、特色等偏好，将路线结果定义为一日/多日路线、途经 POI、服务点和地图动线。相较 S1，它明显扩展了正式运营能力，尤其是游记审核与积分、积分商城和二维码核销、优惠券状态及到店核销、榜单挑战和用户画像；这些能力不应默认进入 7 天 POC。
|
||
|
||
### S3：46 页三期总规划
|
||
|
||
S3 说明了产品问题：文旅信息分散导致信息过载，缺乏本地化个性化规划工具，导航、预订、攻略等体验割裂。产品希望服务游客、商家和运营监管方，并形成探索发现、规划决策、导航体验、分享沉淀的游客旅程。
|
||
|
||
总规划采用三期递进表达：一期 L2 建设全域地图、POI、主题路线、打卡积分和基础 CMS；二期 L3 建设营销、订单、支付、分账、商户和数据看板；三期 L4 建设 AI 路线、AI 客服/助手、多语种导游及其他智能能力。规划周期和预算分别为一期 2 个月、29 万至 45 万元，二期 4.5 个月、50 万至 65 万元，三期 2 个月、19 万至 25 万元，总预算称不低于 98 万元，并建议总预算 20% 至 30% 的弹性备用金。
|
||
|
||
S3 还提出后续运营方向：基础运营、活动策划、惠民补贴、港澳及入境游客推广；相关能力包括 320+ 点位内容中台、预约、会员、消费券、多语言和跨境支付等。这些是长期产品及运营路线，不是 S1 的 POC 交付承诺。
|
||
|
||
## 共同需求主线
|
||
|
||
三份资料可以归纳为同一条产品主线：以光明区全域 POI 数据为基础，以地图作为用户发现入口，通过筛选、详情和 AI 路线降低决策成本，再用导航、打卡、徽章和分享完成行中互动及用户沉淀。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[文旅资源数据] --> B[全域地图与POI]
|
||
B --> C[搜索/分类/筛选]
|
||
C --> D[POI详情与决策]
|
||
D --> E[预设或AI路线]
|
||
E --> F[地图路线展示/导航]
|
||
F --> G[打卡/徽章/积分]
|
||
G --> H[分享与行为沉淀]
|
||
H --> I[内容和运营优化]
|
||
```
|
||
|
||
共同出现且可确认为产品核心的能力包括：
|
||
|
||
- 全域地图、POI 定位与详情。
|
||
- 分类浏览、筛选和地图点位联动。
|
||
- 用户偏好输入、AI 理解、个性化路线生成和地图结果展示。
|
||
- 路线关联景点、餐饮、住宿等 POI。
|
||
- 打卡、徽章或积分反馈以及分享表达。
|
||
- 行为数据记录，为后续运营和正式用户体系提供基础。
|
||
|
||
## 附件差异
|
||
|
||
| 维度 | S1：POC 方案 | S2：功能版 PPT | S3：总规划 PPT |
|
||
|---|---|---|---|
|
||
| 文档目的 | 7 天 Demo 验证 | 功能展示与细化 | 三期建设和运营提案 |
|
||
| 当前交付范围 | 约 10 页，六类页面 | 13 个业务功能主题 | 一期至三期、三端及运营服务 |
|
||
| 地图 | 全域地图验证 | 缩放、渐进 POI、分类、筛选、榜单 | 地图数据底座和商业字段预留 |
|
||
| AI | 问答及个性化路线 | 偏好理解、路线生成、实时数据描述 | 三期 AI 路线、客服、助手、多语种导游 |
|
||
| 互动 | 模拟打卡、积分、徽章 | 真实定位表述、游记、分享、商城核销、挑战 | 账户、流水、规则、风控与会员成长 |
|
||
| 交易 | POC 后扩展 | 优惠券、积分商品核销 | 订单、支付、退款、分账、商户和对账 |
|
||
| 后台 | POC 未纳入 | 功能隐含运营配置 | CMS、商户后台、数据看板和监管 |
|
||
| 工期 | 7 天 | 未单列当前功能工期 | 一期 2 个月，二期 4.5 个月，三期 2 个月 |
|
||
| 指标 | 无量化阈值 | 定性描述增长价值 | 有运营方向，无可信产品基线和目标值 |
|
||
|
||
## 主要冲突与处理建议
|
||
|
||
| 冲突 | 影响 | 处理建议 |
|
||
|---|---|---|
|
||
| S1 为 7 天 POC，S2/S3 包含生产级运营和交易 | 若不切范围，工期与功能严重失配 | 当前 PRD 建议只承诺可演示主流程；交易和正式运营进入后续需求池 |
|
||
| S1 列出六类页面，却称约 10 页 | 设计、研发和验收计数不一致 | 以六类业务页面为基线，浮层和子流程是否拆页由评审决定；最终页数作为 P0 待确认项 |
|
||
| “AI 问答”“AI 导览”“AI 路线规划”混用 | AI 交互、接口、知识和验收不同 | POC 必做路线需求理解与生成；开放问答、语音讲解分别列为条件范围或后续范围 |
|
||
| “模拟打卡”与“到点自动定位校验”并存 | 决定是否申请位置权限、登录和远端存储 | 7 天版默认演示模拟打卡；真实 LBS 打卡仅在账号、隐私和真机条件就绪时替换 |
|
||
| 路线既称实时导航又称地图展示 | 直线、道路级路径和外部导航的成本差异大 | POC 必做 POI 顺序与地图连线；道路级路线及导航跳转需地图能力确认 |
|
||
| AI 生成依赖实时路况/客流 | 当前未给出实时数据源 | POC 不承诺实时客流；路线仅使用已审核 POI 和已提供的静态营业信息 |
|
||
| POC 已有积分徽章，S3 又将完整积分体系放后续 | 容易将本地演示状态误认为正式资产 | POC 仅展示可重置的模拟积分/徽章；正式账户、流水、规则和风控后置 |
|
||
| “全域”没有样本规模和准确率 | 无法判断内容是否完成 | 开工前锁定 POI 数量、分类、坐标系、必填字段和抽检规则 |
|
||
|
||
## 需求缺口
|
||
|
||
### 产品和用户
|
||
|
||
- 未定义当前演示的决策者、验收人和目标体验设备。
|
||
- 未定义本地游客、港澳游客、亲子、研学等人群中谁是 POC 首要对象。
|
||
- 未定义用户是否匿名、是否微信登录、个人中心保存哪些数据。
|
||
- 未定义底部导航、页面拆分和首页信息架构。
|
||
|
||
### 数据和内容
|
||
|
||
- 未提供 POC POI 样本数、来源、坐标系、图片版权和内容审核责任。
|
||
- POI 字段在附件间不一致，缺少必填性、枚举和缺失值规则。
|
||
- 榜单热度、评分、推荐指数、特色标签没有计算或运营规则。
|
||
- 知识库资料、版本、更新和引用方式未定义。
|
||
|
||
### AI 和路线
|
||
|
||
- 未定义一次性路线生成还是多轮问答，是否需要流式输出。
|
||
- 未定义路线输入的必填项、输出 JSON 结构、POI 映射和失败降级。
|
||
- 未定义不存在点位、闭馆、重复点位、距离不可行等约束。
|
||
- 未定义模型供应商、内容安全、数据出境、费用和时延限制。
|
||
|
||
### 技术和合规
|
||
|
||
- 地图供应商、Key、调用配额、微信域名白名单和坐标口径未定。
|
||
- 正式微信 AppID、主体权限、位置隐私声明、网络环境未定。
|
||
- 后端语言、数据存储、部署环境和正式接口协议仍是候选。
|
||
- 没有性能、错误恢复、日志、监控、隐私、内容安全和无障碍要求。
|
||
|
||
### 项目和验收
|
||
|
||
- 7 天内的数据、设计、地图/AI 账号等前置材料未明确由谁、何时提供。
|
||
- 没有源码、设计稿、数据包、接口文档、测试报告、部署说明等交付清单。
|
||
- 没有可量化成功指标，也没有演示失败时的预置路线和静态数据兜底。
|
||
|
||
## 当前范围建议
|
||
|
||
🔶 **假设**：以下范围以 S1 为当前交付基线，并用 S2、S3 细化体验；需由项目决策人在范围评审中确认。
|
||
|
||
### POC 必做
|
||
|
||
- 微信小程序方向的全域地图首页、样本 POI 点位和分类筛选。
|
||
- POI 摘要卡与详情展示。
|
||
- AI 偏好输入、基于审核 POI 的路线生成。
|
||
- 路线结果列表、地图 marker 和 polyline 展示。
|
||
- 模拟打卡、模拟积分和徽章反馈。
|
||
- 个人中心汇总演示记录。
|
||
- 全主流程的加载、空、失败和重试状态。
|
||
|
||
### 条件范围
|
||
|
||
- 关键词搜索和榜单：数据量与演示需要明确时纳入。
|
||
- 真实定位打卡：仅在隐私配置、权限和真机验证就绪时纳入。
|
||
- 开放式景点问答：仅在知识库、内容安全和 API 稳定时纳入。
|
||
- 微信分享卡片或海报：需锁定素材和分享形态。
|
||
- 道路级路线、外部地图导航：依赖地图服务商能力及 Key。
|
||
|
||
### 后续阶段
|
||
|
||
- 游记发布、内容审核和 UGC 运营。
|
||
- 正式积分账户、流水、规则、风控、商城和二维码核销。
|
||
- 优惠券、活动预约、商户、商品、订单、支付、退款、分账和对账。
|
||
- CMS、商户后台、数据看板和监管端。
|
||
- 实时客流/路况、多轮 AI、语音讲解、AI 客服、多语种和 AR。
|
||
- 正式会员、用户画像、分层运营、港澳推广及跨境支付。
|
||
|
||
当前 PRD 已按上述范围形成 V1.0 评审稿。所有“产品细化”与“假设”必须在范围评审中确认后，才能转为正式基线。
|