過去很長一段時間，我把本地模型當成另一個聊天窗口在用——粘貼錯誤，復制答案，回到編輯器，運行測試，再復制下一個錯誤，循環(huán)往復。

這樣能用，但浪費了很多可能性。

Gemma 4吸引我的地方，不只是它是帶多模態(tài)能力的開源模型家族，有針對不同硬件配置的變體。更在于它讓我重新思考一種 setup：模型不再孤立地待在瀏覽器標簽頁里，而是嵌入本地開發(fā)工作流。

這次實驗的目標很簡單：我想要一個完全本地運行的開發(fā)助手，能跟我一起推理，能理解視覺和文本上下文，能讀取項目文件，并且在合適的時候直接操作代碼倉庫——不用把整個代碼庫發(fā)給外部服務。

為此，我搭了一套組件互相配合的棧。

核心思路是：Gemma 4 的真正價值，在于它從"盒子里的模型"變成本地開發(fā)架構的一部分。

這套棧做了職責分離。Ollama 跑在宿主機上，因為在 macOS Apple Silicon 上，這是利用本地運行時的實際路徑。界面層跑在 Docker 里。Open WebUI 是我思考、對比、檢查視覺上下文、生成輔助圖片的地方。OpenHands 是我從對話轉向行動的地方。

這種分離改變了體驗。

Google 把 Gemma 4 定位為面向不同硬件和使用場景的開源模型家族。這對本地開發(fā)很重要，因為不是所有任務都需要同一個模型。

在我的工作流里，有四項能力特別關鍵。

第一，模型尺寸變成路由決策。有時我只想快速確認一個函數，有時想要對跨模塊改動做深度 review。這是不同的任務。

第二，更長的上下文改變了模型處理代碼的方式。一個有用的編程助手需要理解代碼規(guī)范、鄰近文件、之前的決策和測試結構。

第三，agent 需要的不僅是好的文本生成。編程 agent 必須持有指令、使用工具、讀取結果、自我修正。模型重要，周圍的架構同樣重要。

第四，多模態(tài)改變了軟件任務的描述方式。有時上下文不在 .py 或 .ts 文件里，而是一張 UI 崩了的截圖、一張架構圖、一個線框、生成的素材、一張圖表，或者錯誤截圖。