企业官网建设流程全解析

1. 项目概述：为什么在WSL2里跑CUDA不是“花架子”，而是真能省下一台工作站的钱

最近有好几位做AI模型训练的同行朋友，发来截图问：“你这WSL2里nvidia-smi能出来，torch.cuda.is_available()也返回True，是不是骗人的？”——我直接把终端录屏发过去：一边是Windows上开着VS Code写PyTorch代码，另一边WSL2里watch -n 1 nvidia-smi实时刷着GPU显存占用，top里Python进程稳稳吃着4个CPU核心，TensorBoard网页在Edge里开着实时曲线……他们沉默三秒后回：“原来不是demo，是真干活用的。”

这就是本项目标题背后的真实场景：Win10 + WSL2 + CUDA 11.0 + Ubuntu + TensorFlow/PyTorch，不是实验室里的玩具配置，而是大量算法工程师、学生党、小团队在没有独立Linux服务器、又不想放弃Windows生态（比如Office、微信、专业设计软件）前提下，构建出的一套零额外硬件投入、开发调试无缝切换、模型训练可落地的本地AI开发环境。关键词里“WSL2”“CUDA11.0”“Ubuntu”“TensorFlow”“PyTorch”五个词，每一个都踩在2020–2022年Windows端AI开发的痛点上——它解决的不是“能不能跑”，而是“能不能稳定跑满GPU”“能不能复现论文环境”“能不能和同事共享Docker镜像”“能不能接上公司内网GitLab和私有PyPI源”。

我实测过三台不同配置的Win10机器：一台是某品牌游戏本（RTX 3060 + 32GB内存），一台是老款工作站（Tesla P4 + 64GB内存），还有一台是公司配的办公本（MX350独显 + 16GB内存）。结果很明确：前两台完全胜任中等规模模型训练（ResNet50微调、BERT-base finetune、YOLOv5s训练），第三台虽不能训大模型，但做数据预处理、模型推理、单元测试、CI脚本验证毫无压力。关键在于，所有操作都在同一个Windows账户下完成，不需要双系统重启，不需要虚拟机资源争抢，也不需要远程连服务器——你的Jupyter Notebook就在Windows文件资源管理器里双击打开，代码改完Ctrl+S，终端里python train.py回车，GPU就动起来了。

这个配置的价值，不在于技术多炫酷，而在于它把“AI开发环境搭建”这件事，从一个需要专门运维支持、耗时半天起步的“项目”，压缩成了一次性配置、后续零维护的“默认工作方式”。接下来我会带你一砖一瓦搭起来，不跳步、不假设、不甩链接，所有命令都带解释，所有报错都有对应解法，所有参数选择都告诉你为什么这么定——因为我自己就是从wsl --install敲错成wsl install被卡住半小时过来的。

2. 整体架构设计与关键决策逻辑：为什么选WSL2而不是VMware？为什么锁死CUDA 11.0？

2.1 架构分层：从Windows内核到PyTorch张量运算，每一层都得“对得上”

这套环境本质是四层嵌套结构：

• 最外层：Windows 10（Build 19041+）
  这是基石。WSL2依赖Windows的Hyper-V轻量级虚拟化能力，所以必须是Win10 2004及以上版本（对应内核版本≥19041）。低于这个版本，哪怕强行升级WSL2内核也会在GPU直通环节失败。我见过太多人卡在这一步，反复重装NVIDIA驱动，最后发现只是系统版本太老——微软官方明确写了“WSL2 GPU support requires Windows 10 version 21H2 or later”，但实际测试中2004（19041）已可满足基础需求，21H2（19044）更稳。别信网上“只要装了WSL2就能用GPU”的模糊说法，版本号必须手动核对：winver命令弹窗里看清楚。

• 第二层：WSL2 Linux内核（5.10.16.3-microsoft-standard-WSL2）
  注意，这不是你apt update装的Ubuntu内核，而是微软预编译的专用内核。它通过wsl --update升级，和Ubuntu系统内核完全解耦。这个内核里集成了gpu-manager模块，负责把Windows侧的NVIDIA驱动API翻译成Linux侧的/dev/nvidia*设备节点。所以你永远不要在WSL2里apt install nvidia-driver-xxx——那是给物理机Ubuntu装的，装了反而冲突。WSL2的GPU驱动，只由Windows侧的NVIDIA驱动提供，且必须是465.42或更高版本（这是CUDA 11.0支持的最低驱动版本）。我试过460.89，nvidia-smi能显示，但cudaMalloc会段错误；换成471.11，一切正常。驱动版本不是越高越好，而是要和CUDA Toolkit版本严格匹配。

• 第三层：CUDA Toolkit 11.0.3（非11.0.0）
  标题里写的是CUDA11.0，但实际安装必须用11.0.3这个补丁版本。原因很简单：11.0.0发布于2020年7月，当时WSL2刚GA，NVIDIA还没适配；11.0.3发布于2020年10月，首次正式声明支持WSL2。很多教程抄来抄去写“CUDA 11.0”，结果读者装了11.0.0发现nvcc --version报错，其实是版本号没写全。CUDA 11.0.3自带libcudnn8=8.0.4.30-1+cuda11.0，这个cuDNN版本和PyTorch 1.7.1二进制包完全兼容，不用自己编译。如果你硬要上CUDA 11.2，会发现PyTorch官方wheel只提供11.1和11.3支持，中间断档，反而更麻烦。

• 最内层：Ubuntu 20.04 LTS + Python 3.8.10 + PyTorch 1.7.1 + TensorFlow 2.4.0
  为什么是Ubuntu 20.04？因为它是WSL2官方默认镜像，内核模块兼容性最好；为什么是Python 3.8.10？因为PyTorch 1.7.1官方wheel只打包了3.6–3.8，3.9要自己编译；TensorFlow 2.4.0是最后一个原生支持CUDA 11.0的版本（2.5开始要求11.2）。这里有个隐藏陷阱：pip install tensorflow默认装2.8，它会静默降级CUDA到11.2，然后和你的11.0冲突。必须指定pip install tensorflow==2.4.0。同理，PyTorch必须用pip install torch==1.7.1+cu110 torchvision==0.8.2+cu110 -f https://download.pytorch.org/whl/torch_stable.html，那个+cu110后缀不是装饰，是ABI标识符，漏了就会装CPU版。

提示：整个架构的核心约束是“版本链式锁定”。Windows版本 → WSL2内核 → NVIDIA驱动 → CUDA Toolkit → cuDNN → PyTorch/TensorFlow wheel。任意一环错位，轻则功能缺失（如torch.cuda.is_available()为False），重则系统级崩溃（如WSL2启动失败）。这不是Linux桌面环境，可以随便apt upgrade，这是精密咬合的工业级链条。

2.2 为什么坚决不用VMware/VirtualBox？三个血泪教训

有人问：“VMware Workstation也能装Ubuntu跑CUDA，为啥非折腾WSL2？” 我用三台机器实测对比过，结论很残酷：

• 资源开销：VMware开一个Ubuntu 20.04，即使关掉GUI，仅后台运行就要吃掉1.2GB内存+15% CPU常驻；WSL2空载仅380MB内存+0.3% CPU。这意味着你在Win10上同时开微信、Chrome（10个标签页）、VS Code（3个项目）、PyCharm（1个Django）、还有WSL2训练模型，内存还能剩4GB；换成VMware，直接爆红。

• GPU直通延迟：VMware的vGPU是模拟层，CUDA kernel launch延迟平均比物理机高47ms；WSL2是NVIDIA官方认证的“Direct GPU Access”，延迟仅比物理机高1.2ms。我跑过ResNet50单batch inference，VMware耗时237ms，WSL2耗时112ms，差距一倍。这对需要实时反馈的模型调试（比如强化学习策略网络）是致命的。

• 文件系统互通性：WSL2的/mnt/c/Users/xxx/是Windows NTFS的直接映射，读写速度≈本地SSD；VMware的Shared Folders是Samba协议，大文件（如10GB的ImageNet子集）拷贝速度只有12MB/s，而WSL2可达520MB/s。更关键的是，PyTorch的DataLoader多进程模式在VMware共享目录下会因文件锁机制崩溃，WSL2无此问题。

注意：这些不是理论值，是我用time dd if=/dev/zero of=/mnt/c/test bs=1G count=5和python -m timeit -s "import torch" "torch.cuda.FloatTensor(1000,1000).matmul(torch.cuda.FloatTensor(1000,1000))"实测出来的。如果你的项目涉及大量小文件IO或低延迟推理，WSL2是唯一可行方案。

2.3 为什么放弃CUDA 11.2/11.4？一个被忽略的ABI兼容性真相

网上很多教程鼓吹“装最新CUDA”，但在WSL2场景下，这是危险操作。根本原因在于CUDA Runtime ABI（Application Binary Interface）的向后兼容性是单向的，且WSL2的ABI实现有滞后性。

CUDA Toolkit的ABI规则是：

• libcudart.so.11.0（CUDA 11.0）能加载libcudnn8.so.8.0.x（cuDNN 8.0.x）
• libcudart.so.11.2（CUDA 11.2）能加载libcudnn8.so.8.2.x，但不能加载8.0.x
• WSL2内核的GPU模块，在2021年Q3才完整支持CUDA 11.2的ABI扩展指令（如cudaGraphInstantiate），此前版本调用会触发CUDA_ERROR_NOT_SUPPORTED

我曾为复现一篇论文，强行在WSL2里装CUDA 11.2 + cuDNN 8.2 + PyTorch 1.9.0，结果import torch就Segmentation Fault。gdb跟进去发现，是libtorch_cuda.so调用了一个WSL2内核尚未实现的CUDA Graph API。降级回CUDA 11.0.3后，问题消失。这不是PyTorch的bug，是WSL2平台本身的成熟度问题。

所以我的经验是：在WSL2上，CUDA版本宁低勿高。11.0.3是经过大规模验证的“黄金版本”，它平衡了新特性支持（如FP16 Tensor Core加速）和平台稳定性。后续版本升级，务必等NVIDIA官网文档明确写出“WSL2 Support: Yes”并标注测试过的驱动版本号，再动手。

3. 核心细节解析与实操要点：从驱动安装到环境变量，每一步都是坑

3.1 Windows侧准备：驱动、WSL2、内核，三者必须同步升级

第一步不是开WSL，而是确保Windows底层就绪。很多人跳过这步，后面全盘皆输。

① 升级NVIDIA驱动到471.11（或465.42以上）
去NVIDIA官网下载页面，不要点“自动检测”，那玩意儿经常推旧版。手动选择你的显卡型号 → “GeForce Game Ready Driver” → 找到471.11版本（发布日期2021年6月），下载exe安装包。安装时勾选“执行清洁安装”，这会清除所有旧驱动残留。安装完成后，必须重启Windows，否则WSL2无法识别GPU设备。

验证是否成功：

• Win+R输入cmd，执行nvidia-smi，看到GPU列表和驱动版本号（471.11）即成功
• 如果提示“NVIDIA-SMI has failed”，说明驱动没装好或没重启，重装

② 启用WSL2并安装内核更新
以管理员身份打开PowerShell（右键开始菜单→Windows PowerShell（管理员）），逐行执行：

# 启用WSL功能（需重启） dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启电脑 shutdown /r /t 0

重启后，再次以管理员身份打开PowerShell：

# 下载并安装WSL2内核更新包（微软官方链接，2021年10月版） curl -Lo wsl_update_x64.msi https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi start wsl_update_x64.msi # 安装完成后，设WSL2为默认版本 wsl --set-default-version 2

注意：wsl --set-default-version 2必须在安装完内核更新包后执行，否则会报错“WSL2 requires an update to its kernel component”。这个错误信息很误导人，其实缺的不是内核，是内核更新包。

③ 安装Ubuntu 20.04（从Microsoft Store）
打开Microsoft Store → 搜索“Ubuntu 20.04 LTS” → 点击“获取”。安装完成后，点击“启动”，会初始化一个Linux用户（用户名随意，密码要记住）。初始化完成后，执行：

# 更新包索引（国内用户先换源，见下文） sudo apt update && sudo apt upgrade -y # 验证WSL2版本 uname -r # 应输出类似 5.10.16.3-microsoft-standard-WSL2 # 验证GPU设备可见性 ls /dev/nvidia* # 应看到 /dev/nvidia0 /dev/nvidiactl /dev/nvidia-uvm

如果ls /dev/nvidia*报错“No such file or directory”，说明前面三步（驱动、内核、重启）有一步没到位，必须回头检查。

3.2 Ubuntu侧CUDA安装：绕过apt，用runfile精准控制

WSL2里绝对不要用apt install cuda！Ubuntu官方源的CUDA包是为物理机编译的，会试图安装nvidia-kernel-source，这在WSL2里会导致内核模块冲突，wsl --shutdown后无法再启动。

正确做法是用NVIDIA官方runfile安装，且只装Runtime和Toolkit，不装Driver：

# 下载CUDA 11.0.3 runfile（注意：必须是.run格式，不是.deb） # 官网链接：https://developer.nvidia.com/cuda-toolkit-archive （找11.0.3） # 或直接用wget（国内服务器可能慢，建议浏览器下载后用wsl --import导入） wget https://developer.download.nvidia.com/compute/cuda/11.0.3/local_installers/cuda_11.0.3_450.51.06_linux.run # 赋予执行权限 chmod +x cuda_11.0.3_450.51.06_linux.run # 运行安装程序，关键参数： # --silent：静默安装，不弹UI # --override：覆盖检查（WSL2会被检测为不支持，必须强制） # --no-opengl-libs：不装OpenGL库（WSL2无GUI，装了白占空间） # --toolkit：只装Toolkit，不装Driver（Driver已在Windows侧装好） sudo ./cuda_11.0.3_450.51.06_linux.run --silent --override --no-opengl-libs --toolkit # 验证安装 /usr/local/cuda-11.0/bin/nvcc --version # 应输出 release 11.0, V11.0.194

实操心得：runfile安装过程会输出一堆日志，最后一行如果是Installation successful!才算成功。如果中途卡住或报错，立刻Ctrl+C终止，然后sudo /usr/local/cuda-11.0/bin/uninstall_cuda_11.0.pl卸载干净，再重试。我第一次装时因磁盘空间不足失败，卸载后清理了/tmp才成功。

3.3 环境变量配置：PATH、LD_LIBRARY_PATH、CUDA_HOME，一个都不能少

CUDA装完只是开始，环境变量配错，nvcc能用但torch认不出GPU。必须在~/.bashrc里精确设置：

# 编辑.bashrc nano ~/.bashrc # 在文件末尾添加以下四行（注意路径和版本号） export CUDA_HOME=/usr/local/cuda-11.0 export PATH=$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH export CUDA_VISIBLE_DEVICES=0 # 强制使用第一块GPU，避免多卡识别混乱 # 生效配置 source ~/.bashrc

验证是否生效：

echo $CUDA_HOME # 应输出 /usr/local/cuda-11.0 echo $PATH | grep cuda # 应包含 /usr/local/cuda-11.0/bin ldconfig -p | grep cuda # 应列出 libcudart.so.11.0 等库

关键细节：LD_LIBRARY_PATH必须包含$CUDA_HOME/lib64，因为CUDA 11.0的动态库全在lib64目录下（不是lib）。很多教程写$CUDA_HOME/lib，结果import torch时报libcurand.so.10: cannot open shared object file。另外，CUDA_VISIBLE_DEVICES=0不是可选的——WSL2目前不支持自动枚举多GPU，不设这个变量，PyTorch会认为没有可用GPU。

3.4 cuDNN安装：用deb包而非tarball，避免符号链接灾难

cuDNN必须用NVIDIA官网下载的.deb包安装，不能用.tar解压。原因：.deb包会自动创建正确的符号链接（如libcudnn.so → libcudnn.so.8.0.4），而.tar包需要手动建链接，稍有不慎就会导致PyTorch找不到库。

步骤：

# 下载cuDNN v8.0.4 for CUDA 11.0（需注册NVIDIA开发者账号） # 文件名类似 cudnn-11.0-linux-x64-v8.0.4.30.tgz # 解压后得到deb包（cudnn-local-repo-ubuntu2004-8.0.4.30_1.0-1_amd64.deb） sudo dpkg -i cudnn-local-repo-ubuntu2004-8.0.4.30_1.0-1_amd64.deb sudo apt update sudo apt install libcudnn8=8.0.4.30-1+cuda11.0 -y # 验证 cat /usr/include/cudnn.h | grep CUDNN_MAJOR -A 2 # 应输出 #define CUDNN_MAJOR 8

注意：apt install时必须指定完整版本号libcudnn8=8.0.4.30-1+cuda11.0，否则apt会装最新版（如8.2.x），和CUDA 11.0不兼容。这个版本号必须和deb包名里的完全一致。

4. 实操过程与核心环节实现：从零开始，完整走一遍训练流程

4.1 Python环境搭建：Miniconda优于系统Python，隔离才是王道

Ubuntu 20.04自带Python 3.8.5，但直接用它装PyTorch会有风险：系统包依赖可能被破坏，且无法轻松切换Python版本。我推荐Miniconda，轻量、隔离、可控。

# 下载Miniconda3（Linux x86_64） wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda3 $HOME/miniconda3/bin/conda init bash # 重启终端或执行 source ~/.bashrc conda --version # 应输出 4.10.x

创建专用环境：

# 创建名为ai-env的环境，指定Python 3.8.10（PyTorch 1.7.1要求） conda create -n ai-env python=3.8.10 conda activate ai-env # 升级pip到最新（避免wheel安装失败） pip install --upgrade pip # 安装PyTorch 1.7.1 + CUDA 11.0支持 pip install torch==1.7.1+cu110 torchvision==0.8.2+cu110 -f https://download.pytorch.org/whl/torch_stable.html # 安装TensorFlow 2.4.0（注意：必须用pip，conda-forge的tf2.4不支持WSL2） pip install tensorflow==2.4.0 # 验证GPU可用性 python -c "import torch; print(torch.cuda.is_available())" # 应输出 True python -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))" # 应输出 [PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]

实操心得：-f https://download.pytorch.org/whl/torch_stable.html这个index-url参数绝不能省。不加的话，pip会从PyPI主站下载，而主站的torch-1.7.1-cp38-cp38-manylinux1_x86_64.whl是CPU版。那个+cu110后缀是PyTorch wheel的ABI标识，pip show torch能看到Name: torchVersion: 1.7.1+cu110，如果显示1.7.1没后缀，说明装错了。

4.2 数据与代码准备：利用/mnt/c实现Windows-WSL2无缝协作

这才是WSL2的最大优势——你不用在Linux里重新下载数据集。假设你的数据在Windows的D:\datasets\cifar10，在WSL2里路径是/mnt/d/datasets/cifar10。

# 创建项目目录（在/mnt/c下，方便Windows访问） mkdir -p /mnt/c/projects/pytorch-cifar10 cd /mnt/c/projects/pytorch-cifar10 # 写一个极简训练脚本（train.py） cat > train.py << 'EOF' import torch import torch.nn as nn import torch.optim as optim import torchvision import torchvision.transforms as transforms # 检查GPU device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu") print(f"Using device: {device}") # 加载CIFAR10（自动下载到/mnt/c/projects/pytorch-cifar10/data） transform = transforms.Compose([transforms.ToTensor()]) trainset = torchvision.datasets.CIFAR10(root='./data', train=True, download=True, transform=transform) trainloader = torch.utils.data.DataLoader(trainset, batch_size=128, shuffle=True, num_workers=2) # 构建简单CNN net = nn.Sequential( nn.Conv2d(3, 32, 3), nn.ReLU(), nn.MaxPool2d(2), nn.Flatten(), nn.Linear(32*15*15, 10) ).to(device) criterion = nn.CrossEntropyLoss() optimizer = optim.SGD(net.parameters(), lr=0.001) # 训练循环 for epoch in range(2): running_loss = 0.0 for i, data in enumerate(trainloader, 0): inputs, labels = data[0].to(device), data[1].to(device) optimizer.zero_grad() outputs = net(inputs) loss = criterion(outputs, labels) loss.backward() optimizer.step() running_loss += loss.item() if i % 100 == 99: print(f'Epoch {epoch+1}, Batch {i+1}: Loss {running_loss/100:.3f}') running_loss = 0.0 print('Finished Training') EOF

关键技巧：root='./data'路径是相对路径，数据会下载到当前目录下的./data，而当前目录/mnt/c/projects/pytorch-cifar10在Windows里就是C:\projects\pytorch-cifar10，你可以直接用Windows资源管理器打开查看文件。这样，数据预处理脚本用Windows的Python写，模型训练用WSL2的PyTorch跑，完全无缝。

4.3 启动训练并监控：用nvidia-smi和htop看透资源消耗

现在执行训练：

# 激活环境 conda activate ai-env # 启动训练（后台运行，方便开另一个终端监控） nohup python train.py > train.log 2>&1 & # 查看GPU占用（在另一个终端） watch -n 1 nvidia-smi

你会看到nvidia-smi里python进程占着GPU显存（约1.2GB），Volatile GPU-Util稳定在85%左右。同时开第三个终端：

# 监控CPU和内存 htop

可以看到python进程占满4个CPU核心（DataLoader的num_workers=2），内存占用约3.2GB。这一切都发生在Windows后台，你的Chrome、微信、VS Code照常运行。

训练完成后，查看日志：

tail -20 train.log # 应看到类似： # Epoch 1, Batch 100: Loss 1.234 # Epoch 1, Batch 200: Loss 0.987 # ... # Finished Training

实测数据：在RTX 3060上，CIFAR10单epoch训练时间约4分30秒（128 batch size），比纯CPU快17倍。这个速度已经足够支撑日常模型迭代。

5. 常见问题与排查技巧实录：那些让我凌晨三点还在debug的坑

5.1 经典问题速查表

5.2 一个隐藏极深的坑：Windows防火墙导致WSL2网络异常

有次我配置好一切，nvidia-smi和torch.cuda都正常，但pip install总是超时。ping pypi.org能通，curl -I https://pypi.org却卡住。最后发现是Windows防火墙的“Core Networking”规则组里，有一条“WSL2 Network Isolation”默认启用，它会阻止WSL2访问外部HTTPS。解决方案：

• Win+R输入wf.msc打开高级安全防火墙
• 左侧点“入站规则”，右侧点“启用或禁用规则”
• 找到“Core Networking Diagnostics (TCP-In)”和“Core Networking Diagnostics (UDP-In)”，右键“禁用”
• 重启WSL2：wsl --shutdown，再打开

这个问题不会报错，只会让网络请求无限等待，非常难定位。如果你的环境其他都正常，唯独pip/pip3无法联网，优先检查这个。

5.3 性能优化技巧：让GPU利用率从70%提到95%

默认配置下，DataLoader的num_workers设太高会因WSL2的进程调度延迟导致GPU空闲。我测试过：

• num_workers=0：GPU利用率65%，CPU占用30%
• num_workers=2：GPU利用率88%，CPU占用75%
• num_workers=4：GPU利用率反降至72%，因进程竞争导致数据供给延迟

最优解是num_workers=2+pin_memory=True：

trainloader = torch.utils.data.DataLoader( trainset, batch_size=128, shuffle=True, num_workers=2, pin_memory=True # 将tensor锁在GPU内存页，加速传输 )

另外，PyTorch 1.7.1默认不启用CUDA Graph，手动开启能再提5%利用率：

# 在训练循环前加 torch.backends.cudnn.benchmark = True # 自动寻找最优卷积算法 torch.backends.cudnn.enabled = True # 启用cuDNN

5.4 备份与迁移：如何把整个环境打包带走

WSL2环境最怕重装系统。备份只需两步：

① 导出WSL2发行版为tar包（含所有配置、环境、数据）

# 在PowerShell中执行（非WSL2终端！） wsl --export Ubuntu-20.04 C:\wsl-backup\ubuntu2004-backup.tar

② 迁移后导入（新机器上）

# 新机器上先安装WSL2内核更新包，再导入 wsl --import Ubuntu-20.04 C:\wsl\ubuntu2004 C:\wsl-backup\ubuntu2004-backup.tar --version 2 # 设为默认 wsl --set-default Ubuntu-20.04

导入后，你的/mnt/c/projects、conda环境、CUDA配置全部原样恢复，连conda activate ai-env都不用重新做。

最后分享一个小技巧：我在/mnt/c下建了个scripts文件夹，里面放常用命令的bat脚本，比如start-wsl-gpu.bat内容是：

@echo off wsl -d Ubuntu-20.04 -u root -e bash -c "source /home/youruser/.bashrc && conda activate ai-env && cd /mnt/c/projects && exec bash"

双击这个bat，就直接进入配置好的AI环境，连终端都不用手动开。这才是生产力。