如果你最近想认认真真在Windows上搭一套能写代码、能跑大模型、能被AI Agent直接调用的开发环境而不是继续在网页聊天框里复制粘贴那这份从零指南基本是为你写的。标题里的20260909是我整理这套环境时的版本标记也就是说下面所有安装步骤、命令参数和坑点都是我在一台干净的Windows 11机器上从头到尾跑过一遍之后形成的快照。文章覆盖了从系统准备、GPU驱动、Miniconda、AI编程助手到本地大模型和Docker/WSL2的完整链路适合刚想入坑AI开发的程序员也适合早就常写业务代码、但一直没把AI工具链整理成一套可复现工程的人。我会把每个关键选择背后的理由讲清楚而不是只丢一串命令让你照着抄因为只有知道了“为什么”后面出问题时你才不至于两眼一黑。1. 先想清楚你要的到底是“AI聊天”还是“AI编程环境”很多人一上来就装了一堆工具最后发现根本用不上原因就是把“网页AI”和“编程环境里的AI”混为一谈。这两件事的差别值得花三分钟想明白。1.1 网页AI和本地AI开发环境的三点本质差别第一上下文范围完全不同。网页聊天框里你最多把一段代码粘进去让它帮你改它对你的项目结构、依赖版本、历史提交一无所知。而接进开发环境的AI助手比如Codex、Copilot这类能直接读你当前工作区的文件树和选中代码甚至能自己打开文件、执行命令、跑测试改的东西是落到磁盘上的真实文件不是聊天框里的临时答案。第二可重复性差很多。网页对话每次都要重新描述问题换一个会话就得重新喂一遍背景。编程环境里的AI工具可以配置成项目级常驻它知道你写的是Python还是TypeScript、用的什么测试框架、代码风格大致怎样。这些上下文一旦固化下来后面每一次提问的起点都比网页高得多。第三数据边界不同。公司的代码、个人项目的隐私数据、还没对外发布的算法细节你大概率不想全部贴进网页聊天里。本地大模型或者本地优先的AI编程助手至少在架构上给了你一个不出内网的选择。我这套环境里本地和远程模型是混合用的后面第六章会专门讲怎么搭。1.2 我要搭的这套环境包含哪些件传统意义上的“开发环境”可能只有一个编辑器和一套编译链但AI时代的编程环境我拆成了四层操作系统基础层Windows 10/11、WSL2、NVIDIA驱动。开发工具链层Git、Windows Terminal、PowerShell 7、VS Code、Node.js。Python运行层Miniconda用来隔离环境和装深度学习依赖。AI能力层接入远程API的编程助手Codex/Copilot、本地大模型运行时Ollama、以及把它们串起来的IDE插件。四层缺一层都会有明显的使用断层。比如你只装了VS Code和Copilot本地没有GPU驱动想顺手在笔记本上跑一个小模型做实验又得回头补一堆底层东西。既然叫“从零搭建”不如一次性把底座打牢。1.3 这套方案适不适合你按需求对照你的实际需求推荐路径是否建议走完整套偶尔查点代码写法网页AI就够不需要日常写业务项目想要代码补全和单文件解释IDE里装Copilot或Continue连远程API搭到第五章即可需要AI自己改多文件、跑命令、完成小任务必须上Codex这类Agent能力搭到第五章并配好沙箱代码敏感或经常断网需要本地模型兜底必须在Ollama上跑量化模型第六章是刚需要做RAG、向量检索、Agent记忆还得把Docker和WSL2搞定跑周边组件完整搭完我当时的目标是全都要日常开发让远程Agent处理复杂重构本地再养一个大模型处理离线提问和小规模代码解释。这样即便远程API额度不够或网络波动工作流也不会断。2. 硬件与系统准备这一步少了后面全白搭很多人在装软件阶段遇到各种莫名其妙的问题最后定位到根因都是系统层没准备好。Windows上的AI开发尤其依赖虚拟化和GPU驱动这两件事一旦出问题后面所有工具都会连环报错。2.1 最低配置和推荐配置先说硬件不是每个环节都需要高性能但内存和硬盘会成为隐藏瓶颈。项目最低要求推荐要求原因CPU支持AVX2的x86-64处理器8核16线程以上本地模型推理特别吃CPU除非你想全靠GPU内存16GB32GBWSL2、Docker、本地模型同时跑的时候16GB会非常紧GPU无独显也能把工具链装完NVIDIA显卡显存8GB以上本地跑7B量化模型需要约6GB显存14B需要12GB以上硬盘100GB可用空间512GB SSDMinicondaDocker镜像模型文件轻松吃掉100GBWindows版本Windows 10 22H2Windows 11 23H2以上WSL2和GPU透传在新版本上体验好很多如果你的机器是纯CPU也完全可以继续往下走只是第五章之前的远程API方案不受影响第六章本地模型部分建议选3B以内的量化版本。2.2 Windows版本、WSL2和虚拟化的坑Windows 10 22H2和Windows 11都支持WSL2但我强烈建议直接用Windows 11。原因不是性能而是Windows 11对WSL2、Docker Desktop、以及GPU在WSL里的透传支持得更顺滑少了很多驱动层面的兼容性问题。在装任何东西之前先确认两个开关BIOS里打开虚拟化技术Intel VT-x或AMD SVM。Windows功能里启用“虚拟机平台”和“适用于Linux的Windows子系统”。管理员身份打开PowerShell执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart执行完重启。如果这两步漏了后面wsl --install会提示安装成功但一启动Ubuntu就报“WSL注册表配置错误”或“虚拟化支持被禁用”非常折腾。2.3 NVIDIA驱动和CUDA到底怎么装才不出幺蛾子NVIDIA驱动的安装原则很简单去官网下载最新版或者用GeForce Experience/NVIDIA App更新然后重启。装完在CMD里跑一下nvidia-smi能看到显卡信息、驱动版本和CUDA Version那一行说明驱动活了。重点在这里驱动自己带的CUDA版本是“驱动支持的上限”不一定要装完整版CUDA Toolkit。你用PyTorch跑模型时PyTorch的wheel包里已经自带了运行时所需的CUDA库。只有当你需要自己编译CUDA扩展、做底层算子开发时才需要单独装CUDA Toolkit和Visual Studio的C构建工具。我见过太多人一上来就装整套CUDA Toolkit装完又不把VS Build Tools装全结果编译一个开源项目时满屏报错。普通AI开发驱动够用就行。真要装Toolkit记得版本要和你的PyTorch要求的编译版本对应不是越高越好。补充一个经验开发机建议用NVIDIA Studio驱动而不是Game Ready驱动偏稳定游戏机反过来倒是无所谓。3. 装工具链从Git到终端一步步来系统层就绪后开始装日常开发工具。这些工具单个看都不难但我见过很多人卡在“用安装包手动安装一路Next最后PATH乱了还找不到问题”。所以我推荐用Windows自带的winget把安装过程收敛成一条命令。3.1 用winget一站搞定Git和常用工具Windows 11自带wingetWindows 10需要去微软商店装“应用安装程序”。打开PowerShell建议直接用管理员逐条执行winget install -e --id Git.Git winget install -e --id Microsoft.WindowsTerminal winget install -e --id Microsoft.PowerShell winget install -e --id Microsoft.VisualStudioCode winget install -e --id OpenJS.NodeJS.LTS这几条命令分别安装Git、Windows Terminal、PowerShell 7、VS Code、Node.js LTS。为什么选winget而不是手动下载安装包因为winget会先检查已安装版本而且不会在桌面给你放一堆快捷方式装完的路径相对规范后续通过winget upgrade --all就能统一升级。装完重新打开终端验证一下git --version node --version code --version3.2 Windows终端和PowerShell的日常调校Windows Terminal装好后默认打开的可能还是Windows PowerShell 5.1而刚才我们装了PowerShell 7需要把默认配置文件改成PowerShell 7。打开Windows Terminal按Ctrl,打开设置在“启动-默认配置文件”里选择“PowerShell”。这一步很重要因为Miniconda和Codex这类工具经常只在当前版本的PowerShell里执行初始化命令如果在5.1里做了conda init回头打开的却是7会莫名其妙找不到命令。PowerShell的执行策略也顺手改一下避免后面跑安装脚本被拦Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser3.3 环境变量管理什么时候改改哪里才不会坑自己Windows环境变量分成“用户变量”和“系统变量”。装开发工具时尽量只动用户变量因为系统变量改坏了影响所有用户而且越权改系统变量是很多莫名其妙问题的根源。winget和安装包一般会自己写PATH。真正需要手动操作的是下面几种情况你手动解压了某个工具比如某些绿色版CLI需要把它的bin目录加进PATH。conda init在PowerShell里执行后会往PowerShell配置文件中写启动代码不是改注册表。某些命令行工具在系统重启后失效大概率是PATH里写的是安装包临时目录而不是实际路径。检查当前PATH里的重复和残缺项可以用$env:Path -split ;这条命令会把PATH拆成一行一项方便一眼看出哪条路径不对。我踩过最典型的坑是同一款工具被装了两遍导致不同终端里版本都不一样排查了半天才发现是PATH里的第一条先被命中了。4. Python环境Miniconda是AI开发最稳的起点Python是AI开发的地基但Windows上装Python是最容易出乱子的环节。官网装一个Python再 pip install 一堆包短期内能用一旦项目多起来就彻底失控。所以我的建议是直接用Miniconda理由很明确。4.1 为什么是Miniconda而不是裸装Python或Anaconda裸装Python只能靠venv隔离纯Python包但AI生态里有大量非Python系统依赖比如MKL数学库、CUDAToolkit、libgcc等。venv管不了这些。而且很多二进制wheel在不同Python版本之间不兼容换一个项目就得重新折腾一遍系统的运行库。Anaconda虽然把常用科学计算包都集成好了但体积巨大好几个GB而且它的默认软件源对普通开发者来说已经越来越臃肿许可策略也改过没必要为一个“开箱即用”付出那么多磁盘和升级负担。Miniconda是两者的中间态只带conda包管理器和Python本体环境隔离能力和Anaconda完全一样但干净、可控、升级方便。你需要什么包就装什么不想要的也不会被塞进来。4.2 安装和初始化最容易忽略的三个细节Miniconda官网下载Windows安装包安装时记住三件事选择“Just Me”安装不要选“All Users”避免写系统目录时权限不足。安装界面里的“Add Miniconda to my PATH environment variable”我建议不勾选。网上很多教程叫你勾是因为他们图省事但conda进PATH会和其他Python产生冲突尤其是你以后可能还要装别的Python工具链。不勾选用conda init来接管终端才是官方推荐玩法。安装路径记下来默认是C:\Users\你的用户名\miniconda3。装完后打开PowerShell 7执行conda init powershell然后完全关闭并重新打开终端让初始化代码生效。如果conda命令还是找不到检查是不是PowerShell 7的配置文件里没有这段初始化代码。可以用notepad $PROFILE打开配置文件看看有没有conda初始化块。这一步是新手翻车率最高的地方值得多花两分钟确认。4.3 用conda创建AI专用环境并验证GPU可用我不建议把包直接装进base环境AI项目依赖多且版本敏感base保持干净是长期舒服的关键。创建一个专门的AI环境conda create -n ai python3.11 -y conda activate aiPython版本选择3.11目前PyTorch和主流库对它的兼容性稳定3.12或3.13虽然更新但部分原生扩展还没有及时跟上的可能。然后装PyTorch这里命令不是固定的装的时候去PyTorch官网生成一条适配你CUDA版本的最新命令会是最稳妥的。我整理20260909这套环境时用的命令是CUDA 12.8对应的wheelpip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128装完后用这段Python脚本验证GPU是否真的可用import torch print(PyTorch版本:, torch.__version__) print(CUDA是否可用:, torch.cuda.is_available()) print(GPU型号:, torch.cuda.get_device_name(0) if torch.cuda.is_available() else 无)如果输出CUDA是否可用为False不要急着重装环境先用nvidia-smi确认驱动正常再看安装命令是不是用了CPU版索引。如果pip下载太慢在%APPDATA%\pip\pip.ini里配置一个国内镜像源可以缓解但记得只在公司或可信任网络环境使用。最后把这个环境导出成文件方便以后重建conda env export environment.yml项目换机器时一条conda env create -f environment.yml就能恢复现场这比再走一遍手动安装高效太多。5. AI编程助手入坑指南Codex/Copilot和它的Windows安装问题工具链装好了这章讲真正让AI参与编程的部分。现在的AI编程助手从形态上分两大类一类是IDE内嵌的代码补全和对话代表是GitHub Copilot另一类是能在终端里帮你改文件、跑命令的Agent型工具代表是OpenAI Codex。两者解决的是不同层次的问题不是一回事。5.1 现在主流的AI编程助手怎么选助手运行形态最擅长网络依赖GitHub CopilotVS Code等IDE插件行级补全、单文件解释、小范围重构远程APIOpenAI CodexCLI/桌面版多文件修改、执行命令、自主完成小任务远程APIContinueVS Code开源插件连接本地或远程任意模型取决于接的模型Cursor基于VS Code的独立IDE深度封装AI交互对新人友好远程API为主我自己的分工是Copilot负责写代码时的即时补全因为它的延迟低、对当前文件上下文把握准Codex负责接“把XX功能跑起来并写测试”这种需要动手操作的任务Continue平时默认接到本地Ollama用来做那种不适合远程API出面的问题。5.2 Codex在Windows上的安装步骤含“安装未完成”排查Codex有两个入口一个是终端CLI通过npm安装一个是桌面版App。CLI更灵活适合嵌进自动化流程桌面版交互更直观。CLI的安装方式npm install -g openai/codex codex login登录完成后在项目目录里运行codex就会进入对话式的终端界面它能看到当前目录的文件改动状态也能在你确认后执行命令。初次使用建议先开一个临时文件夹试水让它做些小任务比如“写一个Python脚本读取CSV并输出统计信息”观察它怎么调用工具、怎么处理报错再放进真实项目里。桌面版在Windows上经常有人卡在安装界面提示“安装未完成”我在20260909这次搭建时也遇到过一次。排查链路基本是固定的先装运行时很多安装包依赖WebView2缺失时界面能启动但安装进度推进不了。用命令winget install -e --id Microsoft.EdgeWebView2Runtime补上。以管理员身份运行安装程序。不要右键“以管理员身份”就完事先打开管理员PowerShell再执行安装避免UAC级别的权限黑洞。清理临时目录残留安装程序在中途失败后会在%LOCALAPPDATA%\Temp留下上次的安装缓存直接删掉再重试。给安装目录加白名单如果本机装了比较激进的安全软件或EDR终端管控安装包释放子进程会被拦截日志里又看不出来。我给C:\Users\用户名\AppData\Local\OpenAI加了排除规则之后问题消失。检查磁盘空间。桌面版体积不大但安装过程会解压多份临时副本C盘剩余空间少于10GB时会出现“安装未完成错误代码1603”这个最容易误判。安装完成后设置里的“允许AI执行命令”权限不要全部放开。Codex这类Agent是有操作能力的建议第一次用“每次都询问”摸清它的行为边界后再调整审批级别。5.3 让AI助手真正会“写项目”的提示词习惯同样是Codex有的人用起来像神队友有的人用起来像对牛弹琴差距往往在提示词习惯。我的经验是给AI交代任务时至少要包含项目背景、任务目标、验收标准、运行环境这四件事。比如项目背景这是一个Python FastAPI项目数据存在PostgreSQL里。 任务新增一个接口 GET /users/{id}返回用户信息和最近10条订单。 验收标准pytest测试通过使用项目已有的SQLAlchemy会话管理方式不要改动现有接口。 运行环境Python 3.11依赖见requirements.txt。不要让它一次干太多事。让AI先出一份“改动计划”你确认了再让它动手。这个“先计划后执行”的习惯能直接把翻车率砍掉一半。6. 本地大模型跑起来依赖网络和不依赖网络两套路远程API的强大毋庸置疑但代码敏感、或者出差断网的时候本地大模型是唯一不慌的底牌。Windows上跑本地模型目前体验最顺的工具是Ollama。6.1 用Ollama把开源模型跑在家里的Windows上安装Ollama有两种方式一种是最新安装包一种是wingetwinget install -e --id Ollama.Ollama装完打开一个新的终端先拉一个模型。以我用的Qwen2.5 14B量化版为例ollama pull qwen2.5:14b14B的量化模型8GB显存勉强能跑但会把上下文窗口压得很小体验一般。16GB显存以上跑起来就从容了。如果你的显存不大建议从7B或更小的模型开始ollama pull qwen2.5:7b这里要理解量化等级的概念。同一个模型4bit量化体积大概是参数量的0.5到0.6倍左右显存需求参考公式显存≈参数量(GB)×每权重比特数/8再加2GB左右给上下文和推理开销。所以7B模型4bit量化约需要4GB显存加2GB开销14B则要到8到10GB。模型量化等级越低效果损失越大但资源占用越小日常代码解释和文本生成4bit量化够用。6.2 把本地模型接到VS Code或Continue上Ollama装好并拉取模型后默认在http://127.0.0.1:11434开了个API服务而且兼容OpenAI接口格式。这意味着很多AI编程工具可以直接把它当模型源来配置。在VS Code里装Continue插件打开配置界面新增一个模型Provider选Ollama模型名填你拉取的模型名比如qwen2.5:14b。配置文件的本质是这样的结构{ models: [ { title: Local Qwen, provider: ollama, model: qwen2.5:14b, apiBase: http://127.0.0.1:11434 } ] }配上之后在IDE里就能随时和本地模型对话完全不走外网。和我上面第五章说的Codex/ Copilot形成互补联网时用远程Agent干重活敏感代码或断网时切到本地模型。6.3 让本地模型和远程API模型互补工作我实际使用中是这样分工的代码解释、文档改写、私有代码片段分析本地模型。复杂重构、填样板代码、写单元测试远程API。完全离线状态下的代码排查本地模型兜底。这样搭配还有个好处省钱。远程API的额度可以用在真正需要顶级模型能力的任务上日常琐事全丢给本地模型既快又不心疼。如果你还想让本地模型参与自动化流程直接用Python的OpenAI SDK指向Ollama的端点就行from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keyollama) resp client.chat.completions.create( modelqwen2.5:14b, messages[{role: user, content: 解释一下这行Git命令的作用git rebase -i HEAD~3}], ) print(resp.choices[0].message.content)这个用法打通之后你就能把本地模型塞进自己的脚本和Agent工作流里了。7. Docker和WSL2AI开发往往需要Linux生态AI开发绕不开Linux不是因为Windows不能写AI代码而是太多框架的编译二进制、容器镜像、GPU支持工具链都优先发布Linux版本。所以Windows上的AI开发共用一套“WSL2 Docker”的方案已经是社区共识。7.1 为什么AI开发离不开WSL2WSL2是一个轻量虚拟机跑的是完整的Linux内核和你的Windows宿主共享文件系统、网络和一部分硬件能力。对AI开发来说最大的价值是GPU透传只要Windows宿主的NVIDIA驱动正常WSL2里跑Linux版PyTorch也能直接调显卡。另一个价值是开发环境一致性。很多开源项目的README里给的安装命令是apt install ...在WSL2里可以直接执行不需要在Windows上装一个“Linux版本的模拟器”性能损耗也比WSL1和虚拟机要小。Windows 11上安装WSL2非常简单管理员PowerShell执行wsl --install装完重启默认会装好Ubuntu。首次启动会让你设置Linux用户名和密码然后就可以正常使用了。检查WSL版本wsl -l -v确保VERSION列是2。如果是1执行wsl --set-version 发行版名 2。7.2 Docker Desktop与WSL2的搭配和避坑装了WSL2之后Docker Desktop可以无缝集成。安装方式winget install -e --id Docker.DockerDesktop安装完成后打开Docker Desktop在设置里确认“Use the WSL 2 based engine”是勾选状态然后在Resources - WSL Integration里把你要用的发行版比如Ubuntu打开。这样你在Windows终端和WSL终端里都能用docker命令。常见的两个坑一是Docker Desktop启动一直转圈报“WSL update required”直接在PowerShell里执行wsl --update就好。二是WSL2默认会吃掉大量内存。如果Windows宿主机内存不大编译大型项目时整个系统都会卡死。解决办法是编辑用户目录下的.wslconfig文件限制内存和CPU[wsl2] memory8GB processors4 swap4GB然后执行wsl --shutdown让配置生效。7.3 用Docker跑RAG周边组件Postgres/Redis/ElasticsearchAI Agent和RAG应用经常需要PostgreSQL的pgvector、Redis做缓存、Elasticsearch做全文检索。这些东西在Windows上装精简版往往有一堆坑但在Docker里跑几乎是零成本。我在项目里直接用一个docker-compose文件把这些周边组件串起来services: pg: image: pgvector/pgvector:pg16 container_name: ai_pg environment: POSTGRES_PASSWORD: postgres ports: - 5432:5432 volumes: - pgdata:/var/lib/postgresql/data redis: image: redis:7-alpine container_name: ai_redis ports: - 6379:6379 volumes: pgdata:在包含这个文件的目录下执行docker compose up -d两个服务就起来了。需要Elasticsearch时再在compose文件里加一个elasticsearch:8.x的service改一下端口映射就行不需要在Windows里折腾那个zip包解压和各种JVM参数。这也是我在Windows上跑Redis和Elasticsearch这类中间件时首推的方式能用容器就别往系统里装。8. 从零搭完后的检查清单和翻车修复手册环境搭完别急着开工。先用一条链路做全链路验证确保所有环节真的通着然后收藏一份常见坑的排查表。我每次重构环境靠这两样东西能把重装之后的适应期压缩到一顿饭的工夫。8.1 一条命令一条命令验证环境打开一个全新的PowerShell窗口按顺序执行任何一条报错都值得停下来git --version conda --version node --version code --version python -c import torch; print(torch.cuda.is_available()) codex --version ollama --version docker version --format {{.Server.Version}} wsl -l -v到docker version这一步如果Server.Version为空或者报“docker daemon未运行”先去Docker Desktop确认引擎已启动。wsl -l -v看到所有发行版都是2说明底层虚拟化没有问题。验证通过后再手动做一次“AI完整走通”的测试在项目目录里让Codex生成一个Python脚本并运行。如果它能改文件、跑代码、输出结果说明Agent通道通了。接着在VS Code里切到Continue向本地Ollama问一句代码相关的问题如果有回复说明本地模型通道也通了。8.2 高频问题速查表现象根因快速修复conda命令找不到conda init未生效或PowerShell版本不对在PowerShell 7里执行conda init powershell重启终端Codex/ChatGPT桌面版提示“安装未完成”WebView2缺失、管理员权限不足、临时目录残留补装WebView2管理员PowerShell重装清理%LOCALAPPDATA%\Temptorch.cuda.is_available()为False显卡驱动太旧或装成了CPU版PyTorch更新驱动重装CUDA版wheel包用nvidia-smi确认驱动Docker Desktop启动失败WSL2内核太旧wsl --update必要时wsl --shutdownWSL2里内存爆炸默认不限制内存配置.wslconfig限制memory执行wsl --shutdownWSL里nvidia-smi报找不到驱动不完整或PATH缺少WSL的GPU库路径更新Windows侧NVIDIA驱动检查WSL路径是否包含/usr/lib/wsl/libVS Code终端里conda环境没有激活VS Code默认终端的PowerShell版本和初始化不一致在VS Code设置里把terminal.integrated.defaultProfile.windows设为“PowerShell”这个表是我踩坑之后沉淀下来的高频锁定路径。你遇到问题时先对照现象定位到根因再动手比反复卸载重装高效得多。8.3 现场排查两次“真实事故”的完整链路第一个事故是我装了oh-my-posh美化终端后PowerShell一打开就报command not found: conda但Windows PowerShell 5.1里conda是好用的。排查链路是这样的先检查PowerShell 7的配置文件notepad $PROFILE发现里面确实有conda的初始化代码。再检查PowerShell 5.1的配置文件发现也有。此时怀疑是执行顺序问题oh-my-posh的初始化代码和conda初始化代码冲突后者被前者覆盖了。对比两个配置文件后发现新装的PowerShell 7用的是另一个profile路径conda代码被添加在了系统级profile里但系统级profile的执行被组策略拦截了。最终解决在PowerShell 7里重新执行conda init powershell这次写入用户级profile问题消失重启后一切正常。这事的启示是当工具链在某个终端里失效时先检查profile里到底有没有那段初始化代码再检查是不是被组策略或执行策略拦截不要一上来就重装conda。第二个事故是在WSL2的Docker容器里跑GPU任务报错 “could not select device driver with capabilities: [[gpu]]”。排查顺序先在WSL2里运行nvidia-smiGPU信息正常。再看Docker Desktop版本发现running的Docker Engine其实是Windows容器模式不是Linux容器模式。到Docker Desktop设置里把“Use the WSL 2 based engine”打开重启后docker run --rm --gpus all cuda镜像 nvidia-smi终于输出GPU信息。后续又在docker-compose文件里加了gpus: all配置才算彻底解决。这个坑的本质是Docker的“Linux容器”和“Windows容器”两套后端混淆了。凡是GPU容器、Linux镜像一律用WSL2后端不要混着跑。设备准备好之后我一直建议把下面这些东西当成“可复现资产”纳入版本管理Miniconda的environment.yml、.wslconfig、PowerShell的$PROFILE、还有Docker的compose文件。这套环境装完之后真正值钱的不是哪条命令而是这些配置文件里沉淀下来的决策和经验。把它们放进自己的dotfiles仓库下次换电脑或者同事问你怎么搭你直接把仓库丢过去就行了。