最近同事问我“你电脑上那个蓝色图标怎么不见了”我随口回了一句“VSCode我半年没打开过了。”对方一脸震惊好像我程序员身份被剥夺了一样。但我确实没有开玩笑——自从我把日常开发迁到一个AI编程agent主导的终端工作流之后那个陪伴我好几年的编辑器就这么安静地躺在D盘里吃了半年灰。这个标题不是说“AI帮我搞定了一切”更不是鼓吹“程序员要失业了”。真实情况是过去半年我写代码的方式发生了根本性的变化——从前是“我写代码AI补全”现在是“我给需求AI写码我审码改码”。这个转变不是因为VSCode不好用了而是因为一个新的工作范式把它绕过去了。这篇博文不聊虚的全程是我这半年的真实工作流、踩坑记录、工具选型逻辑和排查经验适合正在观望AI编程但不知道怎么落地的人也适合已经被AI agent折腾过、想看看别人怎么稳住阵脚的人。1. 从VSCode搬到纯AI终端我的工作台长什么样1.1 为什么不是“VSCode里装AI插件”很多人一听“AI写代码”第一反应是OpenAI Copilot或者各种IDE里的AI插件。没错我在早期也是这么干的。VSCode里装上一堆AI辅助插件写函数时自动补全写注释时自动生成。说实话当时效率提升是有的但远远没到“让我半年不打开IDE”的程度。真正的分水岭是我从“编辑器内AI补全”切换到“终端内AI agent自主执行”。这两者的区别很大补全式AI人在写AI在猜主动权在编辑器每一步都要人确认。agent式AI人在描述需求AI在规划、写文件、跑测试、改bug主动权在任务本身。说白了Copilot是帮我打字Claude Code这类终端agent是帮我干活。这个差异决定了工作流的位置如果我还在靠VSCode的插件辅助那我必然天天打开编辑器但如果思路变成“用自然语言下达开发任务AI在终端里直接操作文件系统、执行命令、读报错”那VSCode自然就不是必经之路了。我在实际切换的过程中才发现这个变化不只是“工具变了”而是“整个开发的观察对象变了”。以前盯的是编辑器里的代码高亮和红波浪线现在盯的是终端里的执行日志和Git diff。以前写代码是手部和键盘的肌肉记忆现在是意图和评审之间的不断往返。站在这个角度看打开VSCode反而变成多余的一步。1.2 终端工作流的具体形态先交代我现在的标配环境免得后面讲操作你找不到落点。我日常工作跑在macOS终端加tmux多路复用器上主力AI是Claude Code的命令行版本同时配了一个本地脚本帮我做代码库索引。没有图形化IDE没有项目面板没有调试器断点窗口一切都在终端里完成。# 我的基础环境长这样 - macOS zsh tmux - Claude Code CLI终端AI编程agent - Git GitHub CLIpr、issue、review一条龙 - ripgrep fzf快速检索代码库 - pytest / vitest单元测试兜底这套组合有一个关键点所有环节都是可脚本化、可追踪的。AI agent在终端里做的每一件事——创建文件、修改文件、执行测试、提交commit——都会留下记录。代码评审我直接在终端里看diff有问题当场让AI改改完继续跑测试。VSCode的图形化diff工具在我的工作流里完全失去了意义因为diff已经发生在AI和我的对话里了。有人可能会问没有IDE的跳转定义、查看引用、重命名符号这些功能你写代码不痛苦吗我一开始也这么担心。但实际用下来发现当一个AI能精准定位到代码库里的任意一个符号定义并直接改好的时候我根本不需要自己去跳转。我只需要说一句“这个函数改一下”agent自己就找到了。这类操作就像你以前拿着城市地图找路现在上了出租车告诉司机目的地虽然你失去了看地图的乐趣但你到得更快了。1.3 关键认知AI agent不拒绝终端但拒绝的是“环境割裂”再往深一层说VSCode被“绕开”不是因为终端比IDE更好而是因为终端是“agent能顺畅接管的位置”。IDE本身是给人眼设计的它最懂的是“渲染代码给你看”而AI agent最需要的却是“批量读取文件、批量执行命令、批量处理输出”。举个例子我一个项目里可能有几百个文件AI要读懂它们才能动手。在VSCode里我需要手动一个文件一个文件打开、阅读、总结再提供给AI。而在终端工作流里agent能直接遍历目录结构、批量读取关键文件、建索引省掉了我这个“人肉信息搬运工”。所以与其说我“弃用VSCode”不如说我把“读代码”的任务从人转移给了agent。环境割裂消失之后VSCode就没有什么不可替代的了——我的代码在Git里我的编辑器是自然语言我的输出是diff。2. 一条需求从想法到上线的完整链路2.1 需求拆解如何让AI一次就听懂我刚切换到AI编程agent时翻车率最高的环节不是AI能力不够而是我的需求描述太模糊。这个和人跟人协作一样你安排任务的时候不说清楚验收标准接手的人做出来的东西通常不是你要的。我的做法是把需求拆成四个要素背景、输入、期望行为、验收标准。注意不是把需求写一大堆而是精炼地把这四块讲清楚。一个典型的任务开场是这样的任务在现有FastAPI服务中新增一个用户封禁接口 背景项目中已有users表和auth依赖封禁逻辑参考src/admin/ban.py 的现有实现 输入POST /api/v1/users/{uid}/ban请求头带管理员token 期望行为校验请求者权限将用户状态置为banned删除该用户的所有活跃session 验收标准 1. 单元测试覆盖权限拒绝和正常封禁两个分支 2. 数据库操作走现有异步session模式 3. 不改变其他端点的行为这个描述大概花我两分钟但AI后续干活能节省一个小时不止。原因是agent做出来之后我可以拿验收标准逐条核对不用靠感觉判断“对不对”。这个习惯是我在半年里踩了无数坑之后才彻底养成的。2.2 从任务下达到代码落地的实际过程任务下达之后AI的运作方式不是一次性给你一大坨代码而是分成几个阶段读代码——AI会先扫描相关目录定位用户表、auth依赖、路由注册位置。给方案——它会输出一个简短的执行计划比如“先改schema再新增router再补测试”。写代码——按计划逐文件修改并展示diff。跑测试——调用pytest执行相关测试文件反馈结果。修bug——测试不过则分析报错、修复、再跑。这个过程不是每次都顺利但关键是agent具备闭环能力不是一次性生成完就拉倒。我见过很多人在VSCode里用AI生成了一堆代码结果报错后不知道怎么办最后还是自己上。而在终端工作流里让AI自己“写码、跑测、修错”是一个常态操作。我给你讲一个真实案例。有一次我需要给一个数据清洗模块加上“增量更新”能力直接下了个任务“在现有清洗逻辑上增加按时间戳增量处理的入口老逻辑保留”。AI先读了一遍已有的数据处理流程发现原来代码是面向全量数据的直接在原函数上加增量逻辑会污染旧逻辑于是它自己提出“新增一个independent函数并让入口按参数分流”。这个方案没问题我同意了。它写了一百多行代码加了两个单元测试第一次跑测试有一个case超时它自己分析是因为测试数据造太大了优化了夹具后全绿。整个过程下来我做的事情就是下需求、看方案、审diff、点头或提修改意见。那个下午我甚至不需要打开一次VSCode去手改任何一行代码。2.3 评审diff的艺术AI写码你审什么很多人听到“AI写代码”就很慌担心质量失控。我的经验是AI写代码的质量取决于评审者的水平。VSCode里看代码和终端里看diff本质上都要审但agent工作流给了你一个差异化优势——你审的时候可以带着“我当初给的验收标准”去审。具体审的时候我会重点看几个地方改动范围AI是不是顺手改了不该改的文件。边界处理报错路径、空值、权限校验是否到位。风格一致性新增代码是否和你项目的现有范式一致比如用了async没用await、用了requests而项目统一用httpx。测试有效性AI写的单测是真的覆盖了逻辑还是只为了让测试跑过而写的假断言。我总结了一个经验当你审diff的时候不用纠结每一个变量名是否贴切那些细节AI改起来很快。要盯的是错误处理是否完整和模块边界是否清晰。这两处是AI最容易忽视的。比如你会发现AI生成的代码对“正常路径”总是很慷慨对“异常路径”总是很吝啬。知道这个规律后每次评审我都有意识地往异常分支多看一眼屡试不爽。3. 半年产出复盘与真实瓶颈3.1 用真实数据说话效率到底提升了多少人很容易被主观感觉骗了。为了搞清楚“AI写代码”到底是不是伪命题我给自己做了一个简单的记录每月统计合并的PR数量、修复的bug数、以及花在“编码”上的实际时长。半年下来的一组数据月份合并PR数手写代码行数估编码耗时小时/周第1个月14200035第2个月22150028第3个月36120020第4个月3180018第5个月4260016第6个月4840014说明一下这里“手写代码行数”是指我亲自用键盘敲进去的代码量统计方式是靠git blame粗略估算的。趋势很明显合并的PR数翻了三倍多但我的实际编码时长反而腰斩。不是说我一天工作8小时压缩到4小时然后摸鱼而是我把腾出来的时间花在了更值钱的事情上——系统设计、代码评审、和业务方讨论需求。这里有一个容易被忽略的点PR数量增加不是全靠“AI生成速度快”更多是因为“AI把脏活累活吃掉了”。以前写单元测试特别磨人现在只要让AI补齐测试用例同一时间单位里能完成的功能需求自然就多了。3.2 瓶颈不在AI在上下文管理和项目规范但半年里我也遇到很明显的瓶颈。最大的问题就是项目上下文拉得太长时AI会“遗忘”。举个例子一个包含几十个文件的项目AI读完了前20个文件处理到第30个文件的时候它对第5个文件里的某些约定记忆就变得模糊偶尔会写出风格不一致的代码。我的解法和大多数人的直觉相反不是让AI保持更长的记忆而是主动切割上下文。把项目拆成更小的模块每次只让AI聚焦一块领域的代码而不是整个仓库一锅烩。具体操作上我会在任务描述里“缩小战场”。比如不要动src/core和src/api这两个目录只改src/services/notifier下面的内容。另一个瓶颈是项目规范文档不完善。AI写出来的代码会默认采用“最通用”的风格如果你没有告诉它项目里的统一规范它就会自己发明一套。后来我把项目规范写成了一个简短的CONVENTIONS.md并在每次让AI写代码前用一条命令把规范喂给它。有了这个文件之后AI代码的风格一致性突飞猛进。这个文件名你可以自定义但内容建议至少包含命名规则、错误处理偏好、目录职责边界、测试要求。3.3 那些我依然不会交给AI的部分我不能避重就轻得聊聊哪些事半年了我依然不太放心交给AI干。第一是数据库迁移。涉及现有生产数据的迁移脚本我几乎不会让AI直接写然后执行。原因是数据迁移的风险不在于“代码能不能跑”而在于“旧数据里的脏数据你根本预测不到”。AI写出来的迁移脚本对正常数据通常没问题一遇到异常数据就可能翻车。我的做法是让AI先生成迁移脚本我人工审查它的SQL逻辑再在测试库上跑一遍最后才上生产。第二是安全敏感逻辑。比如权限校验、支付回调、密钥管理。不是说AI写得不行而是在这些领域你承担不起“概率性错误”。权限校验漏了一个分支后果可能是线上事故。所以这一类代码我现在仍然是人工主笔、AI辅助补全。第三是系统架构决策。AI很擅长在给定的架构内写代码但不太擅长判断“这个模块该不该微服务化”“这个消息队列选型合不合理”。这本质是trade-off的权衡AI缺少业务约束条件做了决策也只是“看起来合理”。架构的事我还是留给自己。4. 高频翻车现场与排查技巧4.1 症状一AI“自作主张”改了不该改的文件这是我在前三个月遇到的最闹心问题。明明让AI只修一个接口的bug结果它顺手“优化”了相邻两个文件里的代码导致完全无关的测试挂了。排查和解决思路很简单要求AI给出完整的改动清单并且利用Git隔离。我会在任务描述里强化“只做必要改动”然后在评审diff时严格看改动范围。如果发现AI动了无关文件直接在对话里回复“revert掉这些改动只保留需求相关部分”。多数agent支持精确撤销单个文件修改不用重新来。经验总结任务描述中需要写明约束 - “不要重构相关函数” - “不要修改与本次任务无关的文件” - “只新增不改变现有接口行为”这些看似啰嗦的约束其实作用和人类协作者之间的约定一样——管理预期。4.2 症状二AI测试一直绿但代码实际是错的AI很擅长“骗自己”。最常见的场景是它写了一个单元测试断言写得很宽松导致测试全绿但功能的实际行为不符合需求。我称之为“虚假绿测”。排查这个问题的办法是“反向验证”。我会挑几个AI没有提到的边界情况直接要求它补充测试补充测试场景输入为None时、输入超长字符串时、并发调用5次时如果AI补出来的测试暴露了问题那说明之前的绿测确实不靠谱。这个操作花不了几分钟但能救你很多次。我现在已经养成了一个习惯任何AI交付的功能我都至少追加一个“反例测试”——不是验证它“能做什么”而是验证它“拒绝什么”。比如提交数据的接口我会让它写一个测试验证“未登录用户提交时返回401”。很多AI在写功能时下意识只写成功路径反例测试相当于把这个漏洞堵上。4.3 症状三AI中途卡住或重复执行终端型AI agent偶尔会进入“死循环”比如同一个测试跑三次不过就开始重复无意义的尝试或者反复读同一个文件却始终不得要领。我的排查套路分三步打断并缩小任务——在对话中重新强调“只解决当前这个报错不要尝试其他优化”。提供新信息——把报错日志里最关键的一行指给它看它的分析能力立刻好转。重置上下文——如果还是不行就开一个新会话把需求重新描述一遍并把之前已完成的diff提交到Git确保新会话从干净状态开始。这里有个小细节值得说一下重置上下文之前一定先把当前改动提交或stash不然新会话对整个代码库的理解是“带着半成品”的很容易把状态搞混。我栽过跟头之后每做一个阶段任务就commit一次养成习惯后混乱少了很多。4.4 同一类问题的速查表我把半年里最常踩的坑整理成一个速查表方便你对照排查现象最可能原因首选解法AI输出代码风格和项目不一致缺少规范上下文写CONVENTIONS.md并注入任务描述测试全绿但行为不符合预期断言过于宽松手动追加“反例测试”和边界测试改了任务范围外的文件上下文约束不清任务描述中写明“禁止改动目录”同一报错反复处理agent上下文过长重置会话新会话从Git干净状态开始大量重复代码缺少抽象指令明确要求“提取公共函数保持DRY”生成代码依赖了不存在的库项目信息不完整任务描述中附上requirements或package.json关键内容数据库操作和现有ORM模式不符没有参考现有代码要求“参考src/models中现有实现风格”4.5 几个我逢人就推荐的补救技巧最后分享几个小技巧不算什么高深理论但对我来说非常救命技巧一让AI先写“改动说明”再动代码。我会要求它先输出一个不超过100字的改动计划我确认后再让它修改文件。多一道确认能避免80%的白干。技巧二用分支隔离AI的“猛操作”。我会在让AI动代码前创建一个临时分支比如feature/ai-xxxAI代码全部推到分支上我review通过后才合并。万一煮成一锅粥直接删分支重来就行。技巧三日志是最好的prompt。当AI反复处理不好一个bug时不要抽象描述“它崩了”直接把报错堆栈的原始日志丢给它。你提供的信息越贴近机器实际输出AI的修复准确率就越惊人。5. 什么人不适合这条路线我的判断标准5.1 不适合的人我先泼盆冷水标题写得挺热闹但我不会说“人人都应该扔掉VSCode转投AI agent”。我观察了身边同事和朋友的使用情况发现有几类人确实不适合刚学编程三个月以内的新手。如果你还不能看懂代码的语法、不理解函数调用关系、不会看报错信息那么AI agent对你来说就是把双刃剑——它能帮你生成代码但你连“改坏了哪里”都判断不了。此时老老实实用VSCode、一行一行自己敲打好基本功比什么都重要。维护大型遗留系统的开发者。如果一个项目有一堆陈年历史包袱、循环依赖、动态代码生成AI agent会频繁“读不懂”。这类代码库的隐含知识不在文件里而在老工程师的脑子里你让AI硬读也没用。对每一行代码都有极强控制欲的人。有些人习惯每个变量名都自己定每个边界都要自己推。这种人对AI agent会非常难受因为你要花更多精力去纠正它反而不如自己写。5.2 适合的人有一个共同特质反过来看我用得很好的人都有一个共同特质擅长定义验收标准。说得通俗一点就是脑子里很清楚“做完是什么样”。他们可能不会手工敲每一行代码但他们对“什么算做对了”有非常清晰的定义。这条特质在AI编程时代比“敲代码速度”重要得多。因为你越能清晰描述需求、越能明确告知验收标准AI就越能发挥它的能力。相反如果一个人给AI下达任务时总是“你先看着办、差不多就行”那输出质量就会非常随机。5.3 我的建议不要非黑即白工具是流水的能力是铁打的最后我想说一个最朴素的体会。这半年我虽然没打开VSCode但我的工程能力并没有退步反而在“系统设计能力”和“代码评审能力”上长进了不少——因为我不再把时间花在打字上而是花在思考“这里该不该拆模块”“那里有没有漏异常分支”。将来也许会有比Claude Code更强大的AI工具甚至VSCode自己也会长出一个优秀的AI agent把图形化编辑器和自动化编程重新融合起来。但不管工具怎么变有几样东西不会变你要能说清楚自己要什么你要能看懂别人或者AI写出来的东西对不对你还要能守住安全和质量的底线。这三点才是我这半年最大的收获。