老读者都知道我有个毛病新工具出来先装一遍装完先翻配置文件夹配置看不懂直接卸载。Continue.dev 是少数几个让我装完没卸载、而且越用越觉得顺手的开源 AI 编程助手。今天不写软文就把我这一周折腾 Continue.dev 的过程、配置思路和踩坑记录全部摊开聊。1. 先说清楚Continue.dev 到底解决我的什么问题1.1 它和那些“聊天式助手”的本质区别Continue.dev 是一个开源的 AI 编程助手以 IDE 插件的形式工作。它把“代码补全”和“对话式编程”两件事放进同一个侧边栏里同时最大程度保留了你对模型、上下文、系统提示词的控制权。这工具的核心价值对我来说就三点模型随便换。想用本地小模型跑补全就用本地想调用云端大模型做复杂重构就切云端。一切由配置文件说了算不需要切换软件。上下文不是黑盒。它允许你自定义规则、做代码库索引、把多个文件作为上下文一起丢给模型。你甚至能指定“从某个模块目录补充上下文”对经常在大型代码库里干活的人帮助不小。免费。开源免费没有按量计费的心理负担符合“你值得拥有”的评价。很多同类助手要么只能补全要么只能聊天要么把自己限制在自家模型生态里。Continue.dev 把选择权还给了开发者这是它能留在我的工作流里的根本原因。1.2 如果你还在观望对照一下自己的场景如果你符合下面任一情况我觉得完全可以试试它你在公司内网开发没法把代码传到外部服务需要跑本地模型。你手上同时有多个项目每个项目的技术栈、规范都不一样你希望 AI 的回复“入乡随俗”而不是一套话术打天下。你不想每个月固定订阅付费想自己掌控调用成本。你想在不同大模型之间比较效果找一个真正贴合自己工作流的组合。如果你只是想“装个助手然后什么都不管”那 Continue.dev 可能反而让你觉得麻烦因为它默认不绑定任何云端账号你需要自己完成一次初始配置。但这也正是它最值得花时间的地方配置一旦跑通后续的收益是持续的。2. 安装和环境准备别上来就装插件2.1 我的硬件和软件基础清单先交代一下我实际使用的环境方便你对号入座操作系统主流桌面系统。Windows / macOS / Linux 都支持我主要在 macOS 上测但配置方式完全一致。IDEVS Code 和 JetBrains 系 IDE。Continue.dev 对这两类主流的支持做得比较完整。本地推理服务我额外装了一个本地推理运行时用 Docker 方式跑这样不需要污染系统环境。云端模型 API Key准备了一个用来做复杂任务。如果只打算用本地模型这一步可以跳过。2.2 安装插件的两种方式第一种直接在 VS Code 扩展市场搜索 “Continue”找到官方扩展点击安装。安装完成后重启侧边栏会多出一个新的图标点击就能打开对话面板。第二种去官网下载安装包在 JetBrains 系 IDE 的插件管理器里从本地文件安装。两种方式本质一样插件市场更方便。安装完成别急着用。最好先确认左下角或面板上出现模型下拉框如果里面没有任何模型列表说明还没配置模型。这时候就需要进入下一步写配置文件。2.3 首次启动的验证技巧首次启动我建议按顺序做三件事打开任意项目按快捷键调出对话面板输入“简述一下这个项目的目录结构”观察输出确认模型配置是否正常。如果回复是乱码、超时或明显的模板话说明模型没选对或上下文规则有问题。先用最简单的问题验证链路再逐步增加复杂度比直接丢一段大业务代码去问要稳得多。3. 核心配置把 config.yaml 吃透3.1 配置文件到底放在哪里Continue.dev 的配置本质上就是一个 YAML 文件文件名固定为config.yaml。默认情况下全局配置放在用户主目录下的.continue文件夹里。比如在 macOS 上就是~/.continue/config.yaml。但实际操作里我更推荐使用项目级配置在项目根目录下新建一个.continue文件夹把配置文件放进去。这样做的好处有三个可以跟随 Git 仓库提交团队成员统一行为。不同项目可以绑定不同模型、不同规则互不干扰。前端项目配前端规范后端项目配后端规范AI 直接入乡随俗。如果两个地方都有配置项目级配置优先。这个优先级规则非常重要我踩过一次坑后面会讲。3.2 关键字段逐项拆解我把自己实际使用中的配置简化出一个骨架给你逐段解释。name: My Coding Assistant version: 1.0.0 models: - name: 本地快速补全 provider: local-runtime model: code-coder:7b roles: - autocomplete - name: 云端主力 provider: cloud-api model: strongest-model default: true roles: - chat - edit - apply rules: - description: Python 规范 glob: **/*.py rule: 必须包含类型注解优先使用函数式写法 ignorePatterns: - node_modules - dist - build - .git逐项解释一下models列表你不想用一个模型包打天下。我把“补全”和“对话编辑”拆开补全用本地小模型理由是由延迟低、不占网络对话和代码修改用云端主力模型理由是需要更强理解力。roles这玩意类似“工种”。autocomplete是补全角色chat是对话角色edit是编辑器里的内联修改角色。你完全可以指定 A 模型负责补全、B 模型负责对话、C 模型负责代码修改。rules写进配置文件里的“系统提示词”。对某个目录、某种后缀的文件强制要求模型遵守特定规范。ignorePatterns告诉索引器不要扫描哪些目录省时省力还能避免代码泄露到上下文里。3.3 上下文与项目索引codebase 为什么好用Continue.dev 最有特色的能力之一是在对话中直接输入codebase让它对整个代码仓库建立索引然后基于整个仓库回答问题。这个机制底层会做两件事一是分析文件结构二是对内容做向量化/关键词索引。它带来的效果很直观你问“这个项目里有哪些地方用到了登录鉴权”它不会只回答当前文件而是把仓库里相关代码的引用都找出来。但我也要提醒一句代码库越大索引越慢。我第一次把整个旧系统项目丢进去构建索引用了接近十分钟而且中途风扇狂转。解决思路不是不用而是做约束。在ignorePatterns里把node_modules、dist、build、.git这类目录全部排除索引速度立刻快一大截。如果你项目特别大还可以考虑按模块建多个规则只在需要时用codebase指定子目录。3.4 用规则给 AI 立规矩规则这个东西初看觉得只是“额外提示词”实际用起来差别巨大。我举个例子。一个 Python 项目团队规范要求所有新代码带类型注解。如果不在规则里写清楚你让 Continue.dev 帮忙生成代码它大概率会输出一份干净但没有任何注解的代码因为底层模型的训练数据里什么风格都有。在规则里加上“必须包含类型注解”生成结果立刻规矩很多。对 Java、Go、前端项目同样思路适用。规则格式并不复杂一条规则包含描述、glob 文件匹配、具体内容。我建议每个项目至少配三条总则语气、长度、命名风格。分语言规则按*.py、*.tsx、*.go拆开。特殊目录规则比如tests/**里强制要求 pytest 风格。配置完不用重启直接在对话里新建会话就能生效。注意规则对已有会话不生效新会话才会加载最新配置。4. 五个高频实操场景从补全到重构到审查4.1 补全模式注释先行才是正确姿势补全功能很多人把它当成“自动打字机”期望它猜出你的每一步操作。实际效果最好的用法其实是“注释先行”。举个例子你准备写一个把字符串转驼峰格式的函数。不要直接敲函数名先写注释# 把下划线命名转成驼峰命名忽略空字符串返回新字符串。然后回车换行Continue.dev 的补全模型大概率会直接给出完整函数实现而且质量稳定。原因不神秘注释给了模型明确的输入、输出、边界条件模型是在“完成一个明确任务”不是在猜你心思。我试过两种姿势对比。直接写def toCamelCase():然后等补全经常会生成一个空壳函数内部逻辑靠猜。注释先行之后生成的内容通常直接可以跑。4.2 让 AI 解释历史遗留代码面对一段老代码最耗时的不是读语法而是理解业务意图。Continue.dev 在解释代码方面确实帮了大忙。我的操作路径很固定选中一段代码右键选择“Ask Continue”在对话框输入“这段代码在做什么有没有潜在问题用中文回答。”它自动会把当前选中的文件内容作为上下文不用你手动贴代码。这个优势是纯网页版 AI 助手不具备的。实操中我发现一次性问“这段代码在做什么”往往只能得到泛泛而谈。更好的方式是连续追问先问“列出这段代码的关键步骤”根据回答继续问“第 3 步里的循环如果数据量大了会不会有问题”再问“这个函数被哪些地方调用了”。一轮对话下来对老代码的理解速度比以往快不少。但有一点必须强调AI 对业务语义的理解是基于代码推测的真正的业务规则还是要对照文档和测试来验证。4.3 重构拆分给 AI 一个“目标函数”重构是 Continue.dev 的高价值场景但也是最容易失控的场景。我的经验是让 AI 做重构必须给它一个明确的目标函数而不是说“帮我优化一下这段代码”。比如有一段 200 行的函数我会选中它然后输入“把这段拆成三个小函数公共部分抽成单独的工具函数保留原函数名作为入口外层调用方式不变。”这样模型知道你要拆、拆成几个、怎么命名、保持兼容。它生成的建议通常可以直接落地。生成之后我从不直接接受全部修改。Continue.dev 的编辑建议会以 diff 形式展示我会逐段确认尤其是公共部分抽离的逻辑很容易出现边界条件遗漏。还有一条铁律重构之后立刻跑测试。不管 AI 说得多自信回归测试不过就是不行。4.4 单元测试生成从“先跑通”到“覆盖边界”写单元测试是 Continue.dev 表现最稳定的场景之一。我常用的方式是# 给下面的函数生成 pytest 单元测试 def calculate_discount(price, is_vip): if price 0: raise ValueError(price must be positive) if is_vip: return price * 0.8 return price * 0.9然后输入提示词“基于 pytest 生成测试覆盖正常输入、非 VIP 输入、价格小于等于 0 的异常分支、浮点数精度每个测试用 assert 明确断言结果。”它生成的测试基本能覆盖常规路径。但边界情况的覆盖质量取决于你有没有在提示词里明确提出。这跟现实中的同事指导很像说得越清楚活干得越到位。我见过不少朋友抱怨生成测试太浅其实问题多半出在提示词上。只写“生成测试”得到的当然是最常见 happy path 测试。把边界场景列出来效果立刻不一样。4.5 代码审查让助手当二传手代码审查是人类协作里的重要环节Continue.dev 可以作为初审员先筛一遍。我会先通过codebase定位到某个模块然后输入类似这样的指令“审查 modules/order/ 下的代码重点找潜在失败点、竞态条件、资源未释放问题、边界值处理不当输出问题列表并标注风险和修复建议。”它能给你列出几个问题点包括空指针风险、未关连接、异常被吞掉等。这套流程比我直接人肉读代码快得多。但它列出的问题必须逐条验证。有一次它提醒我“这段代码存在越界风险”我看了一下排除条件其实已经保证了安全这只是模型对上下文的误判。还有一次它没注意到一个明显的数据库连接未释放问题反而把注意力放在命名规范上。所以我的定位是AI 初审人类终审。把它当二传手和初筛效率提升明显把它当终极裁判会翻车。5. 踩坑实录和排查技巧5.1 常见报错修复速查表这里我整理了一份实际操作中遇到过的典型问题每一项都对应真实的排查过程。症状可能原因解决办法补全一直转圈不输出本地推理服务未启动先启动本地推理运行时再打开 IDE 重试配置不生效项目级配置覆盖了用户级配置检查项目根目录是否存在.continue/config.yaml模型返回超时云端接口响应过慢调长超时时间或临时切换到本地模型中文回复质量差系统提示词缺少语言要求在规则里加入“用简洁中文回答问题”代码库索引一直构建中项目文件太多太杂在ignorePatterns里排除依赖目录上下文塞入太多文件导致效果变差没有限定范围使用codebase时指定模块目录而不是整仓编辑建议直接应用后格式错乱没有 lint 验证应用前先预览 diff应用后跑格式化和 lint这里面有一个容易被忽略的小问题配置文件里如果 YAML 格式有误比如缩进用了 TabContinue.dev 会静默加载失败面板上不显示任何错误。排查办法是先用 YAML 校验工具检查一遍再重启 IDE。5.2 关于“长上下文”的认知纠偏我在实际使用中发现把越多代码塞给模型效果未必越好。早期我总觉得“上下文越多模型越懂我”于是动不动就codebase加多个文件引用。结果模型被大量文件干扰经常抓不住重點。后面我调整了策略先只给最小上下文让模型回答初步结构再针对具体模块单独提问。这个策略直观很多也明显降低了无用信息和 token 消耗。换个通俗的说法就像你找一个新同事帮忙看代码你不会把整个仓库的源码全丢给他再问他“帮我找 bug”。你给他指定一个模块、一段代码、一套规则他的判断才有方向。5.3 本地模型和云端模型怎么分工才顺手配置多个模型不难怎么分工才是大学问。根据我的使用体验可以做如下划分补全本地小模型。延迟低不打扰。常规对话云端主力模型。理解力强回答质量高。大批量文件编辑云端效果更好但必须仔细审阅 diff。敏感代码处理本地模型更安全因为不需要联网。这个分工背后有很现实的考量补全功能是高频低耗操作用本地模型几乎零延迟。复杂重构是低频高耗任务用云端模型能保证质量。两者互补正好搭配。5.4 为什么我最终说“你值得拥有”回到标题。一个工具值得不值得不是看它功能列表多长而是看它能否真正融入你的开发日常。Continue.dev 给我的体验是我可以完全掌控它用什么模型、理解哪些代码、遵守什么规范。又因为它是开源的遇到问题可以查源码去理解它的行为逻辑而不是对着一个黑盒瞎猜。配置阶段确实有门槛但过了门槛之后它从“插件”变成了“搭档”。它不会取代你思考但它能让思考更快地落到代码上。我个人最满意的一次使用经历是接手一个别人留下的老项目。原开发者只留了一句话注释“先跑起来再说。”我用 Continue.dev 把这个模块的入口、依赖、调用链逐步拆开一条条理解半天时间理清了背景。这个效率靠我自己硬啃至少得两天。所以我的结论很直接如果你愿意花一两个小时完成初始配置Continue.dev 完全对得起“你值得拥有”这个评价。如果你连配置都不想碰那它也拯救不了你——它毕竟是为愿意掌控工具的开发者准备的。