夜雨聆风ai-context 的更新、dev-session-guard 的上下文维护。这些任务本质上像项目书记员的活儿：读取事实源，整理状态，更新记录，最后人看 diff 决定是否 commit。不是高风险代码修改，错了可以回滚；也不是复杂产品决策。
理论上很适合本地模型。
我期待的模型分工是这样的：
本地模型：小任务、文档型、非决策类DeepSeek：大任务、判断型、复杂分析Codex：工程执行、UI 还原、代码落地
如果可行，日常开工、收工、上下文整理都可以丢给本地模型，只有复杂问题才切回 DeepSeek。
我的机器条件不差：i7-14700KF、48GB 内存、RTX 5060 Ti 16GB 显存。选 gemma4:12b，不大不小，理论上刚好卡在合适的位置。
但真正接入 Claude Code 完整模式之后，问题一个接一个暴露出来。
问题一：thinking 输出爆炸
部署本身很顺利。Ollama 安装，模型放 D 盘，拉取 gemma4:12b。遇到过网络 EOF、TLS handshake timeout，但断点续拉后成功。CLI 调用正常返回。
之后通过 CC Switch 把 Ollama 作为 Claude provider 接入 Claude Code。
链路是通的——但 Claude Code 里输入一个很简单的问题后，直接报错：
API Error: Claude's response exceeded the 32000 output token maximum.把输出上限提高到 65536，依然报同样的错。
问题不是上限太小，而是 gemma4:12b 在 Ollama 的 Anthropic 兼容接口下会返回 thinking content block。Claude Code 的系统提示、工具说明、项目上下文都很长，模型被诱发生成超长 thinking。
普通 Ollama chat API 可以 {"think": false}，但对 /v1/messages 的 Anthropic 兼容接口无效——需要传 {"thinking": {"type": "disabled"}}。问题是 Claude Code 不会自动帮你传。
问题二：加了代理，正文开始循环
于是写了一个本地代理，在 Claude Code 和 Ollama 之间做转发：
Claude Code / CC Switch→ http://127.0.0.1:11435（代理）→ http://127.0.0.1:11434（Ollama）
代理自动注入 thinking.disabled、截断 max_tokens 到 2048、加反重复提示、过滤 thinking block。
代理日志看起来一切正常。但 Claude Code 完整模式下仍然出问题：
PleasePleasePleaseAPI Error: Claude's response exceeded the 65536 output token maximum.
这时已经不是 thinking 泄漏了。模型在 Claude Code 完整系统提示、插件、项目上下文下，正文输出也开始失控。
问题从"少传了一个参数"变成了"这个模型面对完整 agent 环境时不够稳定"。
问题三：--bare 能用，但项目能力被砍掉
继续测试发现，加 --bare 参数可以成功：
claude-p"OK"--bare--modelgemma4:12b但不加 --bare，同样走代理，仍然复现 65536 报错。
--bare 可以绕开 Claude Code 的一部分默认上下文，让模型稳定下来。但代价是大量默认能力被跳过——自动项目发现、插件同步、hooks、LSP、memory、动态上下文。虽然后来通过 --add-dir 恢复了项目 skills，但走到这一步，事情已经变味了：
为了让本地模型稳定，需要本地代理、参数注入、固定启动脚本、额外 add-dir，还失去了热切换模型的便利。原本要的是"低成本维护工作流"，结果变成了"为了让模型能工作，不断维护另一套接入工程"。
这和最初的目标是冲突的。
裸聊可用 ≠ Agent 可用
这次探索最重要的收获：
本地模型裸聊能用，和它能不能进入 Claude Code 完整工作流，是两回事。
模型能回答"OK"，只能说明它作为聊天模型可用。但要成为 Claude Code 后端，它需要承受的是：
长 system prompt
tools 协议
skills 机制
项目上下文
streaming 输出
多轮状态
文件读写
agent 行为约束
这些东西叠在一起后，模型要做的不只是"回答问题"，而是稳定地遵守协议、控制输出、理解工具调用、不要循环、不要被复杂上下文带偏。
gemma4:12b 在普通聊天下没问题，但在 Claude Code 完整模式下没扛住。不是硬件失败，不是部署失败——是工作流适配失败。
模型分层的思路仍然成立，但有一个前提
模型按任务分层这个思路我没有推翻：
小任务、文档型、非决策类 → 便宜模型大任务、判断型、复杂分析 → DeepSeek工程执行、UI 还原、代码落地 → Codex
但这次补上了一个关键前提：
便宜模型必须能稳定承载当前 agent 壳。
如果模型在 Claude Code 完整模式下连输出都控制不住，那它再便宜也不能进入日常工作流。省下的模型成本，会变成更多排障成本、等待成本和心智负担。
这恰恰违背了引入本地模型的初衷。
及时停下来，回到主线
最终我清理了本地环境：
删除 gemma4 模型停止 Ollama 和本地代理清除相关环境变量卸载 Ollama
没有动项目里的 skills，也没有直接编辑 CC Switch 内部数据库，避免误伤其他配置。
这不是否定本地模型。
本地模型会继续演进，尤其是 Qwen3-Coder 这类更面向 agentic coding 的模型值得关注。
但对我来说：
工具探索只能服务主线，不能反过来吞掉主线。
如果以后还要继续试，也应该换一个目标——不是验证"本地模型能不能聊天"，而是验证"某个模型能不能稳定跑 Claude Code 完整模式"。
这次探索的真正价值
它让我确认了一件事：
AI 工具链不是单点能力竞争，而是工作流稳定性竞争。
一个模型跑分高、显存够、CLI 能回答，都不代表它能进入真实开发流。真正重要的是它能不能稳定接住现有工具链里的上下文、协议、插件、文件操作和行为约束。
对个人开发者来说，最容易掉的坑就是：为了省一点模型成本，反而引入一堆新的维护成本。这次及时停下来，是正确的。
写这篇的收获：这次探索让我对"工具链稳定性"这个判断标准有了更具体的理解——它不是跑分、不是 benchmark、不是单次对话的流畅度，而是"放在完整 agent 环境下，连续跑 10 次，10 次都稳定"的能力。
如果你也在尝试类似的事情：你试过把本地模型接入 IDE 或 CLI 开发工具吗？模型在完整 agent 环境下稳定吗？你是怎么判断该继续投入还是及时停下来的？