在文本生成领域折腾久了很容易产生一种“模型什么都能干”的错觉。最近我在灰测环境里尝试让 Deepseek 模型直接生成音乐结果拿到了一批相当“抽象”的产物——模型确实给出了两段结构完整的输出但如果你真的按这些信息去渲染音频就会发现它的听感离“音乐”还有十万八千里。更准确地说它像一个完全听不见声音的“聋子”在努力用文本符号描述它根本不熟悉的声音世界。这篇文章想完整记录这个实验过程为什么我会让文本模型生成音乐、灰测版暴露出哪些能力边界、两则音乐产物到底长什么样、以及最后我如何把它的输出改造成勉强能入耳的小样。文章不完全是踩坑记录也包含一套可以复用的工程思路——如果你也想试试用文本模型做音乐生成、音频描述或乐谱输出可以参考这套流程。1. 项目背景与核心概念1.1 为什么让文本模型生成音乐常规的音乐生成方案是音频模型直接输出波形或 MIDI比如一些开源的生成式音乐模型输入一段文字描述就能返回一段音频。这类模型经过专门的音频数据训练知道“音色”“节奏”“力度”这些概念在物理上意味着什么。但文本大模型的训练语料里音乐信息往往以文本形式存在歌词、乐评、曲式分析、甚至 ABC 记谱法的源码。模型知道音乐有旋律、和弦、节奏但它没有真正“听过”声音。它像一个读过大量乐谱却从未演奏过乐器的人能写出一张看起来合理的谱子但没法确认这段旋律到底好不好听。这次实验的主题就是用 Deepseek 的灰测版模型走一条“文本描述 → 乐谱/结构化音乐数据 → 外部工具合成音频”的链路。这条路原本就充满不确定性灰测版模型又把不确定性放大了一些。1.2 “聋子模型”是什么意思在标题里我用了“聋子模型”这个词并不是说模型没有听觉能力而是指它没有音频输入通道也没有音频输出通道只能通过文本符号理解音乐。所以会出现一个很典型的现象模型输出的乐谱信息在语法层面完全正确音高、时值、装饰音都写得清清楚楚但当你把它渲染成音频后听起来就像一段机械的、缺乏音乐表情的练习曲。模型感知不到强弱变化、连断奏法、声部之间的呼吸感。它不是故意写得难听而是它真的不知道真实声音是什么样子。这是所有文本大模型在涉足音乐生成时都会遇到的边界灰测版模型尤其明显。因为在灰度测试阶段模型的指令遵循能力可能不稳定输出格式也可能漂移这让“生成音乐”这个任务的失败率更高。1.3 本文适合谁阅读这篇文章适合以下读者想尝试用文本模型生成音乐或乐谱的开发者。对 Deepseek API 接入、格式约束、结构化输出感兴趣的工程师。想理解“为什么 AI 生成的乐谱听起来奇怪”的 AI 应用研究者。正在做灰度测试、需要把模型输出做后处理的同学。读完本文后你会得到两则由 Deepseek 灰测版生成并经过二次加工的音乐小样也会掌握一套“文本模型产乐谱 → 后处理 → 渲染音频”的实现方法。2. 环境准备与版本说明2.1 本次实验环境这个项目对运行环境要求不高重点在 API 调用和音频渲染两部分。我使用的环境如下环境项说明操作系统Windows 11理论上 macOS / Linux 均可Python 版本Python 3.10模型服务Deepseek 灰测版具体版本号随灰度批次变化音频渲染库music21、pyfluidsynth需要 SF2 音色库记谱解析库music21 自带 ABC 解析器API 调用方式OpenAI 兼容接口格式版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。如果你使用的是官方线上版本或其他渠道部署的模型模型名称和接口地址需要按实际文档填写。2.2 安装依赖首先是 Python 环境准备建议使用虚拟环境python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate需要安装的 Python 库如下pip install openai python-dotenv music21 pyfluidsynth其中music21是学术界常用的乐谱分析工具能把 ABC 记谱法、MIDI、MusicXML 互相转换。pyfluidsynth是一个 FluidSynth 的 Python 封装用来把 MIDI 渲染成 WAV 音频。还需要一个 SoundFont 音色库文件常见的是 GM 音色库可以从网络上合法获取文件名类似GeneralUser GS v1.471.sf2。如果没有这个文件程序无法把 MIDI 变成真正的音频。2.3 Deepseek API 接入基础Deepseek 的 API 兼容 OpenAI 格式所以调用方式和我们熟悉的openai客户端几乎一样。核心是配置base_url和api_key。灰度测试版的接口地址可能和正式版不同以下代码展示了通用思路from openai import OpenAI client OpenAI( api_key你的API_KEY, base_url你的接口地址 ) resp client.chat.completions.create( model模型名称, messages[ {role: user, content: 请生成一段钢琴旋律} ], temperature0.7 ) print(resp.choices[0].message.content)需要注意灰测版模型的名称、上下文长度、定价都可能随测试批次变化。不要在生产环境依赖灰测接口。3. 核心原理如何让文本模型输出乐谱3.1 直接生成音频不现实输出符号才是正道文本模型输出的本质是 token 序列也就是文字。如果强行让模型输出一段音频采样数据比如让它的输出是 PCM 编码的数值序列效果会非常糟糕。因为模型没有经过音频波形级别的训练它只能模仿文本表中偶尔出现的数字串但完全不懂这些数字串如何组成声波。更合理的方式是让模型输出音乐符号。符号体系有很多种符号体系特点适合场景ABC 记谱法文本格式人类可读适合民歌、旋律快速生成旋律草稿MusicXML结构化 XML信息完整专业乐谱编辑MIDI 文本形式音符编号 起始时间 时长程序直接渲染JSON 结构自定义格式可控性强程序后处理我推荐 ABC 记谱法或自定义 JSON 格式。前者是文本模型见多识广后者适合程序直接解析出错时容易排查。3.2 让模型输出结构化内容的 Prompt 设计文本模型很容易在长输出中途跑偏尤其生成乐谱时可能写了一段描述文字后突然开始歌词创作。所以在 Prompt 里要做硬性约束。先看一个简单示例你是一个音乐记谱助手。请用 ABC 记谱法写一段 8 小节的钢琴旋律。 要求 1. 只输出 ABC 记谱法代码块不要输出解释文字。 2. 拍号为 4/4调号为 C 大调。 3. 旋律起伏要自然包含至少一个渐强到最高音的段落。 4. 不要使用装饰音保持简单。这样的 Prompt 把输出范围限制在代码块内同时给了音乐层面的约束。但实际上灰测版模型经常不遵守第 1 条它会输出类似这样的内容好的下面是一段 8 小节的钢琴旋律使用 ABC 记谱法 X:1 ...这个“好的”就是格式污染。后处理时我们必须把模型回复中的有效部分抽取出来而不是直接整段交给解析器。3.3 温度参数与随机性控制temperature参数直接影响输出的随机性。音乐生成和代码生成一样都需要控制随机性否则输出会变得混乱。我的实验参数如下参数数值原因temperature0.6保留一定创造性但不会太散top_p0.9限制候选 token 范围max_tokens2048足够生成一段完整乐谱如果发现模型输出的旋律走向太单调可以把 temperature 提高到 0.8。如果模型频繁出现格式错误则降低到 0.4 左右。4. 完整实战生成两则音乐产物下面进入正题。我会完整演示两则音乐产物的生成过程。4.1 项目结构本次项目的文件结构如下方便你照搬deepseek-music-lab/ ├── .env # 存放 API 密钥等配置 ├── config.py # 加载配置文件 ├── deepseek_client.py # Deepseek API 调用封装 ├── prompt_templates.py # 音乐生成 Prompt 模板 ├── generate_music.py # 主脚本调用模型生成乐谱 ├── render_music.py # 渲染脚本将乐谱转为 MIDI/WAV └── output/ ├── piece1.abc ├── piece1.json ├── piece1.mid ├── piece1.wav ├── piece2.abc ├── piece2.json ├── piece2.mid └── piece2.wav4.2 配置文件与 API 封装先创建.env文件DEEPSEEK_API_KEY你的API_KEY DEEPSEEK_BASE_URL你的接口地址 DEEPSEEK_MODEL你的模型名称注意灰测版的模型名称是动态的请从你的灰度测试通知或服务商文档中获取不要照抄网上的旧版本名称。下面写config.py用于统一管理配置import os from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(DEEPSEEK_API_KEY) BASE_URL os.getenv(DEEPSEEK_BASE_URL) MODEL os.getenv(DEEPSEEK_MODEL)然后是deepseek_client.pyfrom openai import OpenAI import config class DeepSeekClient: def __init__(self): self.client OpenAI( api_keyconfig.API_KEY, base_urlconfig.BASE_URL ) def generate_text(self, prompt, temperature0.6, max_tokens2048): resp self.client.chat.completions.create( modelconfig.MODEL, messages[ {role: user, content: prompt} ], temperaturetemperature, max_tokensmax_tokens, top_p0.9 ) return resp.choices[0].message.content4.3 第一则8 小节单旋律第一则音乐我设定为一段 C 大调钢琴旋律。Prompt 模板放在prompt_templates.py中MELODY_PROMPT 你是一个音乐记谱助手。 请用 ABC 记谱法写一段 8 小节钢琴旋律。 输出要求 1. 必须使用 ABC 记谱法只输出一个代码块代码块语言标记为 abc。 2. 不要输出代码块以外的任何文字。 3. 拍号是 4/4。 4. 调号是 C 大调。 5. 旋律需要有明确的高潮点从低音区逐渐上升到高音区再回落。 6. 每个小节 4 拍不限定音符密度允许使用八分音符。 7. 不要加入歌词。 旋律要求安静、流动、带有一点忧郁感。 然后写generate_music.py的主流程。为了让输出更可控我先请求模型输出 ABC再让模型把同样的旋律转成 JSON 结构。这样做的原因是ABC 适合人类阅读和快速试听JSON 适合程序做特征分析和后处理。import json import re from deepseek_client import DeepSeekClient from prompt_templates import MELODY_PROMPT client DeepSeekClient() def extract_abc(text): pattern rabc\n(.*?) match re.search(pattern, text, re.DOTALL) if match: return match.group(1).strip() # 如果没有代码块去掉常见引导语 text text.strip() if text.startswith(X:1): return text lines text.split(\n) for i, line in enumerate(lines): if line.startswith(X:): return \n.join(lines[i:]) return None def run_piece1(): raw client.generate_text(MELODY_PROMPT) abc_text extract_abc(raw) if abc_text is None: print(第一则生成失败未提取到 ABC 乐谱) print(raw) return with open(output/piece1.abc, w, encodingutf-8) as f: f.write(abc_text) print(第一则 ABC 乐谱已保存到 output/piece1.abc) if __name__ __main__: run_piece1()运行命令python generate_music.py我实际拿到的第一则 ABC 乐谱类似下面这样但略有差异X:1 T:Quiet Blue M:4/4 L:1/8 K:C | C4 E4 | G4 A4 | G2 E2 C2 D2 | E4 C4 | F2 A2 G2 E2 | D4 C2 B,2 | C4 B,4 | A,2 G,2 C4 |从谱面看这是一段 8 小节的 C 大调旋律时值、音高范围、小节长度都符合要求。但实际渲染后你会发现旋律虽然“对”但缺少节奏变化八分音符和四分音符分布得太均匀听起来像节拍器在演奏音阶。后面我会在 4.6 节说明如何修复。4.4 第二则双声部编排第二则音乐我决定提高难度让模型生成一段 16 小节的二声部钢琴曲包含右手旋律和左手伴奏。这时候如果还用纯 ABC 记谱法模型很容易把两个声部混在一起。所以我改用 JSON 结构输出。Prompt 模板如下DUO_PROMPT 你是一个音乐结构生成器。 请生成一段 16 小节的钢琴二声部音乐包含右手旋律和左手伴奏。 输出要求 1. 只输出 JSON不要输出任何解释文字。 2. JSON 结构如下 { title: 作品标题, tempo: 80, time_signature: 4/4, key: C, measures: [ { melody: [C4:4, E4:4, G4:4, A4:4], chord: [C3:E3:G3:4] } ] } 3. 每个音符格式为 音名八度:时值时值使用数字4 代表四分音符2 代表二分音符8 代表八分音符。 4. 和弦格式为 多个音名用冒号连接:时值。 5. melody 每个小节必须刚好 4 拍。 6. 和弦一栏每个元素也必须是整数拍。 7. 不要使用浮点数不要使用复杂和弦标记。 音乐风格温暖、舒缓、类似流行钢琴抒情曲。 注意这里音符格式里的时值数字有点反直觉。在编程思维里8 是更大数字但在乐谱里八分音符是半拍。所以我在 Prompt 里明确写清楚4 代表四分音符8 代表八分音符。这种设计是为了让模型少犯错。接着在generate_music.py里增加一个函数DUO_PROMPT DUO_PROMPT # 已在上方定义 def run_piece2(): raw client.generate_text(DUO_PROMPT) json_text raw.strip() # 模型经常会在 JSON 前后加描述文字需要处理 if json_text.startswith(json): json_text json_text.replace(json, ).replace(, ).strip() try: data json.loads(json_text) except json.JSONDecodeError as e: print(第二则生成失败JSON 解析错误, e) print(raw) return with open(output/piece2.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(第二则 JSON 乐谱已保存到 output/piece2.json)这里的 JSON 结构是我自定义的不是标准音乐格式。它的好处是解析简单容易检查拍数是否合法。缺点是不能直接转成 MIDI需要写一个转换层。4.5 JSON 转 MIDI 的渲染脚本为了让第二则音乐真正“响起来”需要用music21把 JSON 转换成 MIDI。from music21 import converter, note, chord, stream, tempo, meter def parse_note(note_str): # 输入格式例如 C4:4 parts note_str.split(:) pitch parts[0] duration int(parts[1]) n note.Note(pitch) n.quarterLength 4.0 / duration return n def json_to_midi(data, output_path): s stream.Score() p1 stream.Part() p2 stream.Part() right stream.Part() left stream.Part() tempo_mm tempo.MetronomeMark(numberdata.get(tempo, 80)) right.append(tempo_mm) ts meter.TimeSignature(data.get(time_signature, 4/4)) right.append(ts) for measure in data[measures]: # 右手旋律 for mel in measure[melody]: right.append(parse_note(mel)) # 左手和弦 for ch in measure[chord]: pitches ch.split(:)[:-1] duration int(ch.split(:)[-1]) chord_notes [note.Note(p) for p in pitches] c chord.Chord(chord_notes) c.quarterLength 4.0 / duration left.append(c) p1.append(right) p2.append(left) s.append(p1) s.append(p2) s.write(midi, fpoutput_path)最后调用def render_piece2(): with open(output/piece2.json, r, encodingutf-8) as f: data json.load(f) json_to_midi(data, output/piece2.mid) print(第二则 MIDI 已保存到 output/piece2.mid)4.6 两则产物的听感复盘这是最关键的环节。我把两则音乐都渲染成 WAV 后逐个听了一遍和预期完全一致——两段音乐的“乐谱正确性”都还行但“音乐性”几乎没有。维度第一则ABC 旋律第二则JSON 二声部音高正确性正确正确节奏正确性正确正确声部独立性单声部左右手基本独立旋律流畅度一般像是音阶平移一般偶尔有跳跃和弦连接无过于频繁每小节都换听感问题节奏机械缺乏强弱左手和弦密度太高听感沉闷第二则最主要的问题是我要求左手和弦每小节一个但模型生成的左手部分几乎是每拍一个和弦导致低音区非常拥挤。虽然总时长是正确的但听感和“温暖抒情钢琴曲”完全不沾边。这个结果正好印证了最开始的判断模型知道乐谱的结构但不知道声音的组合效果。它会把“和弦”理解为“往小节里填入尽可能多的符合时值的音”而不是“在合适的位置创造静谧的空间”。4.7 修复后处理流程为了让这两则产物能拿得出手我增加了一个后处理脚本把“模型乐谱”加工成“真正可听的音乐”修改策略包括降低左手和弦密度把所有左手音符统一变成每小节一个整和弦。增加力度标记给旋律音符加上渐强渐弱。调整音符长度把一部分八分音符改成二分音符或附点节奏增加律动感。以第二则为例实际修改后的核心逻辑如下def simplify_left_hand(measures): for measure in measures: # 只保留每小节第一个和弦并让时值为全音符 first_chord measure[chord][0] measure[chord] [first_chord.split(:)[0] : first_chord.split(:)[1] :1] return measures这样修改后听感立刻变得宽松很多。虽然它依然不是多高明的音乐但至少不再是“忙碌的音符堆砌”。5. 常见问题与排查思路5.1 模型输出被引导语污染现象模型在 ABC 或 JSON 前后输出“好的”“以下是您需要的”等文字导致解析器报错。原因Prompt 约束不够强或者模型在灰度版本下的指令遵循能力退化。解决思路问题现象常见原因解决思路输出带“好的”等引导语模型未严格遵循只输出代码块指令后处理时用正则抽取 (abc ...) 块JSON 解析失败模型输出json 代码块标记去掉标记后再 json.loadsABC 代码块内混入歌词提示词未强调禁止歌词增加 negative prompt不要输出歌词结构完整但小节拍数不对模型对时值理解不精确在 JSON 后处理时检查并自动修正时长后处理时我写了两个函数来清洗模型输出def clean_abc(text): pattern rabc\n(.*?) match re.search(pattern, text, re.DOTALL) if match: return match.group(1).strip() # 退而求其次找 X:1 开头 start text.find(X:1) if start ! -1: return text[start:].strip() return text.strip() def clean_json(text): if json in text: text text.split(json)[1].split()[0] return text.strip()这个经验是不要指望模型是完美的输出器。哪怕用更强的模型也应该在应用层增加一层校验。5.2 模型生成了音乐描述而不是乐谱有时模型会输出大段文字比如“这段音乐以小调开头情绪忧郁适合下雨天聆听”而不是直接给乐谱。这是因为 Prompt 把“音乐”概念放到了“情绪”前面模型选择了更擅长的文本描述路径。解决方法是把任务拆细第一步要求“只生成乐谱”第二步再要求“分析这个乐谱的情绪”。不要试图让模型同时做创作和评论。5.3 音色渲染后完全不像音乐即使乐谱结构正确经过 MIDI 渲染后也可能出现听感生硬的问题。从音乐工程角度看主要原因有三个缺少力度层。MIDI 音符没有 velocity 信息所有音都一样响。音符时间量化太整齐。真人演奏不会精确踩在每一个节拍网格上。和弦进行缺少耐心。频繁换和弦会让和声失去方向感。在项目里我使用了music21给音符添加力度变化for i, n in enumerate(s.recurse().notes): n.volume.velocity 60 30 * (i % 4) # 简单波浪力度这个操作不算高级但能让听感立刻改善一些。5.4 API 请求失败或返回空内容排查顺序如下确认base_url与api_key是否正确。确认模型名称是否存在于当前灰度环境。确认上下文长度是否超过限制。加入重试与降级机制。灰度测试环境下服务不稳定是常态建议在客户端加上指数退避重试import time def generate_with_retry(prompt, max_retries3): for i in range(max_retries): try: return client.generate_text(prompt) except Exception as e: print(f第 {i1} 次调用失败{e}) if i max_retries - 1: time.sleep(2 ** i) raise RuntimeError(模型调用失败)6. 工程化思路与最佳实践6.1 把模型当“草稿生成器”而不是“成品作者”这次实验给我最大的教训是不要在文本模型输出乐谱后直接对外发布音频。模型的角色应定位在灵感草稿生成而不是最终音乐制作。所有经过模型输出的音乐信息都必须经过人工听感和程序化检查两道关卡。流程可以固定为模型生成乐谱 → 程序检查结构合法性 → 渲染成 MIDI/WAV → 人工试听 → 保留或丢弃 → 必要的二次编辑这一步能有效避免把模型的“幻觉”直接暴露给用户。6.2 为模型输出设计校验层任何文本模型都存在格式漂移风险。因此在实际项目中我对模型输出做三层校验第一层正则抽取。从原始文本中提取代码块或 JSON 区域。第二层结构校验。检查拍数是否匹配、音符时值是否合法、声部是否完整。第三层听感筛选。这一层只能靠人工或专门的音频质量模型文本模型无法完成。以 JSON 结构的校验为例核心代码如下def validate_measure(measure): total_melody 0 for mel in measure[melody]: _, dur mel.split(:) total_melody 4.0 / float(dur) return abs(total_melody - 4.0) 0.01这个校验逻辑不复杂但价值很高。它能在几毫秒内拦截掉绝大多数格式错误。6.3 灰度版本的风险控制如果你也在使用灰测版模型建议做到以下几点不要在生产环境直接调用灰测接口。对模型输出增加版本标签避免后续灰度参数变化导致结果不可比。定期记录输出成功率灰度批次切换时立刻对比历史结果。所有生成结果保存原始响应日志方便回溯和归因。不要把灰测模型的输出直接用于商业发布除非你确认授权范围和内容安全机制。灰度版本与正式版本的差异可能超出预期比如指令遵循能力变强但知识更新不及时或者相反。这些都需要以实测为准不要盲信文档。6.4 提示词设计的几条经验指定输出格式时最好同时给出一个最小示例让模型复制结构。不要同时约束太多音乐属性比如“又忧郁又欢快又复杂”模型会不知道如何取舍。把输出规则放在 Prompt 最前面然后用空行隔开音乐要求减少后面要求被“淹没”的可能。对不想要的输出直接写“不要输出歌词”“不要输出解释文字”“不要输出和弦代号”远比只说“只输出乐谱”有效。6.5 关于版权和合规用 AI 生成音乐内容版权归属取决于服务条款、模型训练数据和生成作品的独创性判断不同的平台有不同的规定。我的建议是使用模型生成的乐谱做自己的原创创作时尽量修改核心旋律走向增加原创段落。不要直接拿模型生成的旋律商用因为无法完全确认训练数据来源。生成内容发布时标注“协助 AI 生成”是更透明的做法。如果在企业项目中使用确认模型服务商的企业服务协议。生成音乐的问题比文本生成更复杂因为音乐本身就有大量组合方式模型有可能在输出中复现训练集中某段旋律的影子。做内容审核时音乐比对比文本查重要困难得多。7. 总结与后续学习路线这次实验让我对文本模型的能力边界有了更深的体会。Deepseek 灰测版能写出语法正确的乐谱但它始终是一个“聋子模型”——它依赖文本符号来“理解”音乐而符号和声音之间有一条无法用提示词抹平的鸿沟。整个流程跑通后我的建议是把文本模型生成音乐当作一个前置创意工具不要把它视为自动作曲引擎。它产生的两段“音乐”虽然原始但确实给后续创作提供了起点。如果你抓住这个起点继续修改会比面对一张白纸更容易进入创作状态。如果你想继续深入可以按以下路线学习掌握 ABC 记谱法和 MusicXML 语法能手动编辑模型输出的乐谱。熟悉 MIDI 协议和音色库原理知道为什么同一段 MIDI 在不同音色库下听感差异巨大。学习数字信号处理基础理解采样率、波形、频谱对最终听感的影响。尝试用条件生成模型例如基于扩散的音频模型做音频级音乐生成和文本模型的乐谱生成形成对比。在服务端实现完整的“文本模型 → 乐谱校验 → MIDI 渲染 → 音频返回”API 链路把整个流程产品化。如果你也准备做一个类似的实验建议从“8 小节钢琴单旋律”开始等格式稳定后再叠加声部、和弦和乐器编排。先让流程可靠运行再谈音乐性优化。两则产物虽然稚嫩但至少它们让我真正理解了在音乐生成这件事上模型不仅要看懂音符更需要听懂声音。这条“听懂声音”的路文本大模型还有很长的距离。