前阵子帮朋友从零装了一台 Windows 电脑的 AI 编程环境整个过程踩了不少坑也整理出几条可以直接照抄的路径。很多人觉得 AI 编程是 Linux 或 Mac 的专属其实在 Windows 下一样能把代码补全、本地模型推理、容器服务这三件事跑通关键是要把层级和顺序理清楚。这篇内容适合刚入手 Windows AI 开发的朋友也适合那些环境装到一半报错、不知道往哪查的人。我会尽量把每一个步骤背后的原因讲清楚而不是扔一堆命令让你复制完就结束。1. 先理清需求这套环境到底要解决什么问题1.1 我为什么坚持在 Windows 上搭而不是直接换系统每次聊 AI 编程环境总有人跟我说直接用 Linux 不就好了。我不否认 Linux 在服务端部署和某些底层开发里有天然优势但对大多数正在读这篇文章的人来说Windows 才是日常主力系统。你可能有 Windows 独占的办公软件、有需要 Windows 驱动的外设、有写了一半的项目甚至只是不想为了写几段代码把整个工作流换掉。Windows 现在的思路其实不是替代 Linux而是补齐 Linux 体验。Windows Subsystem for Linux 2通常叫 WSL2已经在很大程度上解决了Windows 上没有原生 Linux 内核这个老问题。Docker Desktop 也支持直接用 WSL2 作为后端意味着你在 Windows 上跑容器底层用的就是真正的 Linux 内核兼容性和在服务器上几乎没有差别。实测下来用 WSL2 跑 Python、跑 Ollama、跑 Elasticsearch 这些服务稳定度是够用的没必要为了显得专业强行切系统。我想说的是不要被AI 开发必须在 Linux 上这句话吓住。Windows 真正需要你花时间的其实是两件事一是把 WSL2、虚拟化这些基础开关打开二是把终端、包管理器这些入口工具配置顺手。这两件事做完了后面装什么都是水到渠成。1.2 环境全景图按功能拆成四层我在帮朋友装环境前会先画一张非常简单的分层图不写代码就写在备忘录里。这张图帮我避免了很多装到一半发现缺依赖的问题。具体来说我把这套环境分成四层。第一层是基础层包括 Windows 系统本身、终端工具、包管理器还有 WSL2 和虚拟化开关。这一层决定了你后面的操作顺不顺。第二层是语言运行时层包含 Python、Git、Node.js、C/C 工具链等这是绝大部分 AI 工程的基础依赖。第三层是 AI 工具层包括 VS Code、各种 AI 编程助手插件以及本地大模型推理引擎。这一层是离你写代码最近的部分。第四层是服务层也就是 Docker、Redis、Elasticsearch、PostgreSQL 这些中间件AI 项目要落地成真正可用的系统几乎离不开它们。这样拆的好处是排错的时候可以直接定位到某一层不用把整个系统翻个底朝天。比如 VS Code 里 AI 补全不生效问题大概率在第三层Docker 镜像拉不下来问题基本在第四层或网络层conda 命令找不到那就是第二层环境变量的问题。先有分层思维再动手去装效率会高很多。1.3 容易被忽略的决策点内存、磁盘与虚拟化开关很多教程第一句话就是去下载安装包但我建议你先按几个回车键检查一下机器状态。内存方面如果你打算在本地跑 7B 级别的大模型同时还要开着 Docker、VS Code 和浏览器16GB 内存会比较紧张32GB 会更从容一些。如果暂时只有 16GB也不用放弃选 3B 或 4B 的小模型或者只用云端 API仍然能把整条链路跑通。磁盘方面大模型文件通常好几个 GBDocker 镜像也会占用大量空间建议给系统盘预留 60GB 以上的剩余空间。另外要确认一下 CPU 虚拟化已经开启。在任务管理器里切到性能标签页能看到虚拟化这一项是不是已启用。如果没有启用需要重启电脑进 BIOS找到 Intel VT-x 或 AMD SVM 的选项打开。这个细节被很多人忽略等装 WSL2 或 Docker 的时候才发现起不来再回头折腾 BIOS非常耽误时间。顺便说一句Windows 安全中心和 Windows 安全日志建议保持打开状态。开发环境里经常要下载各种依赖包、跑开源工具安全日志能帮你快速定位是不是有异常程序在偷偷改你的环境变量这个习惯在团队协作或多人共用一个开发机器时尤其有用。2. 地基打好Windows 系统、终端和包管理器2.1 开箱前的系统检查这一节说几个我实际踩过的系统级坑尤其是刚从 Windows 10 升级到 Windows 11 的机器。首先确认 Windows 版本号不要太旧。WSL2 和 Docker Desktop 对系统版本有最低要求Windows 11 21H2 之后的版本基本都没问题Windows 10 则需要 1903 以上且必须开启 Hyper-V。与其被各种兼容性报错折腾不如直接在设置 → Windows 更新里把系统更新到最新。其次打开启用或关闭 Windows 功能面板勾选适用于 Linux 的 Windows 子系统和虚拟机平台两项。这里有一个常见误区很多人以为只需要勾第一项结果 WSL2 怎么也起不来其实第二项虚拟机平台才是 WSL2 内核正常运行的关键。如果电脑上装了 VMware 这类虚拟软件也要注意新版本的 VMware 和 WSL2 是否冲突建议安装前先查一下兼容性说明。做完系统检查后在 PowerShell 里执行wsl --install安装 WSL2装完重启。重启后执行wsl --set-default-version 2确保之后创建的发行版都默认跑在 WSL2 上。很多教程直接让你去装 Ubuntu但我更建议先切版本再装发行版顺序反了会导致后续 Linux 容器后端跑不了。2.2 一个好用的终端Windows Terminal 配置Windows 自带的 PowerShell 窗口说实话确实不太好看而且复制粘贴、多标签页的支持都比较弱。我建议直接装 Windows Terminal它在 Microsoft Store 里就能搜到也可以走 winget 安装。Windows Terminal 的好处是支持多标签页、可以自定义配色和字体、能把 PowerShell、WSL 的 Ubuntu、CMD 放在同一个窗口里切换。字体方面我推荐使用 Cascadia Code 或者 JetBrains Mono。这两个字体对开发者非常友好连字符0和O能明显区分代码里常见的箭头符号也能渲染成漂亮的连体字。设置方法是在 Windows Terminal 的 settings.json 里找到font face字段填上字体名。PowerShell 默认执行策略偏保守有时候跑脚本会提示系统上禁止运行脚本。你可以用管理员身份执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser允许本机脚本运行但要求从网上下载的脚本必须有签名。这样既方便日常开发又不至于把安全防线全关掉。顺便说一下这条命令是我给所有朋友装环境时都会顺手执行的因为它能避免后面装各种包管理器时出现莫名其妙的权限报错。2.3 winget 还是 ScoopWindows 上现在有两套很主流的软件包管理器一个是微软官方自带的 winget一个是社区维护的 Scoop。我的用法是系统级的软件用 winget 装开发类的绿色工具用 Scoop 装。winget 的优势是来源广、官方背景适合装 Chrome、Docker Desktop、Windows Terminal 这类需要写入系统配置的软件。Scoop 的优势是绿色免安装默认装到用户目录下不需要管理员权限最重要的是环境变量不会污染系统全局这对开发环境是很大的优点。Scoop 装完一个工具想卸载就删目录不留下任何残留非常适合反复折腾开发环境的场景。建议先装 Scoop。在 PowerShell 里执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser irm get.scoop.sh | iex然后再用 Scoop 装 git、nodejs、python 之类的基础工具。有人可能会问Python 我后面不是要用 Miniconda 管理吗这里用 Scoop 装的 Python 可以理解为系统里先有一个干净的 Python 备用而 Miniconda 负责创建独立的项目环境两者不冲突。如果你嫌烦也可以跳过 Scoop 直接到下一节但装了之后你会发现自己安装软件的速度快一大截。3. 语言运行时Python、Git、C/C 工具链3.1 Miniconda 完整安装我踩过的坑Python 环境的安装方式非常多但我始终推荐 Miniconda而不是 Anaconda。Anaconda 自带了几百个数据科学包看起来很省事实际上绝大多数你用不到反而会让环境变得臃肿conda 启动时间变长。Miniconda 只包含一个最基本的 conda 包管理器和 Python需要什么包再单独装干净利落。安装时我建议你记住这几个关键点第一去 Miniconda 官网下载 Windows 64 位安装包千万别在网上下到什么来路不明的增强版或一键整合包。第二安装路径不要有中文和空格比如D:\dev\miniconda3就很好不要装到C:\Program Files里否则后面有些第三方工具会因路径空格而找不到 Python。第三在安装向导的 Advanced Options 界面建议勾选Add Miniconda3 to my PATH environment variable这样可以避免后面手动配环境变量的麻烦。装完后打开终端先执行conda update -n base -c defaults conda把 conda 自身更新到最新。然后建议设置默认不激活 base 环境因为很多新手打开终端发现命令提示符前面多了个(base)会以为是异常状态conda config --set auto_activate_base false这样你的终端就不会默认进入 base 环境需要哪个项目环境就手动激活哪个逻辑更清晰。如果遇到 conda 下载慢的问题可以根据你所在网络环境选择官方认可或可访问的镜像源来配置配置命令类似conda config --add channels ...但注意不要使用来路不明的第三方源安全性更重要。3.2 Git 安装与全局配置Git 在 Windows 上的安装非常简单下载 Git for Windows 安装包一路默认即可。但装完后的全局配置才是重点很多人跳过这一步后面提交代码时弹出一堆提示还不知道怎么回事。安装完成后先在终端里执行git config --global user.name 你的名字 git config --global user.email 你的邮箱这两个配置会写入提交记录里建议和你的代码托管平台账号保持一致。然后是换行符处理Windows 和 Linux 的换行符不一样Git 默认会把仓库里的文件按 LF 存储、检出到工作区时按 CRLF这个行为适合纯 Windows 用户。如果你经常跨平台开发可以设置core.autocrlf input避免一堆warning: LF will be replaced by CRLF的警告。再补充一个 Windows 下 Git 的常见报错克隆仓库时提示fatal: unsafe repository。这是因为 Git 出于安全考虑拒绝操作属于其他所有者的目录。如果这个目录是你自己创建的可以用git config --global --add safe.directory 路径来添加白名单。这个报错我在接手旧项目的目录时经常遇到很多人以为仓库坏了其实只是一行命令的事。3.3 如果你还要做嵌入式或底层开发顺着热词里提到的嵌入式环境下C编程初探多说一句。如果你打算搞嵌入式开发、单片机程序或者只是想在 Windows 上练习 C 语言那你需要的不光是 Python还要有一套 C/C 编译环境。Windows 下 C 语言编程环境的搭建通常有两种路径一种是用 Visual Studio 官方自带的 MSVC 编译器适合做 Windows 桌面开发和部分嵌入式工具链的场景另一种是安装 MinGW-w64它更轻量配合 VS Code 就能完成编译调试。我个人的建议是如果只是临时跑跑 C 语言代码装 MinGW-w64 就够了因为它不占用太多空间也不需要打开庞大的 IDE。如果是正经做嵌入式开发后续可能需要对接特定芯片厂商的 IDE 和 SDK那就不要折腾 MinGW 了直接装 Visual Studio Community 或者厂商提供的工具链会更省事。另外在做嵌入式这类工业场景的开发时AI 编程工具也能派上用场。比如根据结构化描述生成一段 PLC 或嵌入式代码的雏形再用厂商工具链去验证和修正能够节省不少搭框架的时间。但这里有一条底线工业场景下的代码不能直接信任 AI 生成的结果必须经过严格的测试和电气安全审查AI 在这里的角色是提效工具不是决策者。4. AI 编程工具链IDE、智能补全与 Agent 模式4.1 VS Code 基础配置让编辑器先好用起来AI 编程环境里VS Code 可能是最核心的工作台。装好 VS Code 之后先别急着装各种花哨的主题先把基础配置做对。我建议先安装这些扩展Python、Pylance、GitLens、Docker、Remote - WSL、Remote - SSH还有一个 C/C 扩展如果你要写 C 语言。安装扩展有一个小技巧如果用 VS Code 打开的是 WSL 里的目录记得在 WSL 环境里再装一遍扩展因为 WSL 和 Windows 本地的扩展是隔离的。你可以在 VS Code 左下角看到WSL: Ubuntu的连接状态这时候扩展面板里会自动显示适用于 WSL 的扩展不要装错到 Windows 端。接下来在 VS Code 设置里我用的是这样一份 settings.json{ editor.formatOnSave: true, editor.fontFamily: Cascadia Code, Consolas, Courier New, monospace, editor.fontSize: 14, files.autoSave: afterDelay, python.defaultInterpreterPath: ${workspaceFolder}/.venv/bin/python, python.analysis.autoImportCompletions: true, terminal.integrated.defaultProfile.windows: Ubuntu (WSL), workbench.colorTheme: Default Dark }我在实际使用中发现terminal.integrated.defaultProfile.windows设为 Ubuntu (WSL) 这个配置特别值得推荐。它能让 VS Code 的终端默认打开 WSL 的 Linux shell这样你在 Windows 里写代码、在 Linux 环境里跑命令一气呵成。很多教程在配置环境时一会儿让你用 PowerShell 敲命令一会儿又切到 WSL 里非常乱问题就出在这一步没有提前设置好。4.2 在 IDE 里接入 AI 编程助手配置要点当前主流的 AI 编程助手大致分两类一类是云端服务比如大家耳熟能详的 GitHub Copilot、OpenAI Codex另一类是本地模型方案比如在 Ollama 里跑一个开源模型再通过 Continue 或 Cline 这类插件接入 VS Code。我个人的看法是两者不冲突完全可以同时使用云端助手负责高质量补全本地模型负责处理一些敏感代码和离线场景。云端 AI 编程助手通常要求你有一个开发者平台的账号可能提供付费订阅或免费额度具体以官方最新政策为准。安装方式一般是访问官方安装页面下载对应你操作系统的客户端或 IDE 插件安装完成后用账号登录。这里插一句很多 Windows 用户问Codex 安装一直未完成或ChatGPT 桌面版安装总是失败我遇到过的情况多数集中在三类原因一是下载的安装包不完整二是系统版本不满足要求三是安装时没有以管理员身份运行。建议先检查 Windows 更新然后清理掉%LOCALAPPDATA%\Programs下对应软件的残留目录再以管理员身份重新安装官方最新安装包。接入之后你会注意到AI 助手的补全质量特别依赖你当前打开的代码上下文。一个很实用的技巧是写完函数名和参数列表后在函数内部写一行注释说清楚这个函数要做什么AI 再给的补全会明显更准确。比如在 Python 里写def fetch_user_orders(user_id):然后注释# 查询用户最新10条订单并按时间倒序返回补全结果通常非常靠谱。这比什么都不写直接让 AI 猜要高效得多。4.3 开源替代方案Continue、Cline 怎么选如果你不想依赖云端服务或者公司有数据安全要求本地模型插件会是很好的补充。VS Code 里目前比较常见的两个开源方案是 Continue 和 Cline。Continue 的定位是本地模型对话 代码补全它支持对接 Ollama、LM Studio 等本地推理后端也能对接 OpenAI 兼容接口。Cline 则更像一个全自动编程 Agent它会读取你的项目目录自己规划修改步骤然后调用模型生成代码并直接写进文件。两者我都试过我的感受是Continue 更适合日常写代码时的问答和补全Cline 更适合那种帮我重构这个模块或给这个项目加一个新功能的粗粒度任务。配置本地插件时一个容易踩的坑是模型加载速度。如果用 CPU 跑 7B 模型补全响应时间会明显变长对话体验很一般。我的建议是先确保 Ollama 模型已经加载成功再在插件设置里把 API 地址指向http://127.0.0.1:11434。如果本地模型响应太慢可以给插件设置一个较长的超时时间避免频繁报错。这里要特别强调无论用哪种 AI 工具生成出来的代码一定要自己过一遍尤其要关注安全漏洞和业务边界问题AI 代码只是初稿不是终稿。5. 本地大模型把推理能力放到自己的电脑上5.1 本地部署到底有没有必要很多人一上来就问我要不要在自己电脑上部署一个像 GPT-4 那样的大模型。这个问题的答案取决于你的使用场景我大概分三个维度来说。隐私维度如果你处理的是一些不适合传到第三方平台的内部文档、代码片段本地部署几乎是唯一选择。离线维度出差路上、网络受限环境里本地模型依然可以工作这是云端接口做不到的。成本维度云端 API 按 token 收费长期高频调用是一笔不小的开支本地模型免费跑只是会占用电力和硬件资源。反过来说如果你只是写代码时做补全和问答云端助手体验更好本地模型的代码能力在一些复杂任务上还达不到付费服务的水平。本地部署大模型有个概念你一定要先搞懂量化。意思是把模型参数的精度从 16 位或 32 位降到 8 位或 4 位牺牲一点点精度换取更小的体积和更快的推理速度。我们常说的 7B 模型未量化版本大概要 14GB 空间4 位量化后只要 4GB 左右普通配置的电脑也能跑得动。5.2 Ollama 安装与模型下载本地推理引擎里我目前用得最顺手的还是 Ollama。它不是最简单或最快的但它的跨平台支持和模型管理方式最省心Windows 安装版也做得很成熟。去 Ollama 官网下载 Windows 安装包安装完成后Ollama 会作为一个后台服务常驻运行默认监听在11434端口。之后你就可以在终端里用一条命令拉取模型ollama pull qwen2.5:7b这里我通常选通义千问的 Qwen 系列它对中文的理解和生成质量在开源模型里属于第一梯队而且和 OLLAMA 的适配度很高。你也可以试试 Llama 3.2、Mistral 等模型各有各的侧重点。第一次拉取模型会下载几个 GB 的文件具体时间取决于你的网络带宽和所选的模型源。模型下载完成后关键一步是确认推理用的设备。执行ollama ps如果输出里能看到 GPU 那一列显示显存占用说明模型已经在用 GPU 跑。如果只在 CPU 上运行响应速度会慢不少。NVIDIA 显卡用户要先去官网装 CUDA 驱动目前 Ollama 对 NVIDIA GPU 支持得最好。Intel 或 AMD 核显用户也别灰心Ollama 较新版本已经在尝试支持更多硬件平台但如果你不想折腾驱动直接用 CPU 跑 3B 或 4B 的小模型日常问答也完全能接受。5.3 CPU 与 GPU 推理的取舍及 OpenVINO 思路这里顺便响应一下热词里提到的 OpenVINO 相关技术。OpenVINO 是 Intel 推出的推理优化工具包主要用于在 Intel CPU、核显和 NPU 上加速 AI 推理。它不仅能优化 Ollama 这类大模型推理在很多桌面软件里也有实际应用比如音频处理软件 Audacity 的 AI 降噪效果就是用类似的推理引擎在本地跑的。如果你想在自己电脑上做更多边缘推理实验OpenVINO 是一个非常值得了解的加速方案。我的建议是如果你有 NVIDIA 显卡优先让 Ollama 走 GPU 推理这是当前体验最好的方案。如果你的设备只是普通办公本那就选小模型加 CPU 推理同时注意控制模型上下文长度避免一次给模型塞太多历史对话导致响应变慢。最简单的做法是在调用模型时设置num_ctx参数比如4096这样既保留足够的对话能力又不会无限制吃内存。6. 容器化周边Docker、Redis、Elasticsearch6.1 Windows 上装 Docker 的正确姿势AI 应用要真正跑起来基本离不开容器化技术。Docker 在 Windows 上的安装方式和在 Linux 上完全不一样很多新手第一次装就卡在启动环节。我的建议是直接装 Docker Desktop用 WSL2 作为后端。相比老版本依赖 Hyper-V 的方案WSL2 后端的启动速度更快、内存占用更可控和日常开发环境也更和谐。安装前确保你已经在第 2 章完成了 WSL2 的设置然后下载 Docker Desktop 安装包运行安装选择Use WSL 2 instead of Hyper-V。安装完成后打开 Docker Desktop在设置里找到 Resources → WSL Integration确保你常用的那个 WSL 发行版是被勾选启用的。如果你在 Docker Desktop 启动时看到 unexpected WSL error 之类的提示绝大多数情况是 WSL 内核太旧或 glibc 版本不匹配。解决办法是打开 Windows 终端执行wsl --update wsl --shutdown然后再重新启动 Docker Desktop。这个命令组合帮我解决了很多次 Docker 启动问题。6.2 用 Docker 跑 Redis 和 ElasticsearchAI 应用里Redis 常用于做缓存和消息队列Elasticsearch 则常用于日志检索和知识库存储。在 Windows 上我强烈不建议直接下载这两个软件的 Windows 安装版因为 Redis 的 Windows 版已经很久不维护了Elasticsearch 的 Windows 版虽然可以跑但系统服务注册和环境变量配置都很麻烦。用 Docker 容器跑反而是最干净、最接近生产环境的方式。先跑一个 Redisdocker run -d --name redis-local -p 6379:6379 -v redis-data:/data redis:7 --appendonly yes这里用了一个命名卷redis-data来持久化数据--appendonly yes开启 AOF 持久化这样容器即使删了重建数据也不会丢。再跑一个 Elasticsearchdocker run -d --name es-local -p 9200:9200 -e discovery.typesingle-node -e ES_JAVA_OPTS-Xms512m -Xmx512m -v es-data:/usr/share/elasticsearch/data docker.elastic.co/elasticsearch/elasticsearch:8.14.0注意这里我把 JVM 堆内存限制到了 512MB不然 Elasticsearch 默认会吃掉机器一大半内存。然后输入http://localhost:9200看返回的 JSON 信息能出现 cluster_name 等内容就说明启动成功。新版 Elasticsearch 默认开启安全性配置如果你只是本地开发可以在启动命令里设置xpack.security.enabledfalse临时关闭认证但要记住这只是本地调试的做法生产环境绝对不能这样配。6.3 给 AI 应用挂个后端数据库除了 Redis 和 Elasticsearch很多 AI 项目还需要一个传统的关系型数据库来存用户数据、订单记录或业务元数据。Windows 下同样建议用容器跑 PostgreSQL 或 MySQL命令和跑 Redis 类似主要是换镜像名、换端口、设置账号密码这几个参数。以 PostgreSQL 为例docker run -d --name pg-local -p 5432:5432 -e POSTGRES_USERdev -e POSTGRES_PASSWORDdev123 -v pg-data:/var/lib/postgresql/data postgres:16如果你用的是 Java 技术栈可以留意一下 Spring AI 这个框架它把大模型调用、向量数据库、提示词模板这些 AI 开发中的常见组件做了统一抽象。后面你如果想在现有 Java 项目里集成 AI 功能不用自己封装 API 调用逻辑直接用 Spring AI 的接口会更顺手。到了这一步你的 Windows 机器已经具备了一个相当完整的 AI 开发环境有代码编辑器、有 AI 助手、有本地模型、有容器化的中间件接下来就可以真正写一个业务示例了。7. 从零到跑通一个本地 AI 问答服务的完整实操7.1 项目需求与目录设计理论知识讲再多不如实际跑通一个最小案例来得踏实。这一节我会带你从零做一个本地 AI 问答服务前端不用直接用命令行和浏览器测试后端用 Python 的 FastAPI 暴露一个 HTTP 接口内部调用 Ollama 加载的本地模型。项目目录结构很简单ai-local-demo/ ├── app.py # FastAPI 主文件 ├── requirements.txt # Python 依赖清单 └── .venv/ # 虚拟环境之所以用 FastAPI是因为它足够轻量写接口只需要十几行代码而且自带 Swagger 文档浏览器打开就能调试对新手非常友好。7.2 分步执行记录先创建 Python 虚拟环境并安装依赖。如果你用的是 Miniconda也可以先用 conda 创建环境conda create -n ai-local python3.11 -y conda activate ai-local pip install fastapi uvicorn requests接着确保 Ollama 服务和模型都已经就绪在终端执行ollama serve ollama list确认qwen2.5:7b已经在列表里。然后开始写app.py代码不算长核心就是调用本地模型接口并返回结果。7.3 完整代码与验证结果下面是我写好的app.py你可以直接复制使用import json import requests from fastapi import FastAPI from pydantic import BaseModel app FastAPI() OLLAMA_URL http://127.0.0.1:11434/api/generate MODEL_NAME qwen2.5:7b class ChatRequest(BaseModel): message: str class ChatResponse(BaseModel): reply: str app.post(/chat, response_modelChatResponse) def chat(req: ChatRequest): payload { model: MODEL_NAME, prompt: req.message, stream: False, options: { num_ctx: 4096, temperature: 0.7 } } resp requests.post(OLLAMA_URL, jsonpayload, timeout120) resp.raise_for_status() data resp.json() return ChatResponse(replydata.get(response, ).strip()) app.get(/health) def health(): return {status: ok}写完代码后启动服务uvicorn app:app --host 0.0.0.0 --port 8000然后另开一个终端用 curl 测试一下curl.exe -X POST http://127.0.0.1:8000/chat -H Content-Type: application/json -d {\message\:\用一句话介绍你自己\}正常的情况下几秒到几十秒后你会收到一段 JSON 响应里面就是本地模型生成的回答。整个过程里VS Code 的 AI 助手其实帮了我不少忙比如它帮我补齐了 FastAPI 里 Pydantic 模型的部分写法让我不用频繁查文档。实测下来7B 模型在 16GB 内存、无独立显卡的电脑上回答速度大约是一秒两三个字日常问答够用但如果要批量处理文本建议还是换 GPU 机器或调用云端 API。8. 常见问题与排查技巧实录8.1 安装类问题速查这一节我整理了一份自己实际遇到过的问题清单按照问题现象 → 排查方向 → 解决办法的格式写成表格方便你快速定位。问题现象常见原因解决办法Codex / ChatGPT 客户端安装未完成安装包下载不完整、系统版本过低、权限不足更新 Windows以管理员身份重新运行官方安装包conda 命令找不到Miniconda 未加入 PATH 或未执行 conda init重开终端或手动执行conda init powershellVS Code 扩展安装不上网络策略限制或安装的是旧版本检查网络能否访问官方扩展市场升级 VS CodeGit 提示 unsafe repositoryGit 安全策略限制了目录所有者执行git config --global --add safe.directory 路径PowerShell 禁止运行脚本执行策略默认限制用管理员执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser这里的核心思路是绝大多数安装失败都不是某个软件坏了而是环境前提没满足。你只要把系统版本、网络可达性、管理员权限这三件事排查一遍能解决 80% 的安装问题。8.2 运行类问题排查Docker 起不来、Ollama API 超时、Elasticsearch 启动失败这三个问题在 Windows 上出现的频率最高。Docker 方面很多朋友装完之后点 Docker Desktop 图标半天没反应或者报了一个 Unexcepted WSL error。不用急着重装先执行wsl --update和wsl --shutdown然后重启 Docker Desktop。如果还不行就去 Docker Desktop 设置里把 Experimental Features 关掉再试。WSL2 内存占用过高也是个经典问题可以在C:\Users\你的用户名\.wslconfig文件里设置内存上限[wsl2] memory6GB swap2GBOllama 方面如果调用 API 等了很久却返回超时先确认服务有没有真正启动再确认模型是不是还在加载。首次加载模型时需要把模型文件读入内存耗时较长之后再次请求就会快很多。如果你连续多次请求响应速度又变慢了说明num_ctx设置得过大或者系统内存不够了检查任务管理器后适当降低参数。Elasticsearch 启动失败通常和内存有关。除了在命令里设置ES_JAVA_OPTS之外如果是在 WSL 内部直接跑 Elasticsearch可能还需要提高系统的vm.max_map_count值否则会报 max virtual memory areas vm.max_map_count [65530] is too low。解决办法是在 WSL 终端执行sudo sysctl -w vm.max_map_count262144这个配置重启后可能失效你也可以写成持久化配置但本地开发环境临时执行一下就够了。8.3 环境类问题别让变量冲突拖垮你说实话很多环境坏了的问题真正原因都在环境变量冲突上。Windows 的 PATH 全局变量是系统级和用户级叠加的如果你在多个目录里装过不同版本的 Python、Git、Node.js前面路径的版本总会优先生效于是经常出现我明明装了最新版运行起来还是老版本的诡异现象。我的建议是尽量让工具安装在少数的几个目录里并且用包管理器统一管理。Scoop 默认装在用户目录下的scoop文件夹Miniconda 装在D:\dev\miniconda3WSL 里再装一套 Linux 工具链三者互不干扰。排查环境变量问题时在 PowerShell 里执行$env:Path -split ;把输出结果从头到尾看一遍一眼就能发现是否有多余、重复或缺失的路径。这个方法花费一分钟但能省下你后面几小时的折腾时间。环境搭好之后我最深的一点体会是工具的安装其实只占两成时间剩下八成都在解决环境变量的冲突和版本兼容问题。所以别指望一步到位先把最小路径跑通再慢慢补自己想要的部分。后续我会继续在 Windows 上试更多的本地模型和 AI Agent 玩法如果你有更好的方案欢迎一起交流。