半年没打开VSCode：AI让我从写代码变成监工

整理电脑的时候翻到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, quality=quality_start, optimize=True) 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先给我出一份改造方案”，而不是直接改代码。比如面对一个老接口重构，我会要求它先分析现有调用关系，列出改动影响面，给出改动优先级。等方案确认没问题后，再让它动手。这一步花费的时间很少，但能避免大量“AI自作主张”造成的返工。

4.5 别丢的基本功：AI写代码时代更要懂代码

最后想聊一个看似反直觉的点：AI写代码时代，人的编程基本功反而更重要了。因为AI负责的是“产出代码”，而人要负责“判断代码是否值得采用”。不懂底层逻辑的人，会把AI生成的结构完美但方向错误的代码直接合入，等于在项目里埋雷。

我观察到的现象是，懂代码的开发者用AI能如虎添翼，不写代码的人用AI只能得到一个能跑但无法维护的demo。判断AI生成代码是否适合项目，需要理解代码的复杂度、依赖关系、潜在性能瓶颈，还要能识别出AI为了应付提示词而做的“表面工程”，比如把逻辑强塞进一个函数里，或者用一个笨拙的全局变量来实现状态共享。这些缺陷只有在理解代码的人眼里才是缺陷，不懂的人看到它跑通就放心了。

我的实际建议是，不管工具多强，每周还是留一点时间不带AI，手写一些核心逻辑，看看源码，保持对算法和数据结构的敏感度。这不是情怀，是竞争力。当AI把代码产出变成白菜价时，真正稀缺的是“知道什么代码是好代码”的判断力。

换言之，VSCode半年没打开只是个结果，背后真正变化的，是工作方式从“手写每一行”变成了“指挥Agent、审查成品、兜底复杂问题”。这个转变里，适应得快的人，能把时间花在更有价值的设计和决策上；适应得慢的人，可能会反过来被AI生成的垃圾代码淹没。我个人更倾向于把AI当成一个“话很多、手很快、但偶尔跑偏的实习生”，你可以放心把事情交给它，但关键路口还是得你自己把关。