企业官网建设流程全解析

在文本生成领域折腾久了，很容易产生一种“模型什么都能干”的错觉。最近我在灰测环境里尝试让 Deepseek 模型直接生成音乐，结果拿到了一批相当“抽象”的产物——模型确实给出了两段结构完整的输出，但如果你真的按这些信息去渲染音频，就会发现它的听感离“音乐”还有十万八千里。更准确地说，它像一个完全听不见声音的“聋子”，在努力用文本符号描述它根本不熟悉的声音世界。

这篇文章想完整记录这个实验过程：为什么我会让文本模型生成音乐、灰测版暴露出哪些能力边界、两则音乐产物到底长什么样、以及最后我如何把它的输出改造成勉强能入耳的小样。文章不完全是踩坑记录，也包含一套可以复用的工程思路——如果你也想试试用文本模型做音乐生成、音频描述或乐谱输出，可以参考这套流程。

1. 项目背景与核心概念

1.1 为什么让文本模型生成音乐

常规的音乐生成方案是音频模型直接输出波形或 MIDI，比如一些开源的生成式音乐模型，输入一段文字描述，就能返回一段音频。这类模型经过专门的音频数据训练，知道“音色”“节奏”“力度”这些概念在物理上意味着什么。

但文本大模型的训练语料里，音乐信息往往以文本形式存在：歌词、乐评、曲式分析、甚至 ABC 记谱法的源码。模型知道音乐有旋律、和弦、节奏，但它没有真正“听过”声音。它像一个读过大量乐谱却从未演奏过乐器的人，能写出一张看起来合理的谱子，但没法确认这段旋律到底好不好听。

这次实验的主题就是用 Deepseek 的灰测版模型，走一条“文本描述 → 乐谱/结构化音乐数据 → 外部工具合成音频”的链路。这条路原本就充满不确定性，灰测版模型又把不确定性放大了一些。

1.2 “聋子模型”是什么意思

在标题里我用了“聋子模型”这个词，并不是说模型没有听觉能力，而是指：它没有音频输入通道，也没有音频输出通道，只能通过文本符号理解音乐。

所以会出现一个很典型的现象：模型输出的乐谱信息在语法层面完全正确，音高、时值、装饰音都写得清清楚楚，但当你把它渲染成音频后，听起来就像一段机械的、缺乏音乐表情的练习曲。模型感知不到强弱变化、连断奏法、声部之间的呼吸感。它不是故意写得难听，而是它真的不知道真实声音是什么样子。

这是所有文本大模型在涉足音乐生成时都会遇到的边界，灰测版模型尤其明显。因为在灰度测试阶段，模型的指令遵循能力可能不稳定，输出格式也可能漂移，这让“生成音乐”这个任务的失败率更高。

1.3 本文适合谁阅读

这篇文章适合以下读者：

• 想尝试用文本模型生成音乐或乐谱的开发者。
• 对 Deepseek API 接入、格式约束、结构化输出感兴趣的工程师。
• 想理解“为什么 AI 生成的乐谱听起来奇怪”的 AI 应用研究者。
• 正在做灰度测试、需要把模型输出做后处理的同学。

读完本文后，你会得到两则由 Deepseek 灰测版生成并经过二次加工的音乐小样，也会掌握一套“文本模型产乐谱 → 后处理 → 渲染音频”的实现方法。

2. 环境准备与版本说明

2.1 本次实验环境

这个项目对运行环境要求不高，重点在 API 调用和音频渲染两部分。我使用的环境如下：

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。如果你使用的是官方线上版本或其他渠道部署的模型，模型名称和接口地址需要按实际文档填写。

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": "请生成一段钢琴旋律"} ], temperature=0.7 ) print(resp.choices[0].message.content)

需要注意，灰测版模型的名称、上下文长度、定价都可能随测试批次变化。不要在生产环境依赖灰测接口。

3. 核心原理：如何让文本模型输出乐谱

3.1 直接生成音频不现实，输出符号才是正道

文本模型输出的本质是 token 序列，也就是文字。如果强行让模型输出一段音频采样数据，比如让它的输出是 PCM 编码的数值序列，效果会非常糟糕。因为模型没有经过音频波形级别的训练，它只能模仿文本表中偶尔出现的数字串，但完全不懂这些数字串如何组成声波。

更合理的方式是让模型输出音乐符号。符号体系有很多种：

我推荐 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参数直接影响输出的随机性。音乐生成和代码生成一样，都需要控制随机性，否则输出会变得混乱。

我的实验参数如下：

如果发现模型输出的旋律走向太单调，可以把 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.wav

4.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.py：

from openai import OpenAI import config class DeepSeekClient: def __init__(self): self.client = OpenAI( api_key=config.API_KEY, base_url=config.BASE_URL ) def generate_text(self, prompt, temperature=0.6, max_tokens=2048): resp = self.client.chat.completions.create( model=config.MODEL, messages=[ {"role": "user", "content": prompt} ], temperature=temperature, max_tokens=max_tokens, top_p=0.9 ) return resp.choices[0].message.content

4.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 = r"```abc\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", encoding="utf-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", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) 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(number=data.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", fp=output_path)

最后调用：

def render_piece2(): with open("output/piece2.json", "r", encoding="utf-8") as f: data = json.load(f) json_to_midi(data, "output/piece2.mid") print("第二则 MIDI 已保存到 output/piece2.mid")

4.6 两则产物的听感复盘

这是最关键的环节。我把两则音乐都渲染成 WAV 后逐个听了一遍，和预期完全一致——两段音乐的“乐谱正确性”都还行，但“音乐性”几乎没有。

第二则最主要的问题是：我要求左手和弦每小节一个，但模型生成的左手部分几乎是每拍一个和弦，导致低音区非常拥挤。虽然总时长是正确的，但听感和“温暖抒情钢琴曲”完全不沾边。

这个结果正好印证了最开始的判断：模型知道乐谱的结构，但不知道声音的组合效果。它会把“和弦”理解为“往小节里填入尽可能多的符合时值的音”，而不是“在合适的位置创造静谧的空间”。

4.7 修复后处理流程

为了让这两则产物能拿得出手，我增加了一个后处理脚本，把“模型乐谱”加工成“真正可听的音乐”，修改策略包括：

1. 降低左手和弦密度：把所有左手音符统一变成每小节一个整和弦。
2. 增加力度标记：给旋律音符加上渐强渐弱。
3. 调整音符长度：把一部分八分音符改成二分音符或附点节奏，增加律动感。

以第二则为例，实际修改后的核心逻辑如下：

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 约束不够强，或者模型在灰度版本下的指令遵循能力退化。

解决思路：

后处理时我写了两个函数来清洗模型输出：

def clean_abc(text): pattern = r"```abc\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 请求失败或返回空内容

排查顺序如下：

1. 确认base_url与api_key是否正确。
2. 确认模型名称是否存在于当前灰度环境。
3. 确认上下文长度是否超过限制。
4. 加入重试与降级机制。

灰度测试环境下服务不稳定是常态，建议在客户端加上指数退避重试：

import time def generate_with_retry(prompt, max_retries=3): for i in range(max_retries): try: return client.generate_text(prompt) except Exception as e: print(f"第 {i+1} 次调用失败：{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 灰测版能写出语法正确的乐谱，但它始终是一个“聋子模型”——它依赖文本符号来“理解”音乐，而符号和声音之间有一条无法用提示词抹平的鸿沟。

整个流程跑通后，我的建议是：把文本模型生成音乐当作一个前置创意工具，不要把它视为自动作曲引擎。它产生的两段“音乐”虽然原始，但确实给后续创作提供了起点。如果你抓住这个起点继续修改，会比面对一张白纸更容易进入创作状态。

如果你想继续深入，可以按以下路线学习：

1. 掌握 ABC 记谱法和 MusicXML 语法，能手动编辑模型输出的乐谱。
2. 熟悉 MIDI 协议和音色库原理，知道为什么同一段 MIDI 在不同音色库下听感差异巨大。
3. 学习数字信号处理基础，理解采样率、波形、频谱对最终听感的影响。
4. 尝试用条件生成模型（例如基于扩散的音频模型）做音频级音乐生成，和文本模型的乐谱生成形成对比。
5. 在服务端实现完整的“文本模型 → 乐谱校验 → MIDI 渲染 → 音频返回”API 链路，把整个流程产品化。

如果你也准备做一个类似的实验，建议从“8 小节钢琴单旋律”开始，等格式稳定后再叠加声部、和弦和乐器编排。先让流程可靠运行，再谈音乐性优化。两则产物虽然稚嫩，但至少它们让我真正理解了：在音乐生成这件事上，模型不仅要看懂音符，更需要听懂声音。这条“听懂声音”的路，文本大模型还有很长的距离。