整理电脑的时候翻到VSCode这才发现它已经半年没被我打开过了。两年前这是不可想象的那时候我每天的工作就是从启动VSCode开始装插件、配主题、调快捷键光是Python和C环境来回切换就能折腾一个下午。今年AI编程工具的变化实在太快我的开发流程彻底换了血写代码这件事从“打开编辑器慢慢敲”变成了“给AI描述需求、看它执行、我负责验收”。今天这篇就当是阶段复盘聊聊我是怎么从重度VSCode用户变成AI写代码的“监工”的也聊聊这个过程中踩过的坑和还在坚持的基本功。1. 从“打开VSCode写代码”到“和AI说需求”的这半年1.1 曾经的编辑器信仰为什么VSCode能占领我的桌面先说清楚背景免得被误以为我在劝大家删掉VSCode。我过去是个标准的VSCode用户站队站得死死的。它免费、轻量、生态大打开速度快远程开发配合Remote-SSH也顺滑。为了把一个C/C环境配得明明白白我忍受过tasks.json和launch.json的痛苦也为了Python虚拟环境切换装了一堆插件。那些年折腾VSCode配置的过程本身就是“我还在写代码”的仪式感——仿佛打开编辑器才叫开始工作。但这半年回头一看问题恰恰出在“仪式感”上。当工作里大量时间花在写业务脚本、调接口、改数据、做自动化工具这些事上时VSCode提供的很多能力其实并没有被真正用到。我需要的是快速产出可运行的代码而VSCode的打开、建目录、写代码、调试、跑测试这一整套流程本质上是在给我增加摩擦。尤其是当我发现自己常常打开VSCode却想不起来下一步该改哪个文件时问题的根源就不在编辑器本身了而在“思考代码怎么写”和“把想法落到文件里”之间的那个环节上。AI介入之后这个环节被直接拿掉了。我不再需要先梳理出完整的函数结构再逐个手写而是用自然语言把目标、约束和验收标准告诉AI它会自己读项目结构、生成代码、跑命令、看报错、再修。VSCode的存在感于是迅速下降因为本质上它只是一个“文本容器”而新工作流的入口变成了对话框和命令行。1.2 转折点当AI从“补全代码”进化到“执行任务”真正让我放下VSCode的转折点不是AI代码补全而是AI从“补全”变成“执行”。早期我用GitHub Copilot的时候体验还停留在“智能输入法”阶段。它能根据当前行给我补半个函数但代码的整体结构、文件位置的安排、依赖处理、运行调试全都得我自己来。那时候VSCode还不可替代因为copilot只是我在编辑器里打字时的加速器编辑器依然是我的主阵地。但2024年下半年到今年以Agent形式出现的AI编程工具开始爆发。它们不再满足于“接着我的光标续写”而是能够自己读整个项目的目录结构理解配置文件搜索相关代码片段然后像人一样去创建文件、修改文件、执行命令、读取报错信息甚至跑测试来确认修改有没有生效。这种模式有一个明显特点**你不需要在编辑器里定位文件了你只需要告诉AI“做什么”它自己扑过去完成。**我实测下来的体验是给AI一个明确点的需求它能在几分钟内写好一个可以跑的脚本中间再让它自己修两轮报错基本就收工了。这个过程里我作为人的角色变成了“项目经理验收人”拆需求、卡边界、最后检查代码质量。而不再是“打字员代码结构设计师”。VSCode最核心的“编辑文件”功能因此变得边缘化。我依然会打开它但很多时候只是作为文本查看器看完就关。1.3 我现在的工作流长什么样现在我日常遇到的开发任务大概可以分成三类每一类的用法都不一样。第一类是纯工具类脚本比如批量处理文件、清洗Excel、写爬虫、调API生成报表。这类任务我现在基本不写代码直接在终端里启动AI编程智能体给出需求比如“用Python写一个脚本把D盘photos目录下超过3MB的图片都压缩到2MB以内保持目录结构输出到D盘photos_compressed”。AI会自动生成代码、装依赖、跑一遍如果有路径错误或者编码问题它会自己修复。VSCode在这个过程中完全没有出场。第二类是在现有项目里加功能。比如我们的后端服务要新增一个接口或者前端页面要加一个交互。我会先让AI读取项目相关文件再把需求描述清楚。它改完之后我会上来检查diff看改动是否合理。这个阶段我偶尔会打开VSCode查看具体修改位置但更多时候直接在终端的diff输出里就完成了审查。第三类是复杂问题排查。比如线上出现了诡异的内存泄漏或者某些并发bug在特定条件下才复现。这类任务需要结合日志、监控和代码整体逻辑来推断AI也能帮忙但我的判断主导作用更强。这时候我会打开VSCode但主要不是“写代码”而是“读代码”把关键链路在脑子里梳理清楚再让AI针对具体文件改。这三类任务叠加下来VSCode的打开频率自然就降到了半年没有一次。不是刻意删掉它而是新工作流里没有它发挥核心作用的场景了。2. AI编程工具怎么选从辅助补全到多智能体协作2.1 三类工具的定位差异很多人问我现在到底该用哪个AI编程工具。我先给出我的分类方式这个分类比具体选型更重要。第一类是编辑器原生插件型典型代表是GitHub Copilot、通义灵码、CodeGeeX、Fitten Code。这类工具还是以VSCode为中心本质是给编辑器装上AI大脑帮你补全、解释代码、生成单文件代码。它的优势是上手简单装个插件就能用劣势是Agent能力往往偏弱更多是“车主驾驶辅助系统”而不是“自动驾驶”。如果你还是打算继续每天打开VSCode写代码那这类工具确实能提效但它改变不了“人和编辑器深度绑定”的模式。第二类是命令行Agent型典型代表是Aider、Claude Code这类跑在终端里的智能体。它们直接跳过编辑器这个中间层在命令行里跟AI对话AI自己操作文件系统、执行命令。这个模式的好处是你不需要为了用某个编辑器而改变工作流只需要一个终端。缺点是文本信息的交互密度很高如果你不习惯命令行刚上手会有点蒙。第三类是AI原生IDE型典型代表是Cursor一类把AI能力揉进编辑器体验的产品。它仍然长得像一个编辑器但核心目的在于让AI先写人再改。对于从VSCode迁移过来的人来说这是心理上最平滑的选择界面熟悉但开发模式完全不同。Cursor我最常用的一句话是“按这个逻辑帮我重构一下”它不是补全而是重构整个文件甚至多个关联文件。我的建议是不要迷信某一个工具而是想清楚你现在的工作流更接近哪一类。如果你每天的工作就是打开VSCode写几个函数那插件型就够了如果你像我一样大量时间花在写脚本、做自动化、批量处理上命令行Agent型会带来更彻底的提效如果你已经离不开图形界面的代码审查体验AI原生IDE型可能最适合。2.2 适合自己项目的选型清单这个部分我不能直接替你做决定因为项目类型、团队协作模式、代码敏感程度都会影响选型。但结合半年多来的体验我整理了一份比较实用的小清单。做Python数据处理和自动化脚本我优先用命令行Agent型。因为这类任务不需要复杂的工程结构AI只要拿到明确的输入输出要求就可以生成一个单文件脚本跑完看结果。环境隔离、依赖管理这些事AI也能通过读requirements或pyproject来理解。做Web后端和前后端改动AI原生IDE型体验更好。因为项目文件多关联性强AI需要能跨文件读取理解同时你在审查diff的时候还需要一个可视化工具。Cursor这种产品在这方面做得比较成熟改动的地方会用不同颜色标出来比纯命令行舒服很多。做C、嵌入式这类对编译环境要求高的项目插件型或者命令行Agent型都行但你必须提前把环境和编译命令整理清楚。AI本身不知道你的交叉编译链在哪里它靠的是Makefile、CMakeLists等工程文件来判断。如果工程文件本身就是一团乱麻AI也救不了你。做团队协作、需要严格Code Review的项目无论哪个工具最终审查环节都得靠人。我的做法是让AI生成代码然后自己逐行检查检查通过才合入。千万别让AI直接push代码尤其是涉及线上环境的仓库。2.3 用提示词给AI发“需求文档”AI写代码的效果好不好一半取决于你给它的提示词质量。我踩过很多次坑之后总结出一个相对稳定的模板。想让AI干活别只说“帮我写个图片压缩脚本”这不是需求。一个好需求至少要包含四部分背景上下文、目标、约束条件、验收标准。比如我前面提到的图片批处理需求我会这样描述“项目目录在 /tmp/photo-tool里面有 input/ 和 output/ 两个文件夹。用Python写一个批量压缩图片脚本递归处理 input/ 下的所有jpg/png文件输出到 output/ 并保持原目录层级。单张图片超过2MB的压缩到2MB以下质量参数不低于80。依赖只能用Pillow库。命令行参数设计成 --input、--output、--max-size。写完直接编译并跑一遍用 input/ 里的样例图片验证告诉我输出结果和最终文件大小。”这套提示词里“项目目录”是上下文“写一个批量压缩脚本”是目标“保持层级、参数设计、依赖限制”是约束“跑一遍验证并告诉我结果”是验收标准。AI接收到这些信息才知道往哪个方向使劲。很大一部分人说AI“写不出能用的代码”其实是因为需求里只有一句话。比如“帮我写个大文件去重工具”然后AI就开始自由发挥生成了一堆自定义参数。等你发现不符合预期再回去改来回折腾的时间可能比手写还长。所以我还习惯在第一次对话里就把约束给全宁多勿少。AI面对复杂信息不怕处理不过来怕的是理解不到位而你给的信息越具体理解偏的概率就越低。3. 实操复盘让AI从零开发一个图片批量压缩工具3.1 需求描述与任务拆解用一个完整的实操案例来展示我的AI开发流程。假设我现在需要一个本地批量图片压缩工具要求能递归处理目录下的图片自动识别jpg和png格式超过指定大小就压缩压缩后的图片放到另一个目录并保持原有文件夹结构。这个需求如果搁在以前我的流程是打开VSCode、新建项目、初始化Python虚拟环境、安装Pillow库、写主脚本、考虑用不用argparse、调试路径参数、处理中文文件名问题、再补日志、写README……光这串流程走下来两个小时肯定挡不住。现在的流程是我打开终端启动AI智能体直接扔给它上面那段需求。它会自己分解步骤大概是这样第一读当前目录确认input文件夹和output文件夹是否存在不存在就创建。第二检查Pillow库是否已安装没有就用pip安装。第三写主脚本用os.walk递归遍历input目录对每个文件做大小判断和压缩处理。第四保存压缩结果到output目录的对应子路径。第五跑一遍把运行日志和输出文件列表摊开给我看。AI会自己把这些步骤排好然后逐个执行。我在这个过程中不需要关心中间步骤只需要在最后验收。3.2 生成、运行、修Bug的真实交互过程实际操作里AI不是一次就能成功的。我那次让AI压缩几十张图片它先是生成了一个脚本核心代码大概是这样的from PIL import Image import os import argparse def compress_image(src_path, dst_path, max_size_mb): max_size max_size_mb * 1024 * 1024 file_size os.path.getsize(src_path) img Image.open(src_path) img img.convert(RGB) if img.mode RGBA else img quality_start 95 while file_size max_size and quality_start 50: img.save(dst_path, qualityquality_start, optimizeTrue) file_size os.path.getsize(dst_path) quality_start - 5看起来挺像那么回事但真正跑的时候出了问题。一是input目录下的图片文件名含中文字符保存时编码不一致导致报错二是png图片是RGBA模式转成RGB保存后透明区域变成了黑色三是压缩质量降到50还是超过2MB的脚本会报错退出而不是自动跳过或继续降体积。我把这三个报错截图发给AI它马上针对性地改文件名部分用Path对象处理避免编码问题RGBA图片先粘贴到白色背景上再转RGB透明区域退化成白色而不是黑色压缩后仍然超大的图片输出警告并跳过保证整体流程不中断。这个过程发生得很快来回三四轮对话最终脚本就跑通了。VSCode在这几轮里完全没有出现我不需要把报错信息复制到编辑器里也不需要人工定位第几行错了AI自己读日志找上下文就修掉了。最后我把output目录里的文件尺寸和缩略图检查一遍确认没有明显画质损失就收工了。整个耗时大概二十分钟其中十个点是AI执行五个点是等它思考五个人是我在脑子里过验收清单。如果以我自己VSCode手写的速度来算这至少是半天的工作量。3.3 如果还在用VSCode这个过程会有什么不同为了帮大家理解这个变化我做一次“平行宇宙”式对比。假设我不使用AI回到VSCode写同一个工具时间线大概是打开VSCode新建文件夹初始化venv写代码遇到中文字符路径问题查Stack Overflow修bug遇到RGBA问题再查文档再修继续跑还有依赖环境问题……每次出问题都要在编辑器、浏览器、终端之间来回切换。用AI时这个循环被大大压缩了。你只用在终端里和AI对话它在同一个上下文里同时充当“写代码的人”“看报错的人”“修bug的人”。以前的提问-搜索-理解-修复的链路被整体折叠成一句“帮我看看这个报错”。哪怕有些错误AI不能直接解决它也能缩小排查范围至少告诉你该往哪个文件哪个字段去查。我并不是说VSCode会消失它依然是很好的工具。但这个实操案例很好地解释了为什么“半年没打开”是个自然结果工具链的折叠让编辑器在很多任务里变得不再是必需品。4. 常见问题与避坑指南汇总4.1 上下文窗口不够用改到后面就“失忆”用AI写大项目时最头疼的问题是上下文有限。前几轮对话还能记得整个项目的结构改到第五轮、第六轮它就有可能忘掉之前约好的命名风格或者把已经确认过的函数签名改回去。我有一次处理一个多文件重构AI改到一半突然把一个公共函数删了整个项目当场跑不起来原因就是它上下文窗口里那个函数的信息被更后面的对话挤掉了。遇到这种情况我有几个处理策略。第一个策略是分阶段对话不要把一个大任务一次性压给AI。先把公共部分抽出来让它完成然后固定下来再开一个新会话让它继续做业务层。第二个策略是让AI维护一个“决策日志”在项目根目录创建一份CHANGES.md每改完一个关键决策就让AI把结论记录进去。新会话开始时让它先读这个文件再继续干活。第三个策略是用git做检查点每次AI改完一版代码我就commit一次。这样哪怕它后面“失忆”改坏了也能轻松回滚不用从头再来。尤其要注意当AI连续出现重复错误时别再继续跟它“纠缠”同一段代码了。最好的办法是直接开新会话重新贴出当前文件内容和完整报错很多时候新上下文的推理效果远好于在旧上下文里挣扎。4.2 AI生成的代码不一定对关键要靠验证AI生成代码的准确度在提升但幻觉依然存在。我见过它把不存在的函数名编得有模有样也见过它用了一个已废弃的旧接口却分析得头头是道。所以现在我对AI代码的审查策略很简单能跑就一定要跑能测试就一定要测试。在纯脚本任务里跑一遍看输出是最直接的验证。在项目改造任务里至少要让AI自己先跑单元测试或项目自带的检查命令。我习惯在提示词里要求AI“写完先自测并把测试结果贴出来”这能逼得它认真处理运行环境问题而不是只交付一堆看着能跑的代码。更进一步我会要求AI给自己写的核心逻辑补单元测试。比如写了解析函数就让AI补几个边界用例空输入、异常字符、超长字符串都要覆盖。当AI自己把测试和实现一起给出来时代码质量会高一截因为它必须考虑运行约束而不只是拓印某个模糊的记忆。还有一个细节别让AI伪装会调用你本地没有的库。它经常会自作聪明地引用第三方依赖如果你的项目里没有这个依赖又不希望引入额外重量级库就得明确在约束里写“只用标准库”或“只能用项目现有的依赖”。不写的后果就是AI频繁报“ModuleNotFoundError”来回修消耗大量的时间。4.3 哪些场景我依然会打开VSCode虽然半年没打开但我不会把VSCode删掉。有几个场景我还是需要它的。第一个场景是深度阅读大型项目代码。AI能给出行级建议但它展示代码的时候多数是片段想要全局把握工程脉络还是得有一个好的代码浏览工具。VSCode带了“查找所有引用”“Go to Definition”“Outline”这些基础导航能力我读别人的开源项目时依然要开它。第二个场景是复杂的编辑器内联调试。前端页面看样式、打console、断点看变量这类交互式调试的体验终端Agent还替代不了。我在排查一个复杂的React组件状态问题时最终还是打开VSCode配合React DevTools一起看的。第三个场景是写代码之外的事。比如管理Git暂存区、写commit信息、看冲突diff虽然命令行也能做但VSCode的可视化界面在处理冲突时清晰得多。我偶尔打开VSCode纯粹为了看一个仓库状态图。第四个场景是和同事结对Review。大家开着同一个编辑器指着某一行讨论这种沟通效率远超一人开Agent输出文本。AI再强也没法替代人类面对面的上下文共享。所以准确地说我不是“删了VSCode”而是“日常主体开发不在VSCode里了”。它从高频武器变成了备用工具特定场景下仍然会出场。4.4 常用问题速查表我把这半年积攒的典型问题和处理思路整理成了一张速查表希望对你有点帮助。现象原因解决办法AI改到一半忘掉代码结构上下文窗口溢出定期开新会话用CHANGES.md记录决策重构前先让AI写方案摘要生成的代码有魔法数字可读性差提示词里缺少代码风格约束明确告诉AI定义配置常量、写注释保持函数不超过30行项目依赖被AI乱加没有限制依赖范围在提示词里写明“只能用标准库”或“只能新增X库”AI反复修不好同一个报错上下文里错误信息太多太杂把错误精简到最小复现开新会话重新描述问题在多模块项目里改一个需求经常只改一半AI没有全局扫描范围提示词中明确要求它先找出所有需要修改的文件再动手生成的代码能跑但性能很差AI默认选择易读而非高效实现在验收标准中写明性能要求例如“处理1万条记录耗时小于10秒”代码审查时发现AI引入了不必要的新库自由发挥空间过大要求它先列出计划经你确认后再执行我在这半年里用得最多的一个技巧是“让AI先给我出一份改造方案”而不是直接改代码。比如面对一个老接口重构我会要求它先分析现有调用关系列出改动影响面给出改动优先级。等方案确认没问题后再让它动手。这一步花费的时间很少但能避免大量“AI自作主张”造成的返工。4.5 别丢的基本功AI写代码时代更要懂代码最后想聊一个看似反直觉的点AI写代码时代人的编程基本功反而更重要了。因为AI负责的是“产出代码”而人要负责“判断代码是否值得采用”。不懂底层逻辑的人会把AI生成的结构完美但方向错误的代码直接合入等于在项目里埋雷。我观察到的现象是懂代码的开发者用AI能如虎添翼不写代码的人用AI只能得到一个能跑但无法维护的demo。判断AI生成代码是否适合项目需要理解代码的复杂度、依赖关系、潜在性能瓶颈还要能识别出AI为了应付提示词而做的“表面工程”比如把逻辑强塞进一个函数里或者用一个笨拙的全局变量来实现状态共享。这些缺陷只有在理解代码的人眼里才是缺陷不懂的人看到它跑通就放心了。我的实际建议是不管工具多强每周还是留一点时间不带AI手写一些核心逻辑看看源码保持对算法和数据结构的敏感度。这不是情怀是竞争力。当AI把代码产出变成白菜价时真正稀缺的是“知道什么代码是好代码”的判断力。换言之VSCode半年没打开只是个结果背后真正变化的是工作方式从“手写每一行”变成了“指挥Agent、审查成品、兜底复杂问题”。这个转变里适应得快的人能把时间花在更有价值的设计和决策上适应得慢的人可能会反过来被AI生成的垃圾代码淹没。我个人更倾向于把AI当成一个“话很多、手很快、但偶尔跑偏的实习生”你可以放心把事情交给它但关键路口还是得你自己把关。