前段时间我刚做过一版 Claude 接 DeepSeek 的教程。结果没过多久，Claude 对第三方模型调用的限制明显变严，很多以前能跑通的配置方式突然失效。这个变化对普通用户很不友好，因为你看到的往往不是一个清晰的“不能用了”，而是一堆很像配置错误、网络错误、权限错误的现象。

我这次重新测了一条更窄的路线：用 cc-switch 把 Claude Code 切到 DeepSeek provider。先把结论放前面：这条路线在我的 Windows 环境里可以跑通，但一定要注意边界。

cc-switch 不是 Claude 破解工具，也不是万能模型转接器。它更像是一个 provider 切换工具，把模型名、Base URL、API Key 这些配置整理成可切换的 provider。你需要官方 Claude 的时候切回官方，需要测试 DeepSeek 的时候切到 DeepSeek。

还有一个很重要的点：这条路线主要服务 Claude Code。Codex 目前不能直接照搬这条链路。不要把“Claude Code 可以切 provider”理解成“所有 AI 编程工具都能这么接 DeepSeek”。

为什么要测 cc-switch？

以前很多人接第三方模型，靠的是手动改配置。今天改模型名，明天改 Base URL，后天换 API Key。短期看能用，长期看很容易乱。尤其是你同时保留官方 Claude、DeepSeek、其他兼容 API 时，很难一眼看出当前环境到底连的是谁。

我测试 cc-switch，主要就是想解决这个问题：不要让配置状态变成黑盒。

安装命令如下：

npm install -g @adithya-13/cc-switch

这里有个很容易装错的地方：包名不是单独的 cc-switch，而是 @adithya-13/cc-switch。如果包名装错，后面所有排查都会变成白忙。

装完以后，不建议立刻拿真实项目测试。更稳的做法是先配置 DeepSeek provider，然后用状态检查确认当前 provider 是否真的切过去。很多人调试 AI 工具时，一上来就让它读整个项目，结果失败以后根本不知道问题在模型、配置、命令还是上下文。

Windows 上第一个坑：PowerShell 拦 ps1

我这次是在 Windows 上测的，所以 Windows 自己的坑也绕不开。

npm 全局安装以后，Windows 经常会生成 .ps1 命令入口。PowerShell 的执行策略可能会拦住这个脚本。你输入 cc-switch，它看起来像是工具不能用，但真实原因可能只是 PowerShell 不让这个入口脚本执行。

遇到这种情况，不要急着重装，也不要马上怀疑 DeepSeek API。可以先换成：

cmd /c cc-switch

这个命令的意义很简单：绕开 PowerShell 的 .ps1 入口，先确认 cc-switch 本体能不能跑起来。如果这样可以执行，说明问题更可能在 PowerShell 执行策略，而不是 provider 配置。

这类问题很适合作为第一步排查，因为它成本低，而且能快速缩小范围。不要把一个 shell 层面的失败误判成模型失败。

Windows 上第二个坑：JSON 配置文件带 BOM

第二个坑更隐蔽：JSON 配置文件编码。

我配置 DeepSeek provider 时遇到过一次，文件看起来没问题，但 cc-switch 读取 JSON 时一直失败。最后发现是文件带了 BOM。把配置文件保存成无 BOM 的 UTF-8 后，解析就正常了。

这个坑非常 Windows。很多编辑器保存中文文件时会自动带上 BOM，而命令行工具读取 JSON 时不一定兼容。表面看是“配置没生效”，本质可能只是文件开头多了几个不可见字节。

所以如果你手动编辑 provider 配置，建议检查三件事：

1. JSON 结构是否正确；
2. API Key 有没有多余空格；
3. 文件是否是无 BOM 的 UTF-8。

这三件事比反复重装工具更值得先做。

怎么判断真的接上了 DeepSeek？

不要只看命令有没有报错。

我这次的判断标准是两个：第一，status 能看到当前 provider 已经是 DeepSeek；第二，doctor 检查通过。

至少要看到类似：

Active: DeepSeek

只有 status 和 doctor 都干净，再重启 Claude Code，这条链路才算真正搭起来。

重启以后，也不要急着开大项目。建议先让 Claude Code 做一个很小的任务，比如读取目录、解释一个简单文件、生成一段短脚本。小任务能跑通，再进入真实工程。这样一旦失败，你能更快判断问题是不是出在 provider 链路本身。

这条路线适合谁？

如果你之前一直用 Claude Code，并且最近发现第三方模型路线突然不好用了，可以试这条路线。

如果你只是想测试 DeepSeek 在 Claude Code 工作流里的表现，也可以试。

如果你已经被各种配置文件折腾烦了，希望官方 Claude、DeepSeek、其他兼容 API 之间切换得更清楚，cc-switch 也有价值。

但如果你想让 Codex 直接通过这条链路接 DeepSeek，目前不适合。Codex 和 Claude Code 的调用链路不是一回事。这个边界一定要讲清楚，否则教程看起来热闹，真正落地时只会让人更困惑。

我建议的排查顺序

如果你已经在 Windows 上装过 Claude Code，也配置过 DeepSeek，但现在突然跑不通，我建议不要从“大修配置”开始。先按一个更小的顺序排查。

第一步，看命令本身能不能执行。也就是先确认 cc-switch 能不能正常响应。如果 PowerShell 直接报执行策略相关的问题，先不要动 DeepSeek 的 Key，先用 cmd /c cc-switch 判断是不是 .ps1 入口被拦。

第二步，看当前 provider 是谁。很多人以为自己切到了 DeepSeek，其实当前环境还停在另一个 provider 上。这个时候你继续调 API Key，只会越调越乱。

第三步，看配置文件能不能被工具正常读取。JSON 结构、逗号、引号、文件编码，这些都要比模型能力更早检查。尤其是 BOM 这种不可见字符，不排掉的话，很容易造成“看起来什么都对，但就是不生效”的错觉。

第四步，再看 DeepSeek 侧的 API Key 和额度。也就是说，模型服务本身应该放在后面判断，而不是第一个背锅。

这个顺序的好处是，每一步都能缩小范围。你不是在“猜”，而是在把问题从 shell、配置、provider、API 这几层拆开。

如果你要写成自己的排查记录，也建议把每一步的命令输出留下来。不要只写“已解决”，要写清楚是哪个命令失败、换成什么命令后恢复、最终 status 显示了什么。以后同样的问题再次出现，这些记录会比记忆可靠得多。

为什么不要直接拿大项目测试？

我不建议刚配置好就把一个真实项目丢给 Claude Code。原因很简单：大项目变量太多。

项目目录权限、文件数量、上下文长度、模型能力、网络状态、工具调用方式，任何一层都可能影响结果。你如果一上来就让它修一个复杂 bug，失败以后很难知道到底是哪一层出问题。

更稳的方式是先做小任务。比如让 Claude Code 读取当前目录，解释一个很短的配置文件，或者生成一个简单脚本。小任务能跑通，说明 provider 链路大概率已经搭好；小任务都不行，那就继续回到 status、doctor、配置文件这些基础检查。

这也是我做 AI 编程工具实测时越来越重视的一点：不要把“能启动”当成“能工作”，也不要把“大任务失败”直接归因到模型不行。先把链路拆清楚，后面的判断才有意义。

我的实测结论

这次测试下来，cc-switch + DeepSeek + Claude Code 在 Windows 上可以跑通，但它不是“装完就万事大吉”的方案。

真正影响成功率的，是这些细节：

1. 包名要装对：@adithya-13/cc-switch
2. PowerShell 拦 .ps1 时，先试 cmd /c cc-switch
3. JSON provider 配置不要带 BOM
4. 切换后必须用 status 和 doctor 验证
5. 重启 Claude Code 后先跑小任务，不要直接上大项目

这条路线的价值不是绕过一切限制，而是在限制变多以后，给 Claude Code 用户一条更清楚、更容易排查的 DeepSeek 测试路径。

延伸阅读：我把更完整的测试记录和后续更新放在主站：

cc-switch + DeepSeek + Claude Code Windows 实测