Claude 第三方模型路线变严后，还能怎么接 DeepSeek？cc-switch + Claude Code Windows 实测
Claude 第三方模型路线变严后，本文实测用 cc-switch 在 Windows 上将 Claude Code 切到 DeepSeek provider，并记录 PowerShell ps1、JSON BOM、status / doctor 验证等关键坑位。
需要继续找相关内容？
如果你想继续查工具名、术语、对比页或相关问题，可以直接搜全站，不用回到博客列表页重找。
核心结论
这次 Windows 实测中，cc-switch 可以作为 Claude Code 的 provider 切换器，把 Claude Code 路线切到 DeepSeek；但它不是 Claude 破解工具，也不是所有 coding agent 的通用转接器。
适合谁看
适合已经使用 Claude Code，并想在 Windows 上测试 DeepSeek provider、排查 PowerShell ps1 拦截和 JSON 配置问题的开发者。
关键判断
关键验证信号是 `Active: DeepSeek` 和 doctor 检查通过；如果 PowerShell 拦截 npm 生成的 `.ps1` shim，可以先用 `cmd /c cc-switch` 区分 shell 入口问题和 provider 配置问题。
下一步建议
先安装 `@adithya-13/cc-switch`，配置 DeepSeek provider，再用 status / doctor 验证，最后重启 Claude Code 并用小任务确认链路。
你将学到
- + cc-switch 在 Claude Code + DeepSeek 路线里到底解决什么问题
- + 为什么这条路线不能写成 Codex 也能直接使用
- + Windows 上 PowerShell `.ps1` shim 被拦时怎么排查
- + JSON BOM 配置错误为什么会让 provider 读取失败
- + 如何用 Active: DeepSeek 和 doctor 检查确认链路
前段时间我刚做过一版 Claude 桌面版接入 DeepSeek 的教程。没想到没过多久，Claude 对第三方模型调用的限制开始明显变严，很多以前能跑通的配置方式，突然就不好使了。
这类问题最烦人的地方不是“报错”，而是你很难判断到底是哪一层坏了：是 Claude 侧限制了？是配置文件写错了？是 Windows 命令执行被拦了？还是 DeepSeek 的 API 本身有问题？
这次我换了一条路线，用 cc-switch 重新测试 Claude Code 接入 DeepSeek。结论先说清楚：
cc-switch 不是 Claude 破解工具，也不是所有 AI 编程工具都能用的万能转接器。它更像是一个 provider 切换器，把模型名、Base URL、API Key 等配置整理成可切换的 provider。你要走官方 Claude，就切回官方；你要测试 DeepSeek，就切到 DeepSeek。
这条路线主要服务的是 Claude Code。Codex 这类工具不能直接照搬，这一点不要误解。
为什么需要 cc-switch？
以前很多人接第三方模型，会手动改配置文件。模型名改一遍，Base URL 改一遍，API Key 再改一遍。短期看能用，长期看非常容易乱。
尤其是当 Claude 官方路线、DeepSeek 路线、其他兼容 API 路线混在一起时，你很难知道当前环境到底在用哪个 provider。
cc-switch 的价值就在这里：它让“切换模型后端”这件事变得更明确。
安装命令是：
npm install -g @adithya-13/cc-switch注意包名不是 cc-switch，而是：
@adithya-13/cc-switch安装之后，核心不是立刻去跑大任务，而是先把 DeepSeek provider 配好，然后用 status 和 doctor 这类命令确认当前链路是否干净。
Windows 上最容易踩的两个坑
我这次实测是在 Windows 上做的。Windows 的问题很典型：很多时候不是模型不行，而是命令执行环境先把你卡住了。
第一个坑是 PowerShell。
npm 全局安装命令以后，Windows 上常会生成 .ps1 入口脚本。PowerShell 的执行策略可能会拦住它，导致你输入 cc-switch 以后并不是正常执行，而是被安全策略挡掉。
这时候不用急着怀疑 DeepSeek，也不用急着重装。可以先换成：
cmd /c cc-switch这是一个很普通但很有效的排查动作。先确认工具本身能跑起来，再继续看 provider 配置。
第二个坑是 JSON 配置文件的 BOM。
我这里就踩了一次：配置文件看起来没问题，但 cc-switch 读取 JSON 时直接报错。后来发现是文件编码里带了 BOM。修掉以后，配置就能被正常解析。
所以如果你手工编辑 provider 配置，建议确认 JSON 是无 BOM 的 UTF-8。
怎么判断真的接上了？
很多教程最容易跳过的部分，就是“验证”。
我不建议只看到命令不报错，就认为已经接上 DeepSeek。至少要看到两类信号：
Active: DeepSeek以及 doctor 检查通过。
只有 status 显示当前 provider 已经切到 DeepSeek，并且 doctor 没有继续报配置问题，再重启 Claude Code，才算这条链路真正搭起来。
我的建议是：不要一上来就拿大项目测试。先让 Claude Code 执行一个很小的任务，比如读取目录、解释一个简单文件、生成一个短脚本。小任务能跑通，再进入真实工程。
这条路线适合谁？
适合三类人：
第一类，是之前已经用过 Claude Code，但最近第三方模型路线突然不稳定的人。
第二类，是想把 DeepSeek 放进 Claude Code 工作流里做测试的人。
第三类，是不想每次都手改配置、希望 provider 切换更清楚的人。
但它不适合所有场景。
如果你想让 Codex 直接走这条链路，目前不行。Codex 和 Claude Code 的调用链路不同，不能因为 cc-switch 能服务 Claude Code，就推导出它也能服务 Codex。
这个边界必须讲清楚。否则教程看起来很热闹，真正落地时只会让人更困惑。
我的实操结论
这次测试下来，cc-switch + DeepSeek + Claude Code 在 Windows 上是可以跑通的，但它不是一个“装完就万事大吉”的方案。
真正要注意的是三件事：
- 包名要装对：
@adithya-13/cc-switch - Windows 上遇到 PowerShell 拦截，优先试
cmd /c cc-switch - provider 配置文件不要带 BOM，切换后用
status和doctor验证
最后再强调一次：这不是破解 Claude，也不是万能模型转接器。它只是给 Claude Code 用户提供了一条更清晰的 provider 切换路线。
如果你的 Claude Code 现在还能接上 DeepSeek，可以对照这几个点检查一下：到底是官方限制变了，还是你卡在 Windows 命令、配置文件编码、provider 切换这些更具体的问题上。
继续看：Windows 上的 AI 编程智能体实测
如果你也在 Windows 上折腾 AI 编程工具，可以继续看这几篇实测：
继续延伸
要点总结
- - cc-switch 更像 provider 切换器，不是 Claude 破解工具。
- - 这条实测路线主要是 Claude Code -> cc-switch -> DeepSeek，不能直接扩写成 Codex -> cc-switch -> DeepSeek。
- - Windows 上先把命令入口、配置编码和 provider 状态验证清楚，再进入真实项目。
常见问题
Claude Code 还能通过 cc-switch 接 DeepSeek 吗？
本文记录的是 Windows 实测路线：Claude Code 通过 cc-switch 切到 DeepSeek provider，可以跑通，但需要先处理 provider 配置、PowerShell 入口和 JSON 编码问题。
cc-switch 是 Claude 破解工具吗？
不是。它更像 provider 切换器，用来管理模型名、Base URL、API Key 等 provider 配置。
Codex 可以通过 cc-switch 接 DeepSeek 吗？
不能按本文路线直接照搬。本文边界是 Claude Code -> cc-switch -> DeepSeek，Codex 的调用链路不同。
Windows 上 cc-switch 被 PowerShell 拦截怎么办？
可以先尝试 `cmd /c cc-switch`，确认是否是 PowerShell `.ps1` shim 执行策略问题，再继续检查 provider 配置。
