从“弗一把”到“洛一把”：一个虚拟歌声小游戏的诞生与曲库重建

一切从一个猜人小游戏开始#

“洛一把”的最初灵感来自网络上流行的“弗一把”：系统随机选择一名《反恐精英》职业选手，玩家不断输入猜测，再根据国籍、年龄、战队等字段的匹配结果逐步缩小范围。

我很喜欢这种玩法。它没有复杂操作，核心乐趣来自“我知道这个对象，但能否根据有限线索把它找出来”。于是我开始思考：如果把猜测对象换成洛天依的歌曲，会不会也成立？

虚拟歌声作品天然具有适合比较的数据：曲名、STAFF、发布时间、演唱歌姬、使用声库、演唱会经历，以及歌曲所属的系列或企划。只要能建立一个结构稳定的曲库，就可以把这些字段转化为游戏线索。

项目最早因此被命名为“洛一把”。第一阶段的目标很简单：随机选择一首洛天依传说曲，玩家无限猜测，猜错后获得反馈，直到找到答案。

第一版数据范围：洛天依传说曲#

为了避免一开始就面对几千首作品，我把范围限定为“传说曲”，也就是播放量超过一百万的作品，同时纳入播放量超过一千万的神话曲。

最初设计的歌曲资料包括：

• 曲名；
• 作曲与作词；
• 使用声库；
• 原版发布时间；
• 独唱或合唱；
• 神话曲、生贺曲、演唱会曲目等特殊说明；
• 歌词提示；
• Bilibili 原视频地址。

这些字段看起来清晰，但真正开始采集后，很快就暴露出问题：不同页面的资料结构并不统一。

有的页面把创作者写成“UP主”，有的分别列出作曲、作词和编曲；有的页面顶部是原版信息，页面下方还收录其他歌姬翻唱、重制或二次创作版本。若只依靠简单关键词匹配，很容易把二创 STAFF、翻唱歌姬甚至搬运视频混入原版资料。

因此，原来的“作曲／作词”被重构为更宽容的 STAFF 字段，并限定只保留：

1
UP主：……；作曲：……；作词：……；编曲：……

UP 主优先展示，调校、混音、曲绘和 PV 等暂不作为猜歌字段。这个调整既提高了数据兼容性，也为后来按人员交集判断 STAFF 奠定了基础。

从萌娘百科开始的第一轮爬取#

第一版爬虫以萌娘百科的洛天依模板为入口，按年度寻找“原创曲”栏目下的传说曲和神话曲，再访问歌曲详情页补齐字段。

为了减少对网站的压力，程序在连续请求之间主动等待，并为失败请求设置重试和缓存。爬取过程中坚持几个原则：

1. 只收录原创歌曲；
2. 排除翻唱、翻填、重填词、二创和后续改编；
3. 只使用页面明确记载的信息；
4. 无法可靠判断时写入“待核验”，不根据印象补全；
5. 生贺曲只认官方生贺，同人作者为生日创作的歌曲不自动标记。

这套流程成功生成了第一批本地 Markdown 曲库，也让我第一次看到网站完整运行起来。但随着人工抽查深入，数据误差仍然不少。

典型问题包括：

• 原版和翻唱版的 STAFF 混在同一个页面；
• “演唱者：洛天依、乐正绫”没有被正确识别为合唱；
• ACE、VOCALOID 等引擎信息明明出现在简介中，却没有被提取；
• 歌词开头只有语气词，不能作为有效提示；
• 演唱会记录、生日会记录和宣传翻唱难以依靠单一关键词区分。

这些问题让我意识到：爬虫不能只负责“找到文字”，还需要理解页面中哪一块属于原版、哪一块只是衍生信息。

为什么后来迁移到 VCPedia#

之后我发现了 VCPedia。相比之前的数据源，它的年度模板和歌曲信息框更适合结构化采集。

以某位歌姬的年度模板为例，可以较清楚地定位：

1
歌姬年度歌曲
2
└─ 原创曲
3
   ├─ 神话曲
4
   └─ 传说曲

候选曲目确定后，详情页中的 Songbox、视频模板和正文简介又可以提供原版 STAFF、发布时间、演唱者、声库、歌词及视频地址。相比“在整个页面中搜索关键词”，这种结构可靠得多。

新的采集流程采用年度模板定位候选，再批量读取详情页源码；请求缓存保存在本地，使爬虫可以中断后继续，而不必反复访问相同页面。对于跨年份重复出现的作品，以最早原版为准；对于同一作品的重制版，也不把后续歌姬、声库或 STAFF 合并到原版。

迁移后，数据口径进一步明确：

• STAFF 只保留 UP 主、作曲、作词、编曲；
• 发布时间精确到 YYYY-MM；
• 演唱歌姬只记录歌声合成角色，不把真人合作歌手列入；
• 声库限定为 VOCALOID、ACE Studio、X Studio、Synthesizer V；
• 演唱会／生日会次数按明确记载的活动统计；
• 特殊标注允许生贺曲、拜年／贺岁纪曲目、系列／企划曲目或单曲；
• Bilibili 地址缺失不会阻止歌曲入库。

为什么没有让爬虫直接修改正式曲库#

经历第一版数据错误后，我决定在自动采集和正式网站之间增加一层人工审核。

新的流程变成：

1
年度模板与详情页
2
        ↓
3
规范化采集结果
4
        ↓
5
Excel 审核表
6
        ↓ 人工校对
7
正式 JSON 数据
8
        ↓
9
Markdown 与前端题库

Excel 审核表不仅保存歌曲资料，还增加“来源与核验”工作表，记录年度模板、歌曲页面、传说／神话等级、解析状态和待核验说明。自动程序擅长批量整理，人工则负责处理同名歌曲、页面歧义、演唱会统计和特殊标注。

正式发布后，每首歌曲同时存在三种形态：

1. 审核 Excel：适合人工检查、排序和批量修改；
2. 歌姬 JSON：作为数据库模块的正式数据源；
3. 十行 Markdown：便于阅读、版本对比和生成猜歌题库。

十行 Markdown 最终统一为：

1
曲名：……
2
staff：……
3
发布时间：YYYY-MM
4
演唱歌姬：……
5
使用声库：……
6
演唱会\生日会次数：……
7
特殊标注：……
8
歌词：……
9
哔哩哔哩地址：……
10
歌曲页面URL：……

多歌姬扩展与全局去重#

项目最初只有洛天依，后来陆续加入乐正绫、言和、乐正龙牙、徵羽摩柯、墨清弦、心华、星尘，以及五维介质系歌姬。

这时出现了一个必须解决的问题：合唱曲应该属于每一位参与演唱的歌姬，但在全曲库里又不能重复出现。

最终采用 VCPedia 页面 URL 作为作品的全局身份标识：

• 在单个歌姬数据库中，合唱曲可以同时出现；
• 在歌姬预设中，它对每位歌姬都算作一首；
• 在全曲库、猜歌和填字题库中，多份归属会合并为同一个作品；
• 共享歌曲数据不一致时，按照既定歌姬优先级统一事实字段。

这一规则让项目得以从一位歌姬扩展到十四位歌姬，同时保持全局题库稳定。目前合并去重后的曲库已经达到 496 首不同作品。

数据构建也需要自动测试#

数据量增加后，人工浏览所有文件已经不现实，因此构建脚本会主动检查：

• Markdown 是否严格十行；
• 日期是否符合 YYYY-MM；
• 演唱会次数是否为非负整数；
• 声库是否属于允许范围；
• Bilibili 和 VCPedia URL 是否合法；
• 曲名、ID 和页面地址是否重复；
• 每位歌姬的正式数量是否符合配置；
• 全局去重数量是否发生异常变化。

开发、测试和生产构建前都会重新生成题库。如果审核数据出现非法字段，构建会直接失败并指出具体记录，避免错误悄悄进入线上版本。

本阶段总结#

回头看，项目真正困难的部分并不是把表格显示在网页上，而是建立一套可以长期维护的数据流程。

从萌娘百科到 VCPedia，从直接生成 Markdown 到先输出 Excel 审核，再到 JSON、Markdown 和前端题库分层，数据结构经历了多次重写。但正是这些看似“游戏之外”的工作，让后续所有玩法可以共享同一套可信数据。

下一篇将进入真正的玩法实现：曲目猜猜看如何把数据库字段变成线索，以及曲名填字如何把六首歌名拼成一张可玩的交叉棋盘。

项目地址：https://github.com/LonakoBc/luo-yi-ba
在线试玩：https://luo-yi-ba.pages.dev/