听到一支喜欢的乐队，接下来通常是找它的其他专辑，再看看有什么相近的乐队。多走几步，就会碰到一串风格名称：Punk、Post-Punk、Alternative、Grunge、Shoegaze。
名字能查到，关系却未必容易看清。某种风格是另一种的分支，还是受它影响？两支乐队经常被放在一起，是因为声音相似，还是共享过一个场景和发行网络？
一个阳光的午后，做了一杯咖啡，听着Pink Floyd的“Comfortably Numb”，我突然冒出一个灵感，想要搭建一个摇滚风格谱系知识图谱。
灿烂的摇滚群星，嗯，那么我们就用星图作为整体视觉基调来搭建这个Rock Atlas 摇滚星图。他是一个纯兴趣作品，访问链接如下：
可以从一个风格开始，进入相关艺人，再看作品和来源；也可以先找熟悉的艺人，沿它所在的关系继续走。它想把散落在目录和资料里的线索放进一个可以浏览的空间，让下一次探索有个起点。
01. 最初的想法：让音乐资料之间能走得通
项目最早使用了 Music Wiki 这个名字，目标是组织摇滚音乐中的风格、艺人、作品及关系证据。
音乐资料不缺，难的是把不同来源接起来。同一个艺人可能有不同拼写，一张专辑会有多个发行版本，各数据库对风格的划分也不一致。把名称放进几个表格，只完成了第一步；要沿着关系继续探索，还得确认这些名称是不是同一个对象，以及关系究竟说了什么。
因此，早期设计就把来源与证据纳入了数据结构。资料不完整时保留未知，来源冲突时留下差异，不能为了让一条路径看起来完整，就顺手补一个猜测。
这个原则也约束视觉设计：画布上距离近，不意味着音乐史上存在影响；有一条漂亮的线，也不意味着背后有足够的证据。
02. 先用小样本比较，再逐步扩展
早期工程实验冻结过一份包含 20 个风格、100 位艺人、200 个作品组和 9 条代表录音的小样本，用同一套内容比较 3D、2D 和编辑型阅读界面。
这一步的意义，是先让数据、文字、关系和操作一致，再比较不同呈现方式。否则，3D 版放了熟悉的乐队，列表版放了陌生名字，最后测出的可能只是内容差异。
后来，项目逐渐形成了现在的星图方向：从全局看风格，选择风格后看艺人，再深入作品和关系资料。目录也扩展到当前的限定快照。
从开发记录看，几个阶段可以这样理解：
| 阶段 | 主要变化 | 仍需区分的边界 |
|---|---|---|
| 早期小样本 | 用相同资料比较 3D、2D 与编辑型界面 | 工程样本不等于真实用户研究结果 |
| 目录扩展 | 扩展风格、艺人和作品，并建立跨来源身份与关系记录 | 一个艺人出现在多个风格中，不应重复计为多个艺人 |
| V3 静态目录 | 将概览、搜索与详情分开，按需读取数据 | 读取架构完成，不代表全量数据已经导入 |
| 2026 年 10 月 9 日 | 将前端独立成仓库，保留星图、深链和音频控件 | 仓库拆分不是新的数据覆盖证明 |
| 2026 年 10 月 12 日 | 补充可抓取说明、双语指南与文字目录 | 搜索入口完善，不等于搜索引擎已经收录 |
这些阶段让项目从一个展示想法，逐步变成可以发布、可以继续更新的工具。但是否真的帮助读者理解音乐关系，还需要用实际使用来检验。
03. 星云、恒星和轨道，各自对应什么
Rock Atlas 用一套空间比喻来组织资料：风格对应星云，艺人对应恒星，作品组对应轨道上的对象，关系用光桥表达。
这套设计最关键的地方是分层。全局视图先看风格，选定一个风格后，再加载相关艺人；选择艺人后继续查看作品。把所有层级一次性铺出来，信息和画面都会挤在一起。
浏览时可以用 Styles、Artists 和搜索找到起点，通过 Eras 缩小年代范围，或用 Relations 查看关系类型。语言与动效模式可以切换；喜欢文字阅读，或者设备不支持 WebGL，也有列表路径和独立文字目录。
星图负责给出空间感，详情和来源负责把信息说清楚。两者需要互相对应：在画布里选中的对象，应当就是列表和详情里正在看的对象。
第一次打开，建议先选一个自己熟悉的风格，点开相关艺人和作品，再检查一条关系的类型与来源。熟悉的名字能帮你判断，这张图究竟带来了新理解，还是只换了一种好看的排列方式。
04. 当前覆盖到哪里
截至 2026 年 10 月 13 日，仓库说明与线上指南对应的发布快照包含：
| 对象 | 数量 | 口径 |
|---|---|---|
| 音乐风格 | 828 | 当前限定目录中的风格对象 |
| 艺人 | 420 | 去重后的艺人，不按风格中的出现次数重复计算 |
| 作品组 | 528 | 以 ReleaseGroup 组织的作品，不能等同于全部发行版本或单曲 |
| 关系记录 | 997 | 仓库说明列出的当前关系数量，不代表每条都是历史影响关系 |
这些数量描述当前发布快照，不代表全球摇滚音乐的完整覆盖。 这是一个限定范围的目录，尚未完成全量 MusicBrainz、Discogs 等数据的导入。
当前项目已经有可运行的 V3 前端、按需搜索与详情读取、背景音频控件、双语界面，以及中英文使用指南和风格目录。本文写作时已打开线上星图和中文指南，页面显示的风格与艺人数与仓库说明一致。
网站可以公开访问，前端源码仓库目前仍为私有，仍在迭代中。当前网站前端部署的是 V3 这个版本。
05. 为什么后来拆成三个部分
现在的职责分成了前端、离线数据处理和 JSON 构建发布三个部分。
前端负责星图、查询和阅读；离线处理负责来源获取、身份核对与规范化；构建部分将整理好的数据转成网站能读取的静态文件。
这样拆开以后，读者打开网站时不需要连接作者本机的数据库。首页先读概览，进入一个风格或艺人后，再取相应的详情和搜索分片。长期方向是在底层保留完整目录，用分层显示控制眼前的信息量。
V3 还会核对数据签名和哈希，并让一次浏览固定使用同一份快照。它的作用是检查文件是否与所发布的版本一致，避免新旧分片混用；技术校验不能证明一条音乐关系在历史上正确。
数据来源涉及 Wikidata、MusicBrainz 和 Discogs，许可需要按具体字段与快照核对。代码许可证也不会自动赋予封面、音频或所有上游数据的再分发权。
背景音乐同样有边界：音频文件不放进 Git 仓库，网站有播放与暂停控件；浏览器可能拒绝首次有声自动播放，需要用户手势后才能恢复。用户主动暂停后，其他页面操作不应把音乐重新打开。
06. 关系要能解释，也要允许不知道
这张图里最值得继续打磨的，是关系的解释。
“是子风格”“受过影响”“经常被共同标记”“只是一个待研究的关联”，不能合并成同一种线。即便两种风格经常出现在同一张唱片上，也不能只靠共同标签判断谁影响了谁。
我希望读者点开关系以后，能看清它的类型、方向、来源，以及资料还缺在哪里。没有资料时显示未知，有冲突时保留冲突。这个过程会比画线慢，但有必要。
目前的目录仍有覆盖和审阅边界。它适合用来找到下一步要听什么、读什么、查什么；遇到有争议的音乐史判断，仍然要回到来源。
07. 下一步：扩数据，也验证怎么读
沿着项目的数据与产品设计，下一轮主要方向：
7.1 扩展可追溯的数据覆盖
继续推进全量 Rock 目录的数据处理，在扩大风格、艺人和作品覆盖的同时，保留来源、身份、冲突和许可记录。全量发布还需要完成实际数据导入与完整性验收，不能把现有限定目录换个标签就算完成。
如果更大的目录超过当前静态托管限制，文档中预留了将数据独立放到对象存储的方向。这属于后续架构工作，还需要处理读取地址、跨域、缓存和回滚，目前不能写成已经具备的部署能力。
7.2 完善浏览与纠错
继续检查手机手势、低动效模式、文字可读性与加载失败恢复。用户指出名称、年代或关系问题时，能根据可核查来源修订，也要让更新后的资料与页面同步。
这几件事比继续增加视觉效果更影响使用：能否找到对象、能否看懂关系，以及资料不完整时是否仍能走下去。
7.3 视觉效果的持续打磨
当前小数据量访问情况下，视觉密度，配色等没有发现问题。但大规模全量数据（超过当前样本5个以上的数量级）上线后，渲染的性能、视觉密度、配色可分辨性等，都有待验证。
08. 欢迎从熟悉的乐队开始
如果你喜欢摇滚，可以先打开星图，找一个熟悉的风格或艺人，再顺着作品与关系走几步。
目前源码仓库为私有，普通读者可通过作者联系渠道反馈。纠错时附上对象名称、网页链接和可以核查的来源；体验反馈则告诉我，你从哪里开始，在哪一步找不到或看不懂。
有兴趣的开发者也可以通过GitHub联系，共同打磨产品。