上个月我把一个维护了三年的老项目从"纯编辑器"工作流改成"编辑器加终端代理"混着用，第一周就翻了一次车：让 Claude Code CLI 在仓库里做一次跨模块重构，它在两个同名文件里选错了目标，编译照样过，测试也全绿，问题直到联调才暴露。那次之后我重新梳理了自己对 VSCode 和 Claude Code CLI 的定位，也把日常工具链重新排了一遍。这篇就把这段时间的判断、配置和踩过的坑完整写出来，围绕"VSCode 与 Claude Code CLI 怎么选、怎么配、怎么混用"这条主线展开。适合已经能独立完成日常开发、但还在纠结要不要把 AI 编码工具接进主流程的人看；也适合团队里负责统一工具链、想给同事一套可执行方案的人参考。不管你现在只用编辑器，还是已经在终端里跑代理式编码工具，下面的分工表和配置片段都能直接拿去改。

1. 先分清这两个东西各自站在工作流的哪个位置

1.1 一次真实的改动：从"我自己找文件"到"它替我找文件"

我拿一个具体任务来说明定位差异：给订单模块新增一个"部分退款"状态，涉及状态枚举、数据库字段、接口校验、前端展示、单元测试五处改动。用 VSCode 的做法是：全局搜索refund_status，逐个打开候选文件，凭经验判断哪个是主链路、哪个是历史遗留，然后在每个文件里手动改，靠语言服务跳转和类型检查兜底。整个过程的核心动作是"我找、我改、我验证"，工具负责把找和改的摩擦降到最低。

换成 Claude Code CLI 的做法是：我在终端里用一句话描述需求，它自己去搜索、读取、判断、批量修改，然后把每一处改动以 diff 的形式给我看。核心动作变成了"我描述、我审、我合并"。这两件事的效率拐点非常明确——改动点少于三处、且集中在同一个文件时，手动改反而更快；改动点超过五处、跨三个以上目录时，让它先跑一版草稿、我再挑错，通常比我从零找起省事。

所以第一个结论很直接：它们不是同一层的东西。VSCode 是操作台，负责让"人改代码"这件事本身足够顺滑；Claude Code CLI 是执行者，负责把"人改代码"里的机械查找和重复修改接过去。把两者放在同一个维度上比"谁更强"，从起点就问错了问题。

1.2 手动挡与副驾：为什么我最后没做二选一

我一开始的想法很简单：既然终端代理能自己翻文件、自己改、自己跑测试，那是不是可以基本不开编辑器了？实践两周后否掉了。原因不在于它改得不好，而在于评审环节的体验。终端里的 diff 是流式的，一行一行往下滚，看单文件小改动很舒服，看一次涉及十几个文件的改动就很痛苦——我需要并排对比、需要跳回原文件看上下文、需要随时点开某一行看类型定义是什么。这些恰恰是编辑器的强项。

反过来，编辑器里也有同样明显的短板。让我在 VSCode 里手动完成一次跨十几个文件的机械重命名，再逐个跑测试验证，那半小时基本就没了，中间还容易漏。这种任务交给终端代理，十几秒出草稿，我花五分钟审，性价比高一个数量级。

打个开车的比方：VSCode 是方向盘和仪表盘，你对车况有完全的感知；Claude Code CLI 是坐在旁边帮你盯路、帮你打转向灯的副驾，长途确实省力，但方向盘不能真交出去。我最后落地的方案是长期混用，而不是二选一。后面第 4 节会把具体分工写清楚。

2. VSCode 真正难被替掉的三个能力

2.1 语言服务与调试器：改错的成本在这里被拦住

终端代理能改代码，但它不能替你在断点处停下来看一个变量的实际值。这句话不是贬低，是事实：它的工作闭环是"读文本、写文本、跑命令看输出"，而调试器的工作闭环是"运行时暂停、检查内存状态、单步执行"。后者需要进程在人工控制下停住，流式终端天生不擅长这个交互。

我做过对比测试：一个空指针问题，日志里只报了"第 217 行对象为空"。用 VSCode 的调试器，下断点、看调用栈、看三层对象引用，两分钟定位到是上游某个字段在特定分支没赋值。用命令行方式，只能靠加日志、跑一遍、看输出、再改日志，来回四五次。能复现的问题优先用调试器，这是我一直坚持的原则。

语言服务的价值同理。改一个函数签名，编辑器立刻在所有调用处标红，我能在提交前一次性处理完；终端代理要靠跑类型检查或编译才能发现，反馈链路长了一环。反馈链路越短，返工概率越低，这是编辑器这些年积累下来的最硬的一堵墙。

2.2 工作区配置与扩展生态：团队规范落地的地方

工作区级的.vscode/settings.json是我见过的、把团队代码规范落地成本最低的载体之一。缩进、保存时格式化、行宽、导入排序、拼写检查、特定目录的搜索排除，全部写进版本库，新人拉下代码就自动生效，不需要开会强调，也不需要写文档靠自觉。这种"把规范变成默认行为"的能力，终端工具目前给不了。

一份我常用的最小配置长这样，去掉注释直接能贴：

{ "editor.formatOnSave": true, "editor.tabSize": 2, "editor.rulers": [100], "files.trimTrailingWhitespace": true, "files.insertFinalNewline": true, "search.exclude": { "**/node_modules": true, "**/dist": true, "**/coverage": true, "**/.cache": true }, "files.watcherExclude": { "**/node_modules/**": true, "**/dist/**": true } }

关键不在于这几行本身，而在于search.exclude和files.watcherExclude这两块。大仓库里不加排除，全局搜索会慢到让人放弃使用，文件监听会吃掉大量内存。这两个字段配好，编辑器的响应速度会有肉眼可见的提升，这是很多团队忽略了的基础项。

2.3 什么时候 VSCode 反而是拖累

说句公道话，编辑器也有它明显的低效场景。第一种是纯脚本化的批量操作，比如把三百个配置文件里的某个字段统一加前缀，或者给一批组件补上统一的结构。这种任务在编辑器里做，要么手动点到手抽筋，要么写个正则替换反复校对，风险比收益高。终端里一条命令加一次走查就能完成。

第二种是长时间挂着的任务，比如跑一套十几分钟的集成测试、等一个构建产出、盯着日志看某个偶发错误。编辑器占着图形界面的资源做这些事，纯粹是浪费，终端窗口在小窗口里挂着更合适。

第三种是远程环境下的临时改动。服务器上要动两行配置，打开编辑器还得走一遍连接流程，直接在终端里处理更快。编辑器适合"需要人深度参与的操作台"，不适合"机器跑、人偶尔看一眼"的场景，这个边界划清楚，很多"到底该用哪个"的纠结就自然消失了。

3. Claude Code CLI 改的是"交办"这一段，而不是"补全"

3.1 它自己去翻文件：上下文获取方式的根本差异

编辑器里的补全类工具，工作前提是"你已经把相关文件打开在你面前了"。它的上下文来自当前标签页、光标附近、以及同项目里被引用的符号。它不会主动去搜"这个项目的鉴权逻辑在哪个目录"，因为它默认你已经知道。

Claude Code CLI 的第一个根本差异就在这：它默认自己去找。你说"把这个接口的错误处理统一成新的错误码结构"，它会先搜错误码定义在哪、搜现有接口怎么处理错误、读几个代表性的文件，再动手。这个"先搜后改"的流程，正好对应资深开发者的习惯，也是它在陌生仓库里比补全类工具更有用的原因。

代价是可控性下降。它搜得对不对、读得全不全，你事前不知道，只能事后审。所以我在陌生仓库里第一次用它时，会先让它做一件只读的事，比如"列出这个项目里所有对外暴露的 HTTP 路由及其所在文件"，看它给的清单准不准。清单准，说明它找到了主链路；清单漏了一半，说明目录结构里有它没识别出的约定，这时候再让它改代码就是赌博。

3.2 多文件改动的落地纪律：diff、分支、回滚

多文件改动是它的主战场，也是最容易出事的地方。我给自己定了三条纪律，执行下来基本没再翻过大车。

第一条，永远在干净的工作区上开工。手上有未提交的改动时让它动代码，出问题你根本分不清哪些是它改的、哪些是你自己之前改的。开工前跑一次git status，有脏文件先提交或暂存，这三十秒花得值。

第二条，先看 diff 再接受，而且分块看。它一次改十几个文件时，我会先看改动的文件清单，判断有没有意料之外的文件被碰；再看每个文件改了什么。看到改动范围超出我描述的，直接拒绝，让它重做并说明边界。批量接受全部改动的按钮我是默认不点的。

第三条，改动落地前给一次可回退的机会。大改动我习惯开一个临时分支，或者先git stash一份现场。有一次它在一个工具类里顺手"优化"了一个边界判断，本地测试过了，线上灰度时才发现把某个特殊输入的处理改掉了。如果没有分支隔离，回滚会很麻烦。

# 开工前的标准三步：看清现场、留退路、开工 git status --short git switch -c refactor/order-partial-refund # 大改动前先确认基线是绿的 npm run test:unit -- --silent

这三行命令看着朴素，但它把"出问题时能退回去"这件事从运气变成了流程。

3.3 终端形态带来的三件顺手事

第一件是脚本化能力。终端工具天然能接受管道和重定向。把一次批量检查的输出丢进文件、再用另一个命令处理，这种串起来的能力在图形界面里要实现得写插件。我经常用它做"扫一遍某个目录下所有文件，找出不符合约定的，输出成表格"，这类一次性任务在终端里是一句话的事。

第二件是环境一致性。它跑在我的 shell 里，用的就是项目当前的 Node 版本、当前的依赖、当前的环境变量。不存在"编辑器里跑得通、命令行跑不通"这种割裂。对一个有多个子包、依赖版本敏感的项目来说，这一点省掉大量排查时间。

第三件是可组合。它和 git、和测试命令、和构建脚本在一个空间里。改完立刻跑测试、测试挂了立刻看日志、看完日志立刻让它改，整个循环不需要切换窗口。这个连续性对深度工作状态的保护，比单次操作快几秒重要得多。

4. 我现在的混用方案：一套可以直接抄的配置

4.1 目录约定与项目说明文件的写法

终端代理的效果，很大程度上取决于你给它的项目说明写得怎么样。我习惯在仓库根目录放一个说明文件，把"这个项目是什么、目录怎么分、命令怎么跑、哪些地方别碰"四件事写清楚。核心是具体，不要写"请遵循代码规范"这种正确的废话。

# 项目约定 ## 结构 - apps/web 前端应用 - apps/api 后端服务 - packages/shared 共享类型与工具，改动需谨慎 - scripts 一次性脚本，不进主流程 ## 常用命令 - 装依赖：pnpm install - 跑单测：pnpm test:unit - 类型检查：pnpm typecheck - 本地起服务：pnpm dev:api（端口 3001） ## 硬约束 - 不要修改 packages/shared 下的导出签名，会影响三个应用 - 数据库迁移只允许新增文件，禁止改历史迁移 - 涉及支付、鉴权、账单的目录，改动前必须列清单给我确认 - 所有新增接口必须有对应的单测文件

这份文件的收益是立竿见影的。之前它经常在packages/shared里顺手改点东西，导致其他应用编译失败；写了硬约束之后，这类事故基本归零。另外，"改动前先列清单"这条尤其值得加，它把不可控的批量修改变成了可控的两步操作。

4.2 终端布局与常用别名

我的日常布局是左右分屏：左边终端跑代理，右边编辑器看代码和审 diff。宽度大概是 1:2，编辑器占大头，因为审的时间比说的多。快捷键上我把终端面板绑到一个顺手的组合键，随手能调出来。

几个用得最多的别名，贴在 shell 配置里能省不少敲键盘的力气：

# 快速看当前改动涉及哪些文件，审 diff 前先看这个 alias gs='git status --short' # 改动确认无误后，按文件逐个加入暂存，避免一把梭 alias ga='git add -p' # 跑单测只看失败的用例 alias t='npm run test:unit -- --silent --bail'

git add -p这个习惯值得单独说。批量生成的代码里，通常有七八成是对的，两三成需要修。一把git add .会把对的错的混在一起提交，后面想单独回滚某一处就很麻烦。分块暂存让你能只接收认可的部分，剩下的留在工作区继续改，这个控制粒度对审稿式的工作流是必需的。

4.3 什么时候必须把手放回键盘上

我自己划了四条线，碰到其中任何一条，就不再让它代劳，老老实实自己敲。

涉及核心业务逻辑的判断分支，比如计费规则、权限判定、状态机流转，自己写。这类代码的错误不会在编译期暴露，也不会在常规测试里必然触发，但它错一次代价最大。让它写草稿可以，最终那几行必须我自己过一遍并想清楚每个分支。

涉及并发和事务边界的代码，自己写。它很容易写出"看起来有事务、实际锁的范围不对"的代码，而这种问题只有压测和线上才暴露。这类场景里，人工设计边界、让它补测试，是更稳的分工。

性能敏感的循环和查询，自己写。它给的实现通常是能跑通的朴素版本，索引怎么走、循环里有没有隐式查询、分页是不是全表扫，这些它不一定想到。让它写好之后我再改，改的成本和我们自己写的成本差不多。

最后一条，任何我没读懂它为什么这么写的地方，不许提交。这条是我踩过坑之后加的。有一次它在一段代码里加了个try/catch把异常吞掉了，我看 diff 时觉得"多一层保护也挺好"就放过了，后来那个吞掉的异常正好是上游依赖超时的信号，导致问题被掩盖了半个月。现在我给自己定的规矩是：看不懂的改动，要么让它解释清楚，要么删掉重写，不留"看起来无害"的代码。

5. 选型判断：按项目、按团队、按成本各算一遍

5.1 按项目类型分：四种典型场景的取舍

不同类型的项目，这两者的权重差别很大。我按自己的实际经历整理了一张表，判断标准是"改动的机械程度"和"反馈闭环的长度"。

这张表不是绝对的。我的实际用法是：新项目和老项目重构成熟之后，逐渐把重心移回编辑器。因为项目稳定之后，日常改动变少变精，需要的是精准和可控，而不是批量产出。

5.2 按团队协作方式分

一个人开发和一个团队开发，考虑的东西完全不一样。个人开发时，工具链怎么顺手怎么来，没有协调成本。团队里就要多想两层。

第一层是代码评审的可读性。批量生成的代码如果风格和团队现有代码差距大，评审会变成挑格式，真正的问题反而被淹没。解决办法是把格式化、静态检查放进提交钩子，让风格问题在机器层面解决，评审只看逻辑。

第二层是知识分布。如果团队里几个人习惯把大块逻辑交给工具生成、自己只做浅层审核，时间长了会出现"代码能跑但没人说得清为什么这么写"的情况。我现在的要求是：涉及核心模块的改动，提交说明里必须写清设计取舍，光贴一段生成结果不算完成。

第三层是新人上手。新人用编辑器能通过跳转和提示慢慢摸清结构，用终端代理容易变成"问一句、要一段、贴进去"，跳过了理解的过程。我的做法是让新人前期以编辑器为主，把项目结构走熟之后再引入终端工具，顺序反了会很麻烦。

5.3 成本这笔账要算全

选工具不能只看单次任务快多少，要把隐性成本算进去。我按自己的体感列了一个粗略的对照，分数是主观的相对值，只用来做横向比较。

这张表里最容易被低估的是"上下文切换损耗"。终端和编辑器来回切，每次切换都要重新建立一次心理上下文，一天切几十次，累积的损耗不小。我的缓解办法是把切换变成有节奏的：一批任务在终端里跑完、审完、提交完，再切回编辑器做需要精雕的部分，而不是两边频繁横跳。

6. 踩过的坑：三个看起来能省事实际更费事的做法

6.1 大仓库里把整个目录丢给它

最开始我图省事，直接让它"看看 src 目录下的代码然后改"。结果它读了大量无关文件，抓了一堆过时的实现当参考，改出来的东西和现有主链路完全对不上。更麻烦的是响应变得很慢，因为我给的搜索范围太大。

后来的做法是先缩小范围再交办。让它先只做搜索和列清单，我确认目标文件之后再让它改。范围一收窄，准确率和速度都上来了。经验是：给它一个"目录加一句业务描述"，比给它一个"整个仓库"要有效得多。比如"在apps/api/src/modules/order下找退款相关的处理逻辑"，就比我说的"找找退款在哪"精确得多。

6.2 生成代码"看起来对"的通过率陷阱

有个反直觉的现象：它写的代码通过编译和单测的比例很高，但线上出问题的比例并没有同比例下降。原因在于它的写法倾向于覆盖常见路径，边界条件、异常分支、并发时序这些不太容易在简单测试里暴露的地方，容易被写得似是而非。

我现在的做法是反过来的：让它写实现的同时，要求它把边界条件的测试用例列出来，但测试用例本身我自己审一遍。如果它想不到某个边界，说明它对这块业务的理解不到位，那实现也得重新看。这个检查方式比直接看实现有效得多，因为它暴露的是理解层面的缺口。

6.3 敏感文件与危险命令的边界

这个坑必须单独说。有一次它为了"清理环境"，执行了一条删除构建产物的命令，路径写得比较宽，把一个我本地还没提交的调试脚本目录一起清掉了。东西不重要的，但这件事提醒我：执行类操作的权限边界要提前划好。

我的做法是三层：一是在项目说明里明确写"禁止执行删除类、重置类命令，需要时先问我"；二是把关键配置和凭证类文件放进忽略范围，不让它读；三是涉及数据库、迁移、部署的命令，一律我自己敲，不让它代跑。这三条加上之后，再没出过类似的意外。工具再顺手，删除和部署这两类操作的确认权也不该交出去。

最后分享一个我用了几个月的小习惯：每次让它做完一批改动，我会在提交前花一分钟做一次"反向检查"——不看它改了什么，而是问自己"如果这段代码是我写的，我会不会这么写"。答不上来的地方，就是需要再看一遍的地方。这个动作花的时间不多，但拦下来的问题比我预期的多，尤其是那些"能跑但说不清"的改动。