1. 从 Copilot 到本地我为什么把补全请求切回自己机器GitHub Copilot 用起来确实顺手但用久了总会冒出几个绕不开的念头我写的这段业务逻辑是不是已经被传到某个云端了公司内网项目能不能用断网或者出差在高铁上补全是不是就直接废了这些疑问叠加起来就指向同一个方向——把 AI 编程助手搬回本地。本地部署 AI 编程助手说白了就是让代码补全和对话推理都跑在你自己的机器上代码数据不出本机模型选哪个、参数怎么调、什么时候开什么时候关全由你说了算。它最适合三类人对数据隐私敏感的后端/算法开发者、经常在无网或弱网环境写代码的人、以及想深度定制补全行为比如强制某种命名风格、限定框架版本的折腾型选手。我试过把日常主力项目从云端补全切到本地组合整体感受是补全质量确实有落差但“数据不出本机”带来的踏实感以及可以随手改配置的自主权是云端方案给不了的。这篇文章就围绕 Ollama Continue 这条个人开发者最常用的路线把安装、配置、断网验证、报错排查一步步写清楚。你不需要 GPU 服务器一台 16GB 内存 6GB 显存的普通开发机就能跑起来如果只有 CPU也能用只是响应会慢一些。下面所有命令和配置都可以直接复制改改模型名就能用。在开始之前先明确一点本文讲的“本地”是完全离线本地——模型权重和推理都在你自己的机器上补全请求发往http://localhost:11434不经过任何外部 API。这也是它和“私有化部署到公司内网服务器”的区别后者虽然数据也在内网但通常还需要联网下载模型或更新。个人开发者追求数据完全本地Ollama Continue 是最短路径。2. 前置准备Ollama 安装与代码模型拉取Ollama 是整个方案的推理底座它负责模型下载、加载和对外提供 HTTP 接口。Continue 则是编辑器里的插件负责把补全和对话请求转发给 Ollama。两者分工明确配置起来也不复杂。先说硬件门槛这决定了你能拉多大的模型。7B 级别的量化模型Q4_K_M在 8GB 显存上能跑得比较舒服常驻显存大约 5GB 出头如果只有 CPU16GB 内存也能跑 7B 量化版但单次补全可能要 3-5 秒体验会打折扣。3B 以下的模型对硬件友好很多普通轻薄本也能用代价是复杂上下文理解能力弱一些。我的建议是主力开发机优先上 7B应急或老机器用 1.5B-3B。安装 Ollama 在 macOS 和 Linux 上都是一条命令的事。macOS 直接去官网下载安装包或者用 Homebrewbrew install ollamaLinux 用官方脚本curl -fsSL https://ollama.com/install.sh | shWindows 用户下载安装包后Ollama 会作为后台服务运行。安装完成后先确认服务是否在监听默认端口 11434ollama serve如果这条命令提示端口已被占用说明服务已经在后台跑着了不用重复启动。接着拉取代码模型这里推荐 qwen2.5-coder:7b它在补全质量和响应速度上比较均衡ollama pull qwen2.5-coder:7b拉取完成后用ollama list确认模型已经在本地。如果显存紧张可以换更小的量化版本比如qwen2.5-coder:1.5b拉取命令一样只改模型名。拉取过程会从模型仓库下载权重文件这一步需要联网但下载完成后推理就完全离线了。这里有个容易踩的坑Ollama 默认只监听127.0.0.1如果你打算让同一局域网内的其他设备比如另一台笔记本也调用这个服务需要设置环境变量OLLAMA_HOST0.0.0.0再启动。个人单机使用保持默认即可反而更安全。模型拉好之后可以用一条 curl 命令快速验证服务是否正常curl http://localhost:11434/api/tags正常会返回一个 JSON里面包含你刚拉取的模型名。如果返回连接被拒绝说明 Ollama 服务没起来回到ollama serve那一步检查。这一步验证通过说明推理底座已经就绪接下来配置 Continue。3. Continue 配置config.yaml 与 settings.json 可复制片段Continue 是 VS Code 和 JetBrains 系列都能用的开源插件它的配置文件决定了补全和对话分别走哪个模型。新版 Continue 推荐用config.yaml旧版或部分场景仍用config.json两者字段含义一致只是格式不同。下面给出可直接复制的完整配置。先安装插件在 VS Code 扩展市场搜索 Continue安装后侧边栏会出现 Continue 面板。首次打开会提示登录或跳过选择跳过本地模式即可。然后找到配置文件路径通常是~/.continue/config.yamlmacOS/Linux或C:\Users\你的用户名\.continue\config.yamlWindows。如果文件不存在手动创建。# ~/.continue/config.yaml name: Local Copilot Config version: 0.0.1 schema: v1 models: # 补全模型走本地 Ollama负责 Tab 自动补全 - name: Qwen2.5 Coder 7B (Autocomplete) provider: ollama model: qwen2.5-coder:7b roles: - autocomplete apiBase: http://localhost:11434 # 对话模型同样走本地 Ollama负责 Chat 和 Edit - name: Qwen2.5 Coder 7B (Chat) provider: ollama model: qwen2.5-coder:7b roles: - chat - edit apiBase: http://localhost:11434 tabAutocompleteModel: title: Qwen2.5 Coder 7B provider: ollama model: qwen2.5-coder:7b apiBase: http://localhost:11434如果你更习惯 JSON 格式或者用的是旧版 Continue可以用下面这段config.json字段和上面一一对应{ models: [ { title: Qwen2.5 Coder 7B (Autocomplete), provider: ollama, model: qwen2.5-coder:7b, apiBase: http://localhost:11434, roles: [autocomplete] }, { title: Qwen2.5 Coder 7B (Chat), provider: ollama, model: qwen2.5-coder:7b, apiBase: http://localhost:11434, roles: [chat, edit] } ], tabAutocompleteModel: { title: Qwen2.5 Coder 7B, provider: ollama, model: qwen2.5-coder:7b, apiBase: http://localhost:11434 } }配置里三个关键字段必须写全provider填ollamamodel填你实际拉取的模型名要和ollama list里的一致apiBase填http://localhost:11434。这三件套缺一不可尤其是model名写错会直接导致请求失败。保存配置后在 VS Code 里按CtrlShiftPmacOS 为CmdShiftP打开命令面板执行Continue: Select Model分别把补全模型和对话模型切换成上面配置的本地模型。接着打开任意代码文件输入几行代码触发补全就能看到本地模型给出的建议了。如果你还想保留云端模型做复杂对话可以做成混合配置补全走本地 Ollama对话走云端。这样敏感代码的补全不出本机而复杂重构仍能借助云端大模型。配置方式是在models数组里再加一个云端模型把roles设为[chat, edit]本地模型只保留[autocomplete]。这种“补全本地化 对话云端化”的组合是很多开发者在过渡期的折中选择。4. 断网验证确认补全与对话真的走本地配置写完不代表真的生效必须做一次断网验证才能确认请求确实发往本地而不是偷偷走了云端。这一步很关键也是很多人配置完却不确定是否成功的地方。验证分三步。第一步确认 Ollama 服务正常返回模型列表curl http://localhost:11434/api/tags返回的 JSON 里应该能看到qwen2.5-coder:7b。如果这一步就失败说明服务没起来先解决服务问题再往下走。第二步确认补全请求命中了本地模型。打开一个代码文件输入几行代码触发补全然后在终端执行ollama ps如果看到qwen2.5-coder:7b处于运行状态说明补全请求确实打到了本地服务。这个命令是判断“补全是否走本地”最直接的证据比看日志还快。第三步做真正的断网测试。把机器的网络断开关闭 Wi-Fi 或拔掉网线然后重复上面的补全和对话操作。如果补全仍然能给出建议、Continue 面板里的对话仍然能返回结果说明整个链路完全离线数据没有出本机。这一步是本地部署的核心价值所在——断网可用意味着代码数据不可能被传到任何云端。对话验证也类似在 Continue 面板发送一条消息比如“帮我解释这段代码”观察是否由本地模型响应。如果断网状态下对话正常返回说明对话模型也走的是本地。如果断网后补全失效但对话正常或者反过来说明配置里某个角色的模型没指向本地回到配置文件检查roles和apiBase。这里有个细节Ollama 首次加载模型需要把权重读进内存会有几秒延迟断网测试时第一次补全可能稍慢属于正常现象。保持服务常驻不要频繁重启 Ollama可以避免反复冷启动。验证通过后你就拥有了一个完全离线的 AI 编程助手接下来就是日常使用和排错了。5. 常见报错排查401、local proxy failed、reading choices、OAuth本地部署最常见的几类报错基本都集中在连接和配置上。下面按真实报错信息逐条对照给出原因和解决步骤。401 Unauthorized这个报错通常出现在你误配了云端 provider 却填了本地地址或者反过来。Continue 在请求时如果 provider 和 apiBase 不匹配会返回 401。检查配置文件里provider是否为ollamaapiBase是否为http://localhost:11434。如果混用了云端模型确认云端那部分的 API Key 是否有效。本地 Ollama 本身不需要 Key出现 401 基本是 provider 配错。local proxy failed这个报错说明 Continue 尝试通过本地代理转发请求但失败了。常见原因是系统代理设置干扰了 localhost 请求或者 Ollama 服务没启动。解决步骤先确认ollama serve在运行再检查系统代理是否把localhost也代理了——本地地址应该走直连把localhost和127.0.0.1加入代理白名单。如果用的是公司网络确认防火墙没有拦截 11434 端口。Error reading choices / reading choices这个报错通常出现在对话请求返回格式不符合预期时根源往往是模型名写错或模型没拉取成功。检查ollama list里是否有配置中写的模型名注意大小写和冒号后的 tag 要完全一致。如果模型名对但依然报错尝试用 curl 直接请求 Ollama 的对话接口看返回是否正常curl http://localhost:11434/api/chat -d { model: qwen2.5-coder:7b, messages: [{role: user, content: hi}] }如果这条命令返回正常说明 Ollama 没问题问题在 Continue 配置如果这条也报错说明模型加载有问题重新拉取模型。OAuth / 登录相关报错Continue 首次使用可能提示登录如果你选择了云端账号登录插件会尝试走云端鉴权这和本地模式冲突。解决方式是跳过登录或者在设置里切换到本地模式。如果已经登录退出账号后重新以本地模式打开。本地模式下不需要任何账号所有请求都发往你配置的apiBase。除了这四类还有两个高频问题补全无响应和显存不足。补全无响应先查ollama ps看模型是否在运行再查apiBase端口是否和 Ollama 实际监听一致。显存不足OOM则换更小的模型或量化版本或者调低上下文长度。Ollama 可以通过环境变量OLLAMA_NUM_GPU控制 GPU 卸载层数显存不够时适当调低。排查的核心思路是分层定位先确认 Ollama 服务本身正常curl 能通再确认 Continue 配置正确provider/model/apiBase 三件套最后确认网络和代理没有干扰 localhost 请求。按这个顺序走大部分报错都能快速定位。6. 把判断力留在自己手里本地助手的长期用法走到这里你已经有了一个断网可用的本地 AI 编程助手。但本地部署的价值不只是“省了订阅费”或者“断网能用”更在于它把工具的选择权和数据的控制权交回给了你。云端助手是一个封闭的黑盒你不知道它把你的代码传到了哪里、用来做了什么本地助手则完全透明模型文件在你硬盘上请求日志你能看到配置随时能改。长期用下来有几个实用建议。第一模型不必追新追大7B 量化版对日常补全足够盲目上 32B 只会让响应变慢、显存吃紧。第二保持 Ollama 服务常驻避免每次冷启动的等待。第三定期用ollama list清理不用的模型模型文件动辄几个 GB攒多了很占空间。第四如果某天觉得本地补全质量不够可以临时切回云端做复杂重构但敏感项目的补全始终留在本地——这种混合策略比全盘依赖云端更可控。如果你希望进一步统一管理模型接入、在不同 provider 之间灵活切换可以了解下 TaoToken 的模型接入能力。它提供统一的 API 入口和密钥管理方便你在本地模型和云端模型之间做编排。相关入口API Keys 管理在 https://taotoken.net/api-keys 接入文档在 https://taotoken.net/doc 想直接体验模型对话可以走 https://taotoken.net/model-chat 长期编码或 Agent 场景可以看 Coding Planhttps://taotoken.net/coding-plan 。这些链接都带上了来源标记方便你按需取用。本地部署不是要彻底否定云端助手而是给你多一个选择什么时候用本地、什么时候用云端由你根据项目敏感度和网络环境来决定。把判断力留在自己手里才是这套方案真正的意义。