“做一个音乐网站”不是需求，最多算一个方向。我们把它收敛成一个可运行的目标：输入风格、调式、拍号和速度，生成一段可编辑的 ABC 乐谱，实时渲染、试听并保存。
先拆问题，再选技术
需求被拆成三条链：生成、验证、保存。生成负责产出旋律；验证负责阻止非法乐谱进入渲染器；保存负责让作品脱离一次性演示。这样拆的好处是，每个模块都有明确验收结果，而不是做完一个漂亮但不可维护的页面。
为什么选择 FastAPI + React + ABC
后端使用 FastAPI，便于快速提供接口并复用 Python 音乐处理生态；前端使用 React，把输入区、乐谱预览、播放器和作品列表拆成独立状态；乐谱使用 ABC Notation，因为它是可读写文本，适合“生成 → 校验 → 渲染”的流水线，abcjs 再把文本变成可视化乐谱。
实施步骤
- 先做 composer：确定风格、调式、拍号、速度等参数能够生成 ABC 片段。
- 再做 abc_tools：校验格式和音符范围，失败时返回可定位的错误。
- 接入 SQLite：以单机 NAS 部署为前提保存作品，避免无必要的数据库复杂度。
- 最后接前端：输入、预览、试听和保存形成闭环。
- 统一部署：前端构建产物由 FastAPI 托管，尽量保持单进程、一条启动命令。
当前进度
网页应用的生成、ABC 渲染、试听和保存链路已经跑通，公网访问入口也已部署在 NAS。当前 AI 生成仍以规则模板为主，还没有接入真正的大模型；音色、MIDI/音频导出和作品分享也需要继续补齐。
为什么暂时不急着接大模型
如果格式校验、错误提示和保存链路还不稳定，接入大模型只会把随机性放大。下一步先把输入约束、非法乐谱恢复和导出协议固定，再接模型，才能判断问题来自模型还是应用本身。
评论