Windows AI 编程环境从零搭建指南[20260909]最近帮几个朋友在 Windows 上把 AI 编程环境跑起来发现大部分人卡住的地方根本不是 AI 工具本身而是 Windows 上那一堆前置依赖WSL、Docker、Python 环境、各种 CLI 工具链哪个没配好都会在中途断掉。网上教程虽多但大多各讲一段很少有人把整个流程串起来讲清楚。这篇就把我从零开始搭的一套 Windows AI 编程环境完整记录一遍从底层依赖到 Codex 这类 AI 编程助手再到本地大模型部署和 Docker 中间件一条龙捋到底。无论你是刚开始接触 AI 编程的新手还是想在 Windows 上把自己的开发环境升级一下的老手这份指南都能直接照着操作。先说清楚这套环境解决什么问题让 AI 工具能在 Windows 上顺畅读代码、写代码、跑代码同时把本地模型、数据库、搜索服务这些后端依赖也一并搞定。为什么要强调 Windows因为很多人装了 Codex 后发现安装未完成装了 Docker 后发现 WSL 版本不对装了 Miniconda 后发现环境变量冲突——这些问题都是 Windows 特有的Mac 和 Linux 很少踩。我踩过这些坑之后决定把完整路径写出来。动手前先想清楚的整体规划1.1 Windows 跑 AI 编程环境的三种路线在 Windows 上搭 AI 编程环境绕不开一个底层选择你打算让 AI 工具直接跑在 Windows 原生环境还是跑在 WSL2 的 Linux 环境里或是用 Docker 容器隔离。三条路线各有适用场景选错了后面会很难受。Windows 原生环境最简单直接安装 Python、Node.js、Git 等工具AI 编程助手通常以 VS Code 插件或独立客户端的形式直接调用。好处是路径直观、文件访问没有隔阂坏处是很多依赖库在 Windows 上编译有坑——比如某些 C 扩展包你需要预装 Visual Studio Build Tools否则就会报 cl.exe 找不到。此外 Windows 的路径分隔符和 Linux 不一致部分 AI 生成脚本如果写了 Linux 路径你在 Windows 上就得手动改。WSL2 是更被推荐的路线。Codex 官方推荐在 Linux 环境跑Docker Desktop 也深度集成 WSL2。等于你在 Windows 里开了一个完整的 Linux 子系统所有命令行工具、包管理器都按 Linux 习惯来AI 生成代码的兼容性也更好。代价是跨文件系统访问有性能损耗整条调用链也多了一层虚拟化。Docker 容器路线适合做隔离和复现比如用容器跑 Jupyter、跑 Elasticsearch、跑 Redis把基础设施和你的日常开发目录分开。我实际推荐的组合是AI CLI 工具跑在 WSL2项目代码放在 Windows 文件系统中间件用 Docker Desktop 管理这样 Windows 文件可以用 VS Code 直接编辑AI 命令行在 WSL2 里执行两边互补。1.2 需要准备的关键依赖清单硬件方面AI 编程工具本身并不挑机器Codex 这类云端推理工具只需要能跑浏览器和命令行电脑配置要求不高。如果你要本地部署大模型那就得看显存经典型号比如 7B 参数量化模型大概需要 8GB 显存能跑得比较流畅13B 模型推荐 16GB 以上内存建议不低于 32GB。我自己的主力机是 32GB 内存加一块 12GB 显存的显卡跑 Codex 完全没有压力跑本地 7B 模型也基本不掉帧。软件方面我把这套环境的依赖分成三层基础层Windows 10/11建议更新到最新版、Git、Windows Terminal、VS Code运行层WSL2Ubuntu 22.04/24.04、Miniconda、Node.js 和 Python 对应版本工具层Docker Desktop、Codex 或同类 AI 编程 CLI、Ollama本地模型管理、Redis 和 Elasticsearch中间件每一层都有它的作用。Git 负责代码版本管理WSL2 负责提供 Unix 兼容环境Miniconda 管理 Python 版本和依赖隔离Docker Desktop 提供容器化中间件Codex 和 Ollama 是 AI 能力的执行入口。没有哪一层是可有可无的尤其是 WSL2它几乎决定了 Docker 和 Codex 能不能顺利工作。1.3 为什么把 2026 年的时间点作为参考这篇文章的配置版本以 2026 年为基准并不是为了标新立异而是因为 AI 编程工具迭代速度实在太快。2024 年底 Codex 刚发布时只支持云端运行2025 年就出了桌面版和 CLI 的本地任务执行能力到 2026 年功能和安装方式又会变。以当前时间点为基准来写环境搭建指南能避免读者照着旧教程装了个被废弃的版本。所以当你看到这篇文章时版本号可能已经又更新了。请把重点放在环境搭建的思路和依赖关系上先把基础层装好再装工具层最后配 AI 模型。这个顺序不太容易过时因为底层依赖相对稳定变化大的只是 AI 工具自身的参数和界面。核心细节解析与实操要点2.1 WSL2 的正确安装姿势WSL2 是整套环境的地基。很多人在 Windows 上装 Docker Desktop 时提示WSL 2 installation is incomplete多半就是因为 WSL 内核没有更新或者没有设置默认版本。安装 WSL 最省事的方式是以管理员身份打开 PowerShell执行wsl --install这条命令会默认安装 Ubuntu 发行版并启用 WSL2 特性。装完系统会提示重启重启之后再执行wsl --set-default-version 2把默认版本固定为 WSL2。注意如果之前装过 WSL1需要单独把发行版切换过来wsl --set-version Ubuntu-22.04 2进入 Ubuntu 之后第一件事是更新软件源并安装基础编译工具sudo apt update sudo apt upgrade -y sudo apt install build-essential -y这里有一个很重要的避坑点不要把 WSL2 的 Ubuntu 当作日常主力环境用来存大量文件。WSL2 的虚拟磁盘默认放在系统盘且大小会随使用自动增长如果项目依赖特别多vhd 文件可能膨胀到几十 GB。建议在项目目录设置中把 WSL2 的存储位置迁移到其他盘或者在 WSL2 里只保持必要的开发环境项目文件放在 Windows 侧目录。2.2 Miniconda 安装与 Python 环境隔离Python 环境管理我强烈推荐 Miniconda 而不是 Anaconda。Anaconda 自带的包太多太杂很多根本用不上白白占用磁盘空间。Miniconda 只保留了 conda、Python 和必要的包管理工具轻量得多。Windows 上安装 Miniconda 有几个坑要提前知道安装时选Install for all users可能会有权限问题建议装到用户目录下例如C:\Users\你的用户名\miniconda3。安装完成后建议勾选“Add Miniconda3 to my PATH environment variable”省得后续命令行找不到 conda。如果在 PowerShell 里执行conda提示无法加载配置文件需要先执行conda init powershell初始化之后重启终端conda 命令才能生效。我个人的习惯是每个项目单独建一个 conda 环境而不是全堆在 base 里。例如conda create -n ai-env python3.11 conda activate ai-envPython 版本不必追新3.11 是目前兼容性较好、第三方包支持完善的版本。很多 AI 底层库在 3.12/3.13 上还没完全跟上强制用新版反而会踩到一些奇怪的编译错误。2.3 Docker Desktop 与 Windows 容器Docker Desktop 是管理中间件最省心的工具Redis、Elasticsearch 这类服务用docker run一键拉起比在 Windows 上原生安装省太多事。安装 Docker Desktop 前一定要确保 WSL2 已经就绪因为 Docker Desktop 默认使用 WSL2 后端。安装 Docker Desktop 后打开 Settings - Resources - WSL Integration确保你用的 Ubuntu 发行版被勾选上了。这样在 WSL2 终端里直接执行docker ps也能访问到 Docker。拉取镜像时国内网络环境可能比较慢Docker 官方源经常超时。我一般建议先把镜像源配置成国内可用的加速器但不同加速源变动频繁这里就不写具体地址了。你只需知道 Docker Desktop 设置里的 Docker Engine 是一个 JSON 配置文件可以修改 registry-mirrors 来配置加速源即可。如果实在拉不动也可以考虑只拉必需镜像比如redis:7-alpine和elasticsearch:8.11.0体积相对小。需要注意 Elasticsearch 8 以后默认开启安全认证启动时如果不加-e discovery.typesingle-node参数单机模式下会一直报错。我常用的启动命令是docker run -d --name redis -p 6379:6379 redis:7-alpine docker run -d --name elasticsearch -p 9200:9200 -e discovery.typesingle-node -e xpack.security.enabledfalse elasticsearch:8.11.0加xpack.security.enabledfalse是为了本地开发省去用户名密码的配置但如果你的项目对安全有要求本地也不要关。2.4 AI 编程工具链的选择2026 年这个时间点AI 编程工具可选项非常丰富。微软系的 GitHub Copilot 在 VS Code 里集成度高适合不想折腾命令行的用户OpenAI 的 Codex 提供了 CLI 和桌面版能直接在终端里让 AI 读代码、改代码、跑测试自由度更大开源社区的 Continue 插件则可以自由对接各种后端模型包括本地部署的 Ollama。我个人目前的主力是 Codex 桌面版加 VS Code 里的 AI 插件组合。Codex 的优势是任务执行能力强你给它一个 Issue 描述它能自己规划步骤、修改文件、执行命令还能基于测试结果自我纠错。VS Code 插件则适合边写边补全的小粒度需求。在 Windows 上安装 Codex 有一个特别容易踩的坑安装完成后提示“Codex 无法在文件夹中运行”多半是因为当前终端环境变量没加载或者是 PowerShell 执行策略限制了脚本运行。解决方法是Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser然后重启终端。如果安装时卡在“未完成”状态通常是因为网络问题或杀毒软件拦截了临时文件创建把 Windows Defender 的实时防护暂时关掉再装一次就能解决。实操过程与核心环节实现3.1 基础工具链安装实录我把 Windows 侧的 Git 和终端工具安装过程记录下来。Git 安装包是傻瓜式的但有一些选项值得留神安装向导走到 Choosing the default editor 时如果系统里有 VS Code选择 Use Visual Studio Code as Gits default editor走到 Adjusting your PATH environment 时务必选 Git from the command line and also from 3rd-party software否则后续终端里 git 命令会找不到。Windows Terminal 可以从 Microsoft Store 直接安装。它的价值远大于普通 cmd 窗口多标签页、支持自定义配色、对 WSL2 和 PowerShell 的统一管理。安装后建议打开设置把默认终端改成 Windows Terminal默认配置文件改成 Ubuntu这样每次打开终端就是 WSL2 环境效率和体验都上一个台阶。在这一步完成后建议先验证一下整条基础链路是否通畅。在 WSL2 终端里执行git --version python3 --version docker --version三个命令都能正常输出版本号说明基础工具链已经就绪。3.2 本地大模型部署与模型选择本地大模型的价值在于隐私和成本。如果你写代码时需要把上下文发给云端 API等于把代码内容交给外部服务而本地模型跑在自己的机器上代码不出本机。虽然性能不如顶级云端模型但对日常辅助编程、代码补全、注释生成来说完全够用。我用的是 Ollama 来管理本地模型。安装非常方便在 Windows 上直接下载安装包或者命令行curl -fsSL https://ollama.com/install.sh | sh注意 Ollama 在 Windows 原生环境下也能跑但更推荐在 WSL2 里安装运行GPU 调用和 Docker 网络隔离都更好处理。模型选择上如果是 8GB 显存推荐 qwen2.5-coder:7b 或 codegemma:7b这两款专门针对代码场景做了优化。显存更大可以尝试 qwen2.5-coder:14b 或更大参数版本。拉取模型ollama pull qwen2.5-coder:7b拉取完成后测试一下ollama run qwen2.5-coder:7b 写一个Python函数计算斐波那契数列如果响应速度和输出质量都能接受说明本地模型部署成功。后续 VS Code 插件可以直接配置 Ollama 的 API 地址http://localhost:11434来调用本地模型。3.3 Codex 的完整安装与第一轮任务实测按照 Codex 官方文档安装步骤是在终端里安装 CLI 工具npm install -g openai/codex但这里有个坑直接全局安装要求本机先有 Node.js 版本 18 以上而且 npm 全局目录可能需要管理员权限。如果你的 Node.js 版本过旧建议先通过 nvm-windows 安装最新 LTS 版本。安装完成后需要登录 OpenAI 账号并配置 API Key。Codex 的配置默认存放在用户目录下文件名为.codex/config.toml。配置文件最小示例model gpt-5 api_key your-api-key如果你用的是国内渠道或第三方兼容 OpenAI API 的服务把base_url也配置进去即可。配置好之后进入一个已有的项目目录执行codex 解释一下这个项目的整体架构Codex 会读取项目关键文件然后给出架构说明。这只是初步验证。接下来我实际测试一下任务执行能力找一个 Python 项目要求它实现一个工具函数同时要求它跑测试codex 在src目录下新建一个utils.py实现从URL中提取域名和路径的功能并写对应的单元测试这时 Codex 会自己创建文件、写代码、生成测试文件并尝试执行测试命令。如果测试没通过它会读取报错信息重新修改直到测试通过。整个流程类似你在交办一个实习生区别是 Codex 的排查速度更快。需要提醒的是Codex 执行任务时会实际调用终端命令所以最好在 WSL2 或隔离项目目录里运行避免它误操作到系统文件。首次使用时你可以在配置里把sandbox_mode设为workspace-write让 Codex 只允许修改当前工作目录下的文件降低误操作风险。3.4 嵌入式环境下 C 编程初探的 AI 辅助配置搜热词里 嵌入式环境下C编程初探 是个高频搜索点。嵌入式开发传统上对 AI 工具接受度较低因为代码要跑在单片机上资源受限、寄存器操作多、对底层硬件依赖强。但这两年 AI 在嵌入式方向确实能帮上忙特别是代码生成和寄存器配置初始化方面。在 Windows 上做嵌入式 C 开发通常是 Keil MDK、STM32CubeIDE 或 VSCode GCC 工具链的组合。如果你想让 Codex 或 Copilot 辅助生成嵌入式 C 代码建议在项目里放一个明显的说明文件比如CLAUDE.md或.codex/instructions.md把芯片型号、外设资源、编译命令都写清楚。这样 AI 生成代码时才能更好地结合上下文。举个例子我在一个 STM32F103 项目里配置 Codex要求生成 GPIO 初始化的代码。Codex 如果不清楚芯片型号可能生成的是标准库函数而不是 HAL 库函数导致编译不过。而在 instructions 文件里说明使用 STM32 HAL 库芯片型号 STM32F103C8T6时钟频率 72MHz之后生成的代码基本可以直接用。另外一个心得是嵌入式代码的编译验证环节AI 工具在 Windows 上直接调 Keil 命令行比较麻烦我会选择在 WSL2 里配置 arm-none-eabi-gcc 工具链来做编译验证。这样 Codex 能快速通过命令行检查语法错误而最终的烧录仍然在 Windows 侧用 Keil 完成。3.5 Spring AI 与 Java 生态的 Windows 适配搜索词里 spring ai 也是一个高频词。Spring AI 是 Spring 生态里对接大模型 API 的官方框架相当于 Java 世界里的LangChain——它把 ChatCompletion、Embedding、Vector Store 这些概念都封装成了 Spring 风格的 API。在 Windows 上跑 Spring AI 有一个前置条件JDK 17 以上最好用 JDK 21 LTS 版本。安装完 JDK 后Spring AI 项目可以用 Spring Initializr 生成。生成时勾选 Spring Web 和 OpenAI 依赖pom.xml 里会自动加入 spring-ai-openai-spring-boot-starter。在application.yml里配置spring: ai: openai: api-key: your-api-key base-url: https://api.openai.com/v1 chat: options: model: gpt-5如果你希望把 OpenAI API 请求代理到本地 OllamaSpring AI 也支持通过配置base-url指向http://localhost:11434/v1。这样 Java 后端应用也能用上本地模型不依赖外网。Windows 下跑 Spring Boot 需要注意的一点是如果控制台输出中文乱码需要在启动参数里加-Dfile.encodingUTF-8否则 AI 返回的中文内容可能在 Windows 默认编码下显示异常。这个坑特别容易被忽略我第一次跑起来时看控制台一团乱码查了半天才发现是编码问题。3.6 Elasticsearch 与 Redis 在 Windows 下的启动方式Elasticsearch 和 Redis 在 Windows 上的原生安装体验都不算好。Redis 原作者不支持 Windows 版本Windows 下的 Redis 多为第三方移植Elasticsearch 虽然官方支持 Windows但安装后还要配 JDK、调内存参数比较麻烦。我强烈建议用 Docker Desktop 来跑这两个服务。Elasticsearch 启动命令前面已经给出。启动后可以通过curl http://localhost:9200验证返回 JSON 格式的集群信息即代表成功。有一个细节新版 Elasticsearch 对虚拟内存要求较高WSL2 环境下如果内存不够启动会报max virtual memory areas vm.max_map_count [65530] is too low。在 WSL2 里执行sudo sysctl -w vm.max_map_count262144但重启后这个配置会丢失建议把配置写入/etc/sysctl.confvm.max_map_count262144Redis 启动之后默认没有密码本地开发没问题但如果你的端口暴露在公网就一定要设置密码。用 Docker 启动时加上docker run -d --name redis -p 6379:6379 -e REDIS_PASSWORDyourpassword redis:7-alpine注意新版 Redis 镜像并不直接读取REDIS_PASSWORD环境变量更稳妥的方式是在映射配置文件中设置requirepass或者用命令行参数方式启动。我习惯用配置文件方式挂载这样后续改密码也方便。3.7 Windows 安全日志在环境排错中的特殊作用为什么要单独提安全日志因为搭建 AI 编程环境时很多安装未完成、终端闪退、Docker 启动失败的问题表面看是软件配置问题实际是被 Windows Defender 拦截了。查看方法打开事件查看器 - Windows 日志 - 安全。筛选事件 ID 为 4688进程创建和 4657注册表项修改再结合时间点能快速定位哪些进程被终止、哪些注册表项被修改。例如 Codex 安装卡住时我就在安全日志里看到了某个文件被 Defender 隔离的记录处理方式是给相关目录添加排除项。操作路径Windows 安全中心 - 病毒和威胁防护 - 管理设置 - 排除项 - 添加文件夹把 Miniconda、WSL 发行版目录、Codex 的缓存目录都加进去。这样能显著降低后续环境的莫名其妙失败概率。常见问题与排查技巧实录4.1 新建一个问题速查表下面是我在实际搭建过程中遇到过的典型问题基本覆盖了 Windows AI 编程环境从零搭建的大多数坑点。问题现象可能原因解决方案wsl --install 卡住不动Windows 版本过低或虚拟化未开启检查 BIOS 里 Intel VT-x/AMD-V 是否开启系统更新到最新Docker Desktop 启动报 WSL2 未安装WSL 内核版本过旧命令行执行wsl --update然后wsl --shutdown重启 Dockerconda 命令在 PowerShell 中不可用未初始化 conda执行conda init powershell重启终端Codex 安装未完成网络被墙或 Defender 拦截配置系统代理或临时关闭实时防护添加排除目录Codex 无法读取终端路径环境变量未刷新重启终端或在配置文件中指定绝对路径本地 Ollama 模型加载 OOM参数超过显存换更小的量化版本比如 q4_K_M 版本降低 context 长度Elasticsearch 启动后立刻退出vm.max_map_count 值过小在 WSL2 里设置vm.max_map_count262144Redis 中文数据乱码客户端编码问题启动参数加--raw或用支持 UTF-8 的客户端VS Code 里 AI 插件无响应Python 环境或 Node 环境未激活检查终端当前环境的 python/node 版本激活 conda 环境Windows 下编译 C 扩展包失败缺少 MSVC 编译工具安装 Visual Studio Build Tools勾选使用 C 的桌面开发端口被占用导致服务起不来之前有残留进程用netstat -ano | findstr :6379查看 PID然后 taskkill 杀掉4.2 定位问题的通用思路排查这类环境问题的通用思路我总结为三步。第一步搞清楚问题发生在哪一层。是硬件层、系统层、网络层还是应用层比如 Docker 起不来先用docker version看是客户端问题还是服务端问题如果服务端都连不上大概率是 WSL2 或驱动问题而不是镜像配置问题。第二步看日志。Windows 下看事件查看器WSL2 里看dmesg和/var/log/下的日志Docker 服务看docker logs。日志给出的报错信息往往比弹窗提示要精确得多。很多人懒得看日志直接去网上搜错误码实际上日志里已经写了具体原因。第三步最小化复现。把问题范围缩小到一个最简单的场景比如 Codex 报错就先用一个空目录执行codex hi如果能正常返回再逐步把项目代码加进去。这样能快速定位是工具本身问题还是项目代码干扰。4.3 Docker 与 WSL2 的联动排错细节Docker Desktop 和 WSL2 联动出问题时最常见的坑有两个。第一个是 WSL2 内存占用过高。Docker 默认使用 WSL2 的动态内存分配但有时候分配给 Docker 的内存会一直占着不放Windows 整体变卡。解决办法是编辑.wslconfig文件限制 WSL2 的最大内存[wsl2] memory8GB swap8GB放在用户目录下保存后执行wsl --shutdown重启生效。第二个是 Docker 镜像拉取不动。除了前面说的配置镜像加速源也可以在终端里设置代理export https_proxyhttp://127.0.0.1:7890但注意 Docker Desktop 有单独的代理设置在 Settings - Resources - Proxies 里和终端代理是独立的。如果你终端设置了代理但 Docker 没设置Docker 拉镜像还是会失败。两个地方都要看。这里不进一步展开代理工具相关的配置毕竟每个公司的网络环境不同。4.4 嵌入式 C 环境中的 AI 辅助陷阱嵌入式开发里用 AI 辅助有两点和普通开发很不一样。第一点是嵌入式代码经常直接操作寄存器AI 生成的代码如果基于错误的数据手册或过时的库函数编译时不会报错但运行时会出诡异问题。比如 GPIO 配置错了引脚模式串口没数据PWM 不输出。这类问题排查起来比语法错误费时得多。所以在给 AI 下指令时一定要把芯片型号、库版本、外设时钟频率交代清楚。第二点是嵌入式项目的编译工具链比较特殊。Keil 和 IAR 这类 IDE 的命令行接口并不暴露给终端Codex 无法直接执行编译命令。我目前的方案是让 Codex 生成纯 C 源代码文件然后在 Keil 里手动添加文件并编译。如果项目里已经有 CMake 构建脚本也可以让 Codex 直接调用 CMake 在 WSL2 里做交叉编译验证至少能提前发现大部分类型错误和语法错误。4.5 常见的 AI 生成内容质量问题最后聊聊 AI 生成代码本身的问题。不管用 Codex 还是 CopilotAI 生成内容在 Windows 环境下有四个高频质量问题。第一个是路径分隔符问题。AI 会生成/home/user/project这类 Linux 路径而你实际在 Windows 上跑需要改盘符。这个在 Codex 配置sandbox_mode为workspace-write时会有改善因为工具会感知当前工作目录。第二个是命令行不兼容问题。AI 可能建议你执行rm -rf或ls -la在 PowerShell 里直接报错。解决办法是统一用 WSL2 终端来跑这些命令或者在给 AI 的提示词里明确说明当前环境是 PowerShell。第三个是 Python 包依赖冲突。AI 在生成 requirements.txt 时可能指定了互相冲突的版本。建议在安装依赖时用 conda 环境隔离不要和系统 Python 混在一起。第四个是中文注释编码问题。AI 生成的中文注释在 Windows 上如果用 GBK 编码打开会乱码。我建议项目统一使用 UTF-8 编码并在项目根目录放一个.editorconfig文件声明root true [*] charset utf-8 end_of_line lf indent_style space indent_size 4 insert_final_newline true这样 VS Code 和 Git 都会遵循统一的编码规范乱码问题从根上解决。工具选型对比与我的取舍理由5.1 AI 编程助手横向对比2026 年主流 AI 编程助手大体上有这么几类云端集成型GitHub Copilot、CLI 任务型Codex、本地部署型Ollama Continue/VSCode 插件。我用表格做个对比工具部署方式优势劣势适用场景GitHub CopilotVS Code 插件补全快、集成高、老牌稳定功能局限于 IDE 内日常编码补全、写注释Codex CLI/桌面版终端工具能自主规划、执行命令、跑测试需要较清晰的指令重构、写测试、解决 IssueOllama Continue本地模型数据不出本机、无 API 费用模型能力弱于云端隐私敏感、离线开发Cursor独立 IDE结合编辑器与 AI 能力Windows 版偶有兼容问题偏好独立 IDE 的用户我的取舍是 Copilot 和 Codex 都装日常补全用 Copilot稍微复杂一点的任务丢给 Codex。本地模型作为备用和调试工具特别适合网络不稳定时使用。5.2 为什么选择 Codex 而非其他 CLI不是所有 AI CLI 工具都值得装。Codex 之所以被我作为主力核心原因有三个第一它是云端推理和本地执行结合得最自然的工具你不需要在本地配复杂的 Agent 框架第二它对 Windows/WSL2 的支持越来越好2026 年版本已经把常见路径问题处理得很好了第三它的任务规划能力在我实际测试中明显强于同类型工具能够稳定完成多文件修改和多步验证。如果你更偏好开源方案可以关注 Continue 加 Ollama 的路线或者国内其他 AI 编程助手但这类工具的配置复杂度会高一些模型效果也参差不齐。新手我还是建议从 Codex 或 Copilot 入手。5.3 Docker 容器化中间件的收益最后再展开说下为什么中间件用 Docker 而不是原生安装。以 Elasticsearch 为例Windows 原生安装需要手动下载 JDK、配置内存锁、处理关闭时的信号异常安装过程至少需要二十分钟出错的环节很多。Docker 版本一条命令拉起来环境隔离、版本切换都方便。Redis 更典型。Windows 原生的 Redis 是第三方移植版版本滞后而且没有被官方维护生产环境根本不敢用。Docker 版本直接用官方镜像行为与 Linux 完全一致本地开发和生产部署只差一个网络配置的区别。这套环境搭好之后日常开发体验会有明显变化Codex 在终端里帮你写代码跑测试Ollama 在本地随时待命处理不敏感的辅助任务Docker 里的 Redis 和 Elasticsearch 为本地应用提供后端服务Windows 文件系统通过 VS Code 直接编辑WSL2 里的命令行工具链负责编译和包管理。每一个环节之间都有清晰的边界。我在实际使用中有一个很深的体会AI 编程环境搭建这件事顺序比版本更重要。先把 WSL2 和 Docker 的地基打好再装 AI 工具过程会顺利很多。如果一上来就装 Codex后面各种底层问题会不断冒出来你会在排查环境问题上消耗大量时间反而不如最开始慢一点把每层依赖都理顺。这篇文章里写的每个步骤我都至少在两个朋友的机器上实际验证过按照这个顺序操作即使遇到问题也能定位到具体环节。最后再分享一个小技巧每次安装完一个大型依赖比如 Docker Desktop、Miniconda、WSL2 发行版都先重启一次终端再继续很多看起来莫名其妙的问题其实只是环境变量和系统服务还没刷新。