一台配有 16GB 显存的机器可以顺利跑起 Gemma4 12B，但接入 Claude Code 后，模型多次触发 32000 到 65536 token 的输出超限报错。我们的判断是：本地模型部署已经不是主要门槛，真正卡住落地的，是它能否稳定承受完整工作流环境，而不只是单轮对话。

这是什么

这篇复盘记录了一次把本地模型 Gemma4 12B 接入 Claude Code 的真实失败过程。作者原本希望让本地模型承担“项目书记员”式的小任务，比如读取文档、整理状态、生成下一步建议，把更复杂的判断继续交给云端大模型。

问题出在接入后半段。Gemma4 12B 在 Ollama（本地大模型运行框架）里单独调用没有问题，但进入 Claude Code 这类 Agent（能调用工具、读取上下文、执行多步任务的 AI 工作流）环境后，开始出现超长 thinking 输出、正文循环、反复报 token 超限。即便作者额外搭了本地代理，手动注入禁用 thinking 的参数、限制输出长度、过滤内容，问题仍未真正解决。

进一步测试发现，模型在 --bare 模式下能跑，但这相当于关闭了 Claude Code 的不少默认能力，比如项目发现、插件同步、记忆和动态上下文。换句话说，模型不是完全不能用，而是“能用的条件”削弱了工作流本身的价值。

行业怎么看

这件事最值得行业注意的，不是 Gemma4 12B 表现差，而是它提醒了一个常被忽略的事实：聊天能力和工作流能力不是一回事。很多本地模型在命令行里回答几个问题看起来足够顺滑，但一旦放进真实开发环境，要面对长系统提示、工具调用、项目上下文、格式约束，稳定性要求会陡增。

这也解释了为什么不少开发者对“本地替代云端模型”始终热情很高，真正大规模落地却不多。成本确实能降，但前提是接入和维护成本不能反过来吞掉节省下来的钱。如果为了省模型调用费，却要长期维护代理、脚本、兼容层和异常处理，企业未必算得过来这笔账。

当然，也有反对意见认为，这更像是 Claude Code 与 Ollama 兼容接口之间的适配问题，不完全代表本地模型天然不适合工作流。这种看法有道理。风险在于，哪怕问题出在接口层，企业在采购和部署时也得为这类“最后一公里”负责；兼容性不稳定，本质上仍然是交付风险。

对普通人的影响

对企业 IT：如果公司正在评估本地部署大模型，这个案例提示我们，验收标准不能只看“模型能否跑起来”，还要看它在内部工具链中是否稳定、可维护、可回滚。

对个人职场：对用 AI 辅助开发、写文档、做流程管理的人来说，短期内云端模型仍然更省心。本地模型更像“有潜力的替补”，但离稳定接管日常工作还有距离。

对消费市场：这会影响市场对“个人电脑跑大模型”的预期。硬件性能在进步，但普通用户真正买单的不是能跑，而是能不能无痛接入现有软件、稳定完成任务。