说实话我这几天被 VS Code 里这波 AI Chat 的更新弄得有点上头。以前我总觉得编辑器里的 AI 助手无非就是帮你补补括号、抄抄文档真正碰上逻辑复杂的需求还得自己老老实实翻源码。可最近把本地 Ollama 接进 VS Code 的 Continue 插件之后整个体验完全变了——不用联网、不排队、不担心代码外泄写代码的时候随手就能把一整段函数丢给 AI 去解释、重构甚至生成单元测试这种感受真不是之前的补全插件能给得了的。这文章就聊聊我最近实际用下来的东西VS Code 里的 AI Chat 到底有哪些打开方式、本地模型和云端模型怎么接、以及我在 C/C 开发场景里真正让 AI 帮忙干活的完整过程。不管你是刚装好 VS Code 的新手还是已经把编辑器调教到顺手的老手只要你想把手头这块“编辑器里的 AI”真正用起来这篇文章应该都能给你一点能直接抄作业的东西。1. 先看清局面VS Code 里的 AI Chat 到底有多少种选择1.1 内置方案GitHub Copilot Chat 与 Quick Chat 到底怎么用先说官方自带的那一套。VS Code 现在的内置 AI 能力已经不只是“补全代码”了左侧活动栏里多了一个聊天图标点开就是 GitHub Copilot Chat 的对话框你可以直接在侧边栏里跟 AI 连续对话而不是像以前那样只能在代码空行里等一个自动补全。这个侧边栏能做的事很多选中一段代码问它“这段函数在干嘛”它会直接给你输出带注释的解释你把整个报错信息贴进去它能分析出是空指针还是数组越界你甚至可以选中几个文件让它帮你做跨文件的代码审查这些功能早期版本根本做不到。还有一个很容易被忽略的入口是 Quick Chat默认快捷键是CtrlShiftIWindows/Linux或者CmdShiftImacOS类似命令面板那种浮层你不需要切到侧边栏直接在编辑器中间弹出一个小输入框问完一个问题按回车结果会以内联形式显示。我个人的习惯是遇到小问题、只需要快速确认 API 用法的时候用 Quick Chat 比打开侧边栏顺手太多几乎零打断感。但内置方案有个绕不开的问题Copilot Chat 需要登录 GitHub 账号并且开通相应订阅很多人会在这里卡住。另外一些朋友因为代码保密要求不太愿意把公司项目往云端模型里送。这时候本地模型和第三方 AI 插件的价值就体现出来了。1.2 开源与本地方案Continue 插件如何后来居上如果你不想被 GitHub 账号和订阅绑住Continue 这款插件基本是目前 VS Code 生态里最值得装的开源 AI Chat 方案。它的定位很纯粹把各种大模型接进编辑器给你一个统一的对话窗口。Continue 支持 OpenAI 系 API、Anthropic Claude、Google Gemini也支持通过 Ollama、LM Studio 这类工具连到本地模型关键是它还支持你在同一个对话里把“本地小模型”和“云端大模型”混合着用——这个设计非常实用比如日常解释代码用本地模型省钱省心遇到复杂重构再切换到云端的 Claude相当于一套界面、多种算力。Continue 的侧边栏交互跟 Copilot Chat 很像选中代码按CtrlLWindows/Linux或CmdLmacOS把选中内容加到上下文里再输入你的指令AI 就能结合代码内容给你回答。它还有/commands功能内置了/explain、/edit、/tests等快捷指令你可以一键让 AI 解释代码、帮你改代码或者生成单元测试而且这些指令是纯本地模板不涉及额外请求逻辑用起来特别顺手。我当时选 Continue 而不是继续折腾 Copilot 的另一个原因是它的配置文件是纯 JSON 的路径在用户目录下的.continue/config.json你可以在里面随意注册多个模型供应商甚至自己搭的网关也能接。这种可编辑、可版本控制、可定制的感觉才像开发者工具该有的样子。1.3 一个关键分水岭云端模型 vs 本地模型怎么选你可能会纠结到底用云端还是本地我的结论是别把两者对立起来它们解决的问题完全不同。云端模型的优势是智商高、上下文窗口大、对复杂逻辑的理解能力强。我用 Claude 系列模型做跨文件重构、解释一段晦涩难懂的网络协议代码时准确率确实高。缺点是数据要离开你电脑而且如果网络不稳定体验会很糟。另外如果你用的是需要单独付费的 API过度依赖的话月底账单也会有点吓人。本地模型的主打卖点是隐私和免费。你装一个 Ollama拉一个 7B 到 14B 的模型下来比如 Qwen2.5-Coder-7B、DeepSeek-Coder-V2-Lite 这类日常的代码解释、单函数补全、简单 bug 排查完全够用而且速度也不差。缺点也很明显小参数量模型在复杂任务上会“一本正经地胡说八道”生成的长代码往往需要你再改一遍。所以我的建议是走“本地为主、云端为辅”的混合路线。Continue 恰好支持这种玩法你在配置里把本地 Ollama 设成默认模型把云端模型放在备选列表里只有在本地模型明显搞不定的时候再手动切换。这样既保住了日常聊天响应速度又能在关键时刻调用大模型兜底。2. 动手接入在 VS Code 里跑起第一个本地 AI Chat2.1 装好 VS Code确认扩展市场可用工欲善其事必先利其器很多人其实已经在用 VS Code 了但如果你是从零开始先确认一下安装版本。打开 VS Code 之后在“帮助”菜单里找到“关于”记一下版本号我建议至少是 1.85 以上太老的版本对部分新插件的支持会有问题。另外从官网下载安装包的时候注意区分 User Installer 和 System Installer我个人建议普通用户选 User Installer不需要管理员权限能避开后面很多 EPERM 权限报错。安装完成后打开左侧的扩展商店图标先试一下能不能正常加载扩展列表。如果扩展市场一直转圈、加载不出来优先检查网络的代理设置如果在公司内网可能需要配置代理才能访问微软的扩展市场。这一步解决不了的话后面装什么都无从谈起。还有一个容易被忽略的小动作装完 VS Code 之后建议顺手开启“设置同步”登录微软账号或者 GitHub 账号这样你换电脑的时候所有扩展、快捷键、配置都能一键恢复省去重新配环境的痛苦。2.2 安装 Continue 并完成 Ollama 本地模型配置扩展市场里搜“Continue”认准那个紫色图标的 Continue 扩展作者是 Continue Dev安装量很大一般不会认错。装完之后左侧栏会出现一个 Continue 的图标点开就是一个空对话框。接下来要解决的是模型从哪来的问题。这里我强烈推荐用 Ollama因为它对新手最友好装好就带命令行管理模型没有 Python 依赖、不需要手动下载模型文件。去 Ollama 官网下载对应系统的安装包macOS 和 Windows 都有图形化安装程序装完在终端里执行ollama pull qwen2.5-coder:7b这一步会把模型镜像拉到本地7B 参数的大概 4.7GB根据网速等一会儿。拉完之后你可以先在终端里跑一句ollama run qwen2.5-coder:7b验证一下模型能不能正常对话确认没问题再切回 VS Code。这时候回到 Continue 侧边栏它会弹出一个选择模型的界面。你找到 Ollama 那一栏模型 ID 填qwen2.5-coder:7b保存即可。如果界面里没有自动发现 Ollama你还可以手工编辑配置文件。打开命令面板CtrlShiftP搜“Continue: Open Config”会打开config.json在 models 数组里加这么一段{ title: Qwen Coder Local, provider: ollama, model: qwen2.5-coder:7b }保存之后重新打开 Continue 侧边栏选择这个模型随便输一句“用 Python 写一个快速排序”如果它能正常回复恭喜你本地 AI Chat 已经跑通了。2.3 在 WSL2 里跑 Ollama让 VS Code 跨环境调用很多搞 C/C 或者嵌入式的朋友日常开发环境是 Windows WSL2VS Code 装 Windows 侧但编译工具链在 Linux 子系统里。这时候 Ollama 装在哪边就有讲究了。我踩过的坑是Ollama 默认只监听 127.0.0.1也就是只允许本机访问。如果 VS Code 在 Windows 侧而 Ollama 跑在 WSL2 里两边虽然在同一台物理机器上但 IP 栈是隔离的直接访问 127.0.0.1 是不通的。解决方案有两个。一个是在 WSL2 里启动 Ollama 时让它监听所有网卡OLLAMA_HOST0.0.0.0:11434 ollama serve然后在 Windows 侧的 Continue 配置里把 Ollama 的地址改成 WSL2 的 IP 或者http://localhost:11434具体取决于你的 WSL 版本和网络模式。如果你用的是 WSL2 的 NAT 模式建议先用ip addr查一下 WSL 内部的 IP然后从 Windows 侧用wsl hostname -I获取同一个地址把它填进去。另一个更省事的方案干脆把 Ollama 直接装在 Windows 侧。Windows 版本的 Ollama 安装程序本身就支持后台服务运行VS Code 直接访问 127.0.0.1:11434 就行完全不用折腾 WSL 网络。代价是你需要把模型参数文件放在 Windows 文件系统里磁盘占用要预留好。但考虑到后续要把模型目录从 WSL 往 Windows 侧迁也是个体力活所以我后来的建议是主用 Windows 做前端编辑就装 Windows 侧主用 WSL 做训练和数据处理就装在 WSL 侧并且学会配跨访问。2.4 想用云端模型Minimax Code 与 Claude Code 的配置思路本地模型聊得爽了你肯定也会想试试云端大模型。现在 VS Code 里接云端模型已经非常成熟而且不一定非得走官方 Copilot 订阅。如果你在国内网络环境用 Minimax 的 API我记得 Minimax 开放平台提供过代码专用模型叫 Minimax Code它兼容 OpenAI 的对话格式。在 Continue 的config.json里可以直接走 OpenAI 兼容接口{ title: Minimax Code, provider: openai, model: MiniMax-Text-01, apiBase: https://api.minimaxi.com/v1, apiKey: YOUR_API_KEY }Claude Code 又是另一套玩法。虽然它的定位是个独立的终端工具但实际上很多朋友会把它装进 VS Code 里配合 Continue 或者自带的 AI 能力一起用。安装 Claude Code 本质上就是通过 npm 装一个命令行工具然后你需要一个 Anthropic API Key。在 VS Code 里你可以在配置文件里把它注册成 Continue 的一个模型供应商模型 ID 填claude-sonnet-4或者claude-opus-4这样你可以在 Continue 的同一个聊天窗口里随时从本地 Qwen 切换到云端 Claude对比两个模型的输出质量那种体验真的很爽。需要提醒的是云端 API 服务商经常更新模型版本号配置里填的模型 ID 如果失效会报“Model Not Found”之类的错误。遇到这种情况别慌去对应服务商的文档页面对一下最新的模型名把它改过来即可。3. 实战场景用 AI Chat 解决开发里的具体问题3.1 让 AI 帮你搞定 C/C 环境配置从 MinGW64 到工具链配置 C/C 编译环境是很多 VS Code 新手的第一道坎以前你得自己下载 MinGW-w64、手动加 PATH 环境变量、再写一堆 json 配置文件任何一个环节出错都会让你怀疑人生。现在我基本直接把这些事交给 AI Chat。比如我在新电脑上配置环境时直接在 Continue 对话框里输入“现在的电脑是 Windows没有安装任何 C/C 编译器请一步步告诉我怎么安装 MinGW-w64 并配置 VS Code包括下载地址、环境变量设置、以及 tasks.json 和 launch.json 的内容。”AI 会给你完整流程跟着操作就行。但这里有个细节要注意你让 AI 生成的 tasks.json 里编译命令它可能会写成gcc但如果你装的是 MinGW-w64 的 posix 线程版本编译器路径可能实际是C:\mingw64\bin\gcc.exe。建议你在源文件上右键选择“在集成终端中打开”先执行gcc --version确认编译器能找到再让 AI 基于你实际的环境变量生成配置。我曾经遇到过一个比较典型的场景MinGW64 装好了PATH 环境变量也配了但 VS Code 的终端就是找不到 gcc。排查了一圈发现原因是改完环境变量之后VS Code 没有重启旧的终端进程继承的还是修改前的环境变量。所以提醒各位凡是改了 PATH一定要把 VS Code 彻底退出再重开不是保存文件、不是刷新窗口是完整退出进程。3.2 clangd 与 AI Chat 的分工补全和问答各司其职在 C/C 开发里很多人装了 clangd 插件作为代码补全和跳转引擎同时又想用 AI Chat 来做自然语言问答和代码生成。这两个工具其实不冲突关键在于分工。clangd 是基于编译数据库的语义级补全它知道你的项目里有哪些类、哪些函数、哪些宏定义所以它最适合做“精准补全”和“跳转定义”。而 AI Chat 擅长的是理解你的意图比如你给它一句“我需要读取一个 csv 文件并计算每列的平均值”它能直接给你代码片段这部分 clangd 做不到。我的用法是写代码时依赖 clangd 的补全和诊断红色波浪线遇到“这个函数我该怎么写”“这段报错为什么出现”再切到 Continue 里问 AI。另外我还会让 AI Chat 帮着生成 clangd 需要的compile_commands.json。如果你用的是 CMake 工程在 CMakeLists.txt 里加上一行set(CMAKE_EXPORT_COMPILE_COMMANDS ON)然后重新 configureCMake 会在构建目录生成compile_commands.json这时 clangd 就能准确识别所有头文件和宏定义补全质量完全是另一个档次。需要让 AI 解决 clangd 乱报错问题时记得把compile_commands.json的路径也告诉它。3.3 从报错到测试用例AI Chat 怎么帮你少加班AI Chat 最能体现价值的时候不是你顺畅写代码的时候而是你被一个诡异报错卡住的时候。这里分享一个我前阵子的真实经历。当时我在调试 K210 嵌入式开发里的一个串口中断处理逻辑代码能在编译期通过但运行起来就随机死机。我把核心代码片段和症状描述直接贴给 Continue 里的本地 Qwen 模型它一句“检查你的中断服务函数里是否调用了 printf”直接点醒了我——我确实在中断服务函数里用了 printf而这在某些 SDK 的配置下会导致重入问题换成标志位延时处理就好了。这种“排查 bug”的场景AI Chat 还有个更高效的玩法让 AI 帮你写测试用例。你可以把目标函数贴给它要求“为这个函数生成基于 Google Test 的单元测试覆盖空数组、单元素、重复元素三种情况”。它生成的测试代码不一定完美但能帮你把边角情况快速铺开你再手工补几个关键断言即可。按照我个人经验AI 生成测试用例的“命中率”比生成业务代码高不少因为测试逻辑相对固定边界条件也能靠模型训练数据覆盖到。3.4 嵌入式与局域网场景K210、nRF Connect SDK 的额外提醒如果你也是做嵌入式开发用 VS Code 开发 K210、nRF52 这类芯片时AI Chat 也能帮上不少忙但有两类问题特别容易出现值得提前打预防针。第一类是工具链识别问题。比如 nRF Connect SDK 里 toolchain 下拉选项明明有 v3.1.1 的选项但就是无法选中。这种情况大概率不是 VS Code 的锅而是工具链管理器的环境变量没有配对或者该版本工具链的安装路径跟 SDK 的west配置不一致。我建议先确认一下终端里能不能直接执行west build如果 west 命令找不到AI 写一辈子配置也没用先把 PATH 理顺再说。第二类是设备串口监视问题。K210 开发板通过 USB 转串口跟电脑通信VS Code 扩展插件里经常出现“端口被占用”的情况。你让 AI 帮你写一个串口通信脚本的时候最好把系统信息也告诉它你用的不是标准的COM3/ttyUSB0而是不同厂商的 CDC 设备有时候枚举名称会变AI 不一定知道。与人沟通时背景信息要尽可能给全跟 AI 沟通也是一样。4. 翻车现场常见安装与使用问题排查实录4.1 安装插件报错 EPERM多半不是网络问题我在装 VS Code 扩展时遇到过几次Error: EPERM: operation not permitted的报错当时以为是网络问题各种换源、清缓存都试了一遍最后发现根因是 VS Code 的扩展目录没有写权限。EPERM 在 Windows 上出现通常会发生在你以非管理员模式运行时想往C:\Program Files\Microsoft VS Code\resources\app\extensions等系统目录写入文件的场景。解决办法非常简单把 VS Code 装到用户目录或者以管理员身份重新安装一次扩展。另外公司电脑上可能装了安全软件对特定目录做了加锁这时可以在 VS Code 设置里改extensions.autoUpdate为 false避免每次启动都尝试更新导致权限冲突。如果你是在公司网络环境还遇到过扩展下载一半失败、重新安装也失败的情况建议关掉“代理严格模式”或者检查系统代理是否指向了一个不可用的地址。VS Code 对代理的支持总体还算好但有时候系统代理和扩展进程之间会有冲突表现为反复重试却始终下载不下来。这种问题最简单的处理方法临时关掉系统代理再装一次扩展装完再开。4.2 Tab 键切不了命令命令面板的几种替代姿势VS Code 的命令面板CtrlShiftP是所有功能的入口但你可能会遇到 Tab 键无法切换命令的情况——比如输入关键字之后Tab 只能在少数几个选项之间跳或者干脆没反应。这通常不是键盘问题而是ctrltab系列快捷键被其他插件接管了或者命令面板进入了“命令模式”的子状态。这里分享几个替代方案。第一直接用上下方向键选中列表项回车执行不依赖 Tab第二输入命令时带“”符号可以直接走命令模式比如git:可以筛选出所有 git 相关命令第三如果你想快速找的不是命令而是文件那就是CtrlP快速打开文件不要混在命令面板里用。这三个入口分开记忆能减少很多混淆。如果你连CtrlShiftP都唤不出来大概率是快捷键冲突去Preferences: Open Keyboard Shortcuts里搜workbench.action.showCommands看看绑定的到底是哪个键再重新设置一次即可。4.3 本地模型聊天沉默网络、端口与 CORS 逐个排查Continue 连本地 Ollama 时最常见的现象是在终端里ollama run一切正常但 Continue 对话框里发消息后一直转圈最后超时。这里我总结了一套排查顺序基本能解决 90% 的问题。先确认 Ollama 服务是否在监听。终端执行ollama list能列出模型说明 11434 端口没问题。接着测试 HTTP 接口是否正常用浏览器打开http://127.0.0.1:11434/api/tags如果能看到 JSON 列表说明 Ollama 的 API 通了。这时候还不能排除 CORS跨域资源共享问题——Continue 内部是网页视图向 Ollama 发请求时浏览器会拦截非同源响应。新版 Ollama 默认已经开启了 CORS如果你装的是旧版本需要手动设置环境变量OLLAMA_ORIGINS* ollama serveWindows 下可以在设置里给ollama.exe加环境变量或者直接升级到新版。如果以上都正常最后再看 Continue 配置里的模型 ID 是否和ollama list显示的完全一致包括中间的冒号和标签比如qwen2.5-coder:7b和qwen2.5-coder:latest会视为不同 ID。4.4 工具链下拉灰选、插件不生效几个不起眼的坑回到前面提到过的toolchain下拉选项灰选问题这在嵌入式插件里尤其常见。除了 nRF Connect SDK 的环境变量问题还有一个很隐蔽的坑是VS Code 工作区设置里某些插件从“远程 WSL”窗口打开和从“本地”窗口打开时看到的环境完全不一样。如果你用 WSL 远程开发终端里能执行nrf或者west但 VS Code 的插件界面仍然报找不到工具链一般是插件的进程没有继承 WSL 的用户环境变量。验证方法很简单在 WSL 终端里执行echo $PATH看看 SDK 路径在不在里面。如果 SDK 路径是通过.bashrc里的export加上去的VS Code 有时不会去加载.bashrc它加载的是另一个登录 shell。解决办法是把 SDK 相关的环境变量写进/etc/environment或者 WSL 的设置文件/etc/wsl.conf里这样不管从哪里启动 VS Code 都能拿到。另一个不起眼的坑是插件版本与 VS Code 版本不兼容。VS Code 更新频繁部分更新慢的插件可能在最新版 VS Code 上出现按钮灰选、面板空白的情况。遇到这种问题去扩展市场看插件描述里写的VS Code最低版本要求如果它要求的版本比你现在的版本还高那就先升级 VS Code如果反过来考虑装插件的历史版本。4.5 问题排查速查表现象常见原因快速排查与解决安装扩展报 EPERM扩展目录无写权限装到用户目录或以管理员运行命令面板 Tab 无法切换快捷键冲突或子模式用方向键选中检查快捷键绑定Continue 连不上 Ollama服务未启动、CORS、模型 ID 不一致按网络-端口-CORS-ID 顺序排查本地模型输出质量差参数偏小或上下文不够换 7B/14B 模型或切到云端大模型C/C 找不到 gccPATH 未生效修改环境变量后彻底重启 VS Codetoolchain 下拉灰选环境变量未加载写入 /etc/environment 或 wsl.confclangd 乱报错缺少 compile_commands.json开启 CMake 的导出选项这个表格是频繁翻车后的经验浓缩建议你截图存一下以后遇到类似问题先对着表查一遍能省不少时间。5. 最后说点选型与使用上的真心话VS Code 的 AI Chat 现在能干到哪一步其实已经超出了“自动补全”的范畴它更像是一个坐在你旁边、随时可以请教的老同事。但我也要泼一点冷水它还不能完全替代你的判断力。我在实际使用中体会到AI 生成的代码质量跟你的提问质量高度相关。你把需求说得越具体它给出的答案越好用。同样是“帮我写一个网络请求”如果你给它补充“用 Python 的 requests 库设置 5 秒超时需要处理连接异常返回 JSON 对象”那结果会完全不一样。所以我现在写代码的习惯是先把接口签名、输入输出、边界条件想清楚再让 AI 填充实现最后自己通读一遍修正逻辑漏洞。另外想分享一个小技巧无论本地的 Qwen 还是云端的 Claude在训练数据里都有大量“规范代码”的样本因此它写出来的代码风格通常比多数程序员更统一、更注重注释。你可以利用这一点把团队规范喂给它要求它按你的命名规范和注释风格来生成代码。这样 AI 生成的内容能更自然地融进现有工程而不是一看就是另一个人的手笔。这个内容后续还能扩展的方向挺多的。比如让 Continue 通过 Mermaid 插件顺带生成流程图或者在 VS Code 里同时接入代码搜索工具、让 AI 自动关联多个文件做架构分析。我现在还在尝试用本地模型做 commit message 的自动生成初步效果还凑合。总之VS Code 的 AI Chat 已经不是当初那个玩具了它正在成为日常开发流程里不可缺失的一部分。工具选好了习惯养对了你就能比别人少熬几次夜。