2026年10月我终于把 Codex 桌面端和 WorkBuddy CLI 这套组合彻底调通了。先放结论除了软件安装和模型下载那会儿后面所有代码补全、自然语言改代码、跨文件重构请求全部走了本地推理云端积分一个点都没动过。这篇文章就把完整配置方法、每一步背后的原因、我踩过的坑全部写出来照着抄就能复现。如果你现在正在用某个商业 AI 编程助手的桌面端同时又觉得每个月积分根本不够烧那么这套“桌面端 本地 CLI 调度层”的思路应该能帮到你。整篇文章的核心就一句话借助 WorkBuddy CLI 的本地路由能力把 Codex 桌面端的请求全部导到本地模型服务上实现真正意义上的零云端积分消耗。适合已经会基本命令行操作、有一定动手能力但不想在配置上反复折腾的开发者。1. 这套搭配的核心思路与关键设计1.1 Codex 桌面端到底解决什么问题先说 Codex 桌面端本身。它是一个把 AI 编程能力装进本地窗口的客户端聊天式改代码、自动补全、跨文件重构、错误解释这些功能它都有。以前我在命令行里用 AI 写代码遇到问题还要来回复制粘贴有了桌面端之后直接把当前文件内容、终端报错、整个项目结构甩给它就行确实省了不少事。但桌面端默认的商业方案是按积分走的。一次普通的函数补充还好如果是跨文件重构或者让它帮你排查一个问题反复出方案积分消耗非常快。我的体验是如果是高强度用一天几千积分根本撑不住经常到下午就开始省着用。这个痛点是真实的也是我愿意折腾整套配置的核心原因。1.2 WorkBuddy CLI 在这套方案里的真实定位WorkBuddy CLI 不是另一个 AI 助手它的角色更像一个“请求调度中枢”。它本身不提供模型能力而是管理模型服务、处理请求转发、维护上下文、记录日志。你可以把它理解成一个本地运行的 API 网关专门干一件事情把客户端发过来的 AI 请求按照规则转发到指定的模型服务上。为什么要引入 CLI 而不是直接在 Codex 桌面端里填一个本地服务地址原因很简单桌面端的自定义服务设置通常很简陋只能填一个基础地址和密钥但实际使用场景要复杂得多。比如不同任务要切换不同模型、代码补全用轻量模型、复杂重构用大参数模型、上下文长度要自动适配、请求日志要保留排查问题。这些逻辑如果在桌面端里配置会很僵但在 WorkBuddy CLI 里就可以用配置文件很灵活地实现。1.3 积分零消耗的实现原理一句话讲透很多人第一次听“积分零消耗”会觉得是不是走了什么漏洞其实完全没有。原理就是默认情况下Codex 桌面端把请求发到云端 API按 token 计费所以积分一直在扣。而我们做的是在桌面端设置里把 API 地址改成指向本机的一个 HTTP 服务比如http://127.0.0.1:8787而 WorkBuddy CLI 在这个端口上启动了本地模型推理。请求从桌面端发出后直接打到本机数据不出电脑推理由本地显卡完成。既然请求根本没经过商业计费通道积分自然不会动。这套逻辑的关键前提有两个。第一Codex 桌面端支持自定义 API 端点这个在设置里就能找到。第二WorkBuddy CLI 需要能够在本地拉起一个兼容的推理服务并且暴露 HTTP 接口。两者一配合零积分就是顺理成章的事没有任何灰色操作。1.4 整套架构的数据流拆解我把完整的数据流画成文字描述方便你理解Codex 桌面端发起请求 ↓ 自定义 API 地址 http://127.0.0.1:8787 ↓ WorkBuddy CLI 收到请求 ↓ 路由规则判断 → 选择本地模型 / 调整参数 ↓ 本地推理服务显卡/内存加载模型 ↓ 生成结果原路返回 Codex 桌面端这个链路里最值得注意的就是 WorkBuddy CLI 在中间做了一层“翻译”。因为 Codex 桌面端默认的请求格式是商业 API 的格式直接把它发给本地模型服务经常会不通。WorkBuddy CLI 做的事情就是把桌面端的请求格式转换为本地推理服务能理解的格式再把结果转回去。可以说没有这一层转换桌面端和本地模型之间根本没法直接对话。2. 配置前的环境准备硬件、工具、模型2.1 硬件评估你的机器到底能不能跑本地模型先说最重要的硬件问题。本地推理绕不开显卡尤其代码模型对显存的占用比普通对话模型要高一些。我这个方案能不能跑得动第一看显存第二看内存。我整理了不同规模模型对显存的需求供参考模型规模参数量预期显存占用4bit 量化适合场景轻量模型1B ~ 3B2GB ~ 4GB代码补全、简单问答中等模型7B ~ 8B5GB ~ 7GB日常函数编写、重构建议重量模型13B ~ 14B9GB ~ 12GB复杂逻辑推理、跨文件重构旗舰模型30B20GB全场景但普通人基本不用考虑如果你手里的卡是常见的入门级独显8GB 显存左右建议直接用 7B 或 8B 量级的模型兼顾质量和速度。如果是核显或纯 CPU 环境也不是完全不能用但速度会慢很多建议选择 3B 以下的模型。内存方面模型加载时要额外占一部分内存一般建议至少 16GB32GB 会更从容。2.2 安装 WorkBuddy CLI 和本地推理服务这里我用的本地推理服务不是某个具体的重量级框架而是 WorkBuddy CLI 内置的轻量推理引擎装好 CLI 之后它会自动携带。安装过程非常简单就几步# 这里是 macOS / Linux 环境 curl -fsSL https://workbuddy.example.com/install.sh | bash # 安装完成之后确认 CLI 版本 workbuddy --versionWindows 用户可以直接下载免安装压缩包解压后把可执行文件所在目录加到 PATH 里。安装完成后需要一个配置文件来告诉 CLI 怎么启动本地服务。我的配置文件放在~/.workbuddy/config.yaml初始内容如下server: host: 127.0.0.1 port: 8787 timeout: 120 model: path: ~/.workbuddy/models/code-qwen-7b-q4.gguf context: 16384 gpu_layers: 32这里有几个参数我解释一下。port决定了 Codex 桌面端要连接的端口8787 是我自己定的你完全可以用其他端口只要两边一致。context是上下文长度16384 对于代码任务来说比较舒服太短的话让它看整个文件时会报超长。gpu_layers表示把模型多少层放到 GPU 上计算如果你的显存足够可以把这个值调大推理速度会明显提升如果显存不够推理会掉到 CPU 上速度直线下降。2.3 模型下载与格式选择模型文件是整个配置里最花时间的部分但也是最关键的。我建议选择 GGUF 格式的模型因为这个格式对量化支持好加载稳定WorkBuddy CLI 对它的兼容性也是最好的。下载可以直接用 CLI 内置命令# 拉取一个 7B 级别的代码模型 workbuddy model pull code-qwen-7b-q4如果你的网络情况不太理想也可以手动下载模型文件放到配置里指定的目录。下载完成之后强烈建议先跑一遍命令测试模型能否正常加载workbuddy model test --config ~/.workbuddy/config.yaml这条命令会加载模型然后给一句简单的提示词请求生成。如果这个测试不通过后面桌面端配置了也白搭。2.4 手动验证本地推理服务能通在进入桌面端配置之前先把底层通路验证好。我习惯用curl直接发一个最小请求看看服务能不能正常响应curl http://127.0.0.1:8787/v1/chat/completions \ -H Content-Type: application/json \ -d { model: local, messages: [{role: user, content: 用一个 Python 函数计算斐波那契数列}] }如果返回的 JSON 里出现了content字段并且里面是正常代码就说明本地推理服务已经通了。这一步很值得花时间验证因为后面 Codex 桌面端的接入本质上是同一个通路只是请求格式略有不同。注意这一步测试如果超时先别急着找桌面端的问题先把模型加载、端口监听这两个基础项排查清楚。很多时候你以为的配置问题其实只是模型没加载成功。3. 核心配置流程把桌面端指向本地服务3.1 修改 Codex 桌面端的 API 端点设置这是整套配置里最关键的一步直接决定了积分到底还扣不扣。进入 Codex 桌面端的设置界面找到“自定义 API 端点”或“API 服务地址”相关选项。不同版本的入口不太一样但通常都在设置中的“模型”或“高级”分类下。填写的内容非常简单API Base URL: http://127.0.0.1:8787/v1 API Key: sk-local-workbuddy这里有个容易踩坑的点API Key项即使本地服务不需要校验也一定要填一个值哪怕随便填一长串字母都行因为桌面端代码里可能默认校验这个字段非空。我当时就因为这个没填客户端一直提示认证失败查了半天才发现就是没给 Key 填占位符。另外API Base URL结尾的/v1一定要保留。Codex 桌面端在发送请求时会在这个基础路径后面拼接chat/completions这个路径。如果你省略了/v1请求就会打到http://127.0.0.1:8787/chat/completions而 WorkBuddy CLI 监听的路径默认带/v1前缀两边对不上直接 404。配置完成之后保存设置重启 Codex 桌面端让配置生效。3.2 在 WorkBuddy CLI 中配置路由规则桌面端改完接下来让 WorkBuddy CLI 这边把接收到的请求正确转发到本地模型。我的config.yaml在基础配置之上加了一段路由规则routes: default: model: local temperature: 0.2 max_tokens: 2048 code_refactor: model: local temperature: 0.1 max_tokens: 4096这段配置的意思是所有请求默认走local这个模型温度系数设置为 0.2因为代码生成需要确定性温度太高容易产出不稳定的代码最大 token 值 2048。如果请求类型被识别为重构类任务则切换到更克制的 0.1 温度和更长的输出上限。为什么要单独设一个重构场景因为跨文件重构需要模型一次性输出大段代码2048 token 可能不够用我实际测下来 4096 才比较稳。如果你只用一个默认配置遇到大改动的场景容易输出被截断零零碎碎的代码看着恼火。配置好之后启动本地服务workbuddy server start --config ~/.workbuddy/config.yaml启动命令执行后CLI 会保持在前台运行打印日志。日志里会显示本地服务的监听地址和端口。确认之后再回到终端用刚才的 curl 测试命令跑一遍确保路由规则没把请求搞挂。3.3 验证积分是否真的零消耗这一步很多人会忽略但我强烈建议做。我的方法很简单分三步第一步打开 Codex 桌面端的设置面板记录当前积分余额或者截图。第二步在桌面端里正常问几个问题比如“帮我写一个处理 CSV 文件的 Python 脚本”“解释一下这段代码的时间复杂度”聊差不多十分钟。第三步再次查看积分余额。如果余额完全没变说明请求确实没有走到云端计费通道验证通过。如果余额变了就说明请求还是打了云端这时候立刻停止使用回头检查 API Base URL 是否指向了本地端口以及 WorkBuddy CLI 服务是否真的在监听。我自己的实测结果是连续一整天高强度使用积分余额跟早上完全一样纹丝不动。这也让我彻底放心了。3.4 断网测试法最硬的验证方式如果觉得看积分余额不够放心我还有一个更硬核的验证方式断网测试。断开路由器的 WAN 口或者直接在电脑上关闭 Wi-Fi 和有线连接然后继续在 Codex 桌面端里发请求。如果请求依然能返回正常结果那百分百说明 AI 推理发生在本地因为云端通道已经完全断了。如果请求报错说明有某个环节还在试图访问外网基本上就是配置没生效。这个方法简单粗暴但确实是最有效的。我建议在正式投入使用前至少做一次断网测试确认本地链路可靠。不然等到哪天真断网了才发现配置有问题那才是真正的尴尬。4. 常见问题与排查技巧实录4.1 请求 404路径对不上这是我遇到频率最高的问题。表现是 Codex 桌面端发请求后WorkBuddy CLI 日志里出现404 Not Found的报错。原因基本就是路径不匹配。桌面端请求的路径可能是http://127.0.0.1:8787/chat/completions但 WorkBuddy CLI 监听的路径是http://127.0.0.1:8787/v1/chat/completions。排查方法很简单在 WorkBuddy CLI 日志中看一眼完整的请求 URL再对比一下你填在桌面端的 Base URL。如果日志里显示的是chat/completions而没有/v1前缀就在桌面端的 API Base URL 末尾补上/v1再重启客户端。4.2 请求通了但响应特别慢这个先看是不是模型加载时的 GPU 层数设置不合适。如果gpu_layers设置得太小大部分计算都跑在 CPU 上速度会慢得让人怀疑人生。建议先查看一下模型加载日志里面会显示当前有多少层跑在 GPU、多少层跑在 CPU。如果 GPU 层数为 0那跑得慢就太正常了。试试把gpu_layers往大了调。但注意如果设置的层数超过模型总层数或者在加载时显存不够推理服务可能直接崩溃。我的习惯是先从合理值开始观察显存占用再逐步调高。4.3 中文注释乱码或输出质量不稳定代码模型如果训练语料以英文为主生成大量中文注释时经常会出现奇怪的口吻或者病句。这个问题的根源不在配置而在模型选型。我的建议是优先选择在代码和中文语料上都有过专门训练的模型尽量不要用纯英文代码模型跑中文项目。另外在 WorkBuddy CLI 的配置里加一条系统提示词也是个有效手段model: system_prompt: 你是一名资深软件工程师回复使用简体中文代码注释使用中文代码本身保持英文标识符。加了这个之后输出质量会明显稳定很多。但这只解决风格问题如果模型本身的代码能力不够系统提示词也救不了。4.4 本地模型效果和云端模型差距明显这是很多人的顾虑也是事实。以 7B 量级的本地模型和顶尖云端模型相比在复杂代码推理上确实有差距。但日常使用中代码补全、简单 bug 排查、常见算法实现、小规模重构本地 7B 模型已经够用了。我实际使用体验是大概能满足日常开发的八成需求剩下的两成复杂场景我才会临时切回云端。如果你确实需要更强的本地模型可以考虑 13B 甚至更大参数的模型但显存需求会同步上升。我的建议是从 7B 开始先跑一周感受一下如果明显感觉能力不够再升级。4.5 桌面端更新后配置失效商业桌面端软件在升级时偶尔会重置自定义端点配置。如果你发现某天积分突然开始扣了先别慌去设置里看一眼 API Base URL 是不是被还原成了默认云端地址。这是很常见的情况重新填一次本地地址就行。如果频繁发生建议把配置方法记在本子上升级后第一时间检查。5. 个人实践中的几个补充建议整套配置跑通到现在有小一个月了最直接的感受是AI 编程助手终于从“按次计费”变成了“随便用”。以前我改一个大函数之前都要犹豫一下现在直接让本地模型陪我折腾反复出方案、反复试错一点心理负担都没有。这种自由感才是生产力提升的真正来源。最后分享两个小技巧。第一个WorkBuddy CLI 里有缓存开关打开之后完全相同的请求会在本地直接返回缓存结果速度翻倍还不耗资源。配置里加一行cache: true就行。第二个如果你有多个本地模型可以用路由规则按任务类型做分流补全类请求走轻量模型重构类请求走重量模型这样既保证速度又兼顾质量。这套配置折腾下来我的经验就一句话不要急着一口气全配好先保证底层链路通再一层一层往上接。希望大家都能跑通早日告别积分焦虑。
2026年10月我终于把 Codex 桌面端和 WorkBuddy CLI 这套组合彻底调通了。先放结论除了软件安装和模型下载那会儿后面所有代码补全、自然语言改代码、跨文件重构请求全部走了本地推理云端积分一个点都没动过。这篇文章就把完整配置方法、每一步背后的原因、我踩过的坑全部写出来照着抄就能复现。如果你现在正在用某个商业 AI 编程助手的桌面端同时又觉得每个月积分根本不够烧那么这套“桌面端 本地 CLI 调度层”的思路应该能帮到你。整篇文章的核心就一句话借助 WorkBuddy CLI 的本地路由能力把 Codex 桌面端的请求全部导到本地模型服务上实现真正意义上的零云端积分消耗。适合已经会基本命令行操作、有一定动手能力但不想在配置上反复折腾的开发者。1. 这套搭配的核心思路与关键设计1.1 Codex 桌面端到底解决什么问题先说 Codex 桌面端本身。它是一个把 AI 编程能力装进本地窗口的客户端聊天式改代码、自动补全、跨文件重构、错误解释这些功能它都有。以前我在命令行里用 AI 写代码遇到问题还要来回复制粘贴有了桌面端之后直接把当前文件内容、终端报错、整个项目结构甩给它就行确实省了不少事。但桌面端默认的商业方案是按积分走的。一次普通的函数补充还好如果是跨文件重构或者让它帮你排查一个问题反复出方案积分消耗非常快。我的体验是如果是高强度用一天几千积分根本撑不住经常到下午就开始省着用。这个痛点是真实的也是我愿意折腾整套配置的核心原因。1.2 WorkBuddy CLI 在这套方案里的真实定位WorkBuddy CLI 不是另一个 AI 助手它的角色更像一个“请求调度中枢”。它本身不提供模型能力而是管理模型服务、处理请求转发、维护上下文、记录日志。你可以把它理解成一个本地运行的 API 网关专门干一件事情把客户端发过来的 AI 请求按照规则转发到指定的模型服务上。为什么要引入 CLI 而不是直接在 Codex 桌面端里填一个本地服务地址原因很简单桌面端的自定义服务设置通常很简陋只能填一个基础地址和密钥但实际使用场景要复杂得多。比如不同任务要切换不同模型、代码补全用轻量模型、复杂重构用大参数模型、上下文长度要自动适配、请求日志要保留排查问题。这些逻辑如果在桌面端里配置会很僵但在 WorkBuddy CLI 里就可以用配置文件很灵活地实现。1.3 积分零消耗的实现原理一句话讲透很多人第一次听“积分零消耗”会觉得是不是走了什么漏洞其实完全没有。原理就是默认情况下Codex 桌面端把请求发到云端 API按 token 计费所以积分一直在扣。而我们做的是在桌面端设置里把 API 地址改成指向本机的一个 HTTP 服务比如http://127.0.0.1:8787而 WorkBuddy CLI 在这个端口上启动了本地模型推理。请求从桌面端发出后直接打到本机数据不出电脑推理由本地显卡完成。既然请求根本没经过商业计费通道积分自然不会动。这套逻辑的关键前提有两个。第一Codex 桌面端支持自定义 API 端点这个在设置里就能找到。第二WorkBuddy CLI 需要能够在本地拉起一个兼容的推理服务并且暴露 HTTP 接口。两者一配合零积分就是顺理成章的事没有任何灰色操作。1.4 整套架构的数据流拆解我把完整的数据流画成文字描述方便你理解Codex 桌面端发起请求 ↓ 自定义 API 地址 http://127.0.0.1:8787 ↓ WorkBuddy CLI 收到请求 ↓ 路由规则判断 → 选择本地模型 / 调整参数 ↓ 本地推理服务显卡/内存加载模型 ↓ 生成结果原路返回 Codex 桌面端这个链路里最值得注意的就是 WorkBuddy CLI 在中间做了一层“翻译”。因为 Codex 桌面端默认的请求格式是商业 API 的格式直接把它发给本地模型服务经常会不通。WorkBuddy CLI 做的事情就是把桌面端的请求格式转换为本地推理服务能理解的格式再把结果转回去。可以说没有这一层转换桌面端和本地模型之间根本没法直接对话。2. 配置前的环境准备硬件、工具、模型2.1 硬件评估你的机器到底能不能跑本地模型先说最重要的硬件问题。本地推理绕不开显卡尤其代码模型对显存的占用比普通对话模型要高一些。我这个方案能不能跑得动第一看显存第二看内存。我整理了不同规模模型对显存的需求供参考模型规模参数量预期显存占用4bit 量化适合场景轻量模型1B ~ 3B2GB ~ 4GB代码补全、简单问答中等模型7B ~ 8B5GB ~ 7GB日常函数编写、重构建议重量模型13B ~ 14B9GB ~ 12GB复杂逻辑推理、跨文件重构旗舰模型30B20GB全场景但普通人基本不用考虑如果你手里的卡是常见的入门级独显8GB 显存左右建议直接用 7B 或 8B 量级的模型兼顾质量和速度。如果是核显或纯 CPU 环境也不是完全不能用但速度会慢很多建议选择 3B 以下的模型。内存方面模型加载时要额外占一部分内存一般建议至少 16GB32GB 会更从容。2.2 安装 WorkBuddy CLI 和本地推理服务这里我用的本地推理服务不是某个具体的重量级框架而是 WorkBuddy CLI 内置的轻量推理引擎装好 CLI 之后它会自动携带。安装过程非常简单就几步# 这里是 macOS / Linux 环境 curl -fsSL https://workbuddy.example.com/install.sh | bash # 安装完成之后确认 CLI 版本 workbuddy --versionWindows 用户可以直接下载免安装压缩包解压后把可执行文件所在目录加到 PATH 里。安装完成后需要一个配置文件来告诉 CLI 怎么启动本地服务。我的配置文件放在~/.workbuddy/config.yaml初始内容如下server: host: 127.0.0.1 port: 8787 timeout: 120 model: path: ~/.workbuddy/models/code-qwen-7b-q4.gguf context: 16384 gpu_layers: 32这里有几个参数我解释一下。port决定了 Codex 桌面端要连接的端口8787 是我自己定的你完全可以用其他端口只要两边一致。context是上下文长度16384 对于代码任务来说比较舒服太短的话让它看整个文件时会报超长。gpu_layers表示把模型多少层放到 GPU 上计算如果你的显存足够可以把这个值调大推理速度会明显提升如果显存不够推理会掉到 CPU 上速度直线下降。2.3 模型下载与格式选择模型文件是整个配置里最花时间的部分但也是最关键的。我建议选择 GGUF 格式的模型因为这个格式对量化支持好加载稳定WorkBuddy CLI 对它的兼容性也是最好的。下载可以直接用 CLI 内置命令# 拉取一个 7B 级别的代码模型 workbuddy model pull code-qwen-7b-q4如果你的网络情况不太理想也可以手动下载模型文件放到配置里指定的目录。下载完成之后强烈建议先跑一遍命令测试模型能否正常加载workbuddy model test --config ~/.workbuddy/config.yaml这条命令会加载模型然后给一句简单的提示词请求生成。如果这个测试不通过后面桌面端配置了也白搭。2.4 手动验证本地推理服务能通在进入桌面端配置之前先把底层通路验证好。我习惯用curl直接发一个最小请求看看服务能不能正常响应curl http://127.0.0.1:8787/v1/chat/completions \ -H Content-Type: application/json \ -d { model: local, messages: [{role: user, content: 用一个 Python 函数计算斐波那契数列}] }如果返回的 JSON 里出现了content字段并且里面是正常代码就说明本地推理服务已经通了。这一步很值得花时间验证因为后面 Codex 桌面端的接入本质上是同一个通路只是请求格式略有不同。注意这一步测试如果超时先别急着找桌面端的问题先把模型加载、端口监听这两个基础项排查清楚。很多时候你以为的配置问题其实只是模型没加载成功。3. 核心配置流程把桌面端指向本地服务3.1 修改 Codex 桌面端的 API 端点设置这是整套配置里最关键的一步直接决定了积分到底还扣不扣。进入 Codex 桌面端的设置界面找到“自定义 API 端点”或“API 服务地址”相关选项。不同版本的入口不太一样但通常都在设置中的“模型”或“高级”分类下。填写的内容非常简单API Base URL: http://127.0.0.1:8787/v1 API Key: sk-local-workbuddy这里有个容易踩坑的点API Key项即使本地服务不需要校验也一定要填一个值哪怕随便填一长串字母都行因为桌面端代码里可能默认校验这个字段非空。我当时就因为这个没填客户端一直提示认证失败查了半天才发现就是没给 Key 填占位符。另外API Base URL结尾的/v1一定要保留。Codex 桌面端在发送请求时会在这个基础路径后面拼接chat/completions这个路径。如果你省略了/v1请求就会打到http://127.0.0.1:8787/chat/completions而 WorkBuddy CLI 监听的路径默认带/v1前缀两边对不上直接 404。配置完成之后保存设置重启 Codex 桌面端让配置生效。3.2 在 WorkBuddy CLI 中配置路由规则桌面端改完接下来让 WorkBuddy CLI 这边把接收到的请求正确转发到本地模型。我的config.yaml在基础配置之上加了一段路由规则routes: default: model: local temperature: 0.2 max_tokens: 2048 code_refactor: model: local temperature: 0.1 max_tokens: 4096这段配置的意思是所有请求默认走local这个模型温度系数设置为 0.2因为代码生成需要确定性温度太高容易产出不稳定的代码最大 token 值 2048。如果请求类型被识别为重构类任务则切换到更克制的 0.1 温度和更长的输出上限。为什么要单独设一个重构场景因为跨文件重构需要模型一次性输出大段代码2048 token 可能不够用我实际测下来 4096 才比较稳。如果你只用一个默认配置遇到大改动的场景容易输出被截断零零碎碎的代码看着恼火。配置好之后启动本地服务workbuddy server start --config ~/.workbuddy/config.yaml启动命令执行后CLI 会保持在前台运行打印日志。日志里会显示本地服务的监听地址和端口。确认之后再回到终端用刚才的 curl 测试命令跑一遍确保路由规则没把请求搞挂。3.3 验证积分是否真的零消耗这一步很多人会忽略但我强烈建议做。我的方法很简单分三步第一步打开 Codex 桌面端的设置面板记录当前积分余额或者截图。第二步在桌面端里正常问几个问题比如“帮我写一个处理 CSV 文件的 Python 脚本”“解释一下这段代码的时间复杂度”聊差不多十分钟。第三步再次查看积分余额。如果余额完全没变说明请求确实没有走到云端计费通道验证通过。如果余额变了就说明请求还是打了云端这时候立刻停止使用回头检查 API Base URL 是否指向了本地端口以及 WorkBuddy CLI 服务是否真的在监听。我自己的实测结果是连续一整天高强度使用积分余额跟早上完全一样纹丝不动。这也让我彻底放心了。3.4 断网测试法最硬的验证方式如果觉得看积分余额不够放心我还有一个更硬核的验证方式断网测试。断开路由器的 WAN 口或者直接在电脑上关闭 Wi-Fi 和有线连接然后继续在 Codex 桌面端里发请求。如果请求依然能返回正常结果那百分百说明 AI 推理发生在本地因为云端通道已经完全断了。如果请求报错说明有某个环节还在试图访问外网基本上就是配置没生效。这个方法简单粗暴但确实是最有效的。我建议在正式投入使用前至少做一次断网测试确认本地链路可靠。不然等到哪天真断网了才发现配置有问题那才是真正的尴尬。4. 常见问题与排查技巧实录4.1 请求 404路径对不上这是我遇到频率最高的问题。表现是 Codex 桌面端发请求后WorkBuddy CLI 日志里出现404 Not Found的报错。原因基本就是路径不匹配。桌面端请求的路径可能是http://127.0.0.1:8787/chat/completions但 WorkBuddy CLI 监听的路径是http://127.0.0.1:8787/v1/chat/completions。排查方法很简单在 WorkBuddy CLI 日志中看一眼完整的请求 URL再对比一下你填在桌面端的 Base URL。如果日志里显示的是chat/completions而没有/v1前缀就在桌面端的 API Base URL 末尾补上/v1再重启客户端。4.2 请求通了但响应特别慢这个先看是不是模型加载时的 GPU 层数设置不合适。如果gpu_layers设置得太小大部分计算都跑在 CPU 上速度会慢得让人怀疑人生。建议先查看一下模型加载日志里面会显示当前有多少层跑在 GPU、多少层跑在 CPU。如果 GPU 层数为 0那跑得慢就太正常了。试试把gpu_layers往大了调。但注意如果设置的层数超过模型总层数或者在加载时显存不够推理服务可能直接崩溃。我的习惯是先从合理值开始观察显存占用再逐步调高。4.3 中文注释乱码或输出质量不稳定代码模型如果训练语料以英文为主生成大量中文注释时经常会出现奇怪的口吻或者病句。这个问题的根源不在配置而在模型选型。我的建议是优先选择在代码和中文语料上都有过专门训练的模型尽量不要用纯英文代码模型跑中文项目。另外在 WorkBuddy CLI 的配置里加一条系统提示词也是个有效手段model: system_prompt: 你是一名资深软件工程师回复使用简体中文代码注释使用中文代码本身保持英文标识符。加了这个之后输出质量会明显稳定很多。但这只解决风格问题如果模型本身的代码能力不够系统提示词也救不了。4.4 本地模型效果和云端模型差距明显这是很多人的顾虑也是事实。以 7B 量级的本地模型和顶尖云端模型相比在复杂代码推理上确实有差距。但日常使用中代码补全、简单 bug 排查、常见算法实现、小规模重构本地 7B 模型已经够用了。我实际使用体验是大概能满足日常开发的八成需求剩下的两成复杂场景我才会临时切回云端。如果你确实需要更强的本地模型可以考虑 13B 甚至更大参数的模型但显存需求会同步上升。我的建议是从 7B 开始先跑一周感受一下如果明显感觉能力不够再升级。4.5 桌面端更新后配置失效商业桌面端软件在升级时偶尔会重置自定义端点配置。如果你发现某天积分突然开始扣了先别慌去设置里看一眼 API Base URL 是不是被还原成了默认云端地址。这是很常见的情况重新填一次本地地址就行。如果频繁发生建议把配置方法记在本子上升级后第一时间检查。5. 个人实践中的几个补充建议整套配置跑通到现在有小一个月了最直接的感受是AI 编程助手终于从“按次计费”变成了“随便用”。以前我改一个大函数之前都要犹豫一下现在直接让本地模型陪我折腾反复出方案、反复试错一点心理负担都没有。这种自由感才是生产力提升的真正来源。最后分享两个小技巧。第一个WorkBuddy CLI 里有缓存开关打开之后完全相同的请求会在本地直接返回缓存结果速度翻倍还不耗资源。配置里加一行cache: true就行。第二个如果你有多个本地模型可以用路由规则按任务类型做分流补全类请求走轻量模型重构类请求走重量模型这样既保证速度又兼顾质量。这套配置折腾下来我的经验就一句话不要急着一口气全配好先保证底层链路通再一层一层往上接。希望大家都能跑通早日告别积分焦虑。
