我最近在做一件事：測試本地模型能不能拿來寫部落格文章。

背景很簡單。三月底 Claude Code 出了 prompt cache bug，加上尖峰限速和優惠期結束，三重疊加讓我開始認真評估本地備案。我原本的計畫是等 M5 Max 128GB 開賣後跑 Qwen3-72B，但四月初 Google 發布了 Gemma 4，Apache 2.0 授權、MLX 原生支援、26B MoE 的 active 參數只有 3.8B 卻號稱能跟 20 倍大的模型競爭——我決定先拿手邊的環境試試看。

實驗設計

我用 LM Studio 跑 Gemma 4 26B MoE，接了 DuckDuckGo 的 MCP server 讓它有搜尋能力，然後給它一個題目：寫一篇關於最近某個 YouTuber 徵才爭議的文化觀察文章。

這裡要先說明一件事：這跟我平常寫文章的方式不一樣。我平常的流程是我自己有觀點和立場，用 AI 協助執行——搜尋資料、整理結構、校對文字，但論述的方向是我決定的。這次實驗的重點在於：我刻意讓 Gemma 4 全自動處理——從搜尋到生成全文都交給模型，我只做最後的校對——看看完全不介入的情況下，本地模型的輸出品質到底在什麼水準。

三層問題

文章發出去之後，我把它丟到 claude.ai 請 Claude 幫我檢查。結果一次抓出三個問題：

第一個是印地文混入。一段正常的中文裡突然出現了「इंपॉर्टेंट」，這是印地文的 "important"。我自己校對過一次完全沒發現——因為它混在中文段落裡，視覺上就是一小截亂碼，快速瀏覽很容易跳過。對我來說，這種錯誤特別致命：我是單指打字，逐字校對的時間成本非常高。

第二個是同音字。「標籤」寫成「標驗」、「鑰匙」寫成「鑰決」。這在中文語境下完全說不通，但模型選錯了字。

第三個才是最根本的問題。整篇文章的邏輯是反的——它不是「觀察到現象然後提出觀點」，而是「先有學術框架然後把事實塞進去」。文化資本、注意力經濟、扁平化，每個概念都被放在看起來正確的位置上，但沒有一個是因為「我真的看到了什麼」才出現的。

我之前寫過一篇「你的文章沒有靈魂，不是 AI 的錯」，說的就是這種現象——當你完全交給模型自己處理，沒有人的觀點在裡面驅動，就會得到這種結果。而這次實驗正好證實了這件事。

排除 DDG

這時候一個問題浮現：印地文到底是模型的問題，還是 DDG 搜尋結果的問題？

DDG 的設計哲學是不追蹤、不個人化，代價是搜尋結果更全球化、不做地區過濾。如果搜尋結果裡混入了印度來源的網頁，context 中出現了 Devanagari 字元，Gemma 4 在 140+ 語言上訓練過，被觸發語言切換就很合理。

我做了對照實驗：拔掉 DDG MCP，手動整理好所有事實素材（新聞報導的重點、前員工爆料的具體內容、法律面的規定），直接貼進 LM Studio 讓同一個模型寫。

結果很明確。印地文消失了。同音字還在（「分鐘」寫成「分種」、「淋漓盡致」寫成「淋漓盡進」），但語言污染的問題確實是 DDG 造成的。

而且不只是語言污染。拔掉 DDG 之後，文章的寫作風格也改善了——雖然對稱的小標題和兩面討好的毛病還在，但至少每個論點都有素材支撐，不再是空中樓閣。我的假設是：DDG 搜尋結果裡本身就包含了其他媒體的「分析式報導」，模型在做 in-context learning 的時候直接模仿了那些報導的框架堆砌風格。等於搜尋工具不只帶來了語言污染，還帶偏了寫作邏輯。

26B vs 31B

確認 DDG 的問題之後，下一個問題是：模型本身的天花板在哪裡？

Gemma 4 有兩個適合本地跑的尺寸——26B MoE 和 31B Dense。我查了官方 model card 的 benchmark，大部分指標兩者差距不大（MMLU Pro 差 2.6%、AIME 差不到 1%）。但在需要深度推理的項目上，差距就拉開了：Codeforces ELO 差 432 分、BigBench Extra Hard 差近 10%、長 context 理解差了 22 個百分點。

26B MoE 的結構是 128 個 expert 取 8 個，active 參數只有 3.8B。這代表它在生成每個 token 時能調動的計算量非常有限。我看到的那些問題——兩面討好、結構對稱、不敢選邊——某種程度上就是「推理預算不夠」的表現。它沒有足夠的算力去判斷「這段該不該寫」，所以預設全部都寫、兩邊都講，這樣最安全。

31B Dense 在我目前的 M5 32GB 上可以跑 4-bit 量化（約 18-20GB），但會很緊。等 M5 Max 128GB 就完全沒壓力，甚至可以跑更高精度。

結論

這次實驗讓我學到幾件事。

搜尋工具不是接了就好。 DDG MCP 在這個場景下是淨負面——它同時降低了輸入品質和增加了干擾。如果要讓本地模型接搜尋，引擎的地區過濾能力很重要。我計畫在 Proxmox homelab 上自架 SearXNG，用 Google 後端、地區鎖定台灣繁體中文，然後再跑一次對照。

繁體中文的精確度是 Gemma 4 的先天限制。 同音字問題在兩次實驗裡都出現了，跟搜尋工具無關。這是訓練資料中繁體中文比重不足的結果，短期內不會改善。

寫作品質不只是素材的問題。 即使給了完整的事實素材，Gemma 4 的 instruction tuning 還是傾向框架先行、概念堆砌。你可以用 system prompt 去壓制，但你在對抗模型的預設傾向，效率不高。

本地模型的分工要更精確。 程式碼、結構化任務（JSON extraction、function calling）、快速草稿——這些是 Gemma 4 26B MoE 能勝任的場景。但需要繁體中文精確度和寫作判斷力的任務，目前還是得留在雲端。至少在 31B Dense 經過完整測試之前，我不會改變這個判斷。

最後一點感想：做這個實驗的過程本身就很有價值。不是因為找到了答案，而是因為它讓我知道問題出在哪一層。DDG 的污染是可修復的，同音字是可校對的，但寫作哲學的差異是模型層面的，不是工具能補的。知道這個邊界在哪裡，比盲目地全部自動化或全部放棄，都要有用得多。