【学习工作赛道】AI乐谱大师——乐谱数字化，AI评分一站式工具，音乐教育/学习之友

Meandro · 2026 年7 月 31 日 16:04

0. 初赛作品回顾

初赛贴链接：【学习工作赛道】AI乐谱大师——乐谱数字化，AI评分一站式工具；音乐教育/学习之友（TRAE官方论坛，搜索标题即可找到）

1. 关于我

大家好，我是Meandro（网名：菠萝的自我救赎，horfen也是系列自研模型「Horfen」的命名由来），一名深度沉浸在VibeCoding中的独立开发者。迷上VibeCoding之后基本戒掉了魔兽世界、流放之路这类网游，大部分空闲时间都花在开发上。

我做工具更习惯从使用者的实际痛点出发，而不是从技术炫技出发。这次开发「AI乐谱大师」，缘起于香港音乐老师YOBE的一次委托——沟通后我发现，无论是国内还是海外的音乐教育者与学习者，都遇到了类似的困扰：现有工具要么收费昂贵、要么技术陈旧、而且各平台之间封闭不通，而这个细分的专业需求，一直以来都缺乏比较趁手的工具支持。

开发过程中非常感谢YOBE老师提供的音乐专业指导，"AI + 专业人士"的快速反馈循环，是VibeCoding能把一个项目真正打磨可用的关键思路——边做、边用、边修正，效率和准确度都提升了很多。

我接触VibeCoding大约2年，此前主要做产品设计与需求文档工作。这次比赛让我第一次把一个项目从0到1完整地跑了出来，从初赛的Demo原型打磨成了复赛可以实际体验的完整作品，并完成了Demo域名的部署上线。项目的初衷很朴素：看到全球音乐创作者和学习者都有这个小众刚需，希望用技术帮大家省下重复劳动的时间，不再为了难用又昂贵的海外工具妥协。

目前主打西洋乐谱的识别与处理，民乐识别方向已完成初步的模型训练与技术储备，后续会持续优化并探索集成的可能性，希望能为更广泛的音乐群体提供帮助。

关于体验：当前为比赛Demo版本，未完成ICP备案，仅用于本次大赛评审使用；评审体验地址与账号已通过飞书问卷单独提交，其他朋友有兴趣了解欢迎后台私信交流。

2. 产品简介（复赛版）

是什么

AI乐谱大师（AI Scoring Master）是一个一站式乐谱数字化与音乐学习网页工具，学琴、做曲子全都能搞定。核心能把纸质乐谱转成电子档、音频扒谱、AI批改打分，也对中国民乐识别方向进行了技术储备。

有了它，老师上课更省心，孩子练琴知道自己错在哪，家长也能清清楚楚看到孩子的练习情况。

相比初赛简易试用版，复赛版本已演进为一个核心流程可跑通、已Demo域名上线可真实体验的作品。

面向谁

聚焦音乐教育与学习的核心场景，覆盖日常最有需求的几类音乐从业者与爱好者：

• 音乐教师：不想被市面陪练App固定曲目限制，自由使用自有教学教材与授课体系

• 琴童和学生：独自练琴无人纠错，缺少客观的弹奏对错反馈

• 学生家长：看不懂专业乐理，没法判断孩子练琴质量

• 作曲编曲人：需要高效完成日常扒谱、乐谱转换等重复工作

• 小乐团/学校乐团：预算有限，无力聘请专职编曲、助教

完整功能清单与用户路径

核心功能（4大模块 + 协同模式，民乐识别为技术储备）

乐谱转码（PDF → MusicXML）
- 支持钢琴谱、吉他谱、小提琴谱、长笛谱（其他类型乐谱OMR识别持续优化中）
- PDF标准化预处理管线（PDF类型自动检测/自适应DPI/歪斜校正/谱线增强/乐器差异化增强）
- 基于 Audiveris OMR 引擎 + HorfenScore 自研写谱规训后处理
- 逐页识别模式（复杂谱可选，每页独立输出不合并）
- 兼容老师自有教材，不限曲目

音频扒谱（MP3/WAV → MIDI）
- 单乐器扒谱：钢琴/鼓/BASS/小提琴对应自研 Horfen 专用模型，吉他/长笛使用 Basic Pitch 兜底（HorfenGuitar 架构已设计完成待训练）
- 乐队扒谱：6-stem Demucs 声源分离（drums/bass/piano/guitar/other/vocals），支持流行乐队和交响乐团
- 保留原始力度和表情信息，RMS动态力度映射
- 16分音符网格量化，以鼓为锚点多轨对齐
- HorfenDrums鼓点存在性检测（防止无鼓音频误识别）

LINK扒谱（在线链接 → MIDI）
- 支持 B站（bilibili.com / b23.tv）
- 粘贴链接一键分析内容并转 MIDI
- 说明：复赛版本基于功能稳定性考虑，暂时仅保留B站支持

AI演奏评分
- 六维度量化评分：音准、节奏、音色、力度、完整度、速度
- 小节级错误定位，可视化报告
- 基于 DTW 对齐算法（动态时间规整解决速度差异问题）
- 分乐器差异化评分配置（钢琴/吉他/小提琴/长笛独立标准，基于中央音乐学院/GB/T 44664-2024/伯克利标准）
- 力度对比面积图，直观展示强弱处理差异
- HTML报告导出，家长和老师一目了然
  
  音乐评分页面22549×1473 323 KB

协同模式
- PDF转谱 + 演奏评分联合分析
- 学生可跟着流动乐谱用相同拍子练习
- 支持音频 + MIDI 双格式上传（v3.16.0新增）
- 降低小乐团聘请助教合奏练习的成本

手机端响应式适配
- 768px 断点自适应布局，汉堡菜单 + 侧边栏抽屉
- 所有核心功能（转谱 / 扒谱 / 评分）在手机端均可正常使用
- 方便学生把手机放在琴边，边练琴边看练习结果

技术储备与未来方向

中国民乐识别（技术储备，尚未集成上线）
- 已完成基于 MERT-v1-330M 的民乐识别模型初步训练，覆盖219类中国民族乐器（二胡、琵琶、古筝、笛子、箫、扬琴、唢呐等）
- 当前处于模型验证阶段，数据集扩充、精度优化和产品集成仍在进行中
- 未来计划探索民乐谱（工尺谱、减字谱等）的OMR识别，填补民乐数字化领域的工具空白

工程化与安全能力

Demo域名上线：已完成自有Demo域名部署（腾讯轻量云内网穿透 + HTTPS加密，当前为比赛Demo版本，未完成ICP备案，仅用于本次大赛评审体验，体验地址已通过飞书问卷单独提交）
用户认证系统：JWT双Token机制（Access Token 15分钟 + Refresh Token 7天）+ bcrypt密码哈希 + SQLite，评审账号通过飞书问卷提交以保证体验流畅，其他有兴趣体验的朋友欢迎后台私信申请
网络安全加固：8个安全响应头（含CSP防XSS + HSTS强制HTTPS）+ 敏感页面保护 + 速率限制 + 文件类型校验
监控仪表盘：/monitor 页面，独立IP计数、访问者排名、路径分布、实时时间线、账户管理（解锁功能）
手机端响应式适配：768px断点，汉堡菜单 + 侧边栏，移动端可正常使用
启动脚本归一化：启动/文件夹统一管理 + SSH隧道守护进程（断开自动重连）+ Windows计划任务开机自启
日志轮转 + 自动清理：避免磁盘塞满
静态文件缓存控制：NoCache中间件，解决浏览器缓存旧JS问题

用户完整使用路径

老师场景：登录 → 上传PDF教材 → 转成MusicXML → 布置给学生 → 学生录制演奏 → AI评分 → 查看小节级错误报告
学生场景：听到喜欢的曲子 → 粘贴B站链接 → 一键转MIDI → 导入DAW练习
家长场景：登录 → 孩子上传练习录音 → 查看六维度评分报告 → 了解练习进度，消除与老师的沟通误解
乐团场景：PDF总谱转谱 → 分声部导出 → 各声部跟着流动乐谱独立练习 → 合奏时无需助教
民乐场景（未来）：民乐曲目乐器识别 → 民乐谱OMR数字化

相比初赛 Demo 的升级

初赛 Demo（v3.2.3）只证明了"创意可行"——跑通了 PDF 转谱、音频扒谱、AI 评分三条主链路。复赛版本（v3.18.0）把它打磨成了一个真正能用起来的作品，并完成Demo域名上线，关键升级包括：

维度	初赛 Demo (v3.2.3)	复赛成品 (v3.18.0)
版本迭代	20+版本	116+个commits，从v1.1到v3.18.0
PDF转谱性能	逐页串行，7页约9分钟	多页并行，实测加速6.76x（525s → 77.7s），CPU多核利用率7% → ~50%
部署状态	“无法部署到云端，仅提供演示视频”	已完成自有Demo域名上线（外网可访问，体验地址已通过飞书问卷单独提交评审）
用户系统	无认证，完全公开	JWT+SQLite认证系统，评审账号通过飞书问卷提交
自研模型	0个（全用开源）	4个Horfen系列专用模型已生产部署（Drums/Bass/Violin/Score-Piano）+ HorfenGuitar架构完成待训练
乐器识别	依赖MERT通用模型	四阶段递进训练管线 + 5个专用模型 + 民乐识别技术储备（初步模型已完成，尚未集成）
扒谱平台	B站为主	B站稳定支持，其他平台因功能稳定性暂未开放
协同模式	仅支持音频上传	音频 + MIDI双格式上传
评分维度	3-4维度	6维度（音准/节奏/音色/力度/完整度/速度）+ 分乐器标准
网络安全	无防护	8个安全响应头 + 敏感页面保护 + 速率限制 + 文件校验
监控运维	无	/monitor监控仪表盘 + SSH守护进程 + 日志轮转
手机端适配	未适配	完整响应式适配（768px断点）
工程化	脚本散落，手动启动	启动脚本归一化 + 守护进程 + 计划任务 + 静态文件缓存控制
前端安全	无防护	文件格式校验(大小/类型/文件头) + 防滥用封禁机制（测试期15分钟）
知识库	5篇文档	62篇文档（含8篇编曲实战、模型知识库、训练日志、ABRSM考级标准等）
代码规模	50+ Python模块，10+ Vue组件	129个Python模块 + 12个Vue组件 + 11个JS模块
Git仓库	30.6GB（历史包含模型权重）	23.88MB（清理历史，99.9%瘦身）

3. 产品演示视频

B站：视频BV号 BV13aNW6TEoL

功能演示版：https://www.bilibili.com/video/BV1RMGP6iE2V/?vd_source=33881fb3ce4b8736be43b475f2493be6

详细讲解版：https://www.bilibili.com/video/BV13aNW6TEoL/?vd_source=33881fb3ce4b8736be43b475f2493be6

horfendrums爵士鼓扒谱效果：https://www.bilibili.com/video/BV1CxG36METh/?vd_source=33881fb3ce4b8736be43b475f2493be6

4. 产品创作历程

灵感来源

音乐是人类的通用语言，但音乐学习却长期被高昂的成本和低效的工具所束缚。纸质乐谱难以数字化，音频扒谱依赖人工，练习反馈滞后且主观——这些问题困扰着无数音乐学习者和教育者。作为一位音乐爱好者，我一直在思考：AI技术已经发展到今天，为什么音乐学习还要停留在"手工作坊"时代？

从不同用户角度，痛点各不相同：

音乐老师：新一代老师已经用平板电脑上课，但乐谱还是要打印出来发给学生——这不是真正的数字化。市面陪练App曲目固定，会冲散老师自己经营多年的教学体系；学生课后练习情况无法追踪，和家长沟通学习进度经常产生误解。音乐扒谱要找编曲老师，不仅花时间、花钱，还很难找到可靠的。
学生家长：自己不懂乐理，没办法判断孩子练习是否正确；孩子口头说练熟了，实际节奏、音符错漏很多；和老师沟通学习进度经常出现误解。
学生本人：练琴枯燥，只能练老师指定的曲目；练习没有目标，不知道自己弹得好不好；想弹自己喜欢的歌，却找不到合适的乐谱。
小乐团/学校乐团：有资本的大型演出乐团可以请专业编曲老师扒谱，但小型学校乐团缺乏这样的资源。演出需要编曲扒谱，成本高、周期长，合奏练习还要聘请助教老师——很多小投入的乐团因此失去了表演机会。

我觉得音乐学习不应该是一件昂贵的事，也不应该被工具限制住可能性。请陪练老师一小时300块，普通家庭根本负担不起；手动打谱两小时才打两页，把大量时间浪费在重复劳动上；小乐团想演出，扒谱成本高、周期长——这些问题本不该存在。

OMR乐谱识别、音频转录、音乐理解这些AI技术现在都已经可用了，完全可以整合成一个完整的工具链。技术应该服务于人，而不是让人去迁就技术。

从Demo到成品的关键决策

决策一：从"用开源模型"到"自研Horfen模型系列"——做小而精的垂直专用模型

初赛 Demo 阶段，我全部依赖开源模型（Basic Pitch扒谱、CLaMP3对齐、Audiveris OMR）。但真实使用中发现一个行业共性问题：市面上的开源模型普遍追求"大而全"，一个模型想覆盖所有乐器、所有场景，结果事与愿违——通用模型在特定乐器上表现不稳定，比如鼓点识别漏击严重、小提琴连奏黏连、BASS低频丢失、钢琴MIDI左右手不分，精度难以满足真实教学和练习需求。

这让我下决心走"小而精"的路线——针对每个乐器单独训练轻量级专用模型，垂直深耕而不是贪大求全。实践证明这个方向是正确的，自研的 Horfen 系列模型在各自乐器上都有明显的精度提升：

HorfenDrums：基于 Groove MIDI Dataset，CNN+GRU 轻量模型，16th音符量化网格 + RMS动态力度映射 + 鼓点存在性前置检测（val_loss 从 0.114 降至 0.072），已生产部署
HorfenBass V5：真实摇滚数据训练，无滤波推理方案，解决低频丢失问题（F1=0.6418），已生产部署
HorfenViolin v5：连奏/颤音分离 + RMS力度映射 + SKIP_QUANTIZATION保留rubato自然timing，优化小提琴黏连问题（F1=0.7811，沙箱对比Basic Pitch提升+0.41），已生产部署（含Basic Pitch回退机制）
HorfenScore-Piano v7.5：写谱规训后处理，keep_head去冗余 + 和弦规训 + 声部分离（C4为界左右手拆分），F1=0.7591，基于 163,030 对训练数据（26,571个MIDI文件：ABRSM+PianoCoRe+Pub-Piano），已生产部署
HorfenGuitar：架构已设计完成（CNN+BiGRU+Self-Attention，~4.5M参数，61音高覆盖吉他全音域），待训练数据准备后训练部署

决策二：建立"四阶段训练管线"架构

随着模型越训练越多，我意识到需要一个清晰的架构来组织整个AI流程。于是总结出了四阶段管线：

原始音频 → ①音色识别 → ②实曲识别 → ③节奏与演奏优化 → ④写谱规训 → 输出乐谱

第一阶段（音色识别）：Demucs声源分离 + 乐器分类（NSynth预训练 → IRMAS+Medley微调 → CTIS中国乐器219类微调 → OpenMIC多标签 → URMP精细分类）
第二阶段（实曲识别）：各乐器专用Horfen模型推理，输出原始MIDI
第三阶段（节奏优化）：librosa beat_track检测BPM + 16th音符网格量化 + 以鼓为锚点多轨对齐 + TimeSignature元数据写入
第四阶段（写谱规训）：HorfenScore v7.5后处理，keep_head去冗余 + 和弦规训 + 声部分离（C4为界左右手拆分）

这个架构的关键洞察是：串行依赖，但每阶段可独立迭代。比如 HorfenViolin 从 v1 迭代到 v5，每版只动第二阶段，不影响其他阶段。

决策三：解决部署上线的现实障碍——从"无法部署"到"Demo域名上线"

重要说明：当前上线的是比赛Demo版本，第一，产品尚未最终完成产品化；第二，此次Demo展示仅用于TRAE创造力大赛参赛评审，不是正式对外发布的最终版本。

初赛时我说"无法部署到云端"，复赛我必须解决评委可直接体验的问题。作为个人开发者，面临的不是技术问题而是合规门槛——ICP备案、公安备案每一步都是门槛，短期内无法完成完整的商业化备案流程。

经过多轮方案迭代：

最初尝试 FRP 内网穿透 → 可行但无HTTPS、无自有域名
尝试网络适配方案 → 被安全软件误报为风险工具
最终采用 腾讯轻量云内网穿透 方案：绑定自有Demo域名到腾讯云轻量服务器，Nginx 反代 + HTTPS 证书加密，FRP 隧道直连本地服务，稳定可靠，无需本地公网IP
跨区域网络：通过云服务器优化国内外访问路由，保证内容稳定获取（部分海外平台后因接口政策调整暂时下线）

评审体验地址及账号已通过飞书问卷单独提交，其他朋友有兴趣体验欢迎后台私信申请。

决策四：用户认证与安全加固——从"裸奔"到"生产级安全"

项目公网部署后必须考虑安全问题，复赛阶段完成了完整的认证和安全体系：

JWT双Token认证：Access Token 15分钟 + Refresh Token 7天，bcrypt密码哈希（work factor=12）
8个安全响应头：CSP（Content-Security-Policy防XSS）+ HSTS（强制HTTPS）+ X-Content-Type-Options + X-Frame-Options + X-XSS-Protection + Referrer-Policy + Permissions-Policy + Cache-Control
敏感页面保护：/docs（Swagger）、/openapi.json、/monitor 需登录才能访问
多层防护：前端文件校验（大小/类型/文件头MThd检测）+ 后端速率限制（通用60次/分、上传10次/分）+ IP封禁机制
注册关闭：比赛Demo期间账号需申请，评审账号优先保证体验，防止滥用影响评审

额外思考：VibeCoding时代的AI知识产权保护

这也是我在开发过程中深有体会的一个痛点——VibeCoding极大降低了开发门槛，AI可以帮你写代码、调参数、训模型，但随之而来的问题是：AI生成的代码、AI辅助训练的模型，知识产权到底归谁？如何证明自研模型的原创性？如何避免训练数据的版权风险？这是当下所有AI原生项目都必须面对的问题。本项目从一开始就保留了完整的训练日志、数据来源记录、模型迭代轨迹，所有自研Horfen模型的训练过程都可溯源，为后续的软件著作权申请和知识产权保护打下基础。这部分在产品化阶段会进一步完善。

决策五：从"能演示"到"可稳定使用"——工程化打磨

初赛 Demo 允许有小瑕疵，复赛要求"经得起评审反复操作"。所以我做了几项稳定性打磨：

启动脚本归一化（启动/文件夹统一管理）+ SSH隧道守护进程（断开自动重连）+ Windows计划任务开机自启
日志轮转 + 清理机制，避免磁盘塞满
静态文件缓存控制（NoCache中间件），解决浏览器缓存旧JS导致更新不生效的问题
前端路由SPA回退处理（后端对非/api/路径返回index.html）
账户解锁功能：监控面板支持手动解锁被封禁账户
输出文件名跟随用户上传原始文件名，下载列表显示实际文件名

决策六：功能做减法——LINK扒谱平台缩减（部分平台暂时下线）

这是一个"反直觉"但重要的决策：复赛阶段我主动下线了部分海外和短视频平台的链接内容获取支持，仅保留B站。原因：

部分海外平台接口政策频繁调整，对接维护成本高且稳定性不足
短视频平台内容获取接口不稳定，多种兼容方案尝试后仍无法保证可用性
B站支持稳定可靠，国内访问速度快，满足核心使用场景
复赛评审需要的是"能稳定工作的功能"，而不是"看起来功能多但经常失败"

决策七：协同模式MIDI支持与手机端适配

根据初赛反馈，协同模式只支持音频上传限制了使用场景。复赛阶段增加了 MIDI 文件上传支持（后端文件校验新增MThd文件头检测），并完成了手机端响应式适配（768px断点，汉堡菜单+侧边栏），让老师和家长可以在手机上查看评分报告。

5. TRAE实践过程

整个项目从0到1全程使用 TRAE IDE 完成，涵盖后端Python模块、前端Vue 3界面、AI模型训练、部署运维、网络安全全链路。

开发流程

阶段一：需求分析与架构设计（6月12日-6月18日）

使用 TRAE 与 AI 助手讨论产品定位、功能模块划分、技术选型。AI 帮我梳理了7个Agent和10个Skill的架构体系，统一智能体根据用户意图自动切换工作模式。

阶段二：核心功能开发（6月18日-6月27日）

PDF转谱模块：集成 Audiveris OMR 引擎，优先优化钢琴谱、吉他谱、小提琴谱、长笛谱识别效果
音频扒谱模块：集成 Basic Pitch 模型，支持6种乐器模式
评分模块：基于 DTW 对齐算法，实现六维度评分
Web前后端：Vue 3 + FastAPI，统一任务协议，异步任务管理

阶段三：功能优化与测试（6月27日-7月6日）

协同模式上线：PDF转谱→渲染参考音频→音频比对评分
分乐器评分标准：钢琴/吉他/小提琴/长笛差异化评分配置
乐队扒谱体系：6-stem Demucs分离，支持流行乐队和交响乐团
PDF预处理管线：PDF类型自动检测（文字型/扫描型/混合型）+ 差异化渲染 + 谱线增强
CTIS民乐识别模型初步训练完成（219类，模型验证阶段，尚未集成上线）

阶段四：自研模型训练（7月6日-7月28日）

这是复赛阶段最核心的工作——从依赖开源模型转向自研Horfen系列。这里要特别赞美一下 TRAE 的 Goal 模式，它简直是为模型训练这种长周期、多步骤、需要反复试错的任务量身定制的：训练一个模型从数据准备、数据集划分、模型搭建、训练循环、验证评估、调参优化到最终部署，往往需要连续十几甚至几十个步骤，Goal 模式可以把整个训练目标拆成清晰的任务链，自动记住上下文和之前的训练结果，不会在中途丢失进度，还能根据训练loss曲线自动给出调参建议。没有 Goal 模式，我一个非算法背景的开发者根本不可能在短短三周内完成4个专用模型的训练和部署。

本阶段训练成果：

HorfenDrums：基于 Groove MIDI Dataset，CNN+GRU，16th音符量化 + 鼓点存在性检测，已生产部署
HorfenBass V5：真实摇滚数据训练，无滤波推理，F1=0.6418，已生产部署
HorfenViolin v5：连奏/颤音分离 + RMS力度映射 + rubato保留，F1=0.7811，已生产部署（含Basic Pitch回退）
HorfenScore-Piano v7.5：写谱规训，F1=0.7591，163,030对训练数据，已生产部署
HorfenGuitar：架构设计完成（~4.5M参数），待训练部署

阶段五：用户认证与Demo域名上线（7月22日-7月24日）

腾讯轻量云内网穿透配置，自有Demo域名上线（体验地址已通过飞书问卷单独提交评审）
JWT+SQLite用户认证系统（注册/登录/Token刷新/访问控制/退出）
网络安全加固（8个安全响应头 + 敏感页面保护）
手机端响应式适配
监控仪表盘（/monitor）

阶段六：工程化打磨与稳定性（7月24日-7月30日）

启动脚本归一化 + SSH隧道守护进程 + 计划任务
HorfenViolin v5集成 + HorfenScore v7.5生产部署
协同模式MIDI上传支持
前端封禁机制（测试期15分钟）+ 账户解锁功能
Git仓库瘦身（30.6GB → 23.88MB）
LINK扒谱平台缩减（仅保留B站）+ 静态文件缓存控制
版本号更新至v3.17.1

阶段七：PDF转谱并行加速与多用户并发安全（7月31日）

复赛提交前最后一项关键优化——把 PDF 转谱从"逐页串行"升级为"多页并行"，并补齐多用户并发安全：

Audiveris OMR 并行化：piano_pdf_to_musicxml.py、协同模式、转谱 Service 三处同步升级，每页独立 Java 进程并行识别，实测加速比 6.76x（525s → 77.7s），CPU 多核利用率从 7% 提升至 ~50%
多用户并发安全：输出文件名加入 task_id 防止多用户同标题覆盖；临时目录 UUID 化；全局信号量（Semaphore 4）限制同时进入 OMR 阶段的请求数，防止线程爆炸
版本号更新至 v3.18.0

关键任务Session ID

以下 Session ID 可在 TRAE 中核验开发过程（共提供17个，远超要求的3个，覆盖从初赛到复赛全流程）：

Web前后端骨架搭建：6a32e7096b4a083adddabd88（2026/6/18）
- 搭建 Vue 3 前端骨架 + FastAPI 后端三层架构
- 统一任务请求协议，异步任务管理
音频扒谱功能贯通：6a3781475eb2e3b494373ea5（2026/6/22）
- 实现 Basic Pitch 扒谱 + 和弦约束过滤
- 支持 B站链接内容一键分析转写
协同模式上线：6a3f5fa149324cb9ec5ca7e9（2026/6/27）
- PDF转谱→音频渲染→DTW比对评分
- 分乐器评分标准 + HTML报告导出
CTIS民乐识别模型训练集成：6a3acd7fcad7ff049f807d6f（2026/6/24-6/30）
- 219类中国民族乐器识别模型训练
- 推理模块集成到 instrument_recognition.py
HorfenDrums鼓点识别模型：6a58b0deb514e33379d437d8（2026/7/16-7/19）
- CNN+GRU模型训练 + 训推分离架构
- BPM检测/拍号支持/鼓点存在性检测/MIDI元数据写入
- 集成到乐队扒谱流程
用户认证系统与Demo域名上线：6a60e2ca5451f748ae32f7cc（2026/7/22-7/23）
- JWT+SQLite完整认证体系（注册/登录/刷新/退出）
- 腾讯轻量云内网穿透 + 自有Demo域名部署（体验地址已通过飞书问卷单独提交评审）
- 网络安全加固（8个响应头 + 敏感页面保护）
- 手机端响应式适配
启动脚本归一化与SSH守护进程：6a609b73ae86e82223089b5e（2026/7/24）
- 所有启动脚本归入启动/文件夹
- SSH隧道守护进程（断开自动重连）+ Windows计划任务
HorfenScore-Piano v7.5写谱规训部署：6a6881f3061ad6699c4a41b1（2026/7/26-7/28）
- 钢琴写谱规训后处理模型生产部署
- 动态MAX_NOTES + keep_only模式，F1=0.7591
网络安全加固P0/P1修复：6a6369ade4460c7bb10746e5（2026/7/24）
- 敏感页面保护（/docs /openapi.json /monitor需登录）
- CSP + HSTS安全响应头新增
协同模式MIDI上传与手机端适配：6a69c22f8711c7c1e3eb5f80（2026/7/29）
- 协同模式支持 MIDI 文件上传（MThd文件头校验）
- 前端响应式适配，移动端可用
- 前端安全封禁机制（测试期15分钟）
工程化打磨与Git瘦身：6a6a5135823452dc497a80de（2026/7/30）
- Git 仓库瘦身（30.6GB → 23.88MB，99.9%压缩率）
- 版本号同步 + dist重建
- LINK扒谱平台缩减（仅保留B站）+ 静态文件缓存控制

开发截图

共18张关键步骤截图，完整展示从架构设计到功能上线、模型训练、用户认证、部署运维、安全加固的全过程（见上方配图与「开发记录」目录）：

架构设计阶段：2张
核心功能开发：4张
优化测试：2张
模型训练：4张
用户认证与部署上线：6张

6. 技术方案分享

技术栈

后端：Python 3.10 + FastAPI + PyTorch + librosa + PyMuPDF(fitz) + lxml + python-jose(JWT) + bcrypt
前端：Vue 3 + Element Plus + ECharts + Pinia + Vue Router + Axios
AI模型：
- 4个自研Horfen模型已生产部署（Drums/Bass/Violin/Score-Piano），HorfenGuitar架构完成待训练
- 开源模型：Basic Pitch（吉他/长笛/钢琴兜底）、CLaMP3（音频对齐）、Audiveris（OMR）
- 基础模型：MERT-v1-330M（乐器特征提取/民乐识别）、Demucs htdemucs_6s（声源分离）
部署：腾讯轻量云内网穿透（HTTPS，自有Demo域名上线，未完成ICP备案，仅用于比赛评审体验，地址已通过飞书问卷单独提交）+ SSH加密通道（跨区域网络优化）
数据库：SQLite（WAL模式，线程安全）
运维：PowerShell启动脚本 + Windows计划任务 + 日志轮转 + NoCache静态文件中间件

项目规模

代码量：约6.2万行（Python后端5.1万行，含模型训练/推理/数据预处理脚本 + 前端1万行），129个Python模块 + 12个Vue组件 + 11个JS模块
知识库：62篇文档（含8篇编曲实战、模型知识库、训练日志、ABRSM考级标准、Riemann功能和声理论、MusicXML 4.0规范、前后端架构宪法等）
版本迭代：从v1.1到v3.18.0，共116+个commits、20+个版本
训练数据：
- HorfenScore-Piano：163,030对（26,571个MIDI文件，含ABRSM+PianoCoRe+Pub-Piano）
- 乐器识别：NSynth(289K) + IRMAS+Medley(195K) + CTIS(219类中国民乐，4,470样本) + OpenMIC(20K) + URMP(149文件)
- HorfenDrums：Groove MIDI Dataset + 231首Bilibili摇滚合集增量训练
用户系统：账号申请制，评审账号通过飞书问卷优先提交保证体验，JWT双Token机制
Git仓库：已瘦身至23.88MB（清理历史中的模型权重和音频文件，99.9%压缩率）

四阶段AI管线（核心架构）

这是整个项目最核心的技术架构，实现了从原始音频到规范乐谱的端到端处理：

原始音频/PDF
    ↓
① 音色识别与分离
   ├─ Demucs 6-stem声源分离（鼓/贝斯/其他/人声/钢琴/吉他弦乐）
   ├─ MERT-v1-330M特征提取
   └─ 逐阶段迁移分类器（NSynth→IRMAS+Medley→CTIS民乐219类→OpenMIC→URMP）
    ↓
② 实曲识别（各乐器专用模型 + 开源兜底）
   ├─ HorfenDrums（CNN+GRU，鼓点转录 + 存在性检测）
   ├─ HorfenBass（无滤波推理，低频保留，F1=0.6418）
   ├─ HorfenViolin（连奏/颤音分离，RMS力度，rubato保留，F1=0.7811）
   ├─ Basic Pitch（吉他/长笛/钢琴兜底，复音转录）
   └─ Audiveris（PDF→OMR识别，乐谱转码用）
    ↓
③ 节奏与演奏优化
   ├─ librosa beat_track检测BPM
   ├─ 16th音符网格量化（151ms精度@99BPM）
   ├─ 鼓为锚点多轨动态对齐
   ├─ TimeSignature(4/4)元数据写入
   └─ 力度动态映射（音频RMS能量→MIDI velocity 0-127）
    ↓
④ 写谱规训（HorfenScore-Piano v7.5）
   ├─ keep_head去冗余（同音高重叠保留ghost音符过滤）
   ├─ 和弦约束规训（Krumhansl调性分析）
   ├─ C4为界声部分离（右手高音谱表/左手低音谱表）
   └─ 乐理规则校验（调号/拍号/小节边界）
    ↓
输出：MusicXML / MIDI（可导入MuseScore、Sibelius、Dorico等打谱软件）

架构设计原则：

串行依赖，独立迭代：四个阶段按顺序执行，但每个阶段的模型/算法可以独立升级替换，不影响其他阶段
规则与学习结合：前两阶段用深度学习做感知，后两阶段用音乐理论规则做约束，兼顾准确率和可解释性
鼓为节奏锚点：鼓的节拍最稳定，以鼓的量化结果为基准对齐其他乐器，解决多轨对齐问题
PDF预处理全乐器通用：PDF类型检测+差异化渲染+自适应DPI，钢琴/吉他/小提琴/长笛共用一套管线，未来可扩展支持其他乐器类型

7. 社会价值与商业化方向

社会价值（教育公平）

降低学习门槛：一方面让请不起陪练老师的家庭（300元/小时）也能获得AI客观反馈，让不会打谱的人也能数字化乐谱；另一方面也服务于广大音乐自学爱好者——很多人学琴没有老师指导，不知道自己弹得对不对、哪里需要改进，AI客观的评分和小节级错误定位能给自学者提供方向，让没有专业老师的情况下也能获得不错的练习反馈
保留教学自主权，打破平台封闭：不像市面陪练App只有固定曲目库、老师必须被绑定在平台体系内，我们支持老师导入自己的教材和PDF乐谱，转码输出的MusicXML是国际通用标准格式，可在MuseScore、Sibelius、Dorico等任意打谱软件中打开编辑，真正做到"我的乐谱我做主"，不被任何平台绑架教学体系、不被封闭生态锁住内容
显著提升音乐教育效率：传统模式下老师要花大量时间手动打谱、逐小节批改作业、口头描述练习问题；PDF转谱与音频扒谱几分钟就能完成原本需要花几小时的打谱初稿工作，后续可在打谱软件中再做人工检查与微调；六维度评分与小节级错误定位让学生练习后立刻获得客观反馈，大幅降低音乐教学的时间成本，老师同样的时间可以带更多学生，学生同样的练习时间能获得更精准的指导
小乐团公平机会：转谱本身很多时候就是着急的事——演出前临时改谱、比赛前扒声部、排练临时调整编曲，但市面很多转谱平台要么收取高昂费用，要么效果就像开盲盒——不少平台只是套个皮，底层用的是很老的技术，结果一脚一个坑，耽误演出和排练。我们让缺乏资本的学生乐团、学校乐团也能获得专业级的扒谱和合奏练习工具，不再因资源匮乏和技术不透明而失去演出机会
民乐数字化填补民族音乐技术空白：现有音乐软件和AI模型体系基本由西方开发者主导，围绕钢琴、小提琴、吉他等西方乐器构建，对二胡、古筝、琵琶、笛子、唢呐等中国民族乐器关注甚少，导致民乐数字化长期缺乏趁手的工具支持。这件事还是要靠我们国人自己来做——项目已完成219类中国民族乐器识别模型的初步训练，未来计划继续优化模型精度并探索民乐谱（工尺谱、减字谱等）的OMR识别，为民族音乐的数字化传承和教育贡献一份力量

商业化方向（可持续发展的初步思路，具体定价与范围后续根据实际使用情况灵活调整）

C端用户模式（待探索）：初步考虑基础功能保持可用，对使用量大或更深度的功能可以按需提供更高阶的服务，具体哪些功能免费、哪些功能提供高级化服务将根据用户反馈和使用数据再做决定
B端教育机构合作：音乐教育机构定制化的可能性，提供教师后台、作业管理、学生进度追踪等能力
垂直模型能力开放：Horfen 系列专用模型可以考虑以API方式开放，供音乐教育类App、智能硬件厂商接入，支持根据接入方用户数据实现个性化定制（比如针对特定乐器教学法优化评分标准）
内容生态共建：用户转谱生成的乐谱内容，未来可以考虑构建乐谱分享与流转的社区机制，让优质内容的创作者也能分享到价值

8. 产品迭代规划

实事求是地说，当前版本还是一个比赛Demo，距离真正成熟的产品还有不少差距。以下是我在开发和实际使用过程中梳理的瓶颈和下一步改进方向：

当前产品层面的瓶颈

乐器覆盖不均衡：钢琴谱转谱在清晰排版的标准乐谱上效果相对成熟，但吉他、小提琴、长笛、BASS等其他乐器的扒谱和转谱效果还有明显提升空间，吉他模型架构已设计完成待训练
部署承载能力有限：当前是本地电脑+内网穿透的Demo方案，受限于个人电脑算力和网络带宽，暂时只能支持单次文件处理，不支持批量操作，也无法保证7×24小时稳定服务
内容获取渠道单一：链接扒谱目前只稳定支持B站，其他平台因接口稳定性问题暂时下线，用户如果想扒其他平台的内容需要先本地获取再上传
民乐功能尚未集成：仅完成219类中国民族乐器音频识别模型的初步训练，尚未集成到产品中，民乐谱（工尺谱、减字谱等）的OMR识别和转谱还处于早期探索阶段
产品化合规未完成：尚未完成ICP备案、软件著作权等合规流程，当前只是参赛Demo，不是正式对外发布的产品

下一步改进方向

补全乐器矩阵：完成HorfenGuitar吉他模型训练，并持续迭代BASS、小提琴模型，逐步缩小与钢琴效果的差距
民乐深化：扩大民乐识别训练数据集，优化泛化能力，并探索民乐谱的识别转谱工作，填补这一领域的工具空白
内容获取体验优化：探索更稳定的多平台内容对接方案，或引导用户本地获取后上传，降低使用门槛
教学闭环功能：支持教师远程布置作业、查看学生练习报告、在线批注，形成"教-学-练-评"完整闭环
云端部署升级：待产品成熟度和合规流程完成后，迁移至云服务器部署，支持7×24小时稳定服务和批量处理能力
实时扒谱探索：从离线处理逐步探索实时流式扒谱能力，可用于现场演出辅助和即兴练习场景
AI知识产权保护：VibeCoding时代AI生成代码和模型的知识产权归属是行业痛点，项目将完善代码和模型训练数据的溯源、确权机制，保护自研成果

9. TRAE VibeCoding 项目开发经验分享

在这次比赛的交流群里，看到不少朋友在VibeCoding开发项目的过程中遇到了挑战——比如功能迭代中不小心破坏了之前正常的逻辑、项目规模大了之后回退困难、修复一个问题可能引入新的问题、最终版本需要反复调试才能稳定运行。作为一个代码基础并不深厚、深度沉浸在VibeCoding中的开发者，我用TRAE从零到一完成了这个项目，过程中也踩了很多坑、走了不少弯路。这里把我自己总结出来的一些驾驭AI开发项目的心得体会分享出来，供同样在做VibeCoding的朋友们参考交流。

核心感悟：AI是能力超强的协作伙伴，开发者需要做好"领航员"的角色，明确方向、划定边界、做好校验。

经验一：给AI立"宪法"——项目规则先行

小项目可以想到哪写到哪，但代码量超过1万行、涉及多个模块后，AI每次对话都会"失忆"，经常做出违背你之前设定的决策。我的解决方案是建立项目规则文件project_rules.md，把所有"必须遵守"的原则写下来，让AI每次新对话开始时先读规则。

我们项目的"宪法"里包括：

沙箱测试原则：任何参数调整、算法改进先在temp/scripts/沙箱里验证，不直接修改生产代码——这一条帮我避免了很多不必要的问题
业务独立性原则：处理新PDF时不复用之前PDF的状态（比如页数），必须冷启动检测——这是实际使用中踩过坑之后总结的
文件操作安全闭环：任何移动/复制/删除操作，遵循"操作→验证→确认"三步流程，关键数据先移到临时目录确认无误后再清理
代码头部注释规范：每个新建Python文件包含结构化头部注释（文件用途、输入输出、依赖、更新说明）

规则不是一开始就完美的，而是每踩一次坑就往宪法里补充一条。到复赛结束时，我们的项目规则已经积累了几十条强制执行的原则，AI协作的顺畅度提升了很多。

经验二：建立专业知识库——别让AI在专业领域"瞎编"

做音乐类这种有强专业壁垒的项目，有一个深刻体会：AI写代码能力很强，但它在专业领域的知识经常是错的或者过时的。比如一开始让AI写MuseScore导出逻辑，它写出的MusicXML连谱号、调号位置都不对；让它写评分算法，它根本不知道ABRSM英皇考级的评分维度是什么。

我的解决方案是给项目建立分层知识库，放在docs/目录下：

knowledge/：乐理知识体系，包括基础乐理、调性调式、和弦体系、和声曲式、编曲配器、各乐器演奏技巧、视唱练耳等9大模块几十份文档
rules/：业务规则，包括乐理约束、和声规则、MuseScore4导出规范、ABRSM/国内GB/T评分标准
technical/：技术参考，包括OMR技术文档、模型架构知识、数据集说明等

每次开发涉及专业领域的功能（比如PDF转谱、AI评分、MIDI导出），先让AI读知识库中对应的文档再开始写代码。这样做的效果非常明显——代码里的专业错误大幅减少，不用反复让YOBE老师听音校对基础错误了。

AI的通用知识是"常识"，但专业项目需要"专业知识"。你不喂给它正确的专业资料，它就只能靠"猜"来写代码，结果自然不靠谱。

经验三：用"分层架构"给AI画好边界——Agent/Skill/Rules三层体系

如果在一个对话里让AI同时处理前端、后端、模型训练等多种任务，容易出现上下文混乱、不同模块逻辑互相影响的情况。我在项目里探索建立了三层分工体系：

层级	作用	类比
Rules（规则层）	全局强制执行的铁律，不能违反	公司规章制度
Skills（技能层）	封装好的单功能能力模块，比如PDF预处理、音频扒谱、评分引擎，每个Skill只干一件事	专业岗位员工
Agents（智能体层）	根据用户意图调度不同Skill，负责流程编排	部门经理

这样做的好处是：改评分逻辑只动评分Skill，不会影响PDF转谱；训模型只在训练Agent的会话里搞，不会污染生产代码。AI的能力边界越清晰，它犯错误的影响范围就越小。

经验四：自研Harness做流程兜底——关键开发环节要把主导权握在自己手里

TRAE的Solo Agent已经迭代得很强了，常规开发任务交给它自动推进效率很高。但做过几个复杂功能后我发现，AI自动推进的思考流程未必完全符合开发者的想法——它可能会跳过你觉得必要的校验步骤、选择你不认可的实现方案、或者在关键决策点上"自作主张"。对于一些重点功能开发，完全放任AI自由发挥风险比较高。

我的解决方案是在.trae/agents/目录下为核心业务模块定义自研Agent（也就是Harness），比如：

score-converter（乐谱转码专家）：明确定义PDF转谱的两种模式（完整转换/轻量识别）、调用哪些Skill、输出校验标准
scoring-master（评分专家）：固定评分流程，强制按照乐理校验→音高对比→节奏对比→维度打分的顺序执行
instrument-trainer（乐器训练专家）：模型训练的标准流程，数据准备→数据集划分→训练→验证→部署，每步都有明确的验收标准

这些自研Harness相当于给AI"画了施工图纸"，把关键流程、校验节点、输出标准都提前定义好，Solo Agent在这个框架内执行就不会"跑偏"。日常简单任务直接用默认模式效率高，重点功能或容易出问题的环节就切换到自研Harness兜底，两者结合既保证效率又保证质量。

AI能力很强，但关键流程的主导权要握在自己手里。你给它的框架越清晰，它交付的结果就越符合预期。

经验五：沙箱隔离——生产代码上的调试需谨慎

这是我踩过比较大的坑之后总结出来的原则。前期为了图快，直接让AI在源文件上调参数，结果有一次改PDF预处理的DPI参数，导致历史乐谱识别结果出现异常，回滚花了不少时间。

后来我定下铁律：

所有实验性修改先写独立沙箱脚本放temp/scripts/
沙箱脚本用3组不同类型数据测试（简单/中等/复杂）
测试结果用表格对比改进前后效果
确认没问题了，才让AI把改动合并到生产代码

我自己前期也走过直接在生产代码上调参的弯路，有了沙箱机制之后，改坏生产代码的情况就很少发生了。沙箱虽然多花几分钟，但能帮你省下大量回滚的时间。

经验六：Git管理——每完成一个功能就commit，别攒大提交

在项目初期我也有过"攒了一大堆改动才提交"的经历，后来发现这样一旦出问题想回退非常麻烦。后来我坚持的做法是：

每个小功能完成就commit，commit message用Conventional Commits规范（feat/fix/docs/refactor前缀）
大的功能开发前先开分支，验证没问题再合并
模型训练数据和权重不进Git（.gitignore配置好），仓库从30.6GB瘦到23.88MB
重要节点打tag，比如v3.10.0域名上线、v3.18.0复赛提交版

AI写代码很快，但你给它的指令不一定准确，频繁的小commit给你留足了"后悔药"。

经验七：Goal模式做长周期任务——模型训练的神器

之前说过TRAE的Goal模式特别适合模型训练这种需要十几步、反复试错的长周期任务。其实不只模型训练，任何需要多步骤、有明确验收标准的任务（比如部署上线、做用户认证系统）都适合用Goal模式：

Goal模式会把大目标拆成清晰的todo列表
自动记住之前的上下文，不会对话长了就丢进度
每完成一步会自动校验，失败了会重试或调整方案
训练模型时能监控loss曲线，自动给出调参建议

用Goal模式，你只需要在一开始说清楚"我要什么"，中间不用反复提醒AI之前做了什么，体验比普通对话流畅太多。

经验八：专业人士反馈闭环——AI不懂业务，你得找个"质检员"

AI能写代码，但它不懂音乐教学的真实需求，不懂五线谱的乐理规则。我非常幸运有香港音乐老师YOBE作为专业顾问，形成了"AI搭建→我从用户视角过一遍→YOBE老师从音乐专业角度提问题→我反馈给AI修改"的闭环。

比如小提琴连奏黏连的问题，是YOBE老师实际听出来的；评分体系的维度设置，是参考了ABRSM英皇考级标准和国内GB/T标准；PDF转谱的谱线间距要求，是实际打印对比后才确定20像素这个参数。

AI是强大的实现工具，但它自己很难判断什么是"对的产品"——必须引入真实用户和专业人士的反馈，不然做出来的东西可能只是"技术上能跑"，却难以真正满足实际场景的需求。

经验九：实事求是承认不足——Demo就是Demo，坦诚面对现状

最后一点也是我自己的感悟：VibeCoding做项目很容易让人觉得AI无所不能，什么功能都想加，结果反而什么都没做到位。这次我主动做了减法：

链接扒谱主动下线暂时不稳定的平台，只保留B站支持
明确说明批量处理暂不支持，等云端部署后再实现
开宗明义说明"这是比赛Demo，不是最终产品，还有很多不足"
产品迭代章节老老实实列出当前瓶颈，不回避问题

做产品和做人一样，坦诚面对不足实事求是很重要。哪些功能稳定可用、哪些还在改进，如实说明就好。

10. 致谢

感谢 TRAE 提供的 VibeCoding 平台，让我能够独立完成从0到1的产品开发、模型训练、部署上线的完整链路。感谢香港音乐老师 YOBE 的专业指导，"AI+专业人士"的协作模式让产品真正贴合音乐教育场景的真实需求。

感谢初赛阶段各位评审的认可，让我有机会把 Demo 继续打磨成完整作品并完成Demo域名上线供评审体验。复赛阶段我会继续优化，争取做出一个真正能帮到音乐学习者和教育者的工具。

DuBaDu · 2026 年7 月 31 日 23:37

难度超大且非常有意义的工作，是所有音乐数字化的基础，祝早日上线

Meandro · 2026 年8 月 1 日 00:20

谢谢，你也加油。

是，感觉一个人真干不完