当前四层是：
这套分法有一定合理性，但它更像是产品体验分层，不是严格的技术架构分层。
材料中叙事层包含：
决策层包含：
但用户在叙事页面中同样会看到：
这些内容一旦进入叙事层，就会和现有商户 DSL 的内容发生重叠。
判断依据：当前已经存在“商户页 DSL 模板链路”，而 v3 又计划在叙事层承载住宿、装备、行程等业务主题。若不划边界，后续会出现同一内容在两个系统维护。
建议采用以下边界：
| 层级 | 负责什么 | 不负责什么 |
|---|---|---|
| 叙事入口层 | 讲故事、制造情绪、引导用户产生兴趣 | 不维护完整商户商品/服务信息 |
| 商户决策层 | 展示酒店、服务、适用人群、咨询事项、商户差异 | 不承担品牌主叙事 |
| 工具层 | 行程、核销、订单、个人中心、客服会话 | 不参与主题视觉表达 |
| 基础设施 | 路由、文案、主题变量、埋点、权限、资产加载 | 不承载具体故事内容 |
一句话定义：
叙事层负责“为什么值得去”，决策层负责“具体怎么去、问什么、找谁”。
叙事页中的酒店、装备、行程只展示“摘要卡”和“入口”，详情仍回到决策层或工具层。
对于“全推客服”的模式，真正的核心不是五段内容，而是：
当前四层中没有明确体现这部分。
至少需要定义：
入口来源 → 主题首屏 → 关键信息卡 → 客服 CTA → 咨询上下文例如：
商户码 mid=8
→ 直接展示“芝达布日温泉酒店 + 神山启程”
→ 用户选择“住宿 / 转山准备 / 装备 / 行程”
→ 点击客服
→ 自动携带来源、选择项、当前页面、商户信息这比单纯把用户带到一个“故事首页”更接近实际商业目标。
客服入口至少应携带：
材料未涉及客服系统是否支持上下文透传，因此需要先确认技术能力。若客服工具不支持自动携带上下文，至少在进入客服前展示一段可复制咨询话术。
以下能力可以在 Phase 1 保留接口：
这些都是低成本、低风险的“未来可演进接口”。
以下内容不应在当前阶段实现：
判断依据：当前只有一个商户、一个主题、一个核心转化目标，尚未验证多商户、多主题是否有真实需求和重复配置规律。此时建设这些能力，验证的是平台架构，而不是商业模式。
不要做“主题系统”，做一个本地主题配置对象即可：
const shenshanTheme = {
brand: {
primaryColor: '#...',
backgroundColor: '#...',
titleFont: '...',
},
assets: {
homeHero: 'cdn-url',
chapterDivider: 'cdn-url',
},
copy: {
heroTitle: '...',
heroSubtitle: '...',
},
chapters: [...]
}但这个对象只服务神山秘境一个主题，不要设计成所有未来主题都必须服从的复杂协议。
更重要的是：不要让叙事主题配置复刻现有 DSL。
建议：
如果“数据驱动章节”只是把五段章节的标题、文案、图片、跳转链接配置化，成本可控，值得做。
如果它意味着：
那么对于当前项目明显过度工程。
材料已经有：
当前真正缺的不是“内容可配置能力”，而是验证：
将章节拆成三类：
直接写死：
配置：
暂时不要配置：
可采用这样的简单结构：
const chapters = [
{
id: 'arrival',
title: '抵达',
subtitle: '...',
cover: '...',
cta: {
text: '了解启程仪式',
action: 'open_service'
}
}
]这已经足够支持文案和视觉迭代。
“全屏沉浸故事”容易引入：
材料提到主包 2MB、字体子集和 CDN，但没有提供首屏资源预算、弱网加载指标或图片体积标准。
材料未涉及：当前首屏实际资源大小、平均加载时间、弱网环境表现。
建议明确验收指标：
建议原则：
首屏先显示核心文案和 CTA，再异步加载氛围资产；不能因为沉浸视觉导致用户看不到客服入口。
全屏叙事容易形成“只能往下看”的体验。小程序用户可能直接想看：
建议固定提供：
材料强调扫码进入，但未说明：
这是一个关键缺口。
建议定义：
平台码：进入神山品牌叙事首页
商户码：进入该商户专属决策页或商户定制首屏
分享链接：保留 tenant、scene、主题和当前内容入口“抵达→安顿→准备→出发→归来”有完整的旅程感，也符合“转山故事”的品牌表达。
但它不一定符合扫码用户的即时需求。
扫码用户可能是：
将所有用户统一放入“抵达”叙事，会增加认知成本。
用户更现实的决策顺序可能是：
这是什么
→ 适不适合我
→ 能提供什么
→ 怎么咨询
→ 我现在要不要去而不是：
抵达
→ 安顿
→ 准备
→ 出发
→ 归来30 秒内用户很可能只会完成：
如果用户必须经过五个章节才能找到客服，转化一定受损。
首页只回答四个问题：
推荐结构：
首屏品牌主张
↓
一句话说明服务价值
↓
三项核心选择
↓
真实/具体的服务承诺
↓
客服 CTA
↓
五段旅程入口不建议只放抽象的“神山密钥”“一盏灯引你进山”。
应当采用：
品牌概念 + 用户收益 + 明确行动示例结构：
在神山脚下，找到你的启程方式
住宿、转山准备与启程咨询
先问问此刻最适合你的安排
具体文案需要根据实际服务能力确认。材料未提供酒店可提供的具体住宿、装备、行程和仪式服务，因此不应直接承诺未确认的能力。
入口不宜按五段旅程展示，建议按用户问题展示：
如果实际业务中还有其他高频问题，可由客服数据验证后调整。当前真实用户问题分布，材料未涉及。
首屏至少有一个强 CTA：
不要只使用“探索”“进入秘境”“继续旅程”等弱动作词，因为用户不清楚点击后能得到什么。
保留五段，但调整定位：
抵达：我来到神山脚下
安顿：住在哪里、如何休整
准备：转山前需要准备什么
出发：如何开启行程
归来：留下怎样的足迹每段只承担两件事：
例如：
| 章节 | 内容重点 | CTA |
|---|---|---|
| 抵达 | 神山脚下的第一感受、启程概念 | 了解启程 |
| 安顿 | 酒店环境、住宿价值、休整体验 | 查看住宿 |
| 准备 | 装备、身体状态、注意事项 | 咨询准备 |
| 出发 | 转山服务流程、行程信息 | 咨询行程 |
| 归来 | 足迹、纪念、分享 | 留下我的足迹 |
其中“行程核销”“归来足迹”等功能是否现在已具备，材料只说明工具层有相关能力，但未说明 C 端实际可用范围。上线时不能只按概念设计，需确认真实服务流程。
材料已经有两种 scene：
这正好可以支持不同转化路径，不应让两种入口都进入同一套首页。
适合：
品牌首屏
→ 30 秒故事
→ 三个用户问题入口
→ 进入商户/服务选择
→ 联系客服目标是让用户先理解“神山秘境是什么”。
适合：
商户品牌首屏
→ 酒店/服务核心价值
→ 可咨询事项
→ 立即联系客服
→ 其他旅程内容作为辅助目标是让用户尽快咨询这家商户，不要先要求用户看完平台故事。
用户扫描商户码时，通常已经对该商户或该场景有明确兴趣。此时仍强制进入完整品牌叙事，会造成路径绕行。
但用户扫码的具体来源、扫码场景和用户意图，材料未涉及，建议上线后通过 scene 埋点验证。
建议首屏结构如下：
内容：
目标：用户 5 秒内知道这里是什么。
不要先展示五个章节，而展示：
目标：让用户找到自己的问题入口。
用“抵达—安顿—准备—出发—归来”的横向或纵向内容，让用户感受品牌。
目标：增强信任和记忆，不阻塞转化。
展示：
CTA 保持固定。
回到现有 DSL 商户页，展示具体服务信息。
建议在叙事页固定保留：
咨询启程或：
问问客服点击后不要直接丢给客服，而是先提供三到四个快捷选项：
选择后再进入客服，并将选择结果带入上下文。
这能把“全推客服”从一个泛入口变成一个有意图的线索入口。
不要出现只有气氛、没有下一步的章节。
每一章至少有：
情绪内容 + 事实信息 + 一个 CTA例如：
准备
- 情绪：启程前的安定感
- 事实：准备哪些事项，信息来源是什么
- CTA：咨询我的准备清单如果某章节暂时没有真实业务承接，就不要在 v3 首期重点建设。
建议首期只实现：
不要一开始做完整 46 页重构。
材料未提供现有基线数据，因此建议先建立以下指标：
“有效动作”不能只定义为页面浏览，应至少包括：
采用：
固定叙事壳
+ 简单本地主题配置
+ 现有商户 DSL
+ 统一客服转化组件
+ scene 上下文
+ 基础埋点不做：
主题注册表
主题编辑器
主题动态下发
叙事 DSL
白标系统
复杂多租户主题继承只有当第二个商户出现相同需求时，再抽象：
只有当第二个主题出现且确认存在内容复用时，再建设：
白标化应最后做，因为它不仅是视觉换肤，还涉及：
这些内容当前材料未涉及，不能仅按“换主题”估算。
四层架构可以保留，但应从“未来平台架构”收缩为“当前产品边界”。Phase 1 留缝是恰当的，前提是只留 token、文案、资产、路由和内容配置接口，不建设主题平台。
叙事层数据驱动章节可以做轻量版，不应做通用叙事 DSL。固定结构、配置内容、固定交互，是当前成本和收益最匹配的方案。
五段旅程适合作为品牌叙事主线，不适合作为扫码后的主信息架构。扫码 30 秒转化应优先采用：
价值主张
→ 用户问题入口
→ 具体服务承接
→ 客服 CTA
→ 五段旅程作为深层内容核心原则是：
先让用户愿意问，再让用户慢慢看；不要要求用户看完故事，才有资格进入客服。