1. 为什么要在 VSCode 里折腾 AI 辅助编程
1.1 从“补全”到“对话式编程”的转变
我用了快八年的 VSCode，从最早只装个 Python 插件、靠 Tab 键补全变量名，到现在写代码时旁边常驻一个能读整个项目、能改多文件、能解释报错的 AI 助手，这个变化其实就发生在最近两三年。早期大家用 AI 写代码，基本是开个网页版对话框，把代码复制出去、改完再粘回来，上下文全靠自己脑补。这种方式在写单个函数时还行，一旦涉及跨文件重构、读一个陌生仓库、或者排查一个藏在三层调用后面的 bug，来回粘贴的效率低得让人抓狂。
VSCode + Continue这套组合解决的正是这个痛点。Continue 是一个开源的 AI 编程助手插件，它不像某些商业插件那样把模型、账号、计费全绑死，而是把“用哪个模型、走哪个接口、读哪些文件、怎么改代码”这些决定权交回给你。你可以在侧边栏里跟它对话，可以让它直接在当前文件里生成代码，也可以选中一段代码让它解释或重构，甚至可以让它读取整个工作区的上下文来回答“这个项目的鉴权逻辑在哪”。对于日常写 Python、C++、Java、前端，或者维护一堆脚本的人来说，这套东西装好之后基本就是“第二大脑”级别的存在。
这篇文章适合两类人：一类是刚听说 Continue、想在自己机器上跑起来但被各种配置项劝退的新手；另一类是已经装了插件、但只会拿它当个聊天窗口用、没发挥出真正价值的老用户。我会从安装、模型接入、上下文管理、实际编码场景、常见报错排查这几个角度，把我在多个项目里踩过的坑和总结出来的配置方案完整讲一遍。全程不涉及任何需要特殊网络手段才能访问的服务，所有方案都基于公开可用的接口和本地部署方式。
1.2 Continue 到底是个什么东西
先把概念理清楚。Continue 本质上是一个 VSCode 扩展，它在编辑器里注入了一个 AI 交互层。这个交互层包含几个核心能力：一是对话面板，你可以在侧边栏跟模型聊天，聊天时能通过@符号引用文件、文件夹、终端输出、Git diff 等内容；二是行内编辑，选中代码后按快捷键，让模型直接在你选中的位置改写；三是自动补全，在你打字时给出灰色的建议，按 Tab 接受；四是自定义命令，你可以把常用的提示词固化成斜杠命令，比如/review、/test、/explain。
它跟其他 AI 插件最大的区别在于配置的透明性。Continue 的所有行为都由一个叫config.json（新版本是config.yaml）的文件驱动，模型提供方、API Key、上下文长度、补全触发规则、系统提示词，全部写在明面上。这意味着你可以精确控制它每次请求发出去多少 token、读哪些文件、用什么温度参数。对于在意成本、在意代码隐私、或者需要针对特定项目调优的人来说，这种可控性是刚需。
注意：Continue 本身不提供模型，它只是一个“壳”。你得自己准备模型来源，可以是云端 API，也可以是本地跑的小模型。这一点跟那些开箱即用的商业插件不一样，新手第一次配置时最容易卡在这里。
2. 安装与基础环境准备
2.1 VSCode 安装与中文环境配置
如果你机器上还没有 VSCode，去官网下载对应系统的安装包就行。Windows 用户注意选对架构，现在基本都是 x64，老机器可能是 ARM64；macOS 分 Intel 和 Apple Silicon 两个版本，下错了会提示不兼容；Linux 用户如果用的是 Ubuntu 这类发行版，可以直接下.deb包双击安装，也可以走命令行。安装过程没什么坑，一路下一步即可，唯一建议是勾选“添加到 PATH”，这样后面在终端里敲code .就能直接打开当前目录。
装完之后第一件事是汉化。打开扩展面板，搜Chinese，找到官方那个简体中文语言包装上，重启后界面就变中文了。这一步看似无关紧要，但后面配置 Continue 时你会频繁在设置里翻选项，中文界面能省不少事。顺带把Python、C/C++、GitLens这几个常用插件也装了，后面演示场景会用到。
2.2 Continue 插件的安装方式
在扩展面板搜Continue，认准发布者是Continue的那个，图标是个类似播放键的符号。点安装，几秒钟就好。装完后左侧活动栏会多出一个 Continue 的图标，点开就是对话面板。如果搜不到，先检查 VSCode 版本是不是太老，Continue 对版本有最低要求，升级一下编辑器基本能解决。还有一种情况是公司网络限制了扩展市场的访问，这种就得手动下载.vsix文件离线安装，在扩展面板右上角三个点里选“从 VSIX 安装”。
装好之后别急着用，先点开 Continue 面板右下角的齿轮图标，看一眼配置文件。默认它会生成一个基础配置，里面可能预置了几个模型选项。这时候如果你直接发消息，大概率会报错，因为还没配 API Key。接下来就是最关键的一步：决定用哪个模型。
2.3 模型来源的三种选择
我把可选方案分成三类，你可以根据自己的情况挑：
| 方案类型 | 代表方式 | 优点 | 缺点 | 适合人群 |
|---|---|---|---|---|
| 云端 API | 各大模型厂商的开放接口 | 能力强、响应快、无需本地算力 | 按量计费、代码需上传 | 追求效果、网络条件好 |
| 本地部署 | 本地推理框架加载开源模型 | 数据不出本机、无费用 | 吃显存、能力受模型规模限制 | 隐私敏感、有显卡 |
| 混合模式 | 补全用本地小模型，对话用云端 | 兼顾成本与效果 | 配置稍复杂 | 大多数进阶用户 |
我自己的习惯是混合模式：自动补全这种高频、低复杂度的请求走本地小模型，省 token 也省延迟；对话和重构这种需要强推理的走云端。下面分别讲怎么配。
3. Continue 配置文件详解与模型接入
3.1 配置文件的结构与位置
Continue 的配置文件默认放在用户目录下的.continue文件夹里。Windows 是C:\Users\你的用户名\.continue\，macOS 和 Linux 是~/.continue/。里面核心文件是config.json（老版本）或config.yaml（新版本）。我建议直接用新版的 YAML 格式，可读性更好，注释也方便。
一个最小可用的配置长这样：
name: my-assistant version: 1.0.0 models: - name: 对话模型 provider: openai model: gpt-4o-mini apiKey: 你的key apiBase: https://api.example.com/v1 - name: 补全模型 provider: openai model: gpt-3.5-turbo apiKey: 你的key apiBase: https://api.example.com/v1 roles: - autocomplete context: - provider: code - provider: docs - provider: diff - provider: terminal - provider: folder - provider: codebase这里有几个关键点要解释。provider指的是接口协议类型，很多厂商都兼容 OpenAI 的接口格式，所以哪怕你用的不是 OpenAI，只要对方提供了兼容接口，provider也可以填openai，然后把apiBase改成对方的地址。roles字段决定这个模型负责什么，autocomplete是补全，chat是对话，edit是行内编辑，不写默认是 chat。
3.2 接入云端模型的完整步骤
以接入一个兼容 OpenAI 协议的云端服务为例。第一步，去服务商后台拿到 API Key 和接口地址。第二步，把这两样填进配置。第三步，重启 VSCode 或者点 Continue 面板里的刷新按钮。第四步，在对话面板顶部的模型下拉框里选中你刚配的模型，发一句“你好”测试连通性。
如果报 401，说明 Key 不对或者没生效；报 404，多半是apiBase写错了，注意结尾要不要带/v1因服务商而异；报超时，检查网络能不能正常访问那个域名。我遇到过最常见的问题是apiBase多写或少写了一个斜杠，这种低级错误排查起来最费时间，建议配完先拿 curl 在终端里测一下接口通不通，再去改插件配置。
3.3 本地模型的部署与对接
本地跑模型需要先装推理框架。常见的有几种，选一个你顺手的就行。装好框架后，下载一个适合编程的模型权重，启动服务，它会监听一个本地端口，比如http://localhost:11434。然后在 Continue 配置里把apiBase指向这个地址，provider填对应的类型，model填你加载的模型名。
本地模型的选择上，参数量太小的话补全还行，对话就容易胡言乱语；参数量大的话对显存要求高。我的经验是，补全任务用 7B 左右的模型足够，对话任务至少 14B 起步才有实用价值。如果你的显卡只有 8G 显存，那就老老实实补全走本地、对话走云端，别硬扛。
提示：本地模型首次加载会花几十秒，之后常驻内存就快了。如果你发现每次请求都要等很久，检查一下是不是框架没开模型常驻，或者显存不够导致频繁换入换出。
3.4 上下文提供者的配置逻辑
context这一段是 Continue 区别于普通聊天窗口的核心。它决定了模型在回答时能看到哪些信息。code让你能引用当前打开的文件，diff能引用 Git 改动，terminal能引用终端输出，folder和codebase能让模型检索整个项目。全开的话上下文会很丰富，但 token 消耗也大。我的建议是日常保持code、diff、terminal开启，codebase按需开启，因为索引整个大仓库比较吃资源。
codebase的工作原理是先把项目文件切块、生成向量索引，你提问时它做相似度检索，把最相关的片段塞进上下文。第一次开启会有一个索引过程，项目大的话要等几分钟。索引完成后，你问“这个项目的日志是怎么打的”，它就能定位到相关文件而不是瞎猜。
4. 实际编码场景中的用法拆解
4.1 用 @ 引用精准控制上下文
很多人用 AI 编程效果差，根本原因是给的信息太少。你问“这个函数为什么报错”，模型看不到函数定义、看不到调用处、看不到报错信息，只能瞎编。Continue 的@引用就是解决这个的。在对话框里输入@，会弹出候选列表，可以选文件、文件夹、终端、Git diff 等。
举个实际例子。我有个 Python 脚本跑起来报KeyError，我的操作是：先@terminal把报错栈引进来，再@那个报错涉及的文件，然后问“这个 KeyError 是什么原因，怎么改”。模型拿到报错位置和源码后，直接指出是字典取值时没做默认值处理，并给出了修改方案。整个过程不到一分钟，比我自己翻代码快得多。
4.2 行内编辑与多文件重构
选中一段代码，按Ctrl+I（macOS 是Cmd+I），会弹出一个输入框，你写要求，它直接在你选中的位置改写。这个功能在重构时特别好用。比如我有一堆重复的异常处理代码，选中后输入“抽成一个装饰器”，它就帮我改好了。
多文件重构稍微复杂一点。Continue 支持在对话里让它生成多个文件的修改建议，你逐个确认应用。我的经验是，涉及三个以上文件的改动，最好拆成几步，每步只改一两个文件，改完自己 review 一遍再继续。一次性让它改太多，很容易出现前后不一致的情况，排查起来更麻烦。
4.3 自动补全的触发与调优
自动补全默认是开着的，你打字停顿时它会给出灰色建议。如果觉得太频繁或者太慢，可以在配置里调。关键参数有几个：debounceDelay控制你停止输入多久后才触发，默认 350 毫秒，网络慢的话可以调大；maxPromptTokens控制补全请求带多少上下文，太大影响速度，太小补全不准。
我实测下来，补全模型用本地小模型时，debounceDelay设 200 到 300 毫秒比较跟手；用云端模型时设 500 毫秒以上，避免每敲一个字就发一次请求。另外补全的上下文不要带太多，一般当前文件加上光标前几百行就够了，带整个项目反而拖慢速度。
4.4 自定义斜杠命令的实战价值
Continue 允许你把常用提示词固化成斜杠命令。在配置里加一段slashCommands，定义命令名和对应的提示词模板。我给自己配了几个：/review用来做代码审查，/test用来生成单元测试，/explain用来解释选中代码，/commit用来根据 diff 生成提交信息。
这几个命令用熟之后，日常开发里重复性的脑力劳动少了一大半。比如写完一个模块，选中它敲/test，它直接生成 pytest 用例，我检查一遍补几个边界条件就能用。/commit更省事，改完代码在对话里引用 diff，它给你写一段规范的提交说明，比我自己憋半天强。
5. 常见问题排查与避坑经验
5.1 插件装了但面板不显示
这种情况我遇到过两次。一次是 VSCode 版本太老，升级后解决。另一次是插件装在了错误的配置文件下，比如用了便携版 VSCode 但插件装到了默认用户目录。排查方法是打开命令面板，输入Continue看有没有相关命令，如果没有说明插件没真正加载。可以尝试卸载重装，或者检查 VSCode 的扩展目录权限。
5.2 模型连不上或频繁超时
先分清楚是网络问题还是配置问题。在终端里用 curl 直接请求接口地址，如果 curl 通而插件不通，那就是配置写错了；如果 curl 也不通，那就是网络或服务端问题。配置层面最常见的三个错误：apiBase地址不对、apiKey过期、model名字跟服务商提供的不一致。我建议把服务商文档里的示例配置直接复制过来改，别自己凭记忆写。
5.3 补全不触发或触发太慢
补全不触发先看配置里有没有给模型加autocomplete角色，没加的话它只当对话模型用。触发太慢的话，检查debounceDelay和maxPromptTokens，还有本地模型的响应速度。如果用的是云端补全，网络延迟是硬伤，这种情况建议换本地小模型做补全。
5.4 上下文太长导致报错
模型都有上下文窗口上限，超过就报错。Continue 在发送请求前会做截断，但截断策略不一定符合你的预期。如果频繁遇到“context length exceeded”，可以在配置里调小maxPromptTokens，或者减少context提供者，比如关掉codebase。另外对话历史也会占用上下文，聊得太长时开个新会话。
5.5 代码隐私与数据流向
这是很多人关心的。用云端模型时，你引用的代码片段会随请求发到服务商那边。如果项目涉及敏感逻辑，要么用本地模型，要么在配置里设置排除规则，把特定文件或目录加入忽略列表。Continue 支持在配置里写ignore规则，语法类似.gitignore。我的做法是，公司项目一律用本地模型，个人项目才用云端。
6. 进阶玩法与效率提升技巧
6.1 针对项目定制系统提示词
在配置里可以给对话模型写systemMessage，相当于给它定人设和规则。比如我会写“你是一个 Python 后端专家，回答时优先考虑类型注解和异常处理，不要用已废弃的 API”。这样它生成的代码风格更贴合项目规范，减少我手动改的功夫。不同项目可以配不同的配置文件，通过工作区设置切换。
6.2 结合 Git 工作流提效
Continue 能读 Git diff，这个能力在 code review 和写提交信息时特别有用。我习惯在提交前引用 diff 让它先审一遍，经常能发现一些自己没注意到的边界问题。另外它还能根据改动生成 changelog，维护开源项目时省事不少。
6.3 多模型分工的配置策略
前面提过混合模式，这里展开讲配置。在models列表里可以配多个模型，每个指定不同的roles。补全用一个，对话用一个，行内编辑再用一个。行内编辑对代码质量要求高，可以用能力最强的模型；补全对速度要求高，用最快的。这样各取所长，整体体验比单一模型好很多。
6.4 终端与远程开发场景
如果你用 VSCode 连远程服务器开发，Continue 的配置要放在远程那台机器上，因为插件运行在远程端。这一点新手容易搞混，在本地配了半天发现不生效，其实是配错了地方。远程场景下，如果服务器没有外网，就只能用本地模型或者内网部署的模型服务。
我在实际使用中的体会是，Continue 这类工具的价值不在于替你写多少代码，而在于把“查文档、翻源码、写样板、改报错”这些碎片化的时间省下来，让你能专注在真正需要思考的架构和逻辑上。配置过程确实有点门槛，但一次配好之后，后面每天都能受益。最后分享一个小技巧：把配置文件纳入版本管理，换机器时直接同步过去，省得重新折腾一遍。
