我最早接触 Continue.dev 是在一个 side project 里，当时想找个能连本地模型的 AI 编程助手。用了一段时间，我的感受是它不像那种“黑盒式”的补全工具，更像一个可以自己调教的开发环境插件。Continue.dev 本身是开源的，核心能力围绕代码对话、补全、内联编辑和上下文引用展开，而且它把“模型选择权”交回给开发者。你可以接 OpenAI、Anthropic 这类云端 API，也能接 Ollama、LM Studio 跑本地模型，甚至混着用。这种灵活性是我最看重的地方。
它的插件生态也值得聊两句。VS Code 和 JetBrains 都有官方插件，我主力用 VS Code，装完就能在侧边栏看到聊天面板。Continue.dev 的配置文件是 config.json 或 config.yaml，里面能定义模型提供方、自定义命令、上下文提供方这些内容。我刚开始觉得配置有点门槛，后来发现社区里有不少现成模板，改改就能用。这个插件不是那种装完就完事的工具，它鼓励你按项目需求去调整，有点像给编辑器装了个可编程的 AI 助手。
1.1 Continue.dev 是什么：核心能力与插件生态
Continue.dev 给我的第一印象是“轻但能打”。它没有把功能堆得满屏都是，核心就是聊天、补全、编辑三块。聊天面板里可以引用当前文件、选中代码、整个仓库检索，甚至贴 URL 让它读文档。我平时写 Python 和 TypeScript 比较多，遇到不熟的库就直接在聊天里问，它会结合我引用的文件给答案，比单独开浏览器搜要顺手。补全功能我用的相对少，但写重复性高的代码时挺省事。内联编辑（Inline Edit）是我后来才习惯的，选中一段代码按快捷键，用自然语言说“改成异步写法”，它就在原地改，不用切窗口。
插件生态这块，Continue.dev 走的是开放路线。除了官方 VS Code 和 JetBrains 插件，它还支持自定义模型提供方和上下文提供方。我试过接自己的 Ollama 服务，按文档改几行配置就通了。社区里有人分享针对 React、Rust 的提示词模板，也有人写脚本做自动化配置。这种生态让 Continue.dev 不只是一个插件，更像一个可扩展的 AI 开发环境框架。我个人的看法是，它的核心能力不在于“模型多强”，而在于“你能把模型接进来，并且按自己的习惯用”。
1.2 VS Code 插件在 AI 辅助开发中的角色
VS Code 插件在 AI 辅助开发里扮演的角色，我体会比较深。编辑器是开发者待得最久的地方，插件能把 AI 能力嵌到写代码、读代码、改代码的流程里，不用频繁切到外部工具。Continue.dev 的 VS Code 插件就是这种思路：聊天面板在侧边，补全在光标处，内联编辑在选区上，三者都围绕“当前上下文”做文章。我写代码时习惯先让它在聊天里解释一段逻辑，再让它生成测试，最后用内联编辑改命名。整个过程没离开编辑器，注意力不容易断。
从团队角度看，VS Code 插件的价值还在于配置可共享。Continue.dev 的配置文件可以放在项目仓库里，团队统一模型提供方、提示词模板和上下文规则。我见过一个团队把代码规范写成自定义命令，新人装完插件就能用同样的 AI 辅助流程。这种“环境即配置”的方式比口头传达规范要靠谱。插件本身不生产模型，它做的是连接和编排，把模型能力翻译成开发者顺手的工作流。
1.3 适用场景、目标用户与典型开发任务
Continue.dev 适合的场景挺具体。我试过在维护老项目时用它做代码解释，把整个文件引用进去问“这段数据库迁移逻辑干了什么”，它给出的摘要能帮我快速定位。写新功能时，我用它生成样板代码和单元测试，省掉不少查文档的时间。调试阶段，我把报错信息和相关文件一起丢进聊天，让它分析可能的原因。这些任务都不是“一键生成整个项目”那种大活，而是日常编码里高频的小动作。
目标用户我觉得偏中高级开发者多一些。新手用 Continue.dev 可能会被配置劝退，但喜欢折腾、对模型有偏好的开发者会很舒服。自由职业者和小团队也合适，因为可以接本地模型控制成本。典型任务包括代码补全、解释、重构、测试生成、文档辅助和快速修复。我自己的用法是“聊天为主，补全为辅，内联编辑做精修”。它不追求替代开发者，更像一个随叫随到的结对伙伴，你问得越具体，它给的东西越有用。
1.4 与其他 AI 编程插件的差异化对比
我拿 Continue.dev 跟 Copilot、Cline 这些插件都试过。Copilot 的补全体验很顺滑，开箱即用，但模型和配置基本是黑盒，你想换本地模型或者改提示词，空间不大。Cline 更偏向任务自动化，能自己跑命令、改多文件，适合让 AI 干一整件事。Continue.dev 的位置在两者之间：它没有 Copilot 那么“无感”，也没有 Cline 那么“放手”，它把控制权留给开发者，让你自己搭工作流。
差异化最明显的地方是模型自由度。Continue.dev 允许你给聊天、补全、嵌入、重排分别配不同的模型，我试过聊天用云端大模型，补全用本地小模型，成本和质量能平衡。另一个点是开源和可配置，配置文件透明，自定义命令和上下文提供方都能写。Copilot 胜在生态和补全质量，Cline 胜在自动化深度，Continue.dev 胜在“可调教”。我个人的选择是：日常写代码用 Continue.dev 做聊天和解释，补全偶尔开 Copilot，需要批量改文件时用 Cline。三个工具各干各的活，不冲突。
我装 Continue.dev 那天印象挺深，本来以为几分钟就能搞定，结果卡在配置向导那一步，来回折腾了小半个钟头。事后回头看，安装本身确实不复杂，麻烦的是“装完之后怎么让它跑起来”。这一章我按自己的实操顺序拆开讲，包括踩过的坑和一些绕路的小技巧，你照着走应该能省不少时间。
2.1 安装前环境准备与版本要求
动手前有几样东西得先确认。VS Code 版本我建议保持较新，官方文档里提到最低要求是 1.82 以上，我自己的机器一直跟着稳定版更新，没遇到过兼容问题。另一件事是网络环境，插件市场下载、首次登录云端模型提供方都可能触发网络请求，公司内网的朋友记得提前配好代理，不然插件装上了、模型连不上，体验会很差。
Continue.dev 插件本体不依赖 Node.js 运行时，它跑在 VS Code 的扩展宿主进程里。不过如果你想接 Ollama、LM Studio 这类本地模型服务，那就得先把这些服务装好、模型拉好，插件只是负责连接。我第一次装的时候忽略了这层，装完插件兴冲冲去配 Ollama，结果本地根本没拉模型，聊天面板一直转圈。提前把模型服务跑通，再回来装插件，顺序会顺很多。
硬件方面要求不算高，纯客户端使用的话普通办公本足够。想跑本地模型的话，内存和显存才是真正的门槛，这部分在第 4 章会详细聊。我这台 16G 内存的开发本，接云端 API 毫无压力，接 7B 级别的本地模型也能用，就是补全响应会慢半拍。装插件之前先想清楚自己要接哪种模型，准备工作的重点会不一样。
2.2 在 VS Code 插件市场安装 Continue.dev
装插件这一步是最省心的。打开 VS Code，点左侧的扩展图标，搜索框里输入 “Continue”，排在前面的那个蓝色图标就是官方插件，发布者显示 Continue。我一般会瞄一眼下载量和评分，确认不是山寨包。点安装按钮，几秒钟就完事，装完会提示重新加载窗口，点一下重启就行。
有个细节值得说一下。插件市场偶尔会抽风，搜索不到或者下载卡住，我遇到过一次是公司网络对市场域名限速。解决办法是去 Open VSX 或者官方 GitHub Releases 页面下载 vsix 包，然后从 VS Code 扩展面板右上角的 “...” 菜单里选“从 VSIX 安装”。这个路径虽然绕一点，但内网环境或者离线机器上特别管用。
装完之后 VS Code 左侧活动栏会多出一个 Continue 的图标，点开就是聊天面板。我一开始没注意到这个图标，还以为装失败了，其实它默认收在侧边栏里。第一次点开的时候面板是空的，旁边有个齿轮图标，那就是配置入口。整个安装流程到这里其实就结束了，真正的内容都在后面的配置环节。
2.3 首次启动与基础配置向导
插件装好第一次打开，Continue.dev 会弹出一个配置向导，问你打算接哪类模型。选项大致分云端 API 和本地模型两派，云端那边列了 OpenAI、Anthropic、Gemini 这些，本地这边提示你去装 Ollama 或者 LM Studio。这个向导做得比较友好，选完类型它会自动生成一份基础配置文件，你只需要填 API Key 或者本地服务地址。
我头一回选的是云端路线，填了个 OpenAI 的 key，向导直接帮我写好了 config.json，聊天面板马上就能用。后来我想试本地模型，又重跑了一次向导，把 Ollama 加进去当第二个提供方。向导的好处是省得手写配置，坏处是它生成的配置比较基础，模型角色、自定义命令这些还得自己补。我现在习惯用向导打底，再手动改配置文件。
向导里有个容易忽略的步骤是“选择模型角色”。Continue.dev 支持给聊天、补全、嵌入、重排分别指定模型，向导默认都指向同一个模型。如果你只用一个模型，这样没问题。想细调的话，后面得进配置文件改。我第一次没在意这个，后来发现补全用的模型响应太慢，才回去把补全单独换成了小的本地模型。
2.4 配置文件结构、常用配置项与工作区设置
Continue.dev 的配置文件放在用户目录下的 .continue 文件夹里，名字是 config.json 或者 config.yaml。我用 JSON 多一些，结构清晰。核心字段就几块：models 定义模型提供方列表，tabAutocompleteModel 单独指定补全模型，customCommands 放自定义命令，contextProviders 管上下文来源。刚开始看这些字段会有点懵，其实改几次就熟了。
我贴一段自己常用的精简配置做个示范：models 数组里每一项有个 title 做显示名，provider 指定是 openai、ollama 还是别的，model 写具体模型名。补全那块单独拎出来配，我一般指向一个响应快的小模型，聊天则用大一点的。这样的分工让打字时的补全不会拖慢节奏，提问时又能拿到质量更好的回答。
工作区级别的配置是我后来才用上的功能。VS Code 的工作区设置里可以指定项目专属的 Continue 配置路径，团队把配置模板放进仓库的 .continue 目录，新人克隆项目后插件自动读取，模型、提示词、命令全都对齐。我把一套 Python 项目的配置共享给同事，他们装完插件直接就能用我配好的命令，省掉各自摸索的时间。这个机制对小团队特别实用。
2.5 安装配置常见问题与排查方法
最常见的问题是聊天面板一直转圈或者报连接错误。我遇到这种情况一般先看两处：一是模型服务本身通不通，本地模型的话用 curl 或者浏览器访问一下服务端口；二是 API Key 有没有过期或者额度用完。Continue.dev 面板底部有个状态提示，连接失败时会给个简短原因，顺着查一般能找到症结。
第二个高频坑是配置文件改了不生效。Continue.dev 有时候需要重启窗口才会重新加载配置，尤其是切换模型提供方之后。我的习惯是改完配置按 Ctrl+Shift+P 打开命令面板，跑一下 “Reload Window”，比直接关掉重开快。配置语法错误也会导致加载失败，JSON 少个逗号、引号没闭合这类问题，插件会在输出面板里报出来，打开 “输出” 标签选 Continue 就能看到日志。
代理和防火墙问题在国内环境挺常见。云端 API 走不通的时候，检查 VS Code 的代理设置有没有生效，插件的网络请求跟 VS Code 走同一套代理配置。公司内网还有可能拦截特定域名，这种只能找运维开白名单。本地模型服务倒是没这层烦恼，端口绑 127.0.0.1 就行。我现在的习惯是装完插件先跑一个最小的聊天请求验证链路，通了再慢慢加功能，出问题也好定位是哪一环。
插件装好那天我其实有点懵，面板打开是空的，输入框在那闪，我不知道该往里敲什么。后来用顺了才发现，Continue.dev 的功能密度比我预想的高不少。这一章我按自己日常的使用顺序来聊，从最常用的代码对话，到补全、内联编辑，再到命令和提示词这些进阶玩法，最后说说我怎么把它塞进每天的编码节奏里。
3.1 代码对话、上下文引用与文件检索
代码对话是我用得最多的功能，基本替代了以前在浏览器和编辑器之间来回切的操作。面板里直接敲问题，它能读当前打开的文件，也能看到选中的代码片段。我最常干的事是选中一段函数，问它"这函数在边界情况下会出什么问题"，回复速度取决于后端接的模型，接云端 API 时基本一两秒就有结果，本地小模型稍慢但也能接受。
上下文引用这块有个 @ 符号的用法，敲出来会弹出选择器，可以引用文件、文件夹、代码符号甚至终端输出。我一开始不知道这个，傻乎乎地把代码复制粘贴到对话框里，后来发现直接 @文件名 它自己就去读了。文件检索也是类似的逻辑，项目大的时候用 @ 搜文件名比手动翻目录快得多，尤其是那种几十个模块的老项目，路径记不住没关系，敲几个关键字就筛出来了。
上下文引用有个细节需要注意，它默认不会把整个仓库塞进去，只读你引用的部分。这个设计很合理，不然 token 消耗会失控。我有一次调试一个跨文件的 bug，手动引了三四个相关文件，回复质量明显比只引一个文件高。引用的文件越多，响应越慢，这个取舍得自己把握。我现在的习惯是先把最相关的两三个文件引上，不够再追加。
3.2 代码补全、内联编辑与快速修复
补全功能跟传统代码补全不太一样，它是基于模型生成的，不只是补全单词或方法名。我在写 Python 的时候感受最深，敲完函数签名和注释，它能把整个函数体补出来。响应速度取决于你给补全角色配的模型，我一开始用的大模型，延迟明显，打字节奏被打断好几次。后来换成本地一个小的补全专用模型，流畅度好了很多，虽然生成质量有所下降，但日常写重复代码够用了。
内联编辑是我最近才开始常用的功能。选中一段代码，按快捷键触发，可以直接在编辑器里让模型改写这段代码，改完对比一下决定接不接受。这个交互比在聊天面板里贴代码再贴回来舒服太多了。我重构一个旧函数的时候用它，让它把嵌套的 if 改成提前返回的风格，改完我扫一眼就接受了，省掉手动搬代码的麻烦。
快速修复的入口在编辑器的灯泡菜单里，光标停在报错行上，能直接调 Continue 来解释错误或者给修复建议。这个功能我用得不算多，因为大部分报错信息本身已经够明确了。不过遇到那种第三方库抛出的晦涩异常，让它解释一下堆栈还是有点用的。它给的建议不一定对，我一般当参考看，不会盲接。
3.3 代码解释、重构、测试生成与文档辅助
代码解释这个功能，我主要拿来读别人的代码。接手一个陌生模块的时候，选中整个文件让它逐段解释，比我自己一行行啃快很多。它的解释会带上上下文推断，比如某个变量是从哪来的、这个函数被谁调用了，这些信息它有时候能猜对，有时候会编。我一般会对照着实际代码验证一下，不能全信，但作为理解起点够用了。
重构方面，我试过让它把一个长函数拆成几个小函数，效果还行，拆出来的逻辑基本合理。它不会自动帮你改调用方，拆完得自己检查引用。测试生成是我用得比较多的场景，选中一个函数让它生成 pytest 用例，生成的用例覆盖度一般，边界条件经常漏，但基础路径能覆盖到，我在它基础上补几个边界用例就差不多了，比从零写省时间。
文档辅助这块，我主要用它给函数生成 docstring。选中函数，让它按 Google 风格写注释，生成质量挺稳定，参数和返回值都描述得比较准确。项目里那些没注释的老代码，我批量过了一遍，让它一个个补 docstring，效率比手写高太多了。生成的注释偶尔会有描述偏差，尤其是涉及副作用的地方，我会顺手改一下。
3.4 自定义命令、快捷操作与提示词模板
自定义命令是这插件我觉得最值得花时间配置的功能。配置文件里的 customCommands 字段可以定义自己的命令，每个命令绑一个提示词模板，在聊天面板里敲 / 就能调出来。我配了几个自己常用的，比如 /review 用来做代码评审，/test 生成测试，/explain 解释选中代码。配好之后就不用每次重复敲同样的提示词了，省事很多。
提示词模板里可以带变量，比如选中代码的内容、当前文件名这些。我配 /review 的时候把选中代码和文件名都塞进去，模型拿到上下文后给的评审意见会更具体。模板的写法就是普通文本加变量占位，改几次就熟了。我一开始模板写得太长，塞了一堆要求进去，结果模型反而抓不住重点，后来精简到三四条核心要求，效果好了不少。
快捷操作方面，VS Code 的命令面板里能搜到 Continue 相关的命令，可以给常用操作绑快捷键。我给"打开聊天面板"和"内联编辑"各绑了一个，日常用起来顺手很多。这些快捷键配置会跟着 VS Code 的设置同步，换机器的时候不用重新配。团队里如果有人用同一套配置，直接共享 settings.json 就行。
3.5 将插件融入日常编码、调试与评审流程
我现在的日常节奏大概是这样的：写新代码的时候靠补全功能打辅助，遇到不确定的 API 用法就开聊天面板问一句，写完一个模块让它生成测试用例，提交前用 /review 命令过一遍。这套流程跑顺之后，我在编辑器里停留的时间明显变长了，切浏览器的次数少了很多。补全和聊天用的是不同模型，补全用小模型保速度，聊天用大模型保质量，这个分工挺关键的。
调试环节我用得比较克制。报错信息明确的时候自己看就行，没必要问模型。遇到跨文件的状态问题或者第三方库的诡异行为，我会把相关文件引上，让它帮我分析可能的原因。它给的方向不一定对，但有时候能提供我没考虑到的视角。我印象比较深的一次是一个异步竞态问题，它提示我检查某两个 await 的顺序，顺着查确实找到了问题。
代码评审这块，我把它当第一道过滤。提交 PR 之前用 /review 跑一遍，能揪出一些明显的风格问题和潜在的边界遗漏。它挑出来的问题我会逐条看，该改的改，不该改的忽略。团队里其他人不用这插件也没关系，我这边的产出质量提上去了就行。评审流程本身没变，只是我提交前多了一道自查。这套用法跑了一个多月，最大的感受是它帮我省掉了大量"查一下这个函数怎么用来着"的碎片时间，注意力能更集中在真正的逻辑设计上。
我一开始是纯云端用户，OpenAI 的 key 填进去就能跑，省心。动了本地模型的念头，是因为有个内部项目不让把代码往外发，聊天面板一打开就心虚。索性把整条链路搬到本地来跑。
那段时间我踩了不少坑，从显卡显存算错，到配置字段拼错一个字母排查半小时。下面这套流程是我前后折腾了两周、又在三台机器上重装验证过的东西，照着走能少走点弯路。
4.1 本地大模型运行环境与硬件准备
先说硬件，这块绕不过去。我第一台试验机是台 16G 内存的轻薄本，没独显，想着跑个 7B 模型应该凑合。装完 Ollama 拉了个 7B 的量化版，跑是能跑，生成速度大概每秒三四个 token，打字一样一个字一个字往外蹦，体验差到我不想用第二次。后来换到一台 32G 内存、12G 显存的机器上，同样的模型速度翻了七八倍，才算能用。
选硬件的时候我最看重的不是显卡多贵，是显存够不够把模型整个装下。模型参数量和量化等级决定文件大小，7B 的 Q4 量化大概 4G 多，13B 的 Q4 要 8G 上下，30B 的 Q4 直接上 18G，普通消费级显卡就没戏了。显存装不下会往内存和 CPU 上溢出，速度断崖式下跌。我的建议是先按自己能接受的模型规模反推硬件，别反过来。
软件环境上，Windows、macOS、Linux 都能跑，macOS 的 Apple Silicon 芯片统一内存架构挺吃香，M 系列跑 13B 模型不算吃力。系统层面没什么特殊要求，装好运行时就够了。唯一的提醒是磁盘空间留够，模型文件动辄几个 G，我一个盘塞了五六个模型，几十个 G 就没了。
4.2 常见本地模型服务接入方式：Ollama、LM Studio、vLLM 等
Ollama 是我最推荐新手先试的。安装包双击装完就有个后台服务，命令行里 ollama pull 拉模型，ollama serve 起服务，默认监听 11434 端口。它对 Continue.dev 的支持是最顺的，插件里 provider 直接填 ollama，模型名对得上就能用。我现在的日常工作流就是基于它，简单、稳定、不折腾。
LM Studio 更适合喜欢图形界面的人。它有模型商店，点几下就能下载，界面上能直接开一个兼容 OpenAI 格式的本地服务端，默认端口 1234。我在 Windows 上用这个给同事演示过，他们不爱敲命令行，图形化这块接受度高很多。LM Studio 的模型管理界面还能看到显存占用和生成速度，调参的时候一目了然。
vLLM 是给有正经显卡的人准备的，走的是高性能推理路线，吞吐量比前两个高一个量级，适合多个人共用一个服务或者对速度特别敏感的场合。代价是部署门槛上去了，得装 Python 环境、拉依赖、写启动脚本，参数还一大堆。我在一台 4090 的服务器上试过，跑起来之后确实快，但不是所有人都需要这个级别的性能。
三个之外还有 llama.cpp 的 server 模式、Text Generation WebUI 这些，原理大同小异，都是起一个 HTTP 服务让插件去调。选哪个看你图什么，图省事用 Ollama，图界面用 LM Studio，图性能用 vLLM。
4.3 在 Continue.dev 中配置本地模型提供方
配置入口在侧边栏 Continue 面板右下角的齿轮图标，点开是 config.json 或者 config.yaml。我习惯用 JSON 版本，字段清晰一点。配置里最重要的就是 models 数组，每一个元素描述一个可用的模型，插件根据这里面的信息决定调谁、怎么调。
接 Ollama 的话，一个最简配置大概是这样：provider 写 "ollama"，model 写模型在 Ollama 里的名字，比如 "qwen2.5-coder:7b"，apiBase 一般不用写，插件会默认走 http://localhost:11434。如果你把 Ollama 装在了别的机器或者改了端口，那就得显式写上 apiBase。
LM Studio 和 vLLM 走的都是 OpenAI 兼容协议，provider 填 "openai"，然后 apiBase 指向它们各自的端口，LM Studio 是 http://localhost:1234/v1，vLLM 默认是 http://localhost:8000/v1。apiKey 随便填个字符串就行，本地服务通常不校验，但字段不能空着，有些版本会因为缺这个字段直接报错。我第一次配 vLLM 就卡在这，忘了填 apiKey，报错信息也不明说，查了半天文档才反应过来。
配置改完保存，插件会自动热重载。侧边栏的模型下拉框里应该就能看到新加的条目了。看不到的话，先检查 JSON 是不是有语法错误，逗号和括号是最容易出问题的地方，我写配置的时候习惯开着编辑器的语法检查。
4.4 模型角色配置：聊天、补全、嵌入与重排模型
Continue.dev 的模型是分角色的，这个设计我花了点时间才理解透。每个模型条目里有个 roles 数组，可以填 chat、autocomplete、embed、rerank 这些值，填了哪个角色，这个模型就能干哪个活。一个模型可以身兼多职，也可以每个角色单独配一个模型。
聊天模型是主力，建议用你能跑得动的最大最好的那个。我配的聊天模型换过好几次，从 7B 一路换到 14B，回复质量的提升是肉眼可见的，代价就是慢一点。聊天场景对延迟不敏感，等一下没关系，质量更重要。
补全模型的选法完全相反。补全是在你打字的时候实时触发的，延迟超过一秒就会打断思路。我专门找了个 1.5B 的小模型干这个活，速度飞快，生成质量一般，但补全整行代码、补个函数体开头这些场景够用了。用大模型做补全我试过，一次生成卡两三秒，写着写着就被打断，太难受。
嵌入模型管的是代码库索引，也就是 @codebase 那种全仓库检索的能力。这块得用专门的 embedding 模型，不能拿聊天模型凑。Ollama 里有 nomic-embed-text 挺常用，拉下来配个 embed 角色就行。重排模型属于锦上添花，检索结果多的时候用来二次排序，我配过一次，效果上有提升但不是必须的，硬件紧张就先不配。
我的配置是三个角色各司其职：14B 跑聊天，1.5B 跑补全，embed 模型管索引。这样一边打字一边能秒出补全，真要问复杂问题再切到聊天面板等大模型慢慢想。
4.5 本地模型性能调优、资源占用与隐私安全设置
性能这块我调过几个参数，效果最明显的是上下文长度。每个模型条目里可以写 contextLength，默认值有时候给得很大，模型实际撑不住，跑起来就慢。我一般按模型的实际能力和任务需要来设，聊天给 8K 到 16K，补全给 2K 到 4K，别贪多。上下文开得越大，每次请求吃的显存和计算量越多，速度掉得很厉害。
Ollama 那边还有个 num_ctx 参数可以调，通过 modelfile 或者环境变量控制。我一开始按默认跑，后来发现它给 7B 模型分配的上下文比我想的多，改小之后显存占用降了不少。LM Studio 的界面上能直接看到 token 生成速度和显存占用，调参的时候对着数字改，比盲猜靠谱。
隐私这块是本地部署最大的卖点。所有推理都在你自己的机器上完成，代码不出内网，模型服务默认只监听本地回环地址，外部访问不了。我特意确认过这一点，把 apiBase 用 127.0.0.1 而不是 0.0.0.0，减少暴露面。如果团队里要共享一台推理服务器，那得在局域网内配置访问控制，别裸着开出去。
还有个小细节，插件的 allowAnonymousTelemetry 字段可以设成 false，关掉匿名使用数据上报。这个跟代码隐私无关，纯属个人偏好，我在所有机器上都关了。
4.6 本地模型配置验证与常见问题处理
配置完怎么验证？我最常用的办法是在聊天面板里直接问一句，看它回不回。有回复说明链路通了，没回复就往下排查。面板里能切换模型，切换之后问一句"你是谁"，模型的自我认知有时候能帮你确认到底连的是哪个，尤其是多个本地服务同时开着的时候容易串。
排查的第一步是看服务状态。Ollama 用 ollama list 看模型在不在，curl http://localhost:11434/api/tags 看接口通不通。LM Studio 和 vLLM 的 OpenAI 兼容接口可以用 curl 打一下 /v1/models，能列出模型列表说明服务正常。这一步能排掉一大半"配置写错了"和"服务没起来"的情况。
模型名写错是我遇到最多的坑，Ollama 的模型名带标签，qwen2.5-coder 和 qwen2.5-coder:7b 是两个东西，配置里必须和 ollama list 显示的完全一致。还有端口冲突，LM Studio 的 1234 端口有时候被别的程序占了，服务起不来也不提示，换个端口就好。
补全不出结果、聊天正常，这种通常是角色没配对，检查一下补全模型的 roles 里有没有 autocomplete。反过来聊天没反应但补全正常，可能是聊天模型的名字拼错了或者服务地址指错了。还有种情况是模型加载了但一直转圈，多半是显存不足，模型在 CPU 和 GPU 之间来回倒腾，换个小一号的模型或者调低上下文长度能缓解。最后提一句，有些模型不支持工具调用和结构化输出，配了 chat 角色后功能可用但部分工具类的命令会失灵，遇到奇怪的行为先换个模型验证一下，能快速定位问题出在配置上还是模型上。
用 Continue.dev 大半年下来，我的感受是：装好、配通只是起点，真正拉开体验差距的是后面这些“怎么组合、怎么组织、怎么跟团队一起用”的细节。这一章把我自己踩过的坑和沉淀下来的套路摊开讲讲，有些是配置层面的，有些是工作习惯层面的。
5.1 多模型组合与本地/远程混合配置策略
我现在的配置不是“一个模型打天下”，而是按任务拆开。日常补全交给本地一个 1.5B 的小模型，毫秒级响应，不卡思路；聊天面板里挂两个选项，本地 14B 应付一般问题，遇到复杂重构或者疑难 bug 就切到远程的大模型。这样既保住了隐私敏感场景的底线，又没牺牲难题上的质量。
混合配置的关键是“什么时候切”。我的判断标准很朴素：代码能不能出内网。内部项目的代码我全程用本地模型，哪怕慢一点也认；开源项目或者写博客的代码片段，远程模型随便用。插件里模型下拉框切一下就行，不用改配置，这个设计挺顺手。
配置层面，models 数组里同时放本地和远程条目，每个条目用 roles 区分用途。我给本地模型配了 autocomplete 和 chat，远程模型只配 chat。这样补全永远不会走远程，聊天的默认选项也是本地，需要的时候手动切。有段时间我把远程设成默认聊天模型，结果有次忘记切回来，一段内部代码发出去才反应过来，从那以后默认永远给本地。
5.2 项目级规则、上下文管理与提示词组织
项目根目录下建一个 .continue 文件夹，里面放 rules.md 或者按主题拆的几个规则文件，这是我现在每个项目必做的事。规则里写清楚这个项目的技术栈、代码风格、命名约定、禁用哪些库。插件会自动把这些内容注入上下文，模型生成的代码明显更贴合项目实际，少了很多“看起来对但风格不对”的返工。
提示词我按场景整理成了几个模板，放在 prompts 目录里。比如“生成单元测试”“审查这段 diff”“解释这个报错”各一个，用的时候在聊天框里 @ 一下调出来。模板里预置了输出格式要求，比如测试模板里写死用项目的测试框架、每个 case 单独一个函数，省得每次都要重复交代。
上下文管理上我吃过亏。一开始什么都往上下文里塞，几个大文件一引用，token 直接爆掉，模型反而抓不住重点。后来学乖了，引用文件控制在三五个以内，优先用 @codebase 做语义检索而不是手动贴大段代码，符号引用（@ 加函数名）比整文件引用精准得多。上下文贵精不贵多，这句话在本地模型上尤其成立，窗口就那么大，塞满了反而没空间思考。
5.3 团队协作中的配置共享与规范落地
团队里推广这个插件，最大的阻力不是技术，是“每个人配出来的东西不一样”。我的做法是把 config.json 和 .continue 目录一起提交到仓库，新人克隆下来开箱即用。密钥类的字段走环境变量，配置里写 ${{ secrets.OPENAI_KEY }} 这种形式，不进版本库，避免泄露。
规范落地上我走过弯路。一开始想推一套“标准配置”，要求所有人统一用某个模型，结果推不动，每个人机器不一样、偏好也不一样。后来改成“下限统一、上限自由”：补全模型和规则文件必须用仓库里的，聊天模型随意配。这样既保证了代码风格一致，又没剥夺大家的自主权，接受度高很多。
还有个细节值得提，团队共用一套远程模型 key 的时候，用量和成本要有个交代。我们在配置里给每个人配了独立的 key，月底看账单能追溯到人。不是为了监控，是为了让大家都对成本有点感知，避免有人拿大模型跑批量任务把额度烧光。
5.4 插件扩展、自定义模型提供方与二次开发
Continue.dev 支持自定义 provider，这个能力我用得不多，但关键时候救过场。公司内部有个自研的推理网关，接口不完全兼容 OpenAI 协议，我在配置里写了一个自定义 provider，把请求路径和字段映射对上去，插件就能正常调了。写法不复杂，照着文档里的 provider 模板改，主要是把 streamChat 和 streamComplete 两个方法的请求体拼对。
插件的扩展点比我想的丰富。除了 provider，还能自定义 slash 命令和上下文提供方。我写过一个简单的命令，选中代码后一键生成 commit message，调的是本地模型，几秒钟出结果。这种小工具单个看价值不大，攒多了能省不少零碎时间。
二次开发这块我的建议是“先别急着自己写”。插件本身迭代挺快，很多你想要的功能可能下个版本就官方支持了。我年初想自己写个代码库索引的优化逻辑，写到一半发现新版本已经改了实现，白折腾。真要做扩展，先去 GitHub 的 issue 和 discussions 里翻一圈，看看有没有人已经在做，或者官方有没有路线图。
5.5 性能、成本与隐私的平衡实践
这三者的关系我琢磨了很久，最后的结论是没有标准答案，只有适合自己场景的平衡点。我手上的项目分三类：纯内部项目，隐私优先，全本地，慢点认了；开源项目，成本优先，用免费额度的远程模型；介于两者之间的，混合配置，敏感文件手动排除。
性能上的一个实用技巧是给不同角色设不同的超时和重试。补全模型的超时我设得很短，一秒不出结果就直接放弃，避免打字时界面卡住；聊天模型的超时设得长，等它慢慢想。重试次数补全设 0，聊天设 1，逻辑不一样，补全重试没意义，聊天偶尔网络抖动重试一下能救回来。
成本控制上，本地模型是硬成本（电费和硬件折旧），远程模型是软成本（按 token 计费）。我用一个小脚本统计每周的 token 消耗，发现聊天占大头，补全反而很少。于是把聊天默认模型换成更便宜的档位，复杂问题手动切贵的，一个月下来账单降了一半多，体验上几乎没感觉。
隐私这块，除了前面说的本地部署，还有个容易忽略的点：上下文里引用的文件。有时候随手 @ 了一个配置文件，里面带着密钥或者内网地址，模型回复里就给带出来了。我现在的习惯是引用前扫一眼文件内容，敏感文件加进插件的忽略列表，从源头上不让它进上下文。
5.6 学习资源、版本维护与持续优化建议
官方文档是我最常翻的，尤其是配置字段那一页，每次想加新功能都先去查有没有现成的配置项。GitHub 的 discussions 区质量挺高，很多疑难问题在那里能找到别人的排查过程，比翻 issue 效率高。我还订了他们的 release notes，新版本有什么变化一眼能看到，避免升级后配置不兼容。
版本维护上我吃过一次亏。有次自动更新到新版本，配置文件里一个字段被改了名，插件启动直接报错，排查了半天才定位到。从那以后我把插件设成手动更新，升级前先看 changelog，确认配置兼容再动手。生产环境用的机器更是锁定版本，不跟着追新。
持续优化这件事，我的做法是每个月花半小时回顾一下这个月的使用情况：哪些场景用得多、哪些配置从来没动过、有没有新的模型值得一试。上个月我发现自己几乎不用内联编辑功能，就把相关的快捷键和配置精简掉了，界面清爽不少。工具是给自己用的，定期修剪比不断堆功能更重要。
