最近在一个技术群里看到有人问“VS Code 的 AI Chat 现在已经这么能干了”我当时第一反应是这兄弟是不是闭关了半年刚出来。因为就在过去这几个月里VS Code 的 AI 生态已经不是“能补全代码”的水平了而是真的能坐在你旁边理解整个项目上下文帮你改 bug、写测试、跑命令、甚至自己动手重构代码。更关键的是这套能力不只有 GitHub Copilot 这一条路本地模型、国产模型、Claude Code 插件全都已经能接进 VS Code 里。所以这篇东西我不打算写成功能清单式的水文而是把我自己从“装个插件试试看”到“真把 AI Chat 当结对编程搭子”的完整过程、配置细节、踩坑经历都摊开讲。涉及 Ollama 本地模型接入、Claude Code 插件配置、C/C 开发环境下的实战玩法、局域网和 WSL2 的模型共享方案以及一堆你大概率会撞上的报错。如果你也想在 VS Code 里跑一个真正能用的 AI Chat这篇文章应该能帮你少走不少弯路。1. 先说清楚 VS Code 的 AI Chat 到底是什么形态1.1 从“补全代码”到“对话协作”的转变VS Code 本身其实没有内置 AI 功能你看到的“AI Chat”全部来自扩展。早期大家熟悉的 AI 辅助是 Tab 键补全——你写个函数名它帮你自动补下一行。但现在的 AI Chat 是完全不同的东西它不是一个简单的补全引擎而是一个能理解你整个工作区的对话式助手。你在侧边栏打开聊天面板它可以读取当前打开的文件、选中的代码段、甚至整个项目的目录结构和文件内容。这种转变的本质是模型能力的提升。补全模型只需要预测下一段 token而对话式 AI 需要维护多轮上下文、理解用户的意图、分析代码之间的调用关系。以我自己的体验来说最明显的变化是以前 AI 给你的建议你得自己判断能不能用现在你直接告诉它“这个函数每次跑都会多出一行数据帮我查一下”它能顺着调用链帮你定位到问题连修复方案和验证步骤都给你写好了。1.2 现在 VS Code 生态里的 AI 扩展谱系我按使用场景把主流的 AI 扩展分成了几类方便你根据自己的需求选类型代表扩展特点适合人群商业闭源GitHub Copilot Chat和 GitHub 生态深度集成代码质量高但要付费不差钱、追求省心的开发者本地模型Continue、Ollama 插件完全离线、免费、隐私可控模型能力取决于你机器配置在意代码隐私、不想订阅付费的用户Agent 型Claude Code、Cline能自己读写文件、执行命令像真正的结对程序员愿意接受新工作方式、有 API key 的开发者国产便捷通义灵码中文理解好免费额度大配置简单刚接触 AI 编程的新手需要说明的是这个分类不是绝对的。比如 Continue 也能接 Claude APICline 也能配本地 Ollama。现实中大家往往是好几个插件混着用我自己就是本地模型负责日常补全和问答Claude Code 负责干重活。1.3 我对“能用”和“好用”的判断标准说实话VS Code 里 AI Chat 的插件少说也有上百个但真正能留下来的没几个。我这段时间用下来的感受是判断一个 AI Chat 插件好不好用就看三点第一上下文准备能力。它能不能自动把相关的代码文件、编译错误、终端输出打包给模型如果每次都要你手动复制粘贴那还不如直接用网页版 ChatGPT。第二响应速度。无论是本地模型还是云端 API等 AI 回答超过十秒钟你基本就不会想用它了。第三结果的可操作性。它给的建议能不能一键应用、能不能直接在聊天面板里打开引用的文件、能不能把修改 diff 展示出来。这三个维度直接决定了你把它当玩具还是当工具。2. 本地模型接入Ollama 是让 AI Chat 免费跑起来的关键2.1 为什么要折腾本地模型我知道很多人第一反应是“直接开个 Copilot 会员不就完了”。但本地模型有它不可替代的价值代码不出机器、不花钱、没有上下文长度限制的压力、断网也能用。尤其是你在处理公司内部项目或者要签保密协议的代码时往云端 API 里传代码这件事本身就够你喝一壶的。我自己在帮客户做人脸识别和嵌入式项目时代码全在本地跑图的就是一个心安。本地模型这条路Ollama 目前是最省事的方案。它本质上是一个大模型的运行管理工具把模型的下载、加载、推理 API 全部封装好了你只需要执行几条命令就能把一个几 GB 到十几 GB 的模型跑起来。VS Code 里很多 AI 扩展都原生支持 Ollama所以接入成本非常低。2.2 Ollama 的安装和模型拉取Ollama 支持 Windows、macOS 和 Linux直接从官网下载对应安装包就行。Windows 版本安装完会自动注册系统服务启动后监听在 127.0.0.1 的 11434 端口。装完之后打开终端验证一下ollama --version ollama list如果能看到版本号和模型列表第一次安装是空的说明服务已经跑起来了。接下来拉取模型。以我常用的几个示例# 代码能力较强的通用模型 ollama pull qwen2.5-coder:14b # 轻量级快速响应模型低配机器也能流畅跑 ollama pull llama3.2:3b # 通用对话模型中文效果好 ollama pull qwen2.5:7b这里有个建议别一上来就拉 70B 那种大模型你得先看自己机器的显存和内存。Ollama 默认用 GPU 推理NVIDIA 显卡配合 CUDA 效果最好没有 N 卡的话CPU 跑 7B 模型也不是不行就是响应速度会慢不少。我自己的经验是 16GB 内存的机器跑 7B 量化版模型基本能接受。2.3 Continue 扩展把本地模型接进聊天面板在 VS Code 里我推荐用 Continue 这个扩展来对接 Ollama。它免费、开源、支持自定义模型配置而且不会把你的代码偷偷传出去——因为模型就在本地跑。安装 Continue 后打开它的配置文件config.yaml命令面板输 Continue: Open Config 就能打开把 Ollama 服务加进去。我用的配置片段长这样models: - name: Qwen2.5 Coder provider: ollama model: qwen2.5-coder:14b apiBase: http://127.0.0.1:11434保存配置后在 Continue 的聊天面板里选择你刚才配置的模型就能开始对话了。它能选中代码问问题、让它解释报错、生成注释和测试。实测下来qwen2.5-coder 系列在代码理解方面表现相当不错虽然和 GPT-4o 这种顶级模型还有差距但应付日常开发绰绰有余。2.4 本地模型的性能实测和选型建议为了让你心里有数我把自己在几台机器上实测的数据列个表供你参考模型参数量量化推理硬件响应速度代码理解能力llama3.2:3b3BQ4CPU 16GB较快基础水平适合简单问答qwen2.5-coder:7b7BQ4RTX 3060流畅中等偏上能改简单 bugqwen2.5-coder:14b14BQ4RTX 4070 Ti流畅明显更强能处理复杂重构deepseek-coder-v2:16b16BQ4RTX 4090一般优秀但硬件门槛高这里的核心建议是宁可要 7B 模型的快速响应也不要 14B 模型慢吞吞地转圈。因为 AI Chat 使用频率高每次要等十几秒的话你很快就会放弃它。另外注意Ollama 拉取的模型默认是 Q4 量化版如果你显存够大可以拉非量化版本获得更好的效果代价是磁盘占用和加载时间大幅增加。2.5 本地模型跑不动时的应急方案如果你的机器配置很低连 3B 模型都跑得费劲还有一个思路用 Continue 接在线 API 但走兼容 OpenAI 格式的服务。比如你可以配一个 DeepSeek 或智谱的 API key它们提供 OpenAI 兼容接口写法非常接近 Ollamamodels: - name: DeepSeek provider: openai model: deepseek-chat apiBase: https://api.deepseek.com/v1 apiKey: sk-xxxx这样你只是在本地跑了个客户端模型推理在云端完成响应速度和能力都能上一个台阶。不过代价就是代码要出网这个取舍自己权衡。3. Claude Code 插件把重任交给真正的 Agent3.1 Claude Code 和传统聊天插件的本质区别Continue、CodeGPT 这类插件说到底还是“聊天窗口”你问它答它不会主动去动你的项目文件。但 Claude Code 不一样它是个 Agent 形态的工具。什么叫 Agent就是它会自主规划任务、自己读取文件、自己编辑代码、自己跑命令然后把结果告诉你。举个例子你给它一个任务“帮我写一个 Python 脚本读取 CSV 文件按日期聚合数据并生成图表”。传统聊天插件只会给你贴一段代码让你自己保存Claude Code 会自己创建一个脚本文件、安装依赖、跑一遍看有没有报错然后告诉你“已经完成了你看看这个图”。这种体验差别是巨大的。3.2 安装和配置的全过程Claude Code 的 VS Code 集成方式有两种一是直接装独立的 VS Code 扩展二是用官方的 CLI 工具配合终端使用。我推荐两者都装因为有些场景在聊天面板里操作更方便。安装 CLI 工具npm install -g anthropic-ai/claude-code装完后需要配置 API key。最简单的方式是设置环境变量ANTHROPIC_API_KEY。在 Windows 上可以用 PowerShell 设置$env:ANTHROPIC_API_KEY sk-ant-xxxx在 macOS/Linux 上就写进~/.zshrc或~/.bashrcexport ANTHROPIC_API_KEYsk-ant-xxxx然后去 VS Code 扩展市场安装 Claude Code 扩展。装好后侧边栏会出现 Claude 的图标点开后输入/init可以让它先扫描一遍项目结构并生成 CLAUDE.md 文件。这个文件是 Claude Code 理解你项目的“说明书”它会在这里记录项目技术栈、代码规范、常用命令等关键信息。3.3 实测让 Claude Code 修一个棘手的 bug我最近做一个 C 项目时遇到过一个很头疼的问题程序运行时偶发崩溃但 gdb 看不出明显原因。我把项目上下文和崩溃日志丢给 Claude Code它的处理流程让我印象深刻第一它先读了我项目的 CMakeLists.txt 和崩溃相关的源文件确认编译选项和代码结构。第二它指出崩溃可能跟某个结构体的内存对齐有关并给出了具体修改方案。第三它自己改了代码写了单元测试来复现问题跑完确认修复后还把 diff 展示给我看。整个过程中我几乎没有操作更像是在审查一个初级程序员的工作成果。不过这也不是说 Claude Code 永远正确。它偶尔也会改错东西或者为了修复一个问题引入新的问题。所以我的态度是让它干重活、出方案、做第一版但最终合入代码前一定要 review。它是个高效的实习生不是可以放权的正式员工。3.4 费用观察用 API key 到底花多少钱很多人关心 Claude API 的费用。以我实际用的趋势来看日常开发中让它修 bug、写测试、解释代码一个月下来花费大概在几十美元到一两百美元之间取决于你项目的复杂度和使用频率。如果你只在关键任务上用它把日常问答交给本地模型费用还能更低。4. C/C 开发场景下 AI Chat 的实战配合4.1 为什么 C/C 开发特别需要 AI Chat如果你主要是写 JavaScript 或 PythonAI Copilot 这类工具已经是常规操作。但 C/C 开发里的痛点特别明显编译报错信息又长又晦涩、内存问题难以定位、CMake 配置语法让人头大、跨平台编译经常出幺蛾子。这些场景恰好是 AI Chat 的强项因为它不仅是代码生成器更是一个“懂编译原理的助手”。我在热搜里看到大量 “VS Code 配置 C/C 编译运行环境”“VS Code 里怎么配置 MinGW64”这类需求这正说明 C/C 开发者在 VS Code 里的环境配置和排错需求极其旺盛。而 AI Chat 结合这些场景能做的不只是给你贴代码还能帮你理解背后的原因。4.2 C/C 环境必备扩展和配置清单要想让 AI Chat 在 C/C 项目里发挥最大价值你得先把基础环境搭好。我自己项目的 VS Code 扩展清单是这样的扩展用途是否必须C/C微软官方IntelliSense 代码补全、调试是clangd更智能的代码补全和诊断强烈推荐CMake Tools构建、调试 CMake 项目是Code Runner一键编译运行单个文件强烈推荐Continue / Claude CodeAI Chat是其中 clangd 和微软的 C/C 扩展存在功能重叠同时启用可能造成补全提示冲突。我现在的做法是项目里启用 clangd关闭 C/C 扩展的 IntelliSense只保留调试功能。你可以按CtrlShiftP输入C/C: Select IntelliSense Engine切换。4.3 AI Chat 处理编译报错的完整姿势处理编译报错是 AI Chat 最让我惊艳的场景之一。以前遇到 GCC 输出一长串模板错误信息我只能耐着性子从中间找关键行现在直接选中终端里的报错信息发送给 AI Chat它能直接告诉你“问题出在main.cpp第 47 行你给std::vector传了一个空指针迭代器建议改为……”并且给出可以直接应用的补丁。这里有个小技巧喂给 AI 的报错信息要带上编译命令和上下文。如果只给一段报错模型很难判断你用的是 C11 还是 C20、是 GCC 还是 MSVC。我一般会把报错信息、相关代码、还有 CMakeLists.txt 里的编译选项一起发过去效果立竿见影。4.4 一次完整的实战AI 帮我搞定 MinGW 配置难题说个真实经历。最近在 Windows 上配 MinGW-w64 环境遇到了一个非常经典的坑下载的压缩包解压后g命令在终端里能正常编译但 VS Code 的 C/C 扩展和 Code Runner 怎么都提示找不到编译器。我先把现象告诉本地 Ollama 上的 qwen2.5-coder它给出的建议是检查环境变量和配置文件。照着做了一遍发现没问题但 VS Code 依然报错。后来我换成 Claude Code它让我检查是不是 VS Code 继承了系统环境变量前没有重启。重启 VS Code 后问题解决。整个过程虽然不复杂但 AI 把排查路径梳理得很清楚比我一个个关键词去搜效率高太多。另外一个常见问题中文路径导致编译失败。如果你的用户名含中文MinGW 的 Make 工具很可能在处理路径时崩溃。AI Chat 建议我把tasks.json里改成短路径模式或者干脆把项目挪到纯英文路径下。这种经验型的建议在官方文档里很难找到但 AI 从海量训练数据里学到了这正是它的价值所在。5. 本地模型的联网玩法WSL2 和局域网共享5.1 为什么把 Ollama 放进 WSL2 里跑用过 Windows 的都知道很多开源工具在 Windows 原生环境下的兼容性不如 Linux。Ollama 虽然官方支持 Windows但在 WSL2 的 Linux 环境里跑CPU 调度和内存管理通常更稳定还能避免 Windows Defender 实时扫描导致的大模型文件读取卡顿。我现在的做法是在 WSL2 里装一个 Ubuntu然后在里面安装 Ollama拉取模型让服务跑在 WSL2 内部。VS Code 不用动Continue 扩展只需要把apiBase从127.0.0.1:11434改成 WSL2 的地址即可。5.2 让 Windows 访问 WSL2 里的 Ollama 服务这里要注意一个细节WSL2 的 IP 地址是动态的每次重启都可能变化。如果你在 Continue 配置文件里写死 IP过几天系统重启后可能就连不上了。解决办法是把 Ollama 绑定到0.0.0.0让它监听所有网络接口OLLAMA_HOST0.0.0.0:11434 ollama serve然后在 Windows 终端里查 WSL2 的 IPwsl hostname -I把输出的 IP 填进 Continue 的apiBase例如http://172.20.10.5:11434。注意要确保 Windows 防火墙放行 11434 端口否则会一直连接超时。如果你想省去每次改 IP 的麻烦可以在 WSL2 里配置端口转发或者直接用 WSL 的镜像网络模式.wslconfig 里 设置 networkingModemirrored这样 WSL2 会和 Windows 共享网络栈127.0.0.1:11434在两边都能访问省心很多。5.3 局域网里多人共享一个模型服务器如果你的团队有好几个人都在用 VS Code 的 AI Chat完全可以只在一台配置好的机器上跑 Ollama其他同事通过局域网访问。具体做法在有 GPU 的那台机器上安装 Ollama 并拉取模型设置环境变量OLLAMA_HOST0.0.0.0:11434启动服务确认防火墙放行 11434 端口同事们在 Continue 配置里填上这台机器的局域网 IP这样整个团队就能共享一个大模型服务每次拉模型只占用一份磁盘空间而且大模型推理对核心机器的 GPU 占用会比较明显所以这台机器最好别同时干其他重活。我实测过局域网内 5-6 个人同时用同一个 14B 模型响应速度会有所下降但还能接受。如果人再多就得考虑上 vLLM 这类专门的高并发推理框架了不过那就是另一套玩法了。5.4 本地模型服务的权限和隐私边界局域网共享虽然方便但也得注意一点默认情况下Ollama 接口没有鉴权机制只要知道 IP 和端口谁都能调用。所以共用方案只建议在可信的内网环境里使用。如果非要暴露到公网一定得自己套一层鉴权服务别裸奔。6. 踩坑记录我在这条路上踩过的雷和解决办法6.1 插件安装报错EPERM: operation not permitted这个报错在 Windows 上非常常见尤其是公司电脑或开了杀毒软件的机器。第一次遇到时我还以为是 VS Code 出 bug 了后来才发现根源多半是权限问题。常见原因是 VS Code 的扩展目录%USERPROFILE%\.vscode\extensions被安全软件锁定或者扩展缓存文件损坏。我的解决办法是依次排查以管理员身份运行 VS Code临时退出杀毒软件后重试安装删除%USERPROFILE%\.vscode\extensions下对应的残留扩展文件夹后重装最后一步通常能解决大部分问题。如果还是不行就去 VS Code 扩展市场下载 VSIX 文件用命令行手动安装code --install-extension /path/to/extension.vsix6.2 Tab 键无法切换命令时的替代方案在用 AI Chat 或者编辑代码时如果你习惯了敲几个字按 Tab 来接受补全但突然发现 Tab 键失效了大半原因是另一个扩展把 Tab 键绑定抢走了。尤其是装了多个 AI 插件时它们都会盯着 Tab 键。这种情况下你可以临时改用 CtrlSpace 手动触发补全或者用 CtrlShiftP 打开命令面板直接搜索要执行的命令。如果想彻底解决冲突打开 keybindings.json 看看是谁占用了 Tab 键把不需要的绑定删掉就好。6.3 clangd 和 C/C 扩展的 IntelliSense 打架这是一个能让人抓狂的问题装了 clangd 之后代码补全提示和 C/C 扩展的提示同时出现而且给出的结果可能还不一样光标一闪一闪的体验极差。解决思路也很简单只保留一个智能感知引擎。如果你用 CMake 管理项目我推荐保留 clangd因为它对 CMake 项目配合得更好还能通过compile_commands.json精确感知每个源文件的编译参数。关闭 C/C 扩展的 IntelliSense只保留它的launch.json调试能力。6.4 本地模型无输出的常见原因好不容易把 Ollama 和 Continue 配置好了聊天面板里发消息却迟迟没有反应或者转了几圈后提示错误。我遇到过的原因主要就三种第一Ollama 服务没启动。确认终端执行ollama list能正常返回如果服务进程被杀了Continue自然连不上。第二模型名写错了。Continue 配置里的model字段必须和ollama list输出里的名字完全一致注意看要不要带标签比如qwen2.5-coder:14b不能只写成qwen2.5-coder。第三端口冲突或代理干扰。本地 Ollama 的127.0.0.1:11434被系统代理拦截时也会导致连接失败这时需要在 Continue 的配置里或者系统环境变量中把代理绕开。6.5 mermaid 绘图插件和 Neo4j 扩展这类“边角料”需求有些开发者会在 VS Code 里写文档想直接在 Markdown 里预览 mermaid 图表。这个需求用Markdown Preview Mermaid Support插件就能实现。配置好之后写一段 mermaid 代码预览窗口直接渲染出流程图不需要打开网页工具。另外如果你在做知识图谱或图数据库相关项目Neo4j for VS Code扩展可以直接连 Neo4j 数据库写 Cypher 语句有语法高亮和自动补全比在浏览器里操作方便不少。我之前帮朋友调一个 nRF Connect SDK 项目时还遇到过 toolchain 下拉选项里明明有 v3.1.1 但怎么都选不中的问题。查了很久才发现是系统里装了多个版本的 SDK 工具链环境变量顺序导致 VS Code 识别混乱。这种问题 AI Chat 帮不上太多忙因为涉及本机特定环境得靠人工排查。但也正因如此把能自动化的部分交给 AI把精力集中在环境类问题上才是合理的分工。6.6 关于 Continue 连接 WSL2 里 Ollama 的一个隐藏坑如果你按照我前面说的方案在 WSL2 里跑 Ollama在 Continue 配置里填了127.0.0.1:11434却连不上别急着怀疑配置先检查一下 WSL2 的 localhost 互通特性是否正常工作。Windows 11 较新版本默认支持 Windows 访问 WSL2 里的 localhost 服务但如果你用的是 Windows 10 或者改了.wslconfig这个特性可能失效。最简单的判断方法是在 Windows PowerShell 里执行curl http://127.0.0.1:11434/api/tags如果没有反应就证明 localhost 转发没生效这时就得改用 WSL2 的 IP 来连接。7. 从折腾到顺手我的最终使用姿势绕了这么大一圈说说我现在的固定配置和习惯。日常开发中我开了三个 AI 入口Continue 接本地 Ollama 的 Qwen2.5 Coder 14B负责快速问答、解释代码、生成补全Claude Code 负责需要动文件的活儿比如重构、写测试、修 bug偶尔遇到它们都搞不定的冷门问题再切到云端大模型问一下。这个组合兼顾了隐私、速度和能力上限。用得越久越发现AI Chat 真正的价值不在于替你写代码而在于降低了你接触不熟悉领域的门槛。以前遇到一个没见过的编译报错得去翻文档、搜博客、试各种参数现在直接把报错扔给 AI几分钟就能得到可执行的方案至于方案对不对你自己判断。这种“快速获得候选方案”的能力才是效率提升的真正来源。最后分享一个我特别想强调的习惯不管是本地模型还是 Claude Code给你的方案永远要当作“同事的建议”来审查别当圣旨。AI 会一本正经地给出错误答案而且看起来非常自信。我踩过最狠的一次坑是让 Claude Code 优化一个内存池的分配逻辑它改完代码后单元测试全过但压测时反而多出了 20% 的内存碎片。从那以后AI 提的每一个优化方案我都会先问一句“为什么这么做”它能把理由讲清楚我才敢合入。多一道这样的审视你才能真正驾驭这些能干的工具而不是被它们的自信带偏。