Windows AI编程环境搭建：WSL2+Docker+Ollama实战指南-平芜编程栈

如果你点进这篇文章，大概率跟我当初一样——准备在Windows上认真搞AI开发，结果查资料查到头皮发麻。网上教程各自为战，有的让你装Python，有的让你装Docker，有的直接甩给你一句WSL2命令，你照着敲完也不知道自己在干嘛。这篇文章就是把这堆碎片拼起来，从Windows系统层开始，到WSL2、Docker、VS Code里的AI插件，最后再塞一个本地大模型，组成一套能真正干活的AI编程环境。我实际踩过一遍的完整记录都在下面，照着走基本能一次跑通。

这次搭建基于Windows 11 + WSL2 + Docker Desktop的组合，核心是解决三个问题：多语言运行时怎么管理、AI辅助服务怎么隔离、本地大模型怎么接入现有开发流程。整个过程按“基础层 → 容器层 → 工具层 → 模型层”逐级展开，每层都给了验证方法。无论你是刚入门想做AI应用开发的学生，还是已经在写业务代码想引入AI工具的开发者，这套方案都适用，而且每一步都考虑了后续扩展。

1. 环境方案怎么选：别一上来就追求“全家桶”

1.1 “AI编程环境”拆开是哪几坨

很多人把AI编程环境理解成“装一个PyCharm再装个ChatGPT插件”，这其实是把问题想小了。真的要在Windows上顺畅做AI开发，底下综合着四五个完全不同的组件，它们各有各的职责范围。

第一层是语言运行时。Python大概率跑不掉，因为AI生态的库、框架、脚本基本都是Python优先。如果你要写Java后端对接AI能力，那JDK 17甚至21也要装。要是碰前端或CLI工具，Node.js又得有一份。这一层的问题是版本冲突和路径混乱，所以需要一套相对规范的管理办法。

第二层是AI辅助服务。实际开发中你不太可能只用模型本身，往往还要配套向量数据库、Redis缓存、消息队列、PostgreSQL这类基础设施。这些服务如果在Windows原生环境里挨个装，各种服务和端口会乱成一锅粥，删除卸载还拖泥带水。容器化是这里最干净的解法。

第三层是开发工具。VS Code已经事实标准，AI插件生态也最丰富。GitHub Copilot、Codex CLI、各种代码补全插件，全部围绕它工作。工具选得好不好，直接决定AI功能用起来顺不顺手。

第四层是模型运行时。如果你想在本地跑私有模型做实验、做隐私数据分析，或者单纯不想依赖远程API，那需要一个支持本地推理的运行时。Ollama目前体验最省心，装完拉模型就能用，背后暴露一个HTTP API，供任何语言调用。

把这四层拆开以后，整个环境的脉络就清楚了。后面每一步，都是在给这些层填具体方案。

1.2 为什么选了WSL2 + Docker这套组合

先说结论：Windows原生环境我保留给IDE和日常办公，开发相关的服务全部塞进WSL2和Docker容器里，这样最省心。

为什么不建议全部在原生Windows里做？AI生态里有大量软件是Linux优先，很多库在Windows上的坑非常多。比如某些编译型Python包要么装不上，要么要手动下载预编译的wheel，要么因为路径分隔符问题跑不通。就算你靠毅力把所有Python包都装成功了，将来要部署到服务器时又会发现，服务器全是Linux环境，本机和线上环境不一致，各种潜在Bug。

虚拟机倒是能解决一致性问题，但VMware或者VirtualBox太重了。开一个完整Linux虚拟机要占几个GB内存，启动慢，文件共享、端口映射、GPU透传全是麻烦事。日常操作还要在Windows和虚拟机之间来回切换，效率很低。

WSL2刚好卡在中间。它不是一个完整虚拟机，但内嵌了一个经过优化的轻量Linux内核，启动速度接近原生进程，内存占用可以控制，和Windows的文件互通，还能直接把端口暴露出来。更关键的是，微软官方把WSL2做成了Windows AI开发的默认路径，Docker Desktop、NVIDIA CUDA、VS Code Remote都原生支持WSL2。

这套组合最直观的好处是环境可复制。所有依赖服务的安装过程都写进docker-compose.yml，换电脑时一条docker compose up -d全部恢复，不用再翻历史教程挨个装。Python依赖用requirements.txt或pyproject.toml管住，模型用ollama pull拉取，整个开发环境几乎可以做到一键重建。

当然了，WSL2也不是没有缺点。跨文件系统IO是最大的坑，Windows的盘挂载在/mnt/c这样的路径下，在那边跑编译、装依赖会明显慢。解决办法也很粗暴：工作项目一律放在Linux文件系统里，也就是/home/你的用户名/下面，别放在/c/Users/xxx里，否则后续装Node模块或Python包能等到怀疑人生。

1.3 Docker Desktop和WSL2各自该干什么

很多第一次接触这套东西的人会混淆，WSL2已经是一个Linux环境了，为什么还要装Docker？这两者的关系可以类比成：WSL2是地基，Docker是在地基上盖的一栋栋房子。

WSL2给你一个完整的Linux发行版，你可以在里面自由安装软件包、跑系统服务、做任何Linux操作。但如果你直接用WSL2原生装Redis、装PostgreSQL、装Python环境，时间一长就会回到老问题：依赖冲突、版本混乱、删除不干净。Docker Desktop的作用，是把所有这些服务都包装成互相隔离的容器，每个服务有自己独立的文件系统、网络、端口映射，互不干扰。

Docker Desktop在Windows上跑了WSL2后端，所以它的容器实际上是运行在wsl虚拟化层里，但用户完全感知不到这一层，只管docker命令就行。你可以在WSL2里跑项目的核心代码，同时在Docker容器里跑配套服务，两边用端口通信，开发体验跟一台独立Linux服务器几乎没有区别。

还有一个值得注意的点，Docker Desktop现在对大公司商用有许可限制。开源项目、个人开发、小企业（员工少于250人且年收入低于1000万美元）可以免费，但大公司团队使用需要购买订阅。如果你所在公司是这种情况，可以在WSL2里直接装原生的Docker Engine，效果一样，只是少了Docker Desktop提供的图形化界面。

2. 基础层搭建：系统、WSL2、Python、Git

2.1 先检查系统和虚拟化开关

整个环境的地基是WSL2，所以第一步就是把Windows系统准备好。我用的是Windows 11，实际上Windows 10 21H2以上版本也都支持，安装方法差别不大。先打开“任务管理器”，切到“性能”标签，看CPU区域有没有显示“虚拟化：已启用”。如果没有，需要进BIOS把Intel VT-x或者AMD-V打开，这一步不做，后面所有虚拟机相关功能全部跑不起来。

确认虚拟化没问题后，以管理员身份打开PowerShell，执行下面这条命令：

wsl --install

这条命令会自动打开需要的Windows可选功能（适用于Linux的Windows子系统和虚拟机平台），然后下载并安装WSL2内核，默认还会装一个Ubuntu发行版。装完以后按提示重启电脑，这个环节没得商量，直接重启。

重启之后第一次启动Ubuntu，会要求你设置Linux用户名和密码。注意这个用户名可以跟Windows登录名不一样，它影响后面Linux环境里的路径前缀，比如/home/你的用户名/。密码要记住，因为Linux下用sudo安装软件时经常要输。

2.2 WSL2内存和CPU资源控制

WSL2默认会吃掉Windows剩余内存的一半以上，而且上限不设防。如果你电脑只有16GB内存，一边跑Docker容器一边开浏览器和IDE，很容易卡到怀疑人生。所以在WSL2开始干活之前，建议先写一个配置文件把资源框住。

在Windows用户主目录下新建一个文件，名字叫.wslconfig，内容可以这样写：

[wsl2] memory=8GB processors=4 swap=2GB localhostForwarding=true

memory指的是WSL2能用的最大内存，processors是分配的CPU核数，swap在物理内存不够时兜底。数值根据你机器实际配置调整，我的机器是32GB内存、8核CPU，给WSL2分8GB和4核足够跑日常开发了。改完这个文件，在PowerShell里执行wsl --shutdown，再重新进入WSL2，配置才生效。

这条配置很值得做。我见过很多人Docker Desktop跑着跑着整个电脑变卡，打开任务管理器一看，是WSL2把内存吃光了。提前限制资源，Windows侧才留得下余量，IDE和浏览器不至于跟着遭殃。

2.3 Python环境：官方解释器加venv就够了

说起Python环境，网上一大半教程会让你装Anaconda。我的观点很明确：如果不是做大量数据分析、科学计算，日常AI应用开发就用官方Python加venv，干净、可控、不污染全局。

先到Python官网下载Windows安装包，我建议选3.11或3.12，这两个版本对AI生态的兼容性最好，坑最少。安装时务必勾选Add Python to PATH，否则后面命令行里敲python会提示找不到命令。安装完成之后，打开PowerShell确认一下：

python --version pip --version

在Windows上装Python包，C扩展编译经常报错。解决办法是优先使用预编译的wheel包，pip在多数情况下会自己选对版本，实在遇到没有预编译包的库时再考虑装Visual Studio Build Tools，那个体积很大，能避则避。

Python多版本管理的需求也确实存在。如果你想同时用3.10和3.12，推荐安装pyenv-win。在PowerShell里执行：

pip install pyenv-win

然后就能通过pyenv install 3.12.0和pyenv global 3.12.0在版本之间切换了。不过对大多数读者来说，装一个稳定版Python然后靠venv隔离项目依赖就够了，多版本是后话。

每次新建项目时，推荐固定一套操作流程：先创建目录，再用python -m venv .venv创建虚拟环境，激活后安装依赖。在Windows上激活虚拟环境是：

.venv\Scripts\activate

激活之后命令行前面会出现(.venv)标识，这时候pip安装的所有包都只对这个项目生效。这套流程简单到没什么技术含量，但能避免掉90%的包冲突问题。

2.4 Git安装和最小配置

到了AI时代，Git依然是所有开发工作的前提，因为你要拉取模型代码、第三方库、协作项目。Windows下装Git，直接用gitforwindows.org的安装包。

安装向导里有两个选项要特别注意。第一个是Adjusting your PATH，选择Git from the command line and also from 3rd-party software，方便在PowerShell和WSL里直接调用git。第二个是Line Ending Conversions，推荐选Checkout as-is, commit Unix-style line endings，避免Windows的CRLF换行符污染代码仓库。

装完后在PowerShell里设置用户信息：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这两行不做的话，后面每次commit都会报错让你补配置，非常烦人。还可以顺手设置默认分支名和常用别名：

git config --global init.defaultBranch main git config --global aliases.st status git config --global aliases.ci commit

到这一步，Windows侧和WSL2侧的基础工具链就齐了。接下来进入容器层，把那些旁支末节的服务全部装进Docker。

3. Docker容器化：把依赖服务全部关进盒子

3.1 Docker Desktop安装

Docker Desktop现在版本更新很快，安装本身没有什么门槛。去官网下载Windows版安装包，安装过程中Windows会提示你安装WSL2更新包，这个必须装。安装完成后启动Docker Desktop，首次启动会要求设置，在“Use the WSL 2 based engine”选项处打勾，Docker就会跑在WSL2后端上。

启动后验证一下是否工作正常，在PowerShell里执行：

docker --version docker ps

如果docker命令可用而且docker ps不报错，说明Docker核心已经正常。这一步常见的坑是docker命令提示找不到或者连接到引擎失败，绝大多数原因是Docker Desktop还没完全启动，多等一会儿再执行就对了。

Docker Desktop设置里的Resources选项卡也值得调一下。这里能限制Docker占用的CPU和内存，我一般会把内存限制在4GB以内，因为后续还要给Ollama和WSL2本身留空间。如果磁盘紧张，可以把Docker的磁盘镜像位置挪到其他分区，在设置里面直接改就行。

3.2 跑起第一个容器：用Redis练手

学习Docker最好的方式不是看教程，而是跑一个真实服务。下面用Redis练手，因为它轻量、启动快、依赖少，适合验证整个链路。

在PowerShell里执行：

docker pull redis:7-alpine docker run -d --name dev-redis -p 6379:6379 redis:7-alpine

第一行从镜像仓库拉取Redis 7的alpine版本，alpine是一个极简Linux发行版，镜像体积小，只有几十MB。第二行的关键参数是-p 6379:6379，它把容器内部的6379端口映射到Windows本机的6379端口。这样你的Windows程序、Python脚本、WSL2里的代码，都能通过localhost:6379连接到这个Redis。

执行完以后，用docker ps看容器状态，显示UP就说明成功了。然后验证连接：

docker exec -it dev-redis redis-cli ping

正常会返回PONG。到这里，你已经完成了第一次容器化服务部署。以后所有中间件服务都是这套模式：拉镜像、起容器、映射端口，删除服务时docker rm -f dev-redis一行搞定，不会留下任何残留文件。

3.3 docker-compose编排一组AI依赖

单个容器好办，但实际AI项目往往同时需要向量数据库、Redis缓存、PostgreSQL等多个服务。用docker run一条条启动不仅啰嗦，而且服务之间的网络和依赖关系很难维护。这时用docker-compose，把全部服务写在一个YAML文件里。

我在项目里用的一个最小配置长这样：

services: redis: image: redis:7-alpine container_name: ai-redis ports: - "6379:6379" volumes: - redis-data:/data restart: unless-stopped qdrant: image: qdrant/qdrant:latest container_name: ai-qdrant ports: - "6333:6333" - "6334:6334" volumes: - qdrant-data:/qdrant/storage restart: unless-stopped volumes: redis-data: qdrant-data:

这个文件放到项目根目录，命名docker-compose.yml。然后在当前目录执行：

docker compose up -d

-d表示后台运行。等几秒钟后，docker compose ps会显示两个服务都在运行。volumes那段是数据持久化配置，容器删掉重建后数据依然保留，这对数据库类服务是必要条件，否则每次启动容器数据就丢了。

以后升级版本也简单，改一下配置文件里的镜像tag，再执行docker compose up -d，Docker会自动重新创建变化的容器。这套配置放进Git仓库里，团队成员拉到项目后只需要执行一条命令就能把基础设施全部拉起来，环境一致性拿捏得死死的。

3.4 容器和Windows文件系统的交互

容器里运行的服务，数据和代码都封装在容器内部，Windows侧一般不直接访问。但有一种情况很常见：你想把Windows下载的训练数据、模型文件、代码仓库挂载进容器里使用。这时可以在docker-compose.yml的services里加volumes映射：

services: app: image: python:3.12-slim volumes: - C:/Users/你的用户名/projects:/workspace

这样Windows下C:/Users/你的用户名/projects目录就映射到了容器的/workspace，两边内容实时同步。不过我得提醒一句，这种Windows目录挂载进容器的IO性能并不好，跑起来比纯Linux环境慢。更推荐的路径还是把代码放在WSL2的Linux文件系统里，然后让容器直接挂载WSL2的目录，性能会好很多。

4. 开发设施：VS Code、AI插件和Codex命令行

4.1 VS Code加Remote-WSL，在Linux环境里写代码

基础服务和容器都准备好了，接下来是真正写代码的地方。VS Code这些年能成为AI开发的主力编辑器，很大程度靠的是Remote-WSL插件，它让你在Windows的图形界面里，直接编辑和运行WSL2 Linux里的代码。

安装VS Code后，在扩展市场搜WSL，安装微软官方的Remote Development扩展包。装完后，在WSL2终端里进入你的项目目录，执行：

code .

第一次执行会自动在Windows侧启动VS Code，并以WSL模式连接当前目录。左下角显示WSL: Ubuntu，说明你此刻编辑的是Linux文件系统里的项目。这时候终端是Linux终端，Python环境是Linux的Python，执行的shell命令也是Linux命令，但界面还是那个熟悉的Windows软件，体验非常顺滑。

我长期使用下来觉得，这套方案比直接在Windows原生环境写代码舒服，因为文件路径、安装依赖、运行脚本全部和Linux服务器保持一致，不会有各种平台差异带来的精神内耗。

4.2 把GitHub Copilot接进编辑器

AI编程助手是目前最直接的提效工具，GitHub Copilot在其中属于老牌且稳定。VS Code里装好Copilot扩展，登录GitHub账号授权，紧接着打开一个Python文件，输入一个函数名加注释，Copilot就会开始在后台生成建议代码，灰色显示时按Tab直接接受。

日常用得最多的是两个操作：Tab接受代码，Esc关闭建议。想看多个可选方案时按Ctrl+Enter，会呼出候选列表，比较后选择更合适的一段。Copilot还有个InChat功能，选中代码直接问“这块逻辑有什么问题”“帮我加上类型标注”，会直接在对话里给出修改建议。

需要注意两点。一是Copilot输出质量跟上下文关联很大，文件里已有的代码风格、依赖、开源许可证、命名习惯都会影响推荐结果，所以新项目第一份代码最好自己写，给Copilot建立风格基准。二是AI补全的代码不代表正确，涉及安全、鉴权、资金计算的核心逻辑，一定要人工review，模型生成的内容目前不适合无脑采用。

4.3 使用OpenAI Codex命令行，试试自然语言驱动开发

Codex是OpenAI推出的编程代理工具，可以直接用自然语言描述任务，由它自动分析代码库、修改文件、运行命令，然后给你结果。它在Windows上的安装和使用已经非常简单，前提是装了Node.js 20以上版本。

先安装CLI：

npm install -g @openai/codex

然后执行codex并登录OpenAI账号，完成授权。登录成功后，进入一个项目目录，尝试提出一个真实任务：

codex "给这个Python服务加一个健康检查接口，返回json格式的status和version，并补上对应的测试"

Codex会先扫描项目文件，理解代码结构，然后直接改代码、创建测试文件，最后跑一遍相关命令验证。这个过程中你可以像跟人交流一样继续追加问题，比如“用pytest而不是unittest”“不要修改现有接口的参数格式”。

实际用下来，Codex最适合处理两类事情：一是不太想手动写的模板代码，比如REST接口、数据模型转换、测试用例；二是探索陌生项目时让它帮忙解释代码结构。不过它也不是万能的，面对大型复杂重构或者涉及多个模块联动的任务容易反复试错，我建议从单个文件、明确边界的小任务入手。

4.4 给AI写提示词的三层包装

用AI编程工具，提示词质量决定输出质量。我习惯把提示词拆成三层：背景、约束、验收标准。

背景层告诉AI你在什么项目里、用什么语言、目标是什么。比如“我在一个使用FastAPI的Python项目中，需要新增一个用户注册接口”，而不是只说“写个注册接口”。AI知道的背景越具体，生成的代码越贴切。

约束层说清楚边界。包括不许新增额外依赖、遵循项目现有代码风格、代码要带注释、错误处理要完整等内容。这一步能把AI从“泛泛地写一段能跑的代码”拉回“在你这套体系里写一段合格的代码”。

验收层让AI先思考再动手。可以在提示词末尾加一句“先列出实现方案，我再确认后你开始改代码”。这能避免AI直接动手改错方向，尤其是Codex这类自动执行工具，先让它说方案，花的时间很少，但能节约大量改错成本。

5. 把本地大模型和AI应用串起来

5.1 本地大模型运行时：Ollama

前面所有准备工作，最终都会服务于一个目标：让AI能力真正跑在自己的项目里。本地大模型是重要一环，它有隐私安全、离线可用、调用零成本这些远程API难以替代的优点。Ollama是目前体验最好的本地模型运行工具，Windows版直接安装即可，装完会在后台跑一个轻量服务。

安装完成后，在PowerShell里执行：

ollama pull qwen2.5:7b

这个命令会下载阿里的Qwen2.5 7B模型，体积大概4GB左右，需要等一会儿。下载完成后执行ollama run qwen2.5:7b，就能直接在交互式对话里测试模型效果。

更重要的是Ollama暴露了一个标准HTTP API，供任何程序调用。默认地址是http://localhost:11434，通过POST /api/chat传入消息就能拿到回复。这就意味着你的Python脚本、Java后端、网页应用，都可以直接通过HTTP调用本地模型，不用装任何SDK。

如果机器配置一般，建议优先选择小参数模型，比如qwen2.5:7b或者llama3.1:8b。它们对显存要求相对宽松，8GB显存基本能流畅运行，推理速度在可接受范围内。

5.2 Spring AI集成：让Java后端也能跟模型对话

如果你主要写Java后端，想调用本地Ollama模型，Spring AI框架是当前主流选择。它把对接不同AI模型的复杂底层封装成一套统一接口，写起来非常轻量。使用Spring AI之前需要先安装JDK 17，去Oracle或Adoptium官网下载Windows安装包，装完设置好JAVA_HOME环境变量即可。

创建一个Spring Boot项目，在pom.xml里加入依赖：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-ollama-spring-boot-starter</artifactId> <version>1.0.0</version> </dependency>

然后在配置文件application.yml里指定Ollama地址：

spring: ai: ollama: base-url: http://localhost:11434 chat: model: qwen2.5:7b

接着写一个极简的Controller：

@RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient = builder.build(); } @GetMapping("/chat") public String chat(@RequestParam String message) { return chatClient.prompt(message).call().content(); } }

启动项目后，访问http://localhost:8080/chat?message=你好，Spring AI会调用本地Ollama服务把模型回复返回给你。这套集成方式的好处是Java应用内部不需要处理任何HTTP请求细节，模型调用跟普通函数一样透明，团队协作时也容易统一规范和做单元测试。

5.3 做一个最小RAG：本地知识库问答

本地模型只有在结合知识库时，价值才会真正放大。RAG的思路很简单：先把你的文档切片、向量化后存入向量数据库，用户提问时先检索出相关片段，再把问题加片段拼成完整提示词交给模型回答。这样模型能基于你的私有资料给出带依据的回答，而不用重新训练模型。

用前面装好的Ollama做embedding，Qdrant做向量存储，Python做胶水，流程很清晰。先安装Python客户端：

pip install qdrant-client requests

然后分四步实现。第一步，把文档按段落切分成小块，每块一两百字。第二步，调用Ollama的embedding接口把每块转成向量。第三步，把向量和原始文本一起存进Qdrant的collection。第四步，提问时同样转成向量，在Qdrant里检索最接近的几块文本，拼进提示词后调Ollama生成回答。

实现逻辑参考如下：

import requests from qdrant_client import QdrantClient client = QdrantClient(host="localhost", port=6333) def get_embedding(text): resp = requests.post("http://localhost:11434/api/embeddings", json={"model": "qwen2.5:7b", "prompt": text}) return resp.json()["embedding"] # 1. 切分文档 chunks = ["第一段文档内容", "第二段文档内容", "..."] # 2. 转向量并入库 vectors = [get_embedding(c) for c in chunks] client.upsert(collection_name="knowledge", points=[ {"id": idx, "vector": vectors[idx], "payload": {"text": chunks[idx]}} for idx in range(len(chunks)) ]) # 3. 检索 query_vec = get_embedding("你的问题") hits = client.search(collection_name="knowledge", query_vector=query_vec, limit=3) context = "\n".join(h.payload["text"] for h in hits) # 4. 组装提示词调用模型 prompt = f"根据以下资料回答：\n{context}\n问题：{query}" resp = requests.post("http://localhost:11434/api/chat", json={"model": "qwen2.5:7b", "messages": [{"role": "user", "content": prompt}], "stream": False}) print(resp.json()["message"]["content"])

这段代码演示的是最简流程，生产环境可以加词频过滤、文档去重、重排序等优化，但核心骨架就是这样。有了本地知识库之后，你可以把公司文档、学习笔记、个人资料都喂进去，让模型“记住”那些通用大模型不知道的私有信息。

6. 问题排查实录：我踩过的坑，你直接避开

环境搭建过程中总会遇到各种问题，我把最常见的几个整理成一张速查表，附上解决思路，遇到类似报错直接照着处理就行。

现象	根本原因	解决方案
wsl --install卡住或提示错误	虚拟化未开启	进BIOS开启Intel VT-x/AMD-V，关闭后重试
WSL2启动后内存占用过高	未配置.wslconfig	新建.wslconfig限制memory和processors，执行wsl --shutdown
Docker Desktop启动后一直转圈	WSL2内核版本过旧	执行wsl --update更新内核，然后wsl --shutdown重启
docker pull速度慢	镜像仓库网络不稳定	在Docker Desktop的Docker Engine配置里添加registry mirror，使用国内可访问的镜像地址，地址需在你的云服务商控制台获取
Python虚拟环境无法激活	PowerShell执行策略限制	以管理员运行Set-ExecutionPolicy RemoteSigned，然后重开终端
端口被占用导致容器启动失败	Windows本机已有同端口服务	修改docker-compose.yml的ports映射，如6379改为6380
VS Code远程连接WSL失败	WSL发行版内缺少ssh或VS Code Server依赖	在WSL终端执行sudo apt update && sudo apt install wget ca-certificates之后重试
Codex命令行提示找不到Node	Node版本低于20	重新安装Node.js LTS版本，确认node --version输出大于20

有几个坑值得单独强调一下。第一个是PowerShell执行策略，很多Windows新手第一次激活Python venv时报错，一看提示是“禁止运行脚本”，这不是venv坏了，是Windows默认策略不让执行.ps1脚本。用第二条解决方案里那条命令改掉就行。

第二个是路径问题。我见过很多人在Windows上把项目放在C:\Users\xxx\Desktop\project，然后在WSL2的VS Code里对着这个路径各种操作，编译速度慢到难以忍受。我个人的建议是项目目录统一放在WSL2的~/projects下面，Windows桌面只放日常办公文件，开发项目跟系统解耦，以后备份和迁移也方便。

第三个是版本选择问题。Docker镜像的tag一定要写明确版本，不要盲目用latest。今天看着能用，哪天镜像作者更新了breaking change，拉取新镜像后服务可能就起不来了。Redis用7-alpine，Qdrant用带日期版本的tag，Python镜像用3.12-slim，这些都是经过实际验证的稳定组合。

最后分享一个我自己的排查习惯：新环境搭完以后，先跑通一条“最小链路”再往上叠功能。比如这套环境，最小链路就是Windows能跑Python、Docker容器能跑Redis、Ollama能本地对话，这三件事都通了，说明基础层没毛病，后面加AI辅助和RAG功能时有问题就能快速定位是新增部分的错，而不是从头怀疑环境本身有问题。

写在最后：一次配好，长期受益

搭建这套环境最忌讳一步到位。很多人上来就想把所有工具全部装齐，结果装到一半被各种报错劝退。我自己的建议很简单：先用Python跑通一个小脚本，再上Docker跑一个Redis，最后装Ollama聊天。每完成一步就正常开发一段时间，让环境在真实使用中慢慢变完整，遇到问题再补。

几次踩坑之后我现在换新电脑基本一小时搞定全部环境。核心依赖就三样：WSL2、Docker Desktop、Python，剩下所有东西要么写在docker-compose.yml里，要么写在requirements.txt里，要么用ollama pull拉模型，根本没有“再配一次”的负担。这套环境搭好后，后续学习AI编程、做个人项目、接企业应用开发，底层都不会再拖后腿。