Win11安装opencode避坑指南：从环境准备到模型配置-代码聚汇网

Win11安装opencode避坑指南：从环境准备到模型配置

小狐狸与小道士·2026-09-07·阅读 115 GEO检测（免费）

opencodeWin11npm

|难度：普通|阅读约 38 分钟

前两周帮朋友在他那台新买的 Win11 笔记本上装 opencode，原本以为一条 npm install 就完事，结果前前后后折腾了快四十分钟。最搞的是他之前已经按某篇教程装过一次，但那位博主写的是旧版包名，装完的二进制根本不是 opencode，命令行一敲就报“无法将 opencode 项识别为 cmdlet”。这种问题在 win11 上太典型了：终端换了、PowerShell 执行策略有历史包袱、npm 全局路径容易被安全软件干扰，再加上网上教程良莠不齐，新手很容易在第一步就卡死。

这篇文章我不打算只给你贴一条安装命令。我会把 win11 上安装 opencode 的完整链路拆开讲清楚——从装之前要理解什么，到环境准备、三种安装方式实测、首次启动接模型、Win11 专属的坑，再到一个能直接上手的实战流程和常见报错排查顺序。适合刚接触 opencode 的人，也适合已经在 Linux/macOS 上用过、但第一次在 Windows 上装的人。

1. 装之前先把这个工具想明白：它到底要装到哪里去

1.1 opencode 不是 VSCode 插件，而是一个终端程序

这一点不先搞清楚，后面所有配置都会乱。opencode 是一个跑在终端里的 AI 编码代理，你打开终端进入项目目录，敲下 opencode，它会在当前目录下启动一个交互式界面，你可以让它读代码、改代码、跑命令、提 PR，它能像结对程序员一样帮你干活。它本身的形态是一个命令行程序，不是 VSCode 插件，也不是一个带窗口的桌面应用。

那为什么网上会搜到“opencode vscode 插件”“opencode jetbrains idea 插件”？因为这些 IDE 插件是后来加的前端壳子，它们的职责是把你编辑器里的代码和对话界面转发给本机的 opencode 命令行工具。换句话说，插件只是遥控器，opencode CLI 才是电视机。所以你在 win11 上无论如何先把命令行工具装好，再去折腾插件，顺序不能反。

理解这一点还有个实际好处：你在安装阶段遇到的大多数问题，本质都是在“让 Windows 找到一个命令行程序”。什么 PATH 不对、执行策略限制、下载文件被拦，全都是在解决这一件事。想通了这一点，排查报错时就不会慌了。

1.2 Win11 上跑 opencode 的三条路：原生、WSL、IDE 插件

win11 上跑 opencode 可以有三条路线，我按推荐程度排一下：

原生 Windows 终端跑：直接在 PowerShell 或 Windows Terminal 里安装运行。最直接，也是这篇文章的主线。
WSL2 里跑：在 Windows Subsystem for Linux 里安装 Linux 版 opencode。适合你本来就在 WSL 里做开发、依赖 Linux 工具链的场景，隔离干净，但文件跨系统读写会有性能损失。
IDE 插件调用：在 VSCode 或 JetBrains 系 IDE 里装插件，插件内部调用前面说的命令行工具。

三条路线不冲突，很多人最后是“Windows 终端 + IDE 插件”一起用。但第一次装，我建议你先走原生终端这条路，把核心工具跑通，再考虑别的形态。这样定位问题最简单：出事了就一个终端窗口，不会分不清是插件的问题还是命令行工具的问题。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 环境准备：把 Node.js、PowerShell 和终端这三大件整利索

2.1 Node.js 版本怎么选、在哪下

opencode 是用 Node.js 生态构建的，当前主流安装方式对它要求很明确：你需要一个可用的 Node.js 运行时。这里注意，不是随便装个 Node 就行，版本太老会导致 npm 安装时报引擎不兼容，版本太新又可能撞上某些原生模块还没适配。我的建议是直接用官网的 LTS 版本，长期支持版，稳。

下载地址就是 nodejs.org，别去第三方站点下那种“绿色版”“优化版”，没必要，还容易被塞东西。安装时一路 Next 就行。有一点值得单独说：win11 的安装包默认会帮你勾选“Add to PATH”，这个选项一定保持勾选。很多人在 PowerShell 里敲 node 提示找不到命令，就是装的时候把 PATH 那个勾去掉了。

如果你需要同时维护多个 Node 版本，可以装 nvm-windows。但如果你是刚接触，我不建议一上来就引入版本管理器，反而增加认知负担。就用 LTS 版本，等以后真遇到了“A 项目要 Node 18、B 项目要 Node 22”这种场景，再回来补 nvm-windows 不迟。

2.2 验证环境的三条命令

装完 Node.js 后，别急着装 opencode。先开一个新的 PowerShell 窗口，依次敲这三条命令确认环境没问题：

powershell复制node -v
npm -v
where.exe node

node -v 能看到类似 v20.x.x 的版本号，说明 Node 本体正常。
npm -v 能看到 npm 版本，说明包管理器正常。
where.exe node 能看到 node.exe 的完整路径，说明 PATH 环境变量没有问题。

如果你敲第一条就报“无法识别 node”，大概率是刚才说的 PATH 问题。最快的解决办法是去“设置 - 系统 - 系统信息 - 高级系统设置 - 环境变量”，在“用户变量”的 Path 里把 Node.js 的安装目录（默认是 C:\Program Files\nodejs\）加进去。改完记得关掉所有终端窗口再重新打开，环境变量只在新的进程里才会生效。

2.3 npm 下载慢与执行策略两条经典坑

环境没问题，先做个 npm 镜像配置。这一步不是必须的，但国内网络环境下实测非常管用。你直接跑全局安装命令时，npm 默认从官方源下载，网络不稳定很常见，报 ECONNRESET、ETIMEDOUT 都是这个原因。可以换成国内镜像源：

bash复制npm config set registry https://registry.npmmirror.com

严格来说 registry 只是换了一个下载源，不影响包内容，我个人用下来没遇到过兼容问题。不想永久换的话，也可以安装时单独加参数：

bash复制npm install -g opencode-ai --registry=https://registry.npmmirror.com

第二条经典坑是 PowerShell 执行策略。win11 默认的 PowerShell 执行策略是 Restricted，会禁止运行本地 .ps1 脚本。npm 全局安装某些包时需要执行安装脚本，如果被策略拦住，你会看到一堆红色的权限报错，但仔细看又不是 EACCES。顺手解决掉：

powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned 表示本地脚本可以运行，从网上下载的脚本必须带可信数字签名。这个策略对个人开发机是合理的，不影响系统安全。改完可以用 Get-ExecutionPolicy 确认输出是 RemoteSigned。

3. 实际安装：全局安装、免安装包、npx 三种方式我都试了

3.1 官方推荐：npm install -g opencode-ai

在终端里执行：

bash复制npm install -g opencode-ai

注意包名是 opencode-ai，不是 opencode。opencode 这个包名被别的项目占了，直接 npm install -g opencode 装出来的东西完全不对，这也是很多人装了之后发现命令根本不对的根因之一。官方 README 里的安装命令就是带 -ai 后缀的。

全局安装会把命令放到 npm 全局 bin 目录下，windows 上一般是 %APPDATA%\npm。装完建议立刻验证一下：

bash复制opencode --version

能输出版本号，说明核心命令已经可用了。这一步如果报错，不要慌，直接跳到 3.4 节按排查链路处理。

3.2 免安装：下载 Releases 里的 exe 并加入 PATH

如果你不想装 Node.js（虽然我不建议，因为后续很多依赖都基于 Node），或者你希望 opencode 是一个独立的 exe 文件，可以去 GitHub Releases 页面下载 Windows 版本。下载下来的东西一般是一个压缩包，解压后里面有 opencode.exe。

拿到 exe 后，你需要把它所在目录加入 PATH，这样在任意终端都能直接敲 opencode。具体操作：

Win+R 输入 sysdm.cpl 打开系统属性。
切到“高级”，点“环境变量”。
在“用户变量”里找到 Path，编辑，新建，填入 exe 所在目录的完整路径。

这里有个 win11 特有的问题：从浏览器下载的 exe，SmartScreen 可能会弹蓝色警告说“Windows 已保护你的电脑”。如果你确认是从官方 GitHub Releases 下载的，点“更多信息 - 仍要运行”就行。GitHub 上的文件没有微软的代码签名证书，被拦截是正常的，不代表有毒。

3.3 不想污染全局：用 npx 直接跑

还有第三种方式，严格来说不算“安装”，但很实用。如果你只是临时体验一下，不想在全局留一个包，可以这样：

bash复制npx opencode-ai

npx 会临时下载 opencode-ai 并直接运行。第一次跑会等一会儿，因为要下载完整包，后续运行会走缓存，速度会快很多。这个方式的好处是环境干净，不用了删掉缓存就行；缺点是命令不能直接写成 opencode，得敲一整条 npx opencode-ai，在项目里日常使用有点烦。

我实测下来，临时体验用 npx，长期使用用全局安装，两条路线我都推荐。至于免安装 exe，留给那些确实不想装 Node 的人。

3.4 安装后必做的验证与“cmdlet 识别不了”排查链路

很多人在 win11 上遇到的第一道坎就是下面这行：

text复制opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。

这句话的潜在意思是：系统在当前目录和所有 PATH 目录里都找不到名为 opencode 的可执行文件。我把它可能的根因按出现频率排一下：

原因	判断方法	解决
压根没装成功	执行 `npm ls -g --depth=0`，看不到 `opencode-ai`	重新执行 `npm install -g opencode-ai`
包名写错，装了别的包	全局列表里看到的是别的名字	`npm uninstall -g opencode` 清掉错误包，再装 `opencode-ai`
全局 bin 目录不在 PATH	执行 `npm config get prefix`，看输出路径，再到环境变量里检查是否存在	把该路径加入用户 Path
终端缓存了旧 PATH	改了环境变量后没重开终端	关掉所有终端窗口，重新打开
PowerShell 执行策略拦截	重新安装时看到红色脚本执行错误	按 2.3 节执行 Set-ExecutionPolicy

排查顺序我建议是这样：先重开一个终端窗口，再执行 npm ls -g --depth=0 确认包在不在，然后 npm config get prefix 看路径，最后检查 PATH。百分之九十的情况都出在前三步。别一上来就跑去改系统注册表或者重装系统，没必要。

4. 首次启动与模型接入：没有 API Key 等于白装

4.1 第一次敲 opencode 会发生什么

安装没问题后，找个空目录，敲 opencode。首次运行它会进入一个交互式配置界面，通常要先选 provider（模型提供商）。opencode 本身不生产模型，它只是一个客户端，你需要把某个模型服务的 API Key 给它，或者让它访问一个本地的模型服务。

这一步很多新手会卡住，因为看到一屏英文选项，不知道选哪个。我建议第一次走最简单的路径：如果你有 Anthropic 的 API Key，优先选 Anthropic，因为 opencode 对 Claude 系列模型的支持最成熟；如果你只有 OpenAI Key，就选 OpenAI；如果你什么 Key 都没有，跳到 4.3 用 Ollama 本地模型免费跑。

几个 provider 对应的关键环境变量也顺便说清楚，后面排查时会用到：

Anthropic：ANTHROPIC_API_KEY
OpenAI：OPENAI_API_KEY
OpenRouter：OPENROUTER_API_KEY

在 win11 上设置环境变量可以在当前会话临时设置：

powershell复制$env:ANTHROPIC_API_KEY = "你的key"

但临时设置只在当前终端有效，关掉就没了。想持久化，我建议写在 opencode 的配置文件里（接下来讲），而不是去系统环境变量面板里加一堆东西。

4.2 用配置文件接入 Claude 和 OpenAI 兼容模型

opencode 的配置文件路径在 win11 上一般是：

text复制C:\Users\你的用户名\.config\opencode\opencode.json

第一次运行后它通常会帮你生成这个文件。手动编辑时，一个最简配置大概长这样（不同 2.x 版本 schema 略有差异，以你实际版本为准）：

json复制{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "anthropic": {
      "options": {
        "apiKey": "sk-ant-xxxx"
      },
      "models": {
        "claude-sonnet-4-20250514": {
          "name": "Claude Sonnet 4"
        }
      }
    }
  },
  "model": "claude-sonnet-4-20250514"
}

如果你用的是 OpenAI 兼容接口，更常见的是在 provider 里指定 baseURL。现在不少模型服务商都提供 OpenAI 兼容的 HTTP API，这类配置我在 win11 上验证过一个典型写法：

json复制{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "my_openai_compatible": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "My OpenAI Compatible",
      "options": {
        "baseURL": "https://你的接口地址/v1",
        "apiKey": "你的key"
      },
      "models": {
        "your-model-name": {
          "name": "Your Model Name"
        }
      }
    }
  },
  "model": "your-model-name"
}

要特别提醒的是：baseURL 一定别写错。很多服务商要求末尾带 /v1，如果漏了，请求会直接 404，opencode 里只会报一个很不明所以的错误。出现这种诡异错误时，先检查 baseURL 末尾路径，再检查模型名是否和服务商提供的一致，这俩地方是重灾区。

4.3 想免费体验：先试 Ollama 本地模型

没有 API Key 又不想花钱，本地模型是最稳的方案。win11 上装 Ollama 很简单，去 ollama.com 下载安装包，装完在终端拉一个代码模型：

bash复制ollama pull qwen2.5-coder:7b

然后在 opencode 启动时选择 Ollama provider，或者在配置文件里把默认模型切到 Ollama 下的模型。实测下来，本地 7B 模型做代码解释、生成小工具脚本绰绰有余，但做复杂重构或多文件联动会明显吃力，毕竟是免费本地算力，不能和商用大模型比。

我个人的使用建议是：日常简单任务让本地模型跑，复杂任务切到 Claude 这类强模型。opencode 支持在会话内切换模型，不必退出去改配置文件。别指望一个模型通吃所有场景，工具是死的，搭配是活的。

5. Win11 专属雷区：右键菜单、SmartScreen、WSL 和 IDE 插件

5.1 右键菜单别急着改，先找对“在终端中打开”

网上关于“win11 右键菜单改回 win10”的讨论非常多，看到这里你可能也想顺手把注册表改一下。我的建议是：装 opencode 这个阶段别动右键菜单。

原因很简单，你在 win11 里进入项目目录运行 opencode 的场景，根本不需要右键菜单改回旧版。你只需要在文件夹里按住 Shift 点击右键，就能看到“在终端中打开”选项，点击直接进入该目录的 Windows Terminal，或者你直接在地址栏输入 powershell 回车也能在当前目录开一个终端。这两步在 win11 的新右键菜单里其实更顺手，旧菜单反而多一层。

如果你因为其他原因确实想把右键菜单改回 win10 风格，那也等活动目录里没有正在运行的任务再改，改完大概率需要注销或重启资源管理器。这不是 opencode 的问题，是系统层面的调整，别混在一起排查。

5.2 下载的 exe 被 SmartScreen 拦了怎么办

前面提到过，GitHub Releases 下载的 exe 很容易触发 SmartScreen 拦截。这其实是 win11 上除了 PATH 之外最容易卡住人的一步，尤其是对不常下载开源软件的人来说，看到蓝屏警告会本能地觉得“完了，中毒了”。

我的处理原则是：确认来源。如果你是在 sst/opencode 这个官方 GitHub 仓库的 Releases 页面下载的，那按“更多信息 - 仍要运行”放行是安全的。如果是从搜索引擎下载站来的，不要放行，直接删。

顺带说一句，Windows Defender 实时防护有时会扫描 npm 全局目录里的新 exe，导致 opencode --version 第一次执行卡顿几秒。这不是故障，等一下就行，别急着卸载杀软。系统安全别乱动，尤其是为了跑一个开发工具去关掉杀软，完全没必要。

5.3 WSL2 里跑 opencode 和 Win 原生有什么区别

如果你决定在 WSL2 里跑 opencode，需要知道它和原生 Windows 方案有三个关键差异：

第一，WSL2 是一个完整的 Linux 环境，所以安装方式不再依赖 npm 的 Windows 版本，理论上装的是 Linux 版 opencode。你在 WSL 里执行 npm install -g opencode-ai 没问题，但要注意 WSL 的发行版里也要有 Node.js，不是说你 Windows 装了 Node 就行。

第二，文件系统性能差异很大。WSL2 访问 /mnt/c/ 下的 Windows 文件很慢。如果你项目代码放在 C:\code\project，然后在 WSL 里跑 opencode，模型读代码时会明显感觉卡顿。我个人建议既然用了 WSL，就把项目放在 Linux 文件系统里，比如 ~/projects/，Windows 侧用 \\wsl$\ 路径访问。

第三，网络端口是共享的。Win11 上 WSL2 和宿主机共享网络，所以你在 WSL 里启动 Ollama，Windows 原生程序也能访问 localhost 对应的端口，反过来也一样。这个特性在 opencode + 本地模型场景下很好用，两边不必互相拷贝配置。

5.4 VS Code / JetBrains 插件不是必须，但能提升体验

opencode 在终端里跑已经有完整的交互界面，但有人还是更喜欢在编辑器里用，毕竟上下文直接可以看到代码。VS Code 扩展市场和 JetBrains 插件市场里都能找到 opencode 相关的插件。装插件的逻辑和我开头说的一样：插件本身不是一个独立工具，它会去调用你本机已经装好的 opencode CLI。

所以顺序一定是：先保证命令行里 opencode --version 能正常输出，再装插件。不然插件装好了，它内部调 opencode 命令找不到，报错会异常诡异，你还会怀疑是插件的问题。

安装方面，VS Code 直接在扩展面板搜 opencode 安装，JetBrains 系插件可以在 Settings - Plugins 里搜。装完一般还要在插件设置里指定 opencode 可执行文件的路径，如果你是按全局 npm 方式装的，它会自动识别；如果是手工下载 exe 放到自定义目录的，可能就要手动填路径。实测下来 JetBrains 插件相对更吃配置一些，按官方文档填就行。

另外，如果你之前折腾过 oh-my-claudecode 这类增强工具，会发现它们的配置思路很多都能平移到 opencode 上——无非是系统提示词、模型路由、技能文件这几块。opencode 支持的 Skills 机制就是干这个的，下面一节细说。

6. 装完怎么用：在真实项目里把 opencode 跑起来

6.1 进入项目目录，从 /init 开始

安装和模型都配好之后，你还需要知道在真实项目里怎么启动。先 cd 到一个项目目录，然后执行 opencode，进入交互界面后，第一件事我建议敲 /help 看一下当前版本支持的命令列表。不要凭记忆敲，不同版本的命令名会变，以帮助界面为准。

对于一个新项目，opencode 通常提供 /init 命令，它会扫描当前仓库结构，生成一个给 AI 看的项目说明文件，比如项目结构、技术栈、构建命令、代码风格等。这个文件会作为后续所有对话的上下文基础，相当于给 AI 一张项目地图。我第一次用的时候没太在意，后来发现模型回答质量差很多，几乎都是因为项目上下文不足。

接着你可以直接输入自然语言任务，比如：

text复制帮我梳理一下这个项目里用户登录模块的调用链路，并输出一个 mermaid 时序图

建议任务描述越具体越好。不要只说“帮我优化代码”，要说清楚优化目标、约束条件、期望输出，AI 编程代理和搜索引擎不一样，它要的是明确指令。

6.2 用 Skills 让 agent 学会你的团队规范

Skills 是 opencode 很实用的扩展机制，你可以把它理解成给 AI 设定的“工作模板”或“技能包”。它通常是在项目或配置目录下的一个目录里放 Markdown 文件，每个文件定义一个技能，包含触发条件、执行步骤、输出规范。

比如你可以创建一个 code-review.md 技能，要求它每次做代码审查时先检查安全问题、再检查错误处理、最后检查命名规范，并把意见按严重级别排序。当你在会话里触发这个技能时，opencode 会加载对应的指令，输出风格就能稳定下来。

这个目录在 win11 上通常可以在项目根目录建 .opencode/skills/，具体路径以你的版本 /help 输出为准。我的经验是：不要一开始就写一堆复杂技能，先复制一个简单的跑通，再迭代加内容。技能文件和系统提示词不同，它更结构化，也更适合沉淀团队经验。

6.3 快速接手陌生项目的实际经验

“opencode 接手开发项目”是我看到的热搜词，也是这个工具最值钱的场景之一。我接手过一个历史遗留项目，文档几乎为零，代码一万多行。以前我得花大半天人肉理清模块关系，这次我把项目目录丢给 opencode，让它先输出一份项目结构说明，再顺着入口函数逐个模块梳理，最后把不确定的地方标出来给我确认。

这个流程能省很多时间，但有两点要注意：

第一，别让它一次性分析和生成整个项目。上下文窗口是有限的，你让它“分析整个项目”它会顾此失彼。正确做法是按模块拆，一次只让它读一个目录或一条链路。第二，AI 输出的项目理解不一定全对，涉及业务规则、金钱计算、权限判断的部分，一定要人肉核验。它适合做信息整理和初步推理，但最终判断还是要你自己拍板。

6.4 用 opencode 写一个 README 的完整过程

举一个最简单的实战例子。假设我有个脚本项目，目录结构乱七八糟，README 是空白的。我会这样操作：

text复制请扫描当前目录的文件和代码，生成一个项目 README.md，内容包括项目简介、环境要求、安装方式、使用示例。技术水平说明可以保守一点，不要编造功能。

生成之后，opencode 会给出一个 README 草稿，同时列出它扫描到的主要文件。这时候我一般会要求它再针对 README 里提到的使用示例跑一遍语法检查，确保示例代码不是嘴上说说的。最后我手动过一遍，修正它理解错的地方，保存。

这个流程看起来简单，但它演示了 opencode 的正确用法：先让它读真实文件，再基于读取结果生成内容，同时加约束防止它编造。不加约束直接让它写 README，很容易生成一个“看起来专业但实际对不上项目”的文档。

7. 常见报错与一套排查顺序

7.1 高频报错对照表

把我在 win11 上实际遇到过、或帮别人处理过的问题汇总如下：

报错信息	主要原因	解决方向
无法将“opencode”项识别为 cmdlet	包没装好 / 全局 bin 不在 PATH	npm ls 全局列表确认安装情况，重新配置 PATH
npm ERR! code ETIMEDOUT	官方源网络问题	换 registry 镜像或指定 registry 安装
npm ERR! EEXIST / EPERM	全局目录权限问题	避免用管理员身份安装，优先修复目录权限
EACCES permission denied	权限不足	Windows 上多与 npm 缓存目录有关，执行 `npm cache verify`
打开后找不到模型 / provider 报错	配置文件 schema 或 baseURL 错误	检查 `~/.config/opencode/opencode.json` 中字段是否匹配版本
对话中途卡住 / 无响应	本地网络不稳定或上下文过长	重新发起会话，或使用 `/compact` 压缩对话历史
SmartScreen 拦截 exe	未签名的开源程序	确认来源后选择“仍要运行”
终端显示乱码或排版错乱	终端字体/代码页问题	优先使用 Windows Terminal，字体设置为 Cascadia Mono

表格里的每一项我都实际踩过，ETIMEDOUT 和 cmdlet 识别不了是最常见的前两名，另外配置文件 schema 不匹配在版本升级后会出现得很频繁。opencode 迭代很快，版本升级后配置报错是正常现象，别慌，按提示改配置即可。

7.2 我自己的标准排查顺序

碰到问题了，别东一榔头西一棒子。我整理了一个固定顺序，照着走能解决八成问题：

重开一个全新的终端窗口，排除环境变量缓存。
执行 opencode --version，确认 CLI 本身可用。
执行 npm ls -g --depth=0，确认全局包里确实有 opencode-ai。
查看配置文件 C:\Users\你的用户名\.config\opencode\opencode.json，确认 provider、model、baseURL 字段没有明显笔误。
打开配置文件的 schema 地址，对照当前版本确认字段是否过时。
如果跟网络相关，检查 npm registry 或模型接口连通性，可以临时用 curl 试一下接口地址能否返回预期结果。
最后才是搜报错原文，而且搜的时候带上版本号，因为旧帖子的解决方案很可能已经失效。

这套顺序的核心思路是：先确认命令能用，再确认包在不在，然后确认配置对不对，最后才是网络和兼容性问题。很多人在第一步命令都不通的时候就去改模型配置，只会越改越乱。

opencode 在 win11 上装好只是开始，真正让它产生价值的是你愿意拿真实项目去试、去撞坑、去调整配置。如果你以前只在 Linux 或 macOS 上用它，刚到 Windows 上的头两次会话可能会觉得哪哪都不对劲，但只要把 PATH、执行策略、配置文件这三个点理顺，后面的体验会丝滑很多。我个人的体会是：这个工具值得花一个小时把环境整干净，不要将就着用，环境不干净后面排查问题会成倍浪费时间。