半年不打开VSCode：我用AI Agent重塑编程工作流

上周接了个老项目的需求，给一个跑了多年的定时任务服务加个新的调度策略。放以前，我的流程很固定：打开VSCode，等项目索引转完，Ctrl+Shift+F 全局搜关键词，翻着一堆历史代码慢慢理解脉络，然后新建分支，小心翼翼改代码，最后手动跑一遍测试。但这次不太一样——我打开电脑后直接进终端，在项目根目录敲了一句命令，把需求用三行大白话丢给背后的 AI 编程工具，让它自己先读代码、列改造方案。等我倒了杯水回来看，它已经把改动落到分支里，测试也跑完了，还贴心地列了三个需要人工确认的风险点。

这个场景在一年前我会觉得离谱，但这半年确确实实发生了。我的 VSCode 图标在 Dock 栏上一直待在原来的位置，一直没被点开过。不是刻意不用，是真的没有打开它的动机了。今天把这段时间的完整过程和真实手感写下来，包括我到底在用什么工具、怎么把需求翻译给 AI、踩过哪些坑，以及哪些场景我最后还得老老实实回到编辑器里。

1. 从"打开编辑器"到"下发指令"：我的日常写码流程彻底变了

1.1 一次普通需求的前后对比

先说个具体的例子。之前那个定时任务服务，需求是"按用户等级分配不同的重试次数，超过阈值进死信队列"。以往在 VSCode 里的做法大概是：

1. 全局搜索"retry"或者"死信"，找到处理入口；
2. 顺着调用链往下读，确认配置项从哪里加载；
3. 在脑子里画一张模块依赖图，再决定改动哪个文件；
4. 改完代码继续写单测，生怕影响别的地方；
5. 手动跑 build 和测试，浪费十几分钟等结果。

这套流程静态读码的时间占了 60% 以上，真正敲键盘的时间可能不到十分钟。而我现在用 AI 编程工具之后，同样的需求变成了什么流程？我用对话接口直接说：

"在 xx-service 里给定时任务增加按用户等级配置重试次数的能力，配置放 yaml 里，缺省走原来的默认值，然后补充对应单测。先不要改，先告诉我你打算改哪些文件、风险点在哪。"

它自己去读项目结构、找到相关代码，给出方案。我确认没问题后，说"按这个方案执行"。它就开始改代码、写测试、跑验证。整个过程中我做的唯一一件事是：把脑子里已经想清楚的需求，用准确的话说出来，然后审阅它的方案和 diff。

1.2 为什么是终端而不是传统 IDE

有人会问：Cursor 不也是 IDE 吗？GitHub Copilot 不也装在 VSCode 里吗？为什么我连 VSCode 都不打开了？

我的答案是：当一个工具的核心价值从"帮你补全代码"变成"替你完整执行任务"的时候，编辑器本身就不再是主战场了。

补全代码是低频、低风险操作，它嵌在编辑过程里，IDE 是最合适的载体。但"替你完成任务"，意味着一个 AI agent 要自行完成读代码、搜索、编辑、跑命令、看报错、自我修正这一整套循环。这时候我需要的不是一块写着代码的画布，而是一个方便 AI 自主行动的运行环境——终端恰好就是这样一个环境。它能执行 shell 命令、能跑 git、能看测试输出、能处理文件读写。我只需要看它给我的总结和 diff 就够了。

说白了，以前是我坐在 IDE 里，所有操作都发生在键盘和鼠标之间。现在更像是派了个实习生出去干活，我坐在工位上收结果。VSCode 确实很优秀，但在"AI 替我写代码"这个新的工作流里，它承担的角色变成了一个外围的 diff 查看器，而不再是核心入口。

2. 这半年我实际在用的 AI 编程工具链与选型逻辑

2.1 三条主流路线的真实对比

现在市面上的 AI 编程工具看着很多，本质上是三条路线：

三条路线我都认真用过。说实话，如果只是写写脚本、改改前端页面，Cursor 这种独立 AI 编辑器体验非常好，它的 Tab 补全和对话式改代码比 VSCode + 插件舒服。但到了"一个模块一个模块地重构旧代码、要跨多个文件改逻辑、还得自己跑测试"的时候，IDE 内嵌工具的劣势就出来了——它天然是"人在环上"的模式，每步都要你确认，想象力和执行力其实没完全释放。

命令行 agent 类工具最不一样的地方是：它被赋予的能力边界更大。它可以自己调用编译器、运行测试、修 bug、甚至自己 git commit。它更像是给我打工的小弟，而不是一个建议器。

2.2 我的选型标准：上下文长度、工具调用、价格

有人总问"国内哪个 AI 写代码最强"或者"哪个模型适合写代码"，问到最后其实变成比参数、比刷榜分数。但我这半年的体验是，选 AI 编程工具，真正要看的其实是另外三件事。

第一是上下文窗口的大小和用法。写代码和聊天完全不同。聊天读个几百字的上下文就够了，写代码动辄要把一个项目的目录结构、多个关键文件的完整内容、几十条编译报错全部吞进去。模型上下文太小，它就记不住项目全局，会出现改了 A 文件却不知道 B 文件依赖它的愚蠢错误。

第二是是否具备自主执行能力，也就是 agent 能力。只会生成代码块和会自己跑命令修 bug 的模型，体验差距天壤之别。前者就像只会口述菜谱的厨师，后者是能把菜做出来还自己尝味道调整咸淡的厨师。

第三是实际成本。agent 模式下的 token 消耗比单纯对话快得多。因为每跑一步都要把新的工具返回值、测试输出、diff 内容重新塞回上下文。如果你用 API 按 token 付费，一个中型项目重构跑下来，账单可能够你吃一个月的饭。

2.3 多 AI 协作的真实体验：不要神化，也不要轻视

我现在实际的使用方式，不只是"一个 AI 从头干到尾"。大项目的合理姿势是"多 agent 协作"：一个 agent 专门负责读代码、分析架构，产出理解和方案；另一个 agent 负责写实现代码；还有一个负责跑测试和查错。

听起来高端，实际上操作起来没那么玄乎，就是我开三个终端窗口，每个窗口挂着不同职责的 agent，用文件作为它们之间交换信息的介质。比如分析 agent 把模块梳理结果写进 docs/analysis.md，写代码的 agent 直接读这个文件作为任务输入。这样做的最大好处是上下文干净。写代码的 agent 不会被"读100个文件"的背景信息污染，它只需要聚焦到自己要改的那几块地方。

当然，多 agent 协作的坏处也很明显：协调成本高，时不时会聊岔。如果项目规模没那么大，一个全能 agent + 我的人工审阅，其实已经比什么都够用了。

3. AI 替我写代码的真正核心：提示词工程与规则设定

3.1 把模糊需求翻译成 AI 能执行的任务

刚开始用 AI 写代码的人最容易犯的错，是把需求说得太笼统，比如"帮我优化这个接口性能"。AI 收到这种指令，要么给你一套泛泛而谈的缓存方案，要么一顿大改把测试改崩。

我现在的做法是，不管心里多着急，落地给 AI 的任务说明一定包含四要素：

• 目标：你要让系统达到什么效果，越具体越好；
• 约束：不能动的部分、必须兼容的现状、性能指标底线；
• 交付物：代码、测试、文档，分别放在哪；
• 验收标准：跑什么命令、看什么结果算通过。

拿重试功能举例，我不会说"加个重试配置"，而是会写清楚：重试次数按用户等级从 yaml 读取，key 是 retry-config.level[user-level].maxRetries，等级查不到时用默认值 3；改动范围不允许涉及消息队列的现有消费逻辑；单测覆盖新配置解析和分级重试两条路径；验收跑 gradle test --tests 定时任务模块。

这套描述方式其实就是提示词工程在编程场景里的落地方案。好的提示词不是花哨的技巧，是你把思考过程外化成了模型能遵循的结构化指令。

3.2 让规则深入项目：CLAUDE.md 和 AGENTS.md 的配置经验

光靠每次对话里写清楚还不够，因为 AI 记不住你上次提的要求。我的做法是给项目建一个规则文件，把整个团队的编码规范、项目边界和常见禁忌写进去。

现在主流的命令行动手工具都已经支持在项目根目录放一个类似 CLAUDE.md 或者 AGENTS.md 的规则说明，它的作用相当于给每个新来的 agent 发一份"入职手册"。里面我通常会写三类内容：

第一是项目背景，一句话说清楚这个服务是干什么的，技术栈是什么，目录结构怎么分布。这能让 AI 少很多摸索时间，不用每次一上来就全库扫描猜代码意图。

第二是代码风格约束，比如"I/O 操作统一走 service 层"、"禁止在 controller 里写业务逻辑"、"异常统一用自定义业务异常，不允许裸抛 RuntimeException"。AI 生成的代码如果不加这些约束，非常容易把逻辑堆到一起。

第三是雷区清单，比如"这块订单状态机不要动，牵扯到对账"、"这个旧接口是给外部客户调的，不能改返回结构"。以前这种知识全在老师傅的脑子里，现在把它们写进规则文件，等于把团队经验沉淀成了所有 AI agent 的公共记忆。

3.3 一份真实提示词的横纵对比

给各位看一个我实际用过的正反例子，这是元旦那次排查线上问题的对话备份。

反面写法是："看一下这个接口为什么这么慢，帮忙优化一下。"

正面写法是："接口 /order/list 最近出现 p99 从 800ms 涨到 3s 的情况。怀疑是订单表数据量涨到千万级之后，原来的按 create_time 全表排序有问题。请先分析 service 层的查询链路，确认慢在 SQL 还是慢在序列化，给出优化方案后再动手改。约束：不能引入新的中间件；不能改表结构；改动后要保证分页相关接口的参数兼容。最后输出一份排查记录放 docs/。"

两种写法模型拿到的信息量完全不同。第一种它只能靠猜，输出也是泛泛的"加索引""加缓存"。第二种它知道从哪里查、查到什么程度算结束、边界在哪，产出的结果才是能直接落地的方案。

顺带一提，做专利相关工作的朋友如果在看这篇文章——AI 辅助工具在技术交底书撰写、文献检索、实施例撰写上也能节省不少时间。但提醒一句：AI 生成的专利稿件需要严格校对，尤其是技术术语的一致性和实施例与权利要求书的对应关系，别直接交底。这属于"AI 辅助但不替代"的典型场景。

4. 半年里我踩过的坑，以及 AI 写代码的真实能力边界

4.1 一本正经地改错文件：AI 的自信与误解

有一次我让它改一个配置类的字段命名，它看了半天，把同一个字段在另外两个模块里的引用全改了，结果跑出三十几个编译错误。我打开 diff 一看，它把配置类里"用户名"相关的枚举名理解成了"用户身份"，顺着往下带偏了整个关联变更。

这个问题的根源在于 AI 的语义理解有概率性，它很擅长"看起来有道理"，但不会怀疑自己的理解是否正确。人类程序员改了 A 字段，会顺藤摸瓜确认所有引用点；AI 遇到不确定时会按最可能的语义把整条链路改了，哪怕这个猜测是错的。

从那以后，我给自己定了几条纪律：小改动直接让它做，改动涉及三个文件以上时，必须先出方案再行动；所有涉及"重命名""类型替换"这种跨文件操作，要求 AI 先把搜索到的引用列表贴出来，人扫一眼确认再继续。

4.2 依赖升级是最容易炸的深水区

如果说改错文件是 AI 的"低级错误"，那么依赖升级和自动重构就是 AI 的"高智商事故"，比低级错误更难防。

有次我把一个老库的版本升了，顺手让 AI 把用到的废弃 API 替换成新 API。AI 干得很漂亮，把该替换的地方全都换了，单测过了，编译过了，我天真地以为收工了。结果上线后第二天，有个历史数据清洗任务报了内存溢出，一查才发现新版本的 API 在某种边界输入下会加载全量数据到内存，而旧版本是流式处理的。AI 替换 API 时只看新旧方法的签名对应关系，完全没有理解底层资源模型的差异。

这类问题我复盘下来的结论是：AI 对文档、对常见用法理解极好，但对"某个项目里某个特定版本的行为差异"这种深度隐式知识，它并不真的掌握。涉及升级的改动，我现在的处理方式是把升级影响面分析单独拉出来，要求 AI 先回答"新旧版本在资源使用、异常行为上有哪些不同"，再决定要不要让它动手。

4.3 AI 写不了的东西，以及它的三个致命盲区

半年下来，我总结出 AI 写代码的三个很难靠提示词解决的盲区。

第一个盲区是"信息不存在的决策"。如果需求背后依赖的是线下业务部门的某个口头约定，或者需要靠人来协调拿到的信息，AI 写出来的代码永远是"基于假设的最优解"，它没有能力发现这个假设本身可能是错的。

第二个盲区是灰度发布和兼容性的精细化控制。AI 能写出满足"现在"需求的代码，但很难自动处理好"旧数据、旧调用方、正在运行中的任务"这些现实中存在的过渡状态。比如它不会主动想到"这个字段线上已经有脏数据了，我要在代码里做兼容"，除非你明确告诉它。

第三个盲区是长期维护成本的判断。AI 写代码倾向于局部最优，哪个地方好改就改哪里，很少考虑这个改动是不是给未来埋了债。它不会因为"这个类已经 3000 行了，再往里加方法不合适"而主动提出拆分重构。它只回答你问的问题，不会主动做你没想到但该做的事。

5. 我没删 VSCode：哪些场景最后还是得回到编辑器里

5.1 复杂断点调试：AI 还做不到"盯现场"

AI 写代码再厉害，遇到诡异 bug 的时候还是需要人肉上阵。特别是那种运行时状态完全依赖真实数据的问题——比如某个订单在特定状态下触发了一连串异常，AI 只能读日志、读堆栈，但很难像人一样在关键位置打上断点，观察每一个变量在时序中的实际变化，然后突然喊一句"原来这个值是空"。

这种调试场景我会老老实实打开 VSCode。不是因为它比 AI 聪明，而是因为人类的视觉系统在"看代码执行轨迹"这件事上有无可替代的优势。断点调试的本质是把时间切面展开，让人在空间上理解状态变化，这件事目前没有任何 AI 工具能提供同等的体验。

5.2 代码评审和历史 commit 梳理

AI 能写代码，但代码评审还是得人来。虽然工具也能帮你 review，但我发现 AI 的评审意见通常偏保守、偏规则化，它对"这个实现虽然丑但是很稳"和"这个实现写得漂亮但是有隐患"的区分度很低。真正的 code review 需要业务上下文、历史恩怨、团队技术偏好这些 AI 没有的信息。

另外，翻历史 commit 找"这行代码是谁因为什么理由写的"，这种考古工作我也不会让 AI 去做。不是做不了，而是 git blame 的精神本质是追踪人的决策，这背后往往连着需求变更、事故复盘甚至人事变动。AI 能挖出提交信息，但挖不出当时的语境。这时候 VSCode 的 GitLens 和 blame 界面是比任何 AI 都直观的。

5.3 面试笔试、临时应急、和新人不兼容的场景

还有一些场景你也别指望 AI。

去外面面试的时候，白板题和在线编辑器里手写代码，没有 AI 可以用。这半年 VSCode 几乎没开，但面试前我反而会专门打开它练几天手，把那些常见的算法、系统设计题重新写一遍，防止脑子会了手不会。

还有一类是线上故障极速止血的场景。AI 工具的反应速度虽然快，但再快也要经历"读上下文、分析、生成方案"的过程。真正 P0 故障时，最有把握的还是资深工程师直接杀到出问题的服务里，第一时间看日志、查监控、临时改配置。AI 这时候更像是个话痨助手，你让它闭嘴等着就行。

最后是对不熟悉 AI 工具的团队成员。团队里新来的同学如果一上来就看我用命令行 agent 操作，很容易对整个技术栈产生误解，以为开发就是动动嘴皮子。所以涉及新人培养的项目，我会强制自己打开编辑器，把每一步操作讲清楚。工具再强，人的基本功不能断层。

这半年的体验总结成一句话就是：AI 编程工具把我从"搬砖"里解放了出来，让我有更多精力放在理解业务和做技术决策上；但它没有让我变成一个能偷懒的架构师，反而逼着我学会了更高质量地表达需求、审核结果、识别风险。VSCode 我确实半年没打开了，它躺在 Dock 栏里像个退休的老同事。但我知道，只要哪天项目出了妖孽问题，或者我准备带新人好好讲讲这段代码的前世今生，我还是会点开它。AI 替我写代码，但替不了我理解代码。