企业官网建设流程全解析

说实话，这几年陆陆续续帮朋友和自己配了不下十次 Windows 开发环境，感触最深的是：AI 编程工具再好用，底座环境没搭好，体验照样稀碎。很多人不是不想用 AI 辅助写代码，而是卡在了第一步——在 Windows 上不知道从哪开始，装完 Python 又发现没有 Git，配好 Git 又发现 Docker 起不来，等把环境磨好了，热情也磨没了。

这篇指南就是把我自己实际验证过的 Windows AI 编程环境搭建流程完整写出来，覆盖编码助手、AI 应用开发、中间件运行三类需求。目标读者是刚接触 AI 编程的初学者，以及需要在 Windows 上同时跑 Python、Docker、Redis、Elasticsearch，还想接上 Codex、AI 插件这类智能工具的开发者。不论你是写 Python、Java 还是前端，这套底座都通用。内容按我实际动手的顺序展开：先讲整体方案，再装终端和系统组件，接着是 Python、JDK、Redis、Elasticsearch，然后是 Docker，最后把 Codex 和 VS Code 的 AI 插件配好，结尾附上我真实踩过的坑和排查方法。

1. 整体思路与环境选型：先把“AI 编程环境”拆清楚

1.1 先想清楚：你要的是编码助手、AI 应用开发，还是本地模型

很多朋友一上来就问我“帮我装个 AI 环境”。这个说法太宽了，我一般会先反问三句话：你是要 AI 帮你写代码，还是要代码里调用 AI 接口，还是要自己跑一个小模型？三者对环境的依赖完全不同。

• 编码助手路线：只需要 VS Code 装上插件（Copilot、通义灵码、Continue 等），顶多再配一个 Codex 命令行工具，不依赖任何中间件。
• AI 应用开发路线：需要 Python 或 Node 环境，大概率还要 Redis、向量数据库、Elasticsearch 这类组件，此时 Docker 几乎是必需品。
• 本地模型路线：需要独立显卡、CUDA、大内存，Windows 下一般借助 WSL2 跑推理框架，这块今天不展开，但底座环境是通用的。

我见过太多人跟着教程把全套服务装完，最后只用了其中两个，剩下全是占用资源的累赘。我的建议是：以“编码助手 + AI 应用开发”为默认目标，这套组合覆盖最广，能写脚本、能接大模型 API、能跑中间件，后面想扩展本地模型也不冲突。

1.2 为什么推荐“原生 Windows + WSL2 + Docker Desktop”三件套

我实际用下来，最优解不是裸装 Linux 虚拟机，也不是只用 Windows 原生命令行硬扛，而是“Windows 负责日常编码，WSL2 负责 Linux 环境，Docker Desktop 负责跑中间件”这套三件套组合。

• 纯 Windows 原生：适合只写 Python 脚本、不碰容器的场景。缺点是 Redis、Elasticsearch 这类软件在 Windows 上的支持普遍差一截，很多官方镜像根本不提供 Windows 版本。
• WSL2 方案：相当于一个轻量 Linux 虚拟机，启动快、内存占用小、与 Windows 文件系统互通。日常开发最常用的 Linux 命令、Redis、Docker 后端都在这里跑，体验和 Linux 服务器几乎一致。
• 传统虚拟机方案：隔离性最好，但资源开销大、文件共享麻烦，日常开发完全没有必要。

个人经验：Windows 本体装开发工具，WSL2 里跑 Linux 命令和脚本，中间件一律 Docker 化。这套结构的好处是系统重装了也不用担心服务配置丢失，因为你的服务定义都在 docker-compose.yml 里，换新机器拉起来就跑。

1.3 动手前先做硬件与版本自查

安装前先花三分钟确认几件事，能省掉后面八成问题。内存至少 16G，建议 32G；CPU 虚拟化要在 BIOS 里打开（任务管理器-性能-右下角能看到“虚拟化: 已启用”）；Windows 版本建议 Win11 或 Win10 22H2 以上，版本太老的话 WSL2 和 Docker Desktop 会有兼容问题。

确认方式很简单，Win+R 输入 winver 看系统版本，Ctrl+Shift+Esc 打开任务管理器看内存和虚拟化状态。如果虚拟化是“已禁用”，需要重启进 BIOS 打开 Intel VT-x 或 AMD-V，这一步不做，后面的 WSL2 和 Docker 基本起不来。

2. 基础环境准备：终端、包管理器与 Windows 子系统

2.1 让终端更像回事：Windows Terminal + PowerShell 7

Windows 自带的 cmd 和旧版 PowerShell 实在不好用，第一件事就是把终端换成 Windows Terminal，它现在已经是 Windows 11 的默认终端，Win10 用户可以去 Microsoft Store 搜“Windows Terminal”安装。装上之后，把默认配置文件设为 PowerShell 7，顺便把字体换成 Cascadia Mono 或者 JetBrains Mono，看代码舒服很多。

PowerShell 7 的安装也简单，一条命令：

winget install Microsoft.PowerShell

不过要注意，它不会覆盖系统自带的 Windows PowerShell 5.1，两个版本共存，你在终端里把 PowerShell 7 设为默认即可。我习惯把 winget、git、python 这些命令都在 PowerShell 7 里跑，脚本语法更现代化，处理 json 也比老版本强。

2.2 安装 WSL2 并配置好 Linux 子系统

这一步核心就是一个命令。以管理员身份打开 PowerShell 或 CMD，执行：

wsl --install

这个命令会自动启用需要的 Windows 功能、下载 WSL2 内核并安装默认的 Ubuntu 发行版。装完一般会提示重启。重启后第一次进入 Ubuntu 会让你设置用户名和密码，这个用户名建议不要用大写，也别太复杂，后面进容器经常要敲。

装完确认版本：

wsl -l -v

看到 VERSION 列是 2 就说明用的是 WSL2。如果显示 1，执行 wsl --set-default-version 2 手动切换。WSL2 默认会占用不少内存，我一般会在 %UserProfile%.wslconfig 里手动限制资源，配置如下：

[wsl2] memory=8GB processors=6 swap=2GB

保存后执行 wsl --shutdown 重启 WSL 生效。这是很多教程不会写的，但实际开发中很管用，否则 Docker 和编译一起跑的时候，Windows 本体容易卡死。

2.3 Git 的安装与 Windows 下的使用习惯

Git 是绕不开的基础设施，安装命令：

winget install Git.Git

装完在终端里验证 git --version。然后立刻配置用户信息，否则提交会报错：

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

Windows 下用 Git 有几个经典坑，我一个个说。第一个是换行符，不同系统之间 LF 和 CRLF 转换会导致文件全部显示被修改，建议配置 core.autocrlf 为 false 或按项目统一用 LF。第二个是中文文件名乱码，需要执行 git config --global core.quotepath false。第三个是凭据管理器，Windows 装 Git 后默认会用 Git Credential Manager，以后推送到代码托管平台时弹窗登录一次就行，不用反复输密码。

3. Python 运行环境搭建与日常使用

3.1 用 winget 安装 Python 并确认 PATH

Python 在 Windows 上安装最稳的方式就是用 winget，它会自动写入 PATH，比从官网下载安装包手动勾选省心得多。

winget install Python.Python.3.11

装完打开一个新的终端，执行 python --version 能看到版本号就说明 PATH 没问题。如果提示找不到命令，最可能的原因是你用的终端是在安装之前打开的，重开一个就好。确实找不到的，去“设置-系统-关于-高级系统设置-环境变量”里手动把 Python 的安装目录加进 PATH。这一步是排错高发区，后面 7.1 会细说。

3.2 venv 虚拟环境与 pip 镜像源配置

Python 环境必备意识是：任何项目都要建虚拟环境，避免依赖互相打架。Windows 下创建和激活的命令如下：

python -m venv venv .\venv\Scripts\activate

在 WSL 里则是：

python3 -m venv venv source venv/bin/activate

激活后命令行前面会出现 (venv) 的提示，这时 pip install 的包只会装进这个项目。pip 默认源在国内很慢，我在用户目录下新建 pip.ini（Windows）或 .pip/pip.conf（Linux）来配置镜像。Windows 路径是 %APPDATA%\pip\pip.ini，内容很简单：

[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn

配置完 pip install 速度能快非常多，这个镜像地址是公开的、政策允许的，放心用。

3.3 跑通第一个会被 AI 接管的 Python 脚本

环境装好，写点什么验证呢？我的建议是直接用 AI 编程最常遇到的场景：调大模型接口。下面这段代码不依赖任何库，核心演示 requests 调用 OpenAI 兼容接口的骨架，BASE_URL 和 API_KEY 按你自己的服务商配置填：

import requests def call_llm(prompt: str) -> str: url = "你配置的API_BASE_URL/chat/completions" headers = { "Content-Type": "application/json", "Authorization": "Bearer 你的API_KEY" } payload = { "model": "你的模型名", "messages": [{"role": "user", "content": prompt}], "temperature": 0.2 } resp = requests.post(url, json=payload, headers=headers, timeout=60) if resp.status_code != 200: raise RuntimeError(f"API error: {resp.status_code} {resp.text}") return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": print(call_llm("用一句话介绍Python虚拟环境"))

运行方式：python test_llm.py。能正常打印出来，说明你的 Python、requests、网络链路都没问题。很多 AI 应用项目的第一行代码，就是从这种骨架开始扩展出来的。这里要提醒一句：API_KEY 千万别提交进 Git 仓库，用环境变量的方式读取更安全。

4. 运行时与中间件准备：JDK、Redis、Elasticsearch

4.1 JDK17 的安装与环境变量：Temurin 比 Oracle 更省心

如果你做 Java 后端或者要用到一些 Java 工具，JDK17 是目前最常用的长期支持版本。我的建议是直接装 Adoptium Temurin 发行版，它开源、无商业授权纠纷、更新也及时。

winget install EclipseAdoptium.Temurin.17.JDK

装完需要手动配环境变量，因为 winget 有时不会自动写 JAVA_HOME。在环境变量里新建：

• JAVA_HOME：C:\Program Files\Eclipse Adoptium\jdk-17.0.x.x-hotspot
• PATH 追加：%JAVA_HOME%\bin

配置完新开终端验证 java -version 和 javac -version。如果出现“找不到命令”，多半是环境变量没刷新生效，重开终端还不行就按 7.1 的方法彻底刷新。

4.2 Redis 在 Windows 上的三个常见安装思路

官方 Redis 并不提供 Windows 版本的正式支持，网上那些“Redis-x64-*.zip”多是社区移植版，版本较老。实际工作里我见过三种用法：

• 方案一：Docker 跑 Redis。最推荐，一条命令拉起来，跟生产环境一致，redis-cli 也带了。
• 方案二：WSL2 里安装 Redis。适合不想起 Docker 的场景，apt install redis-server 即可。
• 方案三：用 Memurai 或移植版。适合公司不让用 Docker 的场景，能用但版本落后。

个人建议：如果你已经决定装 Docker（第 5 章），Redis 这类中间件直接进容器，本地不需要装任何东西。

4.3 用 Docker 拉一个 Elasticsearch，把 JDK 的问题也顺带解决

Elasticsearch 同样没有官方 Windows 安装包的便捷渠道，而且它运行依赖 Java。与其手动配一套 ES+JDK，不如直接丢进 Docker。下面命令我实际跑过，一拉一启就完事：

docker run -d --name elasticsearch \ -p 9200:9200 \ -e "discovery.type=single-node" \ -e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \ docker.elastic.co/elasticsearch/elasticsearch:8.12.2

内存给 512m 是避免小内存电脑被 ES 吃满。启动后访问 http://localhost:9200 能看到 json 信息就成功了。8.x 版本默认开启安全认证，会出现一个随机密码和证书；如果是纯本地开发，可以在启动时追加 -e "xpack.security.enabled=false" 关掉认证，省去一堆麻烦。

这里有个额外收获：既然 ES 在容器里跑，它自带的 JDK 是容器内部的，你本地配的 JDK17 只给你的 Java 项目用。两条路线互不干扰，这也是容器化带来的最大价值。

5. Docker Desktop 的安装、配置与验证

5.1 安装 Docker Desktop 前必须确认的三件事

Docker Desktop on Windows 默认依赖 WSL2 后端，所以前面的 WSL2 装好就是最大的前置条件。除此之外还要确认三件事：系统虚拟化已开启；Windows 版本建议 Pro 或 Enterprise（家庭版也能用，但要额外装 WSL2 并手动配置，麻烦）；磁盘预留至少 10G 空间，Docker 镜像动辄几百 M，ES 这种甚至上 G。

去 Docker 官网下载 Docker Desktop Installer.exe，双击安装，注意安装过程中有一个“Use WSL 2 instead of Hyper-V”的勾选项，一定要勾上。勾了才能用 WSL2 后端，性能和兼容性都比旧版 Hyper-V 好。

5.2 安装后的配置：让 Docker 待在 WSL2 里

装完启动 Docker Desktop，打开 Settings - Resources - WSL Integration，确认“Enable integration with my default WSL distro”已勾选，并且在列表里选中你的 Ubuntu 发行版。这样你在 WSL 终端里也能直接敲 docker 命令，Windows PowerShell 里也可以，两边共享同一个 Docker 引擎。

然后建议做两件事。一是把镜像存储在 WSL2 的虚拟磁盘里，这也是默认行为，不用改；二是给 WSL 整体规划内存上限，重复 2.2 里 .wslconfig 的配置。Docker 跑多了不限制内存的话，Windows 机子会变得明显卡顿。

5.3 镜像加速、验证测试与日常清理习惯

Docker 装好第一件事是拉个 hello-world 验证：

docker run --rm hello-world

能看到“Hello from Docker!”那段经典提示就算成功。接着要考虑拉镜像速度的问题，国内环境在 Settings - Docker Engine 里加一段 registry-mirrors 配置，把加速地址填成你自己的专属加速地址：

{ "registry-mirrors": ["https://你的加速地址"] }

保存后 Docker 会自动重启。镜像加速地址每个云厂商给的都不太一样，而且通常会要求注册账号后才能拿到专属地址，网上有些公开的公共地址时好时坏，我建议直接注册一个容器镜像服务的账号，拿自己的专属地址，稳定得多。

日常使用中还要养成清理习惯。Docker 跑久了会积累大量悬空镜像和日志，我每隔一两周执行一次：

docker system prune -f

这个命令不会删正在使用的容器和镜像，只清理垃圾，放心用。Windows 上不需要装各种“清理大师”，Docker 自己的清理命令比任何第三方工具都靠谱。

6. AI 编程工具落地：从 Codex 到 VS Code 插件

6.1 Codex 的安装与初始化

Codex 现在有官方桌面版，Windows 可以直接下载安装包，安装流程和普通软件一样，装完在开始菜单打开即可。如果你更习惯命令行，也可以用 npm 方式安装。

npm install -g @openai/codex

装完后在终端执行 codex 进入交互界面，首次使用会让你登录账号完成认证，然后在 ~/.codex/config.toml 里可以指定模型和参数。比如我习惯把超时放宽、把默认模型改成更强的那一档，配置大致长这样：

model = "gpt-5-codex" model_provider = "openai" approval_policy = "on-request"

approval_policy 建议设成 on-request，这样 AI 每次要改文件或者执行命令之前都会先询问你，对代码库更安全。auto 模式虽然省事，但新手阶段容易失控。

Codex 的典型用法是在项目根目录直接运行，它会自动读取项目结构和 Git 状态，然后你把需求用自然语言描述清楚就行。比如“在 src 下新增一个函数，把 CSV 转成 JSON 并保留空行”，它会自己定位文件、改造代码、给出 diff 确认。这一点对不熟悉项目结构的人帮助很大，相当于有人帮你快速定位改动点。

6.2 VS Code 里的 AI 插件矩阵：选一个主打，两个备用

命令行有 Codex，编辑器里还得有日常陪伴的插件。我用了大半年的几个插件，按场景给你列个表：

我的选型建议是：公司报销选 Copilot；不想折腾免费接入选通义灵码；喜欢开源和自托管模型选 Continue。三个都装上、同时开也可以，但要注意它们会抢 Tab 键的补全事件，如果发现补全混乱，只留一个负责补全即可。

6.3 让 AI Agent 完整跑通一个本地任务

光有工具不会用等于白搭。下面给一个我经常演示给朋友的入门场景，目标是让 AI Agent 帮你整理一个下载目录里堆积如山的文件。在项目目录下对 Codex 或 Cline 说：

“帮我写一个 Python 脚本，扫描当前目录下所有文件，按扩展名分类移动到 images、docs、archives、code 子目录，重名文件自动加时间戳后缀，并打印每个分类移动了多少个文件。”

正常来说，AI 会生成脚本、询问是否创建文件、执行、展示结果。这个过程你只需要点几下确认，真正的“编程”由 AI 完成。但注意，AI 生成的代码不保证完全正确，你要养成阅读 diff 的习惯，至少理解它动了哪些文件、为什么动。我见过有人全自动确认，结果脚本把配置文件移动错了目录，所以 approval_policy 设成 on-request 这个习惯，真的能救你。

7. 常见问题与排查技巧实录

7.1 环境变量改了没生效，怎样才是真正刷新

Windows 改完环境变量后，已打开的终端不会自动刷新，这是最容易踩的坑。最快的刷新方式是用 refreshenv 命令，但它是 Chocolatey 带来的函数，如果你的机器没装 Chocolatey，就完全关闭所有终端窗口再重新打开——注意是所有窗口，包括 VS Code 的集成终端。如果还不行，注销或重启一次系统。不要在同一个老终端里反复试命令，那样永远看不到新配置。

7.2 Docker 或 WSL 启动失败，先看 Windows 安全日志

遇到 Docker Desktop 起不来或者 WSL 报错，很多人直接重装，其实先查日志更高效。按下 Win+R 输入 eventvwr.msc 打开事件查看器，在“Windows 日志-系统”里按来源筛选，找名字包含 Docker、WSL、Hyper-V 的记录，错误级别的事件一般会给出明确原因，比如虚拟化未开启、内存不足、某个服务没启动。

另一个常用命令是：

wsl --status

它会显示 WSL 的当前状态和默认版本。如果显示内核过旧，执行 wsl --update 更新内核，大概率就能解决。排查顺序是：虚拟化 -> WSL 状态 -> Docker 日志 -> Windows 日志，按这个链路走，基本不会走弯路。

7.3 pip、npm、docker 拉取慢怎么处理

下载慢的问题，本质是源的问题。pip 换镜像参看 3.2；npm 同理，把 registry 改成国内镜像；Docker 用 5.3 的 registry-mirrors。这里要特别提醒：不要因为拉取慢就随便搜一个“加速地址”填进去，有些第三方公共镜像源本身也在变，出了问题很难排查。优先使用你自己注册的容器镜像服务的专属地址，稳定且有保障。

7.4 Codex 或 AI 插件连不上服务、识别不了项目怎么办

Codex 或 AI 插件如果报认证失败，先检查登录状态，重新登录一次。如果插件在编辑器里不响应，先确认有没有切换过项目目录——AI 插件只对打开的工作区有感知，在空白文件里问“帮我看看项目”，它当然不知道你在讲什么。还有一类问题是网络代理导致的，这个就看你自己的办公网络环境，建议在系统设置里检查代理配置是否和多开工具冲突，保持环境干净即可。

7.5 高频问题速查表

这套环境从零走到 AI 辅助编码，我一共走了三遍，每次都比上一次快，最后一次几乎只花了半个下午。个人体会是：Windows 上折腾 AI 编程环境，最值钱的不是某个具体软件，而是“容器化 + 子系统”这套底座思维——中间件全容器化，系统重装无负担；AI 工具按需接入，不给工作流添乱。

最后再分享一个小技巧：环境搭完后，把你自己常用的安装命令、配置代码、踩坑记录整理成一个 setup.md 放进 Git 仓库，下次换电脑直接照着自己文档跑一遍，比任何教程都适合你。后续我准备在这个环境基础上继续扩展 Spring AI 和本地 Agent 框架的实战，到时候再接着分享。