1. 项目复盘：2年前那款产品到底死在哪
1.1 最初的产品形态：一个过于硬核的网页音序器
两年前我关掉了一个自己花了大半年业余时间做的项目，名字叫“纸面乐队”——听起来挺浪漫，本质却是一个非常硬核的网页版音乐工作站。它做的事情是把传统的DAW（数字音频工作站）简化后搬到浏览器里，用户可以在网页上添加音轨、摆放音符、调整力度和时值，然后点击播放听效果。我当时的技术选型非常“自嗨”：主界面是一张无限滚动的钢琴卷帘窗，播放头会跟着节拍移动，还做了MIDI键盘映射。我沉迷于把钢琴卷帘做得顺滑流畅，甚至给每个音符设计了圆角拖拽动画。
那段时间我几乎每天都在优化渲染性能，确保即便在一个中等复杂度的曲子里，拖拽音符也不会有任何掉帧。这套东西放出来之后，确实吸引了不少人注册。毕竟“在浏览器里做音乐”在当时也算是个新奇概念，甚至有人跑到我评论区问“这东西和GarageBand有什么区别”。但问题恰恰就藏在这些反馈里：真正来试的人，十个有八个不知道琴键上那些格子代表什么音，不知道C调是什么意思，更别提把脑子里的一段旋律翻译成卷帘窗里密密麻麻的高低音柱。
1.2 数据说真话：四千用户和四十个深度用户
我在决定关停项目之前，认真拉过后台数据。注册用户累计四千多，放在整个互联网里当然算不上什么，但对一个个人项目来说也不算零。可是当我进一步看行为数据时，冷汗就下来了：能在编辑器页面停留超过十分钟的用户，不到四十个。这四十个人里面，又有大半是自己会弹琴、会编曲的。也就是说，这个产品看似面向所有人，实际上只服务到了那批原本就不需要它的人——专业音乐人用不上这种简化版，普通人又用不动它。
更扎心的是留存曲线。第三周留存掉到了百分之二附近，几乎可以判定这个项目没有成长性了。我当时在复盘文档里写了一句：“我们做了一个需要用户先学三个月乐理才能顺手使用的工具，然后把所有不学的人都当成了流失用户。”这句话后来成了我重新启动这个项目时的第一条警句。搞清楚谁在用、谁用了留不下、为什么留不下，比做什么功能重要得多。这一点，我觉得也是很多失败项目最典型的死法：不是方向错了，是产品在“可用”和“可用起来”之间隔了一道太陡的台阶。
1.3 失败原因拆解：门槛不是用户的问题，是产品的问题
两年前的我把“用户不懂乐理”当作教育成本，理所当然地认为“你不会可以先学嘛”。现在回头看，这个念头傲慢得离谱。普通用户想要的是“我有个想法，马上就能听到结果”，而不是“我先学钢琴卷帘窗，再去理解音符时值”。音乐创作工具的终极竞争点，从来不是功能多完整、音质多细腻，而是用户在五秒内能不能获得正反馈。
为什么这么说？因为音乐创作和写文档完全不同。文档写错字，用户可以自己改；但音乐创作里，一个普通人连“下一个音符应该放在哪个位置”都不知道。如果工具不帮他迈出这一步，他连犯错的机会都没有。所以这轮复活，我给自己定了三条非常明确的产品底线：第一，用户不需要输入任何音符；第二，用户不需要理解任何乐理概念；第三，用户第一次打开页面，六十秒内必须听到一段能让自己满意的成品。
这三条底线全部指向同一个答案——AI生成。只有把“音符输入”这件事从用户端拿掉，换成自然语言描述、情绪标签、节奏拍击这些人类天生就会的表达方式，这个项目才能真正面向“零音乐基础”的人。于是今年年初，我把它重新捡了回来，名字也改了，叫“露台音乐棚”。别笑，这个名字起得很随意，但理念反而清晰了：在浏览器里，像在自家露台上喝咖啡一样随便地做音乐。
2. 为什么AI成了复活这个项目的关键钥匙
2.1 AI让“创作音乐”从技能变成了提示
在AI没有成熟的年代，计算机做音乐生成主要靠规则算法：程序里写死音阶、和弦进程、常见终止式，再用随机数挑挑拣拣。这种方案最大的问题是产出的东西“听上去像那么回事，但不动人”。规则算法缺乏对“情绪”的理解，它不知道“清晨阳光”和“深夜雨巷”有什么本质区别，它只会按规定走流程。而现在的生成式模型不一样，它是在大量真实音乐数据上训练出来的，对风格、情绪、配器这些高层特征有隐性的把握。你给它一句“慵懒的周日下午，微风，木吉他”，它能在音色、节奏型和和声色彩上做出符合联想的判断。
对我这类不打算训练大模型的小团队来说，AI真正带来的不是“更聪明”，而是“更低的使用门槛传导到了产品里”。以前我要教育用户“什么是A大调”，现在用户只需要告诉我“我想要开心的、跳跃的、像走在撒满阳光的小路上”。这句话不用学，任何五岁小孩都说得出。所以这轮改造，我优先选择的不是“效果最惊艳的生成模型”，而是“对用户语言理解最宽容的模型方案”。
2.2 技术选型：自研算法还是开源生成模型
这里必须说清楚一件事：即使是现在，想在浏览器里跑高质量的完整音乐生成，也不是开箱即用。音乐生成涉及的操作很复杂：要生成旋律、生成和声、安排鼓组、再合成波形，每一步都吃算力。微软当年也有开源过很小的音乐生成模型，效果只能说勉强及格；Google Magenta那一套老牌开源项目主要偏向MIDI生成而非音频波形，输出的是音符和节奏序列，适合再搭配合成器播放。
我在实际选型时做了折中：底层波形合成完全自研，放在浏览器里用Web Audio API现做；旋律和和弦结构用开源模型或规则混合方案生成；节奏部分则预留了几套基于神经网络和规则算法的鼓点生成器。为什么不全用端到端的大模型？一个是模型体积问题。浏览器上跑一个百MB的音频模型，加载时间可以直接劝退用户。另一个是可控性问题。纯端到端生成类似于抽盲盒，用户想要“轻快的、带点电子元素的”，它给了一段宏大的史诗配乐，这种结果很容易让人产生“算了”的念头。所以我把AI放在用户和最终音频之间，把它当作一个“解释器和翻译器”，而不是完全的黑盒。
2.3 浏览器作为唯一载体的三个理由
这轮复活我坚持只做网页，不做App。理由有三点，都很现实：第一，免安装。用户从第一次听到产品到真正打开它，中间不需要经历“搜应用商店—下载—安装—注册”这条长链路。我在失败项目里做过统计，从分享链接到首次体验的转化率，网页版大概是App版的七八倍。第二，跨设备同步特别简单。电脑上写一半，手机接着改，只要浏览器能打开就行。第三，AI推理时代，浏览器端能跑模型这件事越来越成熟，WebAssembly和WebGPU让中小型模型可以在用户本地跑，不用自建昂贵的推理服务器，也能保护用户的输入数据。
从这个角度看，浏览器不是载体，而是这个项目重新活过来的最低成本基础设施。尤其当我用Transformers.js把开源模型转成ONNX格式后，加载、推理都是局部资源的事，几秒钟出结果，服务器压力几乎为零，也自然没有带宽账单爆发的问题。这在这个项目早期是完全不可指望的，但2024年下半年之后，这套技术栈已经稳定得可以支持真实产品了。
3. 产品设计：让零基础用户能直接上手的核心逻辑
3.1 输入：从“写音符”到“说想法”
如果让我说这个新版产品最重要的变化，我会把输入方式的变化排在第一。旧版里，用户必须通过钢琴卷帘窗输入音符，操作对象是“音高”和“时值”，这俩概念每一个都需要对应到具体的认知：音高靠耳朵、时值靠乐感。新版里我把输入方式分成了三类，第一类是文字描述，比如“一段轻快的小提琴旋律，适合周末早晨”；第二类是情绪卡片，用户直接选“开心、悲伤、紧张、放松”这样的形容词；第三类是节奏敲击，用户可以用麦克风哼一段节奏，也可以随身拍空格键打出自己想要的鼓点节奏。
节奏敲击这条尤其有意思。人类天生对节奏敏感，没有受过训练的人也能用手掌在桌面上拍出一段有规律的“动次打次”。这个能力不需要乐理知识。所以我做了一个“节拍捕捉”的输入层，用户拍完空格后，系统会先对拍点做动态时间规整，将其转换成结构化的节奏模板，再用AI在这个节奏骨架上补全贝斯线和和弦。整体体验是：用户负责表达“感觉”，系统负责行使“技术”。
3.2 输出：从“五线谱”到“可听的即时结果”
新版里，界面里不再有默认摊开的钢琴卷帘窗，所有界面元素都围绕“播放”这个动作来设计。用户完成输入之后，页面中央会立刻出现一个播放按钮，旁边是几个文件风格标签，比如“吉他弹唱”、“电子舞曲”、“钢琴独奏”、“Lo-Fi”。用户点播放，立刻就能听到AI结合他的输入生成的完整曲子。整个过程最快不到十秒。
为什么我认为这一步是关键？因为音乐工具的即时反馈决定了用户是否会继续尝试。一个五岁的小孩玩游戏能玩很久，是因为每一次按键都有画面和声音反馈；同样的道理适用于音乐创作工具。如果用户输入了一句话，等了十几秒没结果，他会觉得“它还在加载”；如果三十秒还没结果，他就关掉了。所以我坚持把“生成”做成一个渐进式的播放过程：先出旋律骨架，同时预加载鼓点和贝斯，播放头慢慢跑起来，给用户一种“它真的在创作”的知觉体验。这个细节不是单纯为了好看，而是为了在播放过程中把用户的期待情绪用电平条和音高走向可视化地兜住。
3.3 可控性：AI生成也可以不是开盲盒
很多做AI生成产品的团队会陷入一个误区：把生成结果直接交给用户，然后告诉用户“不满意就再点一次”。这本质上是一种甩锅。用户面对连续随机的输出，很容易产生“机器无法理解我”的挫败感。我的做法是给用户提供几个轻量级的“微调旋钮”，包括“节奏疏密”（一条滑杆，往左更空灵，往右更密集）、“和声明暗”（往左偏小调忧伤，往右偏大调明亮）和“配器丰富度”（从极简到繁复）。这三个参数会在生成时作为条件反馈给模型，而不是在生成完成后做打伞。
这里我想也讲讲为什么不用传统调音台上的“电子合成器、压缩器、EQ”那些专业参数。原因很简单：零基础用户对着“EQ”两个字只会焦虑，但对着“往左更暗，往右更亮”却能秒懂。我们把专业领域里“调音色”这件事，翻译成带有空间比喻的交互语言，让用户觉得AI是在回应他，而不是AI在演示他。这种体验上的接近感，是留住普通用户的关键。
4. 技术实现：AI音乐生成塞进浏览器的一次走通
4.1 整体架构：模型推理、音频渲染和前端交互的分工
整个新版“露台音乐棚”的前端架构并不复杂，但分层很干脆。第一层是交互层，也就是用户看到的那些按钮、文字框、滑杆；第二层是生成调度层，它负责接收输入，把输入转换成模型可读的条件张量，并调用底层推理引擎；第三层是音符序列层，负责将模型输出的旋律和和弦序列转换成结构化的事件表；最后一层是音频渲染层，基于Web Audio API实时合成PCM波形并播放。
这里的核心思路是：模型不直接输出音频文件，而是先输出MIDI级别的符号信息，再由本地合成引擎渲染。这样做的最大好处是，模型体积小、推理速度快，而且输出结果可以被用户微调——比如用户把“阳光感”滑杆往右拖，实际上是改变了第三层的和声色彩映射，而不是重新跑一遍模型。我用的模型是几个公开开源小模型的组合：旋律生成用了一个小型Transformer架构的模型，和弦进行和贝斯线则用了规则算法和对比选择生成。整体模型转成ONNX格式后大约35MB，在普通PC上推理时间稳定在300到700毫秒。
4.2 从文字到旋律的生成链路
现在拆一下最核心的流程：用户的自然语言是什么变成旋律的。先说大方向，这里并不是让模型“凭空生成一段音乐”，而是分三步走。第一步，前端做文本处理，把用户输入的句子拆成若干关键词，去除停用词后，映射到情绪维度空间——这个空间通常包含“明亮-黑暗”、“平静-紧张”、“律动-静止”这样几个连续的轴。第二步，将这些情绪维度数值和用户调节的三个滑杆参数拼成一个“生成条件向量”，作为模型的提示输入。第三步，模型在这个条件下生成长约16到32小节的旋律骨架，并同步生成对应的和弦序列。
我实测下来，这个三步链路要比直接让模型从原始文本端到端生成靠谱得多。端到端的方案幻想很好，但文本理解的不确定性会直接传导到音乐结果上，用户说一句“像傍晚跑步时听的歌”，模型如果没抓住“傍晚”的时间暗示，出来的就可能是大白天开party的感觉。通过情绪维度做拆解，至少能保证“傍晚”和“跑步”这两层信息分别映射到了节奏快慢和和声明暗上，从逻辑上更稳定。
4.3 Web Audio API与音频输出的关键细节
Web Audio API是整套浏览器音乐系统的地基，它能做的事情远比一般人想象的多。我们在项目里用AudioContext创建音频处理图，把音符事件转换成振荡器、噪声发生器、滤波器节点的组合，再连接到一个Master Gain节点上输出。为了支持多种风格，我还写了几个不同的“合成器预设”，比如吉他预设用的是几个锯齿波叠加加低通滤波，鼓组预设用噪声采样和低频正弦波相互调制，钢琴预设则偏向使用衰减曲线更长的波形。
这里有个特别值得说的坑：浏览器的自动播放策略。几乎所有主流浏览器都规定，页面在用户没有做出任何手势前，不允许自动播放音频。这意味着即使用户已经输入了内容，也必须在“播放”按钮被点击的那个瞬间，先创建或恢复AudioContext，否则整个音频链路是沉默的。回想初版项目就吃过这个亏：用户以为点击了播放，但控制台没有任何声音，实际是自动播放策略在作怪。我在新版里把“创建AudioContext”的动作绑定到了页面的首次点击事件上，并加了一句提示：“点击任意地方解锁声音”，这也是很多Web音频应用的标准做法。
5. 实操记录：两个真实可复现的创作场景
5.1 场景一：输入一句描述，生成一段旋律
我在开发过程中最常用来验收产品体验的一个场景，就是完全模拟一个没见过如何操作的普通用户。我打开页面，在文本输入框里敲一句“雨后的城市，干净，忧愁，很慢”，然后点击生成。系统先会显示一个简要的解读框，上面有几个情绪映射标签：“阴郁-偏暗，慢速-低律动，干净-简洁配器”，这其实是把情绪维度可视化给用户看，让他们有机会在文本理解有偏差时主动纠正。
点击播放后，我听到的是一段以钢琴为主的慢速旋律，和弦偏暗淡，鼓点很少，隔几拍才有一声类似水滴的音色点缀。这一段整体听下来是符合“雨后城市”的感觉的。如果用户觉得还不够忧伤，可以把“和声明暗”滑杆往左拖，生成调度层会重新计算和弦进行序列，钢琴低音区会更多，旋律线条也会稍微往下沉。整个过程从生成到第一次播放，大概十秒，中间没有跳出任何乐理概念。
我特别想说的是这个交互闭环对普通用户有多重要。我在内测群里找了一位完全没有音乐背景的测试者——她是一位做财务的朋友，平时只刷短视频，从来不碰乐器。她第一次只花了四十秒就完成了一小段曲子，而且她说什么：“我以为很难，结果就像在写一段心情日记，然后有人帮我唱了出来。”这句话让我觉得这轮方向走对了。
5.2 场景二：用手打节拍，AI补全编曲
第二个场景主打节奏。用户点开“节拍模式”后，页面提示“用空格键或触摸屏幕，按你想要的节奏打拍子”。系统会记录每次敲击的时间戳，并做归一化处理。我预设了一个简单的换算逻辑：将时间戳序列转换成BPM值范围，并识别出重音位置，生成一个底层鼓点模板。
用户打完八拍之后，点“让AI来配乐”，就会看到界面上的波形区里逐渐长出贝斯线、中声部和弦、以及演奏旋律，它们都严格对齐在用户打出的鼓点节奏骨架上。这个场景的反馈比文字输入更直接，因为用户亲自动手参与了“创作”，哪怕只是打了一段节奏，生成的音乐也会显得“是我做出来的”，而不是“AI随便给的”。
这种体感上的所有权非常重要。我后来分析用户留存时发现，用节拍模式创作过的用户，次日留存率明显高于只用文字输入的用户。原因很好理解：文字输入是“委托感”，节拍输入是“亲手感”。所以新版里我把这两个场景放在同一个首页，让新用户先玩节拍，再用文字润色，整体转化率提升了不少。
6. 踩坑实录：常见问题与排查方法
6.1 浏览器里没有声音，控制台报错
这大概是网页音乐项目最常见的问题，没有之一。用户第一次访问页面，点击播放按钮，什么都听不到，一看控制台，通常会有个报错叫“AudioContext was not allowed to start”。这背后的根本原因是浏览器自动播放策略。解决办法也相对固定：在用户第一次触发交互时，调用AudioContext.resume()；如果已经是suspended状态，再把它“resume”回来。我还在页面左上角加了一个小小的音量状态图标，如果检测到上下文状态不是“running”，会主动弹出一条提示，让用户再点击一次页面。这个比单纯在文档里写“请点击浏览器以启用声音”靠谱得多。
6.2 内存和性能问题：模型加载后页面的卡顿
模型推理本身没有占用太多CPU，但浏览器加载一个35MB的ONNX模型时要分配一大块ArrayBuffer，这在配置较低的设备上会导致页面卡顿甚至崩溃。我的优化方案是：不要在页面启动时就加载模型，而是延迟到用户第一次点击“生成”时才加载，并且加一个加载进度条，让用户有心理预期。另外，推理线程使用Web Worker独立运行，避免阻塞主线程的UI交互。这样即使推理过程中比较慢，用户依然可以流畅地拖动滑杆、切换风格标签，不会被“白屏”吓跑。
内存方面还有一个细节：每次生成后，旧的音符序列和音频缓冲区如果不主动清理，多次操作后内存会稳步上升。我做了一个简单的回收策略——每次生成新曲子前，将上一个AudioBufferSourceNode全部stop，并把相关的GainNode断开引用。这在长期使用时降低了不少崩溃概率。
6.3 生成结果不稳定，如何让输出更可控
即使是同一个输入，模型也可能生成不同的结果，同一个用户多刷几次有时会得到迥异的情绪。这个问题我在早期内测时被反映了很多次。后来我采取了一个比较务实的策略：不追求模型输出的唯一性，而是在生成后做一个“和预设情绪标签的匹配度检测”——算出当前输出属于哪个情绪区间，如果与用户输入的映射偏离太远，就自动再换一个种子重新生成，最多循环三次，取相似度最高的一次输出。
这样做虽然增加了极少量的推理开销，但换来的是用户对“AI懂我”的感知度大幅提升。此外，我还增加了“收藏创作”功能，用户觉得某次生成结果特别好，可以直接保存整段MIDI+音频配置，在自己的创作库里回听和继续编辑。这么一来，随机性反而成了灵感来源，而不是失控感。
最后聊聊我这几年的体会
我并不是一开始就懂这些道理的。打开旧版的代码仓库，看到那些精心设计的钢琴卷帘动画，我心里是很复杂的——那是认真做出来的产品，但它替用户做了太多“他会需要”的决定，却忽略了“他能不能用”。而AI真正带给我的，不是省掉写代码的时间，而是让我重新想象“创作”这两个字可以被怎样重新定义。如果你现在也想用AI复活某个过去没做成的东西，我的建议是：把这个项目重启之前，先花一个下午去听那些曾经的潜在用户说“太难了”到底难在哪。难点往往藏在入口处，AI能解决的大概率就是那个入口。
“零音乐基础也能在浏览器里创作音乐”这件事，在2023年我还觉得是句营销口号，现在我批量跑过上百次生成，验证过主流浏览器上的表现，可以负责任地说：它至少不再是痴人说梦了。我写这篇东西，也是想把这两年来做网页音乐生成项目遇到过的真实路径和坑记录下来，给同样在折腾AI加浏览器的朋友省一点探路的时间。等哪天这个产品真正跑起来，这些文字就是它最好的遗书——哦不，是简历。
