1. 为什么要在 WorkBuddy 里接本地模型先把结论摆在前面WorkBuddy 接入 Ollama 这件事本质上不是多一个模型选项而是把积分消耗这个约束条件从工作流里彻底拿掉。我在团队里推这套方案之前大家用云端模型跑批量任务一天下来积分掉得比预期快得多尤其是那种读一遍代码库、生成一份变更说明的重复性活儿单次看着不多累积起来很吓人。换成 Ollama 托管的本地模型之后同样的任务跑一整天积分消耗是零代价只是本机的电费和一点显存占用。这里要先厘清一个容易混淆的点本地模型不消耗 token 额度不等于不消耗资源。它消耗的是你自己的 CPU、内存、显存和电。所以零积分运行这个说法是准确的但前提是你得有一台能扛得住推理的机器。我见过有人拿一台 8GB 内存的老笔记本硬跑 14B 模型结果生成一句话要等半分钟最后得出的结论是本地模型太慢没法用——这其实是硬件选型的问题不是方案本身的问题。WorkBuddy 在这套组合里扮演的角色是调度层和交互层。它本身不训练模型也不托管模型权重它做的是把你的请求按 OpenAI 兼容协议转发给 Ollama 的本地服务端口再把返回结果渲染到对话界面里。理解这一点非常关键因为后面所有的配置项、报错排查几乎都围绕这条转发链路有没有通展开。那到底哪些人适合走这条路我按实际接触到的用户分了三类高频批量任务用户每天要跑几十上百次模型调用比如批量生成注释、批量改写文案、批量做代码审查摘要。这类用户接本地模型收益最大因为调用次数越多省下的积分越可观。数据敏感场景用户代码或文档不方便发到外部服务希望推理过程完全在自己机器上完成。本地模型天然满足这个诉求。想折腾、想学原理的用户通过亲手配置 models.json、亲手调协议参数能把AI 代理助手是怎么调用模型的这件事彻底搞明白这比看十篇科普都管用。反过来如果你只是偶尔问几个问题、机器配置又一般那老实说没必要折腾云端模型开箱即用更省心。工具是拿来解决问题的不是拿来给自己找麻烦的。提示本文所有操作都基于本机自建服务全程在本地网络内完成不涉及任何外部网络配置。2. 三步走之前先把 Ollama 这头安顿好很多人卡在 WorkBuddy 这一侧其实问题出在 Ollama 那一侧没跑起来。所以三步走的第一步不是打开 WorkBuddy而是确认 Ollama 服务本身健康。这一步做扎实了后面两步会顺得让你怀疑人生。2.1 安装与首次启动的验证动作Ollama 的安装在各平台上都很直接装完之后不要急着拉模型先做一次服务健康检查。打开终端执行ollama --version能打印出版本号说明可执行文件在 PATH 里。接着启动服务并确认端口监听ollama serve正常情况下它会输出监听地址默认是127.0.0.1:11434。这个端口号请记牢后面配置 WorkBuddy 时要一字不差地填进去。我建议另开一个终端窗口做验证因为ollama serve会占住当前窗口curl http://127.0.0.1:11434/api/tags如果返回一段 JSON哪怕模型列表是空的说明服务已经活了。这一步是整个链路的地基验收跳过它直接去配 WorkBuddy出问题时你会分不清到底是哪一头坏了。2.2 模型选择别一上来就冲最大的模型选型是新手最容易踩的坑。我的建议是按内存/显存倒推而不是按哪个最强来选。下面这张表是我实测下来比较稳的对应关系供参考可用内存/显存建议模型规模典型体验8GB3B~4B 量化版能跑速度尚可复杂任务吃力16GB7B~8B 量化版日常问答、代码补全够用32GB14B 量化版综合能力明显提升速度可接受64GB 及以上32B 量化版接近云端中小模型体验拉模型的命令很朴素ollama pull qwen2.5:7b这里有个实操心得拉模型慢是常态别反复中断重试。中断重试会导致分片下载的临时文件残留有时候反而更慢。让它安安静静跑完去泡杯茶。如果你所在网络环境对某些源访问不畅可以了解下是否有可用的镜像配置方式但具体怎么配我这里不展开按你本地环境的实际情况处理即可。拉完之后验证一下模型确实在本地ollama list看到模型名和大小就说明权重已经落地了。再跑一次交互测试ollama run qwen2.5:7b 用一句话解释什么是递归能正常吐字Ollama 这一头就算彻底安顿好了。2.3 让服务常驻而不是每次手动开ollama serve手动开有个问题关掉终端服务就没了WorkBuddy 那边立刻报连接失败。所以第二步走之前最好把 Ollama 配成后台常驻服务。各平台方式不同核心思路都是开机自启 后台运行。配好之后你可以用同样的curl命令随时验证服务一直在WorkBuddy 就不会因为服务掉线而抽风。注意如果你改了默认端口记得 WorkBuddy 那边的配置也要同步改两边端口必须一致这是最常见的配置了但连不上的原因之一。3. 第二步models.json 到底该怎么写这是整篇的核心也是报错最集中的地方。WorkBuddy 通过一个模型配置文件来认识有哪些模型可用、每个模型怎么调用这个文件通常叫models.json。它的结构不复杂但字段含义必须搞清楚否则就是复制粘贴一时爽排查报错火葬场。3.1 配置文件里每个字段在说什么一个最小可用的本地模型配置大概长这样{ models: [ { name: local-qwen, provider: openai, baseUrl: http://127.0.0.1:11434/v1, apiKey: ollama, model: qwen2.5:7b } ] }逐个字段拆解name这是你在 WorkBuddy 界面里看到的名字随便起但要自己能认出来。我习惯加local-前缀一眼区分本地和云端。provider填openai。这里是最反直觉的地方——Ollama 不是 OpenAI但 Ollama 提供了OpenAI 兼容协议的接口所以从调用方的角度看它长得像 OpenAI。WorkBuddy 按 OpenAI 的格式发请求Ollama 按同样的格式收双方就对上了。baseUrl注意结尾的/v1。Ollama 的兼容接口挂在/v1路径下漏掉它就会 404。这是新手第一大坑。apiKey本地服务不校验密钥但很多客户端要求这个字段非空随便填个字符串即可填ollama是社区惯例。model必须和ollama list里显示的模型名完全一致包括冒号后面的 tag。写错一个字符就是模型不存在。3.2 为什么是 OpenAI 兼容协议而不是别的这里值得多说两句因为理解了原理排查问题时你就有方向感。模型服务之间的对话需要一套共同语言这套语言规定了请求长什么样、返回长什么样。OpenAI 的接口格式因为用的人多事实上成了一种通用方言Ollama、以及很多其他本地推理工具都实现了这套方言。WorkBuddy 只要会说这套方言就能和所有会说这套方言的服务通信不需要为每个服务单独写适配。所以当你看到接入失败时排查方向就很明确了要么是地址不对找不到服务要么是路径不对/v1漏了要么是模型名不对服务收到了请求但找不到对应模型要么是协议字段对不上版本差异。这四类几乎覆盖了九成的报错。3.3 保存配置失败的几种真实原因热词里有个workbuddy保存本地模型配置失败我专门说下。这个报错通常不是 WorkBuddy 的锅而是 JSON 本身有问题多余的逗号JSON 不允许最后一个元素后面有逗号这是手写配置最常见的语法错误。中文引号从某些文档里复制粘贴时引号可能被替换成了中文全角引号肉眼几乎看不出来但解析器直接报错。编码问题文件保存成了带 BOM 的格式某些解析器会读失败。用 UTF-8 无 BOM 保存最稳。路径权限配置文件所在目录没有写权限保存动作被系统拒绝。我的习惯是改完配置先用一个 JSON 校验工具过一遍确认语法没问题再让 WorkBuddy 去读。这一步花十秒能省掉半小时的抓瞎。4. 第三步跑通链路与验证配置写完、保存成功不代表链路就通了。第三步的核心是分层验证一层一层确认而不是一上来就在 WorkBuddy 里发消息然后对着报错发呆。4.1 从命令行先验证协议层在动 WorkBuddy 之前先用命令行模拟一次 WorkBuddy 会发出的请求curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好}] }如果这段能返回正常的 JSON 回复说明协议层完全没问题问题一定在 WorkBuddy 的配置或它读取配置的方式上。如果这段就失败了那 WorkBuddy 那边怎么调都没用先回来修 Ollama。这个分层定位的思路是我排查所有集成问题时最依赖的方法。4.2 在 WorkBuddy 里发第一条消息命令行通了之后回到 WorkBuddy选中你配置的那个本地模型发一句最简单的你好。第一次调用可能会慢因为模型需要加载进内存这是正常的别以为卡死了。等它吐出第一个字链路就算打通了。如果这里报错按下面的顺序对号入座报错现象最可能的原因处理方向连接被拒绝Ollama 服务没跑检查服务是否常驻404 Not FoundbaseUrl 漏了 /v1补上路径模型不存在model 名和实际不符对照 ollama list一直转圈无响应模型太大加载慢换小模型或等一等返回乱码或截断上下文长度超限调小输入或换大上下文模型4.3 反应慢的优化思路接入本地模型后反应非常慢是高频反馈。慢的原因通常有三个模型太大、上下文太长、硬件瓶颈。对应的优化手段换更小的量化模型7B 换 3B速度可能翻倍代价是能力下降看你的任务能不能接受。控制输入长度本地模型的上下文窗口有限塞太多内容进去处理时间会非线性增长。把无关的上下文砍掉。确认在用 GPU如果机器有独立显卡但推理还在用 CPU 跑那慢是必然的。检查 Ollama 是否识别到了 GPU。首次调用慢是正常的模型加载有开销连续对话时后续请求会快很多别用第一次的耗时下结论。5. 那些没人告诉你但一定会遇到的坑前面讲的是标准流程但真实操作里标准流程往往只占一半时间另一半都在和各种意外搏斗。这一节我把踩过的坑集中列出来希望能帮你少走点弯路。5.1 端口冲突与服务假死11434这个端口偶尔会被别的程序占用表现是 Ollama 启动看似成功但请求发过去没反应或者返回奇怪的东西。排查方法很简单看端口被谁占了。另一个隐蔽情况是服务假死——进程还在但不再响应请求这时候重启服务通常能解决。我现在的习惯是给 Ollama 配一个健康检查定期 curl 一下发现不响应就自动重启省得半夜跑批量任务时它悄悄挂了。5.2 模型名里的 tag 陷阱qwen2.5:7b和qwen2.5在 Ollama 里可能是两个不同的东西前者带 tag后者用默认 tag。如果你pull的时候带了 tag配置里也必须带同样的 tag。我见过有人 pull 的是:7b配置里写的是不带 tag 的名字结果一直报模型不存在查了半天才发现是这里。5.3 配置文件被覆盖WorkBuddy 某些版本在升级或重置时会重写配置文件你辛苦配的本地模型条目可能就没了。所以改完配置记得备份一份放在别的地方。真被覆盖了复制回来就行不用重新研究一遍字段。5.4 多模型并存时的命名冲突如果你同时配了云端模型和本地模型注意name字段不要重名。重名时 WorkBuddy 的行为不确定可能随机选一个也可能报错。给本地模型统一加前缀是最省心的做法。提示每次改完配置先做一次命令行验证 WorkBuddy 发消息的双重确认再投入正式使用。这个习惯能帮你把问题挡在批量任务之前。6. 让本地模型真正好用的几个进阶思路链路通了只是起点怎么让它好用是另一回事。这一节分享几个我实际用下来觉得有价值的思路。6.1 按任务类型分配模型不是所有任务都需要大模型。简单的格式化、改写、分类任务用小模型又快又省资源复杂的推理、代码生成再上大模型。你可以在models.json里配多个本地模型条目用的时候按任务切换。这种分级调度的思路能让你的本地推理资源利用率高很多。6.2 自定义指令配合本地模型WorkBuddy 的自定义指令功能和本地模型是绝配。因为本地模型不消耗积分你可以把一些冗长的、固定的系统提示词写进自定义指令里让每次调用都自动带上而不用担心提示词太长费积分。比如把你是代码审查助手输出格式固定为……这类指令固化下来本地模型每次都会按这个格式输出省去你反复交代。6.3 批量任务的节奏控制本地模型跑批量任务时别一次性把几百个请求全怼进去。Ollama 默认的并发处理能力有限请求堆积反而会拖慢整体速度甚至触发超时。我的做法是控制并发数让请求排队有序处理整体吞吐反而更高。具体并发数多少合适取决于你的硬件需要实测调优。6.4 日志是你的朋友Ollama 和 WorkBuddy 都有日志输出。出问题时先看日志别猜。日志里通常会明确告诉你请求发到了哪个地址返回了什么状态码这些信息比任何猜测都可靠。养成看日志的习惯排查效率会提升一个档次。7. 关于这套方案的边界说几句实在话本地模型不是银弹它有明确的适用边界。我在实际使用中体会最深的一点是它解决的是成本和隐私问题不是能力问题。同等参数规模下本地模型的能力通常不如云端的大模型这是客观事实。所以正确的用法是把合适的任务交给本地模型而不是所有任务都塞给本地模型。我的分工原则大致是这样高频、重复、对能力要求不高的任务交给本地模型享受零积分和快响应低频、复杂、需要强推理的任务交给云端模型享受更强的能力。两者不是替代关系是互补关系。把这条线划清楚你的工作流会顺畅很多。另外硬件是绕不过去的门槛。本地推理吃内存和显存机器配置决定了你能跑多大的模型、能跑多快。如果你的机器比较旧先从最小的模型试起跑通了、觉得有价值了再考虑升级硬件。别一上来就为了跑本地模型去买顶配机器先用起来让实际体验告诉你值不值得投入。最后分享一个小技巧把 Ollama 的服务状态检查、模型列表查看、配置备份这几件事写成一个简单的脚本每次开工前跑一遍。花不了几分钟但能让你在正式干活之前就发现潜在问题避免干到一半突然掉链子。这套流程我用了挺久稳定性提升很明显推荐你也试试。 WorkBuddy 接入 Ollama 本地模型：零积分运行与配置实战
1. 为什么要在 WorkBuddy 里接本地模型先把结论摆在前面WorkBuddy 接入 Ollama 这件事本质上不是多一个模型选项而是把积分消耗这个约束条件从工作流里彻底拿掉。我在团队里推这套方案之前大家用云端模型跑批量任务一天下来积分掉得比预期快得多尤其是那种读一遍代码库、生成一份变更说明的重复性活儿单次看着不多累积起来很吓人。换成 Ollama 托管的本地模型之后同样的任务跑一整天积分消耗是零代价只是本机的电费和一点显存占用。这里要先厘清一个容易混淆的点本地模型不消耗 token 额度不等于不消耗资源。它消耗的是你自己的 CPU、内存、显存和电。所以零积分运行这个说法是准确的但前提是你得有一台能扛得住推理的机器。我见过有人拿一台 8GB 内存的老笔记本硬跑 14B 模型结果生成一句话要等半分钟最后得出的结论是本地模型太慢没法用——这其实是硬件选型的问题不是方案本身的问题。WorkBuddy 在这套组合里扮演的角色是调度层和交互层。它本身不训练模型也不托管模型权重它做的是把你的请求按 OpenAI 兼容协议转发给 Ollama 的本地服务端口再把返回结果渲染到对话界面里。理解这一点非常关键因为后面所有的配置项、报错排查几乎都围绕这条转发链路有没有通展开。那到底哪些人适合走这条路我按实际接触到的用户分了三类高频批量任务用户每天要跑几十上百次模型调用比如批量生成注释、批量改写文案、批量做代码审查摘要。这类用户接本地模型收益最大因为调用次数越多省下的积分越可观。数据敏感场景用户代码或文档不方便发到外部服务希望推理过程完全在自己机器上完成。本地模型天然满足这个诉求。想折腾、想学原理的用户通过亲手配置 models.json、亲手调协议参数能把AI 代理助手是怎么调用模型的这件事彻底搞明白这比看十篇科普都管用。反过来如果你只是偶尔问几个问题、机器配置又一般那老实说没必要折腾云端模型开箱即用更省心。工具是拿来解决问题的不是拿来给自己找麻烦的。提示本文所有操作都基于本机自建服务全程在本地网络内完成不涉及任何外部网络配置。2. 三步走之前先把 Ollama 这头安顿好很多人卡在 WorkBuddy 这一侧其实问题出在 Ollama 那一侧没跑起来。所以三步走的第一步不是打开 WorkBuddy而是确认 Ollama 服务本身健康。这一步做扎实了后面两步会顺得让你怀疑人生。2.1 安装与首次启动的验证动作Ollama 的安装在各平台上都很直接装完之后不要急着拉模型先做一次服务健康检查。打开终端执行ollama --version能打印出版本号说明可执行文件在 PATH 里。接着启动服务并确认端口监听ollama serve正常情况下它会输出监听地址默认是127.0.0.1:11434。这个端口号请记牢后面配置 WorkBuddy 时要一字不差地填进去。我建议另开一个终端窗口做验证因为ollama serve会占住当前窗口curl http://127.0.0.1:11434/api/tags如果返回一段 JSON哪怕模型列表是空的说明服务已经活了。这一步是整个链路的地基验收跳过它直接去配 WorkBuddy出问题时你会分不清到底是哪一头坏了。2.2 模型选择别一上来就冲最大的模型选型是新手最容易踩的坑。我的建议是按内存/显存倒推而不是按哪个最强来选。下面这张表是我实测下来比较稳的对应关系供参考可用内存/显存建议模型规模典型体验8GB3B~4B 量化版能跑速度尚可复杂任务吃力16GB7B~8B 量化版日常问答、代码补全够用32GB14B 量化版综合能力明显提升速度可接受64GB 及以上32B 量化版接近云端中小模型体验拉模型的命令很朴素ollama pull qwen2.5:7b这里有个实操心得拉模型慢是常态别反复中断重试。中断重试会导致分片下载的临时文件残留有时候反而更慢。让它安安静静跑完去泡杯茶。如果你所在网络环境对某些源访问不畅可以了解下是否有可用的镜像配置方式但具体怎么配我这里不展开按你本地环境的实际情况处理即可。拉完之后验证一下模型确实在本地ollama list看到模型名和大小就说明权重已经落地了。再跑一次交互测试ollama run qwen2.5:7b 用一句话解释什么是递归能正常吐字Ollama 这一头就算彻底安顿好了。2.3 让服务常驻而不是每次手动开ollama serve手动开有个问题关掉终端服务就没了WorkBuddy 那边立刻报连接失败。所以第二步走之前最好把 Ollama 配成后台常驻服务。各平台方式不同核心思路都是开机自启 后台运行。配好之后你可以用同样的curl命令随时验证服务一直在WorkBuddy 就不会因为服务掉线而抽风。注意如果你改了默认端口记得 WorkBuddy 那边的配置也要同步改两边端口必须一致这是最常见的配置了但连不上的原因之一。3. 第二步models.json 到底该怎么写这是整篇的核心也是报错最集中的地方。WorkBuddy 通过一个模型配置文件来认识有哪些模型可用、每个模型怎么调用这个文件通常叫models.json。它的结构不复杂但字段含义必须搞清楚否则就是复制粘贴一时爽排查报错火葬场。3.1 配置文件里每个字段在说什么一个最小可用的本地模型配置大概长这样{ models: [ { name: local-qwen, provider: openai, baseUrl: http://127.0.0.1:11434/v1, apiKey: ollama, model: qwen2.5:7b } ] }逐个字段拆解name这是你在 WorkBuddy 界面里看到的名字随便起但要自己能认出来。我习惯加local-前缀一眼区分本地和云端。provider填openai。这里是最反直觉的地方——Ollama 不是 OpenAI但 Ollama 提供了OpenAI 兼容协议的接口所以从调用方的角度看它长得像 OpenAI。WorkBuddy 按 OpenAI 的格式发请求Ollama 按同样的格式收双方就对上了。baseUrl注意结尾的/v1。Ollama 的兼容接口挂在/v1路径下漏掉它就会 404。这是新手第一大坑。apiKey本地服务不校验密钥但很多客户端要求这个字段非空随便填个字符串即可填ollama是社区惯例。model必须和ollama list里显示的模型名完全一致包括冒号后面的 tag。写错一个字符就是模型不存在。3.2 为什么是 OpenAI 兼容协议而不是别的这里值得多说两句因为理解了原理排查问题时你就有方向感。模型服务之间的对话需要一套共同语言这套语言规定了请求长什么样、返回长什么样。OpenAI 的接口格式因为用的人多事实上成了一种通用方言Ollama、以及很多其他本地推理工具都实现了这套方言。WorkBuddy 只要会说这套方言就能和所有会说这套方言的服务通信不需要为每个服务单独写适配。所以当你看到接入失败时排查方向就很明确了要么是地址不对找不到服务要么是路径不对/v1漏了要么是模型名不对服务收到了请求但找不到对应模型要么是协议字段对不上版本差异。这四类几乎覆盖了九成的报错。3.3 保存配置失败的几种真实原因热词里有个workbuddy保存本地模型配置失败我专门说下。这个报错通常不是 WorkBuddy 的锅而是 JSON 本身有问题多余的逗号JSON 不允许最后一个元素后面有逗号这是手写配置最常见的语法错误。中文引号从某些文档里复制粘贴时引号可能被替换成了中文全角引号肉眼几乎看不出来但解析器直接报错。编码问题文件保存成了带 BOM 的格式某些解析器会读失败。用 UTF-8 无 BOM 保存最稳。路径权限配置文件所在目录没有写权限保存动作被系统拒绝。我的习惯是改完配置先用一个 JSON 校验工具过一遍确认语法没问题再让 WorkBuddy 去读。这一步花十秒能省掉半小时的抓瞎。4. 第三步跑通链路与验证配置写完、保存成功不代表链路就通了。第三步的核心是分层验证一层一层确认而不是一上来就在 WorkBuddy 里发消息然后对着报错发呆。4.1 从命令行先验证协议层在动 WorkBuddy 之前先用命令行模拟一次 WorkBuddy 会发出的请求curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好}] }如果这段能返回正常的 JSON 回复说明协议层完全没问题问题一定在 WorkBuddy 的配置或它读取配置的方式上。如果这段就失败了那 WorkBuddy 那边怎么调都没用先回来修 Ollama。这个分层定位的思路是我排查所有集成问题时最依赖的方法。4.2 在 WorkBuddy 里发第一条消息命令行通了之后回到 WorkBuddy选中你配置的那个本地模型发一句最简单的你好。第一次调用可能会慢因为模型需要加载进内存这是正常的别以为卡死了。等它吐出第一个字链路就算打通了。如果这里报错按下面的顺序对号入座报错现象最可能的原因处理方向连接被拒绝Ollama 服务没跑检查服务是否常驻404 Not FoundbaseUrl 漏了 /v1补上路径模型不存在model 名和实际不符对照 ollama list一直转圈无响应模型太大加载慢换小模型或等一等返回乱码或截断上下文长度超限调小输入或换大上下文模型4.3 反应慢的优化思路接入本地模型后反应非常慢是高频反馈。慢的原因通常有三个模型太大、上下文太长、硬件瓶颈。对应的优化手段换更小的量化模型7B 换 3B速度可能翻倍代价是能力下降看你的任务能不能接受。控制输入长度本地模型的上下文窗口有限塞太多内容进去处理时间会非线性增长。把无关的上下文砍掉。确认在用 GPU如果机器有独立显卡但推理还在用 CPU 跑那慢是必然的。检查 Ollama 是否识别到了 GPU。首次调用慢是正常的模型加载有开销连续对话时后续请求会快很多别用第一次的耗时下结论。5. 那些没人告诉你但一定会遇到的坑前面讲的是标准流程但真实操作里标准流程往往只占一半时间另一半都在和各种意外搏斗。这一节我把踩过的坑集中列出来希望能帮你少走点弯路。5.1 端口冲突与服务假死11434这个端口偶尔会被别的程序占用表现是 Ollama 启动看似成功但请求发过去没反应或者返回奇怪的东西。排查方法很简单看端口被谁占了。另一个隐蔽情况是服务假死——进程还在但不再响应请求这时候重启服务通常能解决。我现在的习惯是给 Ollama 配一个健康检查定期 curl 一下发现不响应就自动重启省得半夜跑批量任务时它悄悄挂了。5.2 模型名里的 tag 陷阱qwen2.5:7b和qwen2.5在 Ollama 里可能是两个不同的东西前者带 tag后者用默认 tag。如果你pull的时候带了 tag配置里也必须带同样的 tag。我见过有人 pull 的是:7b配置里写的是不带 tag 的名字结果一直报模型不存在查了半天才发现是这里。5.3 配置文件被覆盖WorkBuddy 某些版本在升级或重置时会重写配置文件你辛苦配的本地模型条目可能就没了。所以改完配置记得备份一份放在别的地方。真被覆盖了复制回来就行不用重新研究一遍字段。5.4 多模型并存时的命名冲突如果你同时配了云端模型和本地模型注意name字段不要重名。重名时 WorkBuddy 的行为不确定可能随机选一个也可能报错。给本地模型统一加前缀是最省心的做法。提示每次改完配置先做一次命令行验证 WorkBuddy 发消息的双重确认再投入正式使用。这个习惯能帮你把问题挡在批量任务之前。6. 让本地模型真正好用的几个进阶思路链路通了只是起点怎么让它好用是另一回事。这一节分享几个我实际用下来觉得有价值的思路。6.1 按任务类型分配模型不是所有任务都需要大模型。简单的格式化、改写、分类任务用小模型又快又省资源复杂的推理、代码生成再上大模型。你可以在models.json里配多个本地模型条目用的时候按任务切换。这种分级调度的思路能让你的本地推理资源利用率高很多。6.2 自定义指令配合本地模型WorkBuddy 的自定义指令功能和本地模型是绝配。因为本地模型不消耗积分你可以把一些冗长的、固定的系统提示词写进自定义指令里让每次调用都自动带上而不用担心提示词太长费积分。比如把你是代码审查助手输出格式固定为……这类指令固化下来本地模型每次都会按这个格式输出省去你反复交代。6.3 批量任务的节奏控制本地模型跑批量任务时别一次性把几百个请求全怼进去。Ollama 默认的并发处理能力有限请求堆积反而会拖慢整体速度甚至触发超时。我的做法是控制并发数让请求排队有序处理整体吞吐反而更高。具体并发数多少合适取决于你的硬件需要实测调优。6.4 日志是你的朋友Ollama 和 WorkBuddy 都有日志输出。出问题时先看日志别猜。日志里通常会明确告诉你请求发到了哪个地址返回了什么状态码这些信息比任何猜测都可靠。养成看日志的习惯排查效率会提升一个档次。7. 关于这套方案的边界说几句实在话本地模型不是银弹它有明确的适用边界。我在实际使用中体会最深的一点是它解决的是成本和隐私问题不是能力问题。同等参数规模下本地模型的能力通常不如云端的大模型这是客观事实。所以正确的用法是把合适的任务交给本地模型而不是所有任务都塞给本地模型。我的分工原则大致是这样高频、重复、对能力要求不高的任务交给本地模型享受零积分和快响应低频、复杂、需要强推理的任务交给云端模型享受更强的能力。两者不是替代关系是互补关系。把这条线划清楚你的工作流会顺畅很多。另外硬件是绕不过去的门槛。本地推理吃内存和显存机器配置决定了你能跑多大的模型、能跑多快。如果你的机器比较旧先从最小的模型试起跑通了、觉得有价值了再考虑升级硬件。别一上来就为了跑本地模型去买顶配机器先用起来让实际体验告诉你值不值得投入。最后分享一个小技巧把 Ollama 的服务状态检查、模型列表查看、配置备份这几件事写成一个简单的脚本每次开工前跑一遍。花不了几分钟但能让你在正式干活之前就发现潜在问题避免干到一半突然掉链子。这套流程我用了挺久稳定性提升很明显推荐你也试试。