Copilot CLI 接入 AIGoCode：单次 --model 能用，默认模型怎么核对

先分清“这次指定”与“保存默认”

在 GitHub Copilot CLI 中，通过 --model 指定 AIGoCode 模型已经能得到回复，随后只运行 copilot，却不确定是否仍选中了同一模型。这时先保留刚才成功的配置，分别检查模型引用和默认选择，不要立刻重建 Key。

AIGoCode 的Copilot CLI 文档给出两种不同操作：启动时用 copilot --model ... 指定模型；进入工具后用 /model --global 选择并保存默认模型。下面用一份分层记录，把“配置存在”“本次能用”和“默认已保存”分别验证。

第一层：检查文件中的三处名字是否指向同一个对象

官方配置文件位置是 Windows 的 %USERPROFILE%\.copilot\providers.json，或 macOS / Linux 的 ~/.copilot/providers.json。文档要求把 provider 和 model 项加入现有的 providers 与 models 数组。

如果文件原来已有其他服务商，建议先备份，再追加所需条目，保留原有内容。不要把只含一个服务商的整份示例直接覆盖自己的配置，也不要把包含真实 Key 的文件发给别人协助排错。

以文档的 OpenAI 示例为例，需要对照三处名字：

模型条目中的 id 是 gpt-6-astra，它与 Provider 名是两部分。若你自行改了 Provider 名称，应一并核对模型引用和启动参数中的前半段。这里的建议来自官方示例中名字的对应关系，不意味着可以给远端模型随意改 ID。

第二层：先复用完整的单次启动命令

保存配置后，先用文档中明确指定模型的形式检查。OpenAI 示例是 copilot --model aigocode-openai/gpt-6-astra；Claude 示例是 copilot --model aigocode-claude/claude-opus-5-5。

两份配置不要混填：

不要仅因为另一个工具里使用了不同的地址，就把这里两列统一成相同值。示例中的 apiKey 占位符要换为对应分组的真实 Key，但 Key 本身不应进入你的核对笔记。

如果明确指定模型也失败，就先处理连接配置；此时保存默认模型不会替你修复分组、协议或地址不一致。若明确指定后已经能正常回复，则保留这一组配置，进入下一层验证。

第三层：再保存默认选择，并单独验证一次

进入 Copilot CLI 后运行 /model --global，选择刚配置的 AIGoCode 模型。按官方文档，完成这一步后，之后直接运行 copilot 即可使用。

建议完成选择后，另做一次不带 --model 的启动验证，核对所选模型并发送一条简短消息。不要把刚才带参数的成功截图，直接当成默认选择也已验证的证据。

可以留下三条不含密钥的记录：

1. 配置文件核对完成：Provider 名、模型条目中的 provider 与模型 ID 对应。
2. 显式启动核对完成：完整 --model 参数，以及是否收到正常回复。
3. 默认选择核对完成：已执行 /model --global，再次直接启动后的选择与回复结果。

这种拆分便于发现问题停在哪一层，并不对配置优先级、旧会话缓存或所有版本的行为作额外推断。若无法确认，保留工具版本与实际显示的信息，再回到官方说明核对。

报错时，把默认选择问题与请求失败分开记录

官方文档建议在遇到 401、403 或模型错误时，检查 Key 分组、API 地址与模型名称。先记录你是否明确指定了模型，再记录脱敏后的错误；不要一看到报错就把原因归为“默认没保存”。

需要继续排查认证和额度，可以阅读AIGoCode 401/403 排查。尚不清楚不同工具为何要选不同分组时，再看第三方工具接入矩阵。本文处理的是 Copilot CLI 的配置引用、单次指定和默认保存三层核验，不替代这些更基础的检查。