前段时间我刚做过 Claude 接 DeepSeek 的教程。没想到没过多久，Claude 对第三方模型调用的限制明显变严，很多以前能跑通的老配置，突然就不好用了。
这类问题最折磨人的地方，不是它直接告诉你“不支持”，而是你会看到一堆很模糊的现象：命令跑不起来、配置不生效、Claude Code 重启以后没变化、模型好像没切过去。到底是 Claude 限制了，还是 Windows 命令被拦了，还是配置文件写错了，往往要一点点排。
这次我换了一条路线：用 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。刚开始你可能还能记住，等配置多了以后，自己都不一定知道现在连的是哪个 provider。
而 cc-switch 的价值不是“神奇”，是把切换动作变明确。它让你知道当前 provider 是什么，也方便你在官方 Claude、DeepSeek、其他兼容路线之间切换。
安装命令是：
npm install -g @adithya-13/cc-switch
注意，包名不是单独的 cc-switch，而是 @adithya-13/cc-switch。
装完以后，不要急着拿大项目测试。先把 DeepSeek provider 配好，再用状态检查确认链路。很多 AI 工具调试失败，其实不是模型不行，而是第一步配置状态都没确认清楚。
Windows 上两个坑，我都踩到了
第一个坑是 PowerShell。
npm 全局安装以后，Windows 上经常会生成 .ps1 入口脚本。PowerShell 的执行策略可能会拦住这个脚本。你以为是 cc-switch 坏了，或者 DeepSeek 接不上，其实只是命令入口没被允许执行。
遇到这种情况，可以先试：
cmd /c cc-switch
这个动作很小，但能帮你判断问题到底在工具本身，还是在 PowerShell 的执行策略。先把 shell 层面的障碍排掉，再继续看 provider。
第二个坑是 JSON 配置文件编码。
我这次配置 DeepSeek provider 时，JSON 看着没问题，但 cc-switch 读取时一直报错。最后发现是文件带了 BOM。把配置文件改成无 BOM 的 UTF-8 后，解析就正常了。
这就是 Windows 上很常见的“小坑”：表面看像工具问题，实际只是文件编码。尤其是手动编辑配置文件时，一定要注意这一点。
怎么算真的接上了？
不要只看命令有没有报错。
我这次的判断标准是两个：
Active: DeepSeek
以及 doctor 检查通过。
只有 status 显示当前 provider 已经是 DeepSeek，并且 doctor 没有继续提示配置问题，再重启 Claude Code，才算这条链路真正搭起来。
重启之后，也不要一上来就开大项目。先让 Claude Code 做一个很小的任务，比如读取目录、解释一个文件、生成一个简单脚本。小任务能跑通，再进入真实工程。
这样做的好处是，失败时排查范围更小。否则你一上来就丢一个复杂项目进去，失败以后很难判断是 provider 没接好、模型能力不匹配，还是项目上下文本身太复杂。
这条路线适合哪些人？
如果你之前一直在用 Claude Code，但最近第三方模型突然不好接了，可以试这条路线。
如果你只是想测试 DeepSeek 在 Claude Code 工作流里的表现，也可以试。
如果你已经被各种配置文件折腾烦了，希望官方 Claude、DeepSeek、其他兼容 API 之间切换得更清楚，cc-switch 也有价值。
但如果你想让 Codex 直接通过这条链路接 DeepSeek，目前不适合。Codex 和 Claude Code 的调用方式不是一回事，这一点不要混在一起。
我会怎么排查这类问题？
如果现在有人问我：Claude Code 接 DeepSeek 又失败了，该从哪里查？我不会让他第一步就去换模型、换 Key、重装工具。
我会先看命令入口。Windows 上很多问题不是 AI 工具的问题，而是 PowerShell、路径、权限、执行策略的问题。如果 cc-switch 这个命令本身都没有正常执行，那后面讨论 provider 没有意义。
第二步看 provider 状态。你以为自己切到了 DeepSeek，但实际 active 的可能还是旧配置。这个时候继续改正文配置，只会越改越乱。
第三步看配置文件。尤其是 JSON 文件，肉眼看起来正常不代表工具能正常解析。多一个逗号、少一个引号、文件带 BOM，都可能让工具直接读取失败。
第四步才看 DeepSeek API 本身，比如 Key 是否有效、额度是否正常、Base URL 是否写对。这样排查的好处是，每一步都能把问题范围缩小，而不是靠感觉乱猜。
我也建议把排查过程留成记录。比如哪个命令报错、换成哪个命令后能跑、status 最后显示了什么。下次同样的问题再出现，你不用重新靠感觉排一遍。
对普通用户来说，这种记录不需要很正式，只要能复现就够了。截图、命令、报错原文、最终通过的状态，这几样留下来，后面排查会轻松很多。
为什么我不建议一上来就跑大项目？
很多人刚接好一个工具，就立刻把真实项目丢进去，让 AI 修 bug、改架构、写大功能。这个动作看起来很爽，但其实很不适合排查。
因为大项目失败的原因太多了：可能是 provider 没切好，可能是模型上下文不够，可能是项目结构复杂，也可能只是某个文件权限不对。你没有办法一眼判断。
我更建议先跑小任务。比如让 Claude Code 读取目录、解释一个配置文件、生成一个短脚本。小任务能跑通，再进入真实工程。这样你至少知道基础链路是通的。
这也是我这次实测最大的体会：AI 编程工具不是只要“接上模型”就完事了。真正要长期用，必须让整条链路可检查、可复现、可回退。
我的结论
这次实测下来，cc-switch + DeepSeek + Claude Code 在 Windows 上可以跑通。
但真正影响成功率的，不只是模型本身，而是这些细节：
- 包名要装对：
@adithya-13/cc-switch - PowerShell 拦
.ps1时，用cmd /c cc-switch排查 - JSON 配置不要带 BOM
- 切换后用 status 和 doctor 验证
- 重启 Claude Code，再用小任务确认
这条路线的意义不是“绕过一切限制”，而是在限制变化以后，给 Claude Code 用户留一条更清楚、更可排查的 DeepSeek 测试路径。
如果你也遇到过 Claude Code 接 DeepSeek 的奇怪问题，可以先按这几个点排一遍。很多时候，真正卡住你的不是模型，而是 Windows、配置文件和 provider 状态。
我现在做这类工具实测，会先把“环境问题”和“模型问题”分开看。命令入口能不能执行、配置文件能不能读取、当前 provider 是不是切对，这些都属于环境问题。只有这些都确认以后，再去判断模型表现才有意义。否则很容易把一个很小的 Windows 配置坑，误判成 DeepSeek 不稳定，或者误判成 Claude Code 不兼容。
我后面也会继续把这类 Windows 实测坑整理出来，尤其是 Claude Code、DeepSeek、OpenClaw、Hermes 这些工具在真实环境里的问题。比起只看工具宣传，我更关心它们到底能不能在普通 Windows 机器上稳定跑起来。
还有一个建议：不要把这类工具配置当成一次性动作。每次升级 Claude Code、Node、Windows Terminal 或者代理工具以后，都最好重新跑一遍最小验证。先确认命令能执行，再确认 provider 状态，再确认小任务能跑通。这样做看起来多花几分钟，但能避免你在真正项目里排半天错。对普通 Windows 用户来说，稳定性往往不是靠某一个神奇命令解决的，而是靠这种可重复的检查顺序一点点建立起来的。
