最近在折腾VS Code里的人工智能辅助编程，把Continue插件接上DeepSeek大模型之后，整个编码体验直接上了一个台阶。这个过程中最核心的一步就是改配置文件config.yaml，网上虽然有不少零散的教程，但要么只给一段配置完事，要么字段解释得不清不楚，照着填完报错都不知道去哪查。这篇文章把我自己从零开始配置、踩坑、调优的完整过程整理出来，把这一个yaml文件里每个关键字段的逻辑讲透，包括API地址怎么拼、密钥怎么管、上下文窗口设多少、为什么补全延迟高，以及常见的报错对照。不管你是第一次接触Continue，还是已经配过但碰到各种幺蛾子，这篇都能给你一个可以直接抄作业、也可以按需修改的完整参考。
1. 为什么是Continue加DeepSeek：一次IDE内完成AI对话和代码补全
1.1 Continue是用来做什么的
Continue是VS Code里的一款开源AI编程助手插件，它的定位和常见的聊天式AI客户端不太一样。它直接嵌在编辑器里，能在侧边栏聊天、在代码里选中内容让AI解释或修改、还能做光标位置的代码补全。它本身不带模型，而是通过配置对接各种模型服务，DeepSeek就是其中非常主流的一个选择。
这类插件解决的核心问题是“切换上下文”的割裂感。以前用AI辅助写代码，要么打开网页版聊天窗口，把代码复制过去再粘回来，要么用带云端绑定的商业插件，但模型选择和配置灵活度都受限。Continue的思路是把所有AI能力装进编辑器中，选中代码可以发送给模型，模型返回的补丁可以直接应用，整个过程不用离开VS Code。
1.2 为什么模型要选DeepSeek
选DeepSeek很大程度是看中它的API兼容性和性价比。DeepSeek的接口协议和OpenAI格式高度一致，这意味着你在Continue配置里只需要把provider指定为openai，再填上apiBase地址和apiKey，就能跑通整个链路。对使用者来说，不需要为每种模型都学习一套SDK调用方式，代码层面统一，配置成本极低。
另一个原因是上下文长度和中文代码理解能力。我在实际测试中，让它解释复杂的中文注释项目、重构老代码、写单元测试，效果都能接受。尤其对于英文模型经常理解偏的中文注释场景，DeepSeek的表现明显更舒服。整个配置下来，我甚至没有遇到一次因为协议不兼容而产生的报错，这种开箱即用的体验对配置新手非常友好。
1.3 配置前必须先搞懂的几个概念
- config.yaml：Continue插件的配置文件，所有模型的接入参数、系统提示词、斜杠命令都写在这个文件里。
- provider：提供模型API的服务方标识，Continue通过它决定用哪种协议去调用API。
- model：具体使用的模型标识符，比如deepseek-chat。
- apiBase：API服务的入口地址，决定了请求发到哪个服务器、哪个路径。
- apiKey：访问API的密钥，相当于你使用API服务的身份凭证。
- roles：当前模型承担的角色，比如chat负责对话、edit负责修改代码、autocomplete负责补全。
- embeddingsProvider：向量化嵌入配置，用于代码检索和索引，简单说就是让AI能“记住”你项目里的内容。
这些概念搞明白之后，再看配置文件就不会有陌生感了。Continue的配置本质上就是一个yaml格式的路由表，你告诉它“哪些任务交给哪个模型处理”，就这么简单。
2. config.yaml深度拆解：每个核心字段都在干什么
2.1 配置文件在哪、怎么打开
Continue安装完成之后，第一次使用时会在用户目录下自动创建配置目录。在Windows上通常是C:\Users\你的用户名.continue，在Linux和macOS上就是~/.continue。配置文件名是config.yaml，注意好多人搜教程时打成congfig.yaml，实际是config，这个单词少一个字母都会找不到文件。
打开配置文件最稳妥的方式不是手动去目录里找，而是通过VS Code命令面板：按Ctrl+Shift+P，输入Continue: Open Config，插件会自动用编辑器打开当前生效的配置文件。新版本Continue还支持在工作区根目录放一份.continue目录来做项目级配置，项目配置的优先级比用户级配置高，适合不同的项目接不同的模型。
2.2 核心models字段逐行解析
下面是一份最精简的DeepSeek配置示例，先把骨架拉出来：
name: DeepSeek Chat provider: openai model: deepseek-chat apiBase: https://api.deepseek.com/v1 apiKey: ${env:DEEPSEEK_API_KEY} roles: - chat - edit每行拆开看，name是给这个模型起一个显示名称，写在侧边栏模型列表里的名字就是它。provider填openai，这个很关键，DeepSeek的接口格式兼容OpenAI风格，所以使用openai协议作为provider，不需要找专有的provider。model填deepseek-chat，这是DeepSeek官方对话模型的标识符。
apiBase是地址，很多配置失败都出在这个字段上。DeepSeek的API基准地址是https://api.deepseek.com/v1，Continue会在这个地址后面拼接具体的请求路径，比如/v1/chat/completions，如果apiBase少写了/v1，或者多写了一层路径，请求就404了。apiKey是密钥，示例里用了环境变量引用格式${env:DEEPSEEK_API_KEY}，这种写法的好处后面专门讲。roles数组声明这个模型可以承担哪些任务，chat表示对话，edit表示代码修改，如果你想让它在补全里也发挥作用，可以再加上autocomplete。
2.3 apiBase的拼接逻辑和常见写法
apiBase这个字段是配置里最容易翻车的地方，因为很多人不清楚它和请求路径之间的关系。Continue作为一个客户端，向模型服务发起请求时，会根据你指定的provider和apiBase拼出完整的URL。以openai协议为例，请求最终会打到apiBase路径下的/chat/completions。
DeepSeek官方给的API地址是https://api.deepseek.com，如果你在apiBase里直接填这个地址，Continue拼出来就是https://api.deepseek.com/chat/completions，有部分环境会正常，但更稳妥的是填https://api.deepseek.com/v1。这样拼出来就是https://api.deepseek.com/v1/chat/completions，和官方文档里贴的请求示例完全一致。我建议所有参考我配置的人统一带上/v1，可以少踩一个坑。
还有一个容易混淆的地方是有些教程会让你填https://api.deepseek.com/v1/，末尾多了斜杠，配置起来也没问题，但为了整洁统一，我习惯不写末尾斜杠。另外，如果你用的是第三方转发服务提供的DeepSeek兼容接口，apiBase那就要填转发服务提供商的地址，而不是DeepSeek官方地址，这点要特别注意。
2.4 API Key的安全管理：环境变量优先
API Key是访问模型的凭证，泄露的后果就是被别人盗刷额度。最怕的就是把密钥明文写进config.yaml，然后这个配置文件又因为各种原因被分享出去、传到代码仓库里，密钥就彻底暴露了。我自己就见过有人把config.yaml推到公开仓库里的，第二天额度就被刷爆了。
推荐做法是把密钥放到系统环境变量里，在config.yaml中用${env:变量名}来引用。以Windows为例，先打开系统属性里的环境变量设置，新建用户变量，变量名叫DEEPSEEK_API_KEY，值填你申请到的Key。然后config.yaml里apiKey就写成${env:DEEPSEEK_API_KEY}。Linux和macOS则是在shell配置文件里加一行export DEEPSEEK_API_KEY="你的密钥"。
这样配置的好处是：config.yaml本身不含任何敏感信息，可以放心分享和备份；切换环境时只需要调整环境变量，不用改配置文件；密钥不进入VS Code的同步设置里，降低同步导致的泄露风险。
2.5 进阶扩展：embeddings、rules和斜杠命令
一个能跑的配置只需要上面那些字段，但Continue的强大之处在于它还有一套扩展机制，能把AI辅助的效果进一步提升。
embeddingsProvider是向量嵌入配置，它负责把项目里的代码片段转成向量索引，这样在聊天时选择“添加代码上下文”才能检索到相关文件。新版Continue如果没有配置embeddingsProvider，插件基本能靠内置机制工作，但检索效果一般。简单配置一个本地嵌入模型，比如用一个支持本地运行的Embeddings API，可以在不消耗远程大模型配额的情况下实现项目检索。
rules字段是全局系统提示词，可以在这里把代码规范、语言偏好、输出风格一次性写清楚，比如“所有回答使用中文”“生成代码遵循项目中已有的ESLint规范”。这些规则会注入到每一次请求的system prompt里，让模型行为更一致。
slashCommands是斜杠命令配置，你可以给常用操作起一个快捷指令。比如定义一个“explain”命令，要求模型只解释代码不修改，再定义一个“review”，让它以资深工程师视角做代码审查。配置好之后在聊天输入框打/explain就能一键触发。这些扩展项目我都后续单独写文章细讲，这里先知道它们的存在就行。
3. 完整实操：从零开始配置DeepSeek到跑通对话
3.1 安装Continue插件
在VS Code左侧扩展栏搜索“Continue”，认准插件标识，安装后重启编辑器。重启很关键，有些配置项加载不出来就是没重启。装好后左侧会出现Continue的图标，点击会打开聊天面板。
第一件事不是急着配置，而是先打开配置文件，把默认内容备份一份，比如复制到config.yaml.bak。这个习惯很重要，万一改坏了配置，随时能恢复到初始状态。Continue的默认配置里可能包含其他模型的示例字段，我们不需要全部清空，但建议用一个干净文件开始，减少干扰。
3.2 准备密钥和网络连通性检查
先去DeepSeek开放平台注册并创建一个API Key，创建后立刻复制保存，因为有些平台的Key只在创建时完整显示一次，关掉窗口就看不到了。拿到Key后，先不要急着填配置，先用一条命令验证这个Key和API服务器的连通性。
在终端执行：
curl https://api.deepseek.com/v1/models -H "Authorization: Bearer sk-你的APIKey"如果返回一段包含models列表的JSON，说明Key有效、网络可达、API地址正确。这一步做在前面，能把“配置问题”和“网络问题”隔离开，后面排查快得多。如果这一步就失败，先确认网络到该API服务器是否通畅，再看Key是否复制完整、有没有多余空格。
3.3 编写第一版可运行配置
把备份好的config.yaml清空，写入下面这份完整配置：
name: DeepSeek Chat provider: openai model: deepseek-chat apiBase: https://api.deepseek.com/v1 apiKey: ${env:DEEPSEEK_API_KEY} roles: - chat - edit maxTokens: 8096 temperature: 0.7 contextWindow: 65536maxTokens是模型单次回答生成的最大token数，调高可以避免长代码生成一半被截断，但也会增加响应时间。temperature是随机性参数，0到1之间，代码类任务我习惯设0.5左右，偏低一点输出更严谨。contextWindow是模型能够参考的上下文窗口大小，按DeepSeek这款模型的实际上下文长度来填，假设它的上下文窗口是64K，就填65536。
如果你同时需要不少代码补全场景，可以在models列表里再配一个同样指向DeepSeek但role只留autocomplete的条目。实际上大模型的补全延迟通常偏高，如果你对补全延迟敏感，可以考虑用一个本地小模型专门负责补全，DeepSeek负责对话和编辑，两块各司其职。
3.4 让配置生效：重载、选模型、测试
写完yaml后保存文件，然后在命令面板里执行Develop: Reload Window，或者直接重启VS Code。这一步必须有，Continue不会像浏览器一样热更新配置文件。重载之后，打开Continue聊天面板，在模型下拉列表里能找到你刚才配置的DeepSeek Chat。
第一次验证建议分三层走。第一层是在聊天框里发一句简单的“你好”，看有没有正常回复。第二层是选中一段代码，然后用聊天框里的“询问选中内容”功能提问，比如“解释一下这个函数”，确认上下文传递正常。第三层是打开一个代码文件，做一次实际修改操作，看看edit角色的请求是否正常返回补丁并能应用。
这三层全过了，说明配置的chat和edit两条链路都已经打通。
3.5 多模型配置和降级策略
只配一个模型能用，但实际干活时我更推荐在models列表里配多个模型，形成一个主备结构。平时主力用deepseek-chat，遇到复杂推理需求可以在会话下拉菜单里手动切到deepseek-reasoner。如果某种模型偶尔API服务不稳定，还能快速切到另一个模型继续干活。
一份包含多个模型的配置大致长这样：
models: - name: DeepSeek Chat provider: openai model: deepseek-chat apiBase: https://api.deepseek.com/v1 apiKey: ${env:DEEPSEEK_API_KEY} roles: - chat - edit - name: DeepSeek Reasoner provider: openai model: deepseek-reasoner apiBase: https://api.deepseek.com/v1 apiKey: ${env:DEEPSEEK_API_KEY} roles: - chat这里注意数据结构发生了变化，单模型配置时models下面直接是字段，多模型配置时models变成了一个列表，每个模型用短横线开头。缩进层级也要跟着变，yaml对缩进敏感，这个细节很多人改着改着就乱了。
降低成本的策略是把autocomplete单独分配给一个轻量模型，或者干脆不配置autocomplete角色，只在聊天和编辑场景用API模型，这样没有光标位置自动请求，就不会因为每次击键都触发模型调用而产生大量费用。
4. 常见问题排查与经验技巧
4.1 配置完全“不生效”该先查哪几步
遇到配置写了好像没反应，第一反应不是改配置，而是按顺序确认几个位置。先看文件路径对不对，命令面板里用Continue: Open Config打开的才是插件真正读取的文件，不要改了一个名字类似但路径不对的文件。再确认缩进，yaml文件里绝对不能出现Tab，只能用空格，缩进层级错了，插件解析时会报错或忽略。
接着看模型下拉列表里有没有你配置的模型名，如果没有，说明配置没被解析到，回到上一步检查。如果模型在下拉列表里但聊天没反应，看界面上有没有报错信息，一般会弹出的错误信息基本能定位到认证还是网络问题。
| 现象 | 排查方向 |
|---|---|
| 模型不在列表里 | 文件路径、yaml缩进、是否有语法错误 |
| 选模型后聊天转圈 | 网络连通性、apiBase拼写、DNS解析 |
| 弹401错误 | apiKey错误或未正确读取环境变量 |
| 弹404错误 | apiBase路径不对、模型标识符写错 |
| 弹429错误 | 触发速率限制，等一会或降低请求频率 |
4.2 请求报错信息对照表，直接把问题对上号
这次配置过程中我前前后后遇到不少报错，把典型的几个整理成一张速查表，你如果碰到类似信息可以直接对照。
| 报错关键词 | 真实原因 | 解决办法 |
|---|---|---|
| Authentication Fails / 401 | API Key无效或未正确加载 | 检查环境变量名是否和config.yaml里${env:...}写的一致；重新复制Key |
| model not found / 404 | 模型标识符拼写错误或接口地址不对 | 对照官方API文档确认model名，比如deepseek-chat；检查apiBase是否带/v1 |
| Rate Limit / 429 | 请求频率太高或账户余额不足 | 适当调低请求频率，检查账户额度 |
| prompt is too long | 请求内容超过模型上下文窗口 | 调高contextWindow到模型实际支持的值，或清理聊天历史 |
| Connection Error / 超时 | 网络链路问题，或模型响应太慢 | 检查API服务器可达性；reasoner模型思考耗时较长，耐心等待 |
376版本里越界情况比较多的是第二行和第三行，基本每个新手都会撞一次。中间那一列的原因总结是我实际调试下来的经验，基本能覆盖九成以上的配置失败场景。
4.3 响应慢、答案截断、中文乱码，这些参数怎么治
响应慢分两种情况。一种是网络链路导致的慢，这个通过换网络时段能缓解，另一种是reasoner这类推理模型本身要思考很久，这不是故障，是模型特性。如果不想每次聊天都等那么久，就在主对话里继续用deepseek-chat，只有复杂问题再切到reasoner。
答案写到一半被截断，这是maxTokens设太低。很多人的默认配置没写maxTokens，或者写了但只有2000左右，对于生成一段完整代码远远不够。我建议填4096以上，代码生成多的场景可以填8192，注意这个值不能超过模型单次回答上限，否则也会报错。
中文乱码的现象现在很少了，但如果你用的是某些第三方转发接口，仍然可能出现编码不一致的问题。解决办法是检查apiBase指向的接口是否与DeepSeek官方的字符编码处理一致，多模型配置时不同模型来源混用，也可能导致输出文本编码风格不同。这个情况比较少见，遇到了就优先统一模型来源。
4.4 几个确认有效且值得收藏的进阶技巧
第一，把系统提示词写进rules字段，让AI默认说中文。有些人配置完DeepSeek后，发现它经常用英文回复，这其实是系统提示词没有约束语言偏好。在config.yaml顶层加一段rules，比如写“Always respond in Chinese, unless the user explicitly requests English or code”,就能大幅改善中文使用体验。
第二，利用编辑场景给代码做批量重构。选中一个老旧函数，在Continue聊天输入框输入“重构这个函数，保留原有接口签名，增加引用计数”，模型返回diff补丁后，Continue支持直接应用，不用手动复制粘贴。操作过程多几秒钟，但省下来的时间相当可观。
第三，长期使用记得关注账户额度消耗情况。自建API配置不像商业插件那样有统一的用量看板，建议自己在面板里定期查看调用统计，以免某天突然被限额中断开发。我一般会把用量稍大的模型尽量用在编辑和聊天，而不是让它在补全里每敲一个字符就请求一次，成本能省不少。
第四，不要完全依赖一个模型跑所有任务。Continue的多角色机制就是为分工设计的，chat、edit、autocomplete分别用不同模型或不同参数，能够更均衡地兼顾延迟和效果。配置文件本身就支持这种灵活路由，值得每个人花一点时间调一调。
一点总结与后续扩展
这套配置跑通之后，我实际日常开发已经完全切换到Continue加DeepSeek的模式。最直接的感受是“笨重”的AI辅助消失了，剩下的就是那种很顺手、随时待命的感觉。填配置文件那一步拦住了很多人，实际上只要把apiBase、apiKey、model这三个字段理解透，把它当成一个路由表来看，后续扩展各种模型都是同一套套路。
我个人在实际操作中的体会是：与其到处抄别人的完整配置，不如先弄懂每一行是干什么的，再按自己的使用场景精简或增补。后续我还会继续深挖Continue的embeddings检索优化、斜杠命令设计，以及本地模型和云端模型混合调度的玩法，这些都是yaml同一根藤上结出的果子，啃下这一个文件，等于打开了整个AI辅助编程的大门。
