有个朋友前几天突然问我：你最近怎么不在群里发代码片段了？我说代码都不是我手敲的了，再发出来丢人。他愣了一下，问了一句特别戳心窝的话：那你VSCode是不是半年没打开了？我想了想，发现还真差不多。

“当AI替我写代码，VSCode半年没有打开过”这句话放在一年前，我自己都会当段子看。一个靠写代码吃饭的人，半年不用编辑器，听起来要么是彻底转行，要么是项目根本没人维护。但等你真正把AI Agent引入日常工作流之后，会发现这里的逻辑其实非常朴素：人不再负责把代码敲出来，而是负责告诉AI做什么、检查AI做成了什么。这两种工作模式，对我这类常年泡在代码堆里的人，影响几乎是颠覆性的。

这篇文章拖了很久才写，不是不敢写，而是想先把这套流程用到足够成熟，再出来分享。下面会从工作流的转变、我用到的工具组合、一次完整项目实操、踩坑记录，以及“什么时候还是得回头打开VSCode”这几个角度，把半年的真实经验完整拆给你看。不适合所有人盲抄，但它确实值得每个写代码的人认真评估一遍。

1. AI把我从“编辑代码”推到“检查代码”

先说一个反直觉的点：VSCode让我觉得回不去的那些功能——智能补全、LSP跳转、重构、插件生态、小巧思的快捷键——在AI接管大量编码工作之后，反而变得不那么关键了。原因不是VSCode不好，而是你在一个流程里的角色变了。

以前写代码是“人在IDE里完成创作”，编辑器是核心战场。你需要它给你补全、提示、检查语法，因为你是一个字符一个字符在写。现在换成AI Agent替你“写”，它的眼睛是整个仓库，不是当前打开的那个文件。它可以直接grep整个项目，读几千个文件，按你的指令修改一处逻辑，运行测试，然后把修改结果摊开给你看。这个过程中，你本人可能只是坐在终端前面，用cat或者less查看它改过的文件，甚至直接在GitHub网页上看diff。

一旦角色从“手写者”变成“审核者”，IDE最重要的一层价值就消失了。你不再需要每天开8小时编辑器，也不需要保存一堆工作区、记住各种插件快捷键。你真正要做的是把需求讲清楚，然后检查AI交上来的东西是否符合预期。从这个角度看，VSCode半年没打开，不是懒，是工作重心迁移的自然结果。

不过我要先说清楚，我绝不是劝人卸载VSCode。它现在成了我的“审计工具”，而不是“生产工具”。这个定位转变非常重要，带着这个心态去用AI写代码，才不会在碰到复杂调试时手忙脚乱。

1.1 为什么VSCode不再是日常主战场

VSCode这类IDE的核心价值，在于“人工编写体验”。你打开一个大项目，靠它读代码、补全、断点调试、跳转，甚至靠插件模拟远程环境。这些都是为了提高“人写代码”的效率而生。可当AI能直接用命令行完成文件读写、批量替换、跨文件重构时，很多IDE引以为傲的能力就变得冗余。

我举一个特别典型的例子：以前改一个接口签名，要在VSCode里全局搜索所有调用点，然后一个一个跳过去改。跳转精准、错误提示即时，但也非常耗费注意力。现在AI Agent会自己用grep找到所有调用点，统一修改，再跑一遍测试。整个过程中，你根本不需要打开编辑器。VSCode的“查找引用”做得再好，也只是让一个人干得更快；而AI是直接把人从这个流程里抽出来。

还有一点，IDE窗口本身是有存在感的。它打开着一堆标签页，哪个文件改了、哪个文件没保存，都有视觉压力。当你不再把编辑器挂在最前面时，工作心态会轻松很多。我现在的日常画面基本是：终端窗口里一个AI Agent在跑动，另一个窗口开着CI页面，偶尔切到浏览器看GitHub的PR。VSCode？经常一周都不打开一次，直到需要做深度调试才见一面。

1.2 这套工作流真正解决了什么瓶颈

有人可能会觉得，不打开VSCode只是形式，核心问题还是“AI写的代码到底能不能用”。先解决效率瓶颈：以前写功能性代码，最大的开销是“从需求到语法落地”的阶段。写一个量化回测脚本，可能要花半天时间处理pandas的列名、时间索引、数据清洗、指标计算，真正费脑子的业务逻辑只有那么一小块。现在AI把样板代码、边界处理、参数配置全部生成出来，我只需要看核心逻辑对不对。这让我把精力从“怎么把这行pandas写对”挪到“这个策略到底有没有alpha”上。

很多人没意识到，写代码真正的瓶颈从来不是打字速度，而是对需求的理解和验证标准。AI把打字这个环节压缩到近乎为零之后，你必须被迫提升自己的能力：你能不能把需求表达清楚？你知不知道“跑通了”和“真正符合业务要求”的区别？这套工作流的本质，是把我从“代码体力劳动者”推向“代码审核者与需求翻译官”。

2. 半年不开VSCode，我都用什么东西写代码

这套流程能成立，靠的当然不是一句话，而是一整套工具组合。我把自己半年来高频使用的工具盘一下，你要是刚开始尝试，直接照搬这个组合是够用的。

2.1 CLI型AI Agent是核心

我最依赖的不是某个IDE插件，而是跑在终端里的CLI型AI Agent。比如Claude Code、Codex CLI这类。它们的特点是直接在当前项目目录下运行，能读取整个仓库、执行shell命令、编辑文件、运行测试。你问它一句“这个bug在哪里”，它能自己翻代码定位；你说“帮我把这个功能加上”，它能在你眼皮底下完成整个改动。这类工具最大的优点是，你连编辑器都不用打开，在任意一个终端里，它就是一个能主动做事的同事。

我目前使用比较多的是Claude Code，原因是对复杂仓库的理解和交互式任务拆解做得比较成熟；偶尔也会用Codex CLI处理一些偏轻量、快速验证的任务。Aider这类开源方案也推荐新手尝试，它的特点是自带git差异管理，每一次修改都会生成独立commit，回滚特别方便。具体选型因人而异，但你一定要挑一个“能在命令行里运行、能自己执行命令、能跨文件修改”的Agent，而不是只能在聊天窗口里给代码建议的那种，后者充其量是个高级问答工具，做不到让你摆脱IDE。

还有一个小技巧：CLI型AI Agent一般都支持把整个目录作为上下文“喂”给它。开始一个任务前，我会先输入“请先阅读项目README和src目录，了解项目用途”，而不是直接让它改代码。这一步会让后续所有输出质量高很多，也是新手最容易忽略的。

2.2 我用到的其他工具组合

• 浏览器看代码：GitHub或GitLab的网页端看PR、看diff，比在本地开IDE更清爽。盯AI提交的改动、检查是否有敏感信息，一套流程都在网页里完成。
• 命令行三件套：bat替代cat看代码高亮，rg替代grep实现全局搜索，fzf做快速文件跳转。没有这些，在终端里查代码会很痛苦，有了它们，体验不比IDE差。
• 测试与CI兜底：本地跑pytest或npm test，远程用GitHub Actions跑自动检查。AI改完代码后，我不需要肉眼逐行审完所有东西，先把测试全跑一遍，再去看失败的Case，效率非常高。
• 轻量编辑器：偶尔需要手动改几行配置，我会随手用系统自带的nano或者helix打开。注意，是“轻量编辑”，不是“大型开发”。

这里多说一句，很多人问为什么不直接用Cursor这类“AI原生IDE”。不是我排斥Cursor，而是我的目标已经变成了“不打开IDE”，再强的AI IDE，本质上还是要求你坐在编辑器里。如果你愿意打开Cursor，它能给你很好的体验；但我个人享受的更像是“命令行指挥AI干活的自由感”。

3. 一次完整的AI代写代码实操

说一堆工具，不如走一遍真实流程。我拿最近给某个Python量化回测框架增加“按日频率采样”功能这件事当例子，整个过程没有打开过一次VSCode。

3.1 前期准备与任务拆解

开始之前，我先在笔记本上把需求拆成四块：

1. 数据源要支持按日频率读取，而不是当前的默认分钟线；
2. 回测引擎需要感知采样频率，所有时间戳对齐到日线；
3. 配置文件中要能指定股票列表和起止日期；
4. 输出结果里要有日频收益曲线。

拆这个步骤很关键。如果直接把原始需求丢给AI，很容易出现它自作主张设计接口、改动范围超出预期的情况。需求拆得越细，AI的约束越明确，你审查的时候也就越有依据。

然后我在新分支上启动AI Agent。工程目录是Python项目，我给它下了第一道指令：

claude -p "先阅读仓库结构，定位回测框架的入口、数据读取模块和配置加载方式。我要新增按日频率采样的回测任务，支持通过config传入股票列表。先给出修改方案，包括涉及文件、改动范围、潜在影响。方案确定前不要改任何代码。"

为什么这样写？核心是让它先出方案、再动手。AI读代码速度极快，它会先理解现状，列出文件清单，我确认过这个方向没问题，才会让它执行。这一步相当于把AI当顾问用，而不是当码农用。

3.2 需求下发给AI Agent

AI很快返回了方案：建议在数据读取模块里新增一个freq参数；在回测入口新增一个加载日线数据的路径；在配置示例里补充股票列表；同时会写两个单元测试覆盖新逻辑。我同意了执行计划。

然后观察它的行为：AI先创建了一个feature分支，改了datafeed.py、engine.py，新增了config_daily.yaml，写了tests/test_daily_sampling.py，然后自动执行了pytest。整个过程中我基本是在看它跑，偶尔在终端里用git diff main --stat扫一眼改了哪些文件。

等它跑完，我再做人工审查。重点盯三件事：第一，数据时间戳的时区处理是否一致；第二，空股票列表或无效日期有没有边界处理；第三，新加的配置项有没有影响原有分钟级回测逻辑。这一步必须自己做，AI不会主动站在“老用户的角度”考虑兼容性，但它会把潜在影响列出来，你只需要基于这份清单做判断。

3.3 审查合并与上线

确认没问题后，AI把修改提交到了feature分支，生成了比较规范的commit message。我又在GitHub网页上把PR打开，看了看整体diff，再跑一次完整CI。全部通过，合并，收工。

整个流程里，我没有写过一行业务代码，甚至连本地编辑器都不用打开。但注意，这不等于“甩手不管”。我的核心工作变成了：拆分需求、审查方案、检查diff、跑测试定乾坤。这四个环节AI替代不了，或者说现阶段还不能完全替代。

补充一个这个案例里很有代表性的细节：AI第一次跑单元测试的时候，有一个关于“跨时区日期对齐”的用例挂了，它没等我提醒，自己就回去修了时间戳处理逻辑，重新跑通了。这说明现在的AI Agent已经具备“发现问题—定位问题—修复问题”的闭环能力。你要做的就是给它提供一个安全的跑动环境，别在生产主分支上让它乱来。

4. 踩过坑之后，我总结的避坑指南

这半年也不是一帆风顺。AI替我写代码的时候，确实翻过几次车。我把踩过的坑和对应的处理办法整理出来，希望能帮你绕开。

4.1 AI幻觉与真假代码识别

AI最常见的毛病，是“一本正经地写出不存在的API”。比如有一次它在一个数据脚本里用了一个看起来很合理的pandas方法，但实际上那个方法在较新版本中早就被移除了，跑起来直接报AttributeError。它不是不知道版本差异，而是它基于训练数据里的旧写法制出了这段代码，又没去核实当前环境的版本。

我的处理办法是：先让AI自己grep确认某个符号是否存在于依赖库中。比如要求它“在写DataFrame处理逻辑前，用python -c检查当前环境下pandas的版本，再决定使用哪些API”。这类指令能让幻觉概率大幅下降。对于AI生成代码里出现的函数名，我都会快速用命令行搜索一下，确认不是它瞎编出来的。

另一个有效手段是：让AI在回答里标注“依据”。你要求它改动一处公共函数时，必须先在答案里给出这个函数定义来自哪个文件、哪一行。如果引用不对，那就是幻觉，直接打回重写。这个过程看起来麻烦，但能养成AI更谨慎的输出习惯。

4.2 上下文管理与执行权限

AI Agent的上下文窗口是有限的。你可能跟它聊了很长一段任务后，它会忘记最早的项目约束。我一开始也犯过“一个会话里连续丢四五个任务”的毛病，到后面它越改越偏，最后把无关模块都动了一遍。现在我的原则是：一个任务一个会话，任务完成立刻结束，新任务重新启动Agent，只把必要的背景信息重新贴给它。

执行权限也非常容易被忽略。AI能执行shell命令，就意味着它能删文件、改依赖、推代码。如果权限完全放开，它可能会在某个测试通过后顺手帮你装一堆推荐包，或者因为误判而修改了不该动的配置。我现在通过两条手段控制风险：

• 给AI设置命令白名单，限制它只能执行git、python、pytest、npm等必要命令；
• 所有重要改动必须在feature分支进行，禁止直接操作主分支。

我以前就遇到过AI在一次“优化依赖”的任务里，悄悄升级了某个核心库的版本，导致另一个模块跑出了完全不同的结果。之后我加了一条硬性要求：修改任何依赖文件之前，必须给出明确理由并单独确认。

4.3 常见问题速查表

我把这半年遇到最多的五类问题整理成一张表，可以直接当参考：

这五条几乎覆盖了我日常90%的问题。遇到的时候不用慌，先定位是上下文问题还是权限问题，再对应执行上面的策略就好。

5. 什么时候我还会打开VSCode

必须说一句大实话：半年没打开，不是永远不打开。有些场景下，编辑器依然是最好用的工具，强行用AI指挥就是给自己挖坑。

5.1 必须回到编辑器的几种场景

第一是嵌入式开发。像STM32这类工程，往往要连仿真器、看寄存器、烧录固件，AI能帮你写初始化代码，但debug时观察外设寄存器状态、看JTAG/SWD调试输出，传统IDE的调试视图还是比命令行组合直观得多。不是不能用命令行，是没必要较劲。

第二是前端视觉调优。改CSS样式、React组件的渲染效果，最好一边改一边看页面变化。VSCode配合Live Server或者浏览器DevTools联动，能实时看到改动效果，AI在命令行里没法给你提供那种“所见即所得”。虽然AI能准确描述选择器和布局，但人眼确认始终最可靠。

第三是深层性能分析和大型重构。火焰图、调用链、运行时内存快照，这些通常都需要IDE的图形化工具辅助分析。批量重命名跨文件变量时，VSCode的编辑器重构能力依然比AI稳定，它能做到全仓库同步并保留格式。虽然AI也能做，但在这类细节上它偶尔会漏。

除此以外，老项目维护也是高发场景。一些项目用了大量历史遗留的关键字、魔法数字和特殊注释，AI读得懂大方向，却常常误解细节。这种项目里，我宁可打开编辑器配合AI看代码，而不是完全交给AI折腾。

5.2 给新手的一点建议

我不太建议刚学编程的人一上来就完全依赖AI Agent。因为这套工作流的前提是你已经具备“看懂代码和验证结果”的能力。新手如果直接让AI写代码，很容易遇到幻觉却无法识别，遇到报错也不知道该往哪个方向查，最后变成AI说什么都信，出了问题完全抓瞎。

更合理的学习路径是：先手动写够一定量的代码，理解变量、条件、循环、函数、类这些基础概念。至少自己独立写过几百行能跑的程序，再开始引入AI帮你扩展。这个顺序能让你在AI时代具备基本判断力。我知道这么说有点老派，但这半年我见过太多“AI写了半天代码，最后连哪里有问题都找不到”的新手了。

我自己现在打开VSCode的频率大概是两周一次，基本是为了嵌入式工程加点调试变量，或者去看某个奇怪的渲染问题。更多的时候，我坐在终端前，让AI替我跑完一轮测试，然后把结果甩到群里。这不是偷懒，这是把精力挪到更靠近业务逻辑的地方。未来的程序员价值，大概率不取决于打字多熟练，而取决于你能不能把模糊需求翻译成可执行任务，并且有能力验证AI做出来的东西到底对不对。这半年的经验，说到底就是让我搞明白了这件事。