说实话第一次装 Continue.dev 的时候我心里是有点“无所谓”的——那会儿 AI 编程助手早就不新鲜了各家编辑器都在内置插件商店里能叫上名字的助手我基本都试过一圈。真正让我改变想法的是有一次做一个跨平台桌面端项目需要同时维护十几个调用同一个底层接口的模块我在侧边栏选中其中一个文件跟 Continue 说“把这个接口改成异步版本并把所有用到它的地方一起更新”它真的把整个改动链路梳理完还给出了每处修改的 diff。那一刻我就知道这个开源的 IDE 插件已经不是“玩具”了。这篇文章我会把自己半年多来的真实使用经验一次性讲清楚为什么在众多选择里我会固定用它、核心配置怎么做、四个主要功能怎么配合不同模型来用、本地部署时怎么估算资源以及我踩过的那些坑。如果你不想被任何一家厂商的“全家桶”绑定又想用上真正贴合自己工作流和代码库的 AI 编程助手那这份体验报告应该能帮你少走很多弯路。1. 为什么是 Continue.dev它解决的痛点和核心思路1.1 AI 编程助手的“身份认同”问题现在市面上的 AI 编程助手大多数走的是“全家桶”路线装一个插件就等于把代码补全、对话问答、代码解释这些能力都绑定到了某一个云端模型上。好处是省事坏处也很明显——你想换个模型试试不行。你想让代码不出内网做不到。你想团队统一行为规范让 AI 按你自己团队的代码风格来干活它只会“建议你升级到专业版”。这些痛点其实就是 Continue.dev 的切入点。它是一个开源的编程助手定位是“模型无关的 IDE 扩展”。翻译成人话就是它不生产模型它只负责把各种各样的模型接到你的编辑器里然后再围绕编程场景把补全、聊天、编辑、Agent 这些能力串起来。你自带模型 API key 也好本地跑 Ollama 也好接公司内部的统一网关也好它都能当那个“适配层”。这种设计的核心思路用遥控器来类比就很清楚了。 Continue 是遥控器模型是电视盒子。你可以今天用这个盒子明天换另一个盒子遥控器不用换。更重要的是你始终知道自己按下的遥控器按钮到底调到了哪条频道——每一个请求的数据流向、上下文内容都是能在配置里看到的不存在“黑盒”。1.2 Continue 的整体架构和四个核心部件Continue.dev 主要以编辑器插件的形式存在我平时最常用的是 VS Code 系它也支持 JetBrains 系全家桶IDEA、PyCharm、WebStorm 这些都有对应插件。安装之后它主要提供四类能力这也是很多人容易忽略的地方——以为它只是个“补全工具”其实远不止Autocomplete自动补全写代码时 Tab 接受建议的智能补全这是最基础的能力。Chat对话面板编辑器侧边栏的 AI 对话窗口可以选中代码、引用文件、问问题相当于一个深度理解项目上下文的 AI 结对同事。Edit内联编辑选中一段代码在当前位置让 AI 直接重写改动以 diff 形式出现你可以接受或拒绝。Agent / Actions代理与自定义动作用自然语言描述目标让它跨多个文件执行更复杂的任务比如“重构这个目录下所有遗留的 callback 写法为 async/await”。这四层能力叠加基本覆盖了日常开发的绝大部分场景。代码补全负责“关键时刻提词”对话负责“理解项目上下文”内联编辑负责“局部快速修改”Agent 负责“跨文件协同”。关键是每一个能力背后用的是什么模型、传了什么上下文你都可以在配置里改这就给了使用者极大的自由度和可控性。2. 动手安装与基础配置十分钟跑通第一轮对话2.1 安装前的准备如果是 VS Code 系直接在扩展市场搜索 Continue 安装即可不需要额外装什么运行时。JetBrains 系则是在插件市场里搜索 Continue 安装装完之后通常会要求你重启 IDE。我第一次在 JetBrains 系里装的时候因为公司用的是内网插件仓库列表里没搜到后来直接从插件官网下载了安装包手动安装也很快。装完之后侧边栏会出现一个新的 Continue 图标点开就是一个聊天面板。这时候它会引导你选择模型。这里要提醒一句很多人的第一反应是直接选它推荐的那个“快速开始”模型但那个通常需要注册并可能使用它们的代理服务。我更建议直接进入配置页面把模型来源改成你自己真正想用的。2.2 配置第一个模型Continue 的配置是以 JSON 文件形式存在的分全局配置和项目级配置。全局配置默认在用户目录下的.continue/config.json项目级配置则放在仓库的.continue/config.json里这个设计后面我会专门讲因为它是团队协作的关键。配置模型时操作入口是聊天面板右上角的设置按钮然后选择“添加模型”或直接编辑 JSON。一个最基础的 OpenAI 兼容接口配置大概长这样{ models: [ { title: 我的日常对话模型, provider: openai, model: gpt-4.1-mini, apiBase: https://api.example.com/v1, apiKey: sk-xxxxxxxxxxxxxxxx }, { title: 本地轻量补全模型, provider: ollama, model: qwen2.5-coder:7b } ] }这里有几个字段要特别注意。apiBase是接口的基础地址很多自定义网关的地址长得五花八门但 Continue 要求它最终能拼出一个完整的/chat/completions路径所以有些人配置完一直报 404多半是apiBase里漏了/v1或者其他路径前缀。apiKey支持从环境变量读取写法是${env:YOUR_KEY_NAME}这一点对不想把密钥写进仓库的人非常关键。配置好模型之后在聊天输入框里输入/model可以快速切换当前使用的模型。这个命令几乎是我用得最多的命令没有之一。2.3 跑通第一条 Chat 和第一个 Tab 补全配置完成后我建议你先做一个“冒烟测试”新建一个简单函数然后选中它在聊天框里问“这个函数的时间复杂度是多少怎么优化”。如果它能正确识别代码并给出带解释的回复说明链路已经通了。这里有个小细节选中代码再提问和直接把代码粘贴进聊天框效果完全不一样。选中的代码会自动作为附加上下文模型知道它在项目中的位置和已导入的依赖回答会更贴切。补全功能则是即开即用的。新建一个文件写一个函数名看看状态栏是否出现 Continue 的补全提示。默认快捷键是 Tab 接受建议。如果回车之后没反应排除键盘冲突之后多数情况是补全模型没配置好后面我会写具体的排查思路。3. 核心能力拆解补全、对话、编辑与自动执行怎么搭配最省力3.1 Autocomplete它不是“猜下一个字符”而是“读懂了整个文件”很多人对 Continue 的第一印象就是“代码补全”但实际用下来它和传统 IDE 的补全完全不是一个物种。传统的补全基于语法和类型信息顶多给你列出可能的成员变量和方法。Continue 的补全则会把当前文件、最近打开的文件、甚至通过检索召回的相似代码片段一起拼进上下文然后生成一小段完整的逻辑。我举个例子。有一次我在写一个日志封装工具刚写到一个format_log函数的开头它直接给出了一个完整的模板字符串拼接结构连字段名都对上了——因为那个结构的字段名在我项目里其他地方出现过。这不是它“聪明”而是它真的把项目上下文喂给了模型。这个体验是传统补全给不了的。所以我的建议是补全模型不一定要用最强的模型但一定要给 Continue 开启代码库检索能力。默认情况下它会复用你配置的对话模型来做嵌入如果想省成本也可以单独配一个本地的 Embedding 模型。这一步对补全质量的影响比换个更大的补全模型还明显。3.2 Chat选中代码、引用文件和“白盒”上下文侧边栏的 Chat 面板最高效的用法其实是“分段对话”不要一上来就把一整个大文件的代码选进去问而是选中一个函数、一个类或者一段业务逻辑问具体的问题。如果你问的是“这个文件是干什么的”那直接按快捷键调出 AI 解释整个文件也行如果你问的是“这段循环能不能向量化”那就只选中那段循环。再配合引用语法在聊天框输入文件名可以把指定文件的内容作为引用上下文加入对话。这个设计我很喜欢因为它是“白盒”的——你随时能通过界面看到当前对话到底引用了哪些文件模型是基于什么来回答的。相比那些你完全看不到上下文的助手这种透明感在排查“为什么 AI 答得不靠谱”时极有价值。3.3 Edit减少“复制到聊天框再贴回来”的笨操作改代码最流畅的方式其实不是打开聊天窗口而是直接原地改。Continue 提供了内联编辑能力选中代码按快捷键不同平台绑定不同输入你的修改要求它会生成 diff你可以逐个应用或者全部接受。这比“把代码复制到网页里改完再粘回来”的效率高出好几个量级。我觉得 Edit 和 Chat 的分工应该是局部调整、重命名、微调配额用 Edit需要理解全貌、多文件协作、询问方案用 Chat。如果你发现自己每次改一段小逻辑都要开 Chat那说明还没适应 Edit 的工作流——建议先逼自己用一周 Edit 做日常小修改效率提升会很直接。3.4 Agent 与自定义动作把“套路活”变成一句话的事Continue 的 Agent/Actions 能力是我认为它和纯“问答类助手”拉开身位的地方。它允许你配置自定义的斜杠命令比如/fix-lint、/add-test然后在命令定义里写清楚你要它执行的上下文和步骤。执行时它会自动读取当前文件、目录结构甚至可以跨多文件修改并且每一步都会给你确认。我在团队里常用的一个自定义命令叫“按规范补测试”。我配置好规则文件告诉它“参考项目现有的测试风格为当前选中模块生成不小于四个用例覆盖正常、异常、空值和并发场景”执行之后它确实会按约定俗成的测试目录结构去生成文件。这个能力特别适合把 AI 变成“重复性工作的执行器”而不是只能陪你聊天的对象。当然也要诚实地说Agent 能力依赖底层模型的推理水平。如果用的模型不够强它执行多文件任务时可能会出现逻辑断裂所以我一般会把“聊天 补全”交给不同的模型日常聊天用性价比高的模型复杂重构任务手动切换到更强的大模型。4. 模型选型与本地部署从省钱到隐私的完整方案4.1 不同任务该用哪类模型我发现很多第一次用 Continue 的人最容易犯的错误是“一个模型走天下”——拿一个性能最强的商用小模型同时干补全、聊天、重构所有事情。结果要么是计费报表吓人要么是补全延迟高到没法用。更合理的方式是让不同模型负责不同角色 Continue 支持为补全和对话分别指定模型这个能力要善用。任务推荐模型配置原因自动补全本地 7B 量化小模型 / 轻量商用模型延迟低、频率高、不需要特别强的推理日常问答中端商用模型如“mini”级别会话质量与成本之间的平衡点复杂重构 / 长上下文分析旗舰级商用大模型或本地 32B 以上强大的推理能力和超长上下文是刚需代码库检索向量化开源 Embedding 模型如 bge-m3 等数据留在本地、零调用成本我自己的组合是本地跑一个 7B 左右的小模型做补全聊天用按量计费的中端模型遇到需要认真分析的项目级问题再临时/model切到旗舰大模型。这样每个月花不了多少钱且补全体验不会因为网络延迟打折扣。4.2 本地模型的关键参数与显存估算聊本地部署总绕不开显存。 Continue 不会直接跑模型它会通过 Ollama 这类本地推理服务来加载模型所以本地部署的本质是为模型选择合适的量化版本和显存。避不开的一个术语是“量化”——简单说就是把模型权重的精度从 16 位压到 8 位或 4 位体积变小、显存占用变少代价是效果有小幅损失。实际体验中4 位量化对日常补全的影响很小完全值得用。我整理了一张粗略的显存估算表基于 8 位量化Q8和 4 位量化Q4两种情况方便你做选型参考模型规模参数量Q4 量化约需显存Q8 量化约需显存适合用途小模型3B3GB 左右4GB 左右轻量补全、短问答中模型7B5GB 左右8GB 左右日常对话、补全大模型14B9GB 左右14GB 左右复杂聊天、代码分析旗舰本地32B19GB 左右30GB 左右接近商用大模型的体验如果你的机器是 8GB 显存我建议从上到下先试 7B Q4如果是 16GB 显存可以直接挑战 14B Q8 或者 32B Q4。补全追求的是响应速度模型大了反而因为解码慢而拖手速所以“越大越好”这个思路在补全场景并不成立。4.3 让补全和聊天“分工”的配置示例我现在的配置文件结构大概是这样的可以直接参考{ models: [ { title: 主力对话模型, provider: openai, model: gpt-4.1-mini, apiKey: ${env:MAIN_API_KEY}, apiBase: https://api.example.com/v1 } ], tabAutocompleteModel: { title: 本地补全小模型, provider: ollama, model: qwen2.5-coder:7b-instruct-q4_K_M }, embeddingsProvider: { provider: ollama, model: bge-m3 } }注意tabAutocompleteModel是独立的一个字段它和models数组互不干扰。embeddingsProvider则是做代码检索的向量模型如果不想给闭源模型送代码片段本地部署一个开源的 Embedding 模型是非常划算的选择。配置完之后补全走本地、对话走云端、检索走本地整个数据路径就清晰了。5. 进阶玩法把 Continue.dev 变成团队级基础设施5.1 自定义规则让 AI 遵守你团队的“手写规范”Continue 支持在规则文件里写“命令”让 AI 在执行所有对话和补全时都默认遵守。全局规则文件放在用户目录下的.continue/rules.txt项目级规则则放在项目里的.continue/rules.txt。规则文件的优先级是项目规则会叠加在全局规则之上这样团队可以保证每个成员都带上团队规范。我给自己团队写的规则大概包括这几条所有新代码必须带类型注解不要复用已废弃的工具函数提交前先跑一遍现有测试遇到不确定的技术方案时先对比两个候选方案的优缺点再给结论。这些规则写进去之后同样的“帮我写一个接口”这个问题在新老成员电脑上生成的代码风格会高度一致。这一点对维护代码库整洁来说价值怎么强调都不过分。5.2 配置文件入仓库与 API Key 安全团队协作场景下把.continue/config.json提交进仓库是强烈建议的做法它能让所有成员的 AI 工具行为统一——模型列表、规则、补全设置都在版本控制里。但这里有一个安全的坑不要把真实的 API key 写进配置文件。Continue 支持${env:VAR_NAME}语法从环境变量读取密钥。也就是说配置文件里放的是${env:MAIN_API_KEY}每个成员或 CI 环境里设置好自己的环境变量即可。这样既统一了配置又避免了密钥泄露。如果你维护的是多人共用的开发环境还可以在配置里指向团队统一网关用网关来控制模型路由、计费统计和访问审计。5.3 统一网关与多模型调度很多人以为 Continue 只能直连各家模型的官方接口但其实只要对方提供 OpenAI 兼容的接口Continue 都能适配。这意味着团队可以搭一个内部的模型网关在网关上配置多个上游模型、统一鉴权、限流和日志。 Continue 充当 IDE 端的入口网关负责把请求路由到合适的模型上。这种架构的弹性会随着团队规模增长越来越明显不用因为某个模型涨价就让全员换工具也不用担心某个上游服务不稳定导致开发停滞——网关层面就可以做自动降级和兜底。这也是为什么我说它天然适合做“团队级基础设施”因为它的定位不是“某个厂商的入口”而是“你自己模型的网关的客户端”。6. 使用体验中的常见问题与避坑实录6.1 模型一直转圈不回复这是遇到最多的问题。排查顺序建议从外到内先确认 API key 是否有效很多人是换了环境忘了配环境变量。再确认apiBase路径对不对特别是自建网关路径里有没有/v1经常是分水岭。接着看模型名是否和上游完全一致大小写和版本号错了都会直接报错。最后看超时设置本地模型如果加载慢把请求超时调到 60 秒以上会稳很多。我踩过最深的一个坑是自建端点时把地址写成了网关主页少了 API 路径结果所有请求都返回 HTML 页面Continue 面板上只会显示一个含糊的“请求失败”。排查半天才知道是路径问题。从那以后我会先把端点地址复制到浏览器里手动请求一次确认路径无误再填进配置。6.2 Tab 补全不工作如果你能正常聊天但写代码时 Tab 不亮原因通常出在补全专用的那个模型配置上。重点检查三点是否单独配置了tabAutocompleteModel如果没有它可能会尝试用对话模型跑补全响应太慢你就以为它坏了。输入内容是否太短。 Continue 的补全一般会在你输入一定长度后才触发几行空白代码就想要建议是等不出来的。是否安装了多个补全插件导致冲突某些编辑器插件会抢占 Tab 快捷键在快捷键设置里查一下就能定位。6.3 上下文超出窗口大文件、长对话很容易把上下文窗口撑爆表现就是 AI 开始“失忆”——明明前面聊过的东西它就忘了。我的处理习惯是把大文件拆成“选中关键函数再提问”用只引用相关的文件而不是整个目录每开一个任务就开新对话不要在一个会话里一直聊天。如果真的要处理超大文件先用传统工具把文件结构摸清楚再决定要不要把全部内容塞给 AI通常没必要。6.4 常用快捷键速查不同平台的默认快捷键略有差异我把自己常用的几个整理成表装好后可以先试一遍不顺手就改功能Windows/LinuxmacOS打开聊天面板CtrlLCmdL内联编辑选中代码CtrlICmdI接受自动补全TabTab切换对话模型/model命令/model命令新建对话会话CtrlAltLCmdAltL我个人是在使用一段时间后把“内联编辑”改成了自己最顺手的组合键因为它是高频操作。 Continue 的快捷键设置在编辑器快捷键配置里是可以直接搜到并修改的值得花几分钟调一下。6.5 第一次安装时的几条建议如果你是从零开始接触 Continue.dev我最后的建议是不要一上来就接最强的大模型。先本地跑一个小模型把补全用起来体验一下 Tab 补全带来的流畅感再把对话模型配好试着用 Chat 解决两三个真实开发问题等对这套工作流熟悉了再去折腾 Agent、自定义命令和团队规则。这样一步步来不容易因为配置复杂而半途放弃也能在过程中慢慢理解每个功能到底该用在哪个场景。我个人在实际使用中的体会是Continue.dev 最值得称道的不是某一个单项能力而是它把“模型选择权”和“上下文透明度”这两件大事交还给了开发者。对于想认真把 AI 用进日常开发、又不想被厂商生态绑死的人来说它确实是一个越用越顺手的长期搭档。