做七個提示詞生成器的筆記

今年二月到四月之間，我在 PromptCraft 上線了七個提示詞生成器——那是一種在瀏覽器裡跑的小工具，會依照一組結構化的輸入，替某個特定 AI 模型組出一段能用的提示詞。先是 Midjourney，然後是 Flux，接著是 Stable Diffusion、Suno，再來是聊天模型生成器（ChatGPT／Claude／Gemini），然後是影片（Sora／Veo／Kling／Runway／Pika），最後是 Ideogram，它專門處理把文字放進圖裡這件事。

七個，比我原本預期做的還多。我想把學到的東西寫下來，一半是為了自己記得，一半是因為這些心得，跟我一開始以為會學到的，其實不太一樣。

第一個是最簡單的。 這聽起來很反直覺。第一個不是應該最難嗎？畢竟模式是你從頭發明的。但以我的經驗來說，不是。第一個生成器之所以最簡單，是因為你還不知道模型與模型之間差異有多大，所以你只針對*那一個模型*去做。你做的假設剛好都成立，很快就能上線。痛苦是後來才來的。

第二個才是真正的工作開始的地方。 做完 Midjourney 之後坐下來做 Flux 生成器時，我的第一個念頭是：把 Midjourney 的程式碼複製過來、換幾個標籤，就搞定了。這個念頭是錯的。Flux 的提示詞文法有實質上的不同——它更看重自然語言的措辭，不用 Midjourney 那套參數語法，負面提示詞的行為也不一樣。等我把程式碼移植完，其實等於整個重寫了一遍。而在重寫的過程裡，我注意到 Midjourney 生成器裡那些內建的假設，*根本不是關於 Midjourney 的*——它們只是我第一次隨手做出來的方式而已。真正的抽象化工作，就發生在這裡。不是在第一個，是在第二個。

等你做到第三、第四個，抽象化就開始反過來扯你後腿。 做到 SD 生成器的時候，我有個瞬間想把前面三個合併成一套共用的 schema，結果這個 schema 為了容納各模型自己的功能，不斷長出可選欄位。大概搞了一小時後，我把合併的成果全刪掉，回頭讓每個生成器各自當一個獨立元件、配自己的樣板檔。抽象化讓程式碼變糟了，不是變好。生成器從外面看很像，但*它們讓使用者選什麼*——這個結構是真的因模型而異的。硬把它們塞進一個共用的形狀，付出的代價比省下的還多。

音樂比圖片難。 這讓我很意外。我原本以為音樂生成器（Suno）會比圖片生成器簡單，因為輸入的空間比較小——「風格」的軸比較少、沒有長寬比之類的。錯了。音樂有長度、結構（主歌／副歌）、速度、調性、配器、情緒、曲風、人聲風格，還有歌詞內容，而且這些大多會互相牽動，那種牽動是圖片模型裡找不到對應的。Suno 生成器最後變成七個裡面最複雜的一個。它花掉的時間是我估計的兩倍。

影片主要是長寬比的接管線工作。 這是反過來的意外。我本來以為影片會是最難的——維度比圖片多、還要處理運鏡等等——結果它主要是在處理預設值和長寬比。影片模型之間共用的結構，比不共用的多。一個生成器只要把各模型的預設值換一換，就能同時吃 Sora、Veo、Kling、Runway 和 Pika。

文字入圖是自成一格的類別。 Ideogram 是第七個生成器，而它是真的不一樣。大多數圖片模型都不太會可靠地把文字渲染出來；Ideogram 的整個賣點就是它做得到。所以這個生成器最主要的輸入不是主題——是文字內容，然後再拿風格和排版的選項把它包起來。做這個逼我重新去質疑那套輸入排序的模式，那套我前面已經沿用了六次的模式。這很有用。它揭穿了一個我根本沒意識到自己在做的假設。

累積下來的心得是：別相信你第一個生成器的結構就是對的結構。先做個幾個，把它們並排放在一起看，再決定到底有什麼（如果有的話）是真的共用的。大部分表面上的共通性都是表象。真正深層的共通性在於*流程*——輸入、預覽、複製、再跑一次——不在於*欄位*。

兩個月做七個生成器，這個速度我是撐不久的。第八個大概會花更久，因為底層的複雜度已經比較接近浮上檯面了。但這個速度在維持得住的期間是有用的，因為它讓我在還沒對任何一種架構過度投入之前，就先看到了跨多個模型的模式。要是我只做一個生成器、然後花六個月去打磨它，我現在的處境會比實際上更糟。

有時候對的做法，是在兩個月內上線七個不完美的東西，而不是花六個月做一個完美的東西。尤其是當你還在搞清楚「完美」到底是什麼意思的時候。