Crush 换成 AIGoCode 后仍用旧模型？先查 crushrc 的四处引用

切换供应商时，先列出配置中的模型引用

在 Crush 中增加了 AIGoCode Provider，保存后却不确定当前究竟使用哪组模型配置，可以先做一轮引用核对。单看新增的服务地址，无法确认文件中其他位置和界面的选择是否已经对应。

AIGoCode 的Crush 接入文档使用 crushrc 文件配置 Provider 与模型，示例随后分别设置 model large 和 model small，并在启动后通过 Switch Model 选择模型。本文围绕已有配置迁移，整理需要一起检查的位置，避免只新增连接信息便把迁移记为完成。

先确认编辑的是文档所列的配置文件

官方文档要求文件名为 crushrc，不带扩展名。Windows 在 %USERPROFILE%\.config\crush 下创建该文件；macOS / Linux 对应 ~/.config/crush 目录。

如果你刚从其他工具复制了一份配置，先确认保存的文件名和目录与此处一致。不要因为另一个客户端使用 JSON，就自行把文件改名为 crushrc.json。已有配置建议先备份，再加入所需 Provider 和模型项，避免整份替换时丢掉原有内容。

下面提到的 provider add、model add、model large 和 model small 都是官方示例写入 crushrc 的配置语句。不要把它们误当作要逐行粘到系统终端执行的安装命令。安装与版本检查仍可按文档单独进行。

第一组核对：Provider 类型、地址与模型 ID

先决定本次要加入哪一种协议，再按照对应列检查文档示例：

地址应按 Crush 这一页的具体示例填写。尤其是 Claude 示例带 /v1，应保留当前工具文档的写法，避免在没有核对说明的情况下自行去掉路径。对协议地址仍有疑问时，可以参考Base URL 与工具地址的区别，再回到当前工具的文档核对。

API Key 使用对应分组的 Key。表中的 Provider 名用于本地配置引用，模型 ID 则需对照实际可用模型，不要把给 Provider 起别名等同于可以随意重命名远端模型。

第二组核对：沿完整标识检查三条模型语句

以 OpenAI 示例为例，文档把 aigocode-openai/gpt-6-astra 用在三处：model add、model large、model small。建议把它们放在同一张检查表中比较：

例如，已经新增 aigocode-claude 和对应模型，却只修改了 model large，便应继续检查 model small 中是否仍留下旧值。这里的操作目的是发现配置引用不一致，不据此推断所有任务会使用哪一个模型，也不假定 large 和 small 可以随意互换。

若你有意保留不同模型，先把预期写清楚，再分别核对；本文只使用官方示例中两项都指向同一模型的方式作为对照基线。需要采用更复杂的模型分工时，应另行查证其行为。

第三组核对：启动后的选择与实际回复

保存文件后运行 crush，进入 Commands，选择 Switch Model，再选择 AIGoCode 模型。官方接入说明以发送消息后收到回复作为验证步骤。

建议按顺序保留三项不含密钥的记录：

1. 配置核对：编辑的文件位置、Provider 名和模型完整标识。
2. 界面核对：在 Switch Model 中实际选择了哪个模型。
3. 回复核对：发送简短消息后，是否收到正常回复；失败则记录脱敏错误与发生时间。

这三项分别对应文件、选择和调用结果。仅看文件已经保存，或只看到模型出现在列表中，都还没有完成回复验证。一次成功也只覆盖当次选择的配置，不代表另外两种协议同样验证通过。

仍无法确认时，用这份清单交接排查

向同事或支持说明问题时，可以提供工具版本、配置文件路径、选用协议、Provider 名、模型 ID、是否已执行 Switch Model 及脱敏错误。完整 Key 不进入截图或共享材料。

如果症状已经是明确的认证或额度错误，继续参照AIGoCode 401/403 排查。若只是迁移后不清楚哪处仍引用旧模型，就先完成本文的名称对照，再决定修改哪一个值，避免把多个配置变化混在一次排查中。