不要把模型名稱散落在 prompt 與 action 裡

今天要解決的問題

• 不同 action 可用不同模型
• 模型角色應集中設定
• 小模型適合 render 或分類

內容

有一個很容易犯的錯，是在寫第一個 action 時順手把模型名稱打進去：ai.withLlm("gpt-4o")。當下沒問題，能跑就好。問題會在半年後浮現——換供應商、模型下架、或財務問你為什麼帳單這麼高的時候，你得在整個專案裡搜尋這個字串，然後祈禱沒有漏掉。

Embabel 的一個重要優勢是 action 粒度夠小，因此每個 action 可以依任務選模型。摘要與判斷可能需要較強模型，分類與格式化可以用較快較便宜的模型，純 Java render action 則根本不需要模型。這種細分本身就是省錢的槓桿——前提是你要有地方可以換。

LlmOptions 應該被視為工程設定，而不是 prompt 裡的一句話。模型、temperature、token 限制、成本策略都應該集中管理，方便在測試、開發與生產環境切換。

觀念圖解

模型設定最怕散落在各個 action 裡：今天改 provider，明天就要全專案搜尋字串。

比較穩的做法，是把模型名稱、base URL、API key 與角色分工放進設定層，action 只表達「我要用預設模型」或「我要用某個角色的模型」。

這樣做的好處是部署時可以換模型，測試時可以換 fake 或便宜模型，程式碼本身不用跟著環境一起改。

在 action 裡取得 LLM 的幾種方式

Embabel 透過 Ai 介面取得 LLM，從「框架自動選」到「開發者指定模型名稱」都有：

由上往下看，是「交給框架決定」逐步走向「開發者自己決定」。而最後一列的角色寫法，是本篇真正想推薦的做法。

用角色，而不是模型名稱

差別在這裡：ai.withLlm("gpt-4o") 把「我需要一個夠強的模型」這個意圖，寫死成了「我要 gpt-4o 這個型號」。而 ai.withLlmByRole("best") 保留了意圖，把型號的決定權交給設定檔：

embabel:
  models:
    roles:
      best: gpt-4o
      fast: gpt-4o-mini
      cheap: gpt-3.5-turbo

換供應商時只要改這幾行，程式碼一行都不用動。測試環境想全部指向便宜模型也只是換一份設定。這和 Spring 團隊早就熟悉的原則是同一件事——把會變的東西外部化，只是這次變的是模型。

temperature 也值得順帶一提：摘要類任務通常要低 temperature 以求一致，創意草稿才需要調高。這個參數屬於 action 的工程特性，同樣該跟著設定走，而不是寫在 prompt 裡拜託模型「請保持穩定」。

這點到了 generative UI 會更重要。當後端需要產生 UI spec 時，我們會把資料陣列交給 Java deterministic render，只把敘事文字交給 LLM。模型的任務邊界越清楚，越不容易出現空表格、數字竄改或 JSON 破碎。

程式碼補充

這一段把焦點放在設定管理，而不是啟動骨架。

設定原則要先定清楚：模型名稱、base URL、API key 與不同用途的模型角色，應該集中在設定層管理，不要散落在 action 或 prompt 裡。這樣換模型、換環境或跑測試時，才不用改一堆業務程式碼。

從前一天只借設定 record 的局部

@ConfigurationProperties(prefix = "example.activity-summarizer")
record ActivitySummarizerProperties(
    int maxWords,
    float highSpenderThreshold,
    float highTripsPerYearThreshold
) {}

這個片段的重點不是 record 語法，而是「設定集中管理」。今天談模型與環境切換時，只要抓住這個形狀：程式裡讀屬性物件，不要到處硬寫門檻值與模型名稱。

今日實作 / 思考任務

把你的 action 分成三類：必須強模型、可用小模型、不需要模型。為每類寫出 LlmOptions 管理策略。

如果你也想進一步學習如何透過 AI 開發 Spring Framework 應用，讓 AI 協助理解框架、撰寫程式、除錯與驗>證，歡迎到 Hahow 看凱文大叔的最新課程【駕馭 AI 的全端實戰養成班：從零打造企業級智慧應用系統】。一起>學習如何駕馭 AI，提升 Spring 應用的開發效率與品質。
課程連結