过去很长一段时间，我把本地模型当成另一个聊天窗口在用——粘贴错误，复制答案，回到编辑器，运行测试，再复制下一个错误，循环往复。

这样能用，但浪费了很多可能性。

打开网易新闻 查看精彩图片

Gemma 4吸引我的地方，不只是它是带多模态能力的开源模型家族，有针对不同硬件配置的变体。更在于它让我重新思考一种 setup：模型不再孤立地待在浏览器标签页里，而是嵌入本地开发工作流。

这次实验的目标很简单：我想要一个完全本地运行的开发助手，能跟我一起推理，能理解视觉和文本上下文，能读取项目文件，并且在合适的时候直接操作代码仓库——不用把整个代码库发给外部服务。

为此，我搭了一套组件互相配合的栈。

核心思路是：Gemma 4 的真正价值，在于它从"盒子里的模型"变成本地开发架构的一部分。

这套栈做了职责分离。Ollama 跑在宿主机上，因为在 macOS Apple Silicon 上，这是利用本地运行时的实际路径。界面层跑在 Docker 里。Open WebUI 是我思考、对比、检查视觉上下文、生成辅助图片的地方。OpenHands 是我从对话转向行动的地方。

这种分离改变了体验。

Google 把 Gemma 4 定位为面向不同硬件和使用场景的开源模型家族。这对本地开发很重要，因为不是所有任务都需要同一个模型。

在我的工作流里，有四项能力特别关键。

第一，模型尺寸变成路由决策。有时我只想快速确认一个函数，有时想要对跨模块改动做深度 review。这是不同的任务。

第二，更长的上下文改变了模型处理代码的方式。一个有用的编程助手需要理解代码规范、邻近文件、之前的决策和测试结构。

第三，agent 需要的不仅是好的文本生成。编程 agent 必须持有指令、使用工具、读取结果、自我修正。模型重要，周围的架构同样重要。

第四，多模态改变了软件任务的描述方式。有时上下文不在 .py 或 .ts 文件里，而是一张 UI 崩了的截图、一张架构图、一个线框、生成的素材、一张图表，或者错误截图。