1. 为什么我最终选择了本地AI编码助手这条路先说结论我在自己的Windows主力机上用Ollama加VS Code搭了一套完全离线、零订阅费的AI编码助手写代码时的补全、解释、重构、写单测这些活儿它都能接。整套方案不花一分钱不需要独立显卡也能跑起来代码不出本机。如果你是个平时用Windows写代码、对数据隐私比较在意、又不想每个月给云端助手交订阅费的开发者这套东西值得你花一个下午折腾一遍。我为什么非要走本地这条路起因很简单。我手头有几个项目涉及内部业务逻辑代码不能往外传但云端AI助手确实好用补全和解释能力能省不少时间。中间我试过好几个在线方案效果都不错但每次把代码粘进去心里都咯噔一下。后来我干脆花时间研究本地部署从最早的纯命令行玩模型到后来接进VS Code做成顺手的编码助手前后踩了不少坑也总结出一套相对稳定的配置。这里要先说清楚一个概念所谓“本地AI编码助手”本质上是两件事拼起来的。一件是本地推理引擎负责在你自己的机器上把大模型跑起来我选的是Ollama因为它对Windows支持好、安装简单、模型管理方便另一件是编辑器插件负责把编辑器和本地模型连起来让补全、对话、代码解释这些功能出现在你写代码的地方我用的是VS Code加Continue这类插件。两者一接一个离线的编码助手就成了。这套方案能做什么代码自动补全、选中一段代码让它解释、让它帮你重构、生成单元测试、根据注释写函数、排查报错这些日常高频操作都能覆盖。它不适合谁如果你追求的是云端顶级模型那种“什么都懂”的体验本地小模型在复杂推理上确实有差距这点我不藏着。但对日常编码的辅助来说本地模型完全够用而且响应速度取决于你的硬件配得好甚至比云端还快因为没有网络往返。下面我按“整体设计思路、核心细节、实操过程、问题排查”四块来讲每一步都告诉你为什么这么做参数怎么选坑在哪里。你照着抄作业就行。2. 整体方案设计与选型思路拆解2.1 为什么是Ollama而不是别的推理框架本地跑大模型Windows上能选的方案其实不少比如直接编译llama.cpp、用LM Studio、用text-generation-webui等等。我最后锁定Ollama理由有三条都是实际用下来才体会到的。第一是安装和模型管理的省心程度。Ollama在Windows上就是一个安装包双击装完命令行敲ollama run 模型名就能跑模型下载、版本管理、显存调度它都帮你处理了。相比之下llama.cpp你要自己编译、自己找量化模型文件、自己配参数对新手不友好。LM Studio有图形界面但它的模型格式和生态相对封闭接编辑器插件时不如Ollama通用。第二是API兼容性。Ollama默认在本地起一个HTTP服务端口11434接口格式兼容OpenAI的API规范。这一点极其关键因为绝大多数VS Code的AI插件都支持配置OpenAI兼容的接口你只要把地址指向http://localhost:11434插件就能直接用不需要为每个插件单独适配。这是Ollama能成为本地部署事实标准的核心原因。第三是模型生态活跃。Ollama的模型库更新很快主流的开源编码模型基本都能一键拉取比如Qwen系列的Coder版本、DeepSeek的Coder版本、CodeLlama等等。你不需要自己去HuggingFace找GGUF文件再手动导入省了大量折腾时间。提示Ollama的模型默认下载源在部分网络环境下速度较慢这是很多人卡在第一步的原因。后面实操部分我会讲怎么处理下载慢的问题但注意只讨论正常的网络优化思路不涉及任何特殊工具。2.2 编辑器插件怎么选Continue vs 其他VS Code上的AI编码插件我试过好几个。GitHub Copilot是云端的直接排除Cursor和Windsurf本质是独立的编辑器不是插件迁移成本高通义灵码、CodeGeeX这些国内插件也不错但部分功能依赖云端。最后我选的是Continue原因是它对本地模型的支持最彻底配置最透明。Continue的工作方式是在VS Code里提供侧边栏对话、行内补全、选中代码操作这几个入口它的配置文件是一个JSON你可以精确指定用哪个模型、走哪个接口、补全和对话分别用哪个模型。这种“配置即代码”的方式对我这种喜欢掌控细节的人很友好。你可以在配置里同时挂一个本地模型做补全、一个本地模型做对话甚至混合本地和云端灵活性很高。另一个值得提的是VS Code自带的语言功能比如C的IntelliSense、Python的Pylance这些是传统补全和AI补全是互补的不冲突。我的建议是两者都留着AI补全负责“猜你想写什么”语言服务器负责“告诉你语法对不对”配合起来体验最好。2.3 硬件门槛到底在哪显存、内存与模型尺寸的匹配这是最多人关心的问题我直接给结论再解释。本地跑编码模型显存不是必须的内存才是底线。没有独立显卡的机器靠CPU加内存也能跑只是速度慢一些。有显卡的机器显存越大能跑的模型越大、越快。模型尺寸和资源的关系我用一张表说清楚。这里说的“参数量”是模型的规模量化等级是指模型压缩的程度Q4是4位量化最常用平衡了体积和效果。模型参数量量化等级模型文件大小最低内存建议有独显时的显存建议适用场景1.5BQ4约1GB4GB2GB轻量补全老机器3BQ4约2GB8GB4GB日常补全入门首选7BQ4约4.5GB16GB6GB补全加对话主流选择14BQ4约9GB32GB10GB复杂重构体验更好32BQ4约20GB64GB24GB接近云端体验硬件要求高我的建议是8GB内存起步从3B模型开始玩16GB内存可以上7B这是甜点区32GB以上再考虑14B。为什么这么建议因为模型加载后除了模型本身占用的内存推理过程还需要额外的内存做KV缓存可以理解为模型思考时的草稿纸一般要预留模型大小的1到1.5倍。你内存不够模型加载到一半就崩了或者跑起来疯狂读写硬盘慢到没法用。注意这里说的内存是物理内存不是硬盘虚拟内存。虚拟内存能救急但速度差一个数量级体验很差。如果你的机器内存紧张优先加内存条这是性价比最高的升级。2.4 整体架构数据怎么流动把上面几块拼起来整套系统的数据流是这样的你在VS Code里敲代码Continue插件捕获你的输入和上下文通过HTTP请求发给本地的Ollama服务Ollama调用加载在内存里的模型做推理把结果返回给插件插件再把补全或回答显示在编辑器里。整个过程全部在本机完成没有任何数据离开你的电脑。这个架构的好处是解耦。推理引擎和编辑器插件是独立的你可以随时换模型、换插件互不影响。比如今天想试试新的编码模型只要ollama pull拉下来改一下Continue的配置就行编辑器那边不用动。这种灵活性是本地方案相比云端方案的一大优势。3. 核心细节解析与实操要点3.1 Ollama安装路径、端口与开机自启Ollama的Windows安装包从官网下载后双击默认装到用户目录下安装过程没什么可说的。但有几个细节我要提醒都是踩过坑的。安装路径默认装在C:\Users\你的用户名\AppData\Local\Programs\Ollama。模型文件默认存在C:\Users\你的用户名\.ollama\models。这个模型目录会越来越大一个7B模型就4.5GB几个模型下来几十GB。如果你的C盘空间紧张强烈建议在安装前就把模型目录改到大盘。改法是通过环境变量OLLAMA_MODELS指定新路径设置完重启Ollama服务生效。端口Ollama默认监听127.0.0.1:11434。这个端口只对本机开放外部访问不了安全性没问题。如果你发现11434被占用了可以通过环境变量OLLAMA_HOST改成别的端口比如127.0.0.1:11435。改完记得插件配置里的地址也要同步改。开机自启Ollama装完后默认会随系统启动在后台常驻。如果你不想让它一直占着内存可以在任务栏托盘图标右键退出或者去“启动应用”里禁用它需要时再手动启动。我的习惯是保持常驻因为模型加载有冷启动时间常驻的话第一次请求就能快速响应。实操心得安装完成后打开命令行敲ollama --version能输出版本号就说明装好了。再敲ollama list如果提示连接失败多半是服务没起来去开始菜单手动启动一下Ollama即可。3.2 模型选择编码场景下哪些模型值得拉模型是这套方案的核心选错了模型后面怎么调都别扭。我按使用场景给你分个类。补全场景补全要求低延迟模型越小越快。3B以下的模型适合做补全比如Qwen2.5-Coder的1.5B和3B版本响应快补全质量对日常代码够用。补全不需要模型有很强的推理能力它只需要根据上下文猜下一段代码小模型反而更合适。对话和重构场景这类任务需要模型理解你的意图、分析代码逻辑模型越大越好。7B是起步14B体验明显提升。DeepSeek-Coder和Qwen2.5-Coder的7B、14B版本都是这个场景的好选择。拉取模型的命令很简单比如ollama pull qwen2.5-coder:7b ollama pull deepseek-coder:6.7b拉完之后用ollama run 模型名可以进入交互模式测试敲几句话看看响应速度和回答质量满意了再往插件里配。注意模型名字里的:7b、:1.5b是标签代表不同的尺寸和量化版本。同一个模型可能有多个标签拉之前可以用ollama show 模型名看看详情。别拉错尺寸小内存机器拉个32B的模型加载直接失败。3.3 Continue插件配置一份能直接用的配置Continue装好后在VS Code侧边栏打开它会引导你配置模型。我建议直接编辑它的配置文件路径一般在C:\Users\你的用户名\.continue\config.json。下面是我用的一份配置你可以直接抄改改模型名就行。{ models: [ { title: 本地补全模型, provider: ollama, model: qwen2.5-coder:1.5b, apiBase: http://localhost:11434 }, { title: 本地对话模型, provider: ollama, model: qwen2.5-coder:7b, apiBase: http://localhost:11434 } ], tabAutocompleteModel: { title: 补全, provider: ollama, model: qwen2.5-coder:1.5b, apiBase: http://localhost:11434 }, embeddingsProvider: { provider: ollama, model: nomic-embed-text, apiBase: http://localhost:11434 } }这份配置里models数组定义了两个模型一个小的做补全一个大的做对话。tabAutocompleteModel专门指定行内补全用哪个模型这里用小模型保证速度。embeddingsProvider是做代码库索引用的需要额外拉一个嵌入模型nomic-embed-text它能把你的代码转成向量让AI能“检索”你的整个项目回答更贴合你的代码。实操心得补全和对话分开用不同尺寸的模型是这套方案体验好的关键。如果都用7B补全会明显卡顿如果都用1.5B对话质量又不够。分开配置各取所长。3.4 代码库索引让AI读懂你的整个项目Continue有个功能叫代码库索引开启后它会扫描你的项目文件用嵌入模型把代码转成向量存起来。之后你问问题时它会先检索相关代码片段再连同问题一起发给模型。这个功能对“这个函数在哪里被调用了”“这个模块是干嘛的”这类问题特别有用因为模型能看到真实的相关代码而不是靠猜。开启方式是在配置里加上embeddingsProvider然后在Continue的设置里启用索引。索引过程会消耗一些时间和内存大项目第一次索引可能要几分钟。索引完成后你问项目相关的问题回答质量会有明显提升。注意索引会读取你的项目文件虽然数据不出本机但如果你项目里有敏感配置文件建议在.continueignore里排除掉语法和.gitignore一样。这是个好习惯避免不必要的信息进入索引。4. 完整实操过程与关键环节实现4.1 从零开始的安装顺序我把整个流程按顺序列一遍你照着做就行。顺序很重要先装引擎再装插件避免插件找不到服务。第一步去Ollama官网下载Windows安装包双击安装。安装前先想好模型目录放哪如果C盘紧张先设好OLLAMA_MODELS环境变量再装。第二步安装完成后打开命令行验证ollama --version和ollama list。如果ollama list报连接错误去开始菜单启动Ollama等托盘图标出现再试。第三步拉取模型。先拉一个小的补全模型和一个大的对话模型再加一个嵌入模型。命令如下ollama pull qwen2.5-coder:1.5b ollama pull qwen2.5-coder:7b ollama pull nomic-embed-text第四步测试模型。用ollama run qwen2.5-coder:7b进入交互随便问个编程问题比如“用Python写一个快速排序”看它能不能正常回答。这一步是确认引擎没问题再往下走。第五步安装VS Code如果还没装去官网下载Windows版一路下一步。装完打开在扩展市场搜索Continue并安装。第六步配置Continue。打开Continue侧边栏按前面给的配置改config.json保存后重启VS Code。第七步测试补全和对话。新建一个代码文件敲几行代码看有没有补全提示打开Continue对话问个问题看有没有回答。都正常就大功告成了。4.2 模型下载慢的处理思路这是新手最容易卡住的地方。Ollama默认从官方源拉模型部分网络环境下速度很慢一个7B模型可能下几个小时。我的处理思路是换下载源Ollama支持通过环境变量指定镜像源。具体做法是设置环境变量OLLAMA_HOST指向国内可访问的镜像地址。不同时期可用的镜像地址会变你可以搜索“Ollama国内镜像源”找当前可用的。设置完重启Ollama服务再拉模型速度会快很多。另一个思路是手动下载模型文件再导入。Ollama的模型本质上是GGUF格式的文件加一个Modelfile描述。你可以从模型社区下载GGUF文件然后写一个Modelfile指向它用ollama create导入。这种方式适合网络实在拉不动的情况但步骤多一些。实操心得拉模型尽量在晚上或者网络空闲时段速度会好一些。另外拉大模型前先确认磁盘空间一个14B模型加缓存要十几个GB空间不够会中途失败。4.3 补全延迟的优化几个关键参数补全体验好不好延迟是关键。延迟高你敲代码时补全半天不出来反而干扰思路。我调过几个参数效果明显。模型尺寸这是最大的影响因素。1.5B的补全模型在普通机器上延迟能控制在几百毫秒7B就要一两秒体验差很多。所以补全一定用小模型。上下文长度补全时发给模型的上下文越长推理越慢。Continue默认会带一些上下文你可以在配置里限制补全的上下文行数比如只带光标前50行。这样既够模型判断又不至于太慢。量化等级Q4量化的模型比Q8快体积也小。补全场景对精度要求不高Q4完全够用。Ollama默认拉的模型多是Q4不用特别设置。硬件加速有N卡的机器Ollama会自动用CUDA加速速度提升明显。你可以在Ollama日志里看到是否用了GPU。如果没用到检查显卡驱动是不是最新的。4.4 对话模型的提示词技巧本地小模型的对话能力不如云端大模型但用对提示词能弥补不少。我的经验是把要求说具体。比如你想让它重构一段代码别说“帮我优化这段代码”而要说“把这段代码里的重复逻辑抽成一个函数保持原有行为不变用Python写”。越具体小模型越不容易跑偏。再比如让它解释代码可以说“逐行解释这段代码做了什么重点说明那个循环的作用”。给它一个明确的输出结构回答质量会好很多。Continue支持自定义提示词模板你可以在配置里预设几个常用的比如“解释代码”“生成测试”“找bug”用的时候一键调用省得每次手打。注意本地模型有上下文窗口限制一般是8K到32K token。你贴的代码太长会超出窗口模型会截断或报错。贴代码前先精简只贴相关部分。5. 常见问题与排查技巧实录5.1 模型加载失败或报错最常见的报错是内存不足。表现是ollama run时卡住然后报错退出或者系统变得极卡。这时候先看模型尺寸是不是超过了你的内存。7B模型Q4量化需要约6GB内存加缓存你只有8GB内存跑起来就很勉强。解决办法有两个换更小的模型比如从7B降到3B或者加内存。没有第三条路。虚拟内存能顶一下但速度慢到没法用。另一个报错是模型文件损坏通常是下载中断导致的。解决办法是ollama rm 模型名删掉重新拉。5.2 插件连不上Ollama表现是Continue里发消息一直转圈或者提示连接失败。排查顺序是这样的先在浏览器访问http://localhost:11434如果能看到Ollama的欢迎信息说明服务正常问题在插件配置如果访问不了说明服务没起来。服务没起来的话去开始菜单启动Ollama或者检查端口是不是被占用。端口被占用的话改OLLAMA_HOST环境变量换端口插件配置同步改。插件配置问题多半是apiBase地址写错了或者模型名和实际拉取的不一致。用ollama list确认模型名配置里一字不差地填。5.3 补全不触发或触发太频繁补全不触发先检查Continue的补全功能是不是开启了在设置里有个开关。再检查当前文件类型是不是被排除了Continue默认对某些文件类型不补全。触发太频繁表现为你打字时补全一直弹干扰输入。可以在配置里调补全的触发延迟比如设置成停止输入500毫秒后再触发而不是每敲一个字符就触发。这个参数在Continue的设置里能找到。5.4 常见问题速查表问题现象可能原因排查方法解决办法模型加载失败内存不足看模型大小和内存换小模型或加内存插件连不上服务未启动浏览器访问11434启动Ollama服务补全延迟高模型太大看补全用的模型换1.5B小模型下载模型慢网络源问题看下载速度换镜像源或手动导入对话答非所问提示词太模糊看提问方式把要求说具体索引不生效嵌入模型没拉看配置和模型列表拉nomic-embed-text端口冲突11434被占用看端口占用情况改OLLAMA_HOST回答被截断超出上下文窗口看贴的代码长度精简代码再问5.5 几个我踩过的坑第一个坑是模型目录没改C盘爆了。我一开始没注意拉了几个模型后C盘只剩几GB系统都卡了。后来把模型目录改到D盘重新拉了一遍。建议你装之前就规划好。第二个坑是补全和对话用同一个大模型。我一开始图省事都配的7B结果补全慢得要命敲代码时补全半天不出来体验极差。后来分开配置补全用1.5B瞬间流畅。第三个坑是忘了拉嵌入模型。Continue的代码库索引需要嵌入模型我没拉的时候索引功能一直报错查了半天才发现是缺模型。拉个nomic-embed-text就好了。第四个坑是提示词太随意。本地小模型理解能力有限我一开始问“这段代码有啥问题”它回答得很泛。后来改成“这段代码在并发场景下有没有线程安全问题如果有指出具体哪一行”回答就精准多了。5.6 性能调优的几个方向如果你觉得当前配置还不够快可以往这几个方向调。升级硬件内存加到32GB能上14B模型体验提升明显。有独显的话显存越大越好模型能全部放进显存速度比CPU快一个数量级。换更高效的模型同样是7B不同模型的推理速度不一样。一般来说专门为编码优化的模型在编码任务上效率更高。多试几个选响应快的。调整量化等级Q4比Q8快Q3比Q4快但质量下降。补全场景可以试试更激进的量化对话场景保持Q4。限制上下文补全时少带上下文对话时精简问题都能减少推理量提升速度。实操心得调优是个平衡游戏速度和质量要取舍。我的原则是补全优先速度对话优先质量。补全慢一点就干扰思路对话慢一点还能接受。6. 关于这套方案的一些个人体会搭完这套东西用了一段时间我最大的感受是本地AI编码助手的价值不在于替代云端而在于给你一个可控的选项。它可能没有云端顶级模型那么聪明但它完全属于你代码不出本机没有订阅费没有使用次数限制想怎么用就怎么用。对于处理敏感代码、或者单纯不想被订阅制绑住的开发者来说这个选项很有意义。另一个体会是硬件决定了体验上限。我一开始在一台8GB内存的老笔记本上折腾跑3B模型都费劲体验很差差点放弃。后来换到16GB内存的机器上跑7B才真正感受到本地助手的实用性。所以如果你打算认真用硬件投入是值得的尤其是内存。最后分享一个小技巧把常用的提示词存成Continue的自定义命令。比如我存了“解释选中代码”“为选中代码生成单元测试”“找出选中代码的潜在bug”三个命令用的时候选中代码右键调用比每次手打提示词快多了。这个功能在Continue的配置里可以自定义值得花十分钟设置一下。这套方案后续还能扩展比如接更多的模型做对比、把索引范围扩大到多个项目、甚至用本地模型做代码审查。但那是后话了先把基础跑通用起来再慢慢折腾。