说实话，半年前如果有人问我VS Code里的AI聊天好不好用，我大概率会说一句“能补全代码就行，聊天就是个噱头”。但最近这两三个月，我发现情况完全变了。尤其当你把本地大模型接进去之后，VS Code里的AI Chat已经不是当年那个只会“复述文档”的玩具了——它是真的能帮你读代码、查报错、改逻辑、甚至陪你调一晚上编译错误的那种队友。
这篇文章不聊那些花里胡哨的“AI编程未来趋势”，就聊点实在的：VS Code里AI Chat到底能做到什么程度、怎么选方案、怎么把本地Ollama模型接进来、还有我踩过的那些坑。全文基于我自己在Windows和WSL2两个环境里的实测，适配新手也适配老手。
1. AI Chat现在的三种玩法，先搞清你属于哪种
1.1 云端全家桶路线：装了就能用，但别指望太多
这一派代表是GitHub Copilot Chat，以及各种云厂商出的VS Code插件。优点是零配置，装完登录账号就能用，响应速度快，模型智商普遍在线。缺点是你要么付费，要么忍受免费的次数限制，而且代码稍微敏感一点的项目，往云端一发，心里总归有点不舒服。
我个人的看法是：如果你只想体验一下“在编辑器里问问题”是什么感觉，Copilot免费版完全够用。但如果你每天要高频对话、要让AI读你整个工作区、还要让它改代码，那云端的免费额度基本上撑不过一个上午。
1.2 本地优先路线：模型跑在自己机器上，隐私和自由兼得
这就是现在社区里讨论度最高的一种玩法：本地部署Ollama，然后在VS Code里装Continue或者Cline这种支持本地模型的插件，把聊天和补全全指向127.0.0.1。热门搜索里那个“vs code + claude code 插件接入本地大模型ollama”，说的就是这条路线的具体操作。
这条路线最大的优势有两点。第一是隐私，代码不出机器，做什么都踏实。第二是省心，不用纠结API调了多少次、流量超没超，模型跑在自己机器上，想怎么问就怎么问。缺点是模型的智商上限取决于你的显卡，你要是拿一台核显轻薄本去跑14B以上的模型，那对话速度会慢得让你怀疑人生。
1.3 混合路线：云模型做复杂任务，本地模型做日常杂活
这是我目前在用的方式。Continue插件里配多个供应商，日常的代码解释、变量重命名建议、简单报错排查走本地小模型；遇到复杂的架构设计、多文件联动逻辑分析，切到云端的强模型。成本可控，效率和智能也都不差。
而且很多人不知道，VS Code里的AI Chat不只能聊天，它还能直接选中代码片段、右键发送给AI，让AI基于这段代码生成注释、写测试用例、翻译成另一种语言。这些功能不管你用云端还是本地模型，全都支持。
2. 把本地Ollama接进VS Code，全流程实操
2.1 先确认VS Code本身装好了
这个听起来像废话，但真的有人卡在这一步。在桌面能找到VS Code图标不算装好，你得打开VS Code，按Ctrl+Shift+P能弹出命令面板，并且在左侧能看到扩展市场图标，这才算真正能用。如果打开是个空白窗口且命令面板没反应，大概率是安装包损坏，去官网重新下，别用第三方渠道的绿色版。
2.2 Ollama的安装与模型选择
Ollama本身就是一个大模型运行工具，你把它理解成“模型界的Docker”就行。去ollama.com下载对应系统的安装包，Windows直接双击装，Linux用脚本装。
装完之后最重要的一件事是拉模型。我的建议是别一上来就拉最大的，先拿7B或8B级别的模型试水。比如：
ollama pull qwen2.5:7b ollama pull llama3.1:8b拉完以后跑一下：
ollama run qwen2.5:7b能正常对话，说明Ollama本体没问题。注意，Ollama默认只监听127.0.0.1:11434，这个地址就是你VS Code插件要连的目标。
2.3 Continue插件配置：指向本地模型
在VS Code扩展市场搜索Continue，安装后它会自动在左侧生成一个AI Chat面板。关键操作来了：点击面板底部的齿轮图标，打开配置文件config.json，默认是JSON格式，我们在里面加一个本地模型的provider，然后写进models里。
一种比较通用的写法是：
{ "provider": "ollama", "name": "ollama-qwen", "model": "qwen2.5:7b", "apiBase": "http://127.0.0.1:11434", "roles": ["chat", "autocomplete", "edit"] }这就是把聊天、补全、编辑三个能力全挂到本地模型上。重点要理解那个apiBase：它必须是Ollama监听的地址，默认就是http://127.0.0.1:11434。你要是改了Ollama的端口，这里的地址也要跟着改，否则插件一定连不上。
2.4 WSL2里的特殊配置：和Windows互通
热门搜索里有一句话描述得很精准：“在 vs code continue 的设置里，将它指向你已经在 wsl2 里跑起来的本地 ollama 服”。
如果你把Ollama装在WSL2里，会有个“跨系统访问”的问题。在WSL2里启动Ollama，Windows这边的VS Code插件不能直接用127.0.0.1去连，因为WSL2有自己独立的网络栈。这时候你需要让Ollama监听所有网卡，也就是设置环境变量：
OLLAMA_HOST=0.0.0.0:11434 ollama serve然后再从Windows侧访问WSL2的IP。这个IP不是固定的，可以在WSL2终端里用hostname -I查，也可以直接写成http://localhost:11434，配合WSL2的默认端口转发，很多时候也能通。我实测下来，最稳的还是写WSL2的IP地址，虽然每次重启WSL2后IP可能变，但配置一次能用很久。
如果你就想一劳永逸，建议Windows直接装原生的Ollama，不绕WSL2的弯子。速度更快，配置也简单。WSL2方案的唯一优势是Linux环境的兼容性，比如某些模型依赖Linux的CUDA栈。
2.5 连不上怎么办，先分三层排查
第一层：Ollama本身有没有起来。浏览器访问http://127.0.0.1:11434，能看到Ollama is running就说明Ollama没问题。第二层：模型有没有拉对。你在Ollama里要保证ollama list能查到刚才配置的模型。第三层：插件配置对不对。检查apiBase是否带http://，模型名是否完全一致。
这一套走完，基本90%的“连不上”都能解决。剩下10%是版本问题，续插件太老、Ollama太旧，升级到最新版再看看。
3. 实操现场：AI Chat帮我解决真实开发问题
3.1 用AI Chat解释陌生项目的代码
我最近接手了一个别人写的K210嵌入式项目，用的是C语言加FreeRTOS。刚打开项目的时候，头文件之间互相include，宏定义满天飞，设备驱动层和应用层混在一起，一时半会儿真看不明白。
这时候AI Chat的作用就体现出来了。我先把入口函数那段代码选中，右键发送到Chat，然后用Continue面板写了一句：“这个函数整体负责什么？标注出关键调用关系和数据流。”本地7B模型花了大概10秒，给了一段非常清晰的结构说明——它列出了三个线程的创建顺序、两个消息队列的交互方向、还有几个关键全局变量的用途。
这个效率是人肉读码没法比的。模型虽然不写业务逻辑，但它对C语言语法、RTOS API、常见驱动模型的理解，已经足够当一个“不睡觉、不嫌烦的陪读”。
3.2 让AI Chat帮你改编译错误，亲测有效
嵌入式开发经常和GCC斗智斗勇，尤其是链接阶段报错，什么undefined reference to xxx，你看半天头文件也看不出问题。我把报错信息整段贴给AI Chat，它直接指出是“调用了某个外设库的接口，但没把对应的.c文件加进CMakeLists”，还顺手给了修复示例。
这里有个小技巧：贴报错的时候，不要只贴最后一行错误摘要，要把Build控制台里的完整输出贴过去，模型能拿到更多的上下文，判断会更准。同时给它补充一句“这是CMake工程”“目标芯片是K210”“用的工具链是RISC-V GCC”，它给出的方案会准确得多。
3.3 用AI Chat做代码审查，是真能挑出毛病
上个月我写完一个消息解析模块，自己检查了两遍觉得没问题，想着让AI Chat过一眼。它直接指出一个潜在的越界风险：memcpy的长度判断用的是“接收长度”而不是“剩余缓冲区长度”，这在极端情况下会写穿缓冲区。
那一刻我确实有点吃惊。因为这种问题不是简单的语法错误，而是需要理解“这段代码在什么条件下会执行”“传入参数的实际含义是什么”才能发现的逻辑漏洞。当一个本地7B模型能做到这一步，说明AI Chat已经从一个“对答工具”变成了真正的“代码审查搭档”。
当然，它也不是每次都对。有几次它给出了完全错误的修改建议，甚至会一本正经地“编造”一个不存在的API。所以我的原则是：AI Chat给的结论，永远当“草案”看，核心代码的最终判断还是得靠自己。
4. 搭配这些插件，AI Chat才算是完全体
4.1 clangd：让AI Chat看懂你的C/C++工程
很多人在VS Code里写C/C++，装的是微软官方的C/C++扩展，但从代码分析的角度，clangd其实是更专业的引擎。它依托Clang编译器的前端做索引，对C、C++、Objective-C的支持好得离谱，跳转准、补全快、报错信息也比默认插件友好。
关键的关联点在于：clangd会给VS Code提供语言服务器协议（LSP）能力，AI Chat拿到的是“结构化”的代码信息，不是纯文本，这就能让对话内容更准确。
clangd的安装有两步：第一步在扩展市场装clangd插件，第二步是安装clangd二进制本身，Windows用户用winget装：
winget install LLVM.LLVM装好后在配置里确认clangd.path指向了正确的可执行文件路径，然后打开一个C++项目，它会自动生成compile_commands.json或者引导你配置clangd.arguments里的--compile-commands-dir。这个文件就是clangd的“地图”，没有它，clangd就只能靠猜，跳转一塌糊涂，AI Chat也会跟着变笨。
4.2 C/C++编译环境：不是装个插件就能跑的
新手常犯的错误是，以为装了C++插件就能编译运行。实际上VS Code只是编辑器，编译器要你自己装。Windows平台主流是MinGW-w64，安装完要手动把bin目录加进系统PATH，然后重启VS Code，在终端里输入gcc --version能输出版本号才说明环境OK。
如果你用的是CMake工程（比如K210项目），建议装CMake Tools插件，它会自动识别CMakeLists.txt，帮你生成build目录、调用编译工具链。这里就不得不提那个热门搜索里的高频问题：“toolchain下拉选项有nrf connect sdk toolchain v3.1.1选项但无法选中”——这种问题的本质是VS Code不知道该用什么路径的工具链。
解决办法是手动指定工具链路径，或者干脆在CMake Tools的命令面板里重新选择“Scan for kits”，如果还选不中，就自己写一个cmake-kits.json，把编译器路径硬编码进去。AI Chat虽然能帮你解释报错，但工具链选不对这种环境问题，你得自己动手解决。
4.3 边缘案例：Mermaid插件和AI画图
再说个容易被忽略的组合技：VS Code里的AI Chat配Mermaid插件。我现在做方案设计的时候，习惯让AI帮我梳理模块关系，然后把描述贴给Mermaid插件，在Markdown里直接渲染出流程图。VS Code里搜Mermaid装一个，然后在Markdown的代码块里写mermaid，就能把文字描述变成图表，特别适合写设计文档和做代码宣讲。
4.4 几个实用插件的不完全清单
- Code Runner：右键一键跑当前文件和AI Chat配合，改完代码立刻验证
- Prettier：代码格式化，AI生成的代码经常缩进混乱，格式化一下能看
- GitLens：查看每行代码的历史提交信息，AI Chat分析代码时配合GitLens，你能快速知道这行代码是谁加的、为什么加
- Error Lens：把报错信息直接显示在代码旁，减少反复切窗口的麻烦
这些插件单独拎出来都很常规，但和AI Chat叠加以后，整个工作流就顺了：AI分析代码→Code Runner验证→Error Lens看错误→AI继续修→Prettier整理格式。
5. 常见问题与排查技巧实录
5.1 安装插件报错：Error: EPERM: operation not permitted
这个我在Windows上遇到过好几次。多半是权限问题，VS Code默认安装在C:\Program Files目录下，插件往这个目录写文件会被系统拦住。解决的思路一句话：别让VS Code装在需要管理员权限的路径下，插件目录跟着受累。
具体操作：右键VS Code图标，选“以管理员身份运行”，然后再去装插件。如果不想每次都用管理员权限，干脆把VS Code卸载重装到D:\App\VS Code这种目录，一劳永逸。装完以后确认右侧状态栏出现插件图标，才算过了这一关。
5.2 Tab键无法补全命令，还有哪些方式快速调出命令
新用户在VS Code里会发现，有时候按Tab键并不能像IDE那样自动补全。原因是Tab键在编辑器里默认是“插入制表符”，不是“触发补全”。你按Ctrl+Space能手动调出智能提示，回车确认。
如果你已经装了AI补全插件（比如Continue的Autocomplete或Tabnine），那Tab键的补全行为由插件的配置决定，要去插件设置里找“Tab key accept completion”之类的选项打开。
至于“还有没有其他方式找命令”，我最常用的三个：第一是Ctrl+Shift+P命令面板，输入关键词能搜到所有命令；第二是Ctrl+P快速打开文件，配合AI Chat的“跳转到定义”功能，找文件极快；第三是Ctrl+Shift+E切到资源管理器，再配合键盘输入直接搜索文件名。这三个用熟了，效率不比那些花里胡哨的快捷键差。
5.3 Clangd乱报错，多半是compile_commands.json没生成
clangd最让人头疼的问题就是明明代码没问题，它却疯狂标红。九成情况是它没拿到编译参数，不知道你用了哪些宏、包含哪些头文件。对付这个有几招：
- 如果你用CMake，确保
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1被设置，重新配置一次CMake - 如果项目是Makefile，可以装
bear工具生成compile_commands.json：
bear -- make- 确保clangd的
--compile-commands-dir指向包含该文件的目录
我踩过最大的坑是用了“单文件模式”，也就是直接单独打开一个.c文件，这种情况下clangd没有任何上下文，只能靠猜。正确做法是打开整个项目文件夹，让clangd建立全工程的索引。
5.4 局域网模型连接：把AI Chat服务搬给团队用
除了本机用，我最近还试了局域网模式——把Ollama去跑在一台有显卡的服务器上，然后VS Code连那个服务。这就要修改Ollama的监听地址。在启动Ollama前设置环境变量：
export OLLAMA_HOST=0.0.0.0:11434 ollama serve然后在VS Code插件里把apiBase改成http://服务器IP:11434。注意防火墙得放行11434端口，否则能ping通但连不上。
这种模式下，你组里每个人的VS Code都能连上同一台GPU服务器上的大模型，模型只用加载一份，大家的机器零负担。一个小建议：给服务器上的Ollama设置OLLAMA_NUM_PARALLEL控制并发数，不然好几个人同时问，显存容易爆。
5.5 插件的“坑位”其实很关键
很多人装了一堆VS Code插件，结果AI Chat功能全乱了，Chat面板能调用的能力取决于你装了什么扩展。如果你装了多个AI插件，比如Continue、Cline、Codeium同时存在，它们会抢占聊天面板入口。我建议是一个时段只启用一个AI插件，其他的禁用，避免请求混乱。等用熟了再决定主力是哪家。
6. AI Chat的选择没有标准答案，只有适不适合你
每次看到有人在论坛上问“VS Code里AI Chat到底用哪家好”，我都觉得这个问题其实没有标准答案。核心变量就三个：你的模型需求偏好、你的算力条件、你对数据隐私的容忍度。
如果你只是偶尔写点脚本，Copilot免费版随便薅。如果你天天写代码，还要求全流程集成，Continue加本地Ollama是性价比最高的组合。如果你要处理商业项目，代码出不了内网，那本地模型是唯一的选择。至于什么人适合上云端的付费强模型，我的答案是：等你在本地方案里把所有流程都跑通、知道AI哪里好用哪里坑之后，再上也不迟。
还有一个现象很有意思：最近更多人开始把MiniMax这类新的云端模型塞进VS Code里用。这类模型在长上下文理解上确实有优势，但要我说，选AI模型的标准不是“谁参数多谁厉害”，而是“谁在你实际场景里减少你的精神内耗”。一个每次都能精准指出编译错误位置的7B模型，远比一个泛泛而谈的“顶级大模型”有用。
我在实际使用中最大的感受是：VS Code的AI Chat已经不再是一个“锦上添花”的功能，在调试环境、写测试用例、解释历史代码这些场景里，它已经变成了我的日常工作流之一。它不能替代你的判断力，但能大大减少你从“看不懂”到“看懂了”之间的时间。
最后分享一个小技巧：很多刚接触这个组合的人，会忽略Ollama的OLLAMA_KEEP_ALIVE参数。默认值是5分钟，也就是说模型在5分钟不被调用后会自动从显存中卸载。如果你在VS Code里频繁和AI对话，建议把它设长一点，比如：
OLLAMA_KEEP_ALIVE=30m ollama serve这样每次对话之间，模型不用反复加载，响应速度快了不是一点半点。如果你只是偶尔用一下AI Chat，那就保持默认就行，省显存，给其他程序留点空间。这种细节，往往就是“用了都说好”和“用了一会儿就删”之间的分水岭。
