生成式 AI 的終點：Higher-Order Prompting — 寫一個「會生出 prompt 的 prompt」，文字、圖片、音樂、影片生成，最後全都收斂到這個技巧。
這陣子我同時在玩：用 coding agent 寫 code、用 Design.md 鎖網站設計、用 Suno 做歌、imaging 2 生圖、Seedance 生成影像。
今天早上我想清楚一件事，每個人都該有自己的 Prompt Builder。它橋接的是「心裡已經知道要往哪去，但語彙不夠」這個 gap — 你的描述不見得精確，就算自認很精確，也不見得轉得成 AI 真的聽得懂的話。所以與其每次手寫 prompt，不如寫一個會生出 prompt 的 prompt。
下面先把四個領域各自的玩法跟心得分享一下，最後再回到開頭這句話。
一、每個生成模型，先搞懂兩件事
不管它吐的是文字、圖、音樂還是影片，要先搞懂的其實只有兩件事。
第一件是它的「讀入偏好」。 每個模型喜歡吃什麼格式、什麼結構、什麼關鍵字，都不一樣。大部分是純文字沒錯，但純文字底下還是有結構 — 有的吃逗號分隔的 tag list，有的吃完整句子，有的吃分區塊的結構化欄位。沒搞懂它的讀入偏好，就會一直卡在「它怎麼又沒聽懂」的迴圈裡。Anthropic 後來甚至把這件事從 prompt engineering 往 context engineering 推，核心精神是去想「要餵哪些高訊號、低雜訊的 context」，而不只是「我這句要怎麼問」〈Anthropic, Context Engineering, 2025〉
第二件是「Conditioning」，餵它一個參考範例。 與其每次都用純文字從零描述（通常稱作 zero-shot），不如直接丟一個參考進去讓它對齊 — 這是 one-shot，因為你給了它一個範本。文字就餵一份參考文檔或格式，音樂就餵一段參考音檔，圖片就餵一張參考圖。Suno 那些 cover、extend、reference 類的玩法很多就是往這個方向走；影像生成更明顯，常常不是只靠文字硬寫，一定是先餵一張圖，再讓模型沿著它的構圖、角色、風格去跑。
圖片這套餵參考，背後其實可以拆成不同的東西：ControlNet 比較偏姿勢、深度、邊緣、構圖這種空間控制；IP-Adapter 則比較接近把參考圖當成 image prompt，讓圖片 prompt 跟文字 prompt 一起發揮作用〈ControlNet, 2023〉〈IP-Adapter, 2023〉。
重點一直都不是我們把每個美感細節都硬寫成文字。
這兩件事，是四個領域共通的底層。剩下的差異，都是各 domain 自己的細節。
二、文字 — 文章、文案、程式碼，是三種不同的工事
有些人把「文字生成」當成一件事，但對我來說它其實是三種完全不同的工事。
文章撰寫，重點是建立自己的語氣
最有效的做法，是直接把自己過去的貼文拿去養一個 skill。我自己就是這樣搞的 — 把寫過的文丟進去，萃出語氣規則、簽名手法、禁止句型，下次寫就不用每次重新解釋「我是誰、我怎麼講話、我不要什麼 AI 味」。順帶一提，這也是反 AI aesthetic 最實際的方法：不是事後去 AI 化，而是一開始就把「我會講的話」鎖進 skill 裡。呃，但是其實沒這麼美好，直到今天，我還是要一直在事後去 AI 化。
文案撰寫，重點是 SEO friendly 跟可 reuse
標題怎麼下、關鍵字怎麼設計，這個網路上參考一大堆。但真正能累積的，是把 domain 的東西先訂死。以音樂來說，曲風、配器、製作過程、歌曲結構這些先定成模板，之後每次發新作品，文案幾乎直接套，改幾個變數就好。
程式碼撰寫，這塊現在 harness 技巧已經非常成熟
核心概念就一句：想辦法提高 first-pass 的勝率。讓 agent 第一次跑出來就接近能用，而不是來回改十次。再往後就是驗證跟擴張 — 怎麼有效驗證它寫對了、怎麼撐到大量用戶進來時不會垮，這時候 scale 跟 performance 指標要特別盯。
這塊 Anthropic 自己幾篇寫得很完整：一篇講 workflow 跟 agent 怎麼分、什麼時候該用哪個〈Anthropic, Building Effective Agents, 2024〉，一篇講 context engineering，一篇直接講 long-running agent 的 harness 怎麼設計，讓 agent 跨多個 context window 還能接續工作〈Anthropic, Effective Harnesses, 2025〉。我之前也寫過不少，這篇就不展開了，推薦去 trace 厲害的 programmer 都怎麼設計 skill / prompt 的，會很有幫助 — Addy Osmani、Garry Tann、Andrej Karpathy、Simon Willison。
三、圖片 — 先把「我要什麼」鎖死，再讓它生
圖片生成最大的陷阱，是 AI 太容易給你「泛化」的結果 — 看起來都對，但都不是你要的那個。
所以首要任務，是先知道自己要什麼。配色、字體、排版，這些先定下來。現在很多人在做這件事，我自己叫它 Design Lock。程式設計上，設計規範可以用一份 Design.md 把設計鎖住，再去做網站轉換或 App 設計，才不會一直鬼打牆來回修。
這件事其實也有規格可以參考 — Design Tokens 把 colors、typography、spacing 這些設計決策整理成可交換的 token，讓設計系統跨工具、跨平台維持一致。比較精確講，它目前是 W3C Design Tokens Community Group（DTCG）的 stable specification，還不是正式的 W3C 標準，但那個精神 — 把設計決策變成單一真實來源、避免 drift — 拿來套在 AI 生成設計上剛剛好〈DTCG Design Tokens, 2025.10〉。我自己的個人網站就是用這套，不然 AI 改著改著，風格就漂走了。
第二個關鍵是「結構化」。不同的圖片或影像模型有自己的拆法 — 鏡頭可以一區、前景背景各一區、材質自己描述出來。照模型友善的結構去餵，不一定都要寫成一段流水帳，可以看到網路上超多分享用 JSON 格式去結構化生成結果的，我覺得超厲害，腦洞大開。
最後是「逆向工程」，這招超好用：看到一張不錯的 reference，直接丟給 AI 做 description。現在的 description 都生得又長又細，從裡面反推出「我最想貼近的 style 是什麼」，再拿這些關鍵字回頭強化自己的 prompt。
四、音樂 — Style Prompt 跟 Lyric Prompt 是兩種完全不同的東西
以 Suno 為例，它其實是一個 Style Prompt 配一個 Lyric Prompt，這兩塊完全不同。
Style Prompt 得先懂 style 裡面到底有哪些東西
同樣是 Indie Folk，它的節奏怎麼跑、mood 是什麼，差一個字結果就不一樣。
現在主流做法是讓 LM 自己去建 style prompt，但 LM 要建得好，前提是它手上有料。我自己的做法是收集大量 Suno 的 case study，整理出規律，再用這些 case study 去建一個 Prompt Builder 的 library。這個 library 轉成 skill 之後，就不用每次用聊天慢慢喬，直接生出穩定的 style prompt。這種「用資料反推有效 prompt」的思路，學術上也有人專門拿 Suno、Udio 來做系統性的 case study〈Suno/Udio Prompting, 2025〉。
Lyric Prompt 的重點，除了歌詞本身還有 meta tag
寫歌詞是另一門藝術，好的韻腳會帶出好的節奏感，再配上好的旋律。這塊我會建議直接去上一門詞曲創作課，比看一百篇 prompt 教學有用。
技術上最關鍵的，是 lyric 裡支援的 meta tag。要的編曲細節，都靠 meta tag 寫進去。最難的是段落控制與配器 — 想要 airy 的 acoustic guitar、想做 ad-lib 的合音、想要 atmospheric 的 intro，這些全部都要明確寫出來，它才生得出來。
音樂一樣有逆向工程：丟一段 audio reference 進去得到 description，再反推。現在這種 audio / music understanding 的模型越來越強，像 NVIDIA 的 Music Flamingo，已經可以做到很細的音樂理解 — harmony、structure、timbre、lyrics、甚至 cultural context 都涵蓋〈Music Flamingo, 2025〉。從這種描述裡，能挖到更多 meta tag 跟關鍵字，回頭強化自己的 prompt。
五、影片 — 每個模型都有自己的「個性」
影片生成我還在累積，但有個觀察很清楚：每個模型的「個性」差很多，這其實就是第一章講的讀入偏好，在影片上特別明顯。
哪個模型偏物理模擬、哪個偏鏡頭運動、哪個吃結構化資料跟參考圖吃得特別好 — 要先知道手上這個是哪種性格，prompt 才下得準。
影片的 conditioning 大多以圖為主 — 餵一張參考圖，讓它從這張圖開始動。所以圖片那套「先把畫面鎖死」的功夫，在影片這邊一樣是基本盤。
然後是一個我覺得很值得講的實驗：有些主流影像模型，用中文 prompt 生成的效果比英文明顯好。
這不是每個模型都成立，要看它是不是中文語料、中文文化理解比較強的那種。像 ByteDance 的 Seedream 2.0，就主打 native Chinese-English 雙語生成，特別強調中文文化細節、文字渲染跟雙語 prompt 的能力〈Seedream 2.0, 2025〉。所以我現在的做法是：碰到這種模型，配上它喜歡的結構化欄位、再用中文描述，常常比硬翻成英文的效果好。
六、回到開頭那句話 — 終點是 Higher-Order Prompting
講到這裡，四個領域長得不一樣，但做的事情其實是同一件：搞懂模型的讀入偏好、用 conditioning 餵參考、再用逆向工程從好結果反推關鍵字。
但這些如果只停在「我這次調出一個好 prompt」，就太可惜了。
今天早上我想清楚一件事，是每個人都該有自己的 Prompt Builder。它橋接的是「心裡已經知道要往哪去，但語彙不夠」這個 gap — 你的描述不見得精確，就算自認很精確，也不見得轉得成 AI 真的聽得懂的話。
舉個我實際遇到的例子。我想做一個雲彩流動的畫面，直覺就是跟它說「雲彩要流動」。但自然的雲彩不可能流很快，除非在做縮時 — 問題是它兩種都被訓練過，所以你不可能每一次都記得補一句「欸不要太快」。
Prompt Builder 要做的，就是把這個約束先消化掉：我在這套流程裡就是不走縮時。於是我只要說「我要雲彩」，剩下「慢慢流動」這件事，builder 自己幫我轉換。
再往深一層 — 這些 prompt 的抽象層級，其實低到我手寫不出來。什麼 corner framing、什麼 hero composition，full detail 攤開我根本寫不出什麼阿鬼。我能給的只有 high-level 的意圖跟我的品味，中間那層又細又雜的轉換，丟給 AI 補掉。
這就是我說的 Higher-Order Prompting。學術上比較常見的名字是 meta-prompting — 一個操作在更高抽象層、用來生出別的 prompt 的 prompt。我更喜歡用 higher-order 來想它：就像 higher-order function 是「會處理 function 的 function」，higher-order prompt 就是「會生出 prompt 的 prompt」。
而這條路早就被驗證過 — APE 讓 LLM 自己生成、再挑出最好的 prompt，水準逼近人類手寫〈APE, 2023〉；DSPy 乾脆主張「programming, not prompting」，你只定義要什麼，框架自己編譯出 prompt〈DSPy, 2023〉；OPRO 則把 LLM 當成優化器去迭代 prompt〈OPRO, 2023〉。所以「把寫 prompt 抽象化、交給 AI」不是我在亂講，是一個有名字、有 paper 的家族。
我最近做音樂作品的影像就是這樣跑的：先定一個品味（我要那種七零年代嘻皮的風格），寫一個生圖 skill — 但這個 skill 不直接幫我寫 prompt，而是幫我 build 一個 prompt 的 template（它真的有一支 build_prompt 的流程，去撈一個 Hero Template），再把 template 填成完整 prompt、生圖、自動轉成真實化的畫面，最後 build motion 轉成影片。整條管線 e2e 一路接到底。
過程中會有很多誘惑，比方一直糾結「這個 skill 到底要不要寫腳本」。但我給自己的提醒是：終點是能不能轉化出你要的東西，中間途徑的多巴胺，不要被它帶走。
所以回到開頭那句 — Higher-Order Prompting 是「怎麼產 prompt」這件事的終點。再往外一圈，是「怎麼把它跑成流程」：養熟之後它會長成 Harness（開始有約束、有驗證、有 first-pass 的把關），再落地成 Workflow（一條可重複、會越跑越順的流程），最後是全自主的 AI Agent。這條路在每個領域都成立。
而且這裡有個門檻不可能忽略 — builder 寫得好不好，回到的是你的品味跟領域的通透了解。我有美感、知道東西該怎麼呈現，才寫得出這個 builder。別人 fork 得走我的 prompt，但 fork 不走我的品味。
一次性的 prompt 是 leverage， 被歸納下來的 builder 是複利， 被演化出來的自主 AI Agent 是一週工作四天的底氣