开始折腾 WorkBuddy 自定义模型接入纯粹是被逼的。那阵子我每天的工作流是先在 IDE 里写代码遇到问题就切到 WorkBuddy让它帮我分析报错、补全函数、改 bug。官方模型确实聪明但有两个让我很别扭的地方——一个是 token 消耗真的快几个聊天来回下来额度就见底了另一个是公司项目代码不能随便往外送每次看到它把代码片段上传到云端我心里都打鼓。于是我决定接自定义模型把模型换成我自己可控的云端 API或者干脆用本地跑的小模型。这篇不是官方文档的复述是我自己从零配置到跑通、再到日常稳定的全过程记录。WorkBuddy 支持自定义模型接入你可以把默认的模型服务替换成任意兼容 OpenAI 接口协议的大模型这意味着成本可控、数据边界可控、模型选择也可控。适合手里有模型 API 额度、或想用 Ollama 跑本地模型又不想放弃 WorkBuddy 这套交互体验的人。我把我踩过的坑、试出来的参数、还有心态上的变化都写出来给想折腾的朋友一个真实参考。1. 为什么非要给 WorkBuddy 接自定义模型1.1 官方模型之外的三个真实诉求先交代一下背景。WorkBuddy 这类 AI 编程助手默认情况下是调用它们官方绑定的大模型好处是开箱即用坏处也很明显。第一是成本。我日常使用频率高尤其是写单元测试和补全重复代码的时候一个上午能发出几十次请求。官方模型的计费按 token 走积少成多月底一看账单肉疼。自定义接入之后我可以选择更便宜的模型甚至把高频低难度任务交给本地模型成本直接从可控变成几乎为零。第二是数据边界。在公司内网环境开发时代码本身的敏感性比很多人想象的高。你让 AI 助手分析报错它会把整个文件、上下文、甚至邻接文件的内容一起发出去。官方模型的服务端在哪里、数据怎么处置对开发者来说是个黑盒。自定义接入允许我把请求指向企业内部的模型网关或者直接指向本机的 Ollama至少数据不出本机。这一点对于医疗、金融、政务类项目的团队来说不是可选项是硬性要求。第三是场景匹配。代码助手要干的事情其实差异很大写一个排序函数和重构一个模块的业务逻辑需要的模型能力完全不是一个量级。接自定义模型之后我可以配两个甚至三个模型轻量任务用 7B 的本地模型秒回、免费复杂任务切到云端大模型追求理解力。这个分场景用不同模型的思路官方内置模型给不了。1.2 先搞清楚接入到底在接什么很多人一听自定义模型接入第一反应是把接口地址改一下就行。方向没错但实际操作时你要给 WorkBuddy 提供的不是一两个参数而是一整套模型接入信息。本质上WorkBuddy 是通过一套标准化的接口协议去调用模型的只要你选的模型或者服务中间层兼容这套协议就能接进去。我把它类比成给打印机换墨盒打印机有一个标准卡槽接口墨盒只要符合卡槽的规格协议兼容就能装上去用。但不同的墨盒墨水颜色、浓度、适配纸型都不同你得在打印机设置里告诉它我换了一支什么墨盒——这一步就是 WorkBuddy 里的模型名称、参数配置。所以接自定义模型的本质是回答几个问题你的模型服务地址是什么base URL是云端还是本机你的认证凭证是什么API Key还是本地服务不需要认证你调用的模型叫什么名字model name名字写错是最常见的坑你的模型支持哪些能力function calling、tool use、流式输出这决定了 WorkBuddy 能不能用 Agent 模式把这几个问题想清楚配置就成功了一半。后面所有坑几乎都出在这几个问题的答案上。2. 开工前的三张清单模型、密钥与运行环境2.1 模型选型云端 API 与本地模型的取舍动手配置之前先选模型。我先后试过两条路线云端 API 和本地模型。云端路线的代表是 DeepSeek、通义千问、智谱 GLM 这类对外提供 API 的模型服务。优点是模型能力强、部署零成本缺点是每次请求都走公网、数据要出本地以及按 token 计费。适合追求代码质量、不在意数据出域的场景。本地路线我主要用 Ollama 跑开源模型。优点不用说免费、数据不出本机、响应速度通常也够用缺点是模型能力受限于你的显卡和内存7B 模型在复杂任务上的表现和云端旗舰模型有明显差距。另外如果你没有像样的独立显卡纯 CPU 跑大一点的模型会慢到怀疑人生。我用一张表总结一下我当时纠结的结果对比维度云端 API如 DeepSeek本地模型Ollama代码能力强复杂任务也能顶7B 模型够用14B 以上更稳响应速度取决于网络通常 1-3 秒取决于硬件本地通常在 1 秒内数据安全数据出本地数据完全不出本地成本按 token 计费电费加硬件折旧部署难度低注册拿 Key 就行中要装 Ollama、拉模型我的建议是如果你只是想省点钱接云端 API 就够了配置简单、效果有保障如果你是奔着数据安全去的或者想完全避开网络因素那老老实实走本地模型路线。两者不冲突WorkBuddy 支持多配置我可以随时切换这个后面会讲。2.2 环境准备先装什么、先不装什么确定路线之后别急着打开 WorkBuddy 的配置面板。我踩过的第一个坑就是在没有验证接口可用的情况下直接改配置结果出了问题根本分不清是网络问题还是配置问题。正确的顺序是先把环境准备好再用命令行把接口验证一遍最后才去改 WorkBuddy。环境准备分两种情况如果走本地模型路线先安装 Ollama。装完在终端跑一下ollama pull qwen2.5-coder:7b ollama run qwen2.5-coder:7b能正常对话之后再往下走。注意Ollama 安装完成默认监听在 11434 端口它同时提供原生接口和 OpenAI 兼容接口后者是 WorkBuddy 能接上的关键。如果走云端 API 路线先去对应平台注册账号、创建 API Key。创建完先做一次连通性验证。以 DeepSeek 为例在终端跑curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的API_KEY \ -d {model:deepseek-chat,messages:[{role:user,content:你好}]}返回一段 JSON里面有choices字段说明接口通了。本地 Ollama 也可以这么验curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen2.5-coder:7b,messages:[{role:user,content:你好}]}这里有个细节Ollama 的 OpenAI 兼容地址是http://localhost:11434/v1注意/v1一定要带上。我第一次配置就是漏了/v1结果 WorkBuddy 一直报 404折腾了半小时才反应过来。3. 核心配置步骤从新建配置到第一次对话3.1 找到 WorkBuddy 的配置入口环境验证通过之后就可以回到 WorkBuddy 做配置了。不同版本的入口可能不完全一样但大体逃不出两条路一是设置面板里的模型或 Provider 管理二是在用户目录下的.workbuddy/配置文件里手动编辑。我用的是本地配置文件的方式因为字段全、可控性强改错了也容易回滚。我这边实际生效的配置文件路径是~/.workbuddy/config.json如果你的系统里没有这个文件创建一个就行。配置内容长这样{ providers: [ { name: deepseek, baseUrl: https://api.deepseek.com, apiKey: sk-xxxxxxxxxxxxxxxx, models: [ { name: deepseek-chat, type: chat, maxTokens: 8192 } ] }, { name: local-ollama, baseUrl: http://localhost:11434/v1, apiKey: ollama, models: [ { name: qwen2.5-coder:7b, type: chat, maxTokens: 4096 } ] } ], activeProvider: deepseek, activeModel: deepseek-chat }这个结构不是我瞎编的是我自己配置时试出来的形态。它基本对应了大多数同类 AI 助手的 Provider 配置范式一个 provider 代表一个模型服务来源里面可以挂多个模型。如果你用的是企业内部自建网关或者某些中转平台配置结构也类似只是 baseUrl 和 apiKey 不同。3.2 配置项逐字段拆解很多人喜欢直接复制网上的配置但不知道每个字段是干什么的一旦报错就抓瞎。我逐个说一遍我理解的含义nameprovider 的名称纯粹是给你自己看的起个好认的名字比如deepseek、local-ollama、company-gateway。baseUrl模型服务的基础地址。这是最关键也最容易填错的字段。要注意云端 API 有些平台要求填到域名根路径有些要求填到/v1Ollama 的 OpenAI 兼容接口则必须带/v1。拿不准的时候把你已经在命令行验证过的地址复制过来不要手敲。apiKey认证凭证。本地 Ollama 一般不校验 Key随便填一个非空字符串就能过云端 API 必须填真实有效的 Key。我建议把 Key 放到环境变量里引用而不是明文写进配置文件尤其是你的配置文件可能要提交到公司仓库时。models模型列表。每个模型对象里name要和模型服务实际支持的名字完全一致。DeepSeek 的对话模型叫deepseek-chat推理模型叫deepseek-reasoner名字写错直接 404。maxTokens单次最大输出 token 数。设置太小代码生成到一半会截断设置太大又可能超过模型服务的限制导致报错。主流平台的上下文长度普遍到 8K 以上我日常设 8192够用。activeProvider/activeModel默认生效的 provider 和 model对应你在界面上看到的当前模型。除了这些基础字段还有一些高级参数我在后面调优时才会动比如temperature、stream、customHeaders。customHeaders用来给请求附加自定义 HTTP 头有些企业内部模型网关会要求带特定 header 鉴权这时候就需要它。3.3 第一次对话怎么判断配置真的生效了配置保存之后别急着让它改代码先在对话窗口发一句最简单的你好观察三件事第一是否能正常返回内容。如果返回空或者报错说明请求根本没出去或者出去之后被拒了。这时候去看 WorkBuddy 的日志通常在配置文件同目录下有个logs/文件夹也可以直接在日志面板里看。第二对话是否带模型名标识。如果你配了多个模型界面会显示当前用的是哪个方便你确认切换到的到底是不是目标模型。第三响应速度是否正常。如果等了十几秒才出第一个字多半是网络问题或者模型服务端负载太高。第一次对话跑通之后我建议立刻做一个实战验证给它一段故意写错的代码让它定位问题并修复。这一步能同时验证两个关键能力模型能不能理解代码上下文以及 WorkBuddy 的文件读写能力是否正常联动。如果只是对话正常但改不了文件那后面所有自动化都无从谈起。4. 踩坑记录我在这条路上摔过的六个跟头这是大家最想看的部分。我从接入到现在前前后后遇到过十来个报错挑了六个最有代表性、也最可能复现的写出来。每一个我都尽量还原当时的报错信息、排查思路和最终解法。4.1 模型名写错接口直接 404第一次配置云端 DeepSeek 的时候我在配置里写了model: deepseek-coder因为这是个很熟悉的名字觉得肯定没错。结果 WorkBuddy 一直报404 model_not_found。我用命令行一测发现平台要求的是deepseek-chat。教训是模型名不是你以为的名字而是模型服务文档里写的那个名字。配置前打开官方文档核对一下或者用平台的模型列表接口拉一下比瞎猜靠谱得多。4.2 baseUrl 少了/v1被 404 折腾半小时刚才提到过这个坑我在 Ollama 上踩过。WorkBuddy 调的是 OpenAI 兼容接口地址必须是http://localhost:11434/v1而不是裸的http://localhost:11434。云端有些平台也类似根路径和带/v1的路径返回的内容可能完全不同。我的排查方法很简单先用命令行 curl 跑通再原封不动把地址复制进配置不要手动补路径。4.3 temperature 设置过高代码变成了散文接本地模型之后一开始我图新鲜把所有参数都拉满temperature 直接调到了 1.5。结果模型生成的代码注释倒是写得很美像抒情散文但变量名一会儿一个风格函数逻辑大跳步基本不能用。后来我把 temperature 降到 0.2 左右代码风格立刻稳了。对于代码生成任务temperature 不是越高越有创造性而是越低越可控。这个参数我在后面调优部分还会细讲。4.4 模型不支持 function callingAgent 模式直接哑火这是我踩过最严重的一个坑。我先把 WorkBuddy 的配置切到一个轻量本地模型上想节省成本结果发现它只能聊天不能改文件也没有工具调用行为。查了日志才发现模型服务在响应里拒绝了功能调用请求。原因是那个模型版本不支持 function calling。这就是我前面说的——不是所有模型都具备 Agent 能力。WorkBuddy 的改代码、跑命令、管理文件这些能力依赖底层的工具调用模型不支持上层功能就全瘫痪。解决方法是换一个支持 function calling 的模型或者让轻量模型只做问答把代码操作类任务留在更强的主模型上。4.5 maxTokens 设太小代码生成到一半被截断有一次我让它写一个完整的配置文件写到一半突然断了末尾也没有正常收尾。一开始我以为是模型能力问题后来看日志发现返回长度正好卡在maxTokens的上限。我设的是 2048确实太小了。生成一个上百行的配置文件很容易就超。后来我把代码生成任务的 maxTokens 提到 8192截断问题就再没出现过。这个参数要结合你的实际任务来定宁可设大一点也不要频繁截断否则生成结果没法直接用还得二次加工更浪费时间。4.6 配置里有多个 provider切来切去忘了当前是哪个这个问题不算报错但很影响体验。我有 local-ollama 和 deepseek 两个 provider每次切换都要回配置文件改activeProvider。有次我急着干活忘了切回来结果聊天是正常的但一让它改代码就报工具调用失败我排查了半天才意识到用的是本地轻量模型。后来我养成了一个习惯在 WorkBuddy 的对话首句先确认当前模型比如直接问你当前用的是哪个模型通常它会从系统信息里拿到准确的名字。多模型混用的时候这个确认动作能省很多事。我把上面这些坑汇总成一张排查表留着以后参考现象可能原因排查顺序404 / model_not_found模型名写错用 curl 请求验证模型名连接拒绝 / 无法访问baseUrl 错误或漏/v1对比命令行验证过的地址响应为空或长时间无响应网络问题或服务端负载高看 WorkBuddy 日志代码风格飘、逻辑乱temperature 过高降到 0.2 以下重试不能改文件、不能调工具模型不支持 function calling换成支持工具调用的模型输出被截断maxTokens 太小调大 maxTokens5. 接入稳定之后参数调优与日常工作流磨合5.1 不同任务推荐参数配方接入稳定之后我开始琢磨怎么让模型在具体场景下发挥得更好。同样的模型参数不一样效果天差地别。我总结了一套自己的配方不一定适合所有人但思路可以参考。任务类型推荐模型temperaturemaxTokens说明代码补全本地 7B coder 模型0.1 - 0.22048 - 4096追求确定性温度越低越好Bug 解释与修复云端强模型0.2 - 0.34096 - 8192需要较强的理解能力代码重构云端强模型0.3 - 0.48192适度创造但别飘单元测试生成任意 coder 模型0.28192输出格式稳定最重要技术方案讨论云端强模型0.74096可以保留一点发散性这里最核心的一条是我反复验证过的在代码场景里temperature 普遍要控制在 0.4 以下尤其是补全和生成测试几乎都是低温更稳。只有做方案讨论、头脑风暴这类不立即落地的任务才值得把温度调高。另外如果你接的是 deepseek-reasoner 这类推理模型它在输出答案之前会先输出一段 reasoning 内容推理模型的 temperature 往往有额外限制配置时可以留意一下模型文档里的说明。5.2 多模型切换的小技巧我一直保留两个 provider一个本地一个云端切换方式是通过改activeProvider。但每次都改文件太累了我的做法是建了两个配置文件一个默认用本地模型一个默认用云端模型需要切换时直接替换配置文件再重启 WorkBuddy。你也可以看 WorkBuddy 的设置界面是否支持直接切换支持的话会更方便。另一个技巧是给不同模型设置不同的使用场景记在本子上或者写在配置的注释里。比如我的规则是日常快速问答用本地代码生成和重构用云端涉及公司敏感业务代码一律切本地。这个规则固定下来之后我基本不会再出现用错模型的情况。5.3 日常使用中的三条纪律最后分享几个让我少踩坑的日常习惯。第一条别让模型猜上下文。WorkBuddy 能读取当前打开的文件但你要明确告诉它关注哪个文件、解决什么问题。我自己写 prompt 的固定结构是项目背景一句话 我要做什么 约束条件。背景信息越清晰代码生成质量越高也能少烧 token。第二条定期清理会话上下文。长会话会让上下文越塞越满一方面是 token 消耗直线上升另一方面是模型注意力被无关内容稀释回答质量下降。我的习惯是每个任务开启新会话最长不超过二十轮对话。第三条密钥永远不要写死在代码里。配置文件里的 apiKey 我后来全部换成了环境变量引用比如在终端设置export WORKBUDDY_DEEPSEEK_KEYsk-xxx然后在配置文件里用${WORKBUDDY_DEEPSEEK_KEY}引用。这样即使配置文件被误分享也不会泄露密钥。折腾完自定义模型接入我最大的感受是AI 编程助手的能力边界其实有一半掌握在使用者手里。官方模型很好但未必适合每一个场景和每一条数据边界要求接自定义模型的过程看着麻烦可是一旦跑通你会获得一种工具真正归我管的控制感。最后再分享一个小细节如果你的 WorkBuddy 配置了本地 Ollama 模型建议在系统登录项里把 Ollama 设置为开机自启免得每天早上打开 WorkBuddy 发现连不上本机模型还要手动敲一次ollama serve。这种小坑藏不住只有天天用的人才能发现。 
长河君 · 2026/9/8 17:42:58 · 阅读 1.2k WorkBuddy自定义模型接入全攻略：配置、调参与踩坑记录
开始折腾 WorkBuddy 自定义模型接入纯粹是被逼的。那阵子我每天的工作流是先在 IDE 里写代码遇到问题就切到 WorkBuddy让它帮我分析报错、补全函数、改 bug。官方模型确实聪明但有两个让我很别扭的地方——一个是 token 消耗真的快几个聊天来回下来额度就见底了另一个是公司项目代码不能随便往外送每次看到它把代码片段上传到云端我心里都打鼓。于是我决定接自定义模型把模型换成我自己可控的云端 API或者干脆用本地跑的小模型。这篇不是官方文档的复述是我自己从零配置到跑通、再到日常稳定的全过程记录。WorkBuddy 支持自定义模型接入你可以把默认的模型服务替换成任意兼容 OpenAI 接口协议的大模型这意味着成本可控、数据边界可控、模型选择也可控。适合手里有模型 API 额度、或想用 Ollama 跑本地模型又不想放弃 WorkBuddy 这套交互体验的人。我把我踩过的坑、试出来的参数、还有心态上的变化都写出来给想折腾的朋友一个真实参考。1. 为什么非要给 WorkBuddy 接自定义模型1.1 官方模型之外的三个真实诉求先交代一下背景。WorkBuddy 这类 AI 编程助手默认情况下是调用它们官方绑定的大模型好处是开箱即用坏处也很明显。第一是成本。我日常使用频率高尤其是写单元测试和补全重复代码的时候一个上午能发出几十次请求。官方模型的计费按 token 走积少成多月底一看账单肉疼。自定义接入之后我可以选择更便宜的模型甚至把高频低难度任务交给本地模型成本直接从可控变成几乎为零。第二是数据边界。在公司内网环境开发时代码本身的敏感性比很多人想象的高。你让 AI 助手分析报错它会把整个文件、上下文、甚至邻接文件的内容一起发出去。官方模型的服务端在哪里、数据怎么处置对开发者来说是个黑盒。自定义接入允许我把请求指向企业内部的模型网关或者直接指向本机的 Ollama至少数据不出本机。这一点对于医疗、金融、政务类项目的团队来说不是可选项是硬性要求。第三是场景匹配。代码助手要干的事情其实差异很大写一个排序函数和重构一个模块的业务逻辑需要的模型能力完全不是一个量级。接自定义模型之后我可以配两个甚至三个模型轻量任务用 7B 的本地模型秒回、免费复杂任务切到云端大模型追求理解力。这个分场景用不同模型的思路官方内置模型给不了。1.2 先搞清楚接入到底在接什么很多人一听自定义模型接入第一反应是把接口地址改一下就行。方向没错但实际操作时你要给 WorkBuddy 提供的不是一两个参数而是一整套模型接入信息。本质上WorkBuddy 是通过一套标准化的接口协议去调用模型的只要你选的模型或者服务中间层兼容这套协议就能接进去。我把它类比成给打印机换墨盒打印机有一个标准卡槽接口墨盒只要符合卡槽的规格协议兼容就能装上去用。但不同的墨盒墨水颜色、浓度、适配纸型都不同你得在打印机设置里告诉它我换了一支什么墨盒——这一步就是 WorkBuddy 里的模型名称、参数配置。所以接自定义模型的本质是回答几个问题你的模型服务地址是什么base URL是云端还是本机你的认证凭证是什么API Key还是本地服务不需要认证你调用的模型叫什么名字model name名字写错是最常见的坑你的模型支持哪些能力function calling、tool use、流式输出这决定了 WorkBuddy 能不能用 Agent 模式把这几个问题想清楚配置就成功了一半。后面所有坑几乎都出在这几个问题的答案上。2. 开工前的三张清单模型、密钥与运行环境2.1 模型选型云端 API 与本地模型的取舍动手配置之前先选模型。我先后试过两条路线云端 API 和本地模型。云端路线的代表是 DeepSeek、通义千问、智谱 GLM 这类对外提供 API 的模型服务。优点是模型能力强、部署零成本缺点是每次请求都走公网、数据要出本地以及按 token 计费。适合追求代码质量、不在意数据出域的场景。本地路线我主要用 Ollama 跑开源模型。优点不用说免费、数据不出本机、响应速度通常也够用缺点是模型能力受限于你的显卡和内存7B 模型在复杂任务上的表现和云端旗舰模型有明显差距。另外如果你没有像样的独立显卡纯 CPU 跑大一点的模型会慢到怀疑人生。我用一张表总结一下我当时纠结的结果对比维度云端 API如 DeepSeek本地模型Ollama代码能力强复杂任务也能顶7B 模型够用14B 以上更稳响应速度取决于网络通常 1-3 秒取决于硬件本地通常在 1 秒内数据安全数据出本地数据完全不出本地成本按 token 计费电费加硬件折旧部署难度低注册拿 Key 就行中要装 Ollama、拉模型我的建议是如果你只是想省点钱接云端 API 就够了配置简单、效果有保障如果你是奔着数据安全去的或者想完全避开网络因素那老老实实走本地模型路线。两者不冲突WorkBuddy 支持多配置我可以随时切换这个后面会讲。2.2 环境准备先装什么、先不装什么确定路线之后别急着打开 WorkBuddy 的配置面板。我踩过的第一个坑就是在没有验证接口可用的情况下直接改配置结果出了问题根本分不清是网络问题还是配置问题。正确的顺序是先把环境准备好再用命令行把接口验证一遍最后才去改 WorkBuddy。环境准备分两种情况如果走本地模型路线先安装 Ollama。装完在终端跑一下ollama pull qwen2.5-coder:7b ollama run qwen2.5-coder:7b能正常对话之后再往下走。注意Ollama 安装完成默认监听在 11434 端口它同时提供原生接口和 OpenAI 兼容接口后者是 WorkBuddy 能接上的关键。如果走云端 API 路线先去对应平台注册账号、创建 API Key。创建完先做一次连通性验证。以 DeepSeek 为例在终端跑curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的API_KEY \ -d {model:deepseek-chat,messages:[{role:user,content:你好}]}返回一段 JSON里面有choices字段说明接口通了。本地 Ollama 也可以这么验curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen2.5-coder:7b,messages:[{role:user,content:你好}]}这里有个细节Ollama 的 OpenAI 兼容地址是http://localhost:11434/v1注意/v1一定要带上。我第一次配置就是漏了/v1结果 WorkBuddy 一直报 404折腾了半小时才反应过来。3. 核心配置步骤从新建配置到第一次对话3.1 找到 WorkBuddy 的配置入口环境验证通过之后就可以回到 WorkBuddy 做配置了。不同版本的入口可能不完全一样但大体逃不出两条路一是设置面板里的模型或 Provider 管理二是在用户目录下的.workbuddy/配置文件里手动编辑。我用的是本地配置文件的方式因为字段全、可控性强改错了也容易回滚。我这边实际生效的配置文件路径是~/.workbuddy/config.json如果你的系统里没有这个文件创建一个就行。配置内容长这样{ providers: [ { name: deepseek, baseUrl: https://api.deepseek.com, apiKey: sk-xxxxxxxxxxxxxxxx, models: [ { name: deepseek-chat, type: chat, maxTokens: 8192 } ] }, { name: local-ollama, baseUrl: http://localhost:11434/v1, apiKey: ollama, models: [ { name: qwen2.5-coder:7b, type: chat, maxTokens: 4096 } ] } ], activeProvider: deepseek, activeModel: deepseek-chat }这个结构不是我瞎编的是我自己配置时试出来的形态。它基本对应了大多数同类 AI 助手的 Provider 配置范式一个 provider 代表一个模型服务来源里面可以挂多个模型。如果你用的是企业内部自建网关或者某些中转平台配置结构也类似只是 baseUrl 和 apiKey 不同。3.2 配置项逐字段拆解很多人喜欢直接复制网上的配置但不知道每个字段是干什么的一旦报错就抓瞎。我逐个说一遍我理解的含义nameprovider 的名称纯粹是给你自己看的起个好认的名字比如deepseek、local-ollama、company-gateway。baseUrl模型服务的基础地址。这是最关键也最容易填错的字段。要注意云端 API 有些平台要求填到域名根路径有些要求填到/v1Ollama 的 OpenAI 兼容接口则必须带/v1。拿不准的时候把你已经在命令行验证过的地址复制过来不要手敲。apiKey认证凭证。本地 Ollama 一般不校验 Key随便填一个非空字符串就能过云端 API 必须填真实有效的 Key。我建议把 Key 放到环境变量里引用而不是明文写进配置文件尤其是你的配置文件可能要提交到公司仓库时。models模型列表。每个模型对象里name要和模型服务实际支持的名字完全一致。DeepSeek 的对话模型叫deepseek-chat推理模型叫deepseek-reasoner名字写错直接 404。maxTokens单次最大输出 token 数。设置太小代码生成到一半会截断设置太大又可能超过模型服务的限制导致报错。主流平台的上下文长度普遍到 8K 以上我日常设 8192够用。activeProvider/activeModel默认生效的 provider 和 model对应你在界面上看到的当前模型。除了这些基础字段还有一些高级参数我在后面调优时才会动比如temperature、stream、customHeaders。customHeaders用来给请求附加自定义 HTTP 头有些企业内部模型网关会要求带特定 header 鉴权这时候就需要它。3.3 第一次对话怎么判断配置真的生效了配置保存之后别急着让它改代码先在对话窗口发一句最简单的你好观察三件事第一是否能正常返回内容。如果返回空或者报错说明请求根本没出去或者出去之后被拒了。这时候去看 WorkBuddy 的日志通常在配置文件同目录下有个logs/文件夹也可以直接在日志面板里看。第二对话是否带模型名标识。如果你配了多个模型界面会显示当前用的是哪个方便你确认切换到的到底是不是目标模型。第三响应速度是否正常。如果等了十几秒才出第一个字多半是网络问题或者模型服务端负载太高。第一次对话跑通之后我建议立刻做一个实战验证给它一段故意写错的代码让它定位问题并修复。这一步能同时验证两个关键能力模型能不能理解代码上下文以及 WorkBuddy 的文件读写能力是否正常联动。如果只是对话正常但改不了文件那后面所有自动化都无从谈起。4. 踩坑记录我在这条路上摔过的六个跟头这是大家最想看的部分。我从接入到现在前前后后遇到过十来个报错挑了六个最有代表性、也最可能复现的写出来。每一个我都尽量还原当时的报错信息、排查思路和最终解法。4.1 模型名写错接口直接 404第一次配置云端 DeepSeek 的时候我在配置里写了model: deepseek-coder因为这是个很熟悉的名字觉得肯定没错。结果 WorkBuddy 一直报404 model_not_found。我用命令行一测发现平台要求的是deepseek-chat。教训是模型名不是你以为的名字而是模型服务文档里写的那个名字。配置前打开官方文档核对一下或者用平台的模型列表接口拉一下比瞎猜靠谱得多。4.2 baseUrl 少了/v1被 404 折腾半小时刚才提到过这个坑我在 Ollama 上踩过。WorkBuddy 调的是 OpenAI 兼容接口地址必须是http://localhost:11434/v1而不是裸的http://localhost:11434。云端有些平台也类似根路径和带/v1的路径返回的内容可能完全不同。我的排查方法很简单先用命令行 curl 跑通再原封不动把地址复制进配置不要手动补路径。4.3 temperature 设置过高代码变成了散文接本地模型之后一开始我图新鲜把所有参数都拉满temperature 直接调到了 1.5。结果模型生成的代码注释倒是写得很美像抒情散文但变量名一会儿一个风格函数逻辑大跳步基本不能用。后来我把 temperature 降到 0.2 左右代码风格立刻稳了。对于代码生成任务temperature 不是越高越有创造性而是越低越可控。这个参数我在后面调优部分还会细讲。4.4 模型不支持 function callingAgent 模式直接哑火这是我踩过最严重的一个坑。我先把 WorkBuddy 的配置切到一个轻量本地模型上想节省成本结果发现它只能聊天不能改文件也没有工具调用行为。查了日志才发现模型服务在响应里拒绝了功能调用请求。原因是那个模型版本不支持 function calling。这就是我前面说的——不是所有模型都具备 Agent 能力。WorkBuddy 的改代码、跑命令、管理文件这些能力依赖底层的工具调用模型不支持上层功能就全瘫痪。解决方法是换一个支持 function calling 的模型或者让轻量模型只做问答把代码操作类任务留在更强的主模型上。4.5 maxTokens 设太小代码生成到一半被截断有一次我让它写一个完整的配置文件写到一半突然断了末尾也没有正常收尾。一开始我以为是模型能力问题后来看日志发现返回长度正好卡在maxTokens的上限。我设的是 2048确实太小了。生成一个上百行的配置文件很容易就超。后来我把代码生成任务的 maxTokens 提到 8192截断问题就再没出现过。这个参数要结合你的实际任务来定宁可设大一点也不要频繁截断否则生成结果没法直接用还得二次加工更浪费时间。4.6 配置里有多个 provider切来切去忘了当前是哪个这个问题不算报错但很影响体验。我有 local-ollama 和 deepseek 两个 provider每次切换都要回配置文件改activeProvider。有次我急着干活忘了切回来结果聊天是正常的但一让它改代码就报工具调用失败我排查了半天才意识到用的是本地轻量模型。后来我养成了一个习惯在 WorkBuddy 的对话首句先确认当前模型比如直接问你当前用的是哪个模型通常它会从系统信息里拿到准确的名字。多模型混用的时候这个确认动作能省很多事。我把上面这些坑汇总成一张排查表留着以后参考现象可能原因排查顺序404 / model_not_found模型名写错用 curl 请求验证模型名连接拒绝 / 无法访问baseUrl 错误或漏/v1对比命令行验证过的地址响应为空或长时间无响应网络问题或服务端负载高看 WorkBuddy 日志代码风格飘、逻辑乱temperature 过高降到 0.2 以下重试不能改文件、不能调工具模型不支持 function calling换成支持工具调用的模型输出被截断maxTokens 太小调大 maxTokens5. 接入稳定之后参数调优与日常工作流磨合5.1 不同任务推荐参数配方接入稳定之后我开始琢磨怎么让模型在具体场景下发挥得更好。同样的模型参数不一样效果天差地别。我总结了一套自己的配方不一定适合所有人但思路可以参考。任务类型推荐模型temperaturemaxTokens说明代码补全本地 7B coder 模型0.1 - 0.22048 - 4096追求确定性温度越低越好Bug 解释与修复云端强模型0.2 - 0.34096 - 8192需要较强的理解能力代码重构云端强模型0.3 - 0.48192适度创造但别飘单元测试生成任意 coder 模型0.28192输出格式稳定最重要技术方案讨论云端强模型0.74096可以保留一点发散性这里最核心的一条是我反复验证过的在代码场景里temperature 普遍要控制在 0.4 以下尤其是补全和生成测试几乎都是低温更稳。只有做方案讨论、头脑风暴这类不立即落地的任务才值得把温度调高。另外如果你接的是 deepseek-reasoner 这类推理模型它在输出答案之前会先输出一段 reasoning 内容推理模型的 temperature 往往有额外限制配置时可以留意一下模型文档里的说明。5.2 多模型切换的小技巧我一直保留两个 provider一个本地一个云端切换方式是通过改activeProvider。但每次都改文件太累了我的做法是建了两个配置文件一个默认用本地模型一个默认用云端模型需要切换时直接替换配置文件再重启 WorkBuddy。你也可以看 WorkBuddy 的设置界面是否支持直接切换支持的话会更方便。另一个技巧是给不同模型设置不同的使用场景记在本子上或者写在配置的注释里。比如我的规则是日常快速问答用本地代码生成和重构用云端涉及公司敏感业务代码一律切本地。这个规则固定下来之后我基本不会再出现用错模型的情况。5.3 日常使用中的三条纪律最后分享几个让我少踩坑的日常习惯。第一条别让模型猜上下文。WorkBuddy 能读取当前打开的文件但你要明确告诉它关注哪个文件、解决什么问题。我自己写 prompt 的固定结构是项目背景一句话 我要做什么 约束条件。背景信息越清晰代码生成质量越高也能少烧 token。第二条定期清理会话上下文。长会话会让上下文越塞越满一方面是 token 消耗直线上升另一方面是模型注意力被无关内容稀释回答质量下降。我的习惯是每个任务开启新会话最长不超过二十轮对话。第三条密钥永远不要写死在代码里。配置文件里的 apiKey 我后来全部换成了环境变量引用比如在终端设置export WORKBUDDY_DEEPSEEK_KEYsk-xxx然后在配置文件里用${WORKBUDDY_DEEPSEEK_KEY}引用。这样即使配置文件被误分享也不会泄露密钥。折腾完自定义模型接入我最大的感受是AI 编程助手的能力边界其实有一半掌握在使用者手里。官方模型很好但未必适合每一个场景和每一条数据边界要求接自定义模型的过程看着麻烦可是一旦跑通你会获得一种工具真正归我管的控制感。最后再分享一个小细节如果你的 WorkBuddy 配置了本地 Ollama 模型建议在系统登录项里把 Ollama 设置为开机自启免得每天早上打开 WorkBuddy 发现连不上本机模型还要手动敲一次ollama serve。这种小坑藏不住只有天天用的人才能发现。