workbuddy 不运行大模型，需配置外部服务；模型必须正确定义在 models.json 中并匹配平台适配性，否则技能调用失败；验证需重启应用并测试 endpoint 与 prompt mapping。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy 本身不直接运行大模型，它依赖外部服务（如 Ollama、腾讯云 API 或本地部署的兼容接口）提供模型能力。所谓“配置最适合的大模型”，本质是：选对模型定位 + 匹配平台适配性 + 正确写入 models.json 配置项。盲目套用热门模型，反而会导致技能调用失败、格式错乱、任务卡死。
为什么不能直接在 WorkBuddy 界面里选“Qwen3.5”或“Gemma4”？
WorkBuddy 的模型选择器只显示你手动添加并成功验证过的模型条目。它不会自动发现 Ollama 已下载的模型，也不会识别未按规范配置的远程 API 地址。如果你在菜单里看不到 qwen3.5:4b-q4_K_M 或 gemma4:26b-moe，大概率是 models.json 中的 endpoint、model 字段没对齐 Ollama 的实际服务行为。
- Ollama 默认监听
http://127.0.0.1:11434，但 WorkBuddy 要求endpoint必须以/v1/chat/completions结尾（Ollama 原生不带该路径，需加代理或用兼容层） -
model字段必须严格等于ollama run后输入的标识符，比如qwen3.5:4b-q4_K_M≠qwen3.5，少一个 tag 就会返回model not found - macOS 用户若启用了防火墙，可能拦截
127.0.0.1:11434，导致 WorkBuddy 连接超时，但终端里ollama list显示正常——这是最常被忽略的网络层问题
GLM-5.0 和 Kimi-K2-Thinking 怎么选？
这不是性能对比题，而是分工题。WorkBuddy 的技能链（如 docx、batch_file_process）底层调用逻辑不同：
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
-
GLM-5.0是执行型模型：输出结构稳定、token 控制精准、能严格遵循「保存到路径」「禁止生成 JS」等指令，适合所有需要调用技能的任务 -
Kimi-K2-Thinking是分析型模型：上下文理解深、长文本推理强，但输出不可控，容易把docx技能触发成裸写 Word 的 HTML/JS 混合体，造成「生成中」卡死 - 不要用
Kimi-K2-Thinking直接调docx技能——它根本没被适配该技能的 prompt schema，WorkBuddy 会静默降级为纯文本生成
如何验证 models.json 配置是否生效？
改完 ~/.workbuddy/models.json 后，必须完全退出 WorkBuddy 进程（macOS 在 Dock 右键选「退出」，Windows 在任务栏右键选「退出」），再重新启动。仅刷新或重启窗口无效。
验证步骤：
- 打开 WorkBuddy → 左侧菜单「设置」→「模型」→ 查看是否出现你添加的条目（名称可自定义，但状态栏不能显示 ❌）
- 选中该模型 → 输入测试指令，例如：
请用中文输出“模型连接正常”四个字，不要加任何标点或换行 - 如果返回乱码、空响应、或报错
Connection refused，检查endpoint是否可被 curl 访问：curl http://127.0.0.1:11434/api/chat -d '{"model":"qwen3.5:4b-q4_K_M","messages":[{"role":"user","content":"hi"}]}' - 如果 curl 成功但 WorkBuddy 失败，说明
models.json里的endpoint缺少了 Ollama 兼容层（如使用ollama-proxy或openai-compatible-server）
最易被忽略的一点：WorkBuddy 对模型的“适配性”不是由参数决定的，而是由腾讯云预置的 skill-prompt mapping 决定的。哪怕你本地跑着 Qwen3.5，只要没进 GLM/Kimi 的白名单，就无法触发 docx 技能——这时候强行配置，只会让你陷入“模型在线、技能不动”的死循环。
