微調 vs 提示工程：什麼時候該用哪個
比較項目
提示工程
微調
前期投入
極低（幾小時到幾天）
中高（數週，含資料清理與訓練）
需要標註資料
幾乎不需要（少量範例即可）
需要數百到數萬筆高品質配對資料
推論成本
較高（提示詞長、可能需多次呼叫）
較低（提示詞短、行為已內化）
迭代速度
分鐘級，可即時調整
天到週級，需重訓與回歸測試
知識更新
可即時透過上下文注入
需重新訓練或改用 RAG 補足
效果上限
受限於模型原有能力
可突破原有行為分佈
可解釋性
高（看得到提示詞）
低（行為內化，難以追溯）
風險
提示注入、格式不穩
災難性遺忘、過擬合、資料洩漏
這張表已經透露了核心結論：提示工程適合「探索期」與「變動快」的場景，微調適合「穩定期」與「規模化」的場景。接下來我們把這個結論拆成可操作的判斷維度。
二、六大判斷維度：什麼情況該選提示工程？
多數團隊在專案初期都應該預設使用提示工程，原因是它的試錯成本低到幾乎可以忽略。但「預設」不等於「永遠」，以下六個維度可以幫你判斷提示工程是否還撐得住。
維度一：任務是否需要外部即時知識
如果你的任務高度依賴「最新、會變動的外部資訊」——例如客服要回答今天的活動辦法、法務要查最新修法、業務要報即時庫存——那提示工程（搭配 RAG）幾乎是唯一合理選擇。微調無法把「每天都在變的知識」有效內化，你不可能為了每天的價格變動重新訓練模型。
在這種場景下，正確做法是把知識放在外部檢索層，用提示工程定義「如何使用檢索到的內容」與「查不到時該怎麼回答」。這也是為什麼企業級應用幾乎都是 RAG 加提示工程的組合，而不是單純微調。
維度二：資料量與資料品質
微調的成效高度依賴資料品質，而且這個門檻比多數人想像的高。一般來說，要做有意義的行為微調，你至少需要數百到數千筆「高品質、一致性高、涵蓋邊界案例」的配對資料；若要做到領域深度對齊，上萬筆也不意外。而且資料必須乾淨——錯誤標註、格式不一致、彼此矛盾的樣本，會直接把模型帶歪。
相對地，提示工程只需要少量「示範級」範例就能啟動。如果你手上只有幾十筆案例、或資料散落在各部門尚未整理，那麼現階段強行微調，通常只會得到一個「看起來有學但實際不穩」的模型。先把提示工程做扎實，同時把真實使用資料累積起來，才是務實路線。
維度三：迭代速度與上線時程
如果產品兩週後要 demo、需求每週都在改、PM 明天可能就翻盤，那麼提示工程是唯一能跟上節奏的方案。它讓你可以當天修改、當天驗證、隔天回滾，不需要排訓練資源、不需要等 GPU 佇列、不需要跑完整回歸測試。
微調則是一條「有前置期」的路線：資料準備、訓練、評估、部署、監控，每一步都要時間。它適合的是「需求已經穩定、流程已經定型」的場景。很多團隊的錯誤，是在需求還沒穩定時就急著微調，結果訓練完隔週需求一改，整個模型報廢。
維度四：成本預算的分配方式
這裡要區分「訓練成本」與「推論成本」。提示工程的訓練成本近乎零，但推論成本可能較高，因為每次呼叫都要塞入長提示詞與範例，token 消耗可觀。微調則相反：前期訓練要花錢（算力、人力、標註），但上線後提示詞可以大幅縮短，長期推論成本下降。
所以判斷邏輯是：如果呼叫量小、或還在驗證階段，提示工程勝；如果呼叫量極大、且任務高度重複，微調的單位成本優勢會逐漸顯現。舉例來說，一天呼叫一萬次的內部工具，提示工程完全夠用；一天呼叫數百萬次的產品功能，微調的 ROI 就會開始被認真計算。
維度五：輸出格式與行為的穩定性要求
如果你只需要「大致正確」，提示工程通常夠了。但如果你需要「每次都以完全一致的 JSON 結構輸出、欄位不可缺漏、數值單位統一、語氣符合品牌規範」，那麼單靠提示工程的穩定性會讓你疲於奔命——你得不斷加規則、加範例、加驗證層，而且模型換版本時可能全部重來。
這種「格式與行為必須高度穩定」的需求，正是微調的強項。透過大量一致格式的訓練樣本，模型會把輸出結構內化成預設行為，你會發現提示詞可以大幅簡化，而輸出穩定度顯著提升。當然，前提是這個格式已經定案，不會再改。
維度六：模型能力邊界是否已經被試出來
提示工程有一個很實際的診斷功能：它會告訴你「模型的極限在哪」。當你把提示詞優化到極致——角色、範例、思維鏈、格式約束、few-shot 全都上了——卻仍然在特定案例上穩定失敗，這通常代表你撞到了模型的能力邊界。此時繼續在提示上打轉是徒勞的，該考慮的是換更大模型、改用 RAG 補足知識，或進入微調。
換句話說，提示工程不只是解法，也是診斷工具。它幫你確認問題的本質是「不知道」還是「不會做」：不知道就用 RAG，不會做才用微調。
三、什麼情況該考慮微調？
談完提示工程的適用邊界，我們來看不論怎麼優化提示都難以突破、必須動到模型權重的五種情境。這些情境的共同特徵是：需求穩定、資料充足、且行為需要被內化。
情境一：領域術語與風格深度綁定
某些產業的語言習慣極度特殊：醫療病歷的縮寫、法律判決的用語結構、金融商品的合規表述、製造業的工單格式。這些不只是「名詞」問題，而是整套表達邏輯。你在提示裡塞術語表，模型可能記得住字面，卻抓不到使用時機與搭配方式，輸出永遠有一股「外行味」。
這種情況下，用大量領域語料做微調，能讓模型真正「學會講話的方式」。特別是當你需要模型輸出的內容會直接面對專業客戶（例如病歷摘要、法遵文件、技術報告），風格的準確度往往比內容本身更影響信任感。
情境二：延遲與推論成本壓力
假設你的應用需要即時回應（例如語音客服、交易風控輔助），而提示工程為了達到效果，每次都要塞入三千 token 的系統提示加十個範例。這時延遲與成本都會成為瓶頸。微調可以把這些「教學內容」壓縮進模型權重，上線後只需短短的提示詞就能得到同等甚至更好的效果。
這在高頻呼叫的產品功能上尤其明顯。當呼叫量到達一定規模，微調所節省的推論成本，往往在數個月內就能攤平訓練投入。這也是為什麼不少 AI 產品在早期用提示工程快速驗證，成熟後再針對核心任務微調小模型來壓成本。
情境三：大量重複、結構固定的任務
如果你的任務是「每天處理十萬封格式類似的客服信件並分類」，而且分類邏輯已經穩定，那麼這是一個典型的微調候選。因為任務重複性高、輸入分佈集中、輸出類別固定，模型很容易從資料中學到穩定映射，訓練出來的專用模型在準確率與一致性上通常會優於通用模型加複雜提示。
這類任務還有一個好處：你可以用小模型（例如 7B 級別的開源模型）微調，推論成本遠低於呼叫大型商用 API，而且可以部署在自家環境，資料不必出門。
情境四：隱私、合規與地端部署需求
金融、醫療、政府、國防等領域，常常有一條硬規定：資料不得離開特定環境。這時你無法任意呼叫外部 API，只能使用可地端部署的開源模型。而地端小模型在未經調整的情況下，表現往往不如雲端大模型，這就需要透過微調把領域能力「補回來」。
在這類場景中，微調不只是效能選項，更是合規前提。你可以用內部資料微調出專屬模型，同時滿足資料主權與效能需求。當然，這也意味著你必須建立完整的 MLOps 流程來管理模型版本與評估。
情境五：提示工程已到天花板，且任務長期不變
最後一個情境最務實：你已經把提示工程做到極致，評估指標卻卡在一個不上不下的位置；同時，這個任務的定義在可見的未來不會改變。此時微調是合理的下一步，因為你有明確的 baseline 可以比較，有穩定的評估集可以驗證，也有足夠的時間回收訓練投資。
反過來說，如果任務定義還在變、評估集還沒建立、資料還在累積，那麼「現在就微調」通常是一種逃避——逃避把提示工程做扎實的苦工，也逃避面對產品需求還沒想清楚的事實。
四、實戰決策樹：三步驟判斷該用哪個
把前面的維度濃縮成一套可以在會議上直接使用的判斷流程。這套流程的核心精神是：先問知識，再問能力，最後問成本。
第一步：先問「模型知不知道」
如果問題的根源是「模型不知道這項資訊」——例如公司內部規章、最新產品價格、特定客戶合約條款——那麼答案不是微調也不是提示工程，而是 RAG。先用檢索把知識餵給模型，再用提示工程約束它如何使用這些知識。這一類問題佔企業應用的絕大多數，也是最容易被誤判成「需要微調」的類型。
第二步：再問「提示能不能穩定做到」
如果知識沒問題（模型本來就知道怎麼做這件事），但輸出品質不穩，先優化提示工程：補範例、拆步驟、加格式約束、建立驗證層。給自己一個明確的停損點，例如「優化兩週、評估集準確率提升不到 5%」，就表示提示工程已接近天花板，可以考慮微調。
第三步：最後問「成本划不划算」
當提示工程與微調在效果上都可行時，決策就回到成本。用三個問題快速試算：呼叫量有多大？任務會穩定多久？資料與算力資源是否到位？如果呼叫量大、任務穩定、資料充足，微調的長期 ROI 會勝出；反之則維持提示工程，並持續累積資料，等待微調的時機成熟。
決策流程速查表
你的狀況
建議方案
理由
需要回答會變動的外部知識
RAG + 提示工程
微調無法即時更新知識
需求還在變、兩週內要上線
提示工程
迭代速度最快、可即時回滾
輸出格式必須高度一致
先提示工程，穩定後考慮微調
格式定案後微調可顯著提升穩定度
領域語言風格難以用提示複製
微調
風格需內化，非規則可描述
高頻呼叫、推論成本吃緊
微調小模型
壓縮提示長度、降低單位成本
資料不得外流、需地端部署
微調開源模型
合規前提下的效能補強
提示優化兩週仍卡關
評估微調可行性
可能已達模型能力邊界
五、常見誤區與混合策略
知道「該選哪個」只是第一步，實務上更多失敗來自於對兩者的誤解。以下整理三個最常見的誤區，以及一個真正能在生產環境落地的混合策略。
誤區一：以為微調可以「灌知識」
這是最普遍也最危險的誤解。很多人以為把公司文件全部丟進去微調，模型就會「記住」這些知識。實際上，微調更適合學「行為模式」而非「事實記憶」。模型在微調過程中確實會接觸到資料內容，但這種記憶是模糊的、不可靠的，而且容易在追問時產生幻覺。
正確做法是：知識歸 RAG，行為歸微調。要讓模型知道「我們的退貨政策是 30 天」，用檢索；要讓模型學會「用我們的客服語氣回答退貨問題」，用微調。兩者分工明確，系統才會穩定。
誤區二：以為提示工程萬能
另一個極端是把提示工程當成萬靈丹，不斷在提示詞裡堆疊規則，最後寫出上千字的「咒語」，維護困難、成本高昂，而且模型換版本就全部失效。這種「提示詞技術債」在很多團隊裡悄悄累積，最終變成沒人敢改的黑盒子。
健康的做法是把提示工程視為「有紀律的工程」：建立版本控制、撰寫評估集、定期回歸測試、控制提示長度。當提示複雜度超過一定門檻，就該認真評估是否把部分邏輯轉移到微調或程式碼層。
誤區三：忽略 RAG 這條第三條路
許多「微調 vs 提示工程」的爭論，其實預設了一個錯誤的二選一框架。但在真實世界裡，最多的問題是「知識問題」，而知識問題的最佳解是 RAG。把 RAG 拉進來之後，你會發現原本糾結的許多案例，其實根本不需要微調，也不需要把提示寫到爆炸。
RAG 的優勢在於：知識可即時更新、來源可追溯、成本可控、可與提示工程無縫結合。它的限制則是檢索品質與文件切分策略，需要額外的工程投入。但對於大多數企業應用來說，這筆投入的報酬率遠高於過早微調。
混合策略：RAG + 提示工程 + 微調的三層架構
成熟的 AI 產品通常不是單一方案的勝利，而是三層架構的協作：
實務上的演進路徑通常是：先用提示工程快速驗證產品價值，同時用 RAG 解決知識問題；等產品站穩、任務定型、資料累積足夠後，再針對最穩定、最高頻的環節進行微調。這樣的順序讓每一分投入都建立在已被驗證的需求上，而不是憑空猜測。
六、實務案例：三種團隊的選擇，三種結果
為了讓抽象原則更具體，我們用三個虛構但高度寫實的案例來說明決策的差異。
案例一：新創客服機器人——先提示後 RAG，暫不微調
A 團隊是一間十人規模的電商新創，想做出能回答訂單、退貨、活動問題的客服機器人。他們一開始就問「要不要微調」，但冷靜分析後發現：問題核心是「知識會變」——活動辦法每週更新、運費規則隨地區調整。於是他們選擇提示工程搭配 RAG，把 FAQ 與政策文件放進檢索庫，用系統提示定義回答風格與轉人工規則。
結果：兩週上線，準確率達到可接受水準，且每次政策更新只需重新索引文件，完全不必動模型。他們把省下的資源拿去累積真實對話資料，為未來可能的微調鋪路。這是一個典型的「先確認問題本質」的成功案例。
案例二：壽險業理賠摘要——毫不猶豫選微調
B 團隊是壽險公司的 AI 小組，任務是把理賠申請的雜亂敘述整理成標準化摘要，供理賠人員快速審閱。這個任務有三個特徵：第一，格式極度固定（欄位、用語、順序都有內規）；第二，領域術語密集（保單條款、醫療名詞）；第三，資料不得離開公司環境。
他們的做法是：先用提示工程建立 baseline 與評估集，確認通用模型在格式穩定度上確實不足；接著用內部累積的歷史案件微調一個 13B 級別的開源模型，並部署在地端。上線後，摘要格式的一致率顯著提升，理賠人員的審閱時間下降，且資料完全留在內部。這是「需求穩定、資料充足、合規優先」三者同時成立的典型案例。
案例三：跨國 SaaS 的內容生成功能——分層混搭
C 團隊是一間跨國 SaaS 公司，產品內建「行銷文案生成」功能，服務數萬名客戶。他們一開始全部用提示工程，但隨著用戶增長，推論成本與延遲成為痛點；同時，客戶抱怨輸出風格不穩、品牌語氣難以維持。
他們最後採用三層架構：用 RAG 提供客戶的品牌指南與產品資訊；用提示工程處理多語系、格式與安全過濾；再針對「品牌語氣對齊」這個高度穩定的子任務，微調一個較小的模型來專門處理。這樣的拆分讓每一層都只做自己最擅長的事，成本與品質同時獲得改善。這是規模化之後「混合策略」的標準樣貌。
結語：問題從來不是「哪個比較好」，而是「你現在卡在哪」
回到最初的問題：微調還是提示工程？如果你的團隊還在為此爭論，不妨把問題換一種問法——我們現在卡住的地方，是模型「不知道」、還是模型「不會做」、還是模型「做得太貴」？
不知道，就用 RAG 補知識；不會做，就先優化提示，確認邊界；做得太貴或太不穩，才輪到微調上場。這個順序不是鐵律，但它符合成本效率，也符合多數團隊的資源現實。
最後提醒一句：提示工程與微調不是對立陣營，而是同一條生產線上的不同工站。真正成熟的團隊，不會把資源押在單一方法上，而是建立一套「資料累積、評估迭代、成本監控」的機制，讓方法論隨產品階段自然演化。當你能清楚說出「我們現在為什麼選這個、什麼條件下會換另一個」，你就已經超越了大多數還在爭論信仰的團隊。
希望這篇文章能成為你下次技術決策會議上的一張地圖。與其問「哪個比較強」，不如問「我們現在在哪裡、要往哪裡去」——答案自然會浮現。