Markdown格式输出乐谱信息：让ACE-Step生成结果更易读可分享

让AI音乐“看得懂”：用Markdown重构ACE-Step生成结果的可读性与协作价值

在AI开始作曲的今天，我们面对一个微妙却真实的问题：当一段旋律由文字提示“一段温暖的C大调钢琴曲，带着雨后的静谧感”自动生成时，创作者听到的是音频，看到的却常常是一片空白。没有乐谱、没有结构说明、没有和声线索——只有.wav或.mp3文件静静地躺在下载目录里。

这就像收到一封加密信件，内容动人，但你不知道它是怎么写出来的，也无法修改其中某个小节的和弦。这种“黑箱创作”模式，正是当前AI音乐落地过程中最隐蔽的瓶颈之一。

而解决这个问题的关键，或许不在模型本身，而在输出方式的设计。

ACE-Step，这个由ACE Studio与阶跃星辰（StepFun）联合推出的开源音乐生成模型，已经在技术上实现了高质量、多模态输入、快速响应的闭环。它采用扩散模型架构，在潜在空间中逐步去噪生成音乐表示，并通过深度压缩自编码器与轻量级线性Transformer的组合，兼顾了音质与效率。但真正让它从“能听”走向“可读”的，是后处理环节的一项看似简单却极具潜力的设计：将生成结果以Markdown格式输出为结构化乐谱信息。

这不是简单的文本导出，而是一种思维方式的转变——把AI从“演奏者”变为“作曲人”，让它不仅产出声音，还能写出自己的“创作笔记”。

想象一下这样的场景：

你输入一句提示：“写一首适合清晨咖啡馆播放的爵士吉他小品，B♭大调，swing节奏”。几秒后，系统返回两个文件：
- 一个是16秒的音频片段，温暖慵懒；
- 另一个是名为morning_cafe_guitar.md的文档，打开后清晰列出：

## 《晨间咖啡》 **风格**：Jazz / Bossa Nova **调式**：B♭ major **节拍**：4/4 (Swing) **BPM**：96 ### 主旋律（Guitar） | 小节 | 和弦 | 旋律音 | 节奏型 | |------|----------|-----------------------|----------------| | 1 | B♭maj7 | D F A C | ♪. ♪ ♪ ♪ | | 2 | E♭7 | G B D F | ♪ ♪. ♪ ♪ | | 3 | Am7♭5 | C E♭ G B♭ | ♪ ♪ ♪ ♪ | | 4 | D7 | F♯ A C♯ E | ♪. ♪ ♪ | > 自动生成于 2025-04-05 | 模型版本：ACE-Step-v1.2

你可以一眼看出第三小节用了半减七和弦营造张力，第四小节属七和弦引导回主调；可以复制这段和弦进行到你的DAW项目中重新编配；甚至可以把这份文档贴进团队协作工具里，请同事批注：“这里试试改成II-V-I？”。

这才是真正的“协同创作”起点。

实现这一切的技术链条其实并不复杂，核心在于打通三个环节：解析 → 量化 → 结构化呈现。

首先是解析生成输出。ACE-Step最终输出通常是JSON格式的结构化音乐数据，包含全局元信息（标题、BPM、调性）、轨道列表以及每个音符的时间戳、音高、力度等字段。这些数据本就是符号化的，只是通常被直接送往合成器转为波形，而我们选择先将其“截留”，用于构建文档。

接着是时间对齐与量化。原始音符的时间可能是浮点数（如0.375秒），我们需要将其映射到最近的节拍网格上。例如在96 BPM下，每拍约0.625秒，那么一个起始时间为1.88秒的音符应归入第4小节第2拍。这个过程确保所有音符都能按小节整齐分组，避免出现“半个音符卡在小节线上”的混乱情况。

然后是和弦识别。同一时间点上的多个音符是否构成和弦？如果是，是什么和弦？虽然完整和声分析需要上下文理解，但对于基础三和弦或七和弦，我们可以用简单的音程规则判断。比如[C, E, G]对应C major，[D, F, A]对应D minor，[E, G, B, D]则是Emin7。更复杂的和弦则标记为“Complex”或留空，不强行命名以免误导。

最后一步是表格化组织与渲染。使用标准Markdown语法构造标题、加粗标签和表格，再辅以注释水印，即可生成一份既美观又兼容性强的文档。更重要的是，这种纯文本格式天然支持Git版本控制——你可以提交v1初稿，几天后再对比v2修改版，清楚看到哪一小节换了和弦、哪一段旋律延长了两拍。

下面是一个简化的转换脚本示例，展示了如何将JSON音乐数据转为Markdown表格：

import json from fractions import Fraction def quantize_beat(time_seconds, bpm): beat_duration = 60 / bpm return round(time_seconds / beat_duration) def pitch_to_note(pitch): notes = ['C', 'C#', 'D', 'D#', 'E', 'F', 'F#', 'G', 'G#', 'A', 'A#', 'B'] octave = pitch // 12 - 1 note_name = notes[pitch % 12] return f"{note_name}{octave}" def infer_chord(pitches): if len(pitches) < 3: return "N.C." root = min(pitches) intervals = sorted((p - root) % 12 for p in pitches) if set(intervals[:3]) == {0, 4, 7}: return pitch_to_note(root).replace('#', '♯') + "maj" elif set(intervals[:3]) == {0, 3, 7}: return pitch_to_note(root).replace('#', '♯') + "min" else: return "Complex" def generate_markdown_score(music_data: dict) -> str: meta = music_data['metadata'] tracks = music_data['tracks'] md_lines = [] md_lines.append(f"## {meta.get('title', 'Untitled')}") md_lines.append(f"**风格**：{meta.get('genre', 'Unknown')} ") md_lines.append(f"**调式**：{meta.get('key', 'C major')} ") md_lines.append(f"**节拍**：{meta.get('time_signature', '4/4')} ") md_lines.append(f"**BPM**：{meta.get('bpm', 120)} ") md_lines.append("") for track in tracks: md_lines.append(f"### {track['name']}（{track['instrument']}）") md_lines.append("| 小节 | 和弦 | 旋律 | 伴奏 |") md_lines.append("|------|------|------|------|") notes_by_bar = {} chords_by_bar = {} beats_per_bar = 4 total_bars = 8 for note in track['notes']: bar_idx = quantize_beat(note['start'], meta['bpm']) // beats_per_bar if bar_idx >= total_bars: continue if bar_idx not in notes_by_bar: notes_by_bar[bar_idx] = [] chords_by_bar[bar_idx] = [] notes_by_bar[bar_idx].append(note['pitch']) chords_by_bar[bar_idx].append(note['pitch']) for bar in range(total_bars): chord_str = infer_chord(chords_by_bar.get(bar, [])) if bar in chords_by_bar else "N.C." melody_pitches = notes_by_bar.get(bar, [])[:4] melody_str = " ".join(pitch_to_note(p) for p in melody_pitches) if melody_pitches else "-" md_lines.append(f"| {bar+1} | {chord_str} | {melody_str} | ? |") md_lines.append("") md_lines.append(f"> 自动生成于 {meta.get('generated_at')} | 模型版本：{meta.get('model_version')}") return "\n".join(md_lines)

这个模块完全可以作为ACE-Step后端服务中的一个独立组件运行，与音频合成并行处理。它不增加主干推理负担，却极大提升了输出的信息密度。

值得一提的是，这种设计背后体现了一种工程哲学上的权衡：不过度追求精确，而是强调可用性。

我们不会试图在Markdown中还原每一个十六分音符的装饰音，也不会强制推断每一帧的和声功能。相反，我们接受一定程度的简化——以小节为单位汇总关键信息，保留主旋律线条与和弦骨架。这种“摘要式呈现”反而更适合人类阅读与讨论。

同时，为了增强机器可读性，可以在文档开头加入YAML front-matter：

--- title: 晨光序曲 bpm: 92 key: C instruments: Piano, Strings chord_sequence: [C, G, Am, F] ---

这样既能被文本编辑器友好展示，也能被后续工具链自动提取元数据，实现“人机双通”。

回到最初的问题：为什么非得让AI输出Markdown？

因为未来的AI创作工具，不应止步于“生成即终点”，而应成为“创作流程的入口”。

当一位新手想学习流行歌曲的和弦套路时，他可以直接查阅上百份由AI生成的.md文件，观察哪些进行最常见；当一位制作人需要灵感参考时，他可以在Notion中建立一个“AI草稿库”，用标签分类不同情绪、风格的片段；当团队远程协作时，GitHub PR里的评论可以直接指向某一小节：“这里换成iv级小和弦会不会更有忧伤感？”

这已经不只是格式优化，而是在构建一种新的音乐知识流通方式。

ACE-Step所采用的“扩散+线性Transformer”架构固然先进，但真正让它区别于其他AI音乐系统的，可能正是这类细节设计：对用户工作流的理解、对协作场景的预判、对透明性的坚持。

未来，我们或许会看到更多AI音乐平台跟进类似功能——不是比谁生成的音频更动听，而是比谁的输出更易理解、更易传播、更易演化。

那时，我们将不再说“AI写了首歌”，而是说“AI提交了一份乐谱提案”。

而那份提案的扩展名，很可能是.md。