有一段時間，我幾乎把所有事情都翻譯成「要不要改模型」。
回答不夠直接，我會想是不是該上 LoRA。語氣不夠像技術助理，我也會想是不是該再訓一層。後來真的一路把 Modelfile、LoRA、partial fine-tune、merge、quantization、Ollama 全都摸過一輪之後，我才慢慢承認一件事：很多人不是不懂模型，而是把不同樓層的東西全都叫成同一件事。
這篇想做的，不是先教你打哪個指令，而是先把地圖攤開。因為只要樓層一混，後面每一步都會特別累。你可能只是想調一下說話口氣，最後卻跑進 Hugging Face 申請權限；你可能只是想讓模型少一點廢話，最後卻把一顆本來很穩的 instruct 模型訓得怪怪的。
先把整件事想成一個拍片現場
我最後最喜歡的比喻，不是把模型想成一本會回答問題的書，而是把它想成一個拍片現場。
單次請求，像演員今天臨時拿到的一段新台詞。System prompt，像導演開拍前塞給演員的角色小紙條。Template 是劇本格式，決定誰先講話、角色標籤怎麼排、哪裡算開場、哪裡算輪到模型接話。Message 或 few-shot，比較像幾段示範演出，讓演員知道這齣戲平常怎麼說話。Parameter 則更像拍攝風格設定，節奏要保守一點，還是可以放一點，重複要不要壓住。把這些東西包起來，變成一份可重複使用的設定書，就是 Modelfile。
再往下，才輪到 LoRA 或 adapter。這一層不是改台詞，而比較像改演員的肌肉記憶。最底下那層，才是 base model weights，也就是演員原本的大腦和訓練底子。
這個比喻不是為了可愛。它的實際用途是，你會比較容易問對問題。你不再問「我是不是該改模型」，而是問「我現在遇到的問題，到底是哪一層的問題」。
第一層：單次請求，是最快也最短效的控制
單次請求最容易理解，也最容易被高估。你今天在 prompt 裡寫「請先給結論，再分成原理、風險、做法」，模型可能就會很配合。你再多寫一句「請簡潔、直接、不說教」，手感又會再變一次。
這一層的優點非常明顯：快、便宜、壞了也好收。你不需要建環境，不需要下載權重，也不用擔心把模型訓歪。缺點也一樣明顯：它通常不穩，且不留下來。下一次聊天、下一個工具、下一個 client，如果沒把這段要求再帶進去，模型就會回到原本那個樣子。
所以單次請求很適合做局部控制，不適合被誤會成「模型已經真的學到了」。如果你只是想快速試一個語氣、一個格式、一個回答順序，這一層就很好用。反過來說，如果你每次都得手打同樣幾句要求，代表問題多半已經不該只停在這一層。
第二層：System prompt，比單次請求穩，但還是外層
System prompt 很容易被描述成「更高級的 prompt」，但這樣講有點太輕。它的真正價值在於，它比較像預設角色設定，而不是臨時加台詞。你可以把語言偏好、回答習慣、風格規範、禁忌行為放在這裡，例如：
- 優先使用繁體中文
- 技術問題先給結論
- 沒有要求時不要直接丟大段程式碼
- 不要亂補沒有把握的術語
這些設定很適合放在 system prompt，因為它們不像一次性的 task instruction，而比較像你希望模型長期預設帶著的傾向。
但它還是不是深層記憶。它會被長上下文稀釋，也會被 template、tooling 和底模本身的慣性拉扯。這也是為什麼很多人明明寫了很長一段 system prompt，最後還是覺得模型有點飄。問題不一定是這層沒用，而是這層本來就不是拿來解所有問題的。
第三層：Template 與 chat template，是劇本格式，不是裝飾
這一層很常被低估，尤其是第一次接觸 chat model 的人。Template 看起來像格式問題，容易讓人覺得只是包裝。但對 instruction-tuned 模型來說，格式不是表面工夫，它是輸入協議的一部分。
Llama 3.1 這類 instruct 模型有自己熟悉的 prompt format。Meta 官方文件直接提供了 prompt formats 與 chat usage 的範例，而 Hugging Face 上的 model card 也把 8B Instruct 定位成對話導向的 instruction-tuned 模型。這不是小註解，而是它到底被訓成怎麼接收輸入的關鍵前提。 也就是說，模型不是看見「人類在聊天」就自動懂。它最後真正吃到的是 tokenizer 和 chat template 整理好的 token 序列。角色標籤怎麼排，assistant generation prompt 接在哪，哪裡算一輪對話的邊界，這些都會影響結果。
這也是為什麼有些模型沒明顯報錯，但就是哪裡怪怪的。不是因為它突然變笨，而很可能是你餵它的劇本格式，跟它原本習慣的格式不一樣。這一層一錯，後面很多問題都會被誤判成 LoRA 或量化的鍋。
第四層：MESSAGE / few-shot，是示範演出，不是規章條文
有些東西不適合寫成硬規定。你只是想讓模型抓到一種說話節奏，或理解「像樣的回答」大概長什麼樣。這時候 message 或 few-shot 特別好用。
它不像 system prompt 那麼像明文規範，也不像 LoRA 那樣真的去動可訓練參數。它比較像開拍前先放兩三段 sample 給演員看，讓他抓到這齣戲平常怎麼演。這種方法對「先給結論」、「少一點空話」、「更像技術助理」這類偏好，常常很有效，而且成本遠比訓一層 adapter 低。
它的邊界也要講清楚。few-shot 很適合拿來校正風格和模式，但不適合拿來當長期知識庫，也不適合被誤認成模型真的把某個領域學會了。它還是外層，而且通常比 system prompt 更容易受上下文長度和當前任務影響。
第五層：Parameter，是拍攝風格設定，不是大腦改造
temperature、top_p、repeat penalty、context length 這些設定，一調常常就很有體感。也正因為體感明顯，它們很容易被高估。
這一層的工作，比較像拍攝風格設定，而不是改演員大腦。你可以把 temperature 調低，讓模型少一點發散；你可以把 repeat penalty 拉高，讓它少碎碎念。這些對使用感都很有幫助，但如果模型本身已經被訓歪，或 template 一開始就不對，光靠參數通常救不回來。
所以參數很重要，但它們在解的是「怎麼跑」的問題，不是「模型到底學了什麼」的問題。這兩件事一混，後面就很容易誤判。
第六層：Modelfile，是整份包裝藍圖，不只是長版 system prompt
我後來對 Modelfile 的看法整個翻過來。剛開始我也覺得它不就是比較長的 system prompt，後來才發現這個理解太淺。Ollama 的 Modelfile 可以定義 base、template、system、message、parameter，必要時還能接 adapter。它不是一張紙條，而是一整份拍片企劃書。 這件事很關鍵，因為如果你的目標是：
- 保住原版 instruct 模型的底子
- 把手感推向你想要的方向
- 但又不想太早動到權重
那 Modelfile 往往比 LoRA 更值得先碰。這不是保守，而是更接近目標。很多人其實不是需要重訓一顆模型，而是需要把 base、template、system、message 這些外層包裝得更像自己要的使用方式。
第七層：LoRA / adapter，才真正開始碰到肌肉記憶
真正開始變深，是到 LoRA 這一層。PEFT 文件把 LoRA 定義成一種 parameter-efficient fine-tuning 方法，透過在原本矩陣旁邊加上低秩可訓練矩陣，大幅降低需要更新的參數量。它的好處是，跟 full fine-tune 相比，計算與儲存成本都低很多。 如果沿用前面的比喻，LoRA 比較像是在演員原本的大腦不重練的前提下，針對某些反應模式，再掛一層新的肌肉記憶。這也是為什麼 LoRA 會比 prompt 深，又通常比 full fine-tune 便宜。
但 LoRA 最容易騙人的地方也在這裡。它看起來像漂亮的中間路，彷彿又便宜、又有感、又不太危險。實際上不是。資料太少、方向太窄、驗收太晚時，LoRA 一樣可以把模型拉進很奇怪的口音裡。你最後得到的可能不是「更像你要的模型」，而是「回答開始怪，但流程都成功了的模型」。
所以問題不是 LoRA 好不好，而是：你真的需要把這個東西寫進參數層嗎？如果你只是想調語氣、回答順序、使用手感，很多時候先從 Modelfile、template、few-shot 開始，反而更合理。
第八層：base model weights，是演員原本的大腦
再往下，就是最深的一層。base model weights 不只是語言能力，也包括知識分佈、推理底子、對 instruction 的反應習慣，以及很多很難一句話說清楚、卻真的存在的使用平衡。
尤其像 Llama 3.1 8B Instruct 這種模型，本來就不是生肉。Meta 官方明確把 Llama 3.1 分成 pretrained 與 instruction tuned 兩類，而 Hugging Face 上的 8B Instruct 也明講它是 optimized for multilingual dialogue use cases。 也就是說，你不是在白紙上畫圖。你是在一幅本來就畫得不差的作品上改筆觸。這也是為什麼我最後留下來的判準反而很樸素：想保住原版模型的聰明程度，第一優先通常不是更深，而是先少碰權重。
那到底該先改哪一層
如果把整篇壓成可以拿來工作的版本，我現在會這樣分：
- 想快速試語氣、格式、回答長短，先從單次請求開始。
- 想讓模型有比較穩的預設角色與回答習慣，先改system prompt。
- 想保住底模，但把整體使用手感往你要的方向推，先調template、few-shot、Modelfile。
- 想讓某些行為偏好更穩、更深，而且手上真的有夠乾淨、夠一致的資料，再考慮LoRA / adapter。
- 想改的是可更新、會變動的事實或文件內容，不要急著往權重塞，優先想外部記憶。
- 只有當你真的知道自己在做什麼，而且也能承擔成本與風險，才去碰base weights。
這不是宇宙真理，但它比把所有問題都翻譯成「我要不要改模型」好多了。
什麼時候不要急著上 LoRA
這篇至少要留一個反例，才不會長成漂亮地圖而已。最典型的反例就是：你只是想讓模型少一點空話、先給結論、格式更穩。這類問題如果一開始就衝進 LoRA，成本通常太高，風險也太早。這時候更好的順序往往是：
- 先把 template 與 chat format 對齊
- 再調 system 與 message
- 必要時用 Modelfile 固化外層設定
- 真的還不夠，再考慮 adapter
換句話說，LoRA 不是錯，只是太多人把它用來解不該由它解的問題。
下一篇要接什麼
只知道樓層還不夠，因為接下來更麻煩的問題是：不同樓層各自比較像哪一種記憶？什麼應該放在上下文，什麼應該放在外部記憶，什麼才值得寫進 LoRA 或權重？
那是下一篇。