半年不用VSCode：终端AI Agent如何重构我的编码工作流

算下来我差不多有半年时间没有主动打开VSCode了。这不是标题党——我说的没有打开不是指电脑休眠后重新唤醒、应用自动启动的那种打开而是我作为一个常年写前端、偶尔碰后端和脚本的全栈开发者日常工作里已经不再依赖IDE来完成写代码这件事。以前我也是VSCode的重度用户插件装得比功能用得还多主题换了一茬又一茬C/C环境折腾过Python虚拟环境配过STM32的调试环境也被我硬生生搭起来过。但今天回头看我发现一件有点反直觉的事当AI把写代码这个动作本身接管之后编辑器那些让我曾经痴迷的功能——语法高亮、智能补全、符号跳转、实时报错——突然变得没那么重要了。这篇文章就是对我这半年工作流的一次完整复盘。我会讲清楚我每天怎么用一个终端加上几个AI Agent完成以前需要一整套IDE环境才能做的事我在工具选型上做过哪些对比为什么最后驻留在终端型的AI助手而不是继续留在VSCode里插插件AI写代码在真实项目里会踩到哪些坑、我是怎么给AI立规矩的最后也诚实说一说哪些场景下我还是会老老实实重新打开VSCode。无论你是还在纠结VSCode配置的初学者还是已经开始用Copilot但觉得不够爽的进阶用户这篇文章都应该能给你一些可以直接用的经验和判断依据。1. 半年不开IDE我的日常工作流变成了什么样1.1 一天的工作里IDE的存在感消失了先说一个最简单的观察以前我打开电脑的第一件事是打开VSCode现在第一件事是打开终端拉一下git状态然后直接把需求丢给AI Agent。区别在哪以前的需求是我要写一个函数来处理这个数据现在的需求是我要实现这个功能你看看项目里哪些地方要改。前者需要我自己去设计函数签名、考虑边界条件、写注释、调格式后者更像是在带一个上手很快但需要盯着的实习生——我说清楚目标它负责把活干了我负责验收。这种转变最开始让我有点慌因为代码不是自己一个个字敲出来的总感觉不踏实。但用了大概两周之后我发现一个关键点我的关注点从代码怎么写转移到了代码怎么验——也就是代码审查和测试环节。以前花一小时写代码十分钟看报错现在十分钟让AI写出初稿一小时用来挑毛病、改边界情况、补测试。这个时间分配的变化直接改变了我的工作习惯IDE里那些为了快速写代码提供的辅助设施自然就退到了背景里。1.2 一个具体的例子从接到需求到合并代码的全流程拿我上周处理的一个真实需求来说。产品经理在群里丢了一个需求给现有的列表页加一个按标签筛选的功能要求标签可以多选筛选结果要实时更新同时要处理好与已有搜索条件的联动。放在一年前我的流程是打开VSCode找到列表页组件找到状态管理的文件然后开始设计筛选状态的shape、写过滤逻辑、改UI、处理空状态。这一套下来顺利的话一个上午不顺利的话中间还得翻文档、查类型定义、调样式。这次我的流程变成了这样把需求原封不动贴给AI Agent让它先给我一个改动方案。它读完项目之后列出了一个清单——涉及三个文件一个是状态管理模块一个是列表页组件一个是工具函数库里需要新增一个多选过滤的函数。我看了方案觉得合理让它开工。几分钟后它改完了告诉我改了哪些地方、为什么这么改、有没有覆盖边界情况。我做的第一件事不是看代码而是先跑一遍现有的测试再手动在浏览器里点一遍几种典型场景——多选两个标签、再加一个搜索关键词、清空筛选条件。全部通过后我用git diff扫了一遍改动范围确认没有多余的变更然后合入提交。整个过程中VSCode只在最后看diff的时候被打开了一会儿。平时这个工作流里我甚至不需要打开编辑器。1.3 转变后我的真实工作节奏现在我的典型工作节奏是早上先列举今天的任务清单然后按需求逐个跟AI对话每个任务先聊方案再动工。写代码、改bug、补测试、写文档这些以前靠编辑器完成的事情现在都变成了对话-等待-审查-反馈的循环。这个节奏一开始会让人不太适应因为你不再亲手敲那些代码手感会生疏。但反过来我时间被释放出来了——一天里省下的大量时间被花在阅读代码、思考架构和做产品细节的权衡上。说白了AI把体力活接走了我剩下的是脑力活。而且我现在写代码反而比以前更谨慎了因为AI产出的代码长度往往比我手写更长注释也更啰嗦审的时候反而要更仔细地看它有没有引入逻辑漏洞或者多余的依赖。2. 从VSCode迁移到终端Agent工具选择背后的逻辑2.1 我对四类AI编程工具的真实使用感受这半年里我不是直接从VSCode跳到终端的中间试过好几类工具。整个过程可以分成四个阶段每个阶段都有明确的取舍逻辑工具类型代表我的真实感受适合人群IDE内置补全GitHub Copilot在VSCode里确实能提高打字速度但本质上还是在辅助人写代码没有改变工作流不想改变习惯、只需要提效的人AI优先的IDECursor比Copilot更进一步Agent能改多个文件但我始终觉得它的很多操作还得围着IDE界面转想体验AI改代码、但舍不得IDE体验的人独立编辑器里的AI面板各类插件式Chat像是给IDE装了个外挂大脑问一句答一句缺少对整个项目的主动理解偶尔问问题、不指望AI独立干活的人终端型AgentClaude Code、Codex CLI完全跳出编辑器以对话为主体AI自主探索项目、改文件、跑命令能接受命令行、愿意重构工作流的人我最终驻留在终端型Agent不是因为它完美而是它最贴合我现在的使用习惯我可以直接用自然语言描述目标它自己决定要看哪些文件、怎么改、改完怎么验证。2.2 为什么最终驻留在终端型Agent最核心的差异在于当AI开始写大部分代码IDE的精髓就不再是编辑体验而是上下文理解和行动自由度。在VSCode里哪怕有Copilot辅助我仍然需要自己决定打开哪个文件、光标放哪里、怎么改AI只是一个高级输入法。而终端型Agent可以直接在整个仓库里自由行动读多个文件、定位调用关系、改完还能跑测试反馈给我这已经是交给我执行而不是帮我打字了。另一个被很多人忽略的点是终端型Agent的输入输出是纯文本的这反而让工作流更干净。它不会像IDE里那样弹出各种补全窗口、报错红波浪、自动格式化这些视觉噪音在我需要专注判断这个功能到底要不要这么设计时都是干扰。终端里没有这些只有对话、指令、代码diff、测试结果信息密度很高。2.3 给不同基础读者的工具选择建议如果你刚开始接触AI编程我不建议你一步跳到终端型Agent。原因很简单终端型Agent操作能力很强但也需要你具备基本的命令行能力、git能力和定位问题的意识否则它改出问题你不知道怎么回退。我的建议是分步骤第一先把GitHub Copilot在VSCode里用起来感受AI补全和对话。第二尝试Cursor这类AI优先的IDE让AI尝试改多文件。第三在你有信心处理AI搞砸的情况之后再迁移到终端型Agent。每一步的跨度都不大但每一步都是在重构你对写代码这件事的心智模型。有一点我想专门提一下很多人纠结哪个AI写代码最强我实际用下来的体会是短期内工具的差距远小于你使用方式的差距。同一款Agent给足上下文和明确验收标准的人和直接丢一句帮我写个登录页面的人产物的质量可以天差地别。工具只是下限使用方式决定上限。3. AI写代码踩过的坑它失效的三种模式与应对办法3.1 失效模式一AI自信地提交了错误API第一个大坑AI经常用一种自信满满的态度去调用一个实际上不存在的API。有一次我让AI帮我修改一个Node服务它为了处理某个边缘情况直接写了一个我从来没见过的方法名还煞有其事地在注释里标该方法用于处理XX。结果一跑测试就报TypeError我翻了半天文档发现这个API在当前的依赖版本里根本不存在。这个问题的根源在于大模型的训练数据里包含了太多不同版本、不同框架的代码片段它在生成时是概率上最像的那个而不是当前项目环境里可用的那个。应对办法其实很朴素——它改完之后你必须保留验证环节。我现在默认就是AI交出改动的同时必须给出运行/测试证据不能只给我认为没问题。它会自己跑测试或者提供一条验证命令我把这条命令执行一遍通过了我才会去看实现细节。3.2 失效模式二长对话中上下文被稀释第二个坑是对话一旦拉长AI就会忘记前面已经确认过的约束。最典型的一次前面几轮我跟AI反复确认了某个字段的命名规则结果它写了二十多分钟之后开始自由发挥冒出了三四种不同的命名风格甚至把自己之前定义的规则打破了。后来我搞明白了——长上下文里的注意力分散是客观存在的不是AI偷懒。对策也很简单每个独立的任务尽量开一个新的对话如果任务必须很长中途每隔一段时间就让它把当前状态整理成一份改动清单待办事项写进项目里的一个临时文件作为活动的外部记忆。这样哪怕它后面跑偏了我拿着这份清单也能立刻让它回到正轨。3.3 失效模式三多文件改动时的失控第三个坑最严重当AI一次性改动多个文件的时候容易出现发散性修改——它会在改完需求之外顺手优化掉一些它觉得不好的代码。有一次我让它改一个组件结果它顺手把我们团队封装的工具函数替换成了Node原生API理由是这样更简洁完全没顾及我们的项目规范。那一次我花了大半个小时才在diff里把这些无关改动挑出来。应对这个问题的办法是我现在非常依赖的改动范围约束我每次下指令都会明确只允许改我指定的文件其他文件哪怕看到问题也只要提出来不要动。如果AI确实觉得有优化点它只能写在反馈里由我决定是否单独授权。这个规则写进了我的项目规则文件里AI现在基本不会犯这个毛病了。3.4 让AI先出方案再动手我的负责人模式综合以上三种坑我给自己工作流定了一条铁律任何非纯文案类的改动AI必须先给方案再动手。什么叫方案就是一份清单写明涉及哪些文件、每个文件打算怎么改、这么做会不会引入兼容性问题、怎么验证。方案我点头之后才允许动代码。这个模式最大的好处是让我在执行之前就保有判断权避免AI带着错误理解一头扎进代码堆里。我现在甚至把它当成一个强制流程哪怕需求再小只要涉及两处以上的修改我就要求它先列方案。如果AI直接开始改我大概率会打断它——这个习惯帮我避开了多轮无谓的返工。4. 提示词工程与规则设定让AI输出稳定可用的代码4.1 项目级规则文件把团队规范写进AI的入职手册一个经常被忽视的事实AI进入你的项目仓库时对项目的历史、规范、技术约束一无所知。你每开一个新对话它都是第一天上班的新人。指望它自己从代码风格里领悟规范有时候能做到但极不稳定——不同的代码风格交织时它很容易被带偏。我的做法是在项目根目录维护一个规则文件作为AI的入职手册。不同工具对应不同文件名Claude Code认CLAUDE.mdCodex认AGENTS.md内容结构大同小异。我实际在用的模板大概长这样# 项目规则 ## 技术栈 - 前端React 18 TypeScript Vite - 状态管理Zustand不要引入 Redux - 服务端Node 20 Express不要引入 NestJS ## 代码规范 - 函数命名使用 camelCase组件使用 PascalCase - 禁止在业务代码中使用 any如遇类型问题可以在工具函数中使用 unknown - 所有公共函数必须写 JSDoc 注释说明入参、出参和行为 ## 工作流 - 改代码前先读相关文件先给方案再动手 - 只允许修改用户指定的文件其他文件有问题先在回复里提出不要直接修改 - 每次改动完成后必须提供验证方式命令或手动测试步骤这个文件一旦写好AI每次进项目都会主动读它等于每个对话都从入职培训开始而不是从零猜起。我用了这个文件之后AI产出代码的贴合度提升非常明显至少不再出现随手引入新框架或者在业务代码里用any这类低级问题了。4.2 对话级提示词的结构化写法规则文件解决的是项目级约束但每个具体任务的提示词还是要讲清楚上下文、目标、约束和验收标准。我常用的结构是这样也推荐给你作为模板## 背景 这个项目的xxx模块目前存在什么问题或者需要什么新功能相关文件是哪些。 ## 目标 请实现xxx功能具体要求是1、2、3。 ## 约束 - 只修改xxx文件 - 不改变现有api的行为 - 不要引入新的依赖 ## 验收标准 - 可以通过 xxx 命令跑通现有测试 - 手动验证步骤打开页面点击xxx观察xxx注意约束和验收标准这两块一定不能省。约束决定了AI的改动范围验收标准决定了你判断它干得对不对的尺子。没有这两块AI很容易给你一份看着能用但没法验证的代码——这在变更稍微复杂一点的项目里就是灾难。另外一个小技巧每次对话开始的时候先粘贴相关文件的关键代码片段而不是让它自己去翻。虽然现代Agent自己会找文件但你主动给出的上下文往往是最精准的减少它翻错地方理解偏的概率。翻文件这个能力适合用来补充信息不适合让它自己界定什么重要。4.3 多AI协作的真实形态AI写代码、AI写测试、我评审搜索热词里有一个词叫多AI协作这个我实际也在用但形式和很多人想象的不太一样。我不是同时把多个AI拉进一个对话里而是让不同的AI负责不同的阶段。举个例子主Agent负责业务逻辑的编写和重构完成后我把本轮对话的变更摘要复制给另一个专门用来补测试的Agent让它根据改动补测试用例、跑覆盖率、找边界情况。最后我干的活是确认没有遗漏、没有双标、没有把测试写成自证式——真正的评审。这种分工有个好处写业务逻辑的AI和写测试的AI互相没有看过对方的心思测试反而不容易被实现细节带着走更容易暴露逻辑漏洞。这比同一个AI既写代码又写测试要可靠得多。我在这套协作下跑了一个多月回归测试抓出来的问题明显比过去AI一条龙模式下要多。顺带提一句怎么处理多个AI之间的交接不要直接甩一个超长的对话记录过去。花两分钟把关键改动、关键文件、预期的行为变化整理成几行摘要再传递给下一个AI效果比丢几百行上下文好得多。这跟给新同事交接工作是一个道理——你给的材料组织得越清楚对方上手越快。5. 哪些场景我会重新打开VSCode5.1 调试JavaScript比对话式修bug更有效诚实地讲我并没有完全戒掉VSCode。用得上它的时候第一类场景就是调试。让AI看着报错日志猜测为什么这里拿不到数据不如自己在VSCode里打上断点跑一遍单步调试来得直观。尤其是前端项目里跟浏览器环境交互密切的逻辑比如事件时序、异步竞态、浏览器API的兼容性行为AI靠代码推断和靠断点观察的差距非常大。我现在处理这类问题的典型流程是先用AI定位可能的出错区域然后打开VSCode在关键位置打断点跑起来看运行时状态。AI负责缩小范围我负责最终确认。这时候VSCode真正发挥的是它作为调试器外壳的价值——变量监视、调用栈、控制台输出这些终端Agent给不了也给不好。5.2 代码审查的diff视图优势无法替代第二类场景是代码审查。虽然我在终端里会用git diff看改动但一旦改动涉及多个文件、有大量的增删和移动终端diff的可读性就很吃力了。VSCode的diff视图会把删除和新增分栏展示还能快速跳到下一个改动处配合时间线看提交历史体验确实更好。有一次我审查一个跨了六个文件的改动就坐在那里用VSCode把每一个diff过了一遍确认没有意外删改、没有漂移的缩进、没有顺手改掉的同事代码风格。这个过程纯粹是人肉看逻辑没有AI插手的必要VSCode的diff界面是这个场景里最称手的工具。5.3 给还在配置VSCode的朋友一句忠告翻了翻最近的搜索热词很多人还在纠结VSCode怎么配置C/C环境、Python环境、为什么写C的时候没有代码提示这类问题。我的想法可能会让人意外这些配置问题当然值得解决但如果你打算在这条路上走很久我更建议你把一半的精力分出来去熟悉一下AI编程工具怎么用。以前我们花很多时间折腾IDE本质上是为了自己写好代码。但现在AI已经能把写代码这个动作做得相当好了你的核心竞争力正在转向需求理解、方案设计、结果验收这三个环节。VSCode的智能补全和代码提示是为人手输入服务的而当代码产出方变成AI之后这些功能对你的价值会迅速缩水。与其把所有插件都配到完美不如先把怎么跟AI描述一个需求怎么审阅AI改的代码练好——在我看来这比多装一个主题插件、多配一个环境变量要重要得多。我自己这半年用下来的感受是不开VSCode从来不意味着效率工具不重要而是我的工作重心找到了更适合它的载体。终端加上AI Agent让我把时间花在了判断和决策上VSCode则在它真正擅长的调试和审查环节回到了我的手里。工具没有好坏只有什么场景下合适。你要做的不是跟我一样半年不打开VSCode而是想清楚自己在整个写代码流程里最应该花时间的是哪一环然后把那一环的工具用到位。AI时代真正的分水岭不是看你用没用AI而是看你有没有把人该干的活和AI该干的活分清楚。