1. 从半年没打开VSCode说起一个反直觉的开发状态第一次跟朋友说我大概半年没正经打开过VSCode了对方的反应基本都是你转行了。其实没有代码照样在写项目照样在交付只是我打开VSCode的方式变了——以前是打开编辑器→新建文件→敲代码→调试→提交现在更多是描述需求→让Agent改→在diff里审→跑测试→合并。VSCode从主战场退成了审阅台真正干活的位置被AI Agent和MCP工具链占了大半。这个转变不是一夜之间发生的。大概是从去年开始我陆续把一些重复性高、模式固定的活儿交给AI写CRUD接口、补单元测试、改配置、迁移老代码、生成文档。一开始只是当个高级补全用后来发现真正改变效率的不是补全而是Agent能自己读文件、自己跑命令、自己看报错再改。这背后靠的就是MCPModel Context Protocol这类协议把模型和本地工具、文件系统、终端连起来让AI从聊天框变成能动手的助手。所以这篇不是要劝谁卸载VSCode也不是吹AI万能。我想聊的是当AI真的开始替我写代码之后我的工作流到底变成了什么样哪些环节被替代了哪些环节反而更重要了以及踩过的那些坑。适合已经在用AI辅助编码、但感觉也就那样的人也适合还在观望、想知道这套东西到底能落地到什么程度的同行。核心关键词就几个VSCode、AI、IDE、MCP、Agent下面全部围绕它们展开。2. Agent接管编码后我的日常到底变了什么2.1 从我写代码到我审代码的角色切换最直观的变化是输入方式。以前写一个接口我得先想清楚分层、命名、异常处理然后一行行敲。现在我会先写一段自然语言描述比如给用户模块加一个按手机号查询的接口走现有的Service层异常统一抛BizException补上参数校验和单元测试然后让Agent去改。它会把相关文件读一遍找到现有的模式照着写出来。这时候我的角色就从作者变成了审稿人。审稿其实比写稿更考验判断力——你得快速看出它哪里理解错了、哪里偷懒了、哪里引入了隐患。我见过Agent把equals写成也见过它把事务注解加在私有方法上还见过它贴心地帮你把没用的import删了结果删错了。所以审diff的能力成了新的核心技能。以前拼的是打字速度和API熟练度现在拼的是代码审查的敏锐度和对业务边界的把握。这个切换有个适应期。刚开始我总忍不住想我自己写更快确实简单改动自己写可能就30秒。但一旦涉及跨文件、跨模块的改动Agent的优势就出来了它不会累不会漏能把十几个文件的关联改动一次性做完而且改完还会告诉你我改了哪些文件、为什么这么改。这种批量一致性是人手很难保证的。2.2 那些被Agent吃掉的重复劳动具体哪些活儿被接管了我列一下自己实际交出去的样板代码生成Controller、Service、Mapper、DTO、VO这一整套只要有现成的模板Agent照着生成基本不会错。单元测试补全给它一个类它能根据分支覆盖生成测试用例虽然偶尔断言写得不够严谨但骨架和边界用例基本够用。老代码迁移比如把一批Date换成LocalDateTime把旧版HTTP客户端换成新版这种机械但量大的改动Agent做得又快又稳。配置和脚本改pom.xml、写Dockerfile、写CI配置这些有固定套路的交给它省心。文档和注释根据代码反推接口文档、补注释虽然文风一般但信息基本准确。这些活儿的共同点是有明确模式、有参照物、不需要创造性决策。Agent最擅长的就是照着已有的样子再做一遍。反过来涉及架构选型、业务规则模糊、需要跟产品反复确认的需求它就不行了还是得人来。2.3 为什么VSCode从主角变成了配角那VSCode为什么开得少了因为很多操作不再需要打开编辑器这个动作了。Agent可以直接读写文件、跑终端命令、看测试结果整个过程在对话界面里就完成了。我更多是在它改完之后用VSCode打开diff看一眼确认没问题就提交。但注意VSCode没有被淘汰只是位置后移了。它现在承担的是三件事一是审阅diff视图、Git集成、代码跳转这些还是它最顺手二是兜底Agent搞不定的复杂调试、性能分析、断点跟踪还得靠IDE三是环境管理Python环境、C工具链、插件配置这些VSCode依然是入口。所以准确的说法不是不用VSCode了而是VSCode从写代码的地方变成了看代码和管环境的地方。3. MCP到底解决了什么问题让AI从嘴炮变成动手3.1 没有MCP之前AI辅助编码卡在哪在MCP这类协议普及之前AI辅助编码最大的痛点是上下文割裂。你在聊天框里问它问题它只能基于你粘贴进去的代码回答。它看不到你的项目结构不知道你有哪些依赖不能跑测试不能看报错。你想让它改代码得手动复制粘贴改完再手动贴回去。这个来回成本很高高到很多人试了几次就放弃了。更麻烦的是它不知道自己的改动对不对。人写代码可以跑一下看结果AI写完只能靠你肉眼判断。它没法执行—观察—修正这个循环所以经常给出看起来对、实际跑不通的代码。这就是为什么早期很多人觉得AI写代码也就图一乐。MCP的价值就在于打通了这个循环。它本质上是一套标准协议让模型能通过统一的接口去调用外部工具读文件、写文件、执行命令、查询数据库、调用API。模型不再只是生成文本而是能操作环境然后根据操作结果决定下一步。这就从一次性生成变成了多轮迭代。3.2 MCP的工作机制一次改代码的完整链路我拿一个真实场景拆一下。假设我要给订单模块加一个超时自动取消的功能Agent通过MCP大概会做这些事读文件先通过文件系统工具读取订单相关的Service、Mapper、配置类理解现有结构。搜索用搜索工具找到现有的定时任务写法照着模式来。写文件生成新的定时任务类修改Service加取消逻辑。执行命令跑一下编译看有没有语法错误。看结果如果编译失败读报错信息定位问题再改。跑测试执行相关单元测试确认没破坏原有功能。汇报告诉你改了哪些文件、测试结果如何、有没有遗留问题。这个链路里执行—观察—修正的闭环是关键。没有MCP第4到第6步都做不了Agent只能盲写。有了MCP它就能自己验证大大降低了人工返工的成本。3.3 工具选型哪些MCP工具真正值得接MCP工具很多但不是每个都值得接。我的原则是只接那些能形成闭环、且我信任其副作用的工具。具体分几类工具类型典型能力我的取舍文件系统读写、搜索、列目录必接这是基础终端执行跑命令、编译、测试必接但限制危险命令版本控制查看diff、提交接但提交前必须人工确认数据库查询、执行SQL谨慎接只读为主外部API调第三方服务按需接注意密钥管理这里有个安全边界的问题必须说清楚终端执行和数据库写入这两类工具权限给大了很危险。我的做法是终端只允许跑白名单里的命令编译、测试、格式化数据库只给只读账号。Agent再聪明也不该让它有删库跑路的能力。这不是不信任AI是工程上必须有的护栏。4. 我的实际工作流从需求到提交的完整拆解4.1 需求描述怎么写Agent才不容易跑偏跟Agent协作描述质量直接决定产出质量。我踩过的坑是描述太笼统它自由发挥描述太细又变成我在口述代码失去了意义。摸索下来比较有效的描述结构是目标要达成什么一句话说清。约束必须遵守的规则比如走现有Service层异常用BizException不要引入新依赖。参照让它参考哪个现有实现比如照着UserService的写法。验收怎么算完成比如补单元测试编译通过。举个例子我实际用的一段描述给商品模块加一个批量下架接口。要求走现有的ProductService批量操作要加事务参数用List接收并做非空校验异常统一抛BizException。参考UserService里批量删除的写法。完成后补单元测试确保编译通过。这段描述里目标、约束、参照、验收都有了Agent基本能一次做对。如果我只说加个批量下架它可能给你生成一个完全不同的分层结构还得返工。4.2 审diff时我必看的几个点Agent改完我不会直接提交一定会在VSCode里过一遍diff。有几个点是必看的边界条件空集合、null、越界这些它经常漏。事务和并发事务注解位置对不对有没有并发隐患。异常处理是不是吞了异常是不是抛错了类型。依赖变更有没有偷偷加依赖或改版本。测试覆盖测试是不是真的测了逻辑还是只走了个过场。这几项过完基本能拦住大部分问题。剩下的就是跑一遍完整测试确认没破坏别的功能。这个过程看着繁琐但比自己从头写还是快尤其是改动量大的时候。4.3 什么时候我会果断关掉Agent自己上不是所有活儿都适合Agent。以下几种情况我会直接自己写核心算法和复杂逻辑涉及性能、精度、边界极多的自己写更可控。调试疑难问题需要断点、日志、逐步排查的IDE比Agent强太多。架构级改动涉及模块拆分、接口重新设计的需要人来决策。紧急修复线上出问题时间紧自己上手最快。判断标准很简单如果这个活儿需要边做边想就自己来如果是想好了照着做就交给Agent。这个边界不是固定的随着Agent能力提升会往左移但目前这条线还挺清晰。5. 踩过的坑那些让我重新打开VSCode的时刻5.1 Agent自信地写错最危险的一类问题Agent最坑的地方不是它不会而是它不会的时候也写得特别自信。我遇到过一次让它改一个日期格式化的逻辑它用了一个我项目里根本没引入的工具类代码看起来完全合理编译直接报错。还有一次它把一个Transactional加在了private方法上Spring根本不生效但它写得煞有介事。这类问题的根源是它不知道自己的知识边界。它见过太多代码会把别的项目的写法套到你的项目上。所以编译和测试这两道关必须过不能光看代码像不像对的。我现在养成的习惯是Agent改完先编译再跑测试最后才审diff。顺序反了容易先入为主。5.2 上下文丢失多轮对话后的失忆长对话里Agent会忘记前面的约束。比如一开始说了不要引入新依赖聊了十几轮之后它又给你加了个库。或者前面定的命名规范后面它自己改了。这是因为上下文窗口有限早期信息会被稀释。应对办法有两个一是把关键约束写进项目级的配置文件让它每次都读二是长任务拆成短任务一个任务一个对话别在一个对话里干太多事。我现在基本是一个需求一个会话做完就归档避免上下文污染。5.3 权限给太大一次危险的终端操作前面提过权限问题这里说个具体的。有次我图省事把终端执行权限开得比较宽结果Agent在清理临时文件的时候执行了一条删除命令差点把我一个没提交的目录删了。幸好有Git兜底恢复回来了。从那以后我定了两条规矩一是危险命令白名单删除、格式化、强制推送这类一律禁止二是所有改动先提交或暂存保证随时能回滚。AI再靠谱也不能把后悔药交给它。5.4 过度依赖我自己退化的那段时间还有个坑比较隐蔽用久了会退化。有段时间我几乎不自己写代码全靠Agent结果遇到一个需要手写复杂逻辑的场景发现自己反应变慢了API也记不清了。这挺可怕的因为审代码的能力是建立在你自己会写的基础上的。如果你不会写你根本看不出Agent哪里写错了。所以我现在会有意识地保留一部分自己写的活儿尤其是核心模块和复杂逻辑。不是为了效率是为了保持手感。工具是放大器但放大器放大的前提是你自己得有东西可放大。6. 多Agent协作与并发效率提升的下一站6.1 单Agent的瓶颈在哪单个Agent干活瓶颈很明显串行。它读文件、改文件、跑测试一步一步来遇到大任务就很慢。而且一个Agent的上下文有限任务一大就容易丢信息。我试过让它一次改二十个文件结果改到后面它已经忘了前面的约定风格都不统一了。6.2 多Agent分工的实践思路多Agent协作的思路是把任务拆开让不同Agent并行处理最后合并。比如一个大重构可以拆成Agent A改数据层Agent B改服务层Agent C改接口层各自在自己的范围内干活最后人来合并和校验。但这里有个前提任务之间要低耦合。如果两个Agent改同一批文件就会冲突。所以拆分的时候要按模块、按文件边界来分尽量让它们的改动不重叠。我实际用下来多Agent适合那种模块清晰、改动独立的场景比如同时给几个不相关的模块加功能。耦合高的任务还是单Agent串行更稳。6.3 并发下的冲突与合并多Agent并行最大的问题是冲突。两个Agent可能改了同一个工具类或者一个改了接口签名另一个还在用旧签名。解决办法是先定接口再并行。也就是人先把公共接口、数据结构定下来Agent们照着这个约定各自实现最后合并时冲突就少。合并阶段我会用VSCode的Git工具仔细看每个Agent的改动确认没有互相覆盖。这个过程比单Agent慢但总时间还是省的因为并行省下来的时间更多。不过说实话多Agent目前还不够成熟冲突处理挺费精力我一般只在任务量确实大、且模块边界清晰的时候才用。7. 半年之后的复盘哪些能力变得更重要了7.1 代码审查能力成了硬通货半年下来我最大的感受是写代码的能力在贬值审代码的能力在升值。以前一个高级工程师的价值很大程度体现在能写出高质量代码现在这部分被AI分担了价值就转移到了能判断代码好不好、对不对、合不合适。审代码不是简单地看语法而是要判断这个实现符不符合业务语义边界处理全不全有没有引入技术债性能有没有隐患这些判断需要深厚的经验积累AI替代不了。所以如果你在担心AI会不会取代程序员我的答案是会取代一部分只会照着写的活儿但会让能判断、能决策的人更值钱。7.2 需求拆解和任务描述的能力跟Agent协作把需求拆成它能执行的任务是一项新技能。这其实跟带人很像你得把模糊的需求翻译成清晰的指令把大任务拆成小步骤把验收标准说清楚。会带人的人用Agent往往也更顺手因为底层能力是相通的——沟通、拆解、验收。我现在写任务描述的时间有时候比写代码还长。但值得因为描述清楚了Agent一次做对的概率高很多返工少。这跟磨刀不误砍柴工是一个道理。7.3 对工具链和环境的理解用Agent之后我反而更懂工具链了。因为它会调用各种命令、各种工具我得知道这些工具是干嘛的、有什么副作用、怎么配置才安全。以前我可能只会mvn test现在得搞清楚编译、测试、打包、格式化的完整链路还得知道哪些命令危险、哪些安全。VSCode的配置也是。以前装个插件就完事现在得考虑插件和Agent的配合、环境变量的隔离、密钥的管理。这些环境工程的活儿以前可能被忽视现在变得重要了。8. 给想尝试这套工作流的人几句实在话如果你也想试试让AI接管一部分编码我的建议是从低风险场景开始。别一上来就把核心模块交出去先拿工具类、测试、配置这些练手熟悉了Agent的脾气再扩大范围。同时护栏一定要先搭好版本控制、危险命令白名单、只读数据库账号这些是底线。工具选型上别贪多。MCP工具接一堆不如把文件系统和终端这两个核心的用好。Agent的能力上限很大程度上取决于它能接触到什么工具、这些工具好不好用。先把基础打牢再考虑扩展。最后别丢掉自己写代码的能力。这不是情怀是实用主义——你审代码的水平取决于你自己写代码的水平。AI是放大器你得先有东西可放大。半年没打开VSCode不丢人但如果半年没自己写过一行代码那才是真的危险。我现在的工作状态是VSCode开着但更多是在看diff、跑测试、管环境Agent在后台干活我负责判断和决策。这个分工目前挺舒服效率也确实高。至于以后会变成什么样边走边看吧工具在变人的判断力始终是那个不变的核心。