1. 为什么要在 Windows 上折腾本地 AI 编码助手很多人第一次听到本地部署 AI 编码助手脑子里冒出来的第一个念头是这不是自找麻烦吗云端那些现成的服务打开浏览器就能用响应快、模型大、还不用自己维护何必在本地搭一套我一开始也是这么想的直到有几次在没网的环境下改代码或者处理一些不方便往外传的项目文件时才真正意识到本地部署的价值。本地 AI 编码助手的核心吸引力说白了就三点数据不出本机、断网可用、长期零成本。你写的每一行代码、每一次提问都只在你自己电脑的内存和硬盘里流转不经过任何外部服务器。对于经常处理内部项目、或者单纯对隐私比较敏感的人来说这一点是云端服务给不了的。而且一旦部署好后续除了电费基本没有额外开销用多少都不心疼。那为什么偏偏是 Windows因为绝大多数人的主力开发机就是 Windows。虽然 Linux 和 macOS 在开发环境上有些天然优势但现实是很多人手里只有一台 Windows 笔记本或者台式机平时写代码、跑项目都在上面。所以把本地 AI 助手跑在 Windows 上是最贴近真实使用场景的选择。这套方案适合谁我觉得有三类人特别值得一试。第一类是预算有限但想长期用 AI 辅助编码的开发者不想每个月付订阅费第二类是对代码隐私有要求的人项目不方便上传到外部平台第三类是喜欢折腾、想搞明白大模型到底怎么跑起来的技术爱好者。如果你属于这三类中的任何一类那接下来的内容应该能帮到你。整个方案的技术栈其实不复杂核心就是Ollama VS Code这套组合。Ollama 负责在本地把大模型跑起来提供一个标准的接口VS Code 通过插件连上这个接口把 AI 能力直接嵌进你的编码流程里。中间不需要 Docker不需要复杂的容器编排也不需要独立显卡当然有显卡会更快。我实测下来一台 16GB 内存的普通 Windows 笔记本就能跑起来虽然速度比不上云端但日常补全、解释代码、写注释这些任务完全够用。提示本文面向的是从零开始的读者假设你之前没接触过 Ollama也没配过本地模型。每一步我都会说清楚为什么这么做以及容易在哪里卡住。2. 部署前的环境盘点与工具选型逻辑2.1 硬件门槛到底在哪里在动手之前先花两分钟确认一下你的机器能不能跑。本地部署大模型最吃的是内存其次是显卡显存CPU 反而没那么关键。原因很简单模型加载后要常驻内存参数量越大占用的内存越多。我整理了一个粗略的对照表方便你判断自己能跑多大的模型模型参数量量化后大致占用最低内存建议体验预期1.5B~2B1~2 GB8 GB能跑响应快但能力有限7B~8B4~6 GB16 GB日常编码辅助的甜点区14B8~10 GB24 GB能力更强速度明显变慢32B 及以上18 GB32 GB普通笔记本基本别想这里说的量化是个关键概念。原始模型用 16 位浮点数存储一个 7B 模型要占 14GB 左右。量化就是把它压缩成 4 位或 8 位整数体积能砍到三分之一甚至更少代价是精度略微下降。对编码辅助这种任务来说4 位量化的损失几乎感觉不到所以优先选带 Q4 标识的模型版本。显卡方面有独立显卡尤其是 N 卡会快很多因为模型推理可以放到 GPU 上跑。但这不是硬性要求Ollama 在纯 CPU 模式下也能工作只是生成速度会从每秒几十个 token 降到每秒几个 token。如果你只是偶尔用用CPU 模式也能接受。2.2 为什么选 Ollama 而不是别的方案本地跑模型的工具其实不少比如直接用手动编译的推理框架、各种带图形界面的整合包等等。我最终推荐 Ollama理由有这么几条。第一是安装简单。Ollama 在 Windows 上就是一个安装包双击、下一步、完成没有依赖地狱不用配 Python 环境不用装 CUDA 工具链。对新手来说这一点太重要了。第二是模型管理省心。它内置了模型仓库的拉取机制一条命令就能下载和切换模型版本管理、缓存清理都帮你做好了。你不需要自己去网上找模型文件、手动放到某个目录。第三是接口标准化。Ollama 启动后会在本地开一个 HTTP 服务默认端口 11434提供和主流云端接口兼容的调用方式。这意味着任何支持自定义接口的编辑器插件都能直接连上它不用为每个工具单独适配。第四是资源占用可控。它会在模型闲置一段时间后自动卸载释放内存不会一直占着你的机器。这一点在内存紧张的笔记本上尤其重要。至于 VS Code选它没什么悬念。它是目前插件生态最丰富的编辑器AI 辅助相关的插件选择多配置灵活而且免费。你不需要为了用 AI 助手而换一个不熟悉的开发环境。2.3 网络下载慢的应对思路这是国内用户最容易卡住的地方。Ollama 的安装包和模型文件默认都从境外服务器拉取速度可能非常慢甚至中途断掉。我的经验是分两步处理。安装包本身可以去官方渠道下载如果速度不理想找一些国内的开源镜像站点很多高校和企业都维护了同步镜像。下载的时候注意核对文件大小和校验值避免拿到不完整的包。模型文件的下载更麻烦因为动辄几个 GB。Ollama 支持通过环境变量指定镜像源你可以在系统环境变量里加一个OLLAMA_HOST或者相关的镜像配置项把拉取地址指向国内节点。具体做法是在系统属性 - 高级 - 环境变量里新建一个用户变量名字按你使用的镜像服务文档来填值填镜像地址。设置完记得重启终端让变量生效。注意镜像源地址会变动我不在这里写死具体地址你搜索Ollama 国内镜像就能找到当前可用的。设置前先确认镜像站是可信的别随便用一个来路不明的地址。如果镜像也不稳定还有一个笨办法但很有效找别人已经下载好的模型文件直接放到 Ollama 的模型目录里。Windows 下默认路径是C:\Users\你的用户名\.ollama\models把对应的文件按目录结构放进去Ollama 启动后就能识别省去下载环节。3. 从零到跑通Ollama 安装与模型拉取实操3.1 安装 Ollama 并验证服务下载好安装包后双击运行。安装过程没什么可说的一路默认即可。装完之后Ollama 会常驻在系统托盘里图标是一个小羊驼。这时候它已经在后台跑起来了本地服务默认监听127.0.0.1:11434。验证是否正常打开 PowerShell 或者 Windows Terminal输入ollama --version如果能看到版本号说明命令行工具已经就绪。接着测试服务是否在跑curl http://127.0.0.1:11434正常的话会返回一句Ollama is running。如果这条命令报错多半是服务没启动去托盘图标那里右键看看或者重新运行一次安装目录下的可执行文件。这里有个小坑要提醒Windows 防火墙有时会拦截本地回环之外的访问。如果你只是本机用127.0.0.1 不受影响但如果你想局域网内其他设备也能连就需要在防火墙里放行 11434 端口。放行的方法是进高级安全 Windows Defender 防火墙新建入站规则选端口填 11434允许连接。不过除非你确实有跨设备需求否则不建议开放安全第一。3.2 挑选适合编码的模型模型选择直接决定体验。我的建议是先从一个 7B 级别的编码专用模型开始跑顺了再考虑换更大的。为什么优先选编码专用模型因为通用模型虽然也能写代码但在代码补全、函数签名理解、报错解释这些任务上专门针对代码数据训练过的模型表现明显更好。它们对编程语言的语法结构、常见库的 API 更熟悉生成的代码更少出错。拉取模型的命令很简单ollama pull qwen2.5-coder:7b这条命令会下载一个 7B 参数的编码模型。下载过程中你会看到进度条速度取决于你的网络。如果卡住不动参考上一节的镜像配置。下载完成后用这条命令确认模型已经在本地ollama list列表里应该能看到刚拉下来的模型后面跟着它的大小和修改时间。3.3 第一次对话测试与参数调整模型就位后先做个最简单的对话测试ollama run qwen2.5-coder:7b进入交互模式后输入一句用 Python 写一个读取 CSV 并统计行数的函数看看它的反应。第一次加载模型会花几秒到几十秒取决于你的硬盘速度和内存大小之后就会快起来。如果响应速度让你难以忍受可以调整几个参数。Ollama 支持在运行时设置num_ctx上下文窗口大小和num_predict最大生成 token 数。上下文窗口越大模型能记住的对话内容越多但占用的内存也越多。对编码辅助来说4096 到 8192 的上下文通常够用。你可以在模型目录下创建一个 Modelfile把这些参数固化进去FROM qwen2.5-coder:7b PARAMETER num_ctx 8192 PARAMETER temperature 0.2然后用ollama create 你的模型名 -f Modelfile生成一个自定义版本。temperature设低一点0.1~0.3生成的代码会更稳定、更少胡编这对编码任务很重要。提示如果你发现模型回答到一半突然中断多半是num_predict太小了把它调大比如 2048 或 4096。4. 把 AI 接进 VS Code插件配置与联调4.1 选哪个插件来对接本地模型VS Code 里能连本地 Ollama 的插件有好几个我主要用两个方向一个是通用对话型的适合问问题、解释代码、生成片段另一个是补全型的能在你打字时给出行内建议。通用对话型插件里比较成熟的是 Continue 和 Cline 这类。它们都支持在配置里指定自定义的模型接口把地址指向http://127.0.0.1:11434就能用。补全型的话Continue 本身也带补全功能配置好之后可以同时满足两种需求省得装一堆插件。我个人的配置思路是一个插件搞定对话和补全减少维护成本。Continue 在这方面做得比较均衡配置文件是 JSON 格式改起来直观。安装插件就是常规操作在 VS Code 的扩展面板里搜名字点安装。装完可能需要重启一下编辑器。4.2 配置文件怎么写Continue 的配置文件默认在用户目录下的.continue文件夹里文件名是config.json。核心是models这一段你要告诉它去哪里找模型。一个可用的配置大概长这样{ models: [ { title: 本地编码模型, provider: ollama, model: qwen2.5-coder:7b, apiBase: http://127.0.0.1:11434 } ], tabAutocompleteModel: { title: 本地补全, provider: ollama, model: qwen2.5-coder:7b, apiBase: http://127.0.0.1:11434 } }这里provider填ollama插件就知道用 Ollama 的协议去通信。model字段必须和你ollama list里看到的名称完全一致大小写、冒号后面的标签都不能错否则会连不上。tabAutocompleteModel是专门管行内补全的可以指向同一个模型也可以指向一个更小的模型来加快速度。如果你觉得补全太慢影响打字就换一个 1.5B 或 2B 的小模型专门做补全对话还是用 7B 的。4.3 联调时最容易踩的三个坑第一个坑是端口对不上。Ollama 默认 11434但如果你之前改过配置或者装了别的服务占了端口就会连不上。排查方法是浏览器访问http://127.0.0.1:11434看有没有响应。第二个坑是模型名写错。这个特别常见比如你拉的是qwen2.5-coder:7b配置里写成了qwen2.5-coder少了标签插件就找不到。一定要以ollama list的输出为准原样复制。第三个坑是首次调用超时。模型第一次被调用时要加载进内存如果模型比较大可能要等十几秒。有些插件默认超时时间短会直接报错。解决办法是先在命令行里ollama run一次把模型预热加载之后再在插件里用就快了。注意如果你同时开了多个 AI 插件它们可能会抢着调用同一个模型导致内存吃紧。建议只保留一个主力插件其他的先禁用。5. 让本地助手真正好用的调优经验5.1 上下文管理比模型大小更重要很多人以为模型越大越好其实在本地部署的场景下上下文管理对体验的影响往往更大。原因在于本地内存有限上下文窗口开太大模型加载后占用飙升系统开始用虚拟内存速度断崖式下跌。我的做法是给不同任务配不同的上下文。日常补全用 2048 就够因为补全只看当前文件和附近几行解释代码、重构建议这种需要理解整个文件的再开到 8192。Continue 支持在配置里针对不同用途设置不同模型你可以建两个条目一个低上下文用于补全一个高上下文用于对话。另外及时清理对话历史也很关键。聊得越久历史越长占用的上下文越多响应越慢。完成一个任务后开新会话能明显感觉到速度回升。5.2 提示词要顺着本地模型的能力来本地 7B 模型的能力和云端大模型有差距提示词写得太随意它容易跑偏。我的经验是把要求拆细一次只让它做一件事。比如你想让它帮你重构一个函数不要直接说帮我优化这段代码而是分步来先让它解释这个函数做了什么再让它指出可能的性能问题最后让它给出改进版本。每一步的输出都更可控出错也容易定位。还有一个技巧是给它提供示例。本地模型对格式的遵循能力弱一些你在提示词里给一个输入输出的例子它模仿起来会准很多。这在生成特定格式的代码、写单元测试时特别有用。5.3 内存和速度的平衡术如果你机器内存不大又想跑 7B 模型可以试试这几个办法。一是关闭其他吃内存的程序。浏览器是内存大户开着一堆标签页再跑模型很容易爆内存。写代码时把不必要的标签页关掉能省出不少空间。二是用更小的量化版本。同样是 7BQ4 比 Q8 省一半内存速度也更快代价是精度略降。对编码辅助来说Q4 通常够用。三是设置模型闲置卸载时间。Ollama 有个OLLAMA_KEEP_ALIVE环境变量控制模型在闲置多久后从内存卸载。默认是 5 分钟你可以调短一点比如 1 分钟这样不写代码的时候内存能及时释放。设置方法是加一个系统环境变量值填1m。四是考虑 CPU 和 GPU 混合。如果你的显卡显存不够放下整个模型Ollama 会自动把一部分层放到 CPU 上跑。这种情况下速度介于纯 GPU 和纯 CPU 之间具体表现取决于你的硬件配比可以多试几次找到合适的模型大小。6. 常见故障的排查链路6.1 模型拉取卡住或报错现象是ollama pull执行后进度条长时间不动或者直接报网络错误。排查顺序是这样的先确认网络能通用浏览器访问一下镜像站再检查环境变量里的镜像地址有没有拼错如果都正常可能是镜像站临时抽风换个时间再试或者换一个镜像源。如果报的是磁盘空间不足去模型目录看看剩余空间。模型文件很大C 盘紧张的话可以通过设置OLLAMA_MODELS环境变量把模型目录挪到其他盘。6.2 插件连不上本地服务先在命令行确认服务活着curl http://127.0.0.1:11434。如果这条通问题就在插件配置如果不通问题在 Ollama 本身。插件这边重点检查三处apiBase地址对不对、model名称和ollama list是否一致、provider是不是ollama。改完配置记得重启 VS Code有些插件不会热加载配置。还有一种情况是端口被占用。用netstat -ano | findstr 11434看看有没有别的进程占着这个端口。如果有要么停掉那个进程要么改 Ollama 的监听端口改完插件配置也要同步改。6.3 生成速度突然变慢如果之前用得好好的突然变慢先看任务管理器里的内存占用。如果内存快满了系统在疯狂读写虚拟内存速度自然掉下来。这时候关掉一些程序或者重启一下 Ollama 服务释放内存。另一个可能是模型被换成了更大的。检查一下ollama list和插件配置确认用的还是原来那个模型。还有一种隐蔽的情况后台有多个 Ollama 实例在跑。有时候重复启动会导致端口冲突或者资源争抢。去任务管理器里看看有几个 ollama 进程多余的结束掉。7. 我实际用下来的几点体会这套本地 AI 编码助手我断断续续用了大半年最大的感受是它不会让你惊艳但会让你踏实。云端大模型确实更聪明回答更漂亮但本地这套东西胜在随时可用、完全可控。写代码写到一半想查个 API 用法不用切浏览器、不用等网络直接在编辑器里问一句就有答案这种流畅感是云端服务替代不了的。另一个体会是别指望它一次到位。本地模型的能力边界很明显复杂逻辑它容易绕晕长文件它容易丢上下文。我的用法是把它当成一个反应很快但经验一般的搭档让它干那些重复性高、逻辑简单的活比如写样板代码、补全函数签名、解释报错信息。真正需要深度思考的部分还是得自己来。最后分享一个我踩过的坑别在模型下载的时候干别的重活。有一次我一边拉模型一边编译项目结果内存被吃满系统卡到几乎无响应最后只能强制重启。下载模型是个内存和磁盘 IO 都很密集的过程最好挑机器空闲的时候做。如果你也想在 Windows 上搭一套自己的 AI 编码助手按上面的步骤走大概率一两个小时就能跑通。跑通之后别急着换大模型先用小模型把流程摸熟知道每个环节在干什么再根据实际需求升级。这套东西的价值不在于模型多大而在于它真正长在了你的工作流里。