VS Code AI Chat实战指南：从Copilot到本地模型，附配置与避坑技巧

你别说，“VS Code 的 AI Chat 现在已经这么能干了？”这句话，是我上周凌晨两点对着屏幕脱口而出的。以前我有个根深蒂固的偏见：IDE 里的 AI 聊天不就是个高级搜索引擎吗，问一句答一段，最后代码还得自己动手改。结果那天我在一个数组分组逻辑上卡了半个多小时，AI Chat 不仅一眼指出了问题所在，还顺手把重构补丁和单元测试样例全部给了我，我在终端里看着它逐行改完文件，那个心情确实有点复杂。所以这篇文章不聊虚的，就把 VS Code 里 AI Chat 当前的主流玩法、接入方式、实测表现、能力边界和配置过程中容易踩的坑一次讲清楚，给关心这个话题的朋友一份可以直接抄作业的参考。

1. 那个让我改变态度的深夜：AI Chat 不再只是“玩具”

1.1 一次真实的排错经历

先说回那个深夜。我手上有个跑了三年的老项目，里面有一段处理用户标签分组的函数，逻辑本身不复杂，但经过好几轮需求变更后，if-else 套得跟俄罗斯套娃一样。那天线上反馈某个活动页的标签偶尔会串组，我打开这段代码，肉眼排查了二十分钟都没锁定问题在哪。后来我顺手在 VS Code 的 AI Chat 对话框里把这整段函数粘贴过去，问了一句“这个分组逻辑哪里可能出错”，它几乎没有犹豫，直接指出第二个分支里groupMap的 key 复用了外层变量，导致第二个用户进来之后上次的分组结果被意外覆盖。这个问题其实不大，但在层层嵌套下极难靠肉眼抓住。

更让我意外的是它接下来的行为：它主动给出了修复后的完整函数，并且建议我补充两组边界测试用例，一组模拟空标签数组，一组模拟相同 key 反复出现的情况。我把它的建议应用进代码里，跑了测试，确实通过。那一刻我突然意识到，这几年 AI Chat 已经不是当初“你问我答、纸上谈兵”的阶段了，它已经开始参与到修改、验证、甚至测试建议的完整闭环中。这种变化，不亲自在项目里用一次，很难有体感。

1.2 AI Chat 两年间的三个关键变化

如果非要把这种“能力跃升”拆开讲，我会总结成三个关键变化：

• 从“对话式检索”变成“可落地的修改器”。以前 AI Chat 给答案是给答案，改代码还是要自己复制粘贴回编辑器。现在像 Copilot Chat 的 Agent 模式或者 Claude Code 这类工具，可以直接在你的工作区里搜索相关文件、读取内容、生成 diff，并一键应用。它不再只是“张嘴说话”，而是真的“动手干活”。
• 从“单文件上下文”变成“整个工作区检索”。过去你问一个问题，它只能看到你粘贴过去的那段代码，对项目其他部分一无所知。现在你可以让它关联整个 workspace，它会自己遍历目录、找到引用关系，然后基于全局逻辑来回答。这个能力在处理跨文件的改动时特别关键。
• 从“只能写代码”变成“能跑命令、看结果、自我纠错”。我和 Claude Code 配合时，它可以自己执行终端命令，跑测试、看报错、再根据报错继续修改。这种“行动-观察-修正”的循环，让 AI Chat 从辅助工具变成了半个结对编程队友。

当然，这里得先泼一盆冷水：它的能力提升并不意味着可以无脑放手。越是强大的工具，越需要你在关键节点把关。后面我会专门讲它的能力边界和一次“翻车”的经历。

2. 想用 VS Code 的 AI Chat，先看清这四条路线

很多人接触 VS Code 的 AI Chat 都是从 GitHub Copilot 开始的，但这两年生态已经分化出好几条完全不同的路线。搞清楚它们的区别，比直接装插件更重要，因为每条路线对应的能力上限、成本、隐私条件和适用场景都不一样。

2.1 路线一：GitHub Copilot Chat，最省心的“官方标配”

GitHub Copilot 是绝大多数人最先接触到的方案，它直接内嵌在 VS Code 中，从代码补全发展到聊天功能，再到现在的 Agent 模式，演进速度非常快。你在侧边栏打开 Chat 面板，可以用@workspace让它检索整个工作区，用@file指定某个文件作为上下文，甚至让它解释当前终端的报错。

这条路线最大的优势是省心——安装官方扩展、登录 GitHub 账号、开启 Copilot 订阅即可，不需要自己配置模型、管理 API Key。它的代码补全质量依然在线，聊天能力在几年前属于另一个维度，因为背后有多个很强的基础模型做支撑，很多模型可以在聊天面板里直接切换。

但这条路线也有明显的“政策”约束：它和你 GitHub 账号深度绑定，需要订阅；一些对数据敏感的团队可能不敢把内部代码交给第三方服务去分析。后者也是很多公司选择下一条路线的原因。

2.2 路线二：Claude Code + VS Code，编码代理的激进派

Claude Code 最初是跑在终端里的一个命令行工具，后来官方推出了 VS Code 扩展，可以直接在编辑器里用对话驱动的方式操作整个项目。它和传统聊天工具最大的区别是：它更像一个编码代理，而不仅仅是一个代码问答工具。

你可以让它“帮我重构src/utils/format.ts里面的日期处理逻辑，并跑一下相关的测试”。它会自己去读文件、设计改动方案、修改文件，然后打开终端执行测试命令，如果测试失败，它还会继续调整代码，直到测试通过或者确认需要人工介入。这种自主执行能力在编码类 AI 里是走得比较远的。

不过，能力和风险总是成正比。给它的权限越大，它能“搞事”的范围也越大。所以官方的权限确认机制做得很保守，默认情况下每次工具调用都会询问你是否允许执行。如果你在沙箱环境或 CI 里使用，可以显式跳过权限确认，但我的建议是本地开发环境不要开“免确认模式”，哪怕多敲几次回车，也比让它误删文件好得多。

2.3 路线三：Ollama 本地模型，离线也能有 AI Chat

如果你的需求是数据不出本机，或者网络环境不稳定，那就绕不开本地模型方案。Ollama 是目前最简单易用的本地大模型运行工具，配合 Continue、Cline 这类支持自定义模型的 VS Code 插件，就能在完全离线的状态下获得 AI Chat 能力。

我自己的 Mac 上跑的是 Qwen2.5-Coder 14B 的量化版，内存占用大概 9GB 左右，虽然响应速度不如云端 API 那样秒回，但在可接受范围内。现在的开源代码模型能力其实已经很能打了，处理函数编写、Bug 定位、单测生成这些日常场景完全够用。对于不依赖最新长上下文能力的团队，这是一条成本很低的路线。

2.4 路线四：第三方平台接入（MiniMax Code 等国内方案）

除了 Copilot 和本地方案，还有一类是接入国内大模型开放平台的方案，比如 MiniMax Code。这类方案通常提供 OpenAI 兼容的接口，你可以通过 Continue、Cline 等插件，在“API Provider”里选择 OpenAI 协议，填上对应的 Base URL 和 API Key，就能把模型接入到 VS Code。

我身边有朋友就在用 MiniMax 的代码模型做日常辅助，它的优势是中文理解好、国内访问延迟低、连接稳定。如果你对网络连接稳定性有要求，又不想用本地模型，这类平台值得一试。配置本质上就是“自定义模型接入”，后面在 Ollama 章节我会再说一遍 Continue 的配置逻辑，二者是相通的。

为了让你对这四条路线有一个直观的对比，我整理了一个表格：

3. Claude Code 接入 VS Code：我这边跑通的完整过程

3.1 安装之前必须确认的三件事

Claude Code 的安装看似简单，但我在第一次装的时候还是踩了两个流程上的坑，所以先把前置条件列清楚。

第一，你需要一个能正常工作的 Node.js 环境。Claude Code 是基于 Node.js 的命令行工具，官方建议使用 Node.js 18 以上版本，我自己用的是 20 LTS。确认 Node.js 版本可以打开终端执行node -v，如果输出版本号，就说明基础环境没问题。如果还没装 Node.js，建议去官方网站下载 LTS 版本安装，别从乱七八糟的渠道搞“绿色版”，后面会有一堆权限问题。

第二，终端环境必须正常。这个听起来像废话，但真的有人卡在这。Claude Code 在 VS Code 里跑起来后，要调用终端执行命令，如果你的 VS Code 默认终端是 PowerShell、CMD、Git Bash 混着用，而且路径解析有问题，后面会有很多怪毛病。我的做法是 Windows 上统一用 PowerShell 7 或者 Git Bash，macOS 上原生 Terminal 就行，先把默认终端定下来再装工具。

第三，想清楚用官方账号登录还是用 API Key。这两种方式各有各的应用场景：如果你只是个人日常使用，直接claude命令走官方账号授权登录最快，登录一次能管很久；如果你在团队项目或自动化脚本里要用，那么通过环境变量配置 API Key 是更好的选择，方便统一管理，也不占用个人账号的交互额度。后面我会给出两者的具体操作。

3.2 安装与授权步骤

确认好上面三件事后，安装过程就非常简单了。打开终端，执行：

npm install -g @anthropic-ai/claude-code

全局安装完成后，直接在终端里输入claude，首次运行时它会引导你完成登录。如果你选择用 Anthropic 账号授权，它会打开浏览器让你确认登录，然后在终端里回显授权结果，整个过程一道命令都不用手动改配置。如果你是 API Key 路线，在终端里配置环境变量即可：

# Windows PowerShell $env:ANTHROPIC_API_KEY = "你的Key" # macOS / Linux / Git Bash export ANTHROPIC_API_KEY="你的Key"

如果你想长期生效，建议把环境变量写进 shell 配置文件中，而不是每次打开终端都临时设置一次。

装好命令行工具之后，再到 VS Code 扩展市场搜索 “Claude Code for VS Code”，安装官方扩展。装完重启 VS Code，侧边栏会出现 Claude 的图标，点击后可以在编辑器里直接对话，不必切到外面终端。两种使用方式跑的底层逻辑是一样的，但我个人在 VS Code 里更喜欢用扩展面板，因为选中代码后可以直接右键“发送给 Claude”，上下文传递更顺滑。

3.3 让 Claude 记住项目习惯：CLAUDE.md 的实战价值

这里有个非常实用的进阶用法，我想单独拎出来说：在项目根目录放一个CLAUDE.md文件。这个文件是 Claude Code 的“项目记忆”，每次对话它会自动读取并作为长期上下文。你可以在这个文件里写清楚项目的技术栈、目录结构、常用命令、编码规范、已知坑位等等。

举个例子，我维护一个 Spring Boot 项目时，会在CLAUDE.md里写下这么一段：

# 项目规范 - 使用 Java 17，Maven 构建 - 所有接口返回值统一走 Result<T> 包装类 - 业务逻辑放 service 层，controller 层禁止写判断逻辑 - 测试使用 JUnit 5 + Mockito # 常用命令 - 本地启动: mvn spring-boot:run - 跑全量测试: mvn test

建好之后，后续让 Claude 写接口或者加功能时，它自动就会遵守这些约定，代码风格和项目现状基本保持一致。这个习惯一旦养成，你会明显感觉到 AI 的输出质量上一个台阶。没有这个文件的时候，它经常按“通用最佳实践”来写代码，容易和项目的既有风格产生冲突。

4. 不花一毛钱的本地 AI Chat：Ollama 离线方案实操记录

4.1 为什么我会在云 API 这么好用的情况下坚持试本地模型

其实我一开始也嫌本地方案麻烦，后来促使我去试的真正原因是两件事。一是有一次我在高铁上改代码，笔记本连的是手机热点，信号在隧道里断断续续，云端 AI 聊天几乎没法用，那一次我特别想有一个本地方案兜底。二是有个朋友的公司做政务项目，代码完全不允许出内网，他们对 AI 工具的需求是“可以在内网环境用 AI 辅助写代码”，这不就得靠本地模型嘛。

所以本地模型方案的核心价值就三点：完全离线、数据不出本机、长期使用零调用成本。当然它也有短板，模型能力受硬件约束，运行大模型需要足够的内存和算力，响应速度也比不上云端 API。但它作为一种兜底和隐私优先的选项，在 2024 年之后越来越成熟，完全值得一试。

4.2 硬件门槛与模型选型参考

跑本地模型最关键的限制是内存，这也是选型时首先要考虑的因素。我用一个表格把常见规格列出来，供你参考：

以我自己的使用经验为例，我在一台 32GB 内存的 Mac mini 上跑 Qwen2.5-Coder 14B，4bit 量化后占内存约 9GB，生成速度大概每秒 20 来个 token，日常问问题、改小函数完全够用。如果你手头只是 16GB 内存的机器，那更推荐先跑 7B 的模型。配置太低强行跑大模型，内存会频繁交换，体验会非常痛苦。

4.3 从零到能聊：Ollama + Continue 插件的完整流程

本地方案的软件部分很直接。先下载并安装 Ollama，Windows 和 macOS 可以直接到官网下载桌面版安装包，Linux 用户用一行命令：

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，打开终端拉取代码模型。这里我以 Qwen2.5-Coder 14B 为例：

ollama pull qwen2.5-coder:14b

首次拉取会下载约 9GB 的模型文件，具体大小取决于你的网速。拉完之后，可以先直接在终端里验证一下模型是否能正常回复：

ollama run qwen2.5-coder:14b

输入“写一个快速排序函数”之类的测试指令，能看到回复就说明本地模型已经跑通了。之后在 VS Code 里安装 Continue 扩展，然后打开配置文件~/.continue/config.json，添加本地模型：

{ "models": [ { "title": "Local Qwen Coder", "provider": "ollama", "model": "qwen2.5-coder:14b" } ] }

保存配置后，在 Continue 面板里切换到 “Local Qwen Coder” 这个模型，就能开始对话了。这里的核心原理其实不复杂：Ollama 会在本机起一个服务（默认端口 11434），Continue 通过这个地址调用模型，所以所有的请求都在本机完成，不存在任何外部流量。

4.4 实测下来，本地模型能做什么、不能做什么

我必须诚实地讲一下本地模型的能力边界。实测下来，14B 这个级别的模型处理“明确的、小范围的”任务表现是靠谱的：解释一段晦涩代码、给某个函数写单测、根据注释生成一个小工具函数、指出明显的语法或逻辑错误，这些它都能干，而且不用花钱。

但如果你给它一个非常庞大的项目，要求它跨八个文件做一次大规模架构调整，它会明显吃力：上下文一长，它会把遗忘前面的关键信息，甚至开始“一本正经地胡编”。这和云端的大参数模型还是有明显差距的。所以我对本地模型的定位是：离线兜底和隐私环境下的日常辅助，关键决策还是交给更强的模型或人工来做。

5. 真正能提效的几个场景：跨文件重构、历史代码解读、审查

5.1 跨文件改动：从“查资料”升级到“出补丁”

我做了一个不算严谨但很直观的对照实验：用一个旧的 Node.js 项目，让 AI Chat 把其中三个文件里的 Promise 链统一改成 async/await，并且保持对外行为不变。传统聊天工具能做到的是给你展示“应该怎么改”的示例代码，然后你自己去三个文件里逐一落地；而 Claude Code 这种代理式工具能做到的是直接打开这三个文件，自动生成改动方案，让我逐个确认，改完再跑项目的 lint 和测试，整个过程它自己驱动。

坦白说，第一次看到它连续改完三个文件并跑通测试的时候，我确实有点“这孩子长大了”的感觉。这种能力的本质是：AI Chat 已经可以组合使用“读取文件、编辑文件、执行命令”等多种工具，而不是单纯靠回答文字来干活。对于我这种经常需要做跨文件小重构的人，效率提升是实打实的。

5.2 接手历史代码：AI 是很好的“代码解说员”

另一个我觉得特别实用的场景是接手别人留下的老代码。每次进入一个不熟悉的项目，光是把工程结构摸清楚就需要半天，更别提那些充满历史包袱的诡异逻辑了。现在我的习惯是，选中一个模块后直接问 AI Chat：“这个模块的入口在哪里？整体数据流是怎么走的？有没有明显的坏味道？”它基于整个工作区的检索，通常能给出比我看文档更快的答案。

有一次我在看一个十年前的老项目中处理编码转换的部分，代码里全是位运算魔法，注释几乎没有。我就把这几十行代码扔给 AI Chat，让它用“给新手讲解”的方式逐行解释。它给出来的答案不仅讲清了每个位运算的作用，还主动指出其中一处逻辑在边界值传入时可能产生溢出问题。这种“快速理解历史代码”的能力，对于做维护型开发的开发者来说，价值比写新代码还要大。

5.3 终端、Git 和文档联动：AI 不止能改代码

现在的 AI Chat 还有一个容易被忽略的点：它不只是改代码，还能和终端、Git、文档协同工作。比如你可以让它“看看当前分支和主分支的差异，总结一下这次提交影响到了哪些模块”；或者在数据库项目里直接让它“根据这三张表的关系，写一段 Cypher 查询，找出所有和某用户有间接关联的节点”。在 VS Code 里安装 Mermaid 插件后，你甚至可以让 AI Chat 生成 Mermaid 格式的流程图，然后直接内嵌到 Markdown 文档里预览。

这种“工具面板式”的使用方式拓宽了 AI Chat 的应用场景。以前你可能需要在搜索引擎、文档站、IDE 之间来回切换，现在很多问题在对话流里就能解决大半，隔壁写 SQL 的同事看了都开始抄作业。

5.4 代码审查：当第二双眼睛

我目前用得最勤的其实是“AI 作为代码审查的第二双眼睛”。每次提交 PR 之前，我会先让 AI Chat 过一遍变更文件，重点看三类问题：明显的逻辑漏洞、和项目现有风格不一致的写法、遗漏的边界条件。实测下来，它对逻辑漏洞和风格问题的准确率不错，但边界条件经常会提一些过度设计式的建议，需要人工判断。

这里我的态度是：AI 审查适合“查漏”，不适合“挑刺”。它能在你疲劳的时候帮你抓出一个可能被你忽略的undefined分支，但它也可能因为过于“教科书风格”而建议你加一堆这个项目根本不需要的抽象层。审查这件事，最终拍板的还得是人。

6. 它也会一本正经地胡扯：能力边界必须心里有数

6.1 依赖与环境的“幻觉自信”

AI Chat 在代码生成上最大的隐患不是语法错误，而是它对“依赖和环境的幻觉自信”。它会很流畅地告诉你“使用useContext可以解决这个问题”，却完全不知道你当前项目的 React 版本是 16 还是 18，也不了解你的构建工具是否支持它推荐的那个特性。它推荐的依赖包甚至可能根本不存在，或者版本号在它的训练数据里是存在、但现实中已经被废弃。

我遇到过最典型的一次：它推荐我使用某个 npm 包里一个并不存在的 API，而且给了完整的调用示例。因为它的表述太自信了，我最初根本没有怀疑，直到运行时报“module.exports 不是一个函数”的错，仔细查了文档才发现这个 API 从来就没有出现过。这件事之后我总结出一条铁律：凡是 AI 推荐的“外部依赖”“陌生 API”“非常规配置”，都必须到官方文档验证一次，花不了两分钟，但能省下大半天排查时间。

6.2 架构级建议得打三折看

越是“看起来全局视野很强”的架构级建议，越要保持警惕。AI Chat 擅长的是给出“结构上正确”的方案，但架构设计从来不只是结构正确，它涉及到团队协作习惯、历史包袱、部署环境、性能预期、甚至组织边界。AI 不懂你们团队谁擅长哪块，也不知道这个模块未来会怎样演进，它的架构建议本质上是从它的训练数据里“统计”出来的最优解，而不是你这个具体项目的最优解。

我现在使用 AI Chat 的一个原则是：它做“解释、实现、验证”我大力欢迎，它做“决策、选型、架构定夺”我严格把关。如果它给了一套看起来很漂亮的六边形架构方案，我会把它当成一个候选意见记录下来，但绝不会因为它写得自信就照单全收。

6.3 模型的时间差：你以为它很懂“当前”，其实它有滞后

大模型的训练语料有截止日期，它的知识天然有时间滞后。你问它“2025 年最新的 React Router 用法”，它很可能还在按老版本的路由配置方式来回答。这不是它不聪明，而是它脑子里确实没有比你更新的信息。

所以处理“新技术、新版本、新 API”相关问题时，我一般会让 AI Chat 先回答一遍，然后结合自己的常识或者官方文档去校验。遇到它不清楚的新特性，它会很诚实地告诉你“知识截止到某个时间，建议查阅官方文档”，这种回复反而让我觉得靠谱。真正危险的是那些不承认自己不知道、继续编答案的情况，所以涉及新版本特性时，始终保留一份对官方文档的信任。

7. 配置和日常使用中容易踩的五个坑，附排查思路

7.1 插件安装报错 EPERM：权限与缓存的经典组合

在 Windows 上装 VS Code 扩展时，经常会遇到error: eperm: operation not permitted这个报错。我第一次遇到时以为是扩展市场的问题，折腾了半天才搞明白，罪魁祸首通常是 VS Code 的扩展目录权限错乱，或者是扩展缓存损坏。

排查顺序我建议这样：先用管理员身份重新打开 VS Code 试试，如果问题依旧，就手动打开扩展目录（Windows 上是%USERPROFILE%\.vscode\extensions），找到对应的插件文件夹删掉，再到扩展市场重新安装。还有一种情况是公司电脑上被安全软件锁定了某些目录的写权限，那就需要联系 IT 把 VS Code 和扩展目录加入白名单。特别提醒一下，那些从第三方渠道下载的“便携版”VS Code，扩展目录的位置很迷，权限问题更容易出现，属于自找麻烦。

7.2 扩展市场 failed to fetch：先做这几步排查

“Failed to fetch”是 VS Code 里常见的网络类报错，很多人第一反应是扩展市场挂了，但其实大部分时候是本地网络环境的问题。我这边实测有效的排查路径是这样：

• 先看是不是临时网络波动，直接多试几次，很多时候自己就恢复了；
• 检查电脑是否存在系统级代理规则导致连接异常，如果公司内网有访问限制，那大概率需要管理员把扩展市场域名加白；
• 看看是不是开了某些“离线模式”或安全软件拦截，这些软件会静默拦截接口请求，表面看起来就是 fetch 失败；
• 如果是局域网环境，建议先从官网下载 VS Code 的离线安装包或者用命令行安装扩展，绕开实时联网。

这里有一条底线：无论如何不推荐使用非官方渠道来绕过网络限制，既不稳定，也有安全风险，老老实实走官方支持的方式才是正道。

7.3 nRF Connect toolchain 无法选中：SDK 状态才是元凶

这个坑我是在做嵌入式工程时踩到的。在 VS Code 里用 nRF Connect 扩展时，Toolchain 下拉框里明明有nrf connect sdk toolchain v3.1.1这个选项，但就是无法选中，点上去没有任何反应。一开始我以为是扩展 bug，反复重启了 VS Code 也没用。

后来仔细看 nRF Connect 扩展的输出日志才发现，问题不在 VS Code，而在这个 toolchain 本身没有完全下载或安装完成，SDK 路径根本没就绪，所以下拉框里的选项是“可见但不可用”的状态。解决办法是到 nRF Connect 扩展的 Toolchain Manager 面板里查看实际下载进度，确认安装完成后，再回到下拉框选择，就能正常选中了。这个经历告诉我：VS Code 里的很多“界面问题”，根因其实在外部工具链，不要只盯着编辑器本身排查。

7.4 Tab 键补全失灵：快捷键冲突的排查路径

如果你用过 Copilot 或者各种 AI 代码补全插件，一定遇到过“Tab 键突然无法接受补全建议”的情况。这个问题的根源十有八九是快捷键冲突：某个插件抢占了 Tab 键，或者你的输入法快捷键把 Tab 事件截走了。

排查路径很简单：先禁用最近安装的插件，看看 Tab 键是否恢复；重点检查有没有同时装了多个“代码补全类”扩展，比如 Copilot、Tabnine、Codeium 同时开启，它们会互相抢占快捷键。另一个容易被忽略的点是 VS Code 的输入法联动，如果你在用中文输入法，输入框的候选窗口可能会吃掉 Tab 事件。如果 Tab 键怎么都调不好，你还可以用Ctrl+Shift+P打开命令面板，直接搜索“接受建议”或者相关命令，手动触发补全确认，实测能临时救急。

7.5 clangd 和 AI Chat 同开：资源占用实测

我日常写 C/C++ 时会开启 clangd 语言服务，同时又要挂着 AI Chat，两个工具对内存的消耗都不低。实测下来，在打开一个中大型 C++ 工程时，clangd 通常要吃掉 1.5~2GB 内存，而本地跑 14B 模型要占 9GB 左右，如果再开几个浏览器标签页，16GB 内存的机器会非常紧张。

解决方案有三个：一是给 VS Code 设置更大的 Node.js 内存上限，在启动参数里加--max-old-space-size=4096，避免语言服务提前崩溃；二是尽量在需要本地模型时才启动 Ollama，不用的时候关掉，用ollama stop释放内存；三是把 clangd 的索引范围做一下限制，去掉一些不需要索引的目录，比如只在src和include下做索引，能省不少资源。

8. 我现在的日常工作流：谁干活、谁把关、谁兜底

8.1 一个相对稳妥的“人机分工”规则

经过这几个月的搭配使用，我慢慢形成了一套相对稳定的人机分工规则，分享出来供你参考：

• 让 AI Chat 负责“明确且边界清晰”的实现类任务，比如写单元测试、实现文档里描述得很清楚的函数、做小范围的跨文件重构。这类任务目标明确、验收标准好定义，AI 的完成度通常很高。
• 让 AI Chat 负责“快速理解”类任务，比如解读老代码、梳理数据流、总结 diff、生成流程图。这类任务不需要它做决策，只需要它把信息整理清楚，人在关键结论上复核一下即可。
• 人工把关“决策类”任务，包括依赖选型、架构设计、和环境相关的排错。在这些事情上，AI 更倾向于给出“看起来正确”的答案，而这些答案往往缺少对你现实的考量，直接采用会埋下隐患。
• 保留一个“最后兜底”的验证环节，无论 AI Chat 给出什么样的修改建议，都要在本地跑一遍测试、lint、构建，确认没有破坏现有功能后再提交。

8.2 给不同基础读者的建议

如果你是刚接触 VS Code AI Chat 的初学者，我的建议是先走最简单的路线：装一个 GitHub Copilot 或者用 Continue 接一个云端模型，先感受一下“边写代码边有 AI 助手”的体验，不用一上来就折腾本地模型和代理式工具。等你对它的能力和脾气有了一定体感，再根据自己的隐私需求、离线需求、项目类型去调整方案。

如果你是我这种对本地方案、代理式工作流都感兴趣的老手，我的建议是：把 Claude Code 和 Ollama 当成互补的两件工具来用，云端方案负责复杂任务，本地方案负责隐私和离线场景，日常都把项目根目录的CLAUDE.md维护好。一个人如果能把工具链配置得顺滑，AI Chat 在项目里发挥的作用，确实会超出你最初对“聊天助手”这四个字的预期。