核心判断依据：

四个 Tab 必须分别对应“发现—选择—现场连接—个人沉淀”四种不同任务，否则首页、玩法、在地会变成三个重复的内容/服务集合页。

二、内容块级分配表

1. 首页现有内容块

2. 玩法页现有内容块及新增能力

3. 在地页现有内容块及服务能力

4. 我的页现有内容块及用户资产

5. 明确的挪动、删除、合并清单

从首页挪走

• 今日推荐完整卡片 → 玩法。
• 在地的人完整人物卡 → 在地。
• 我的历程 → 我的。
• 规划工具 → 玩法。
• 需求广场主入口 → 玩法。
• 找补给 → 在地。
• 语音导览 → 玩法。
• 原五个快捷入口 → 拆分到玩法和在地。

从玩法挪走

• 住宿、餐饮、交通服务入口 → 在地。
• 详细商户服务信息 → 在地。
• 主理人完整名片 → 在地。

删除或不再作为独立块

• 首页和玩法重复的完整“服务入口”之一：首页删除完整服务入口。
• 首页和玩法重复的完整“需求广场”之一：首页删除主入口。
• 首页和在地重复的完整“主理人卡”之一：首页删除完整主理人卡。
• “我的历程”在首页作为独立模块：删除，改为轻量回访入口。
• 多处重复的“示意数据声明”：不删除合规信息，但改为数据就近说明。
• “转山·信仰”作为独立大入口：不删除转山内容，删除其独占式入口表达，改为六项目之一。

合并

• “我的收藏”与“心愿清单” → 收藏与心愿。
• “主理人故事”和“主理人服务” → 一个主理人体系，内容来源在玩法，服务承接在在地。
• “今日推荐”和“按体力挑一段” → 统一为玩法卡片体系，首页只保留推荐摘要。
• “今日卡”中的天气、风力、路况、观星指数 → 统一为今日状态卡，由 A 端配置字段和排序。

三、四页首屏结构：各页前 3 屏

以下按“用户首次进入页面后的连续浏览顺序”定义，不对应具体像素高度。

1. 首页：内容杂志流

第1屏：让用户知道“今天这里怎样”

1. 顶部搜索。
2. Hero 大图与一句平台品牌文案。
3. 今日状态卡：
4. 藏历；
5. 天气；
6. 路况；
7. 观星指数；
8. 一句“今天适合做什么”的可配置提示。
9. 非主导式“继续上次旅程”入口。

第2屏：让用户看到“阿里不只有转山”

1. 六项目矩阵：
2. 转山；
3. 观星；
4. 圣湖；
5. 温泉；
6. 寺院；
7. 野生动物。
8. 每个项目使用专属场景色，不扩散为全局色彩体系。
9. 大阿里目的地横滑：
10. 古格；
11. 土林；
12. 班公湖；
13. 札达；
14. 普兰。
15. 点击项目或目的地进入玩法，而不是直接进入商户目录。

第3屏：让用户产生“我可以这样走”的想象

1. 攻略流/今日玩法预告。
2. 单张或少量“地方走法”卡片。
3. 主理人署名作为内容来源。
4. “去玩法页挑一段”按钮。
5. “需要现场有人接应？”进入在地。
6. 客服收口。

首页不出现完整需求广场、完整服务九宫格和完整主理人卡。

2. 玩法：帮助用户做选择

第1屏：先回答“我现在适合怎么玩”

1. 页面标题与目的地筛选。
2. “今天可走”主卡。
3. 按体力、时间、兴趣的快速筛选：
4. 轻松；
5. 半天；
6. 一天；
7. 多日；
8. 文化；
9. 自然；
10. 转山。
11. 规划工具入口：
12. 走几天；
13. 想靠近哪里；
14. 生成我的规划。

第2屏：按场景找玩法

1. 六项目或五类场景横滑。
2. “按体力挑一段”卡片流。
3. 卡片统一展示：
4. 适合谁；
5. 大约需要多久；
6. 大约走多远；
7. 难度/体力；
8. 是否需要联系在地服务；
9. 参考费用或费用说明；
10. 线下直结标识；
11. 商业推广标识。
12. 语音导览入口嵌入对应项目或路线卡。

第3屏：准备出发与找同行

1. 出发准备：
2. 身体自查；
3. 边防证办理指引；
4. 行前安全；
5. 语音导览。
6. 大阿里目的地内容。
7. 需求广场。
8. 卡片底部统一引导：
9. “需要住宿/交通/餐饮/补给？”→在地；
10. “想找同行或提出需求？”→需求广场。

3. 在地：帮助用户现场找到人和服务

第1屏：先让用户知道“谁现在能帮我”

1. 页面标题“阿里在地服务”。
2. 服务分类：
3. 住宿；
4. 餐饮；
5. 交通/接驳；
6. 补给；
7. 讲解；
8. 温泉；
9. 紧急帮助。
10. 当前状态通知：
11. 营业/可联系；
12. 暂停接待；
13. 更新时间。
14. 平台责任提示。

第2屏：看具体服务和商户

1. 在地精选服务卡：
2. 服务内容；
3. 适用地点；
4. 所需时长；
5. 费用范围；
6. 可联系时间；
7. 谁提供；
8. 谁负责；
9. 线下直结说明。
10. 商户名片：
11. 塔钦山口茶屋；
12. 圣湖岸边接驳；
13. 芝达布日温泉酒店等。
14. 服务详情和客服联系入口。

第3屏：先认识人，再决定是否联系

1. 主理人卡：
2. 姓名；
3. 所在地；
4. 能做什么；
5. 更新时间；
6. 当前是否接待。
7. 主理人发布的福钥任务。
8. “从玩法而来”的回链：
9. 某条路线需要补给；
10. 某个项目可联系讲解；
11. 某个温泉玩法对应酒店供给。
12. 紧急帮助固定入口。

4. 我的：管理个人旅程

第1屏：继续进行中的旅程

1. 用户身份卡。
2. 继续我的旅程。
3. 当前行程状态：
4. 第几天；
5. 下一站；
6. 下一步动作；
7. 必要提醒。
8. 返回玩法或现场信息。

第2屏：看我已经留下什么

1. 四项资产：
2. 福钥；
3. 印章；
4. 手记；
5. 收藏。
6. 最近抵达地点。
7. 最近一篇手记。
8. 已完成旅程。

第3屏：整理下一次出发

1. 我的路线：
2. 计划中；
3. 已收藏；
4. 心愿清单。
5. 联系/服务记录，如业务和合规允许。
6. 数据同步状态。
7. 设置、帮助、关于。

四、Tab 间的信息引路设计

1. 首页如何引到玩法

首页不直接把用户送入复杂目录，而是通过“内容—选择”引导：

原则：首页只提供“为什么值得去”和“可能怎么去”，具体筛选、比较、规划全部在玩法完成。

2. 首页如何引到在地

首页不保留完整服务入口，但可保留一条明确的情境式入口，例如“到了这里，谁能帮我”。

3. 玩法与在地如何互相衔接

玩法 → 在地

每个玩法卡只在确有必要时展示以下情境入口：

• 需要住宿；
• 需要接驳；
• 需要补给；
• 需要讲解；
• 需要温泉休整；
• 需要现场帮助。

点击后进入在地的对应筛选结果，而不是进入泛化首页。

在地 → 玩法

每个服务或主理人名片可展示：

• 适合搭配的玩法；
• 适用地点；
• 适合人群；
• 对应项目；
• 相关攻略或语音导览。

例如芝达布日温泉酒店应关联“温泉”项目和休整型玩法，而不是直接包装为“住宿+交通+游览”的组合产品。

4. 重复入口如何收敛

五、与平台定位的对齐检查

1. 转山是否只是流量因子

结论：符合，但必须做到“首页接住、不独占”。

具体分配：

• 首页：Hero 或今日推荐可以使用冈仁波齐和转山作为强内容钩子。
• 玩法：转山只是六项目中的一个，同时展示观星、圣湖、温泉、寺院、野生动物。
• 在地：承接转山所需的住宿、补给、接驳、讲解和现场协助。
• 我的：记录用户实际完成的路线、印章、手记和旅程，不把个人资产限定为转山。

依据：平台定位明确为阿里周边综合旅游服务，不是转山专用工具。

2. 自营温泉酒店是否被正确处理

结论：作为首批供给重点承接，但不应成为平台品牌主角。

建议位置：

1. 首页六项目矩阵中的“温泉”入口，可出现内容预告；
2. 玩法页温泉项目中，展示温泉体验和相关玩法；
3. 在地页温泉服务分类中，展示芝达布日温泉酒店商户名片；
4. 我的页只在用户收藏、计划或联系后出现个人记录。

不得做：

• 首页大面积酒店品牌广告；
• 把酒店包装成平台总品牌；
• 与交通、景点、餐饮组合为包价产品；
• 使用未核实的“神山起点”等表述作为核心卖点。

“神山密钥/到神山拿钥匙”只能按材料定义作为品牌仪式创作，并明确不是宗教传统。

3. 六项目矩阵如何在四页展开

颜色规则：

• 六项目场景色只用于项目卡和项目详情页；
• 不把六种颜色扩散到全局导航、按钮和普通服务卡；
• 主行动色仍统一使用圣湖蓝，避免用户因为颜色过多而无法识别可点击操作。

4. 住/食/行/游/运输服务矩阵是否完整

• 住：在地，温泉酒店、客栈等。
• 食：在地，茶馆、餐饮服务等。
• 行/运输：在地，接驳、交通、补给相关服务。
• 游：玩法，路线、项目、内容和语音导览。
• 服务责任与客服：在地统一说明，客服进入 CRM 链路。

这样既保持平台综合服务定位，又避免把所有服务入口塞入首页。

5. 线下直结合规检查

所有服务详情和联系按钮附近必须同时出现：

• 服务由谁提供；
• 费用由谁收取；
• 平台是否参与；
• 平台负责什么；
• 平台不负责什么；
• 是否线下直结；
• 是否仅为信息展示；
• 联系后不代表平台承诺履约。

禁止：

• 平台代收款；
• 平台确认交易；
• 平台打包报价；
• 平台承诺服务一定可用；
• 用多个单项服务组合成旅行社式包价产品。

所有费用范围、可联系时间、暂停状态、推荐数量、福钥规则等运营数值均由 A 端配置，C 端不写死。

六、常见分配错误风险

风险一：四个 Tab 都做“内容+服务+工具”的大杂烩

表现：首页有服务入口，玩法也有服务入口，在地又有服务入口，用户不知道去哪找。

避免方式：

• 首页负责发现；
• 玩法负责选择和规划；
• 在地负责现场服务；
• 我的负责个人资产；
• 相同任务只保留一个主入口，其余只能做上下文跳转。

风险二：把转山做成平台主导航

表现：首页、玩法标题、核心按钮全部围绕转山，圣湖、温泉、寺院等被降级为边角内容。

避免方式：

• 转山可做最大流量钩子，但六项目矩阵必须在首页首屏后稳定出现；
• 玩法提供项目切换，而不是只有冈仁波齐切换；
• 自营温泉酒店和其他在地供给以服务能力出现，不被转山叙事吞没。

风险三：把主理人当内容 IP，同时又复制为商户列表

表现：首页有一套人物卡，玩法卡有一套作者卡，在地又有一套主理人卡，信息重复且状态不一致。

避免方式：

• 在地建立唯一主理人档案；
• 玩法只引用“来源主理人”；
• 首页只展示轻量语录或人物内容预告；
• 姓名、能力、地域、更新时间、接待状态以在地档案为准。

风险四：把线下直结做成“平台下单感”

表现：按钮写“立即预订”“立即付款”，页面展示平台打包价或承诺到店。

避免方式：

• 使用“查看服务”“联系现场”“咨询可用时间”等表达；
• 费用使用单项参考范围；
• 联系按钮旁固定显示责任说明；
• 不出现代收、平台确认和履约承诺。

风险五：为了“丰富”堆叠过多卡片和运营数字

表现：页面充满“今日X人”“剩余X席”“热度X”等固定数字，低文化水平用户难以判断重点，且弱网下加载成本高。

避免方式：

• 首屏只保留当前任务相关的信息；
• 数值和状态全部 A 端可配；
• 无真实数据就明确标注示意，不把示意数据当核心卖点；
• 使用“适合谁、要多久、能做什么、谁能帮我”等直白字段替代复杂营销文案。

七、给低文化水平用户的设计含义

1. 用“任务语言”替代抽象栏目语言

少使用：

• 目的地探索；
• 资源整合；
• 特色体验；
• 深度发现。

优先使用：

• 今天适合怎么玩；
• 我能走多远；
• 住哪里；
• 谁能帮我；
• 现在能不能联系；
• 这段路要多久。

依据：用户文化水平不高，且手机使用、弱网环境多，页面必须先表达动作和结果。

2. 每页只解决一个主要问题

• 首页：这里今天怎样？
• 玩法：我这一程怎么玩？
• 在地：谁现在能帮我？
• 我的：我已经走到哪了？

避免一个页面同时出现“看内容、找服务、做规划、管资产”。

3. 减少需要读懂的层级

• 六项目用图像、短标题和场景色辅助理解；
• 玩法卡固定展示“适合谁、多久、难不难”；
• 在地卡固定展示“谁提供、在哪里、现在能不能联系”；
• 重要责任说明使用短句、分行和就近提示；
• 不把关键规则藏在长文章或二级帮助页。

4. 用视觉和状态帮助弱网用户判断

• 首屏减少大面积动态内容；
• 今日卡优先显示轻量关键字段；
• 服务卡显示明确的“可联系/暂停/更新时间”；
• 重要操作提供文字，不只依赖图标；
• 图片加载失败时仍能看到项目名称、地点和下一步动作。

5. 不让用户理解复杂商业规则

用户不需要先理解平台商业模式，只需要看懂：

• 这是谁提供的；
• 大概多少钱；
• 我能不能联系；
• 平台负责什么；
• 平台不负责什么。

但“线下直结、不代收、不承诺履约”等合规内容必须以简单直接的方式表达，不能因为追求简洁而省略。

6. 保留弱互动，但不让互动取代任务

可以保留：

• 今日观星指数；
• 今日适合玩法；
• 福钥任务；
• 印章和手记；
• 轻量需求发布。

但不能让点赞、打卡、复杂社区互动挤占“选玩法、找服务、看状态、继续旅程”这些核心任务。

最终分配原则：

首页负责把人留下，玩法负责帮人选，在地负责让人找到真实的人和服务，我的负责让旅程继续。四页之间可以互相引路，但不能互相复制。