一人做互動敘事，最容易卡住的地方不是寫程式，而是素材。劇本可以慢慢磨，程式可以一個模組一個模組補；可是畫面一旦缺背景、缺立繪、缺 CG，整個遊戲就只剩文字和黑底。那種空感很明顯。

Day19 這篇想講 AI 怎麼幫《九重燼》加速美術和音樂，但我不想把它寫成「AI 讓一切自動完成」。實際情況比較麻煩，也比較有用：AI 幫我把第一批可接入素材做出來，但規格、後製、命名、授權、接入測試，還是要自己扛。

先說邊界：AI 不是直接進遊戲的魔法入口

目前專案裡跟素材製作最相關的文件有幾份：

這些文件的存在，讓 AI 工具比較像「執行者」，不是「決策者」。我要先知道這張背景是承華殿夜雨還是迎賓夜宴、下方要不要留對話框空間、畫面裡可不可以有人、尺寸要 16:9 還是透明 PNG。這些先寫清楚，生成結果才有機會接得上專案。

圖片資產：目前登記的是 LIC-AI-IMG-001

docs/ASSET_LICENSES.md 裡目前有一筆 AI 圖像授權登記：

LIC-AI-IMG-001

它涵蓋的範圍很大：Demo P0 背景、CG、道具、角色立繪、青禾傷勢差分、缺口背景補圖、CH04 / CH05 補充事件 CG、主角醉酒與虛弱差分、皇帝病容差分，還有 portal 用的縮圖派生圖。

來源欄寫的是：

OpenAI 內建圖片生成；專案提示與後製

這句其實很關鍵。它不是「丟一句 prompt 就直接上線」，而是「生成後還要進專案處理」。授權表的細項也寫了後製內容：尺寸正規化、16:9 裁切、透明通道與色鍵邊緣整理。透明素材還用了純色色鍵，再由本機工具去背。

也就是說，AI 負責把第一版圖像做出來；專案負責把它變成可用資產。

為什麼要把 AI 圖片寫進授權表

AI 圖片很容易讓人產生一種錯覺：既然是自己生成的，就可以直接放進遊戲。實務上沒這麼簡單。

ASSET_LICENSES.md 一開始就寫得很硬：來源不明、授權不清、禁止商用或禁止修改的資產，不得進入正式版本。LIC-AI-IMG-001 目前狀態是 pending，商用欄也是「待複核」。這代表它可以拿來做 Web Demo 和內部美術驗收，但公開或商業發布前，還要複核當期平台條款和專案權利政策。

這一步很煩，但不能省。因為遊戲素材不是只在本機看一看，最後會被打包、部署、截圖宣傳，甚至可能進商店頁。授權問題如果拖到發布前才補，通常會變成災難。

我現在的做法是：只要是正式會進 public/assets 的素材，不管是 AI 生成、手工自製、外包委託，最後都要能在授權表或 manifest 裡找到來源狀態。

背景 prompt：先把畫面語言固定住

docs/BACKGROUND_PROMPTS.md 是 AI 生圖最直接的工作文件。它不是單純列場景名稱，而是先定共通規範：

Chinese ancient palace visual novel background,
cinematic composition,
no people,
no text,
no logo,
leave lower area clean for dialogue UI,
16:9

負面提示詞也寫得很具體：不要現代物件、不要車、不要 neon sign、不要 logo、水印、文字、模糊、錯亂建築。這些限制聽起來很瑣碎，但每一條都對應到實際踩過的坑。

視覺小說背景最怕兩件事。第一，畫面太滿，對話框一蓋上去就亂。第二，AI 自己塞人、塞招牌、塞奇怪文字，結果要修很久。與其每次生成後才崩潰，不如在 prompt 文件裡先把「不要什麼」寫清楚。

這份文件還要求建議規格是 1920×1080、16:9，下方 20～25% 畫面盡量乾淨。這不是美術口味問題，是 UI 需求。背景再漂亮，如果底部細節太多，對話框文字就會被干擾。

角色立繪：AI 可以畫，但規格要先管住

角色立繪更麻煩。背景只要氣氛一致就可以用，角色一旦臉變了、比例變了、配件方向錯了，玩家馬上會覺得「這不是同一個人」。

docs/CHARACTER_SPRITE_LIST.md 先定了角色立繪的規格：

• 半身立繪高 1600～2000px，透明背景。
• 全身立繪高 2600～3200px，透明背景。
• 頭身比例建議 7～7.5 頭身。
• 光源方向統一為畫面左上。
• 臉部角度以正面微側 10～20 度為主。
• 方向性道具不能因鏡像而錯置。

這些規格不是給人看的裝飾文字，而是約束生成結果的尺。AI 很擅長畫「一張看起來很漂亮的人物圖」，但它不擅長自動維持整個遊戲的角色連續性。男主的半枚鳳尾玉佩、顧清漪的軍裝輪廓、柳如煙的書卷氣，如果每張圖都長得像不同企劃案，進遊戲後就會破功。

所以我把角色製作拆成「第一批最低組合」：標準服裝搭配 neutral、smile / smirk、serious、angry 或 sad。核心角色先跑得起 Demo，再補服裝、姿勢、戰損和路線限定差分。這比一開始就追求每個角色十幾張完美圖更實際。

後製：AI 生成只是半成品

Day19 原本只寫到「AI 生成 → 專案內後製調整」，這裡可以講細一點。

圖片進遊戲前，大概會遇到幾種處理：

• 背景要裁成 16:9，並確認下方不會和對話框打架。
• CG 要跟 characters-scenes.json 裡的 ID 對上。
• 角色圖要有透明背景，否則 Pixi / DOM 疊圖會很難看。
• 道具圖要進 asset-manifest.ts，證據 UI 才能透過 asset id 找到它。
• portal 縮圖要另外產生 webp 派生圖，不能拿原圖硬塞。

授權表裡寫「透明素材使用純色色鍵並由專案本機工具去背」，就是這類工作。AI 生成圖通常不會乖乖交出完全乾淨的透明 PNG；就算工具支援透明背景，邊緣也常有雜色。這些不清掉，立繪一放到深色背景上就很明顯。

所以 AI 省掉的是「從零畫第一版」的時間，不是省掉美術管線。

接入：素材必須變成資料，不只是檔案

《九重燼》的畫面不是直接在 Vue 裡寫死圖片路徑。素材要能被劇本 tag 和資料表找到。

音訊資產在 src/data/asset-manifest.ts 裡長這樣：

bgm_001_dream_wakes_in_nine_palaces: {
  id: 'bgm_001_dream_wakes_in_nine_palaces',
  kind: 'audio',
  title: '夢醒九重宮',
  path: '/assets/audio/bgm/bgm_001_dream_wakes_in_nine_palaces.mp3',
  licenseId: 'LIC-USER-AUDIO-001',
  licenseStatus: 'pending',
}

圖片資產也是同一個思路：要有 id、kind、path、尺寸、透明資訊、licenseId、licenseStatus、chapters、tags。這樣遊戲才知道它是背景、CG、道具還是音訊，也才能在資產驗證與授權檢查時被追蹤。

這一步很容易被低估。檔案丟進資料夾只是「存在」；進 manifest 才算「能被系統使用」。

BGM：已入遊戲，但不是「全部完成」

目前 public/assets/audio/bgm 裡有 9 個 mp3 檔，其中 1 個是 placeholder.mp3，另外 8 首是實際 BGM：

bgm_001_dream_wakes_in_nine_palaces.mp3
bgm_002_rain_over_chenghua.mp3
bgm_003_blood_on_white_jade.mp3
bgm_004_emperor_question_at_midnight.mp3
bgm_006_hidden_edge.mp3
bgm_007_white_plum_old_scroll.mp3
bgm_014_foreign_banners_at_the_gate.mp3
bgm_016_words_before_the_throne.mp3

BGM 規格書：AI 工具和真人都能讀

BGM_PRODUCTION_LIST.md 開頭寫得很直接：這份文件是為了方便交給 AI 音樂工具或作曲者。

它沒有只寫「這裡要一首緊張的歌」。每首曲子都拆成：

• 用途
• 情緒
• 節奏
• 樂器方向
• 長度
• Loop 需求
• 遊戲 Asset ID
• 目前 Ink 對應

例如序章的 BGM_001 夢醒九重宮，用途是開場和標題後進入序章，情緒是迷惘、危險、宿命感，樂器方向是低音古琴、空靈 Pad、細雨環境音和低弦。這種寫法不管丟給 AI 音樂工具，還是給真人作曲者，都不會只剩一句模糊的「古風懸疑」。

我覺得這才是 AI 在音樂上的主要價值：不是替我決定音樂，而是讓規格可以快速被轉成第一版聲音。

音訊接入：還要通過 AudioManager

音樂檔進 manifest 後，還要能被遊戲播放。AudioManager.ts 裡有一層 alias：

const bgmAssetAliases: Record<string, string> = {
  opening_theme: 'bgm_001_dream_wakes_in_nine_palaces',
  palace_rain: 'bgm_002_rain_over_chenghua',
  tension_theme: 'bgm_003_blood_on_white_jade',
  emperor_theme: 'bgm_004_emperor_question_at_midnight',
  bgm_hidden_edge: 'bgm_006_hidden_edge',
  bgm_white_plum_scroll: 'bgm_007_white_plum_old_scroll',
}

這層是為了相容 Ink 裡比較語意化的 tag。劇本可以寫 # bgm:opening_theme，AudioManager 再把它映射到真正的 asset id。這樣劇本不需要記完整檔名，也比較不怕檔名改了以後整批 Ink 跟著壞。

AudioManager 還做了幾件播放層的事：BGM 雙軌 crossfade、環境音獨立通道、首次互動後補播被瀏覽器 autoplay 擋下的音樂、頁面失焦時暫停並在回來後恢復。這些和 AI 無關，但它們決定音樂能不能真的用在遊戲裡。

AI 加速的是迭代，不是責任

如果不用 AI，這個專案的美術管線大概會卡在兩個地方。第一，背景數量太多。第二，角色差分和事件 CG 會吃掉大量預算或等待時間。

AI 讓我可以先做出可玩的版本：有承華殿雨夜，有國子監，有迎賓夜宴，有角色立繪，有證據道具。它讓我能在程式、劇情、畫面之間快速對齊，而不是先等所有素材外包完成才開始接系統。

但它沒有替我解決這些事：

• 這張圖到底是不是正確場景？
• 角色有沒有跑臉？
• 圖能不能裁成 16:9？
• 透明邊緣乾不乾淨？
• 音樂能不能 loop？
• 授權能不能公開發布？
• 檔案有沒有進 manifest？
• Ink tag 能不能觸發到正確資產？

這些還是專案管理和工程問題。AI 只是把「產生第一版」這件事變快。

工作流程：先寫規格，再產素材，再接進遊戲

目前我比較認同的流程是這樣：

劇情需求
  ↓
SCENE_ASSET_LIST / CHARACTER_SPRITE_LIST / BGM_PRODUCTION_LIST
  ↓
AI 生成、裁剪音樂或委託製作
  ↓
後製：裁切、去背、壓縮、命名
  ↓
asset-manifest / characters-scenes.json / AudioManager alias
  ↓
Ink tag 觸發與實機驗收
  ↓
ASSET_LICENSES 複核

這個流程看起來慢，但它讓每一步都有可查的東西。哪天某張圖出問題，可以回到 license id；某首 BGM 播不到，可以查 manifest 和 alias；某張背景不適合放對話框，可以回到 prompt 規格修。

一人開發最怕的不是慢，而是亂。AI 會讓產出速度變快，亂起來也會更快。沒有文件管住，三天後你可能會得到一堆漂亮檔案，但完全不知道哪張能用、哪張不能用、哪張已經接進遊戲。

小結

Day19 的答案不是「AI 幫我完成美術和音樂」。比較接近的答案是：AI 幫我把素材從零推到可驗收版本，讓程式和劇情可以繼續往前跑。

真正讓它能用起來的，是旁邊那些不太浪漫的工作：prompt 規格、角色差分規格、manifest、授權表、後製、Loop 檢查、實機測試。AI 很快，但遊戲不是只要快。遊戲要能被維護、能被發布，也要在半年後回頭看時，還知道每個素材是怎麼來的。