告别VSCode半年：AI Agent如何重构我的编码工作流

“打开VSCode”这个动作已经从我的日常里消失半年了。不是快捷键失效也不是编辑器坏了而是我的编码方式整个换了一套AI Agent在终端里替我把代码写完、测好、修好我剩下的工作变成了拆需求、审补丁和定验收标准。以前遇到问题第一反应是开VSCode找插件、搜定义、翻Git历史现在第一反应是叫出一个AI工作会话把上下文和输入输出扔给它等它给出diff。这篇文章不是标题党也不是劝退所有人不用编辑器而是把这半年里我从“VSCode重度用户”变成“AI代写代码使用者”的全过程拆给你看工作流是怎么重组的、AI Agent到底怎么用才不翻车、有哪些坑我替你踩过了。无论你是刚接触AI编程、还是已经在用Copilot一类的补全工具这篇文章都适合你——因为重点不是“哪个工具最强”而是“怎么把AI写代码变成稳定可控的日常流程”。1. 告别VSCode我的编码工作流是怎么被AI Agent重组的1.1 我之前为什么离不开VSCode先交代背景。在AI Agent大量出现之前我和绝大多数后端开发者一样VSCode是每天一开机的固定动作。它承载的不是一个编辑器而是一整套个人工作台插件市场里装着Remote-SSH、Python、C/C、Docker、GitLens本地写着代码远程连着服务器集成终端直接跑命令调试面板一键打断点。说夸张点一天八小时有七个小时泡在VSCode里剩下的时间在浏览器里刷文档。那时候VSCode不可替代的核心原因是它把所有“人写代码”的辅助能力聚合到了一起语法高亮让你扫代码更快IntelliSense让你少打几个字跳转定义让你顺着函数调用链往下摸全局搜索让你在一堆文件里捞线索。这些能力本质上都在做同一件事——降低人写代码的心智负担。但你有没有发现这套组合拳解决的是“动手写”之前和之后的问题真的到了“把思路转成代码”这一步键盘还是得自己敲。1.2 让我真正转向AI Agent的转折点转折发生在我开始频繁使用AI编程工具之后。一开始用的还是补全型的帮我续写函数体、生成模板代码感觉上是“VSCode的IntelliSense Plus”没觉得能替代编辑器。真正让我意识到工作流可以重组是我第一次用上Agent模式的编程工具——它不再只是在你光标后面补字而是你给它一句话它自己去读仓库、查文件、写代码、跑命令、根据报错再修最后给你一个已经验证过的补丁。那一次我做的是一个内部数据处理脚本需求是“读取一批Excel按规则清洗后写入数据库”。搁在过去我至少要花半天打开VSCode新建文件写导入逻辑调试跑通。但那次我直接把需求说清楚AI Agent在终端里自己建了Python文件自己装了依赖自己跑了一遍测试数据最后把结果打印出来。我全程只做了一件事——审查它提交的改动。那一刻我突然明白编辑器最重要的“写代码手感”已经不再是瓶颈瓶颈变成了“你能不能把需求讲清楚以及你有没有能力判断AI给的答案对不对”。当AI能自己闭环处理一个任务时VSCode作为“人写代码中枢”的位置就开始松动了。1.3 为什么半年再也没有回去很多朋友问我是不是所有代码都交给AI写了当然不是但确实有相当大一部分轮不到我亲手写了。这半年我的编码节奏变成了这样新需求来了我先理清边界和验收条件然后开一个AI会话让它给实现方案和diff方案不对就继续对话调整方案对了就合入、跑测试。以前最耗时的“写”环节被压缩成了“审”。VSCode在这个过程中退化成偶尔看一眼diff的工具甚至有时候终端里的git diff就足够了。支撑这个转变的核心因素有三个。第一现在Agent模式下的AI能理解整个仓库的上下文知道模块依赖、命名规范、错误处理风格产出的代码质量已经接近初级工程师的水平但速度是人的好几倍。第二IDE本身也在变VSCode里现在也到处是Copilot停机坪说明“AI辅助”已经是行业默认方向。第三也是最关键的当AI写代码的准确率足够高时人的价值就转移到了需求定义和结果审查上而这两件事并不依赖某个特定的编辑器。所以半年没点开VSCode不是赌气是工作流确实回不去了。2. 不依赖VSCode我实际是怎么用AI Agent写代码的2.1 终端里的AI环境准备与工具选型既然不用编辑器我的开发主战场就变成了终端。目前我主要用的几款AI编程工具都跑在命令行里Claude CodeAnthropic 官方 CLI、OpenAI Codex CLI以及国内几家的智能体产品。Coursier 装好之后再跑npm install -g anthropic-ai/claude-codeCodex 则是直接brew install codex都是几分钟的事。安装完记得在终端里配置好模型API的访问凭证Claude Code需要Anthropic API Key或者账号登录Codex需要OpenAI的凭证。没有密钥的话也可以直接用各家官网的订阅版根据自己的预算选。这里说一个很重要的选型心得如果你追求的是“Agent式工作流”优先选CLI工具而不是编辑器插件。原因是CLI工具天然贴近终端操作能直接执行命令、创建分支、跑测试、读文件它跟Git的交互是原生的。编辑器插件往往把AI嵌在侧边栏里更像一个“提词器”反而不擅长自主完成任务。当然如果你目前的舒适区还是编辑器那先用插件模式培养习惯也行但要明白插件模式和Agent模式是两种不同的生产力级别。2.2 提示词工程想让AI写出能用的代码先把需求说人话AI编程最大的门槛根本不是工具而是你给的需求够不够清楚。我总结了一套“需求五要素”写法每次开AI会话前都会过一遍目标你要做的事是什么一句话说清楚。输入/输出输入什么格式的数据输出什么格式的结果。约束技术栈、命名风格、不要用某个库、性能要求、兼容性要求。验收标准怎么算成功最好给一组测试数据或预期行为。上下文涉及哪些文件、哪个模块、参考哪个现有实现。举个例子。弱需求是“帮我写个爬虫抓取网站数据”AI大概率会给你一个泛泛的破烂脚本网站上改个结构就废。强需求是“写一个Python命令行工具读取symbols.txt中的股票代码调用Yahoo Finance的API抓取收盘价输出到CSV接口失败自动重试3次、每次间隔2秒代码遵循PEP 8不需要外部浏览器模拟。验收标准用AAPL,MSFT,TSLA跑通CSV包含代码、日期、收盘价三列”。后一种需求AI一次写完基本就能用前者可能要来回改五轮。把需求写清楚是这一整套流程能跑起来的基础。2.3 从零跑通一个小功能一个完整会话记录为了方便没有体验过的朋友理解我贴一个真实的会话过程。当时的任务特别小统计代码仓库里所有TODO注释的数量和分布。我直接在项目根目录下开了Claude Code输入claude 扫描当前仓库内所有源码文件统计TODO和FIXME注释的数量按文件分组输出结果AI的行为很有意思它没有直接给我代码而是先用rg在仓库里搜索确认了哪些文件有匹配项然后写了一个小脚本统计最后在终端里列出了结果表格。整个过程大概1分钟它自己读了文件、写了代码、跑了命令、输出了结果。我做的事就是看一眼统计数字合理不然后让它标注出数量最多的三个文件。如果换成以前我肯定要打开VSCode按CtrlShiftF再手动数或者临时写一个脚本再删掉。现在这种“一句话搞定”的频率越来越高我越来越依赖终端里的AI对话。2.4 跨文件改动怎么让AI在复杂项目里不跑偏单文件小任务是最简单的真正的考验是大范围重构。比如“把这个模块的HTTP客户端从requests换成httpx并更新所有调用点”。这类任务涉及多个文件AI在长对话里容易漏掉其中一个调用位置或者改着改着就忘了最初的约束。我这半年的经验是跨文件改动要单独开一次会话不要把零碎问题堆在一起。而且开局就给它喂三样东西改动涉及的顶层目录、关键上下文文件的路径、你要遵守的约束比如“不要在数据库层改动”。它先输出一个改动计划我确认计划没漏再让它执行。这就相当于给AI装了一个“范围护栏”它不容易越界你也好审查。3. 那些VSCode时代最头疼的工程问题AI Agent现在直接接管了3.1 环境配置战争结束了C/C、Python、STM32都被AI一把梭以前每换一台电脑或配一个新项目最头疼的就是环境配置。VSCode官网下载完编辑器装插件、改setting.json、配C/C编译环境、调Python解释器路径一个环节不对就是一串红色波浪线。不信你看看多少人搜“VSCode配置C/C环境”、“VSCode配置Python环境”、“VSCode配置STM32开发环境及J-Link下载环境”——每个人都在这上面交过学费。配置类问题通常不是“不会写代码”而是“不知道环境缺了什么”错误信息还晦涩难懂。现在这个场景被AI Agent极大简化了。我的做法是拿VSCode的报错信息直接问AI比如“Invalid parameter was passed to C runtime function”后面跟一长串日志AI能直接翻译成人话并给出修复方案甚至直接帮你把tasks.json、launch.json、c_cpp_properties.json生成好。以前配一套STM32的编译下载环境要折腾大半天现在把芯片型号、工具链路径、J-Link SWD接口类型喂给AI它能生成一个可运行的VSCode任务配置再往里搜报错就行。即使我不打开VSCode也能把问题解决掉。这个能力对嵌入式新手来说是质变级的帮助。3.2 从“写函数”到“写完整工程”依赖、测试、文档一把抓以前的AI补全工具给的是函数体现在的AI Agent给的是完整工程能力。我最近做一个小工具需求是一个REST API服务中间要接Redis缓存和MySQL。AI除了写核心接口代码还自动生成了requirements.txt、docker-compose.yml、单元测试脚本、README文档甚至写了一个启动脚本。要理解这个进步打个比方以前的AI是“作文素材库”给你段落现在的AI是“代笔作家”还帮你校对错别字、排版、加注释。它做的不只是生成代码而是把整个交付物都帮你补齐了。对你来说这意味着什么意味着一个很小的需求从“写代码”到“能上线”之间的距离被AI大幅压缩。但注意压缩不等于消失你要做的事变成了检查依赖版本是否安全、确认测试覆盖了核心路径、看看文档描述是否和实际行为一致。这些审查工作本身就属于工程师的日常只是换了个环节。3.3 让AI做代码审查先滤掉低质量改动这半年我养成的一个习惯是不只让AI写代码还让AI审代码。团队里同事提了PR我如果时间不够直接把PR涉及的文件路径和改动范围丢给AI让它从“性能问题、边界条件、异常处理、安全漏洞”四个角度过一遍。实测下来它能筛掉一部分低级错误比如变量作用域错误、缺少空值判断、循环里做了重复计算这种。AI干这活特别擅长因为它不累不会因为PR太长而偷懒也愿意逐行看。我甚至在个人项目里试过多AI协作的玩法一个AI负责写实现另一个AI负责挑刺。比如让Claude Code实现一个支付回调的接口再让GPT从“并发重复请求”“签名校验时序”“失败重试策略”三个角度做攻击式审查结果真抓到了几个我自己都没想到的边界问题。这招在关键业务上非常好用等于团队里多了一个免费的结对评审。3.4 测试数据与边界条件AI帮你生成用例你负责判断还有一件以前很磨人的事写测试数据。AI现在能根据函数签名和业务规则批量生成边界测试用例空输入、极值、超长字符串、重复请求、并发冲突。让它列出来之后你再决定哪些是有意义的。这比从零造数据要快得多而且覆盖思路广。我管这叫“AI发散的边界清单人来收敛取舍”能在上线前把很多隐性bug找出来。4. 这些坑我替你都踩过了AI写代码的质量风险与控制手段4.1 AI会一本正经地编造API和库函数第一个大坑也是几乎所有AI编程新手都会遇到的AI在不确定某个函数是否存在时会编一个看起来像真的假API给你。比如让你用libcurl写网络请求它会写一个curl_easy_setopt_timeout这种实际上不存在的函数。没有编译或IDE提示的时候你根本看不出来。为什么会这样因为大模型是在生成“概率上最像”的文本它并不会实时查文档验证。我的处理办法很简单重要API调用必须让AI给出依据。在提示词里加一句“用到的库函数请先确认是否存在可以通过README、头文件或官方文档验证再写入代码”或者直接让Agent先执行搜索命令再写代码。对已经生成出的代码如果编译报错不要慌把报错信息原样丢回给AI它自己会纠错。这个循环跑熟了之后假API问题基本能被消灭在无声阶段。4.2 上下文窗口与任务漂移长对话越聊越歪AI Agent的另一个常见问题是任务漂移。刚开始对话时说好的“只重构登录模块”聊到后面它会心血来潮把全局的路由也改了。原因是长对话里上下文窗口满了早期约束被挤出了注意力范围而新上下文中“你觉得怎么完善就怎么改”的倾向占了上风。解决方法的思路是把任务拆小一个会话只做一件事做完就开新会话。如果项目很大把需求写在一个AGENTS.md或者CLAUDE.md文档里每次会话开始先让它读这个文件就像给新同事发入职手册一样。这样AI始终围绕文档里的约定行动不容易跑偏。4.3 业务逻辑理解永远不能全交给AI你以为AI理解了你的业务其实它只是理解了“字面需求”。有次我让AI实现一个文件权限判断逻辑按我的预期应该是“文档创建者可编辑其他人只读”结果AI自动发挥成了“管理员可编辑其他人只读”它替用户加了一个角色系统出来。这个例子很典型——AI会用它见到的“最常见模式”去填你没说清楚的空洞而不是去猜你的真实意图。所以业务规则、权限模型、状态流转这些东西必须写进验收标准里一条条明确。这不是AI不行而是需求规格这件事本来就是人的职责AI只是照单执行。我的经验是凡是涉及钱、权限、隐私、状态机的代码都要把“输入-处理-输出-异常”四件事写详细最好配具体例子。宁可多写两段提示词也不要让AI自由发挥。4.4 安全红线不能省AI生成的代码同样有漏洞很多人有个错觉觉得AI写的代码比人写的安全其实不一定。AI在生成SQL时会用字符串拼接在拼接文件路径时不验证文件名这些都是它“学”到的大量旧代码里的常见毛病。我记得有一次让AI写一个从邮件附件导出文件的脚本它直接用了原文件名拼路径如果附件的文件名里带../../就有路径穿越风险。人写的代码会犯这种错AI同样会犯而且它犯起来更理直气壮。我的建议是让AI写完代码后追加一句“请列出这个改动可能出现安全问题的三个场景”它会把自己生成的代码重新审视一遍多数时候能主动指出问题。但在合入正式环境前涉及鉴权、加密、支付的部分还是要人来过一遍这个环节无论如何不能省。安全审查是底线AI只能做辅助不能做主力。4.5 警惕“看起来能跑”的假完成度AI有个常见特征过度自信。它写完代码后不是说“我写完了”而是给你一份性感的README和一堆测试通过。但有时它所谓的“通过”只是跑通了预设路径并没有覆盖异常分支。所以我对AI交付物的态度是信任但核实。核实的方法不是自己重新写一遍而是看它跑了什么命令、测试覆盖了哪些分支以及主动让它列几个“边界情况我还没处理”。多问它“哪里可能出问题”它反而能给你列很长的清单。5. 新手入坑AI写代码的避坑指南与工具选择5.1 主流AI写代码工具怎么选一张表说清楚这里整理了我实际用过的几类工具各有各的主场。没有最强只有最匹配。工具类型适合场景不足Claude CodeAgent式CLI复杂任务、多文件改、自主执行命令需要订阅/API成本需学习对话习惯OpenAI Codex CLIAgent式CLI与GitHub集成紧密、代码补全和任务执行对复杂工程上下文掌握仍需调教GitHub CopilotIDE插件日常函数级补全、编辑器内辅助单文件内强跨文件任务弱通义灵码IDE插件/Agent中文需求描述、国内环境友好大型仓库上下文能力仍在追Cursor编辑器重度GUI用户、想在编辑器里体验Agent换了编辑器适合愿意迁移的人我对工具选型的建议是如果你是零基础先别上Agent从补全型工具开始在VSCode里装插件用一周熟悉AI的产出风格。如果你已经开始用编辑器里的AI补全而且觉得“它总猜不对我要什么”那说明你已经有一定审查能力了可以切换到Agent模式。如果一上来就上Agent你会被AI的自主行为吓到因为你不确定该让它执行哪些命令。5.2 可直接复制的提示词模板我日常用的提示词模板直接贴在这里你可以根据项目改一改项目背景一句话说明这个仓库是做什么的 我的任务你希望AI完成的功能或修改 输入输入数据的例子 输出输出结果的格式 技术约束 - 不使用 某个不希望的依赖 - 沿用仓库内现有风格 - 其他约束 验收标准 - 怎样算完成例如测试数据A跑通得到B 请先检查相关文件给出改动计划再实施改动并在完成后列出你改动过的文件列表。这个模板的核心是把“验收标准”放在最后逼着AI在动手前先理解边界。你在让它跑之前先念一遍它的计划对不对路。计划对再放行。5.3 哪些项目不适合交给AI写诚实说AI写代码不是所有场景都合适。我自己会特别谨慎的几个场景核心算法的精确实现比如渲染管线、加密协议、实时控制系统的异常路径嵌入式中断处理更要人审、以及业务规则极其复杂的合规需求比如资金账户的操作逻辑。不是AI不能写而是这类代码出错代价太高需要人亲力亲为地逐步推导。反过来CRUD接口、脚本工具、配置生成、数据清洗、文档整理、测试用例这些都是AI的舒适区能交就交。5.4 现在什么情况下我还会打开VSCode虽然标题是“半年没有打开过”但这不是说VSCode就没有用了。我偶尔还是会打开它比如调试一个特别复杂的C程序时断点可视化、调用堆栈查看还是比纯终端舒服或者查看大型Git历史用图形化界面做分支梳理和回滚更清爽再就是审查大PR时VSCode的diff视图和上下文预览确实比终端直观。不过频率确实从“每天八小时”降到了“每周几小时”而且打开它更多是看结果而不是从头写。所以如果你要我给你一个务实的结论VSCode并没有被淘汰它只是从“双手”变成了“眼睛”——偶尔拿来查看、对比、调试核心编码工作被AI Agent接管了。工具不重要产出才重要。写在最后这一路实测过来我最大的体会是AI写代码并不会让程序员失业它只是把大量“把已知逻辑敲成代码”的时间压缩了逼着你把精力放到更上层的事情上——需求定义、架构决策、代码审查、风险控制。半年前我还在为一行缩进纠结现在我更多在看AI是不是误解了业务规则。这个转变一开始有点不适应但用久了你会清楚真正的工程能力从来不是打字快而是把复杂问题拆清楚、把结果管住。最后分享一个小技巧也是我现在每次AI会话结束前必做的一步让AI给自己生成一段“变更审阅笔记”内容包括改了什么、为什么这么改、有哪三个可能出现问题的边界情况。这段笔记会跟着commit一起提交下一个人看代码时直接就有了上下文省了很多沟通成本。这一个习惯帮我减少了至少一半的返工时间。