企业官网建设流程全解析

那年我把主力开发机从 Linux 切回 Windows 的时候，身边还有人觉得是倒退。事实是，Windows 上搭 AI 编程环境的成本这几年真降下来了：WSL2 稳定、Docker Desktop 可以直接用、Codex 桌面版这类 AI 编程助手都有了原生入口，连以前最让人头疼的 Redis、Elasticsearch 这类服务，也能用容器一键带起来。这篇指南是我在 2026 年 9 月重装系统时实际跑通的完整流程，从裸机一路到能顺畅使用 AI 辅助开发的 Windows 开发环境。

适合谁看？手头只有 Windows 电脑、想进入 AI 开发，或者想把 AI 工具接进日常编码流程的开发者。不限定技术栈，不用管你是写 Python、Java 还是前端，只要愿意把命令行走通，这套环境就能让你后面省掉大量折腾时间。

1. 整体设计与组件清单

1.1 先把依赖关系理清楚

搭建环境最怕一上来乱装软件，装完根本分不清谁依赖谁。我这次每一个组件都有明确用途：AI 工具和项目代码运行在 Python 等语言环境，Python 环境由 Miniconda 统一管理；Redis、Elasticsearch 这类基础服务跑在 Docker 容器里，Docker 底层依赖 WSL2；终端和 Git 负责把命令行体验拉到现代水平。

依赖关系理顺之后，后面排错会轻松很多。举几个例子：Codex 桌面版会直接调用 git 去读 diff、切分支，如果 Git 没配好，AI 一启动就报错；Python 包和操作系统绑定得很死，Conda 没装对，AI Agent 帮你装依赖时很容易把包装错地方。所以我把最基础的终端、Git、Conda 单独放一节，就是怕有人跳过去直接装 AI 工具，结果环境全是暗坑。

1.2 组件选型速查表

先给一张表，后面每一节再展开讲安装和踩坑。

为什么这套组合不出错？核心是每一层边界清晰：Conda 只管语言运行时，Docker 只管服务，AI Agent 只管生成代码和执行命令，Git 管代码状态。出了问题顺着边界查，不会整个环境一起崩。

1.3 Windows 上独有的选型思考

Windows 的包管理生态确实不如 Linux，过去大家全靠人工下载安装，很容易装到旧版或相互冲突的组件。我的原则有三条：

能用官方安装包就装官方安装包，不迷信“解压即用”的绿色版软件，绿色版运行时经常缺依赖。

能用程序包管理器就用程序包管理器，Git 这类可以用命令行装。但 Miniconda 和 Docker Desktop 我建议还是用安装包，因为安装过程会写系统级配置，纯命令行不一定可靠。

遇到需要跑 Linux 服务场景的组件，不要硬装在 Windows 原生环境里，直接上 Docker。我早年试过 Redis for Windows，后来发现维护成本远比 Docker 高，这个后面单独说。

再说 WSL2 和 Hyper-V 的区别。Docker Desktop 在 Windows 上可以选择两种后端引擎，我强烈建议用 WSL2。一是 WSL2 启动更快、内存占用更可控；二是一旦你后面需要直接操作 Linux 文件系统，WSL2 里也能跑 Docker 命令，使用体验更连续。手动创建 Hyper-V 虚拟机当然也可以，但那是绕远路。

2. 打地基：终端、Git、PowerShell

2.1 先把终端换成 Windows Terminal

这一步很基础，但影响巨大。老 PowerShell 窗口的字体渲染、复制粘贴、UTF-8 支持都很一般，AI 生成的命令往往带着各种引号和反斜杠，在 cmd 或旧版 PowerShell 里一贴就乱。

所以第一件事是装 Windows Terminal。装完后打开设置，把默认配置文件改成 PowerShell，默认终端应用程序改成 Windows Terminal。这样以后按快捷键弹出来的都是新终端。

我还会顺手做两件事：把字号调到 14，字体换成 Nerd Font 字体，这类字体对图标渲染和路径显示更友好，特别是用 Codex 这类 AI 工具时，经常要输出各种特殊字符，字体不合适容易错位。Windows Terminal 还支持标签页和分屏，AI Agent 在处理多任务时，你可以一边看日志一边下指令，效率完全不一样。

2.2 安装 Git 并做好全局配置

第二步是 Git for Windows。安装向导有几个关键选项需要留意：

组件选择里把“Git Bash Here”和“Git GUI Here”勾上，之后右键就能进 Git Bash。

PATH 环境变量这里选默认的“Git from the command line and also from 3rd-party software”，保证 IDE 和 AI 工具都能找到 git。

凭据助手选择“Git Credential Manager”，Windows 下保存 GitHub 凭据最省心。

装完在 PowerShell 里执行：

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

在 AI 编程环境里，Git 的作用不只是版本管理。Codex 这类 AI Agent 会频繁读取 git diff、git log，甚至自动创建分支提交代码。如果 Git 本身没配好，Agent 一启动就报错。我个人的习惯是，每次让 AI 改代码前先git status，看清当前工作区，再给它下指令。这样它生成的改动不会被无关文件干扰，回溯也方便。

如果你用 GitHub，可以给 Git 配上 SSH key，拉私有仓库会顺畅很多：

ssh-keygen -t ed25519 -C "你的邮箱"

生成后把~/.ssh/id_ed25519.pub的内容贴到 GitHub 设置页。 Windows 的 ssh-agent 默认不一定启动，拉仓库时如果提示Permission denied，先去服务列表把“OpenSSH Authentication Agent”的启动类型改成“自动”并启动它。

2.3 解决脚本一运行就闪退的问题

“脚本一闪而过”是我看到热搜词以后特别想展开说的痛点。新手最常见的画面：双击.bat或.ps1，屏幕一闪就没了，跟没反应一样。这里要分两种情况。

如果是.bat文件，窗口关闭是因为脚本执行完，命令窗默认自动退出。解决方案是，要么在脚本末尾加pause，要么先把终端打开，然后在终端里执行.\脚本名.bat，这样窗口不会关，报错输出也能停留在屏幕上。

如果是.ps1，那很可能是被 PowerShell 执行策略拦住了。Windows 默认执行策略是Restricted，不允许跑本地脚本。你需要在 PowerShell 里执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned的意思是：本地写的脚本可以运行，从网络下载的脚本必须有数字签名。这是安全底线，不要为了省事设成Unrestricted。

还有一个更隐蔽的问题：PowerShell 脚本里某个命令报错后，脚本默认不会立刻停，而是继续往下跑，等你看到最后的闪退时，根本来不及定位是哪一行出错。所以排查脚本闪退时，先别急着双击，右键选择“使用 PowerShell 运行”，或者干脆在 PowerShell 里逐行执行，找出具体出错的那一行。AI 生成的批量脚本尤其容易犯这种边执行边报错的毛病，复制过来后必须先人工过一遍高风险操作，比如网络下载、写注册表、删除文件，再执行。

2.4 JDK 17 到底装不装

热搜里有“jdk17下载windows”，我专门解释一下。JDK 17 是很多 Java 系工具，特别是 Elasticsearch 8.x 的运行时要求。如果你跟着我的方案用 Docker 跑 Elasticsearch，容器里自带 JDK，宿主机可以不装。不过如果你想在宿主机直接调试 Java 项目，那么装一个 JDK 17 很合理。

Windows 下我建议装 Eclipse Temurin 或 Microsoft OpenJDK，别装 Oracle JDK 个人版，许可证和后续更新维护太麻烦。装完设置好JAVA_HOME环境变量，把%JAVA_HOME%\bin加到 PATH，然后验证：

java -version

能输出版本信息就行。为什么在 AI 环境里要提这个？因为你的 AI Agent 分析代码时，如果项目本身是 Java 项目，它会默认这台机器上有 JDK。环境缺了，Agent 想帮你编译验证也验证不了，等于少了一条自动化路径。

3. Python 与 Conda 虚拟环境

3.1 Miniconda 安装：别一上来就装 Anaconda

AI 生态里 Python 是绝对主流。Python 环境管理我用的是 Conda，但装的是 Miniconda 而不是 Anaconda。Anaconda 安装包太大，附带了一堆大概率用不上的库；Miniconda 只有 conda 和 Python 本体，需要什么包再现场装，干净利落。

下载地址直接去官方选 Windows 版本，安装时有几个点很关键：

安装路径建议用C:\Miniconda3，不要装到带空格的目录，后面很多工具对路径空格很敏感。

安装向导里有一个“Add Miniconda3 to my PATH environment variable”的选项，默认不勾，我建议也不要勾。不勾的好处是避免 conda 自带 Python 抢走系统里其他 Python 的默认位置，我们用conda init来管理访问方式。

如果电脑上已经装了其他 Python，更别随手勾选，免得 PATH 冲突，IDE 里用的解释器和命令行里用的完全不是同一个，排查起来非常痛苦。

需要批量部署的，可以直接用静默安装命令：

Start-Process ".\Miniconda3-latest-Windows-x86_64.exe" -ArgumentList '/InstallationType=JustMe','/RegisterPython=0','/S','/D=C:\Miniconda3' -Wait

其中/RegisterPython=0表示不让 conda 注册为系统默认 Python。装完打开新终端，如果直接输入conda --version提示找不到命令，可以先执行C:\Miniconda3\Scripts\conda.exe --version验证安装是否成功。

3.2 创建独立的 AI 开发环境

Conda 的核心用法是一个项目一个环境，环境之间装的包互不干扰。AI 项目的依赖特别容易打架，有的要 numpy 1.x，有的要 2.x；有的只支持 Python 3.10，有的非 3.12 不可。为了避免这些冲突炸掉开发机，我每次都先新建环境：

conda create -n ai python=3.11 -y conda activate ai

创建环境时可以直接指定 Python 版本，Conda 会自动下载。这里我特意选 3.11，而不是最新版，原因是很多 AI 库的二进制包发布节奏相对滞后，最新 Python 刚发布时，大量包还没有预编译的 wheel 文件，Windows 上现场编译 C 扩展很容易翻车。写这篇时，Python 3.11 和 3.12 是最稳的组合。如果你的框架文档明确要求 3.12，把命令里改成python=3.12即可，思路一样。

激活环境后，顺手升级一下 pip：

python -m pip install --upgrade pip

接下来装什么包看你项目需求。比如做 AI 训练的话：

pip install torch transformers datasets

如果只是普通开发，这一步就算完成，剩下的交给 AI 工具去处理。

3.3 让新终端默认能用 conda 命令

我经常被问到：conda 装完，新开的 PowerShell 里输入 conda 提示无法识别。这通常是因为 Conda 的初始化没写进 PowerShell 配置文件。在你已经能在当前终端使用 conda 的情况下，执行：

conda init powershell

如果你并没有把 Miniconda 加入 PATH，那么先执行：

C:\Miniconda3\Scripts\conda.exe init powershell

然后重新打开终端，PowerShell 前面应该会显示(base)。如果没有显示，大概率是执行策略拦了配置文件的加载，回到 2.3 节处理一下。

这里要提一个习惯性问题：我几乎不往 base 环境里装包，base 只留 conda 本身。AI Agent 在生成代码时，可能会自己指导你往“当前环境”里 pip 装某个包。如果你区分得清楚，看一眼终端前缀就能判断现在到底在哪个项目环境里。这个细节对后面用 AI 工具很重要，环境一混，AI 帮你装的所有东西都可能落在错误环境里，排查起来非常痛苦。

4. Docker、Redis 和 Elasticsearch 的 Windows 落地

4.1 Docker Desktop 和 WSL2 的配合

服务类组件在 Windows 原生的玩法确实折磨人，所以这一节主角是 Docker Desktop。安装前，先把 Windows 功能里的“适用于 Linux 的 Windows 子系统”和“虚拟机平台”打开。管理员权限的 PowerShell 里执行：

wsl --install

如果提示找不到命令，说明系统版本较旧，先去 Windows Update 完成系统更新。装完重启电脑。这个命令会默认安装一个 WSL 发行版，同时开启所需的系统组件。

接着下载 Docker Desktop for Windows。安装过程中有一个“Use WSL 2 instead of Hyper-V”的选项，勾上。安装完成后，打开 Docker Desktop 设置里的 Resources → WSL Integration，把默认集成打开，这样 WSL 里也能直接调用 Docker 命令。验证：

docker run hello-world

看到一句 “Hello from Docker!” 说明容器引擎已经正常工作。如果卡在启动阶段，解决方法我放到第 6 节。

有人会问：Windows 上为什么不用 Podman，或者直接装 Docker Engine？答案很简单：Windows 没有官方 Docker Engine 的原生支持，Docker Desktop 靠虚拟机跑 Linux 容器才是官方推荐路径。Podman 体验也在变好，但大量现有 docker-compose 配置和文档都是围绕 Docker Desktop 生态的，上手成本更低。

4.2 用 docker-compose 一键起 Redis 和 Elasticsearch

接下来要跑两个服务：Redis 和 Elasticsearch。别再直接往 Windows 系统里装了，所有配置都放到 docker-compose.yml 统一管。在项目根目录建一个services/docker-compose.yml：

services: redis: image: redis:7-alpine container_name: local-redis ports: - "6379:6379" volumes: - redis-data:/data restart: unless-stopped elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.15.3 container_name: local-es environment: - discovery.type=single-node - xpack.security.enabled=false - "ES_JAVA_OPTS=-Xms512m -Xmx512m" ports: - "9200:9200" volumes: - es-data:/usr/share/elasticsearch/data restart: unless-stopped volumes: redis-data: es-data:

在 docker-compose.yml 所在目录执行：

docker compose up -d

等几十秒容器就能起来。验证 Redis 用docker exec -it local-redis redis-cli ping，返回PONG说明通了。验证 Elasticsearch 直接打开浏览器访问http://localhost:9200，能看到 JSON 格式的版本信息。

开发环境里我关闭了 ES 的安全认证，这样 AI Agent 对接本地知识库时不用处理证书和账号。但生产环境绝对不能这么干，这个边界必须清楚。

4.3 为什么我不推荐 Windows 版 Redis 安装包

热搜词里有“redis windows 下载”，我特别想多说几句。

Redis 官方并不发布正式 Windows 版本。历史上 GitHub 上的 Redis for Windows 其实来自一个微软仓库的移植版，很多年前就不再活跃。后来有些第三方编译版，质量参差不齐，甚至有人往里捆绑广告。做开发环境的首要原则是可靠，所以用 Docker 是最稳的方式。

Elasticsearch 同理。虽然官方提供了 Windows 安装包，但它需要本机 JDK，配置过程还有目录结构、内存参数一大堆讲究。用容器把所有细节隔离在一个配置文件里，团队里任何一个人拿到同一份 docker-compose.yml，都能复现出一模一样的服务环境。这一点在 AI 开发里尤其关键，因为 AI Agent 最擅长的就是“照着项目配置来”，你给它一个 docker-compose，它一眼就能看懂整个依赖关系。

5. 接入 AI 辅助编程工具

5.1 Codex 桌面版的安装与验证

前面所有准备工作，都是为了这一节：让 AI 真正帮你写代码。Codex 是目前 Windows 上体验最好的 AI 编程入口之一，官方同时提供了桌面版和命令行两种形态。我的做法是桌面版当主入口，IDE 插件做辅助，避免两个界面同时纠结。

安装过程很常规，下载官方 Windows 桌面版安装包，安装完成后登录账号。如果要用命令行交互，它一般也会把 CLI 带进来，直接在终端里执行codex就能进入对话模式。首次打开会要求授权，按提示确认即可。

验证它能不能真正干活，比啥都重要。我习惯让它先做一个小任务：在当前目录新建一个 Python 脚本，读取某个文件并统计行数。如果它能完成，说明基础环境通了。注意观察它执行命令时会不会被权限弹窗挡住。如果 AI 要执行需要管理员权限的操作，Windows 的 UAC 会让它卡住，这是正常的，选择允许即可。

5.2 给 AI 的提示词这样写才高效

“AI 编程提示词”这个话题很多人问。这里分享我常用的三个模板。

第一个是“环境搭建类”。直接对 AI 说：

我要在 Windows 11 + PowerShell 7 + Miniconda 的 ai 环境里安装 xxx，版本要兼容 Python 3.11。请只输出命令，并在关键步骤加注释，不要修改我的系统全局 PATH。

这里限定了平台和运行环境，AI 就不会给出 Linux 的 apt 或 macOS 的 brew 命令了。限定“不要修改全局 PATH”，是为了防止 AI 把 conda 环境搞乱。

第二个是“代码审查类”：

请审查当前分支相对 main 的 diff，重点检查潜在的空指针、资源泄露、Windows 路径分隔符处理错误。输出时按严重程度排序，给出修改建议，但先不要直接改代码。

让 AI 先“只审不改”，守住代码审查的边界，避免它自作主张把整个文件重写。

第三个是“Agent 自动修复类”：

有一个 bug：执行 python main.py 会报 xxx。先复现，再定位根因，然后修改代码并运行测试。所有改动单独开一个 git 分支，最终展示 git diff。

这种提示词特别考验环境完整性。Git、conda、Docker 没配好，Agent 执行到一半就会失败，所以前面几节的基础打得越扎实，后面 AI 用起来越舒服。

还有一个经验：每次跟 AI 交互前，在提示词里告诉它“先看我的项目结构和现有代码风格”，能显著减少答非所问的概率。更高级的玩法是，在项目 README 里写清楚 Python 版本和 Docker 服务有哪些，AI Agent 每次运行时自己会读，不用重复交代。

5.3 本地大模型跑起来，省得什么都问云端

有时候只是问一个命名规范、代码片段之类的轻量问题，不需要开远程 AI，直接本地跑一个小模型更自在。Windows 上推荐用 Ollama。装好之后，在终端执行：

ollama run qwen2.5:7b

就能在命令行里和新模型对话。如果想接入 IDE 补全，很多 AI 插件支持配置自定义的 OpenAI 兼容接口，把地址指向http://localhost:11434/v1，本地模型就能出现在代码补全面板里。本地模型受限于算力，补全质量跟云端大模型有差距，但胜在私有、免费、离线可用。

如果你用 Java 生态，Spring AI 也可以把本地模型配置成 Bean 来调用，但这里的思路是一样的：AI 工具对接的统一协议越来越标准化，Docker 起的本地服务完全可以作为这些 AI 工具的后端。

5.4 安全和合规底线

用 AI 编程工具时，不要把未脱敏的数据库连接串、内部系统账号、第三方访问令牌整段贴进对话窗口。即使你用的是本地模型，也要想想工具日志会不会把内容写到磁盘上。大的 AI 平台有内容安全策略，这是整个生态的一部分，我们应该配合而不是绕过。

因此，在代码审查时给 AI 设好边界：不允许它访问敏感目录，不允许它自动执行高危命令，比如删除数据库表、格式化磁盘。部署类操作必须由人类确认。AI Agent 会越来越强，但把控制权攥在自己手里，才不会让提效变成埋雷。

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

6.1 一张速查表解决大部分问题

我把环境搭建前后最常踩的坑列成一张表。

6.2 Docker 和 WSL2 的坑，我实际踩过

WSL2 内存问题是我遇到最多的。默认情况下 WSL2 会占用最多一半物理内存，而且回收不积极。容器多跑几个之后，Windows 本身就开始卡。我的解决办法是在用户目录下建一个.wslconfig文件：

[wsl2] memory=6GB processors=4

这个文件只对 WSL2 生效，保存后执行wsl --shutdown，再重启 Docker Desktop 和 WSL 发行版就可以了。

另一个坑是磁盘空间。Docker 容器文件在 WSL2 的虚拟磁盘里，默认会越来越大。Elasticsearch 的数据卷存多了，虚拟磁盘文件可能把 C 盘塞满。建议在.wslconfig里加上swap=2GB，同时定期清理无用容器和镜像：

docker system prune -f

在 AI 开发中这个命令尤其常用，本地大模型镜像动不动几个 G，不清理的话 C 盘很快报警。

排查 Windows 层面的服务或驱动问题时，我会直接打开事件查看器，翻“Windows 日志”里的系统日志和安全日志，比到处猜更高效，很多启动失败的根本原因都写在这里。

6.3 AI Agent 卡住时，按这个顺序排查

AI 工具跑起来之后，最常见的问题不是 AI 本身，而是环境和权限。比如 Agent 说“我无法写入文件”，第一反应应该去查当前工作目录是否真的存在。换句生活化的话说，Windows 上运行 AI Agent，就像请了一个超级能干的实习生：他懂很多，但对这台机器的规矩一概不知，你要把路径、权限、语言环境都给他准备好。

遇到 AI Agent 执行命令失败，我的通用排查顺序是：

1. 看完整日志，别只盯最后的错误摘要，日志里往往藏着真正原因。
2. 看它是不是卡在交互式确认上。某些 CLI 工具会弹出“是否继续 y/N”，AI 看不到提示就一直在那里挂机。
3. 确认 PowerShell 或 Git Bash 的执行策略和 PATH 是否正确。
4. 在提示词里明确加上一条：如果遇到交互式确认，默认选择安全选项并告诉我，不要跳过检查。

6.4 搭完之后我还会做的一件事

整套环境跑通以后，建议把搭建命令整理成一个一键脚本，放进 git 仓库。以后换电脑，或者系统出问题重装，直接拉下来执行，几分钟就能把同样一身环境再搭起来。

我自己在实际操作中的最大体会是，别急着装软件，先把依赖关系想清楚。Windows 上 AI 开发的上手难度其实早就被拉低了，真正容易卡住人的往往就是 PATH、执行策略、WSL2 内存。把它们一一理顺，剩下的就是让 AI 帮你写代码。环境是一次性投资，别让它变成你和 AI 协作时每次都会卡一下的门槛。