Continue.dev 实战——在 VS Code/JetBrains 里接本地模型
Continue.dev 实战——在 VS Code/JetBrains 里接本地模型
适读人群：注重代码数据隐私的开发者 | 阅读时长：约14分钟 | 核心价值：完整配置 Continue.dev + Ollama，清楚哪些场景本地模型够用
去年底，我们团队接了一个银行的项目。
需求评审的时候，对方技术负责人专门问了一句："你们用 AI 辅助开发，代码会不会上传到云端？"
我当时没正面回答，因为我自己也没想清楚。回去查了下，GitHub Copilot 的用户协议里写着代码片段会用于模型训练（可以关闭，但默认开启），Cursor 的代码也会发送到他们服务器做推理。对于涉及核心业务逻辑、内部接口设计的代码，这确实是个问题。
那次之后，我开始认真研究本地模型方案。Continue.dev + Ollama 是我最终选定的组合。
Continue.dev 是什么
Continue.dev 是一个开源的 IDE AI 编程助手插件，支持 VS Code 和 JetBrains 全系 IDE。它的核心价值是：你可以接任何模型，不管是本地运行的 Ollama，还是云端的 OpenAI、Anthropic，完全由你配置。
相比 GitHub Copilot 和 Cursor，它最大的区别是：
GitHub Copilot = 固定产品，功能完整，没有自定义空间
Cursor = 功能更强，但模型固定（GPT-4/Claude），代码经过 Cursor 服务器
Continue.dev = 灵活配置，可以完全本地，代码不出局域网开源地址：github.com/continuedev/continue，Star 数量在 AI 编程工具里算前列的。
环境准备：先把 Ollama 跑起来
Continue.dev 本身不包含模型，它只是一个接口层。本地模型我用 Ollama 跑。
安装 Ollama：
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.ai/install.sh | sh
# Windows
# 去 ollama.ai 下载安装包安装完之后，拉模型。代码补全我推荐 deepseek-coder，Chat 我用 qwen2.5-coder：
# 代码补全专用（小模型，响应快）
ollama pull deepseek-coder:6.7b
# 代码对话（能力更强）
ollama pull qwen2.5-coder:14b
# 如果机器配置一般，7b 够用了
ollama pull qwen2.5-coder:7b拉完之后验证一下：
ollama list
# 应该能看到刚才拉的模型
ollama run deepseek-coder:6.7b
# 能交互就说明正常
# 按 Ctrl+D 退出Ollama 默认在 http://localhost:11434 提供 API，兼容 OpenAI 接口格式。
我的机器是 M2 MacBook Pro 16G 内存，跑 14b 模型推理速度大概是每秒 15-20 个 token，勉强够用。要流畅的话推荐 32G+，或者跑 7b 模型。
安装和基础配置 Continue.dev
VS Code 安装：
扩展市场搜索 "Continue"，找到 continuedev 发布的那个，安装。
安装完左侧出现一个 Continue 的图标，点击进入。
配置文件位置：
- macOS/Linux：
~/.continue/config.json - Windows：
%USERPROFILE%\.continue\config.json
也可以在 Continue 面板里点击右下角的设置图标直接打开配置文件。
完整配置文件（本地模型版本）：
{
"models": [
{
"title": "Qwen2.5-Coder 14B (本地)",
"provider": "ollama",
"model": "qwen2.5-coder:14b",
"apiBase": "http://localhost:11434"
},
{
"title": "Qwen2.5-Coder 7B (本地·快速)",
"provider": "ollama",
"model": "qwen2.5-coder:7b",
"apiBase": "http://localhost:11434"
}
],
"tabAutocompleteModel": {
"title": "DeepSeek Coder 6.7B",
"provider": "ollama",
"model": "deepseek-coder:6.7b",
"apiBase": "http://localhost:11434"
},
"tabAutocompleteOptions": {
"useCopyBuffer": false,
"maxPromptTokens": 1024,
"debounceDelay": 500
},
"customCommands": [
{
"name": "review",
"prompt": "请对以下代码进行 Code Review，重点关注：1. 逻辑错误 2. 安全问题 3. 性能隐患。给出具体改进建议，不要只说'代码很好'：\n\n{{{ input }}}",
"description": "代码 Review"
},
{
"name": "test",
"prompt": "为以下代码生成单元测试，覆盖正常流程和边界条件，使用项目已有的测试框架：\n\n{{{ input }}}",
"description": "生成单元测试"
},
{
"name": "doc",
"prompt": "为以下代码生成文档注释，要求简洁清晰，重点说明参数含义和返回值，不要废话：\n\n{{{ input }}}",
"description": "生成文档注释"
}
],
"contextProviders": [
{
"name": "code",
"params": {}
},
{
"name": "docs",
"params": {}
},
{
"name": "diff",
"params": {}
},
{
"name": "terminal",
"params": {}
},
{
"name": "problems",
"params": {}
},
{
"name": "folder",
"params": {}
},
{
"name": "codebase",
"params": {}
}
],
"slashCommands": [
{
"name": "edit",
"description": "Edit selected code"
},
{
"name": "comment",
"description": "Write comments for the selected code"
},
{
"name": "share",
"description": "Export the current chat session to markdown"
},
{
"name": "cmd",
"description": "Generate a shell command"
}
]
}如果你也想保留一个云端模型作为备用（比如 Claude API），可以这样加：
{
"models": [
{
"title": "Qwen2.5-Coder 14B (本地)",
"provider": "ollama",
"model": "qwen2.5-coder:14b",
"apiBase": "http://localhost:11434"
},
{
"title": "Claude 3.5 Sonnet (云端备用)",
"provider": "anthropic",
"model": "claude-3-5-sonnet-20241022",
"apiKey": "sk-ant-你的key"
}
]
}云端模型我只在本地模型处理不了的复杂场景才切换，日常开发全用本地。
JetBrains（IntelliJ IDEA）的配置
JetBrains 用户在插件市场搜 "Continue"，安装后重启。
配置文件和 VS Code 共用同一个 ~/.continue/config.json，不需要重复配置。
但 JetBrains 里有个细节：代码补全在 IDEA 里的触发方式和 VS Code 略有不同，需要在 Settings > Editor > General > Code Completion 里确认 Continue 的补全有没有和 IDEA 内置补全冲突。我的做法是把 Continue 的补全快捷键改成 Alt + \，和 IDEA 原生的不冲突。
本地模型 vs GitHub Copilot：实测体验
我用了差不多两个月，在同样的任务上对比了本地模型和 GitHub Copilot 的体验。
代码补全（Tab 补全）
GitHub Copilot：
- 响应速度：非常快，几乎感觉不到延迟
- 补全质量：准确率高，特别是主流框架
- 上下文理解：理解多文件上下文，能补全跨文件引用的类
本地 DeepSeek Coder 6.7b：
- 响应速度：有明显延迟，大概 0.5-2 秒
- 补全质量：简单补全差不多，复杂逻辑明显差一截
- 上下文理解：只看当前文件，跨文件理解弱坦白说，代码补全上本地模型差距明显。如果你的核心需求是补全流畅度，本地模型暂时还代替不了 Copilot。
Chat 对话（询问代码问题、生成代码片段）
这里差距缩小很多。我用 Qwen2.5-Coder 14b 做了一些测试：
场景1：解释一段 Java 代码逻辑
- Copilot Chat：清晰，准确
- Qwen2.5-Coder 14b：清晰，准确，差不多
场景2：帮我重构一个方法，把嵌套 if 用策略模式改写
- Copilot Chat：给出合理的重构方案
- Qwen2.5-Coder 14b：给出的方案质量相当
场景3：帮我写一个 Python 数据处理脚本（处理 CSV，做一些聚合计算）
- Copilot Chat：一次性写出可运行的代码
- Qwen2.5-Coder 14b：也能写出来，但偶尔有小错误需要修正
SQL 生成和调试
GitHub Copilot：理解复杂 SQL，包括 CTE、窗口函数
本地模型：常见 SQL 没问题，复杂场景偶尔出错我的结论：
本地模型够用的场景：
- 不涉及跨文件上下文的代码对话
- 解释现有代码
- 生成简单工具函数、数据处理脚本
- SQL 生成（常见场景）
- 代码审查和优化建议
本地模型明显差距的场景：
- Tab 自动补全（延迟高、准确率低）
- 需要理解整个项目结构的重构
- 复杂算法实现
- 不常见框架的使用
数据隐私的实际价值
回到最开始那个银行项目的问题。
用本地模型之后，代码完全不出机器。对方的技术负责人再问这个问题，我可以直接说：模型运行在本地，代码不会发送到任何外部服务器。
这对于以下场景有实际价值：
- 涉及商业机密的核心业务逻辑
- 金融、医疗、政务类项目的合规要求
- 含有 API key、密码等敏感信息的配置代码
- 公司明确规定代码不能出内网的情况
当然，大多数互联网公司的普通业务代码不涉及这些问题。如果只是普通的增删改查，用 Copilot 或 Cursor 完全没问题，效率更高。
本地模型是一种选项，不是必选项。知道它的存在，在需要的时候能用上，这才是关键。
配置细节：提升本地模型体验
调整 debounceDelay。 本地模型响应慢，补全延迟太长会很烦躁。我把 debounceDelay 调成 500ms，意思是你停止打字 500ms 后才触发补全，避免一直触发但还没响应的尴尬。
maxPromptTokens 不要设太大。 本地模型处理长上下文时速度更慢。我设 1024，对代码补全场景够用，响应速度也还可以。
多个模型按场景切换。 在 Continue Chat 面板顶部可以选模型。我日常用 7b 的快速模型，遇到复杂问题再切 14b。补全固定用 6.7b 的 DeepSeek Coder，它在补全任务上比通用模型准确。
配合 .continuerc.json 做项目级配置。 和 Cursor 的 .cursorrules 类似，Continue 支持在项目根目录放 .continuerc.json：
{
"systemMessage": "你是一个 Java Spring Boot 专家。本项目使用 Java 17 + Spring Boot 3.2，MyBatis-Plus ORM，不使用 Lombok。代码生成时请遵循构造器注入、Result<T> 返回值包装等团队规范。"
}这个文件也应该提交进 Git，和 .cursorrules 一样的逻辑。
Continue.dev 不是要取代 Copilot 或 Cursor，它是一个补充选项。在数据隐私要求高的场景，或者你就是喜欢折腾、喜欢完全掌控工具链的情况下，它值得认真配置。
而且它是免费的、开源的。这也是一个理由。