很多年前我一直觉得，在 Windows 上搞 AI 编程环境是件自讨苦吃的事。显卡驱动、Python 版本、各种 Linux 才会有的依赖，能把一个下午耗得干干净净。但最近两年情况真的变了，WSL2 成熟之后，Windows 已经成了我主力 AI 开发机，甚至新换电脑的第一天就能把 Codex、Ollama、Docker 这套环境全部跑起来。这篇东西不是那种“十分钟搞定 AI 环境”的标题党，而是我按 2026 年 9 月 9 日这个时间节点，从零配置 Windows AI 编程环境的一份完整沉淀，覆盖 WSL2、Miniconda、Docker 中间件、AI 辅助编码工具，以及本地模型推理。如果你正准备入局 AI 编程，或者新电脑到手想一次配好不再返工，照着往下走就行。
1. 先问自己三个问题，再决定怎么搭这台 AI 开发机
1.1 你的“AI 编程”到底指什么
很多人看到“AI 编程环境”这个说法就直接开装全家桶，其实这个词在 2026 年已经拆成了三条差别很大的路线，我先帮你把路线认清。
第一条路线是“用 AI 辅助写代码”。你日常在 VS Code 或终端里用 Codex CLI、GitHub Copilot、Claude Code 这类工具生成代码、改 bug、做重构。这条路线最关心的是 IDE 集成、上下文管理、API Key 配置，对硬件要求反而不高。
第二条路线是“本地跑模型”。你想把大模型拉到自己机器上推理，做 RAG，或者出于隐私考虑不想把代码片段发给云端，这条路线需要好的显卡、足够的内存，以及 Ollama、LM Studio 这类推理工具的熟练使用。
第三条路线是“开发 AI 应用”。你要写调用模型 API 的产品代码，搭向量数据库，做数据处理管道，重点会落在 Python、Docker、Redis、Elasticsearch 这些基础设施上。
三条路线的共同点是都叫 Windows AI 编程环境，但配置策略差别很大。如果你三条都占，也请按优先级排一个序，这决定了你第一步该装什么，而不是被网上五花八门的推荐带跑。
1.2 硬件现实：显卡、内存与硬盘的底线
先解决一个残酷的现实问题：你到底需要多强的硬件。这里没有标准答案，我给出一份我实测下来比较舒服的配置档位，你可以对着自查。
| 使用场景 | CPU | 内存 | 硬盘 | 显卡 |
|---|---|---|---|---|
| 纯 API 开发（Codex/Copilot 为主） | 4 核以上即可 | 16GB 起步，32GB 更稳 | 512GB SSD | 核显即可 |
| 本地小模型/嵌入模型（7B 以下） | 8 核以上 | 32GB 起步 | 1TB NVMe SSD | 8GB 显存舒服，无独显也能跑 CPU 版 |
| 本地大模型/微调（14B 以上） | 强力多核 | 64GB 左右 | 2TB SSD | 24GB 显存起步，否则别谈微调 |
我的建议很直接：如果你不是明确要做模型微调，就不要把预算全砸在显卡上。大多数人的日常是调用 API 加本地小模型，16GB 到 32GB 内存才是投入产出比最高的部分。
硬盘空间也常被忽略。一个大模型文件就是 4 到 8GB，Docker 镜像再堆一叠，几十 GB 很快没了。系统盘建议留足 80GB 的剩余空间，不然用着用着磁盘写满，各种诡异问题都会冒出来。
1.3 最小闭环原则：先跑通，再补全家桶
我见过太多人第一天就把 Elasticsearch、Milvus、Redis、PostgreSQL 全装好了，结果一周后发现自己连一个模型调用都没跑通过。这是典型的“装修先于入住”。
正确做法是先把最小闭环打通：装好系统依赖，用 Python 成功调用一次大模型接口，让 AI 辅助工具能正常生成一段代码并跑起来。这个环节通了，后续加什么中间件都只是时间问题。
一开始我建议只装这几样：Git、WSL2、Miniconda、VS Code、一个 AI 助手 CLI。进阶清单里的 Docker Desktop、Redis、Elasticsearch、Ollama 等，等真正需要时再装也不迟。这不是让你少装，是让你每一步都在可运行的状态上往前走，出了问题也好定位。
2. 第一层地基：WSL2、终端与 Git 的正确打开方式
2.1 为什么建议从 WSL2 入手，而不是死磕原生 Windows
你可以只用原生 Windows 跑 AI 开发吗？可以，但你会频繁撞到同一种墙：某个 Python 库只提供了 Linux 预编译包，Windows 下要么没有轮子，要么让你现场编译，编译就跑二十分钟再报个错。
WSL2 相当于给你一个轻量 Linux 子系统，和 Windows 共享文件系统与网络，但跑的是真正的 Linux 内核。AI 生态里绝大多数工具在 Linux 上的兼容性是优先保证的，你踩的坑会少一个数量级。
安装过程现在非常简单，管理员身份打开 PowerShell 执行：
wsl --install wsl --set-default-version 2重启后系统会默认帮你装好 Ubuntu。第一次启动会让你设置用户名和密码，这个密码和 Windows 登录密码无关，是 WSL 内部的 Linux 账户密码，最好单独记一下。
我对 WSL2 的使用建议是“重活进 Linux，轻活在 Windows”：VS Code 这类编辑器和日常聊天软件留在 Windows 侧，Python 环境、Docker 容器、模型推理这些重活放到 WSL 的 ext4 文件系统里跑。这样既能享受 Windows 的图形界面体验，又能拿到 Linux 的兼容性和性能。
2.2 终端侧的基本设置和日常加速
Win11 自带的 Windows Terminal 已经做得非常好了，默认就支持多标签页、快捷键复制粘贴、自定义配色。我建议你做两件小调整。
第一，把默认配置文件改成 Ubuntu（WSL），这样每次打开终端就自动进 Linux 环境。终端配色选一个深色主题，比如 One Half Dark 或者 Dracula，长时间盯着不累。
第二，在 WSL 里装一套顺手的外层工具，我这里提供一个最小配置脚本，只做一件事：安装常用软件并开启zsh：
sudo apt update && sudo apt install -y build-essential curl wget git zsh sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"之所以推荐 zsh 加 oh-my-zsh，主要是它的自动补全和主题提示能明显减少日常敲错命令的次数。装了之后你可能会发现，很多需要反复记忆的命令都变得友好了不少。
2.3 SSH 密钥是每天都要踩的钥匙，别留到“后面再配”
Git 和代码托管平台的连接方式，决定你每天要重复输多少次密码。我见过无数人用了很久 Git，还在一遍遍输入用户名和密码，还会遇到各种权限缓存问题，纯属自伤。
装好 Git for Windows 后（官网下载或者用 Windows 包管理器都行），在 WSL 里生成一把 ed25519 密钥：
ssh-keygen -t ed25519 -C "你的常用邮箱"一路回车，默认保存到~/.ssh/id_ed25519。
Windows 侧还有一个特别容易踩的细节：OpenSSH Authentication Agent 服务默认是手动启动状态，有时候 Git 在 Windows 原生环境里找不到你的密钥文件。你需要先以管理员身份打开 PowerShell，执行：
Set-Service ssh-agent -StartupType Automatic Start-Service ssh-agent然后把~/.ssh/id_ed25519.pub的内容复制到 GitHub、GitLab 或你私有化代码平台的 SSH Keys 设置里。这个操作一次搞定，之后所有 clone、push、pull 都不需要输密码，值得花十分钟做干净。
3. Python 环境管理的“车轱辘话”：Miniconda 为什么仍然值得用
3.1 安装 Miniconda：官方包、默认路径和界面侧问题
Python 环境管理在 2026 年已经有了很多新工具，比如uv和PDM，速度快、理念先进。但如果你让我给 Windows 新手一个最不容易出错的推荐，我仍然会选 Miniconda。原因不是它技术最酷，而是它在 Windows 生态下的安装包、依赖解析和社区资料库是最扎实的，出了问题一搜就有答案。
安装 Miniconda 时注意三个点：从官方仓库下载安装包，安装时选择“Just Me”而不是“All Users”，安装路径不要有空格和中文。我习惯装在D:\Miniconda，方便重装系统时找到。
安装完成后需要确认 conda 命令是否在 PATH 里。如果在 PowerShell 或 CMD 里执行conda --version提示找不到命令，多半是安装时没有勾选环境变量。你可以从开始菜单里的 “Anaconda Prompt” 进入，或者手动把 Miniconda 的Scripts目录加到 PATH 里，但我更推荐直接把安装路径写进用户环境变量，否则之后各种脚本都会找不到 conda。
3.2 环境创建与 Python 版本选择
conda 的核心理念是环境隔离。你完全可以把 base 环境当成一个“启动器”，平时别动它，每个项目都创建独立环境。这样做的好处是，项目 A 升级了什么包，绝不会影响项目 B 的运行。
创建环境的命令：
conda create -n ai python=3.12 conda activate ai创建之后，你的终端提示符会变成(ai) user@host这样的形式，表示当前已经在独立的ai环境里。
Python 版本选择有一点需要强调：不要一上来就追最新的 Python，AI 生态对 3.11 和 3.12 的兼容性是最稳的。很多底层库发布新版本时优先适配这两个版本，瞎追新版很容易在安装某个编译型依赖时收到一句“requires Python < 3.13”的报错，然后你就得退版本重来。
3.3 pip 安装过程中两件会卡你一整天的事
第一件事是 pip 默认源在某些网络条件下特别容易超时。解决办法是换一个国内更稳定的 PyPI 镜像源。你可以在命令行里直接设置：
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple配置会写入pip.ini文件，之后所有安装都会走这个源，速度提升非常明显。这不算什么黑科技，但很多人装了一堆依赖总是失败，根源就在这里。
第二件事是依赖版本冲突。AI 项目的依赖关系经常一团乱麻，你装了一个库，它强制升级了另一个库，结果另一个库的旧接口被干掉了，你的代码原地爆炸。我的习惯是，每装完一个包，马上把当前环境的依赖清单导出一份：
pip freeze > requirements.txtrequirements.txt 同时放进 Git 仓库里。遇到环境崩溃，直接执行pip install -r requirements.txt就能快速恢复。记住，依赖管理不是可有可无的习惯，它是 AI 项目能不能持续迭代的生命线。
4. 中间件靠 Docker，还是本地裸奔？Redis 与 Elasticsearch 的取舍
4.1 Docker Desktop 与 WSL2 后端
AI 应用开发中，Redis、Elasticsearch、PostgreSQL 这类中间件几乎是标配。到底装在 Windows 原生环境还是 Docker 容器里，我给出的判断标准有三条：这个服务是否需要精确版本控制、是否需要随时启停、是否会污染系统环境。
满足其中任意一条，答案就是 Docker。
安装 Docker Desktop 时，最好勾选 “Use WSL 2 instead of Hyper-V”，这样 Docker 的运行引擎会构建在 WSL2 之上，资源占用更小、启动更快。装完之后在 Settings 里的 Resources 页面选择你要启用 WSL 集成的发行版，比如 Ubuntu，然后在 WSL 终端里就能直接使用docker命令。
这里有一个 Windows 用户最容易踩的坑：容器里挂载的数据卷，如果直接挂载到 Windows 的 D 盘目录，读写性能会明显下降，因为涉及跨文件系统的 IO。更合理的做法是把数据持久化放在命名卷或者 WSL 内部路径里。同样的配置，换个挂载位置，性能差距肉眼可见。
4.2 Redis：一个适合 95% 情况容器化的服务
Redis 是一个典型的不太需要“安装”的服务，至少不需要你在 Windows 上装一个常驻服务。用 Docker 跑 Redis 是我日常做 AI 项目时的标准姿势：
docker run -d --name redis-dev -p 6379:6379 redis:7-alpine这条命令会拉取 Redis 7 并启动一个名为redis-dev的容器，宿主机 6379 端口映射到容器内。加了--restart unless-stopped的话，Docker 服务启动时它也跟着自动启动，不用每次手动开。
容器用得越久，你越应该惦记一下内存。Redis 默认启动后，有多少内存就能用多少，如果只是做缓存，建议加个阈值限制：
docker update --memory 512m redis-dev这个限制能防止某个失控的业务一次性把内存打满，搞挂整台开发机。Redis 做消息队列、做缓存、做临时结果存储都非常顺手，但每个场景都要先想清楚内存预算。
4.3 Elasticsearch：写进 Docker 时怎么避免内存爆炸
Elasticsearch 是搜索和日志分析领域的老牌中间件，在 AI 应用里通常用来做全文检索或向量检索。它在 Docker 里默认配置相当激进，如果你不限制，它会把机器内存吃到让你怀疑人生。
我的建议是启动时就指定 JVM 堆内存，并且设置容器总内存上限：
docker run -d --name es-dev \ -p 9200:9200 \ -e "discovery.type=single-node" \ -e "ES_JAVA_OPTS=-Xms2g -Xmx2g" \ -m 4g \ docker.elastic.co/elasticsearch/elasticsearch:8.14.0ES_JAVA_OPTS里的-Xms2g -Xmx2g表示把 JVM 堆内存锁定为 2GB，这是最关键的设置。-m 4g则把整个容器限制在 4GB 以内，避免堆外内存和元数据把机器吃光。
另外注意，Elasticsearch 8 默认开启了安全认证，本地开发时不想搞证书这堆事，可以在启动后调整安全配置，或者直接用docker logs es-dev查看初始密码。总之，容器化并不代表不用管配置，该设的参数一个不能省。
4.4 容器之外的选择：那些不想开 Docker Desktop 的人
Docker Desktop 在商用场景下是有许可成本的，而且它本身比较吃资源。如果你不想用 Docker Desktop，还有一个非常轻量的替代方案：直接在 WSL 里安装 Docker Engine。
WSL2 本身就是一个完整的 Linux 环境，可以通过 systemd 管理 docker 服务。安装完成后，日常使用体验和原版 Linux 几乎一致，而且没有 Docker Desktop 那一层额外的资源开销。
我自己的习惯是：服务型依赖（Redis、PostgreSQL、Elasticsearch）放在 WSL 里通过 systemd 常驻，项目里需要临时起的服务才用docker compose一键拉起。这样既保证了环境一致，又不至于让整个开发机都跑满了容器，Windows 侧的内存压力会小很多。
5. AI 辅助编码：从 Codex CLI 到 IDE 插件，配置到能干活为止
5.1 Codex CLI 能解决什么问题，装它前需要哪些前置依赖
聊到 AI 编程，2025 年到现在最热门的工具毫无疑问是 Codex CLI。它把 AI 助手从 IDE 的侧边栏搬到了终端，你写一句自然语言，它能直接读取仓库里的文件，生成 diff，甚至执行命令帮你完成整个改动周期。对于写脚本、重构代码、补测试这类任务，效率比手动在旁边问一个对话框高很多。
要用 Codex CLI，首先需要一台装有 Node.js 20 或更高版本的机器。Windows 用户直接用官方安装包装 Node LTS 就行，安装时务必勾选 “Add to PATH”。
然后配置 API Key。Codex CLI 一般会读取环境变量OPENAI_API_KEY，或者在首次启动时引导你写入配置文件。在 Windows 上设置环境变量可以用 PowerShell 的setx命令：
setx OPENAI_API_KEY "你的密钥"使用setx设置后，需要重开终端窗口才会生效。密钥千万别直接写进项目代码仓库，这是死规矩。
5.2 Windows 上的 Codex 安装不顺利，通常卡在哪几步
“codex windows 安装未完成”已经成了一个高频搜索词，我当初也踩过这坑。表面上提示安装未完成，实际上绝大多数情况下不是 Codex 本身的问题，而是安装机制隐含的依赖没满足。
Codex CLI 走的是 npm 全局安装，命令通常是：
npm install -g @openai/codex装到一半失败的常见原因有三个：
第一个是 npm 拉依赖的时候网络超时，留下一个残缺的 node_modules 目录。解法是清理缓存并重装：
npm cache clean --force npm install -g @openai/codex --verbose--verbose会输出完整日志，看到底挂在哪个包上。
第二个是 Node 版本太旧或太新。有些安装脚本依赖 Node 的某个 API，版本不对就会在中途抛异常。建议安装 Node 官方 LTS，而不是最新的 Current 版本。
第三个是 npm 全局目录没有写权限。Windows 下如果你用系统管理员权限安装的 Node，全局安装经常碰到 EPERM 错误。解决办法是在 PowerShell 里直接改 npm 的全局前缀到一个用户目录：
npm config set prefix "$env:USERPROFILE\npm-global"改完之后重装，路径就会落在普通用户目录，权限问题迎刃而解。
5.3 把本地模型接到 AI 助手链路的思路
并不是每个人都愿意把代码上传到云端模型处理。很多人想用本地模型来减轻隐私顾虑，或者是掐着 API 成本过日子。
在 2026 年，大部分 AI 编码工具都支持自定义 Base URL。你可以在 Codex CLI 或 VS Code 扩展的配置里，把接口地址指向本地推理服务，比如后面会讲到的 Ollama。但我要泼一点冷水：本地小模型应付代码补全、格式化这类轻任务没问题，但复杂重构和仓库级理解力还是不如云端大模型。
更现实的用法是混合路线：日常写注释、补全、翻译代码，用本地模型；做大的跨文件重构、解释陌生代码库，用云端 API。成本、隐私、能力三者之间取一个折中，这个思路可以一直用下去。
5.4 提示词里最有用的上下文信息
AI 编码工具的体验差距，很大一部分不在模型本身，而在你给了它多少有效上下文。我强烈建议在每个项目根目录维护一个AGENTS.md或者CLAUDE.md这类约定文件，让 AI 助手能自动读取项目规范。
文件里写清楚这几件事：项目怎么构建和测试；代码风格约定比如“严格类型标注”“禁止魔法数字”；目录结构说明，比如src只放核心逻辑，tests对应测试；依赖安装方式。
实践下来效果非常明显。给 Codex 或 Copilot 一份清晰的上下文，生成的代码风格几乎和团队手写一致，有时候你都不需要二次调整。这个习惯比纠结选哪个模型、升级到哪一档订阅更值得先做。
6. 本地模型不是玩具：Ollama 与嵌入模型实战配置
6.1 为什么我选择 Ollama 而不是其他推理工具
本地推理工具里，目前两个主流选择是 Ollama 和 LM Studio。LM Studio 有图形界面、开箱即用，适合新手试玩。但我日常主力用的还是 Ollama，原因有三个：命令行体验干净，一条命令就能拉模型、跑模型；原生提供 OpenAI 兼容 API，脚本和现有代码几乎零改动就能接上；安装部署灵活，能跑在 Windows，也能跑在 WSL 和容器里。
对于想真正做事的人来说，Ollama 的高可移植性是很大的优势。你在本机测好的调用代码，部署到服务器时几乎不用改接口地址。
6.2 拉模型与典型资源占用
在 Windows 上安装 Ollama 很简单，官方安装包下载安装即可。装好后终端执行：
ollama pull qwen2.5:7b ollama run qwen2.5:7bpull是把模型文件拉到本地，run是启动交互式聊天。7B 参数的量化模型大小大约 4 到 5GB，16GB 内存的机器能跑，但建议 32GB 起步，因为推理过程除了模型文件，还要留出上下文窗口的内存开销。
如果你的机器配置一般，可以换成 3B 甚至 1.5B 的小模型。小模型在简单任务上速度飞快，日常体验往往比硬跑一个 14B 的卡顿机器更好。
Ollama 默认监听 11434 端口，启动后可以验证接口是否正常：
curl http://localhost:11434/v1/models看到模型列表返回，说明本地推理服务已经就绪。
6.3 嵌入模型和最小 RAG 准备
本地模型不只是用来聊天的，嵌入模型在 RAG（检索增强生成）里是核心零件。它的作用是把文本转成向量，让程序可以用数学方式计算语义相似度。
用 Ollama 拉一个嵌入模型：
ollama pull nomic-embed-text然后在 Python 里通过 OpenAI 兼容接口调用：
from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # 本地服务不需要真实 key，占位符即可 ) resp = client.embeddings.create( model="nomic-embed-text", input="Windows AI 编程环境" ) print(resp.data[0].embedding[:5])这是我搭最小 RAG 项目的固定流程：先用文档解析工具把 PDF 或 Markdown 切块，调用上面的接口生成向量，存入向量库，用户提问时先做向量检索召回 topK，再喂给本地大模型生成答案。整个过程串起来之后，你基本就掌握了一个本地私人知识库的雏形。
6.4 集显与低内存机器的兜底路线
如果你的机器没有独立显卡，甚至只有 16GB 内存，本地模型这条路依然可以走，只是需要调整预期。
首先选小模型，1.5B 到 3B 的量化版本在纯 CPU 上也是可以跑的，速度取决于 CPU 算力和内存带宽，但至少能用。其次，在 Ollama 里把上下文窗口调小，能显著减少内存占用。启动后进入交互界面，执行：
/set parameter num_ctx 4096这个命令把上下文长度限制在 4096 个 token 以内，内存占用会降下一截。
再用nvidia-smi或者任务管理器观察显存和内存的占用变化，别让模型推理跟其他大型软件抢资源。我记得有一次在笔记本上跑 7B 模型，关掉所有浏览器窗口之后速度直接翻倍，把后台资源腾出来这招真的很管用。
7. 安装“未完成”的折腾日记：Codex、Docker 与 PATH 排错
7.1 现象记录：安装卡住的共同特征
开发机配到最后，你大概率会遇到一次性“安装未完成”的提示。不要慌，这属于正常的排错流程。根据我自己的踩坑，最常见的几个场景和根因可以整理成下面的对照表：
| 场景 | 现象 | 常见根因 |
|---|---|---|
| Codex CLI 安装 | 进度走完又退出，命令找不到 | npm 缓存损坏、Node 版本不对、全局目录权限不够 |
| Docker Desktop 启动 | 始终转圈，无法进入工作状态 | WSL2 内核未更新，发行版未开启 WSL 集成 |
| Miniconda 安装 | 安装成功但 conda 命令不可用 | PATH 环境变量未写入，或者没有重开终端 |
| Elasticsearch 容器启动 | 容器反复重启 | JVM 堆内存设置不合理，宿主机内存不足 |
共同特征非常明显：安装过程本身没有给你一个明确的失败提示，而是悄悄退出，最终表现为“命令找不到”或“服务不响应”。所以第一步永远是看日志，而不是盲目重装。
7.2 排查链路一：下载环节与半成品文件
“安装未完成”有一半情况是下载环节出了问题。安装包下载到一半断了，或者从一个不可靠的来源拿到一个大文件同名但内容损坏的版本，安装程序可能不会报错，只是装完之后工具跑不起来。
我通常的做法是先确认下载来源。凡是热门 AI 工具，网上都会有一堆仿冒站点和劫持链接，你搜到“某某最新版下载”之后，一定要回到开发者官网或者官方 GitHub Releases 页面下载。下载完成后，有条件就做一次 SHA256 校验，官方页面通常会提供校验值。Windows 下可以用 PowerShell 执行：
Get-FileHash .\安装包.exe -Algorithm SHA256把得到的哈希值和官网对照，一致才安装。这一步能挡掉九成的“装了但坏着”的问题。
另外，杀毒软件和 Windows Defender 的实时扫描在安装大文件时也可能干扰安装进程。如果在资源管理器里看到安装包半天没反应，试试暂时关闭实时保护后再装，装完再开回来。
7.3 排查链路二：PATH、权限与系统变量
第二个高发区是 PATH 和环境变量。Windows 的 PATH 分为系统级和用户级，配置错一层就会导致“某个终端能用，另一个终端不能用的”怪现象。
排查时按这个顺序操作：
- 关闭所有旧终端，重新开一个，因为环境变量只在新的进程里才刷新。
- 在 PowerShell 里打印当前 PATH：
$env:PATH，看看目标工具的安装路径在不在列表里。 - 用
where.exe node、where.exe conda、where.exe docker查具体命令位置。 - 确认安装路径里没有中文、空格和引号。
权限问题往往藏得更深。如果你把工具装进了C:\Program Files反而容易遇到 UAC 弹窗和写入受限，AI 开发工具我推荐全部安装到用户目录，比如C:\Users\你的用户名\tools或者 D 盘的自定义目录，权限干净，路径也短。
7.4 一套我最常用的快速排查命令组
最后分享一套我在新机器上排错时一定会跑的检查命令组，可以直接存成一个小脚本，每次环境出问题先执行它缩小范围。
Windows 侧用 PowerShell 检查：
where.exe node where.exe conda where.exe docker where.exe codex node -v npm config get prefixWSL 侧用 bash 检查：
which python which ollama which docker python --version ollama list这套命令跑完，基本能判断出问题是出在“命令没装”还是“装错位置”还是“环境变量没生效”。大多数时候，问题就定位在这三者之间。
如果最后还是装不上，我的标准流程是：卸载工具，清理对应的缓存目录，比如~/.npm、~/.conda、~/.ollama，再重新安装。这一套“卸载、清理残留、重装”的组合拳非常老套，但反复实践下来成功率极高。缓存清理这一步千万别跳过，很多“安装未完成”的残留文件就是重装失败的元凶。
在这台全新的 Windows 开发机上，我花了不到一天把上述环境全部跑通。之后再开新坑项目，基本就是拉个requirements.txt起环境、写几行docker compose起中间件、配好 API Key 就能直接开工。AI 编程环境的搭建本质上是一次性投入，前面每多花十分钟把路径、权限、缓存、上下文文件理顺，后面每天都会省下几倍的时间。如果你正要开始，希望这份记录能帮你少绕一点远路。
