Continue.dev 是一个开源的代码助手插件,常见用法是在 VS Code 或 JetBrains 里接入大模型,让它帮助你解释代码、生成代码、重构文件、写测试、做代码审查。对开发者来说,Continue.dev 的价值不只是“在编辑器里聊天”,而是把模型能力嵌进真实编码流程。
如果你已经在使用 DeepAI API 中转站,就可以把 Continue.dev 配成 OpenAI-compatible Provider,通过统一的 Base URL 和 API Key 调用不同模型。这样你不需要在每个模型厂商之间反复切换,也可以把 Chatbox、Open WebUI、Dify、LobeChat、Cherry Studio、Continue.dev 等工具统一到一套 API 网关里管理。
本文会从零讲清楚:Continue.dev 如何接入 DeepAI API 中转站,config.json 应该怎么写,聊天模型、代码补全模型、Embedding 模型应该怎么分开配置,以及 401、404、上下文过长、流式中断、Token 消耗过高时应该怎么排查。
> DeepAI Base URL:https://api.deepai.wang/v1
Continue.dev 适合用来做什么
Continue.dev 和普通聊天客户端不一样。Chatbox、LobeChat、Open WebUI 更偏“对话界面”,而 Continue.dev 更偏“开发工作流”。它可以在编辑器里完成这些任务:
- 解释当前文件或选中的代码;
- 根据上下文生成函数、测试、注释;
- 重构一段复杂逻辑;
- 根据报错信息定位问题;
- 对整个代码库做语义检索;
- 使用 Tab 自动补全代码;
- 结合自定义命令生成 commit message、review diff、写文档。
也正因为它离真实代码更近,所以 Continue.dev 对模型配置、上下文窗口、Token 成本和响应稳定性要求更高。随便填一个模型能跑起来,但不一定适合长期写代码。
Continue.dev 和 DeepAI API 中转站的关系
Continue.dev 是客户端,DeepAI API 中转站是模型 API 入口。两者关系可以理解成:
VS Code / JetBrains
↓
Continue.dev 插件
↓
DeepAI API 中转站(OpenAI-compatible API)
↓
上游模型
Continue.dev 并不关心背后到底是哪个厂商的模型,只要接口兼容 OpenAI API 风格,它就可以通过类似 baseUrl、apiKey、model 的配置发起请求。
因此,配置重点只有三个:
- Base URL:
https://api.deepai.wang/v1 - API Key:DeepAI API Key
- Model ID:DeepAI 后台实际可用的模型 ID
但对代码助手来说,仅有这三个还不够。你还需要考虑:聊天模型、代码补全模型、Embedding 模型是否要分开;是否开启 autocomplete;上下文长度是否够;成本是否可控。
准备工作
开始前你需要准备:
- 已安装 VS Code 或 JetBrains;
- 已安装 Continue.dev 插件;
- DeepAI API Key;
- 至少一个适合聊天/代码任务的模型 ID;
- 如果要做代码库检索,还需要 Embedding 模型;
- 网络能访问
https://api.deepai.wang/v1。
建议先用 curl 验证 DeepAI Key 是否可用:
curl https://api.deepai.wang/v1/chat/completions \
-H "Authorization: Bearer sk-你的DeepAIKey" \
-H "Content-Type: application/json" \
-d '{
"model": "你的模型ID",
"messages": [
{"role": "user", "content": "用一句话解释 Continue.dev 是什么"}
]
}'
如果 curl 不通,先不要急着改 Continue.dev。先排查 Key、模型 ID、余额、权限和网络。
站内基础测试文章可以参考:
从 curl 到 Python:如何确认 DeepAI OpenAI 兼容接口真的能用
Continue.dev 配置文件在哪里
Continue.dev 主要通过配置文件管理模型。常见位置是:
~/.continue/config.json
在 VS Code 里也可以通过 Continue 面板打开配置。不同版本的 Continue.dev 可能支持 config.json、config.yaml 或新的配置格式,但核心字段类似:provider、model、apiKey、apiBase / baseUrl。
如果你正在使用较新版本,界面字段可能和本文示例略有差异。不要死记字段名,重点看最终请求是否满足:
POST https://api.deepai.wang/v1/chat/completions
Authorization: Bearer sk-xxx
model: DeepAI 后台可用模型 ID
最小可用配置示例
下面是一个最小配置示例,适合先跑通聊天功能:
{
"models": [
{
"title": "DeepAI Chat Model",
"provider": "openai",
"model": "你的模型ID",
"apiKey": "sk-你的DeepAIKey",
"apiBase": "https://api.deepai.wang/v1"
}
]
}
有些版本字段叫 apiBase,有些可能叫 baseUrl 或 apiBaseUrl。如果 Continue.dev 报配置字段无效,需要以当前版本文档为准,但 DeepAI 相关参数不变:
| 参数 | 填写 |
|---|---|
| provider | openai 或 OpenAI-compatible |
| apiBase / baseUrl | https://api.deepai.wang/v1 |
| apiKey | DeepAI API Key |
| model | DeepAI 后台实际可用模型 ID |
注意:Base URL 不要填成完整接口路径:
https://api.deepai.wang/v1/chat/completions
Continue.dev 会自动拼接接口路径。你只需要填到 /v1。
推荐配置:聊天模型和补全模型分开
写代码时,“聊天模型”和“自动补全模型”的使用方式不同。
聊天模型通常用于:
- 解释代码;
- 修改文件;
- 生成测试;
- 分析报错;
- 多轮上下文讨论。
自动补全模型通常用于:
- 根据当前光标位置生成下一行代码;
- 快速补全函数体;
- 频繁、小请求、低延迟调用。
如果你把一个很贵、很慢的大模型同时用于聊天和 Tab 补全,Token 消耗会明显上升,体验也可能变慢。
更稳的做法是:
{
"models": [
{
"title": "DeepAI Coding Chat",
"provider": "openai",
"model": "你的强代码模型ID",
"apiKey": "sk-你的DeepAIKey",
"apiBase": "https://api.deepai.wang/v1"
}
],
"tabAutocompleteModel": {
"title": "DeepAI Fast Autocomplete",
"provider": "openai",
"model": "你的快速模型ID",
"apiKey": "sk-你的DeepAIKey",
"apiBase": "https://api.deepai.wang/v1"
}
}
模型 ID 需要替换成 DeepAI 后台实际可用的模型。这里不建议盲目复制别人文章里的模型名,因为不同平台开放的模型 ID 和权限可能不同。
Embedding 模型要不要配置
Continue.dev 如果要做代码库检索、语义搜索、RAG 类能力,可能需要 Embedding 模型。Embedding 和聊天模型不是一回事。
聊天模型用于生成回答:
代码解释、函数生成、重构建议
Embedding 模型用于把文本转成向量:
代码片段索引、语义搜索、相关文件召回
如果你只是让 Continue.dev 读当前文件、解释选中代码,可以先不配置 Embedding。如果你希望它更好地理解整个项目,就需要考虑 Embedding 配置。
示例结构可能类似:
{
"embeddingsProvider": {
"provider": "openai",
"model": "你的Embedding模型ID",
"apiKey": "sk-你的DeepAIKey",
"apiBase": "https://api.deepai.wang/v1"
}
}
具体字段随 Continue.dev 版本变化较大。配置时要确认 DeepAI API 中转站是否提供你要使用的 Embedding 模型,以及 Continue.dev 当前版本如何声明 embeddings provider。
第一次测试:从简单问题开始
配置完成后,不要一上来就让 Continue.dev 重构整个项目。建议按下面顺序测试:
1. 在 Continue 面板里发送一句简单问题; 2. 选中一小段代码,让它解释; 3. 让它生成一个小函数; 4. 再测试当前文件级别的问题; 5. 最后再测试跨文件或代码库检索。
这样做的好处是,一旦出错,你知道问题发生在哪个层级:
- 简单聊天都失败:API Key / Base URL / Model ID 问题;
- 当前文件失败:上下文或插件读取文件问题;
- 跨文件失败:索引、Embedding、项目权限问题;
- 自动补全失败:tabAutocompleteModel 或流式/延迟问题。
401 Unauthorized 排查
Continue.dev 报 401,优先检查 Key。
常见原因:
- API Key 没复制完整;
- Key 前后多了空格;
- 手动写了
Bearer sk-xxx; - Key 已删除或禁用;
- 当前 Key 没有调用该模型的权限;
- Continue.dev 读取的是旧配置;
- VS Code 没重载窗口,配置没生效。
建议用同一个 Key 跑 curl。如果 curl 能通,Continue.dev 不通,重点查配置文件和插件是否读取到了正确值。如果 curl 也不通,就回到 DeepAI 后台检查 Key、余额和权限。
404 Model Not Found 排查
404 常见原因有两个:Base URL 路径错,或者模型 ID 错。
先确认:
https://api.deepai.wang/v1
不要写成:
https://api.deepai.wang/v1/chat/completions
再检查模型 ID:
- 是否把展示名当成模型 ID;
- 是否大小写写错;
- 是否模型已经下架或权限不足;
- 是否聊天模型能用,但补全模型不能用;
- 是否 Continue.dev 的配置里还有旧模型。
继续排查时,可以把 Continue.dev 配置先简化到只保留一个模型。跑通后再加补全模型、Embedding 模型和其他高级配置。
上下文过长怎么办
代码助手很容易遇到上下文过长。比如你让 Continue.dev 分析整个项目,或者一次性塞入多个大文件,模型就可能返回 context length exceeded、请求失败或回答被截断。
解决思路:
- 不要一次性选择太多文件;
- 先让模型分析目录结构,再逐步深入;
- 对大文件只选中关键函数;
- 选择上下文更长的模型;
- 使用 Continue.dev 的代码库检索能力,而不是粗暴粘贴所有代码;
- 对日志文件、构建产物、锁文件设置忽略。
建议在项目里排除这些内容:
node_modules/
dist/
build/
.git/
coverage/
*.lock
*.min.js
这些文件进入上下文,只会浪费 Token,而且通常对解决问题帮助不大。
Token 消耗高怎么办
Continue.dev 的 Token 消耗可能比普通聊天客户端高,因为它会频繁读取代码上下文、发送 diff、处理自动补全请求。
控制成本可以从几方面入手:
1. 拆分模型用途
- 强模型:用于复杂重构、架构分析、疑难报错;
- 快模型:用于简单问答和补全;
- 便宜模型:用于注释、摘要、简单解释。
2. 限制自动补全
自动补全是高频调用。如果你发现消耗异常,可以:
- 临时关闭 Tab autocomplete;
- 降低触发频率;
- 换更便宜/更快的补全模型;
- 只在需要时开启。
3. 控制上下文
不要让插件每次都带过多文件。选中关键代码,比“把整个项目给模型”更有效。
4. 给 Continue.dev 单独建 Key
建议在 DeepAI 后台给 Continue.dev 单独创建 Key。这样你可以单独统计它的调用量,也能快速判断是否是代码助手导致消耗上升。
流式输出中断怎么办
Continue.dev 使用流式输出时,可能遇到:
- 回答到一半停止;
- 一直 loading;
- stream disconnected;
- VS Code 面板没有完整渲染。
排查顺序:
1. 用非流式请求测试模型是否正常; 2. 换一个模型测试; 3. 减少上下文长度; 4. 检查代理是否中断长连接; 5. 检查公司网络、VPN、透明代理; 6. 查看 DeepAI 后台是否有完整调用记录; 7. 查看 Continue.dev / VS Code 开发者控制台日志。
如果非流式能通、流式失败,问题通常在客户端、代理或网络长连接处理,而不是 DeepAI Key 本身。
代码任务应该怎么选模型
代码任务不是所有模型都适合。选择模型时建议看五个维度:
| 维度 | 说明 |
|---|---|
| 代码能力 | 是否擅长生成、重构、理解代码 |
| 上下文长度 | 能否容纳足够项目上下文 |
| 速度 | 是否适合频繁交互和补全 |
| 成本 | 是否能承受高频调用 |
| 稳定性 | 是否容易中断、报错、超时 |
常见策略:
- 日常解释代码:用速度较快、价格适中的模型;
- 复杂重构:用更强的代码模型;
- 自动补全:优先低延迟、成本可控;
- 长文件分析:优先上下文更长的模型;
- CI / 自动化任务:优先稳定和成本可控。
DeepAI API 中转站的价值在于,你可以通过统一入口切换和管理这些模型,而不是每个工具都重新配置一遍。
Continue.dev 和 Cline、Aider、Roo Code 的区别
它们都能用于代码任务,但定位不同:
| 工具 | 更适合 |
|---|---|
| Continue.dev | 编辑器内辅助、代码解释、补全、轻量重构 |
| Cline | Agent 式改代码、执行命令、跨文件任务 |
| Aider | Git 工作流、命令行结对编程 |
| Roo Code / Kilo Code | IDE 内 Agent 工作流 |
| Chatbox / LobeChat | 通用聊天,不直接嵌入编辑器 |
如果你希望模型直接参与编辑器里的日常编码,Continue.dev 很适合。如果你希望 Agent 自己读文件、改文件、跑命令,Cline / Roo Code 会更像自动化助手。
站内可以继续阅读:
- https://paper.deepai.wang/chatbox-deepai-openai-compatible-api-tutorial/
- https://paper.deepai.wang/lobechat-deepai-openai-compatible-api-tutorial/
- https://paper.deepai.wang/openwebui-deepai-openai-compatible-api-tutorial/
- https://paper.deepai.wang/openai-compatible-api-cherry-studio-dify-cline/
推荐配置清单
| 项目 | 建议 |
|---|---|
| Provider | OpenAI / OpenAI-compatible |
| Base URL | https://api.deepai.wang/v1 |
| API Key | 给 Continue.dev 单独创建 Key |
| 聊天模型 | 选择代码能力强、上下文足够的模型 |
| 补全模型 | 选择低延迟、成本可控的模型 |
| Embedding | 需要代码库检索时再配置 |
| 上下文 | 排除构建产物、依赖目录、锁文件 |
| 排查 | curl、Continue 日志、DeepAI 日志三方对照 |
FAQ
Continue.dev 可以接 DeepAI API 中转站吗?
可以。只要使用 OpenAI-compatible 配置,把 Base URL 填为 https://api.deepai.wang/v1,再填写 DeepAI API Key 和模型 ID 即可。
Continue.dev 的 Base URL 要不要写 /chat/completions?
一般不要。推荐填写 https://api.deepai.wang/v1。Continue.dev 会自动拼接聊天接口路径。
为什么 curl 能通,Continue.dev 不通?
通常是配置文件没有生效、字段名不匹配、VS Code 没重载、插件读取旧配置、或代理设置不同。先简化配置,只保留一个模型测试。
自动补全为什么消耗很高?
自动补全是高频调用,每写几行代码就可能触发一次。建议给补全单独配置更快、更便宜的模型,或者在不需要时关闭 Tab autocomplete。
Continue.dev 需要 Embedding 模型吗?
不一定。普通聊天和解释当前代码可以先不配。需要代码库语义检索、跨文件召回时,再配置 Embedding 模型。
模型 ID 应该在哪里看?
以 DeepAI 后台、模型列表接口或实际 curl 测试结果为准。不要把展示名当成模型 ID。
总结
Continue.dev 接入 DeepAI API 中转站,最基础的配置只是 Base URL、API Key 和模型 ID。但如果你希望它真正成为可长期使用的代码助手,还需要进一步考虑模型分工、上下文控制、自动补全成本和错误排查方式。
推荐的落地方式是:先用一个聊天模型跑通基础对话,再配置补全模型,最后按需配置 Embedding。每一步都用 curl、Continue.dev 日志和 DeepAI 后台日志对照验证。
这样配置完成后,Continue.dev 就可以成为你在编辑器里的 DeepAI API 入口:日常解释代码用快模型,复杂重构用强模型,自动补全用低延迟模型,成本和稳定性也更容易控制。