AI 音樂先做提示堆疊

把 AI 音樂拆成可直接複製的提示堆疊，先定義工作，再生成、編輯、控管。

我跟 AI 音樂工具磨了好一陣子，老實說，一直有種卡卡的感覺。不是它不能出聲音，而是它常常只會出「看起來很厲害」的東西：前十秒像回事，後面就散掉；或者你問它要改哪裡，它只會繼續裝懂。這種東西拿來 demo 很爽，拿來做工作流就很煩。你不是缺一個播放鍵，你是缺一套能反覆修、能交付的做法。

我後來回頭看 Wikipedia 的 Music and artificial intelligence，才發現問題其實很清楚。它把這件事拆成生成、分類、推薦、表演、深偽風險，不是把所有 AI 音樂混成一鍋。這點很重要，因為我也常看到團隊一上來就說要做「AI 音樂」，結果其實只是想做短影音配樂，完全不是同一件事。

先別談 AI 音樂，先講你到底在做哪種工作

“Music software utilizes artificial intelligence to generate, classify, or recommend music.”

翻譯一下就是：AI 音樂不是一個東西，它是好幾種不同任務硬被塞進同一個名字裡。生成旋律、推薦歌單、分類曲風、混音、聲音仿冒，這些都沾到 AI，但控制方式完全不同。你如果不先定義任務，後面選工具、選模型、選 prompt，全都會歪掉。

我最常看到的錯誤，是大家把「想要一段能用的配樂」誤認成「要做音樂生成研究」。其實不是。前者更像產品問題：要多長、什麼情緒、能不能剪、能不能匯出、授權怎麼算。後者才會碰到作曲結構、和聲走向、節奏建模。你不先分清楚，最後只會拿一堆不相干的工具互相比爛。

我自己的做法很土，但有效：先寫一句任務定義，再碰模型。像是「我要 30 秒、適合產品開場、不要人聲、要能切成三段」；或是「我要根據既有曲庫做相似推薦，不是新作曲」。這樣一來，你評估的是對不對題，不是誰 demo 比較會演。

實操上，我會先把 AI 音樂需求分成四類：

• 生成：要新素材，重點是風格與結構。
• 編輯：要改現有素材，重點是可控與局部重生成。
• 推薦：要找相似內容，重點是排序與偏好記憶。
• 風險控管：要辨識仿冒或來源，重點是 provenance 與標記。

這四類不要混在同一個 prompt 裡，不然你會得到一個什麼都像、但什麼都不能交差的結果。

規則式系統雖然老派，但它教了最重要的一課

“In the 1950s and the 1960s, music made by artificial intelligence was not fully original, but generated from templates that people had already defined and given to the AI, with this being known as rule-based systems.”

這段我很喜歡，因為它很誠實。早期的 AI 音樂不是在追求神祕感，它是在追求可預測。人先寫規則，系統照規則跑，輸出就不會飛掉。聽起來很笨，但笨有時候才是能上線的東西。

現在很多團隊剛好反過來：一開始就想讓模型「自由發揮」，然後再努力把控制權搶回來。結果做半天，最後還是得加硬規則。這不是你技術不夠，是你順序錯了。先把能鎖死的東西鎖死，才有空間讓模型去補細節。

我以前做一個簡單的配樂原型時，就踩過這坑。最初想直接讓模型吐完整曲子，結果每次生成都像在不同宇宙。後來改成先固定 BPM、調性、段落數、樂器編制，模型只負責補旋律與裝飾，整個東西立刻可用很多。這就是規則層存在的理由：不是為了限制創意，是為了讓創意不會失控。

實操寫法很直接：

• 用程式鎖住 key、tempo、duration、section count。
• 把 instrumentation 當成硬限制，不要讓模型自己亂選。
• 保留 deterministic fallback，生成失敗時至少還有能交付的版本。

如果你在做產品，別把所有控制都丟給模型。模型負責變化，規則負責邊界。這樣才像工作流，不像抽卡。

符號式輸出最適合拿來做真正的編輯

“Symbolic music composition”

符號式音樂就是 note、duration、velocity、chord、structure 這些可讀的東西，不是原始音訊。這種輸出我一直比較喜歡，因為它像程式碼一樣能檢查、能 diff、能局部修改。你可以知道到底哪個音變了，而不是只聽到「好像有改，但不知道改了什麼」。

如果你的使用者是作曲人、編曲人、或需要跟 DAW 接的人，我會優先選這條路。因為他們要的是控制，不是只聽一個漂亮成品。MIDI、MusicXML、note-event schema 這些格式雖然沒那麼炫，但很實際。你可以接進 Google Magenta 這類專案，也可以自己做轉換管線。

Wikipedia 提到的 Continuator 很有意思，因為它不是要取代人，而是接住人的一句話。這個思路我覺得一直都對：AI 音樂最有用的地方，不是一次生出整首歌，而是接著你已經寫好的東西往下走。

我之前做過一個和弦草稿工具，最早也想直接做音訊生成，結果編曲的人嫌它太難修。後來改成符號式輸出，讓他們能改 bass line、換 voicing、只重生 bridge，整個接受度差很多。原因很簡單：他們看得到，也改得動。

實操上，如果你想讓工具真的可用，請把 prompt 寫成結構指令，不要只寫情緒詞：

• 指定段落：intro、verse、chorus、bridge、outro。
• 指定密度：每小節音符數、重複比例、休止比例。
• 指定範圍：音域、和聲走向、禁止過度轉調。

你越能把輸出變成可編輯資料，這工具越不像玩具。

音訊模型很適合抓 vibe，但不適合做外科手術

“Audio-based music generation”

音訊生成之所以吸引人，是因為它很像成品。你打一段文字，幾秒後就有聲音，這件事很容易讓人上頭。但問題也很快出現：你想只改鼓、只改副歌、只改 bass，通常沒那麼順。原始音訊是整體渲染，天生就比較難做精準修補。

像 Suno、Udio 這類 text-to-music 工具，最強的是快、是爽、是讓非音樂人也能立刻生出東西。這是真的。我不會裝清高說它沒用；它超有用，只是用途要講清楚。拿它做靈感發散、情緒探索、短片草稿，很合理。拿它當唯一交付來源，就很容易翻車。

我自己的判斷是這樣：音訊模型適合當 ideation engine，不適合當終稿機器。先生成 5 到 10 個版本，挑一個 energy 對的，再去做 remix、分軌、或重建。這樣比較像工作，不像賭博。

如果你真的要把音訊模型放進 production，我建議至少加兩層東西：

• stems 或 separation，讓你能局部調整。
• 版本管理，讓你知道哪個 prompt 產生哪個結果。

不要把「聽起來不錯」誤認成「可交付」。這兩件事差很多，差到最後常常是法務先醒，不是你先醒。

推薦系統其實才是大多數產品最需要的 AI 音樂能力

“AI music in music software can generate, classify, or recommend music.”

這句話我想多講一次，因為很多團隊都錯把生成當主菜。實際上，很多音樂產品根本不需要新歌。它們需要的是「下一首放什麼」、「這段素材跟哪個更像」、「這個使用者偏好什麼」、「這個場景適合哪種情緒」。這些都是推薦問題，不是作曲問題。

推薦系統的價值很低調，但很實際。它靠 embedding、相似度搜尋、偏好回饋、排序模型，把使用者從找不到東西的狀態拉出來。這種功能不會像生成那樣容易被拿去拍影片，但它常常更接近真實需求。尤其當你的曲庫一大，沒有機器幫忙，人工整理會先爆掉。

Wikipedia 也提到 conversational agents 和 voice-controlled playback，這其實是在提醒一件事：很多人要的不是創作，而是更好地找到、控制、組合內容。你讓使用者說「給我更冷一點、但不要太空」，本質上還是在做推薦，只是包了一層自然語言介面。

我見過不少團隊把時間花在生成器上，結果真正卡住的是搜尋。後來一改成先做相似搜尋、風格聚類、偏好記憶，產品立刻好用很多。因為使用者不是每次都想從零開始，他們多半只是想快一點到達某個方向。

實操寫法：

• 先做曲庫 embedding，再做相似搜尋。
• 把使用者的 skip、收藏、重播當回饋訊號。
• 用自然語言包裝排序結果，但底層別只靠 prompt 瞎猜。

如果你的產品場景是發現與選擇，推薦通常比生成更先救命。

深偽風險不是附帶問題，是設計起點

“Musical deepfakes”

這段最不浪漫，但最不能跳過。只要 AI 能模仿聲音、風格、甚至某個人的唱腔，問題就不只是「做得像不像」，而是「有沒有授權」、「來源能不能追」、「出事怎麼處理」。如果你把這當小事，最後通常是別人來幫你補洞。

我真的很不喜歡有些產品把 voice cloning 當成酷炫功能，卻不先處理 consent。這種做法很短視。你可以做，但你要先知道來源、授權、模型版本、prompt 歷史，還有誰能撤回。這不是道德裝飾，是基本營運。

Wikipedia 提到像 “Heart on My Sleeve” 這類案例，其實已經把問題講得很明白了：平台會開始標記、過濾、下架，因為這不是理論題，是正在發生的內容風險。你如果做的是面向創作者或品牌的工具，更不能把 provenance 當可選項。

實操上，我會把這些欄位直接做進系統：

• source audio / source dataset
• model version
• prompt 與 edit history
• consent flag
• synthetic label

如果你要上線，請把這些當成預設欄位，不要等出事才補。音樂 AI 一旦碰到仿冒，處理方式就不是「功能修一下」而已，而是整個信任模型都得重做。

真正能交付的，是人機一起修的流程，不是一次生完就算

“Interactive composition technologies that respond dynamically to live performances.”

我最想要的 AI 音樂系統，其實不是一個會自己唱歌的黑盒子，而是一個會回應、會讓人接手、會讓人修的流程。也就是說，AI 不該是最後一棒，而是中間那個很會出草稿、但還是要人盯著的夥伴。

這也是 Wikipedia 那篇最有價值的地方：它一直在暗示 hybrid workflow。不是純人，也不是純機器，而是互相回饋。人先定方向，模型出幾個版本，人再挑、再改、再鎖定。這種流程才真的像 production。

我自己最常用的方式很簡單：先讓模型給 3 個方向，刪掉 2 個，保留 1 個有感覺的片段，再進行局部重生。這比叫它一次吐完整首歌更有效，因為你保留了人的判斷，也保留了模型的速度。

實操上，工作流要有這幾個控制點：

• prompt 可改。
• seed 可固定。
• 段落可鎖定。
• 只重生局部，不要每次整首重來。

如果你想把 AI 音樂做成真的工具，不要問「怎麼讓它更會作曲」。先問「怎麼讓人更好地修它」。這個順序一換，很多問題就會少一半。

可抄的模板

# AI 音樂提示堆疊模板（可直接複製改寫）

## 1) 先定義任務
- 任務類型：生成 / 編輯 / 推薦 / 風險控管
- 使用者目標：草稿 / 續寫 / 局部修改 / 找相似 / 標記來源
- 輸出形式：MIDI / MusicXML / WAV / stems / 排序結果
- 控制層級：低 / 中 / 高

## 2) 寫死硬限制
- 調性：{key}
- 速度：{BPM}
- 長度：{seconds}
- 段落：intro / verse / chorus / bridge / outro
- 編制：{instruments}
- 音域：{range}
- 禁止項：{forbidden_elements}

## 3) 生成提示詞
請為 {use_case} 生成一段 {genre/style} 的音樂。

要求：
- 結構要清楚：{structure}
- 重點放在：{emotion / energy / clarity / repetition / variation}
- 不要出現：{avoid}
- 如果是符號式輸出，請回傳可編輯的 note event。
- 如果是音訊輸出，請回傳 3 個版本：主版本、較穩版本、較強烈版本。

## 4) 編輯提示詞
請只修改以下區段：{section}

保留：
- {keep_1}
- {keep_2}

修改：
- {change_1}
- {change_2}

不要重寫整首，只做局部重生。

## 5) 推薦提示詞
根據下列曲目或素材，找出 10 個相似項目：
- 相似條件：{mood / tempo / instrumentation / genre}
- 排除條件：{exclude}
- 回傳欄位：title / similarity_reason / tags / confidence

## 6) 風險與 provenance
- source_audio_logged: yes/no
- model_version_logged: yes/no
- prompt_history_saved: yes/no
- consent_required: yes/no
- synthetic_label_applied: yes/no

## 7) 人工審核清單
- 旋律可用嗎？
- 結構有沒有跑掉？
- 能不能局部修改？
- 有沒有授權或仿冒風險？
- 能不能匯出到 DAW？

## 8) 最後輸出
- export_format: {WAV / MP3 / MIDI / MusicXML}
- version: {v1 / v2 / v3}
- notes: {human_review_notes}

這份模板我會直接拿去改，不會先問模型「你覺得怎樣」。因為真正有用的，不是它會不會講好聽話，而是你能不能把它塞進一個可控、可修、可交付的流程。

這篇的拆解基礎來自 Wikipedia：Music and artificial intelligence，以及它連到的 Google Magenta、MuseNet、Suno、Udio。模板是我整理的，觀點是從原始條目和相關專案衍生出來的。