一、核心判断 DECISION
冈仁波齐不是最终商品，而是用户进入阿里地区的认知入口、行程决策入口和商业分发入口。
产品定位从“转山平台”升级为“阿里目的地服务平台”
转山业务竞争激烈，不应成为神山秘境的唯一核心。平台应利用冈仁波齐的搜索和目的地流量，承接住宿、餐饮、交通、文化体验、摄影、文创、特产和公司自营项目。
冈仁波齐认知入口→看懂阿里→周边路线→公司+商户供给→咨询/预约/履约
游客价值来之前降低陌生感，来之后快速找到真实可用的服务。
公司价值展示品牌、自营项目和目的地资源组织能力。
商户价值低门槛获得展示、客源、订单和结算工具。
平台价值沉淀目的地偏好、路线、消费、评价和复游意向。
二、先解决游客的陌生感 USER NEEDS
第一次来阿里的人通常不是只想问“怎么转山”，而是想确认：这里是否能生活、怎么到达、住在哪里、周边还有什么、哪些服务可信。
认识阿里阿里在哪里、如何进入、海拔和气候是什么样。
建立安全感高原适应、天气、道路、住宿、餐饮、补给和应急信息。
发现周边以冈仁波齐为中心，理解圣湖、普兰、古格、扎达等目的地关系。
做出计划根据时间、兴趣、体力和预算选择路线与服务组合。
完成消费咨询、预约、凭证、核销、评价和后续纪念服务形成闭环。
三、产品结构 PRODUCT
首页：我来阿里之前，先看懂阿里
首页不是商品堆砌，而是目的地决策入口。
- 今日天气、温度、能见度、道路和开放状态
- “第一次来阿里”专题
- 冈仁波齐与周边目的地入口
- 住在哪里、吃什么、怎么到达
- 公司自营项目和合作商户精选
探索阿里：从认知到路线
按用户决策顺序组织“认知层、区域层、玩法层、服务层”，每个目的地内容都必须关联真实路线、服务或咨询入口。
服务：到达之后的可用服务
将酒店、餐饮、交通、门票、向导、摄影、文化体验、文创、特产、补给和安全服务组织为目的地服务目录。商城不必作为孤立一级入口，应嵌入相关场景。
重要边界：游客端只展示与决策有关的信息，不展示内部渠道、分销、结算、岗位权限等运营字段。
四、以冈仁波齐为中心做路线套餐 ROUTES
路线不按“转山几天”单一分类，而按停留时间、旅行目的和可履约的服务组合组织。
| 路线层级 | 适合人群 | 产品方向 | 必须解决 |
|---|---|---|---|
| 1日体验 | 时间有限、初次到访 | 神山观景、塔钦生活、餐饮、文化、星空 | 当天交通、开放状态、低强度安排 |
| 2-3日周边 | 神山之外短途延展 | 冈仁波齐+玛旁雍错、普兰、圣湖 | 住宿、车辆、节点顺序 |
| 4-6日小环线 | 希望深入了解阿里 | 神山、圣湖、普兰、扎达或古格 | 跨地住宿和路线衔接 |
| 7日以上 | 自驾、摄影、深度旅行 | 阿里核心目的地组合 | 道路、补给、天气和异常预案 |
第一次来阿里重点是降低陌生感，提供少踩坑的入门路线。
摄影与星空重点是机位、天气、住宿和摄影服务。
自驾用户重点是路况、加油、维修、补给和住宿。
轻旅行用户重点是不转山也能体验阿里的低强度玩法。
路线套餐的四层结构
目的地：去哪里+路线：怎么走+服务：住/吃/行/玩+保障：天气/路况/补给
套餐支持有限选项组合：基础路线 + 住宿档位 + 交通方式 + 餐饮/文化体验 + 摄影/文创，不做无限制自定义。
五、公司与商户如何联动 NETWORK
| 参与方 | 主要责任 | 平台给什么 |
|---|---|---|
| 公司自营 | 目的地内容、代表性体验、品牌项目、组货和异常协调 | 品牌展示、统一入口、路线组合、履约中枢 |
| 住宿商户 | 房态、接待、住宿履约 | 商户主页、今日状态、房态、订单和核销 |
| 餐饮商户 | 营业状态、餐饮服务、接待容量 | 服务展示、预约、到店凭证 |
| 交通/摄影/文化商户 | 档期、服务范围、实际履约 | 路线参与、订单、异常反馈、结算查询 |
商户工具优先级
| 优先级 | 轻量工具 | 核心目的 |
|---|---|---|
| P0 | 商户主页、今日营业状态、可接待人数/可用服务 | 让游客看到真实且及时的供给 |
| P0 | 订单查看、咨询接收、路线服务环节报名 | 让商户真正接到平台需求 |
| P1 | 凭证核销、异常反馈、图片和服务维护 | 形成履约证据和服务质量记录 |
| P2 | 结算查询、评价反馈、历史经营数据 | 提高持续使用意愿 |
商户工具的目标不是做复杂 SaaS，而是让商户每天用几步维护状态、接单、核销和查看收益。
六、技术落点 ARCHITECTURE
保留神山秘境现有原生小程序、FastAPI 后端和业务适配器分层，在上层补充目的地和路线能力，不推倒重来。
建议新增业务域
Destination目的地、区域、内容、开放信息、更新时间和来源。
Route路线、节点、天数、交通、可选服务和行程组合。
Supply住宿、餐饮、交通、体验、文创等真实供给。
Fulfillment多商户履约项、核销、异常和责任方。
Destination→Route→Supply→Order/Voucher→Settlement
联合路线订单必须拆成履约项
一个路线订单可以包含住宿、交通、餐饮、体验和公司自营项目。每个履约项必须绑定责任方、状态、核销记录和结算依据，不能只保存一个笼统的“套餐已完成”。
技术决策：先保持后端模块化，不立即拆成微服务。只有在独立扩展、团队责任、数据隔离或发布节奏明确需要时，才考虑拆分。
七、四阶段落地计划 ROADMAP
M1 · 目的地认知入口
目标：验证游客来之前是否愿意通过神山秘境了解阿里并规划行程。
- 首页增加“第一次来阿里”与目的地入口
- 建设冈仁波齐中心页和周边目的地页
- 接入天气、道路、开放状态和真实服务目录
- 展示公司自营项目和合作商户
- 先做咨询/意向提交，不急于复杂交易
验收：冈仁波齐内容 → 周边目的地 → 路线查看 → 服务咨询链路可走通。
M2 · 周边路线商品化
目标：先上线 3 条真实可执行路线。
- 冈仁波齐周边短线
- 神山圣湖线
- 冈仁波齐与普兰、古格或扎达方向的可执行组合
每条路线必须有节点、天数、交通、住宿、可选服务、开放状态、更新时间和取消说明。
M3 · 商户轻工具
目标：让合作商户低门槛维护真实供给。
- 商户主页
- 今日营业和接待状态
- 可用房间或服务容量
- 路线套餐参与
- 订单查看和异常反馈
标准是：商户每天打开一次，几步完成主要工作。
M4 · 履约凭证与结算闭环
目标：跑通一条多商户联合路线。
选择路线→提交预约→生成订单→分履约项→核销/异常→评价/结算
支付、代收、线下支付和分账方式需要结合实际资质、合同关系和财税流程确认，不能仅靠产品设计规避合规问题。
八、关键风险与验收原则 GUARDRAILS
| 风险 | 后果 | 控制办法 |
|---|---|---|
| 内容无法转化 | 用户看完即走 | 每个目的地必须绑定真实路线、服务或咨询入口 |
| 商户状态过期 | 游客到店无法使用 | 记录更新时间，过期数据降低展示权重 |
| 联合路线环节失约 | 平台信任受损 | 每个履约项绑定责任商户和异常处理人 |
| 公司责任边界模糊 | 纠纷和合规风险 | 明确自营、合作、平台撮合三种关系 |
| 范围铺得过大 | 运营维护失控 | 先选一个真实可控区域和少量路线 |
| 工具过于复杂 | 商户不使用 | P0 只保留状态、订单、核销三个核心动作 |
每个公开目的地有更新时间、来源和真实服务入口。
未确认状态的商户不能展示为“今日可用”。
联合路线可以拆出多个履约项，每项有责任方。
核销、退款、异常和结算记录可以相互追溯。
测试账号、测试订单和生产数据完全隔离。
游客端不展示内部岗位、渠道、分销和结算字段。
九、现有云服务器环境 KNOWN ENVIRONMENT
结论：我知道项目总纲中记录的云服务器架构，但这些信息属于文档记录，不等于我已经实时登录服务器核验当前运行状态。
| 项目 | 已知记录 |
|---|---|
| 云厂商/规格 | 腾讯云轻量应用服务器，成都二区 |
| 系统 | Ubuntu 24.04 LTS |
| 部署方式 | Docker Compose |
| 公网入口 | 文档记录为 162.14.97.25；正式使用前应重新核验 |
| 内网通道 | Tailscale；文档记录服务器 100.64.1.230、本地开发机 100.64.1.89 |
| 反向代理 | Nginx，负责 80/443 反向代理与静态文件 |
| 后端 | FastAPI + Uvicorn，JWT 认证，asyncpg 连接池 |
| 数据库 | PostgreSQL 16，文档记录主数据库约 34 张表 |
| 服务器目录 | /srv/kailash/，包含 app、nginx、postgres、uploads、logs、backups |
| API 域名 | https://api.kailashi.cn/api/miniapp |
开始实施前必须核验的环境信息
- 当前服务器是否仍使用文档中的公网 IP 和 Tailscale 地址
- Docker Compose 当前运行的容器、镜像和环境变量
- 数据库当前实际表结构与最近迁移记录
- Nginx、API 域名证书和微信小程序合法域名配置
- 备份是否成功、恢复是否可执行
- 生产、测试账号和测试数据是否已经隔离
十、下一步执行顺序 NEXT ACTIONS
确定首个试点区域不要一开始覆盖整个阿里，先选一个真实可控、能完成履约的区域。
盘点真实供给确认公司自营项目和 2 至 3 家合作商户的名称、价格、时间、容量和责任。
定义目的地与路线数据先把目的地、路线节点、服务项目、状态和更新时间字段确定下来。
改造首页和目的地入口先验证“看懂阿里 → 发现周边 → 提交咨询”是否发生。
再做商户工具和履约等路线产品真实成立后，再投入订单、核销和结算的完整改造。
第一条要跑通的链路：第一次来阿里 → 冈仁波齐 → 周边目的地 → 一条短路线 → 公司自营项目 → 2 至 3 个合作商户 → 咨询/预约 → 履约记录。