本地AI编程助手搭建指南：从Ollama到Continue的完整实践

坦白说我是被一条额度提示赶出舒适区的。标题里提到的那款商业编码终端我连续用了两周多日常补全、问答、改单测都顺手直到配额归零的那一刻才发现自己所有的操作习惯都绑在一个订阅上。那天我正在改一个历史遗留接口提示弹出来的瞬间我脑子里不是抱怨而是一个一直没认真对待的问题如果不靠这个订阅本地到底能不能接住我的日常工作答案是可以但不是开箱即用。这篇内容我会用完整的实操顺序讲清楚本地AI编程助手需要哪几个组件、代码模型怎么选、显存怎么算、Ollama和Continue怎么配、我实测以后哪些参数真正影响体验以及踩过的几类翻车现场。适合被额度逼来的朋友也适合本来就想把编码辅助完全本地化的开发者。1. 额度归零之后本地替代到底在替代什么1.1 被一条额度提示赶下线的那天当时我手头的活并不复杂一个老接口要加超时熔断代码大概两百行。午后我照常选中一段函数让助手重构函数签名结果工具直接进入只读模式多问一句都不回。那一整天我像一个突然被收回工作台的人——习惯的反馈链路断了效率掉得比预想中还快。事后复盘问题不在工具能力而在订阅制的“断供一刀切”。商业编码终端的计费方式决定了它会在某个节点突然停摆而这个节点往往卡在最不凑巧的联调时间。于是我开始认真评估本地替代。我的要求很朴素不依赖额度、不把代码传出去、日常编码辅助不能被掐断。1.2 能接住的工作和接不住的工作先说结论本地方案不是同一个场景的平替而是切换了一种工作模式。我把自己过去一周的开发任务拆开统计大约六成到七成的编码辅助需求本地模型接得住剩下三成是跨多文件的架构性改动本地模型会露怯这部分需要另外的兜底策略。场景本地模型体验说明自动补全很好填充式补全14B档位已经接近商用体验单文件重构可用把范围收窄到函数级效果会明显提升生成单元测试可用给出同类先例后输出稳定度很高仓库范围问答一般依赖嵌入质量跨多文件时容易漏信息多步代理任务弱本地模型的工具调用稳定性低于云端这个表是我半个月实测的体感不是跑benchmark得出的结论。特别想说清楚的是如果你指望本地模型复刻商业终端那种“丢一个需求下去它自己翻仓库、改文件、跑命令行”的代理式体验现阶段大概率会失望。但当工作拆成“补全一段代码、改一个函数、生成一批测试”这种原子操作时本地模型的可用度比我预想高很多。1.3 隐私和不依赖网络是隐藏红利额度之外本地方案有个很少被当卖点但实际很值钱的特性代码不出机器。我在一个小团队做内部工具很多脚本涉及内部数据格式往云端传始终有心理负担。本地跑起来之后这个顾虑直接消失。另外断网也能干活出差在高铁上改代码不再需要赌网络质量。还有一个容易被忽略的点没有按token计费的心理压力。云端方案写提示词时总会下意识省token本地模型不会你可以把需求背景写详细、把上下游函数贴进去反正不花钱。这个心态差别对输出质量的影响实测非常明显。2. 整体架构三个组件和一条兼容管线2.1 为什么拆成三段而不是一个全家桶本地AI编程助手在我这里由三块独立拼装推理引擎负责把模型跑起来并对外提供HTTP接口模型权重负责实际生成代码IDE插件负责把补全和对话接进编辑器。三层互不绑定每一层都可以单独换。打个比方这像自己攒电脑而不是买整机引擎是机箱电源模型是CPU显卡插件是显示器键盘。任何一层不满意都能单独升级替换成本几乎为零。我见过有人只看重某个IDE插件结果被绑定在它的默认云端模型上也有人下了个模型就直接在终端里聊完全没意识到这个模型其实可以供给整个开发工具链使用。拆成三段的意义在于生态里的工具大多默认说同一种“语言”——兼容OpenAI约定的接口于是引擎暴露一个本地端口插件把地址指向它两边就通了。后面配置时会看到整个核心配置其实就是这一行地址。2.2 Ollama与LM Studio怎么选推理引擎可选的不多实际用下来主要就是两个引擎形态适合谁备注Ollama命令行常驻服务喜欢脚本化、愿意写配置的人轻量、支持Modelfile自定义、生态文档全LM Studio图形界面不想碰命令行的新手模型管理方便内置聊天窗口llama.cpp server底层二进制喜欢折腾的进阶玩家可控性最强但默认没有配套服务管理我的默认推荐是Ollama。原因很实际它能常驻后台能通过环境变量调调度能用Modelfile固化参数而且插件社区对它支持最全。LM Studio也很稳图形界面确实友好但它更偏“单机软件”的形态做服务端和多并发时会别扭一点。如果你只是想先体验一晚装LM Studio下个模型就能聊天想长期作为开发基础设施直接上Ollama。2.3 OpenAI兼容端点本地服务的对外语言Ollama安装完成后会监听11434端口除了原生的/api/chat接口它还提供/v1/chat/completions——也就是OpenAI兼容协议的路径。这件事是整套方案的枢纽。我用一个curl命令验证过curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer whatever \ -d { model: qwen2.5-coder:7b, messages: [{role: user, content: 用Go写一个并发安全的计数器}], temperature: 0.2 }看到正常返回JSON说明这个本地服务已经可以被任何“支持自定义OpenAI地址”的工具调用。API Key随便填一个非空字符串都行因为请求不会出本机。接下来不管我接VS Code的插件、JetBrains插件还是终端里的AI工具指到http://127.0.0.1:11434/v1就完事。这个通用性是整套方案最大的自由度来源。3. 模型选型先算显存账再动手3.1 现在值得关注的代码模型清单模型选择决定了体验上限。当前这个时间点我实测过且还愿意推荐的本地模型集中在下面几档模型参数量常用量化近似权重占用定位qwen2.5-coder:3b3BQ4_K_M约2.6GB低配机器补全专用qwen2.5-coder:7b7BQ4_K_M约4.7GB入门主力qwen2.5-coder:14b14BQ4_K_M约9GB性价比标杆qwen2.5-coder:32b32BQ4_K_M约20GB高端玩家/接近商用deepseek-coder-v2-lite16B MoEQ4_K_M约9GB通用代码任务Qwen的Coder系列在中文和英文代码上都稳是我目前的主力。DeepSeek-Coder-V2-Lite是MoE结构16B总参数但激活参数少生成速度有优势不过某些边缘case不如Qwen14B扎实。还有Codestral 22B这类模型能力不差但授权条款限制商用团队使用前先看清再决定。3.2 量化、上下文与显存的三角关系选模型只看参数量是新手最容易踩的坑。本地部署要同时算三笔账权重大小、上下文长度、量化精度。量化以Q4_K_M最常见意思是把每个权重压到4bit左右7B模型权重从14GB降到约4.7GB。Q8量化精度更高但体积翻倍对代码生成这类任务Q4和Q8的体验差距远小于体积差距所以我默认推荐Q4。显存里除了权重还要给KV Cache留地方——上下文越长KV越大大约是几GB随上下文规模变化。16GB显存的显卡跑14B Q4、开16K上下文是比较舒服的组合再往上就容易碰到溢出。如果显存不够Ollama会把一部分层放到CPU上跑。这种做法能救急但速度断崖式下降。我的建议是宁可换小一档模型也不要让GPU和CPU混跑混跑时的延迟会让人完全不想用。3.3 不同硬件配置的推荐组合按我周围几个开发者的实际机器给一套可以直接抄的选型只有核显或纯CPU7B Q4 能用但补全偏慢3B做补全会流畅很多。这个配置适合对话和临时改文件不适合做主力补全。8GB显卡3B做自动补全7B Q4做对话和单文件编辑。亲测这是小显存的最优解。16GB显卡直接上14B Q4补全和对话都在非常可用的范围这是当前性价比最高的组合。24GB及以上32B Q4可以当作日常主力能明显感觉到推理深度上了一个台阶。Mac统一内存16GB内存跑7B很稳14B略挣扎32GB内存以上可以尝试32B Q4Metal加速实测比同价位Windows机器顺手。别迷信最大参数。在我的实测里14B是本地代码场景质量和速度的黄金点7B是底线3B只适合补全。选型时先看显存再谈参数是这条线最核心的原则。4. 搭建流程Ollama安装、模型拉取与参数配置4.1 安装OllamaOllama的安装没有太多花活。macOS和Linux一条命令curl -fsSL https://ollama.com/install.sh | shWindows直接去官网下载安装包双击装完即可。安装完成先验证版本ollama --versionLinux下Ollama会注册成一个systemd服务默认随开机启动。这一步很多人忽略导致重启后记不起来要手动把服务拉起来。4.2 拉取模型并用API自检装好后拉取模型ollama pull qwen2.5-coder:7b ollama pull qwen2.5-coder:14b ollama list拉取时间看网络和镜像大小7B大约4.7GB14B大约9GB建议磁盘预留足够空间。模型就位后先用命令行做冒烟测试ollama run qwen2.5-coder:7b 写一个Python二分查找函数能正常输出代码再去确认服务接口curl http://127.0.0.1:11434/api/tags返回一串JSON列表说明本地API已经活了。到这一步本地推理能力已经具备接下来要做的是把它变成日常工具。4.3 服务参数与Modelfile自定义Ollama默认参数对交互式聊天够用但作为后台服务需要微调。我常用的几个环境变量# 允许局域网访问方便多设备共用一台渲染服务 export OLLAMA_HOST0.0.0.0:11434 # 模型常驻内存避免反复从磁盘加载 export OLLAMA_KEEP_ALIVE-1 # 允许并发请求配合IDE补全会更流畅 export OLLAMA_NUM_PARALLEL4Linux下通过sudo systemctl edit ollama写入环境变量Windows则在系统环境变量里配置。这里最实用的是OLLAMA_KEEP_ALIVE-1它让模型加载后一直留在显存否则每次补全都要重新加载那个等待时间会逼疯人。如果还想固化模型参数可以写一个ModelfileFROM qwen2.5-coder:7b PARAMETER num_ctx 16384 PARAMETER temperature 0.2然后执行ollama create my-coder -f Modelfile ollama run my-coder这样创建出来的模型会带上参数默认值。需要注意API调用里的参数会覆盖Modelfile里的值所以两边要保持一致。5. IDE接入与工作流Continue完整配置5.1 安装与配置文件IDE插件我选Continue理由很直接它支持多模型并存、配置是纯YAML、对Ollama原生友好。插件装好之后打开配置文件路径一般在用户目录下的~/.continue/config.yaml也可以在项目根目录放一份项目级的.continue/config.yaml覆盖全局配置。我的完整配置供参考schema: v1 name: Local Assistant models: - name: 本地Qwen Coder 7B provider: ollama model: qwen2.5-coder:7b contextLength: 32768 roles: - chat - edit - autocomplete completionOptions: temperature: 0.2 topP: 0.9 apiBase: http://127.0.0.1:11434 embeddingsProvider: provider: ollama model: nomic-embed-text apiBase: http://127.0.0.1:11434保存后Continue会自动重载。如果你用的是14B模型把model:改成对应标签就行。关键点有两个roles要包含autocomplete否则不会启用补全apiBase必须是本机地址别漏了端口。5.2 自动补全为什么这是本地模型最顺手的事本地方案里体验最接近商业助手的就是自动补全核心原因是填充式补全Fill-in-the-Middle的机制。和聊天不同补全时模型拿到的不是整段对话而是光标前面的一段代码和光标后面的一段代码它只负责生成中间被删掉的那一段。这个机制不需要理解整个项目只需要局部的代码模式对7B、14B这种规模的模型负担小得多。实际体验下来14B在中型函数补全上的准确率相当高尤其是样板代码、CRUD接口、重复性模式基本能做到指哪打哪。补全的使用习惯也要调整多在函数中部触发多按Tab接受不要每次让它从空文件生成整段逻辑。如果在一行行注释后面强行触发补全模型容易跑偏因为它会把注释当成生成内容的锚点。5.3 对话、内联编辑与代码库上下文除了补全聊天和内联编辑是另外两个高频功能。聊天窗口里可以用codebase把当前仓库纳入上下文前提是配置了嵌入模型。我配置里用的nomic-embed-text是一个轻量嵌入模型占用很低先在命令行拉取ollama pull nomic-embed-text有了嵌入模型Continue会把当前文件和相关文件做向量化聊天时可以引用“和你改动相关的代码”。不过实测下来仓库问答对本地模型来说容易漏细节尤其仓库很大的时候。我的做法是在项目根目录配置.continueignore把node_modules、dist、build这类目录排除掉减少噪音。内联编辑比整文件重写靠谱。选中一个函数让模型改逻辑比让它重写整个文件稳定得多。本地模型对“改动范围”很敏感范围越小输出越贴合预期。5.4 需要一点代理能力时Cline/Roo Code的配置思路Continue能把补全和对话做好但如果你想要代理式体验——让模型自己翻文件、执行命令、改完再验证——可以再装一个Cline或Roo Code插件它们同样支持配置Ollama为后端。配置思路和Continue一致在插件设置里选自定义OpenAI兼容端点填http://127.0.0.1:11434/v1。但我要泼一盆冷水本地模型在代理模式下稳定性一般。模型要输出规范的工具调用JSON还要在多轮工具调用里不跑偏这超出了7B、14B模型的舒适区。如果你非要试把一次任务的工具调用次数限制在十步以内关闭并行工具调用优先用计划模式。真到了让它连跑十步工具的时候大概率你会切回手写。6. 从能跑到好用实测调参记录6.1 决定体验的四个旋钮搭建完成后真正拉开体验差距的是参数调整。我实测最影响日常感受的有四个参数推荐值影响温度0.2代码场景要低太高会胡写top_p0.9配合温度限制采样范围num_ctx16384或32768决定能“看见”多少上下文keep_alive-1模型常驻显存避免加载等待温度这个参数最容易被忽视。聊天模型的推荐温度是0.7、0.8但代码生成不适合温度0.2左右能明显减少缩进错乱和语法错误。如果遇到模型总在同一个地方反复横跳可以把温度再降到0.1试试。上下文长度是另一个双刃剑。开得越大模型能看到越多代码但显存占用和生成延迟都会上升。7B模型开32K会明显变慢我最终用的是16K既能看到大文件骨架又不至于拖慢速度。6.2 实测速度与质量参考不同硬件上的速度差异非常大我测过的几组参考值3B Q4在8GB显卡上补全约60到100 token/秒聊天约30到50流畅。7B Q4在16GB显卡上补全约40到60聊天约20到30日常完全可用。14B Q4在16GB显卡上聊天约15到25补全约25到40这是我认为的体验甜点。32B Q4在24GB显卡上聊天约10到15能感觉到模型更聪明但生成偏慢。纯CPU跑7B只有2到5 token/秒基本只能对话用。这些数字不是benchmark只是我机器上的真实体感不同硬件会有浮动。看完数字你大概能理解为什么我一直强调14B是黄金点——它的推理深度足够应付绝大多数日常编码任务速度还能维持在手感不错的区间。6.3 使用习惯比模型参数重要调参只能解决一半问题另一半在使用习惯。本地模型不像顶级云端模型那样能自己补全你语焉不详的需求它非常依赖你把任务说清楚。我总结了几条实测有效的习惯第一拆小任务。别让7B一次性生成五十行拆成两三个函数分别生成再合起来质量会稳定很多。第二提供既有代码作为锚点。把当前函数贴进对话说“在原有逻辑上加一个重试”比只丢一句“给这个模块加重试”效果好得多。第三明确硬约束。说“不要引入新的第三方依赖”比说“写得规范一点”有用本地模型对约束词很敏感。第四生成前先让模型列计划。一问一答确认方案后再改代码本地模型在计划模式下的跑偏率明显低于直接生成。还有一个容易被忽略的习惯让模型写测试来自我验证。本地模型生成代码后附一个最小测试函数跑一遍就能发现幻觉问题这个闭环能帮你过滤掉大量无效生成。6.4 混合兜底策略不超过额度也能接住大活本地方案能覆盖日常但总有几个时刻需要更强模型跨二十个文件的架构重构、新框架不熟悉、要一次性打包处理一个复杂需求。这种时候我采用混合策略——在Continue配置里加一个云端模型条目- name: 云端大模型 provider: openai model: 某云端模型名 apiKey: ${API_KEY} apiBase: https://api.example.com/v1平时默认用的还是本地模型只有遇到硬骨头时在Continue模型选择器里切到云端按量付费问完就切回来。这种策略的好处是费用极低又保住了额度归零时的底线。商业终端的订阅确实好用但混合方案让主动权回到了我自己手里。7. 踩坑汇总五个翻车瞬间与排查链路7.1 补全永远在复读上一行现象光标停在空行按Tab触发补全模型输出的还是上一行代码反复循环。排查链路先看模型是否支持填充式补全格式Qwen Coder原生支持但某些通用模型不支持再看温度是否偏高温度0.6以上很容易让模型选择最稳妥的重复动作最后确认配置里roles包含autocomplete。我最后定位到的问题是温度被全局配置带到了0.7改成0.2后复读现象基本消失。7.2 import幻觉与不存在的API现象模型在一个用requests的旧项目里生成新代码却自动import了httpx或者在一个纯Python脚本里堂而皇之引入pandas。排查链路这通常不是模型抽风而是它没有拿到当前项目的依赖背景。先看对话里是否用codebase提供了仓库上下文再看提示词里有没有做依赖约束。修复方式是明确写一句“该项目已使用xxx库只允许使用这些库”或者把当前文件的import区块贴进对话作为锚点。实测后者最有效。7.3 长文件上下文爆掉后开始胡说现象在一个几千行的文件里编辑模型突然引用一个不存在的类名或者把无关函数接在一起。排查链路这是上下文溢出的典型表现。模型默认可能只有4096上下文超出部分被截断于是它根据残片“脑补”。看Ollama日志会出现上下文长度相关提示。修复方式修改Modelfile把num_ctx提到16384或32768或者在Continue里缩小选中范围只把当前函数及其调用链贴进对话。不要试图让模型看一整本小说。7.4 缩进和引号错乱现象生成出来的代码逻辑对但格式乱尤其在Python和嵌套JSON里。排查链路优先怀疑温度。温度偏高时采样噪声会导致空格和引号不稳定。我实测把温度固定在0.1到0.2之间这类问题大幅减少。另外注意编辑器本身的缩进设置——如果项目用4空格但模型被训练数据带偏成2空格接受后跑一遍格式化工具如Prettier或black就能统一。这类问题是配置层面能解决的不涉及换模型。7.5 代理模式里的“瞎指挥”现象Cline或Roo Code模式下模型连续调用工具但方向完全错误——让它改A文件它跑去安装一个不存在的包然后陷入循环。排查链路先看工具调用格式是否正确。本地模型在长对话中容易忘记“函数调用”的JSON格式越到后面越容易输出自然语言冒充工具调用。再看上下文沟通是否足够清晰很多循环是因为初始任务描述含糊。修复方式限制工具调用次数开启计划模式要求每一步都先说明意图再动手。如果模型陷入循环超过三轮直接停掉切回Continue对话拿到方案再做。踩过这些坑之后我最大的体会是本地AI编程助手的价值不在于跟顶级云端模型比“谁的代码更聪明”而在于它把编码辅助这件事变成了一种不会被额度掐断的基础设施。我现在的工作流是本地14B做日常补全和单文件编辑遇到架构难题切云端大模型问一轮隐私敏感的任务全程本地。配额压力消失了代码还是我的代码工具链也还在自己手里。这套方案不一定适合所有人但如果你也正在那个“额度用完、工作停摆”的时刻给它一个晚上值得。