1. Copilot 换成本地模型，卡在哪一步
Copilot 能换成本地吗？能，而且换完之后你的代码补全、对话问答、仓库级检索都可以跑在自己的机器上，敏感代码不出内网。但真正动手时，多数人会卡在三个地方：一是本地模型跑起来了，VS Code 里却连不上；二是每个插件都要单独填一遍 API 地址和 Key，换台机器就得重配；三是补全延迟高、上下文短，用两天就退回 Copilot。
这篇聚焦一个更省事的思路：用 TaoToken 作为统一的 Key/API 通道，把本地大模型和云端模型都收敛到同一套配置里，再通过 VS Code 的 Continue 插件接入。这样你只需要维护一份 settings.json 骨架，本地模型走本地地址，需要更强推理时切到统一通道，不用在多个插件之间反复粘贴 Key。
适合谁看：已经装过 Ollama 或准备装、想把 Copilot 替换掉、又不想被一堆 API Key 管理拖住的开发者。下面从环境准备讲到可复制的配置、连通性验证，再到常见报错排查，每一步都能直接跟做。
2. 前置准备：本地引擎与统一 Key 通道
2.1 本地模型引擎先跑起来
本地大模型需要一个推理引擎，Ollama 是目前上手成本最低的选择。安装完成后，终端执行拉取命令，按你的内存选模型：
# 8GB-16GB 内存，7B 级别代码模型，性价比高 ollama run qwen2.5-coder:7b # 24GB 以上显存，可以上更大的参数 ollama run qwen2.5-coder:14b拉取完成后，Ollama 默认在http://localhost:11434提供服务，这就是你的本地推理端点。先用一条命令确认它活着：
curl http://localhost:11434/api/tags返回模型列表就说明本地引擎没问题。这一步很关键，因为后面 VS Code 连不上时，要先排除是引擎没起还是配置写错。
2.2 统一 Key 通道解决什么问题
本地模型不需要 Key，但实际开发里你往往还要用云端模型补足复杂推理。如果每个插件、每台机器都单独配一遍，Key 散落各处，轮换和审计都很麻烦。TaoToken 的作用是把这些调用收敛到一个统一入口：本地模型继续走localhost，云端模型走统一 API 地址，插件侧只认一套配置格式。
先到控制台创建 Key，入口在这里：
https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=console创建后复制出来，形如sk-开头的一串字符。API 基础地址统一用：
https://taotoken.net/api注意这个地址不带任何查询参数，直接填在配置的apiBase字段里。Key 的管理页面在 API Keys 区域，后续要轮换或查看用量都从这里进：
https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys注意：Key 只放在本地配置文件或环境变量里，不要提交到 Git 仓库。建议把 Continue 的配置文件加入
.gitignore。
3. 可复制配置：settings.json 与 Continue 骨架
3.1 安装 Continue 插件
在 VS Code 扩展市场搜索 Continue 安装。它开源、支持多模型后端，是目前替代 Copilot 比较成熟的方案。安装后侧边栏会出现 Continue 图标，点开设置会生成一个配置文件，通常在用户目录下的.continue/config.json（新版也可能叫config.yaml）。
VS Code 自身的settings.json主要用来控制编辑器行为，比如是否禁用内置 Copilot 补全、是否开启内联建议。两者配合使用，下面分别给出骨架。
3.2 VS Code settings.json 关键项
打开命令面板，输入Preferences: Open User Settings (JSON)，加入以下配置，先把内置 Copilot 的补全关掉，避免和本地模型打架：
{ "github.copilot.enable": { "*": false, "plaintext": false, "markdown": false }, "editor.inlineSuggest.enabled": true, "editor.quickSuggestions": { "other": true, "comments": false, "strings": true }, "continue.enableTabAutocomplete": true }editor.inlineSuggest.enabled保持开启，因为 Continue 的补全也是以内联建议形式呈现的。关掉 Copilot 只是停用它自己的请求，不影响其他插件。
3.3 Continue 配置骨架：本地 + 统一通道
下面是核心配置，把本地 Ollama 模型和统一通道的云端模型放在同一个models数组里，切换时只改model字段：
{ "models": [ { "title": "Local Qwen2.5 Coder 7B", "provider": "ollama", "model": "qwen2.5-coder:7b", "apiBase": "http://localhost:11434" }, { "title": "TaoToken Unified", "provider": "openai", "model": "claude-3-5-sonnet", "apiKey": "sk-你的Key", "apiBase": "https://taotoken.net/api" } ], "tabAutocompleteModel": { "title": "Local Tab Autocomplete", "provider": "ollama", "model": "qwen2.5-coder:7b", "apiBase": "http://localhost:11434" }, "embeddingsProvider": { "provider": "ollama", "model": "nomic-embed-text", "apiBase": "http://localhost:11434" }, "contextProviders": [ { "name": "code", "params": {} }, { "name": "diff", "params": {} }, { "name": "codebase", "params": {} } ] }几个字段说明：tabAutocompleteModel专门管 Tab 补全，指向本地模型保证零延迟；embeddingsProvider负责代码库索引，需要额外拉一个嵌入模型：
ollama pull nomic-embed-textcontextProviders里的codebase就是仓库级检索能力，配合本地索引，问问题时它会先搜你的代码再交给模型。
3.4 参数对照表
| 配置项 | 本地模型 | 统一通道 |
|---|---|---|
| provider | ollama | openai 兼容 |
| apiBase | http://localhost:11434 | https://taotoken.net/api |
| apiKey | 不需要 | sk- 开头 Key |
| 适用场景 | Tab 补全、隐私代码 | 复杂重构、架构设计 |
| 延迟 | 毫秒级本地 | 取决于网络 |
4. 验证请求与成功结果
4.1 先验证本地端点
配置写完后不要急着在编辑器里试，先用命令行确认本地模型能正常返回：
curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5-coder:7b", "prompt": "写一个 Python 快速排序函数", "stream": false }'返回 JSON 里response字段有代码内容，说明本地链路通。
4.2 验证统一通道
再用一条请求确认统一通道的 Key 和地址可用：
curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的Key" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-3-5-sonnet", "messages": [{"role": "user", "content": "回复 ok"}] }'返回结构里有choices字段即表示通道正常。如果这里报 401，多半是 Key 复制时带了空格；报 404 则检查apiBase是否多写了/v1后缀，配置里只填到/api。
4.3 在编辑器里做端到端测试
回到 VS Code，打开 Continue 侧边栏，在模型下拉里选中Local Qwen2.5 Coder 7B，输入一句「解释当前文件的作用」。如果它开始流式输出，说明插件到本地引擎的链路完整。
接着测试 Tab 补全：新建一个.py文件，输入def calculate_，停顿一秒，看是否出现灰色内联建议。有建议且按 Tab 能接受，补全就通了。
最后测仓库级检索：在对话框输入@Codebase 这个项目的入口函数在哪，它会先建索引再回答。首次建索引会花一点时间，取决于仓库大小。
5. 本篇常见错排查
5.1 补全不出现或一直转圈
先看 Ollama 进程是否还在，curl http://localhost:11434/api/tags有没有响应。如果引擎正常，检查 Continue 配置里tabAutocompleteModel的apiBase是否写成了https，本地服务是http，写错会静默失败。
另一个高频原因是模型名不匹配。ollama list看实际拉下来的名字，配置里的model字段必须和它完全一致，包括:7b这样的标签。
5.2 统一通道报 401 或 403
Key 失效或权限不足。到 API Keys 页面重新生成一个，替换配置里的apiKey。注意 JSON 里字符串不能有换行，粘贴时容易带上不可见字符，建议手动敲一遍前缀再粘贴后半段。
5.3 内存溢出、VS Code 卡死
本地模型吃内存很凶。8GB 内存跑 7B 模型已经是上限，再大就会触发交换分区，整个编辑器卡住。判断方法：任务管理器看 Ollama 进程内存占用，接近物理内存上限就换更小的模型。另外.continueignore要配好，把node_modules、dist、二进制文件排除，否则索引阶段会拖垮机器：
node_modules/ dist/ build/ *.log *.bin5.4 补全结果和项目风格不符
本地模型看不到全局代码时会瞎猜。确认embeddingsProvider已配置且索引已建完，再在提问时用@Codebase显式带上仓库上下文。索引没建完就提问，等于让模型闭卷考试。
6. 后续怎么用：分流与长期配置
日常写业务逻辑，Tab 补全和简单问答交给本地 7B 模型，零延迟、不花钱、代码不出机器。遇到复杂重构、跨文件架构设计，在 Continue 下拉里切到统一通道的模型，用完再切回来。这种混合策略比追求 100% 本地化更实际，既保住了隐私底线，又不牺牲复杂任务的完成度。
如果你打算长期把编码助手跑在本地，建议把 Continue 配置纳入 dotfiles 管理，Key 用环境变量注入而不是硬编码。需要更系统的接入说明，可以看接入文档：
https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc想把模型对话能力单独拿出来调试，用模型对话页面直接试：
https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=model-chat如果你的工作流已经偏向 Agent 式长任务编码，Coding Plan 提供了更贴合这种场景的额度与配置方式：
https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding-plan配置这件事，第一次跑通最费时间，之后就是复制粘贴。把这份 settings.json 骨架存好，换机器时改一下 Key 就能复用。
