#workbuddy

Work companion best sample 🥹🌺

source from Xiaohongshu @米米meko

用 PowerShell 自动维护 WorkBuddy models.json：备份、去重和批量写入模型

如果只是给 WorkBuddy 添加一个自定义模型，手动编辑 models.json 也能完成。

但如果你经常切换模型、批量添加模型、更新 API 地址，手动维护就容易变成重复劳动：

每次修改前要手动备份。

多个模型字段要反复复制。

URL 可能忘记补 /v1。

同名模型可能重复写入。

JSON 格式一旦写坏，WorkBuddy 可能读不到配置。

这篇文章用一个 PowerShell 脚本为例，拆解如何自动维护 WorkBuddy 的 models.json。

示例脚本仓库：

https://github.com/xujfcn/workbuddy-crazyrouter

本文重点讲脚本设计思路，不要求你一定使用同一个模型服务。你可以根据自己的环境修改 Base URL、模型列表和能力字段。

---

1. 脚本要解决什么问题？

一个实用的 WorkBuddy 配置脚本，至少要解决这些问题：

| 问题 | 脚本处理方式 |

|---|---|

| 配置文件不存在 | 自动创建目录和文件 |

| 旧配置可能有用 | 写入前自动备份 |

| URL 写法不一致 | 自动规范化 Base URL |

| 模型重复 | 按模型 ID 去重 |

| 需要批量写入 | 支持模型列表参数 |

| 想重置旧配置 | 支持替换模式 |

| 不想交互输入 Key | 支持环境变量 |

这类脚本的目标不是“炫技”，而是减少手动编辑配置文件带来的不确定性。

---

2. 参数设计

脚本开头定义了一组参数：

param( [string]$ApiKey = $env:CRAZYROUTER_API_KEY, [string]$BaseUrl = "https://cn.crazyrouter.com", [string[]]$Models = @( "claude-opus-4-8", "claude-opus-4-7", "claude-sonnet-4-6", "gpt-5.5", "gpt-5.4" ), [string]$ConfigPath = (Join-Path $HOME ".workbuddy\models.json"), [switch]$ReplaceCrazyrouter, [switch]$NoBackup )

这几个参数分别负责：

$ApiKey：模型服务 API Key

$BaseUrl：接口基础地址

$Models：要写入的模型 ID 列表

$ConfigPath：WorkBuddy 配置文件路径

$ReplaceCrazyrouter：是否替换旧的同类配置

$NoBackup：是否跳过备份

参数化的好处是：脚本不用每次改源码。

例如你想换模型列表：

.\setup-workbuddy-crazyrouter.ps1 -Models "model-a", "model-b"

想换接口地址：

.\setup-workbuddy-crazyrouter.ps1 -BaseUrl "https://api.example.com"

---

3. 从环境变量读取 API Key

脚本默认从环境变量读取 Key：

[string]$ApiKey = $env:CRAZYROUTER_API_KEY

这样可以避免把 Key 写死在脚本里。

临时设置方式：

$env:CRAZYROUTER_API_KEY="sk-你的Key"

如果没有环境变量，脚本会提示输入：

$secureKey = Read-Host "请输入 API Key" -AsSecureString

这里使用 SecureString，至少可以避免输入时明文显示在终端上。

不过要注意：最终 Key 仍然需要写入 WorkBuddy 本地配置文件，否则 WorkBuddy 无法调用模型。

所以真正的安全重点是：

不要把配置文件发给别人。

不要把 API Key 截图到公开平台。

不要把包含 Key 的 models.json 提交到 Git 仓库。

---

4. Base URL 规范化

很多接口地址需要以 /v1 结尾。

但用户输入可能是：

https://api.example.com

也可能是：

https://api.example.com/

或者已经是：

https://api.example.com/v1

脚本通过函数统一处理：

function Normalize-BaseUrl { param([Parameter(Mandatory = $true)][string]$Url) $normalized = $Url.Trim().TrimEnd("/") if ([string]::IsNullOrWhiteSpace($normalized)) { throw "BaseUrl cannot be empty." } if ($normalized -notmatch "^https?://") { throw "BaseUrl must start with http:// or https://" } if ($normalized -notmatch "/v1$") { $normalized = "$normalized/v1" } return $normalized }

这段逻辑做了三件事：

1. 去掉首尾空格和末尾 /。

2. 检查是否以 http:// 或 https:// 开头。

3. 如果没有 /v1，自动补上。

这可以避免很多接口路径错误。

---

5. 读取已有模型配置

配置文件可能不存在，也可能为空。

WorkBuddy 自定义模型不生效？models.json、base_url 和模型 ID 排错清单

WorkBuddy 支持自定义模型后，很多开发者会尝试接入自己的模型服务或 OpenAI 兼容接口。

配置本身并不复杂，但实际使用时经常会遇到这些情况：

配置写完了，模型列表里没出现。

模型出现了，但一调用就报错。

同一个模型出现了好几次。

改完 models.json 后 WorkBuddy 启动异常。

不确定 base_url 到底该怎么写。

这篇文章整理一个排错清单，帮助你从文件路径、JSON 格式、接口地址、模型 ID、API Key、备份恢复几个方面逐项检查。

---

1. 先确认 models.json 路径

用户级配置文件通常在：

%USERPROFILE%\.workbuddy\models.json

PowerShell 中可以这样查看：

$ConfigPath = Join-Path $HOME ".workbuddy\models.json" Write-Host $ConfigPath Test-Path $ConfigPath

如果返回 False，说明文件不存在。

这时可能有两种情况：

1. WorkBuddy 还没有生成用户级模型配置。

2. 你需要手动创建 .workbuddy 目录和 models.json 文件。

可以用脚本自动创建，也可以手动创建。

---

2. 配置后必须完全重启 WorkBuddy

很多人改完配置后，只是关闭窗口，然后马上重新打开。

但有些桌面程序可能仍然有后台进程。

建议：

1. 退出 WorkBuddy。

2. 打开任务管理器。

3. 确认 WorkBuddy 相关进程已经结束。

4. 再重新启动。

如果程序没有重新读取配置，模型列表就不会更新。

---

3. 检查 JSON 格式是否正确

models.json 必须是合法 JSON。

常见错误包括：

少逗号

错误示例：

{ "id": "model-a" "name": "model-a" }

正确示例：

{ "id": "model-a", "name": "model-a" }

多余逗号

错误示例：

[ {"id": "model-a"}, ]

标准 JSON 不允许最后一个元素后面多逗号。

引号错误

JSON 字符串必须使用英文双引号：

{ "id": "model-a" }

不要写成：

{ 'id': 'model-a' }

PowerShell 可以尝试读取验证：

Get-Content $HOME\.workbuddy\models.json -Raw | ConvertFrom-Json

如果这里报错，说明 JSON 格式有问题。

---

4. 检查配置结构是不是数组

很多 WorkBuddy 自定义模型配置是数组结构，例如：

[ { "id": "model-a", "name": "model-a", "vendor": "Custom", "url": "https://api.example.com/v1", "apiKey": "sk-xxx" } ]

如果你写成单个对象：

{ "id": "model-a", "name": "model-a" }

程序可能无法按预期读取。

如果你不确定结构，可以参考官方文档或先备份，再用自动化脚本生成一份标准结构。

---

5. 检查 base_url 是否带 /v1

很多 OpenAI 兼容接口的基础地址需要以 /v1 结尾。

例如：

https://api.example.com/v1

如果你只写：

https://api.example.com

调用时可能会找不到正确接口。

如果你写成：

https://api.example.com/v1/v1

WorkBuddy 如何配置自定义模型？从 models.json 到 PowerShell 自动化

WorkBuddy 支持自定义模型，这意味着你不一定只能使用默认模型，也可以把符合接口规范的第三方模型服务接入进来。

很多教程会直接告诉你“修改 models.json”，但对新手来说，真正麻烦的不是知道要改哪个文件，而是：

models.json 放在哪里？

每个字段分别是什么意思？

url 要不要带 /v1？

API Key 写错了怎么办？

改坏 JSON 后怎么恢复？

多次添加同一个模型会不会重复？

这篇文章从工程角度讲清楚 WorkBuddy 自定义模型配置的基本原理，并给出一个 PowerShell 自动化脚本示例，用来减少手动编辑 JSON 的出错概率。

> 说明：本文重点是 WorkBuddy 自定义模型配置方法和脚本自动化思路，不讨论具体模型服务优劣。

---

1. WorkBuddy 自定义模型配置的基本思路

WorkBuddy 的自定义模型，本质上是把模型信息写入本地配置文件。

常见配置项包括：

| 字段 | 含义 |

|---|---|

| id | 模型 ID，用于在配置中唯一标识模型 |

| name | 展示名称，通常可以和 id 一致 |

| vendor | 供应商类型，自定义模型通常是 Custom |

| url | API 接口地址 |

| apiKey | 调用接口所需的 Key |

| supportsToolCall | 是否支持工具调用 |

| supportsImages | 是否支持图片输入 |

| supportsReasoning | 是否支持推理模式 |

| useCustomProtocol | 是否使用自定义协议 |

一个简化后的模型配置可能长这样：

{ "id": "example-model", "name": "example-model", "vendor": "Custom", "url": "https://api.example.com/v1", "apiKey": "sk-xxx", "supportsToolCall": true, "supportsImages": false, "supportsReasoning": false, "useCustomProtocol": false }

真正使用时，WorkBuddy 会读取这些配置，并在模型列表里显示对应的自定义模型。

---

2. models.json 在哪里？

用户级配置文件通常在：

%USERPROFILE%\.workbuddy\models.json

换成 PowerShell 里的路径，大概是：

$HOME\.workbuddy\models.json

例如 Windows 用户名是 alice，那路径可能是：

C:\Users\alice\.workbuddy\models.json

如果这个文件不存在，可以手动创建，也可以通过脚本自动创建。

---

3. 手动编辑 models.json 容易出哪些问题？

手动编辑不是不行，但比较容易踩坑。

3.1 JSON 格式错误

比如少一个逗号：

{ "id": "model-a" "name": "model-a" }

这个 JSON 就是错误的。

正确写法：

{ "id": "model-a", "name": "model-a" }

3.2 url 少了 /v1

很多 OpenAI 兼容接口要求地址以 /v1 结尾，例如：

https://api.example.com/v1

如果只写：

https://api.example.com

就可能导致 WorkBuddy 拼接接口路径时找不到正确 endpoint。

3.3 模型重复写入

如果你多次复制粘贴配置，可能会出现多个相同 id 的模型。

这样不仅难维护，也可能导致 WorkBuddy 读取时出现混乱。

3.4 改坏后没有备份

很多人第一次改配置时，没有先备份原文件。

一旦格式改坏，想恢复就比较麻烦。

所以比较稳妥的做法是：

1. 修改前先备份。

2. 写入时做 JSON 格式校验。

3. 对同名模型执行更新，而不是重复追加。

4. 保留其它已有自定义模型。

---

4. 用 PowerShell 自动化配置

下面这个开源脚本就是为了解决这些问题：

https://github.com/xujfcn/workbuddy-crazyrouter

它做的事情很简单：

找到 WorkBuddy 的 models.json

如果文件不存在就创建

如果文件存在就先备份

读取已有模型配置

合并新的自定义模型

对同名模型去重

把接口地址规范成 /v1

写回 JSON 文件

一键执行方式：

iwr https://raw.githubusercontent.com/xujfcn/workbuddy-crazyrouter/main/setup-workbuddy-crazyrouter.ps1 -UseB | iex

脚本会提示输入 API Key。输入的 Key 只会写入本机 WorkBuddy 配置文件。

如果不想交互输入，也可以先设置环境变量：

$env:CRAZYROUTER_API_KEY="sk-你的Key" iwr https://raw.githubusercontent.com/xujfcn/workbuddy-crazyrouter/main/setup-workbuddy-crazyrouter.ps1 -UseB | iex

执行完成后，需要完全退出并重新打开 WorkBuddy，然后在模型列表中选择 Custom / 自定义模型。