不要把诗写死在代码里——一张表搞定全部点位元数据。
第三章开始讲内容数据。很多人会以为诗词只是页面文案：找一些名句，放到卡片里，配一个地点，就结束了。这个理解太浅了。对诗贯山河来说，诗词数据不是文案库，而是整个地图引擎的导演表。
为什么这么说？因为一首诗不仅决定用户读到什么，还决定点位落在哪里、镜头飞向哪里、要不要触发雨雪烟气、配什么声音、属于哪个区域、和哪些古地名发生关系。只要你把诗词当文案写死，这些能力都会退化成手工 if else。
内容数据为什么会变成工程问题
视觉作品最容易出现一种问题：代码很复杂，但内容很脆弱。比如你手写了 56 个点位，每个点位里塞一段诗、一个坐标、一个卡片颜色、一个动画参数。第一版可以跑，等你想新增第 57 首诗、换一个区域、批量筛选唐代作品时，就会发现没有任何结构能支撑这些操作。
所以第三章要解决的，不是「怎么录入诗词」，而是「怎么设计一份能驱动地图、镜头、特效和卡片的诗词数据」。这个问题解决好了，诗贯山河才有机会从单个作品变成内容系统。
一首诗不只是 title 和 body
- slug：稳定 URL 或内部 id，不随标题改动。
- title / author / dynasty：卡片展示的核心信息。
- body：正文，建议按行存储，方便排版。
- location：经纬度或投影后坐标，用于点位。
- region：归属区域，用于筛选和分组。
- tags：山水、边塞、怀古、送别等主题标签。
- audioCue / effectCue：可选字段，用来驱动声音和局部特效。
这些字段可以分成三类：展示字段、空间字段、导演字段。展示字段给用户看，空间字段把诗放到地图上，导演字段用来驱动画面行为。很多项目只做了第一类，所以它只能展示；诗贯山河要三类都做，才能让内容参与交互。
slug 为什么比标题更重要
标题会重复，标题也可能调整，但 slug 必须稳定。它是数据、路由、埋点、缓存、后续内容管理之间的锚点。比如「登高」这样的标题可能不只一首，单靠 title 作为 key 很快会出问题。slug 应该表达稳定身份，而不是展示名称。
- 展示名称可以改，slug 尽量不改。
- slug 不要依赖数组下标，排序一变就全乱。
- slug 最好可读，比如 author-title 或 region-short-title。
- 埋点和用户行为记录里也应该使用 slug，而不是中文标题。
location 不是一个点那么简单
诗词和地点的关系有强有弱。有些诗明确写某座楼、某条江、某座山；有些诗只是和某个区域、作者生平或历史事件相关。你不能把所有 location 都当成同一种置信度。否则地图看起来很确定，实际上内容关系可能很牵强。
更稳的做法是给地点关系加元信息：locationType、confidence、source、displayOffset。locationType 表示它是精确地点、城市级地点、区域级地点还是文学意象地点；confidence 表示可靠程度；source 记录来源；displayOffset 用来解决视觉避让，但不污染真实坐标。
采集时不要只看名气
如果只选最有名的诗，地图会变成唐诗宋词合集，传播性有了，但空间关系会弱；如果只按地理位置选，地图很准确，但用户可能没有记忆点。诗贯山河要在文学辨识度、地理关联度和画面想象力之间取平衡。
- 文学辨识度：读者看到标题或名句能快速产生熟悉感。
- 地理关联度：诗和地点之间不是牵强绑定。
- 画面想象力：这首诗是否能自然对应雨、雪、风、江、山、古城等视觉线索。
标签不是给搜索用的，是给系统用的
tags 很容易被写成装饰字段，比如山水、边塞、送别、怀古。但在诗贯山河里，标签应该参与系统决策。边塞类诗词更可能触发风沙，江南类诗词更适合细雨，山寺类诗词适合烟气，送别类诗词的镜头节奏可以更慢。
- 主题标签：山水、边塞、怀古、送别、田园。
- 空间标签：江河、山岳、古城、关隘、寺庙。
- 情绪标签：孤独、旷达、离别、豪迈、清冷。
- 视觉标签：雨、雪、风、烟、水、夕照。
当标签体系稳定后，很多功能就能从数据里自然长出来：筛选、推荐、批量生成镜头、自动匹配音频 cue、控制特效默认参数。标签不是为了后台好看，是为了减少未来写死逻辑。
去重不是删重复标题
诗词数据的重复，经常不是标题重复，而是表达功能重复。比如三首诗都指向同一座城、同一种情绪、同一个镜头节奏，那用户连续点击时会感觉内容换了，但体验没变。真正的去重，要看空间分布、朝代分布、作者分布、情绪分布和视觉分布。
- 空间分布：不要让点位全部挤在少数名城。
- 朝代分布：唐宋当然重要，但不要让时间层次过于单一。
- 作者分布：李白杜甫苏轼辨识度高，但不能垄断地图。
- 情绪分布：豪迈、清冷、离别、闲适要交错出现。
- 视觉分布：不要连续触发同一种天气或同一种构图。
正文排版也应该从数据开始
诗词正文最好不要只存成一个长字符串。古诗词天然有行、句、标点、注释、名句高亮等结构。如果你只存纯文本，后面卡片排版会很难做；如果一开始按 lines 存储，DOM 渲染、逐行入场、名句强调都会简单很多。
- 短诗可以完整展示，长诗需要摘要和展开策略。
- 名句可以单独标注，给首屏卡片或短视频标题使用。
- 正文行数会影响卡片高度，因此应该进入布局计算。
- 注释和译文可以先不展示，但数据结构最好预留位置。
一份健康诗词数据的验收标准
- 每首诗都有稳定 slug，且不依赖数组顺序。
- 每首诗都能解释为什么放在这个区域或点位。
- 坐标字段和展示偏移字段分离。
- 标签能驱动筛选、特效、音频或镜头，而不是只做装饰。
- 新增一首诗时，只需要补数据，不需要改渲染逻辑。
串一下
一次用户点击诗词点位，背后其实经历了这样一条链路：点位 slug 找到诗词数据，location 映射到 Three.js 世界坐标，tags 决定默认氛围，effectCue 激活局部 Volume，audioCue 播放声音，body 渲染到诗文卡片，镜头系统根据目标坐标完成飞行。用户看到的是一张卡片，系统执行的是一整套数据驱动流程。