企业官网建设流程全解析

先说一个可能和主流认知不太一样的结论：用 Windows 做 AI 编程，未必比 Linux 差，甚至在某些业务场景下更顺手。我见过太多朋友一开始就直奔双系统或纯 Linux，结果折腾显卡驱动、桌面环境、输入法，小半个月过去了还没开始写代码，最后又默默回到了 Windows。这篇不是什么官方文档的翻译，而是我这些年一直在 Windows 上搭 AI 开发环境、踩了不少坑之后，整理出来的一套可以照着抄的搭建清单。内容包括系统级准备、Python 多版本管理、Docker 容器环境、本地中间件、模型推理服务，以及 Codex 这类 AI 编程助手的接入，完整覆盖“从零到能跑 AI 项目”的全流程。

适合谁看？一是刚接触 AI 编程、想在 Windows 上把 Python、Docker、本地模型跑起来的新人；二是已经有一定经验、但每次换电脑都要重新配环境的开发者。照着这篇做一遍，你手上这台 Windows 机器就能变成一套规范的 AI 工作台。

1. 动手之前先想明白：你的 AI 工作流到底需要哪些组件

1.1 先给“AI 编程环境”做一个需求拆解

很多人一上来就装一堆软件，结果发现一半用不上。我建议先想清楚，你所谓的“AI 编程环境”是做哪一类事情。我大致分成三种：

• AI 应用开发：调用大模型 API 或本地模型接口，写业务逻辑、做 Prompt 编排、开发 RAG 应用。这类工作主要需要 Python、Node.js、HTTP 调试工具，以及一个顺手的代码编辑器。
• 模型微调与训练：需要 Python、CUDA 驱动、PyTorch/TensorFlow，以及足够的显存。Windows 下也能做小规模微调，但大规模训练仍然建议 Linux 服务器。
• 模型本地推理与测试：用 Ollama、LM Studio、vLLM（Windows 支持有限）等工具把开源模型跑在本机，验证效果或做私有化部署。这类工作最看重的是内存、显存和磁盘速度。

你的需求决定了环境复杂度。如果只是写代码调 API，那 Python 3.12 + Docker 基本就够了；如果还要本地跑模型，那 CUDA、Ollama、大内存都得安排上。我下面会按“较完整”的配置来讲，你可以按需裁剪。

1.2 分清楚“系统级环境”和“项目级环境”

这是我在团队里反复强调的一个原则：系统级环境要克制，项目级环境要独立。

系统级环境指的是 Python、Node.js、JDK、Docker 这类基础运行时，能装一个版本就装一个，不要今天升级明天回滚。项目级环境则是每个项目自己的依赖，比如某个项目要用 TensorFlow 2.15、另一个要用 PyTorch 2.5，这些必须在虚拟环境里隔离，绝对不能直接装在系统里。这个原则在 Windows 上尤其重要，因为 Windows 没有 Linux 那么宽松的依赖管理机制，装乱了清理起来非常痛苦。

1.3 硬件与系统版本的底线

先给一个参考配置标准（实测跑中小型模型和常规开发够用）：

硬盘和内存这两项，直接决定你本地跑模型的时候会不会卡死。能上 32GB 内存就上，现在很多本地模型加载后就要占掉 8-12GB，再叠加 IDE 和浏览器，16GB 会很吃紧。硬盘建议留出至少 100GB 给 Docker 镜像、模型文件和数据。

2. Windows 系统底座整理：终端、Git、包管理器与 WSL2 的取舍

2.1 Windows Terminal：现代终端是编程体验的第一步

很多在 Windows 上写代码觉得不舒服的朋友，问题往往出在终端还是老旧的 conhost。我强烈建议第一步就安装 Windows Terminal，它支持多标签页、自定义配色、快捷键，还集成了 PowerShell、CMD、WSL 等多个终端会话。

安装方式很简单，在 Microsoft Store 搜索“Windows Terminal”直接安装，或者用 winget 命令：

winget install Microsoft.WindowsTerminal

然后把默认终端设为 Windows Terminal，默认配置文件设为 PowerShell 7。PowerShell 7 是跨平台的新版，比自带的 Windows PowerShell 5.1 快很多，而且很多命令行为更接近 Linux shell。安装 PowerShell 7 同样用 winget：

winget install Microsoft.PowerShell

安装完成后，把终端字体设置为 MesloLGM Nerd Font 或 Cascadia Code，显示中文和特殊符号更舒服。这一步虽然不起眼，但每天要敲几百条命令，体验差距非常大。

2.2 Git 安装与全局配置

AI 项目大多用 Git 做版本管理，Windows 下安装 Git 推荐用官方安装包或 winget：

winget install Git.Git

安装时注意几个关键选项：建议选择“Checkout as-is, commit Unix-style line endings”，也就是签出时保持原样、提交时统一换行符为 LF，这能避免和 Linux 环境产生换行符冲突。另外建议勾选“Enable symbolic links”，虽然默认关闭更安全，但很多 AI 项目会用到符号链接，开启后能少踩很多坑。

装完后的全局配置我一般这样做：

git config --global user.name "你的名字" git config --global user.email "你的邮箱" git config --global init.defaultBranch main git config --global core.autocrlf false git config --global core.quotepath false

core.quotepath false特别重要，否则中文文件名会被转义成八进制编码，看着非常难受。

2.3 包管理器：winget 和 scoop 怎么选

Windows 下有两个很常用的包管理器，我建议两个都装，但分工不同。

winget 是微软官方出品，适合安装图形化软件，比如 Docker Desktop、VS Code、浏览器这类，命令简单，覆盖面广。scoop 则适合装命令行工具和开发库，它有一个最大的优点：安装的软件都在用户目录下，不需要管理员权限，也不会污染系统 PATH。对于经常要装一些编译工具、小工具的场景，scoop 非常好用。

scoop 的安装：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser irm get.scoop.sh | iex

装完以后可以用 scoop 安装很多开发小工具：

scoop install curl wget unzip 7zip jq python nodejs

不过注意，scoop 里的 python 是它自己维护的版本，如果你要用 pyenv-win 管理 Python 多版本，最好别用 scoop 装 python，避免冲突。

2.4 WSL2 到底要不要启用，我给你一个判断标准

WSL2 是微软的 Windows 子系统，相当于在 Windows 里跑一个轻量级 Linux 虚拟机。很多人聊 Windows 开发必谈 WSL2，但我的建议是：能不用就不用，用到的时候再用。

判断标准很简单：

• 如果你的 AI 项目以 Python 为主，依赖都能通过 pip 安装，docker 也能用 Windows 版，那就完全不需要 WSL2，直接用 Windows 原生环境反而更流畅，文件读写性能也更好。
• 如果你的项目里有 Linux-only 的依赖，比如某些只在 Linux 下编译的 C/C++ 库、需要使用 systemd 的服务，或者你要用 Docker Desktop 的 Linux 容器后端（这个场景通常建议开启），那就可以启用 WSL2。

启用 WSL2 只需要在管理员 PowerShell 执行：

wsl --install

然后重启，系统会自动装好 WSL2 和默认的 Ubuntu。我个人现在主要用 WSL2 跑 Docker 后端和 Linux 环境调试，日常 Python 开发仍然在 Windows 原生环境。两者可以共存，不冲突。

2.5 顺手检查 Windows 安全日志与防护状态

搭建环境之前，建议先看一眼系统是否健康。在“事件查看器”里展开“Windows 日志 -> 安全”，可以查看最近的登录成功/失败记录。这个步骤和生产环境服务器排查异常登录是一个套路，Windows 桌面机同样适用。另外确认 Windows Defender 处于开启状态，别在装开发工具时顺手把它关了，后续安装破解工具或不明软件时中招的风险会大幅上升。

3. AI 核心语言环境：Python 多版本管理、Node.js 与 JDK

3.1 pyenv-win：用 Windows 也能优雅管理多个 Python 版本

Python 是 AI 生态的第一语言，这一节非常关键。Windows 下最头疼的问题就是 Python 版本管理：装了 3.11，某个项目要 3.9，另一个项目要 3.13，直接用官网安装包去覆盖版本，很容易把系统搞乱。我推荐用 pyenv-win 来做多版本管理，和 Linux 下的 pyenv 用法几乎一致。

pyenv-win 的安装：

git clone https://github.com/pyenv-win/pyenv-win.git $HOME\.pyenv

然后把$HOME\.pyenv\bin和$HOME\.pyenv\shims加入 PATH。或者直接用 scoop：

scoop install pyenv-win

接下来常用命令：

pyenv install --list pyenv install 3.12.8 pyenv install 3.11.9 pyenv global 3.12.8 pyenv local 3.12.8

pyenv local会在当前目录生成一个.python-version文件，指定这个项目用哪个 Python 版本。切换目录后自动切到对应版本，团队协作时也会读这个文件，非常实用。

有一个坑需要提醒：pyenv-win 安装 Python 时可能会因为网络或权限问题失败，如果下载慢，可以先把 Python 安装包手动下载到~/.pyenv/installer目录，文件名按python-3.12.8-amd64.exe规则命名，再执行pyenv install 3.12.8，这样能避开下载超时的问题。

3.2 虚拟环境与依赖管理：venv、uv、poetry 的选择

Python 装好之后，虚拟环境是必须的。我推荐的工具优先级是这样的：

• 日常用 venv：Python 自带的python -m venv .venv，简单可靠，没有额外依赖。
• 追求速度和现代体验用 uv：uv是 Rust 写的包管理器，安装依赖速度极快，还能直接管理 Python 版本。安装方式：pip install uv或winget install astral-sh.uv。
• 项目管理用 poetry：它能把依赖声明、锁定、打包都统一管理，适合发布到 PyPI 的库项目。但对绝大多数 AI 应用项目来说，poetry 的复杂配置反而会增加成本。

我的建议是：AI 项目直接用 uv 或 venv。uv 的使用非常直观：

uv venv .venv .\.venv\Scripts\activate uv pip install numpy pandas torch

它会自动解析依赖并生成锁定文件，既快又不容易出现依赖地狱。相比 pip，uv 在安装大型依赖（如 PyTorch）时速度提升非常明显，我实测能快两到三倍。

3.3 Node.js 环境：nvm-windows 管理多个版本

AI 应用开发往往离不开前端展示，或者要写 API 中间层，Node.js 几乎是标配。Windows 下管理 Node.js 多版本，最常用的是 nvm-windows。注意这个工具和 Linux 的 nvm 不是同一个项目，但用法类似。

安装方式（Release 页下载 nvm-setup.exe）或：

winget install CoreyButler.NVMforWindows

常用命令：

nvm install 22.13.0 nvm use 22.13.0 node -v npm -v

nvm-windows 默认会把 npm 包安装到%APPDATA%\npm目录，要注意这个路径要在 PATH 中。不然全局安装的命令（比如后面的 codex）会提示找不到，这是非常常见的坑。

3.4 JDK：Spring AI 生态的基础运行时

如果你要开发基于 Spring AI 的 Java 项目，JDK 17 是最稳妥的选择，因为 Spring Boot 3.x 和 Spring AI 官方都要求 JDK 17 以上。Windows 下安装 JDK 我用的是 Adoptium Temurin 发行版，也可以直接用 winget：

winget install EclipseAdoptium.Temurin.17.JDK

安装后验证版本：

java -version

然后配置环境变量。现在的 JDK 安装器一般会自动配置JAVA_HOME，如果没有，手动加系统环境变量JAVA_HOME=C:\Program Files\Eclipse Adoptium\jdk-17.0.x.x，并把%JAVA_HOME%\bin加到 PATH。

另外，如果你本地要用 Elasticsearch 8.x，它自带 JDK，不需要额外设置。但如果用了 ES 7.x 或一些旧工具链，就需要确认它们和 JDK 版本兼容，别一股脑装最新版。

3.5 补充：Windows 下 C/C++ 编译环境

AI 项目中经常有 Python 包需要编译 C 扩展，比如pip install某些依赖时如果找不到现成 wheel，就会走源码编译。Windows 下我建议安装Visual Studio Build Tools，而不是完整版 Visual Studio。安装时勾选“使用 C++ 的桌面开发”工作负载，这样 cl.exe、链接器这些就都齐了。另一种选择是 MSYS2，对 UNIX 风格命令更友好，但配置复杂一些。对绝大多数 AI 项目来说，Build Tools 足够，也更容易和 pip 配合。

4. Docker Desktop：给 AI 环境建一条可复现的装配线

4.1 安装 Docker Desktop 并选对后端

Docker 是 AI 开发环境里最有价值的一环。它可以把 Redis、PostgreSQL、向量数据库、模型推理服务全部打包成容器，一条命令启动，换机器也不怕环境丢。Windows 下安装 Docker 基本只有一个主流选择：Docker Desktop。

安装命令：

winget install Docker.DockerDesktop

装完第一次启动，会提示选择后端。如果你已经启用了 WSL2，建议选择“Use WSL 2 based engine”，这样容器跑在 WSL2 的轻量虚拟机里，性能和 Linux 环境基本一致。如果没有启用 WSL2，也可以选 Windows Hyper-V 后端，但我个人更推荐 WSL2，原因有两个：一是资源占用更小，二是能和 WSL 里的 Linux 工具链共享一套 Docker 上下文，开发调试链路更短。

4.2 镜像加速源配置

在国内环境下拉取 Docker Hub 镜像经常很慢。Docker Desktop 提供了配置镜像源的地方，在 Settings -> Docker Engine 里编辑 JSON：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://docker.mirrors.ustc.edu.cn" ] }

这里列出的是我实测可用的几个公共镜像加速地址，你可以按自己的网络情况调整。配置完成后点击“Apply & Restart”，再拉镜像试试速度，通常会有明显改善。这一个步骤能帮你省下一大把时间，千万别跳过。

4.3 组建一套标准 AI 中间件容器

搭建好 Docker 之后，我用它来管理 AI 开发常用的中间件。下面是一个参考的 docker-compose.yml，直接保存到你的项目目录里就能用：

services: redis: image: redis:7.2-alpine container_name: ai-redis ports: - "6379:6379" volumes: - redis-data:/data command: ["redis-server", "--appendonly", "yes"] postgres: image: pgvector/pgvector:pg16 container_name: ai-postgres environment: POSTGRES_USER: ai_dev POSTGRES_PASSWORD: ai_dev_password POSTGRES_DB: ai_platform ports: - "5432:5432" volumes: - postgres-data:/var/lib/postgresql/data elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.14.0 container_name: ai-es environment: - discovery.type=single-node - xpack.security.enabled=false - ES_JAVA_OPTS=-Xms2g -Xmx2g ports: - "9200:9200" volumes: - es-data:/usr/share/elasticsearch/data volumes: redis-data: postgres-data: es-data:

启动命令：

docker compose up -d

这条命令会同时启动 Redis、带 pgvector 插件的 PostgreSQL、Elasticsearch 三个服务，覆盖了大多数 AI 应用所需的缓存、存储和检索能力。pgvector 插件能让 PostgreSQL 当作向量数据库用，RAG 项目里非常常见。

一个实操经验：生产环境不要用latest标签，示例里我写了具体版本号，这样下次docker compose pull时不会因为大版本升级导致不兼容。

5. 本地 AI 服务与中间件：Redis、Elasticsearch 和模型推理

5.1 Redis 在 Windows 下的正路与岔路

Redis 官方其实不提供 Windows 原生版本，网上能搜到的“Redis for Windows”基本是第三方移植版（比如 tporadowski/redis），版本普遍偏老。我的建议是：开发环境直接用 Docker 跑 Redis，最省事，而且和 Linux 生产环境行为一致。

如果你因为某些原因不能装 Docker，那再考虑 Memurai。它是一个 Redis 兼容的开源 Windows 服务实现，支持 Redis 7 的大部分命令，API 兼容性不错，可以注册成 Windows 服务开机自启。我实测过用它跑一些小规模缓存场景，问题不大，但如果要用 Lua 脚本或模块，建议还是老老实实回 Docker。

验证 Redis 是否正常：

docker exec -it ai-redis redis-cli ping

如果返回PONG，说明服务正常。Windows 下访问 Redis 也可以直接用代码里的 redis-py 或 Spring Data Redis，只要localhost:6379能通就行。

5.2 Elasticsearch 的启动与踩坑点

搜索和向量检索是 AI 应用的重要基础，Elasticsearch 在 Windows 下可以直接跑原生版本。先确认 JDK 环境，然后去官网下载 Windows zip 包，解压后进入bin目录执行：

elasticsearch.bat

8.x 版本默认绑定了 JDK 并开启了 HTTPS 和安全认证，开发环境建议先关掉这些配置，减少折腾。修改config/elasticsearch.yml：

xpack.security.enabled: false discovery.type: single-node

启动后浏览器访问http://localhost:9200，返回cluster_name等信息就说明成功了。这里最典型的坑有三个：

• 端口被占用：如果 9200 被别的程序占用，ES 会启动失败。用netstat -ano | findstr 9200查一下占用进程。
• 内存分配过大：默认jvm.options会把堆内存设成物理内存的一半，16GB 内存的机器可能直接分配 8GB，导致启动缓慢甚至 OOM。建议手动改成-Xms2g -Xmx2g。
• 路径不能有中文或空格：ES 对数据目录的路径很敏感，解压到带中文的路径可能会导致某些插件异常。建议解压到纯英文路径。

5.3 本地模型推理：Ollama 与 OpenAI 兼容接口

本地跑开源模型是很多 AI 开发者的刚需。我目前最常用的工具是 Ollama，它支持 Windows，安装包在官网下载即可。装好之后拉取模型：

ollama pull qwen2.5:14b ollama run qwen2.5:14b

Ollama 会自动下载模型并启动一个本地服务，默认端口是11434。它支持 OpenAI 兼容的 API 接口，也就是说你代码里本来调 OpenAI SDK 的地方，只需要改一下base_url：

from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") response = client.chat.completions.create( model="qwen2.5:14b", messages=[{"role": "user", "content": "你好，介绍一下你自己"}] ) print(response.choices[0].message.content)

这个兼容层非常香，意味着本地环境和云端 API 可以在代码层面无缝切换。我通常的做法：开发调试用 Ollama 本地模型，上线切回云端 API，只改一个环境变量。如果你要跑更大参数的模型，还需要给 Ollama 设置OLLAMA_MODELS环境变量，把模型默认存储路径放到一个大分区，避免 C 盘被塞满。

6. 接入 AI 编程辅助工具链：Codex 桌面版与提示词工作流

6.1 Codex 的命令行与桌面端安装

AI 编程助手现在已经成了日常开发的一部分。以 OpenAI 的 Codex 为例，它提供了命令行工具（CLI）和新版桌面应用，Windows 下安装有两种方式。

第一种是 CLI 方式，要求本机已经装好 Node.js 18+，然后全局安装：

npm install -g @openai/codex

安装完以后执行：

codex --version

第一次运行会让你登录账号完成认证，之后在项目目录里启动：

codex

它会读取当前项目的上下文，回答你的问题，或者直接帮忙写代码、改代码。如果需要把对话和一些指令直接通过命令执行，可以:

codex exec "帮我给这个项目增加一个 health 检查接口"

第二种是桌面版，适合不熟悉命令行的用户。安装后登录同一个账号，在图形界面里选择本地项目目录，Codex 会直接读取项目文件结构、定位关键文件，然后进行修改。桌面版的可视化 diff 体验很直观，我一般先用 CLI 做批量操作，用桌面版做代码审查和局部修改。

6.2 AI 编程提示词模板：我沉淀下来的三段式框架

工具装好只是第一步，真正拉开效率差距的是提示词的组织。我平时写 AI 编程提示词，基本遵循一个“上下文-任务-约束”的三段式框架。

上下文部分告诉 AI 这个项目的技术栈和背景，例如：

这是一个基于 FastAPI 的 RAG 服务，Python 3.12，使用 PostgreSQL + pgvector，项目结构遵循 src 目录布局。

任务部分要非常具体，最好能给出输入输出样例：

请实现一个 /search 接口，接收 query 参数，先在 pgvector 里做向量检索，取 top 5 结果，然后用 LLM 生成摘要返回。返回格式为 {"results": [{content, score}]}

约束部分说明边界，比如：

使用 async/await 风格，不要引入新的第三方依赖，所有新增依赖必须说明理由。代码放在 src/api/routes/search.py 下。

这套模板比直接丢一句“帮我写个接口”有效得多。AI 编程助手本质上还是一个概率模型，你给它越清晰的上下文，它产出越可靠，这个经验适用于任何 AI 编程工具。

6.3 其他值得装的 Windows AI 插件

VS Code 里我目前必装的三类插件：官方 Python 扩展（Python、Pylance），Docker 扩展，以及 GitLens（查看代码历史和责任人）。这三件套对应了 AI 项目的三个关键场景：改 Python 代码、管理容器、查历史变更。另外，如果你的项目用 Jupyter Notebook 做实验，建议给 VS Code 装 Jupyter 插件，直接在 IDE 里跑 cell 调试模型，比开浏览器顺畅很多。

我很推荐把 VS Code 的“设置同步”打开，用 GitHub 账号同步配置和插件列表，换机器时一条命令复现开发环境。这其实也是“AI 编程环境”的一部分——你的工具链越一致，AI 辅助工具的上下文越稳定。

7. 全链路验证与 Windows 特有坑位的排查记录

7.1 一张自检清单，快速判断环境是否搭好

环境搭建完成后，我习惯按下面这张清单跑一遍，每个命令能返回预期结果，才说明这步真的没有问题：

建议把这份清单存在笔记里，每次换电脑或重装系统后照跑一遍。排查问题时也能快速定位是哪个环节断了。

7.2 Windows 下三个高频“坑位”及完整排查思路

坑位一：命令执行后提示“不是内部或外部命令”

这个报错几乎每个 Windows 开发者都遇到。根本原因是命令所在目录没有加入 PATH。我通常按三步排查：先确认软件确实装上了（比如C:\Program Files\xxx\bin\xxx.exe存在），再检查 PATH 环境变量里有没有对应路径，最后新开一个终端窗口重新执行。特别提醒：修改系统环境变量后，已经打开的终端窗口不会自动刷新，必须新开。

坑位二：Python 包安装失败，报错信息指向 MSVC

前面提到要装 Visual Studio Build Tools，就是为了解决这类问题。当你在 Windows 上pip install一个没有预编译 wheel 的包时，pip 会尝试调用 MSVC 编译源码，没有编译环境就会报Microsoft Visual C++ 14.0 or greater is required。解决办法：打开 “Visual Studio Installer”，勾选 “使用 C++ 的桌面开发”，等安装完成后重启终端再试。如果还不行，检查是否缺少对应的 Python 调试库，可以在 pyenv-win 安装 Python 时勾选“Download debugging symbols”等选项。

坑位三：本地模型推理时 GPU 显存不足或 OOM

跑本地模型最恼火的是刚开始加载模型就把显存吃满，然后直接闪退。我的排查思路是这样：先用nvidia-smi看空闲显存量，再算模型体积。比较靠谱的经验是 7B 参数模型量化后大约需要 5-7GB 显存，14B 量化模型大约需要 10GB 以上。如果显存不够，优先选择更小的量化版本（比如 q4_K_M），或者退回到 CPU 推理，只是速度慢一些。Ollama 也支持通过OLLAMA_GPU_LAYERS控制多少层放到 GPU 上计算，这个参数可以按显存大小灵活调整。

7.3 一次真实的环境排障过程

上周我在一台新的 Windows 电脑上复现这套环境时，代码执行到 Elasticsearch 启动就一直失败。日志显示内存分配错误。我先确认了机器是 16GB 内存，而默认 jvm.options 会分配物理内存一半也就是 8GB，再叠加 Docker 和 Ollama 吃内存，系统直接卡死。

排查链路是：先看 ES 日志文件logs/elasticsearch.log，发现unable to create native threads和内存分配异常，再打开jvm.options看到-Xmx8g，最后改成-Xmx2g，重启后恢复正常。这一步只用了五分钟，但如果一开始不去看日志，而是反复重启 ES，大概率会浪费两三个小时。遇到任何服务启动失败，第一件事永远是打开它的日志文件，而不是瞎试。

还有一个不起眼但容易坑人的点：ES 解压到带“中文”或“空格”的路径后，某些数据文件相关插件可能报路径错误，我习惯把所有开发工具统一放在C:\dev\这种纯英文目录下，比如C:\dev\elasticsearch-8.14.0。这套路径规划看似小细节，却能避免很多莫名的坑。建议从第一天就养成这个习惯。

写在最后的一点体会

整套环境搭下来，最大的感受是：Windows 做 AI 开发，不缺能力，缺的是规范。Linux 生态之所以让人感觉“专业”，是因为大家习惯了用命令行和配置文件管理一切；Windows 只要把终端、包管理器、虚拟环境、WSL2/Docker 这几层理顺，开发体验完全不输。我个人现在的固定配置就是 Windows 11 + Windows Terminal + PowerShell 7 + pyenv-win/uv + Docker Desktop + Ollama + Codex，日常写 AI 应用和本地调试模型都在这一套里面完成。你第一次搭可能会花一天，但第二台机器照着这份清单来，基本一个小时内就能进入状态。最后再分享一个小习惯：把所有个性化的配置文件和 docker-compose 文件纳入一个 Git 仓库，换环境时直接git pull就能找回所有开发环境设置，这才是环境复用最有价值的一步。