1. 先聊聊我为什么越写越累我印象最深的一次是给一个老项目写接口对接。需求本身不复杂但光是“查老代码里这个函数怎么用、看另一个项目里类似的写法、再复制过来改参数”这个流程就重复了十几次。等到真正动手写的时候思路早就被切成一小块一小块心流断得稀碎。这种累不是体力上的累而是注意力被反复打断的累。仔细盘了一下日常我写代码慢的大部分原因还真不是打字慢而是下面这几件事在拖后腿重复劳动太多。同样的初始化逻辑、同样的增删改查、同样的异常处理样板几乎每个项目都要重敲一遍敲到后面肌肉记忆都有了脑子却完全不需要参与。上下文切换太频繁。写两行就要切去浏览器翻文档、翻旧代码、翻示例回来还要花几分钟恢复刚才的思路。看似每段只花一两分钟一天攒下来就是不知不觉的一两小时。工具配置不给力。比如 VS Code 里写 C/C 时没有代码提示IntelliSense 配置了半天还是满屏红色波浪线。这种问题不解决就会一直磨人可解决了又未必提升多少产出特别两头难。小细节琐碎磨人。改一个变量名要手动找引用加一个字段要翻三个文件还要同步改注释、改日志、改前端展示这种活最耗耐心。所以我那段时间的核心诉求特别明确找一个能帮我“把样板代码直接生成出来、在我敲下一行之前先给出合理建议、我提问时能基于当前项目代码回答、改代码时顺手把相关位置一起改掉”的工具。说白了是一个真正理解“我当前正在写什么”的助手而不是又一个套壳聊天框。试了一圈之后真正留在我编辑器里天天用的是一款开源免费的 AI 编程助手插件。接下来我把选型过程、安装配置、提示词调优和踩坑经验全部写出来也分享一份可以直接抄作业的配置模板。如果你正在被“写代码速度慢”“没有代码提示”“重复劳动多”这类问题折磨这篇应该能让你少走不少弯路。2. 选型实录市面上这么多 AI 插件我为什么偏偏选了它2.1 当时对比过的几款主流方案我先说结论AI 编程助手这个赛道现在非常热闹但大部分人是“装上即巅峰”用两天就弃了。原因多半不是产品不好而是选型时只看了宣传页没对应上自己的真实场景。所以我把主流的几类都拉出来放在一张表里先有个全局观。方案形态是否免费是否开源模型接入主要编辑器GitHub CopilotIDE 插件订阅付费否封闭托管VS Code / JetBrainsCursor / Trae独立 IDE部分免费部分开源内置为主自带编辑器通义灵码IDE 插件免费否内置为主VS Code / JetBrainsCodeGeeXIDE 插件免费部分云模型或本地VS Code / JetBrainsContinueIDE 插件开源免费是自由接入云/本地模型VS Code / JetBrains看这张表能发现几件事。第一免费选项里通义灵码和 CodeGeeX 都是“内置模型为主”优点是开箱即用缺点是模型能力、提示词规则这些你基本说了不算。第二Copilot 体验很丝滑但封闭生态意味着你没法按自己的需求去调底层提示而且它只做了补全和对话对“改代码”的支持一直都比较保守。第三Cursor 这类独立 IDE 确实香但问题是要换编辑器旧项目的快捷键、配置、插件生态都要重新适应迁移成本不比换工作低。2.2 最终定下的插件以及选它的三个理由我最后定的是 Continue一款开源免费的 AI 编程助手插件。严格说它不是唯一的答案但对我来说是“刚刚好”的那一个。理由有三条你可以对照自己的情况参考。一是“免费且开源”意味着底层透明。你完全自己掌控数据流向模型、接口、规则都能自己定。这点对大多数开发者来说很重要尤其是公司项目里代码可能涉及内部逻辑时我不想把代码喂给一个不明不白的黑盒。二是它支持自由接入模型。既有 DeepSeek 这类云端 API也有 Ollama 这类本地模型云端贵了切本地本地不够用再切云端主动权始终在我手里。三是它把“规则设定”和“提示词工程”做成了第一公民。全局规则、项目规则、自定义命令这些能力让它不是一个只会补全的哑巴工具而是能真正理解团队规范和个人写码习惯的“实习生”。这一点我放在第 4 节详细讲也是我认为它和同类工具拉开差距的关键。2.3 插件和独立 IDE 的取舍也有人问我直接用 Cursor 这类 AI IDE 不就行了我的看法是分场景。新项目从零开始或者你本来就习惯折腾新工具独立 AI IDE 的体验确实更完整因为它把模型、补全、对话、代码索引全都揉进了一套体验里。但如果你和我一样手上有一堆维护中的老项目VS Code 和 IDEA 里还装着大量已有的快捷键、片段和自定义插件那用插件方案明显更稳妥不改变原有工作流只是往里面加一层 AI 能力。还有一个容易被忽略的细节插件和现有生态能共存。比如我平时会用 Git Graph 看分支、用 Todo Tree 管理待办、用 Docker 插件操作容器这些在独立 AI IDE 里未必有同等完善的对齐。选择插件等于不动地基、只换装修。3. 实操从安装到跑通前后大概十五分钟3.1 安装VS Code 和 JetBrains 两条线先说 VS Code。打开扩展商店快捷键 CtrlShiftX搜索 Continue认准官方发布的那个装就行。也可以用命令行装适合规模化同步多台设备code --install-extension continue.continueJetBrains 系IDEA、PyCharm、WebStorm、GoLand 操作都一样走 SettingsmacOS 是 Preferences里的 Plugins搜 Marketplace找到 Continue 安装后重启 IDE。装完一般在侧边栏会多出一个对话图标左下角状态栏也会出现 Continue 的入口。这里有个小提醒不少朋友装了插件后找不到入口多半是装了旧版本或者装到了错误的 VS Code 实例。VS Code 的扩展是分用户级和工作区级的窗口标题栏能直接切换到某个工作区时要确认扩展是否在当前这个实例里启用。JetBrains 则要确认装的是当前 IDE 版本对应的插件装完必须重启不是热加载。3.2 接上大模型DeepSeek API 和本地模型两条路Continue 默认不带模型需要你自己接。第一次安装完打开聊天面板它会引导你选择模型提供商按界面提示操作就行。我这边把配置放在一句能看懂的话里你的配置是工作区里的 .continue/config.yaml新版默认 yaml旧版可能是 config.json。以 DeepSeek API 为例配置大概是下面这样name: 我的工作区配置 version: 1.0.0 schema: v1 models: - name: DeepSeek Chat provider: deepseek model: deepseek-chat apiKey: ${DEEPSEEK_API_KEY} roles: - chat - name: DeepSeek Coder provider: deepseek model: deepseek-coder apiKey: ${DEEPSEEK_API_KEY} roles: - autocomplete - edit注意两个细节。第一apiKey 用环境变量引用别把 key 直接写进这个文件。你在 DeepSeek 开放平台建好 API Key 后macOS/Linux 在 ~/.zshrc 或 ~/.bashrc 里写 export DEEPSEEK_API_KEYsk-xxxWindows 用 setx DEEPSEEK_API_KEY sk-xxx配置完重启编辑器即可。第二模型名称比如 deepseek-chat、deepseek-coder要以你账号后台当前展示的为准各家更新很快配置文件里填死的名字如果不存在请求会直接报错。不想用云 API 的话本地模型方案也成熟。装一个 Ollama拉取带代码能力的模型常见的选择是 qwen2.5-coder 的 7B 和 14B 版本然后把上面配置里的 provider 换成 ollamamodel 名填你实际拉取的模型名就行。本地模型的好处是隐私和免费不足之处是补全速度取决于机器性能硬件普通的机器开大模型做自动补全会明显感觉到延迟。models: - name: Local Qwen provider: ollama model: qwen2.5-coder:7b roles: - chat - autocomplete3.3 三场快速实测装上到底有没有用光装不算数我按三个最常用的场景各测一遍。第一场补全。我新建一个 Python 文件写一个分页函数只写到 def paginate(query, page, page_size): 这一行按一下 Tab插件会根据对上下文的判断给出函数实现建议包括参数校验、总页数计算和返回结构。质量好的补全不只是“续写”而是能结合你项目里已有的写法风格来续。第二场对话问答。选中一段看不懂的老代码在 Chat 面板里问它“这段代码在做什么有没有潜在 bug”插件可以直接读取当前选中内容回答会带着行号和上下文比你去搜索框里复制粘贴再人工翻译高效得多。第三场改代码。选中一个函数让它“把这里改成不依赖全局变量的写法”插件产出 diff你自己确认后再应用。它不像某些工具那样直接把代码糊到你文件里而是把改动做成可预览的 diff这一点在真实项目里非常重要因为 AI 改的并不总是你想要的。实测下来的体感补全能顶住日常 30% 以上的样板代码问答能帮我快速理解不熟悉的模块改代码的场景最费心但收益也最大。一个“能聊天、能补全、能改代码”的插件把原本散落三四个工具里的能力收敛到了一个侧边栏里这是我愿意一直留着它的直接原因。4. 让它“更懂你”规则设定和提示词工程才是灵魂4.1 全局规则先把“个人偏好”说清楚很多人装上 AI 插件后觉得答案“不够好”其实问题不在模型在指令。默认情况下模型对你有什么代码风格、什么工程约束、什么安全和性能底线一概不知。所以你应该花十分钟把规则写清楚再让 AI 干活。Continue 的设置里有一段 Global Rules所有对话和补全都会带着它。我自己的版本可以参考- 回答代码问题时先给结论再给实现不要上来就甩一大段代码。 - 生成代码必须带简要中文注释注释解释“为什么”不要复述“是什么”。 - 遇到性能敏感场景在回复开头明确提醒。 - 不使用已废弃 API优先使用标准库其次再引入依赖。 - 涉及文件路径时基于当前工作区给出相对路径。规则不是越多越好写得太长模型反而会“忘掉”重点。我建议全局规则控制在 5 到 8 条只留最高频、最关键的原则。改规则后记得让新会话生效避免旧会话的上下文还保留旧指令。4.2 项目规则把团队规范塞进 AI 脑子里比全局规则更进一步的是项目级规则。Continue 的配置文件里支持带 glob 匹配的规则也就是不同文件类型走不同的规范。举个例子rules: - glob: *.py rule: | 所有 Python 代码遵循 PEP 8。 函数与方法的参数必须带类型注解。 模块顶部必须有 docstring 说明模块职责。 - glob: *.sql rule: | SQL 关键字一律大写。 表名字段名使用下划线命名。 禁止使用 SELECT *。团队合作时这个功能的价值会被放大。公司项目里如果有“错误码规范”“日志格式规范”“接口命名规范”把这些写进项目规则里AI 生成的代码就会自动对齐不再需要每次在提示词里反复唠叨。我见过不少团队把规则文件同步进 git 仓库新同事拉下来配好插件AI 助手生成的第一版代码就已经符合团队规范省掉了大量 review 循环。4.3 自定义命令把常用提示词固化成“快捷键”Continue 支持自定义 slash 命令本质上就是把一段精心设计过的提示词模板挂载到一个简短命令后面。我常用的三个命令给你参考commands: - name: review description: 审查选中代码 prompt: 请从可读性、性能、安全性三个维度审查下面的代码给出问题清单和重构优先级{{{ input }}} - name: test description: 为选中代码生成单元测试 prompt: 为下面的代码生成单元测试使用项目现有的测试框架和命名规范覆盖正常、边界、异常三类情况{{{ input }}} - name: commit description: 生成提交信息 prompt: 根据当前 git diff 生成一条提交信息不超过 50 字符合 conventional commits 格式{{{ input }}}这套做法的意义在于把你自己摸索出来的有效提示词沉淀成团队资产。第一次调提示词可能花十分钟但只要调通了一条之后每次使用都只需要敲两个字母。这就是提示词工程的实际落地方式——不是每句话都靠现场想而是把高频场景模板化、版本化。5. 用了两个月的真实体感哪些是真香哪些要避坑5.1 帮我省时间的几个瞬间最明显的是写 C/C 时的兜底。之前我在 VS Code 里写 C 没有代码提示排查下来是头文件包含路径没配好IntelliSense 一直找不到标准库的位置。这种问题配置确实复杂AI 插件能根据当前文件的 include 和上下文给出代码补充虽然不能替代完整的 IntelliSense但至少不会让你卡在原地。当然根本解法还是把 C/C 插件和 includePath 配好AI 补全是兜底不是替代。第二个省时间的场景是“改一处连带改多处”。比如一个字段改了名字AI 能顺着引用关系帮你找相关调用处批量生成修改建议。虽然它不会像重构工具那么精确但当你只需要“大概知道还有哪些地方受影响”时用它问一嘴比手动全局搜索效率高得多。第三个是生成测试和文档。写单测这件事很多人不爱做不是不会而是觉得启动成本高。我把某个函数选中敲 /test不到十秒它就能按当前项目风格生成一份测试骨架我再往里面补断言和边界用例比从空白文件开始写快很多。文档注释同理几行注释生成得又快又规整。5.2 避坑清单这些坑我踩过你就不用踩了别把“黄色高亮”当成插件坏了。在 IDEA 里写代码时突然出现黄色高亮占好几行通常不是 AI 插件的锅而是编译器给你的“未使用代码”“类型不匹配”警告如果那段文字是灰色或浅色的建议文本那才是 AI 插件的内联建议。两种东西一眼能分辨警告高亮会同步出现在 Problems 面板AI 建议则是可接受/可拒绝的补全候选。上下文上下文还是上下文。很多人喜欢一次性把整个文件甚至几个文件全塞给 AI结果是速度变慢、费用变高、回答质量下降。模型不是数据库给它 5000 行代码它做不了全文索引反而会被无关内容带偏。合理的做法是只选中当前问题相关的函数和类型定义。注意敏感代码。公司内部代码、密钥、带客户数据的 SQL别随便发给云端模型。用本地模型是最稳妥的方案或者至少在配置里关掉一些遥测项、用匿名化的示例问题来测试。模型选型直接影响体验。同一个插件接不同能力的模型补全和对话的水平有明显差异。先判断你缺的是“高质量分析”还是“快速补全”再决定把什么角色分配给什么模型。我个人的做法是对话和代码审查用强模型自动补全用速度快、成本低的模型这样成本和体验能平衡住。6. 常见问题与排查技巧实录6.1 高频问题速查表现象可能原因处理办法装好后侧边栏没有入口装到错误的扩展实例 / IDE 未重启确认扩展在当前工作区启用JetBrains 系需重启补全一直不出现模型角色没配 autocompleteAPI Key 无效本地模型没拉取检查配置文件 roles 字段测试 API 连通性确认 Ollama 已启动补全内容质量差上下文太小 / 模型选得太弱 / 规则过多选中更多相关代码换能力更强的模型精简规则IDEA 出现大面积黄色高亮编译器警告或 AI 内联建议看 Problems 面板区分AI 建议通常可用 Esc 忽略对话回答与项目无关上下文里没有引用项目文件用 符号把当前文件加入上下文不要只在全局聊天里提问配置改了不生效配置文件格式或字段名与版本不符查看日志和官方 schema保持 yaml 缩进正确6.2 我的排查“三板斧”第一板斧看日志。VS Code 里用输出面板切到 Continue 的日志通道JetBrains 里在 Help 菜单的 Log 里找。报错信息里能直接看到 API 返回的状态码绝大多数配置问题在这一步就能定位。第二板斧最小化复现。把当前工作区里其他插件全部禁用新建一个最小测试项目只配置一个模型看是否复现。这一步能快速区分“插件问题”还是“我的项目配置问题”。第三板斧校验配置。yaml 的缩进错了、字段名拼错了都会导致配置被静默忽略。把配置内容贴到本地 yaml 校验工具里跑一遍再对照当前版本官方文档的 schema基本能排除九成问题。养成一个好习惯每次改配置后先在聊天面板发一条消息看有没有正常响应再进入工作状态。7. 文末福利送你一份可以直接抄作业的配置清单按照之前约好的最后是一份福利。我把自己用了两个月的整套配置整理成了一个压缩包里面包括一份带注释的 config.yaml 模板默认接 DeepSeek API同时附了 Ollama 本地模型的注释写法直接复制改名就能用。一份全局规则清单包含我在第 4 节里写的全部规则外加几条我在实际项目中补进去的安全和规范条款。十个常用 slash 命令覆盖代码审查、单元测试、提交信息、Bug 分析、SQL 优化、接口文档生成等高频场景。一份模型搭配对照表不同任务补全、对话、代码审查、重构建议用哪些模型成本、速度、效果怎么取舍。获取方式很简单在这篇博文下面留言或者私信我发一句“配置全家桶”我看到后会统一把下载链接发给你。如果你不方便留联系方式还有一个办法——直接照着本文第 3 节和第 4 节的配置自己手敲一遍效果不会差太多而且你会对每一步配置心里有数。最后再分享一个小经验AI 插件这东西装上是起点调好才是分水岭。那 15 分钟的安装配置只是把工具放进工具箱真正拉开效率差距的是后面那半小时的规则设定和提示词沉淀。我建议你每周花十分钟回顾一下自己的高频操作把“每次都要重新说一遍的废话”固化成规则或命令一个月后再回头看写代码的状态绝对不一样。