先说一个很多人没绕过来的结论:Claude Code 在 Windows 上根本不需要装 WSL,原生环境就能跑。官方文档确实默认推荐 Linux / macOS,也给了 WSL 路线,但实际用下来,绝大多数 Windows 用户走“Node + npm + 一条命令”这条路就够了,从安装到能对话,我实测五分钟左右能完成。这篇文章要聊的,就是怎么在 Windows 上找到最短的那条安装路径,装完之后没有官方订阅怎么接第三方模型、怎么调本地模型,以及 Windows 上特有的那堆权限坑和终端问题。
这篇文章适合谁看?如果你跟我一样,主力环境是 Windows,主要干的事是写代码、跑脚本、让 AI 帮忙改文件,想试试 Claude Code 但被网上各种 WSL 教程劝退,那你算是来对地方了。文章会尽量把“为什么”也讲清楚,不是给一堆命令让你复制完就完事。
1. 别急着装 WSL:先想清楚你走哪条安装路径
1.1 官方为什么推荐 WSL,但多数人其实不需要
Claude Code 这工具本质上是基于 Node.js 的命令行程序,核心工作区在终端里,通过读取文件、执行命令来完成各种任务。它最早是在 Unix 环境下打磨的,所以官方文档里给的安装示例,很多都默认你用的是 Linux、macOS,或者 Windows 上的 WSL。
问题是,很多教程直接把 WSL 当成“Windows 上装 Claude Code 的前提条件”,这个说法有点把简单事搞复杂了。WSL 解决的是 Linux 环境兼容性问题,但 Claude Code 本身是 Node.js 写的,跑在 Windows 原生的 Node 环境里没有任何障碍。我自己长期在 Windows 终端、VS Code 集成终端里直接跑 claude,读写 Windows 文件系统、调用 PowerShell 命令、操作 Git,都没有问题。
那什么时候才真的需要 WSL?我总结了两类情况。一类是你接下来的目标环境本身是 Linux 服务器,你希望本地和服务器保持一致的 shell 习惯、路径规则、权限模型;另一类是你主要用 Docker、需要 Linux 下的网络命名空间这种能力,或者你在原生 Windows 终端里遇到了持续无法解决的输入、路径乱码问题。这两类人群占比其实不大,大多数想在 Windows 上尝鲜 Claude Code 的人,直接走原生路径更省事。
1.2 三条主流安装路线对比
我把目前常见的几条路线放在一起对比,你可以直接按自己的情况选:
| 安装路线 | 核心操作 | 适合谁 | 复杂度 |
|---|---|---|---|
| 原生 Windows + Node.js | 装 Node,再 npm 全局安装 @anthropic-ai/claude-code | 日常 Windows 用户、VS Code 用户 | 最低 |
| WSL + Node.js | 先装 WSL,在 Linux 子系统里装 Node 和 Claude Code | 需要 Linux 环境、远程部署、长期在 shell 里工作 | 中 |
| 第三方 GUI / 桌面封装 | 装社区做的图形界面版本 | 不想碰命令行、纯聊天式使用 | 低但功能受限 |
结论很直接:如果你只是想用 Claude Code 来辅助写代码、整理仓库、执行本地任务,选第一行。后面讲的一切,也都是围绕原生 Windows 这条最简单路径展开的。
2. 最短安装链路:Node、npm、一条命令
2.1 准备 Node.js:版本要求与 nvm-windows
先检查你 Windows 上有没有 Node。打开 PowerShell 或 Windows Terminal,输入:
node -v npm -v如果你能看到类似 v20.x.x 和 10.x.x 的输出,说明环境已经有了,直接跳到 2.2 节。如果提示找不到命令,就去 Node.js 官网下载 LTS 版本安装包,一路下一步就行。Claude Code 要求 Node 18 以上,我建议直接用 20 或 22 这种 LTS 版本,别贪新,LTS 稳定,后面少踩很多坑。
这里多提一句给那些经常切换项目的朋友:如果你不只是想装 Claude Code,还可能在电脑上跑不同年代的 Node 项目,那就别用官网安装包了,用nvm-windows来管理 Node 版本。装好之后,你可以随时切换、随时装新版本,避免“为了一个 CLI 工具把全局 Node 搞乱”的尴尬。
winget install OpenJS.NodeJS.LTS用 winget 装完后再用 nvm-windows 也是可以的,本质上都是把 Node 运行时搞定。装完务必重新打开终端,让 PATH 环境变量生效,再执行node -v确认一下。
2.2 全局安装与首次启动
Node 就绪之后,安装 Claude Code 就是一条命令的事:
npm install -g @anthropic-ai/claude-code这里解释一下为什么是“全局安装”。Claude Code 作为一个命令行工具,你需要能在任意目录下直接敲claude启动它。全局安装会让 npm 把可执行文件放到系统 PATH 里,这样你不管在哪个项目文件夹下都能直接唤起。如果你用npx的方式临时跑,也不是不行,但每次都要等 npx 解析包,路径和配置管理也更绕,不符合“最简单”的原则。
安装完成后验证一下:
claude --version看到版本号输出,再直接敲:
claude首次运行会让你走一次登录流程,浏览器里打开授权页面,把你的 Claude 账号和本机绑定,然后把页面上给的一次性 code 粘贴回终端。这一步完成之后,你就在 Windows 原生终端里有了一个能对话、能读文件、能执行命令的 Claude Code。
2.3 升级与卸载
Claude Code 更新很频繁,功能迭代也快,我建议你每隔一两周升一次级。升级同样是一条命令:
npm update -g @anthropic-ai/claude-code卸载则对应:
npm uninstall -g @anthropic-ai/claude-code升级前可以先看一眼自己的版本和官方发布版本的差别,如果只是小版本号变化,直接升就行;升级后如果遇到配置失效之类的问题,多半是新的 CLI 改了命令位或配置文件字段,去官方文档查一下变更记录就清楚了。
3. 装好后没订阅怎么办:三种接入模型的方式
3.1 官方订阅、账号权限与组织限制
很多人把 Claude Code 装好了,结果一打开发现登录都过不去,或者登录后提示没权限。先说正常情况:如果你用的是个人的 Claude 账号,并且有 Pro 或 Max 订阅,那 Claude Code 是可以直接用的,订阅覆盖对话和一定额度的使用量。
但有一种很常见的报错,网上一搜一大把:your organization has disabled claude subscription access for claude code。出现这个,说明你登录的是某个企业/组织的工作区账号,这个组织的管理员在后台把 Claude Code 的访问权限关了。这是组织策略问题,不是你的安装问题。解决办法很简单:换成你个人的 Claude 账号登录,或者找管理员开启权限。如果你压根没有官方订阅,那也别慌,看下面两种接入方式。
3.2 用第三方兼容 API 接 DeepSeek、Qwen、GLM:环境变量原理
Claude Code 的价值在于它的 agent 能力和工具调用机制,但它的对话后端默认指向 Anthropic 官方服务。很多国内用户希望接 DeepSeek、通义千问、GLM 这类模型,或者用一些第三方聚合 API,思路本质上是一样的:让 Claude Code 把请求发到一个你指定的 API 端点。
Claude Code 读取两个关键环境变量:
ANTHROPIC_BASE_URL:决定请求往哪个服务器发ANTHROPIC_AUTH_TOKEN或ANTHROPIC_API_KEY:决定用什么身份认证
直接在 PowerShell 里临时设置也可以:
$env:ANTHROPIC_BASE_URL="https://你的网关地址" $env:ANTHROPIC_AUTH_TOKEN="你的密钥" claude但这里有个坑要注意:Claude Code 原生用的是 Anthropic 的协议格式,而 DeepSeek、通义千问、GLM 官方 API 大多是 OpenAI 兼容格式,两者不能直接画等号。你不能只改个 Base URL 就指望它通,中间需要一个做协议转换的层。我测下来比较好用的是社区里那些 Claude Code Router、CC Switch 之类的工具,它们本质上是把 Anthropic 格式的请求翻译成 OpenAI 兼容格式,再转发给目标模型服务。
CC Switch 是 Anthropic 官方出的一个配置切换工具(Beta),解决的就是在官方订阅、第三方 API、本地模型之间反复切换的麻烦。装好 CC Switch 后,你可以创建多个 profile,每个 profile 里配置不同的 base_url、token、模型名,用命令一下就切过去。比如配一个 DeepSeek 的 profile,把 base_url 指向 DeepSeek 的 Anthropic 兼容端点,再选一个支持 Claude Code 的映射模型,就能在 claude 会话里用上 DeepSeek 的模型了。至于具体是让你编辑 JSON 配置文件还是在交互界面里填表,每个版本有点差别,但原理就这一套,你不懂的时候先抓环境变量和模型名这两个核心就好。
3.3 调本地模型:LM Studio 的接入逻辑
再看另一个高频需求:本地模型,尤其是 LM Studio。
LM Studio 是 Windows 上跑本地模型的利器,它起一个本地服务,默认地址是http://127.0.0.1:1234/v1,提供 OpenAI 兼容的接口。但 Claude Code 不会直接说“我要访问 OpenAI 接口”,它说的是“我要访问 Anthropic 接口”。所以还是得靠协议转换层。
我实际跑通的路径是这样的:
- 在 LM Studio 里加载一个模型,并开启本地服务器,记下端口号(默认 1234)。
- 配置一个路由工具,把 Claude Code 的请求目标
http://127.0.0.1:端口号/v1转换为 OpenAI 兼容调用。 - 在 Claude Code 的环境变量里把 base_url 指向这个路由工具,模型名填 LM Studio 里加载的模型名称(比如
qwen2.5-coder-7b-instruct这种实际加载名)。 - 启动 claude,先跑一句最简单的对话验证链路通不通。
验证的时候可以直接用一个命令测试本地服务和路由层是否正常响应:
curl http://127.0.0.1:1234/v1/models能看到 LM Studio 返回模型列表,说明服务活着;接下来就是路由层和 Claude Code 之间的配合问题了。
要说句实在话:本地模型的算力开销和模型能力直接决定了 Claude Code 的实际体验。Claude Code 非常依赖长上下文和工具调用能力,你要是在一台普通笔记本上跑 7B 参数模型,代码分析、批量改文件这些任务很容易达到能力上限。它适合的更多是“隐私优先、断网也要能用、跑跑小任务”的场景。图省事的话,还是官方订阅或第三方大模型 API 体验更完整。
4. Windows 上最容易踩的坑:权限、终端与网络
4.1 PowerShell 执行策略:RemoteSigned 是什么
装完 Node、全局安装也成功了,结果一敲claude就报错,说什么“无法加载文件,因为在此系统上禁止运行脚本”。这是 Windows 上最常见的第一坑。
PowerShell 默认执行策略是 Restricted,意思是不允许任何本地脚本文件运行,而 npm 全局安装生成的那些.ps1快捷脚本就属于这一类。解决方式是放开当前用户的执行策略:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserRemoteSigned 的意思是:本地创建的脚本可以运行,从网上下载的脚本文本需要有合法签名才能运行。这个策略对普通用户足够安全,也足够解放 Claude Code 这类工具的启动脚本。执行完再次敲claude就能进了。注意,要用管理员权限吗?不需要,-Scope CurrentUser只改当前用户层面,别一上来就 Open as Administrator,后面会解释为什么尽量不要用管理员终端。
4.2 elevated 终端 daemon 报错:为什么不要用管理员运行
Claude Code 在 Windows 上有一个后台 daemon 机制,用来处理多客户端之间的会话共享,比如你在 VS Code 集成终端和 Windows Terminal 里同时挂着同一个会话,它能同步状态。这个 daemon 是由你首次启动 claude 的进程拉起来的,它继承那个进程的权限。
如果你手贱用“管理员身份运行”的 PowerShell 去启动 claude,daemon 就会以管理员权限跑起来。之后你用普通权限的 VS Code 或 Windows Terminal 再去连 claude,就会撞上一类报错,典型的就是热搜里那句:error: start the windows daemon from a non-elevated terminal; shared clients。
遇到这个报错,不要想着去提权对抗,正确做法是把所有管理员权限的终端窗口关掉,甚至去任务管理器把残留的 daemon 进程结束掉,然后重新用普通权限的终端启动claude。Windows 上这种“高权限反而坏事”的场景不多见,但 Claude Code 恰好就是一个。记住:日常使用一律普通终端,别为省事去点“以管理员身份运行”。这个坑我当初反反复复试了好几次才想明白,以为是 npm 包装坏了,差点重装系统。
4.3 终端卡死与中文输入法
再一个 Windows 上独有的体验问题:终端里输入中文不稳。你用 claude 会话时如果用中文提问,在某些老的 cmd.exe 窗口里会出现输入法候选框错位、光标跳动、甚至整行输入乱码的情况。
我个人的方案是:别用 cmd.exe,用 Windows Terminal。Windows Terminal 对 Unicode 支持、输入法兼容、字体渲染都明显更好。如果你用的是 VS Code,那就直接放在 VS Code 的集成终端里跑,这个终端对中文输入法兼容度也还行。还有一个小细节,输入中文前先把终端聚焦一下,别在编辑器里打着打着直接切到终端回车,输入法状态有时候会没跟着切过去。
4.4 网络环境与慢响应的处理思路
说完权限和终端,再说一个绕不开的现实问题:Claude Code 官方服务对国内网络没那么友好,即使你有官方订阅,也可能遇到连接超时、请求失败这些事。这里我不打算展开讲什么工具,这不是本文范围,而且每个人的网络情况差别太大,我只给两条思路:
- 如果你走官方订阅,先确认自己当前网络能稳定访问相关服务。装登录卡住的时候,可以先检查浏览器能否正常打开账号页面,再回头看终端里的登录流程。
- 如果你网络不通畅,又不想折腾,那就干脆走本地模型或第三方 API 的路线,这样 claude 的请求发到本地端口或国内可直连的网关,省心很多。
Claude Code 本身也提供了一些超时、重试相关的环境变量,但不同版本变量名有调整。遇到网络问题,先看错误日志,再按报错信息去搜,比盲目调参数更靠谱。
5. 装完后这样用才顺手:VS Code 接入与命令习惯
5.1 在 VS Code 里跑 Claude Code:两种姿势
在我日常的工作流里,VS Code 是主要战场,Claude Code 的用法有两种,看你自己习惯。
第一种最简单:直接在 VS Code 的集成终端里敲claude,然后在当前项目目录下开始对话。Claude Code 会自动识别当前工作目录里的代码、Git 状态,你可以让它读文件、改代码、跑测试。这种方式零配置,最适合从终端路径迁移过来的人。
第二种是用官方提供的 VS Code 扩展。装了扩展后,你可以在编辑器侧边栏直接展开 Claude Code 的面板,把对话独立出来,不用跟终端窗口抢位置。注意,扩展后面还是要依赖你本地装好的 claude CLI,别以为装个扩展就可以不装命令行工具了。我自己的习惯是:小修改直接在终端里来,需要边看代码边持续对话时,切到侧边栏面板。两种姿势都顺手的办法是,把 claude 启动拆成一个快捷键,想开哪个开哪个。
5.2 三个高频操作,帮你把命令行用出效率
很多人装了 Claude Code 之后,还是只会进交互模式一句一句问,其实它有几种命令行模式,在 Windows 下一样好用。
第一个是claude -p,即非交互模式。你可以把它当成一个“一次性问答工具”:
claude -p "看一下当前目录下的 main.py,告诉我哪里可能出 bug"它会直接跑完,把结论打到终端然后退出。这个模式适合写脚本时批量调用,比如在 Git 提交前自动跑一轮代码审查。
第二个是claude --continue。你上次会话没聊完,或者想把上一轮的上下文接上,直接在同一个目录下运行:
claude --continue它就接着上一轮的状态继续,不用重新描述需求。这里注意一点,它是在当前目录找你上一次的会话历史,所以最好别跨目录跑。
第三个是理解它的权限机制。Claude Code 不是一个单纯聊天工具,它会请求“执行终端命令”来完成你的任务。默认情况下,它每执行一次命令都要你点头批准,这其实就是你搜的那个问题——“claude code 如何直接执行终端命令”的答案:它会先给你看命令内容,你同意后它才跑。如果你追求全自动,有--dangerously-skip-permissions这种跳过确认的模式,但我强烈不建议在重要机器上开,AI 一多手,删库虽然不至于,但误操作完全有可能。
5.3 注意上下文和用量,别把额度跑飞
Claude Code 最大的隐性成本是上下文膨胀。你让它改一个文件,它会把整个文件读进去,对话轮次一多,上下文就越占越大,最后表现为响应变慢、API 费用变高。
我自己的经验是这么几条:单次任务不要贪多,一次让 AI 干一件事,比如“重构这个函数”和“顺带修那三个 bug”分开跑;对话中间发现跑偏,直接用/compact压缩上下文,把摘要保留下来,重新起一轮;轮次太多时要敢于开新会话,Claude Code 会用 Git 记录工作区变化,你不太会丢东西,顶多是用/review复查一下改了什么。
如果你是接第三方 API 或本地模型,也一样要注意 token 消耗。第三方 API 是按量计费的,前几轮看着便宜,上下文一长,一次请求就可能吃掉几万 token。本地模型虽然没有费用,但上下文拉长之后显存吃紧,速度会肉眼可见地变慢。总之,把“及时开新会话”当成习惯,比什么优化参数都实在。
最后说点个人感受。我在好几台 Windows 机器上都装过 Claude Code,从 Win10 到 Win11,从公司电脑到个人笔记本,没一次需要动用 WSL。最稳的组合就是:nvm-windows 管好 Node 版本,普通权限的 Windows Terminal 或 VS Code 集成终端跑 claude,需要接什么模型就用环境变量或 CC Switch 切一下。装的过程真不难,难的是想清楚自己到底想让它干嘛——是当编辑器里的代码助手,还是批处理脚本的加速器,还是本地私有模型的前端。想明白了,后面所有配置都是顺水推舟的事。