三星堆看展辅助小程序制作经验总结

1. 先定义产品边界，不要一上来做“大而全”

这次三星堆看展辅助小程序最有效的做法，是把 V1 明确收敛成“现场理解辅助工具”，而不是售票、社交、UGC 或完整知识库。产品核心不是替代博物馆官方体系，而是解决观众在展厅里的几个高频问题：

• 不知道从哪里开始看
• 看到了重点器物，但不知道该看什么
• 展厅网络弱，视频和图文容易失效
• 对神话、考古、器物关系有兴趣，但不想读学术论文

因此内容和页面都围绕四件事展开：

• 导引首页：先交代展览定位、主题线索、官方入口
• 展品索引：按看展顺序组织，而不是按百科分类组织
• 详情页：给出“看什么”“怎么理解”“还能延伸到哪里”
• 缓存中心：把弱网问题当作主流程，而不是异常流程

这个边界判断很关键。看展辅助小程序的价值，不在“信息总量最多”，而在“观众站在展柜前时最能用得上”。

2. 内容结构必须按“现场浏览动作”设计

三星堆项目里，内容不是先写长文再拆页面，而是先按现场动作组织：

• 先用主题总览建立观看框架
• 再用分段展品卡片承接实际观看顺序
• 每张卡片只回答少数关键问题
• 对高兴趣用户再开放延伸阅读

data/content.js 里的结构说明了这件事：

• guide 负责展览级框架
• prologueThemes 负责主题组织
• browseIndex 负责具体展品段落
• guideScript、viewingGuide、guideTips 负责“站在现场能直接用”的解释
• hasExtensionReading 负责知识深挖分流

这里最值得复用的经验是：每个展品卡不要试图解释一切，而要稳定回答下面四个问题：

1. 这是什么
2. 为什么重要
3. 站在现场应该看哪里
4. 它和前后展品、整条叙事线怎么连起来

3. 好的看展内容不是“堆知识”，而是“降理解门槛”

三星堆项目最成熟的内容方法，不是把资料改写成百科，而是把每段讲解改写成观众能立即使用的观察提示。

例如这类表达比“学术正确但不可用”的写法更有效：

• “先看眼眶、鼻梁、口部处理”
• “注意双手之间那个空位”
• “先看整体轮廓，再看人物，再看动物，最后看建筑”

这说明博物馆小程序内容生产要遵循三条规则：

• 先解释用户眼前能看到的东西，再补抽象意义
• 可以给联想入口，但必须区分“可靠事实”和“推测路径”
• 不要把观众逼进长篇文字，重点是帮他看懂展柜

三星堆题材尤其说明了一点：神话联想很有吸引力，但必须控边界。像纵目面具、青铜神树、太阳神鸟这类内容，可以提供《山海经》式联想卡，但要明确标注“这是理解入口，不是定论”。

4. 多媒体不是装饰，而是内容组织方式

这个项目没有把视频当作宣传素材，而是把视频切成 35 个“可消费的观展单元”。这比单条长视频更适合展厅场景，原因有三点：

• 用户在现场停留时间短，只会消费短段内容
• 展品理解本来就适合按单件器物或单组主题切分
• 弱网环境下，短片段更适合缓存、失败回退和分批下载

因此，一个博物馆看展小程序如果要上视频，最优先考虑的不是“拍得多完整”，而是：

• 是否能切成顺序清晰的短段
• 每段是否只服务一个理解目标
• 每段是否能独立缓存和独立失败恢复

5. 弱网和缓存不是补丁，是主设计对象

这次最重要的工程经验，不是页面写法，而是对微信运行环境的重新认识。

项目一开始用本地 127.0.0.1 提供视频联调，这对原型成立，但对真机、审核、发布都不成立。后续必须切换到：

• 云存储或合规 CDN
• wx.cloud.init()
• cloud:// 作为资源标识
• wx.cloud.getTempFileURL() 把资源 ID 转成临时可访问链接

真正有效的经验不是“把本地地址换成云地址”，而是接受微信小程序的资源链路和 Web 直觉不同：

• 资源 ID 不等于可直接播放地址
• 展示前通常要先取临时 URL
• 下载、播放、缓存、失败提示要分步骤处理

utils/cache.js 的做法值得直接复用：

• 缓存状态显式建模：not_cached、queued、downloading、cached、failed_network、failed_storage、using_online_fallback
• 下载流程串行化，避免并发过高
• 本地持久化失败时允许回退到临时文件路径
• 缩略图临时链接单独缓存，避免重复取 URL

这说明“博物馆现场导览”这类产品，缓存中心不是次要页面，而是核心能力页。

6. 发布版和原型版必须分离

这次复盘里最明确的工程教训，是原型目录和发布目录必须物理分开。

原型阶段可以容忍：

• 本地测试页
• 临时联调脚本
• 本地资源占位
• 试验性页面

发布阶段则必须单独收敛：

• 只保留真正参与上传和审核的代码
• 配齐云函数、云环境、配置文件
• 去掉本地大资源，控制主包体积
• 把调试能力改造成面向云链路的诊断页

否则很容易出现“本地能跑、开发者工具能预览、但真机和审核不过”的错觉。

7. 页面设计要围绕“导引-浏览-详情-缓存-来源”闭环

三星堆项目的页面结构很克制，但非常适合博物馆场景：

• index：导引页，告诉用户这展怎么进入
• segments：展品列表页，承接实际浏览顺序
• detail：单段内容消费页
• readings：高兴趣用户的延伸阅读
• cache：现场稳定性保障
• sources：来源透明与可信度托底

这个结构说明：博物馆小程序不需要复杂信息架构，但必须有完整闭环。尤其 sources 页很重要，它给了内容可信度，也方便处理“哪些是官方事实、哪些是二次解读”的边界。

8. 最值得复用的通用方法

如果以后再做其他博物馆看展辅助小程序，这次三星堆项目最值得复用的是以下方法：

1. 先做“主题线 + 现场顺序 + 单展品卡片”的三层内容结构。
2. 每个展品只解决一个主要理解任务，不追求讲全。
3. 把“看哪里”写进内容，而不是只写“是什么”。
4. 把延伸阅读和主导览分层，避免主流程过重。
5. 把弱网、缓存、失败提示当主流程设计。
6. 从项目早期就按微信发布模型准备资源和配置。
7. 原型、发布、诊断工具链分目录维护。

9. 一句话结论

三星堆看展辅助小程序的成功经验，不是做了很多功能，而是把“现场导览”“短段内容”“弱网可用”“解释门槛低”“官方事实和延伸解读分层”这几件事同时做对了。博物馆看展辅助产品要先解决观众站在展柜前的真实决策，再谈更复杂的互动和传播。