全名「流行音樂合約六層架構檢查器」，劉亮做的一個網頁工具，把合約丟進去，由語言模型依六個面向檢查、評分並指出缺漏。上線於 music-contract-checker.pages.dev。
它出自一次課堂導讀。《當代音樂人求生指南》第十章談音樂製作與演出合約，作者用 Who、Whose、When、Where、What、$ 六個問題系統性檢視合約，目的是讓長期處於結構性弱勢的音樂人靠合約設計避開日後的衝突。
從「說得對」到「用得到」
劉亮記下的反應不是同意或反對，是實務落差：文章說得都對，但音樂人通常很不愛簽合約，更談不上對條款的敏感度。
他的第一步是把提醒改成檢查清單，至少需要時可以快速核對。第二步他自己形容為「更懶人的做法」——乾脆讓語言模型直接對合約跑六層檢查，給評分與修改建議。工具就是第二步的產物。
這個轉換是這個專案真正的內容。原材料是一套要人記住並主動套用的框架，而他判斷「要人主動套用」正是會失效的環節，所以把框架搬進一個不需要記住它的地方。
合約作為預防性設計
他從那一章挑出來標成重點的是兩句：
合約是寫在衝突發生前的「預防性設計工具」，是未來的保命符。法律上沒有約定的，往往等同於放棄權利。
第二句是六層架構為什麼要逐項問過的理由。沒問到的層次不會停在「未定」，會直接倒向對方。
這條與動手之前先想清楚收攏的框架群是同一個主張的法律版本：前期思考便宜、後期修正昂貴。更近的對應在教父筆記本——Coppola 那本筆記的 pitfalls 欄在開拍前逐場登記「我可能怎麼把它搞砸」，合約做的是同一個動作，只是登記的對象從失敗場次換成衝突情境，而且簽名之後就有法律效力。
兩類合約的風險點
原始筆記附了兩張圖，內容是各自的風險分布。
製作合約的三個節點是製作、驗收、付錢，圖上密布警告符號的位置正是節點之間。要問的是承攬性質（專屬承攬還是單純出資）、有沒有二包以及責任歸誰、驗收期限與交付格式，錢的部分則是詞曲是否另計、分期方式與授權範圍。
演出合約的風險結構不同，關鍵在人身專屬——簽的是特定藝人與樂手，不可換人，因此排練投入的採譜、編曲與排練費全是換不回來的時間成本。時間軸往下走，取消費、不可抗力與前置費用決定演出取消時誰承擔，最後是後續利用：交付什麼檔案，以及著作權與肖像權分開授權。這一段與演唱會製作管理記的執行流程貼在一起看，剛好是同一件事的兩面，一面是怎麼把演出做出來，一面是做不出來的時候誰負責。
兩張圖都由 NotebookLM 生成，右下角有浮水印。簡報教學記過他對這項功能的評價，說它的視覺化已超越單純配圖、達到溝通層次。
定位與界線
他在筆記末尾自己畫了範圍：工具出自課堂導讀後的想法驗證，僅供初步檢視與教育用途，不構成法律意見，實際簽約前仍須諮詢律師，而 AI 評分基於文本與模型判讀，可能有遺漏或誤判。
他給的預期也不高——能修改到什麼程度看個人造化，但至少知道自己簽了一份什麼樣的合約，多少有機會對尚未發生的衝突情境進行預想與防範。
在他的工具序列裡
這是 wiki 記錄到的第三個對外上線的網頁，前兩個是LLM Wiki 入門指南網頁與滾寒宮，三個都掛在 Cloudflare Pages（見滾寒宮建站歷程）。三者的共同形狀是把自己走過一遍的流程做成別人能直接用的東西，而不是寫成文章講述流程。這一個的距離最短：從課堂讀到框架，到工具上線，中間沒有經過教學或講座。
相關原始筆記
0406/USEFUL/流行音樂合約六層架構檢查器.md— 構想、工具連結與兩張風險圖