有个朋友前几天突然问我你最近怎么不在群里发代码片段了我说代码都不是我手敲的了再发出来丢人。他愣了一下问了一句特别戳心窝的话那你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。工具特点适合场景Claude Code上下文理解强支持Plan/Act模式交互式拆解任务仓库级改造、复杂重构、多文件联动修改Codex CLI轻量GitHub生态融合好启动快快速原型、Demo验证、单一模块修改Aider开源自带git差异管理回滚方便想谨慎控制AI每一步修改的场景还有一个小技巧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 前期准备与任务拆解开始之前我先在笔记本上把需求拆成四块数据源要支持按日频率读取而不是当前的默认分钟线回测引擎需要感知采样频率所有时间戳对齐到日线配置文件中要能指定股票列表和起止日期输出结果里要有日频收益曲线。拆这个步骤很关键。如果直接把原始需求丢给AI很容易出现它自作主张设计接口、改动范围超出预期的情况。需求拆得越细AI的约束越明确你审查的时候也就越有依据。然后我在新分支上启动AI Agent。工程目录是Python项目我给它下了第一道指令claude -p 先阅读仓库结构定位回测框架的入口、数据读取模块和配置加载方式。我要新增按日频率采样的回测任务支持通过config传入股票列表。先给出修改方案包括涉及文件、改动范围、潜在影响。方案确定前不要改任何代码。为什么这样写核心是让它先出方案、再动手。AI读代码速度极快它会先理解现状列出文件清单我确认过这个方向没问题才会让它执行。这一步相当于把AI当顾问用而不是当码农用。3.2 需求下发给AI AgentAI很快返回了方案建议在数据读取模块里新增一个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 常见问题速查表我把这半年遇到最多的五类问题整理成一张表可以直接当参考现象可能原因处理方式AI改了许多不相关的文件没有明确改动范围一开始就指定“只动xxx目录其他文件只读”测试挂了但AI不知情只跑了局部单测没跑完整CI指令中明确要求“运行完整测试命令”代码里出现敏感信息AI从样例或历史提交中复制了硬编码内容diff审查时重点扫字符串常量生产密钥一律用环境变量依赖版本被无端升级AI自动执行了包安装命令限制写黑名单“禁止修改requirements文件”写进约束commit信息又乱又多分了很多次小提交要求AI在完成后执行squash合并保持提交历史干净这五条几乎覆盖了我日常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做出来的东西到底对不对。这半年的经验说到底就是让我搞明白了这件事。
