上半年翻开发开记录时我自己都愣了一会儿最后一次主动打开 VSCode已经是五个多月前的事了。不是换了别的编辑器也不是转行了而是过去半年里绝大多数“写代码”的动作都被 AI 拿走了。最初我对 AI 写代码是很抗拒的总觉得它只能补个片段、凑个函数离真正能干活还差得远。但等到我认真把 AI Agent 当作主力开发搭档之后传统 IDE 的使用频率突然就降了下来。这篇东西就是想聊聊这段时间我的工作流到底发生了什么变化AI 写代码解决了什么问题哪些坑我替你踩过了以及为什么我说“半年没打开 VSCode”并不意味着编辑器没有用了。1. 为什么我半年没打开 VSCode工作流的迁移真相1.1 我不是抛弃了编辑器而是换了个“驾驶舱”很多朋友看到标题第一反应是“你直接躺平了吗”。其实不是。我依然每天看代码、调问题、改逻辑只是大部分时间不再是“我手动敲代码”而是“我告诉 AI 做什么然后审它做出来的结果”。这种感觉很像从手动挡换成了带辅助驾驶的车油门刹车还在你脚下但巡航、变道、跟车这些重复操作系统帮你接过去了。你需要做的是盯着路况、判断什么时候接管。我把代码编辑的重心从“一个字一个字敲”变成了“一段话一段话描述需求”VSCode 那个界面自然就很少打开了。严格来说我并没有删掉 VSCode它还在硬盘里偶尔还会用。但半年下来我的常用开发环境变成了“终端 AI 客户端 浏览器”绝大多数操作在命令行里用 AI Agent 完成。VSCode 的启动频率从每天十几次掉到了一个月两三次。1.2 触发我迁移的几个真实原因我认真复盘过自己是从什么时候开始不用 VSCode 的。不是因为哪家 AI 工具宣传得猛而是几个特别实际的问题让我不得不变。第一个原因是重复劳动太多了。我大部分工作不是发明新算法而是写接口、配参数、调格式、补单元测试。这类活儿用传统的“人肉敲代码”方式效率极低尤其是一个接口从 Controller 写到 Service 再写到 DAO每个文件结构都差不多差别就是字段名和业务逻辑。AI 对这种模式化任务极其擅长我只要把表结构或者需求文档丢给它它能把整套模板代码一次铺开。第二个原因是 VSCode 的维护成本让我心累。你有过“配置环境配了一下午代码一行没写”的经历吗我之前就经常这样。比如 VSCode 写 C 没有代码提示十有八九是没装 C/C 扩展或者 includePath 没配Python 环境换个解释器插件就闹情绪再来个 STM32 开发环境光调试器配置就能让人崩溃。这些事在传统的 IDE 里都是隐性时间成本而 AI 恰恰能帮你快速定位配置问题、生成配置文件甚至直接在命令里把所有步骤跑完。第三个原因是我接手老项目时被坑了一次。有次接手一个年代久远的 C 仓库VSCode 打开之后全是红波浪线代码跳转完全失效。我折腾了半天最后把整个构建流程和头文件关系交给 AI 梳理它给我整理出清晰的依赖关系还顺带生成了正确的c_cpp_properties.json。那一刻我很清楚地意识到原来我花时间解决的问题根本不是业务问题而是工具链问题。把这个环节交给 AI省下来的精力可以用在真正重要的东西上。2. AI 写代码的核心能力拆解从补全到 Agent2.1 三层能力行级补全、对话生成、自主执行现在很多人一说“AI 写代码”想到的还是最早那种“光标后面跟着灰色提示代码”的补全工具。那只是第一层能力而且说实话它并没有从根本上改变开发方式。真正改变工作方式的是后面两层。我这个分层是自己实际用了半年之后总结出来的第一层行级补全。你在 VSCode 里装个 AI 插件它根据你当前的上下文预测下一段代码。这个能力适合手写代码时的加速但本质上还是“人在主导AI 帮忙接话”。第二层对话生成。你可以直接描述需求AI 返回一段完整代码或一个方案。它解决了“从需求到代码”的翻译问题但还是需要你手动复制、粘贴、保存。第三层Agent 自主执行。这个差别很大。AI 不仅生成代码还能自己改文件、跑构建命令、执行测试失败了它会读报错、定位问题、继续修复直到任务完成。人只需要在关键节点做决策和验收。能力层谁在主导适合任务局限性行级补全人已知逻辑下的快速输入无法理解项目整体目标对话生成人单个函数、模块需要手动落地到文件Agent 自主执行人设定目标AI 执行跨文件改动、跑测试、修 bug任务定义不清时容易跑偏2.2 为什么 Agent 比补全插件更改变工作方式补全插件提升的是“打字速度”Agent 提升的是“完成任务的速度”。举个例子让我写一个“用户注册接口”补全插件能帮我写个函数签名、补几个参数但后续的控制器逻辑、参数校验、数据库操作、异常处理、单元测试全都得我自己一步步来。Agent 不是这样。我只要把需求说清楚它会自己找项目里现有的风格新建对应的文件把注册逻辑补全还会跑一遍现有测试甚至主动发现“这个接口没有防重复提交”然后提醒我。这种体验的改变是巨大的我从“执行者”变成了“验收员”。但这里必须泼一盆冷水。Agent 只适合定义清楚的任务任务边界没画好就会翻车。你把一个大仓库甩给它说“帮我优化一下”它可能热情地改了几十个文件最后把你代码风格全带偏了。所以后面我总结了一套提示词和规则设置的方法把 Agent 的能力关在笼子里用。3. 我的 AI 编程工作流与提示词工程实战3.1 给 AI 设定规则一个可复用的 System Prompt 模板很多人用 AI 写代码上来就一句“帮我写个登录模块”然后抱怨结果不好。问题不在于 AI 能力不够而在于你给的上下文太少、约束太松。我自己现在不管用哪个工具第一件事都是先给它立规矩。下面这个模板我几乎每周都会用到你可以直接抄走你是一名资深后端工程师负责维护我这个 Python 代码仓库。 工作约束 1. 优先使用项目已有依赖不要随意引入新库如必须新增请先说明理由。 2. 代码风格与项目现有模块保持一致不要擅自重构无关代码。 3. 改动前先列出你计划修改的文件清单和实现思路等我确认后再动手。 4. 每完成一个任务必须运行测试命令并贴出结果。 5. 注释使用中文提交信息遵循 Conventional Commits 格式。这个模板看起来简单但它把角色、边界、流程、验收标准全都定死了。AI 就不再是“即兴发挥”而是按你的规则执行。有人觉得“AI 写代码不需要提示词工程”那是没吃过“它给你改了一大片无关代码”的亏。3.2 提示词工程的四个关键技巧我踩了无数次坑之后总结出四个最管用的技巧分享给想用 AI 写代码的人。第一任务拆分一次只做一件事。不要试图让 AI 一口气完成一个大型功能。把需求拆成“建表脚本”“写数据模型”“写查询接口”“写单元测试”四步每一步单独扔给它成功率远高于一次塞一个大需求。第二给足上下文。AI 不知道你的项目结构你不能只给一句话。要告诉它文件路径、相关函数名、报错信息甚至贴一段现有代码。上下文越充分生成结果越贴合实际。第三先要方案再要代码。我现在的习惯是让 AI 先给我列实现思路关键取舍讲清楚我确认没问题之后才让它写具体代码。这样能提前把方向跑偏的问题扼杀在摇篮里。第四明确验收标准。告诉它“写完之后跑一下测试保证全通过”比说“写一个功能”有用得多。AI 会自己循环尝试直到测试通过为止。我最开始用 AI 写代码的时候提示词就是一句话“帮我写个用户列表接口”。结果它给了我一个独立脚本里面用的是requests直接请求第三方 API完全没接我项目的数据库。第二次我贴上了路由文件、模型文件和相关依赖它生成的代码基本能直接用。差别就这么大。3.3 多 AI 协作与工具选型还有一个很多人没试过的玩法让多个 AI 互相配合。我现在写一个稍微复杂的模块时会用一个模型负责生成初版代码另一个模型负责代码审查专门挑毛病。为什么要这么干因为不同模型训练数据、优化方向不一样。有的生成能力强但有时候过于自信会“一本正经地胡说八道”有的思考链路长适合做 review 和问题定位。把这两类组合起来质量会明显比单模型高。我常跟朋友说写代码的人写错审代码的人抓住这个模式跟人类团队协作其实是一个道理。至于工具选型我不太愿意做“谁最强”的绝对排名因为不同场景差异太大。但我可以把市面上主流方案按场景分一下类方便你对号入座工具类型代表例子适合谁我的评价IDE 内嵌 AI 插件VSCode 内置 AI、Cursor还习惯图形界面写代码的人起步平滑但 Agent 能力相对克制终端型 AgentClaude Code、Codex 一类已经习惯命令行工作流的人系统集成能力强适合跨文件改动国产 AI IDE各个大厂的 AI 编程助手需要中文交互和国内服务的人上手快对国内开源生态更熟多模型协作自己拼让多个模型各司其职需要高质量稳定输出的人维护成本高但可控性最强我自己的选择是“终端型 Agent 主力 另一个模型做 review”。这套组合跑了半年稳定性够用。但我不建议新手一上来就跟我一样可以从 IDE 内嵌 AI 插件开始跑通再进阶。4. 实操从 VSCode 迁移到 AI 工作流的完整步骤4.1 第一步先盘一下你的仓库如果你也想试着把工作流迁到 AI 上不要急着让 AI 干活先整理仓库。AI 对你的项目一无所知你需要给它一张“地图”。我现在的每个项目里都会放一个AGENTS.md文件里面写清楚项目是干什么的、目录结构是什么、入口文件在哪、构建命令和测试命令是什么、代码风格有什么要求。这个文件不写给人类同事看就写给 AI 看但它带来的收益远超你想象。比如我的一个 Python 服务项目AGENTS.md开头是这样的# AGENTS.md 这是一个 FastAPI 服务提供用户和订单两类接口。 - 代码入口app/main.py - 路由文件app/routes/ 按资源拆分 - 数据库SQLAlchemy 2.x PostgreSQL - 测试命令pytest tests/ -v - 代码风格black isort保持函数纯逻辑不写冗余注释有了这个文件AI 每次动手前都会先读它相当于你给新成员发了一本入职手册。之后让它写代码出错的概率会低非常多。4.2 第二步让 AI 做一次“小范围重构”接下来用一个真实小案例演示完整流程。我最近把一个老的配置读取模块重构过原本是一堆手写的if/else分支读取不同配置项既不安全也不好扩展。我的提示词大概是这样的这个项目里有app/config.py现在读取配置的方式是裸露的字典加 if/else。请重构为 dataclass 加类型校验保持对外函数名不变最后跑一下pytest tests/test_config.py -v确保所有测试通过。改动文件范围限定在app/config.py和对应测试文件不要碰其他模块。AI 返回了一个方案用dataclass定义AppConfig写load_from_dict做类型转换和缺失值检查用functools.lru_cache做全局缓存。我觉得方向没问题让它执行。执行过程中它自己发现有个测试断言的是老结构顺手把测试改成了新接口跑了两轮全绿。这件事放在以前我自己写至少得小半天。AI 大概五六分钟就完成了而且它还主动补了缺失字段的默认值考虑得比我还周全。这就是一个很典型的“AI 写代码”的正确姿势小范围、有边界、有验收标准。4.3 第三步从 AI 输出到代码合入的检查清单AI 把代码写完了不代表可以闭眼合入。我给自己定了一个检查清单每次 AI 跑完任务都要过一遍改动范围是否符合预期我给了“只改这两个文件”的限制AI 如果私自改了第三个文件立刻回退重来。依赖是否新增了如果版本文件里多了几个之前没有的库必须让 AI 解释理由。测试是不是真测试有些 AI 生成的测试只有“跑了一遍没报错”断言写得稀烂等于没测。我会扫一眼断言是否覆盖核心逻辑。提交信息是不是清晰AI 生成的提交信息经常是“refactor config module”太笼统我会让它按规范重写写清楚改动原因。这套清单我打印在自己的笔记里实战中救了我很多次。尤其是“测试是不是真测试”这一条AI 特别容易“自说自话”跑通就认为自己任务完成了实际上只是把测试写得很弱。你在传统 VSCode 里清理删除分支要右键、找分支、点删除有时候分支多了还容易误删。现在我在命令行里直接跟 Agent 说“把已经合并到主分支的本地分支都清理掉”它会把git branch --merged列出来逐个确认再删。这就是工作流迁移的质感原来图形界面里反复点的操作现在一句话就解决了。4.4 第四步训练自己“看得懂 AI 代码”的基本功说了这么多 AI 的好处有一个底线我一直没放松基础能力不能丢。AI 生成代码的速度越快代码审阅的能力就越值钱。你可以不会手写每一行但你得能看懂它为什么这么写知道哪里可能藏雷。我见过不少新手把 AI 当万能 API不管报什么错都把锅甩给 AI结果项目越改越乱。真正有效的姿势是AI 负责产出你负责把关两头都不能少。我自己的做法是每周还是会花一点时间刷算法题、读开源源码维持对代码的敏感度。半年下来我的“手写代码”量少了但“读代码”的能力加强了综合产出反而更高。5. 常见问题与排查技巧实录5.1 AI 生成代码的翻车现场速查表我用 AI 写代码半年翻车次数两只手数不过来。下面是我整理的高频问题对照表你遇到了可以直接照着排查现象可能原因排查思路AI 引用了不存在的库训练数据里有这个库名但作者没更新或已废弃引入前先检查依赖源确认维护状态改动“超出合同范围”任务边界没定义清楚提示词里加“只改我指定的文件不要碰其他模块”测试全部通过但没断言AI 为了“跑通”写了空测试查看测试断言确保覆盖核心行为生成死循环或性能爆炸复杂递归/循环没有边界条件要求 AI 先解释算法复杂度再生成代码注释和文档全是英文你没指定语言在 system prompt 里写明“注释使用中文”最坑的是第一种。有次它给我生成一个用retry库重试 HTTP 请求的代码我一看版本文件里多了一个我没听过的库去查才发现这个库好几年前就不再维护了。从那以后我加了一条规则要引入新依赖必须先把理由说清楚而且我会让另一个模型同步审查一遍。5.2 VSCode 那些高频问题我替你重查了一遍你可能会好奇既然我半年没打开 VSCode为什么对它还这么熟因为之前用得太多了那些搜索记录到现在还在热搜里挂着。趁这次机会我把几个高频问题顺带整理一下你如果还在用 VSCode直接抄答案。VSCode 写 C 没有代码提示多半是没装 C/C 扩展或者编译器路径没识别到。最简单的方法是用扩展生成c_cpp_properties.json把includePath指到正确的头文件目录。VSCode 配置 Python 环境先确认你在命令面板里选了正确的解释器再确认pylint或pyright插件启用。环境变量别乱配用.env文件管理最省心。VSCode 汉化装上“中文简体语言包”插件然后在命令面板里搜 “Configure Display Language”选zh-cn重启即可。没有编辑过的文件会自动关闭这个是我以前最烦的默认行为。在设置里搜workbench.editor.closeEmptyGroups关掉它就能避免那些“空标签页自动消失”的问题。黄色高亮占好几行一般是 lint 或类型检查的波浪线它把整行都标黄了看起来很脏。你可以调整问题面板或者安装类似 Error Lens 的插件把错误信息压缩到行尾显示代码区会干净很多。这些配置不是说我不会而是这套东西的维护成本太高了。每次换机器、换项目、换编译器都要重新折腾一遍。现在我把这些精力省下来留给真正需要思考的业务逻辑。5.3 我踩过的坑清单除了上面那张表还有几个教训值得单独拿出来说因为它们不是“技术问题”而是“使用姿势问题”。第一个教训不要把生产分支直接交给 AI 改。有次我图省事让 Agent 直接在main分支上重构一个支付状态机结果它中途改崩了还提交了好几个中间状态。从那以后所有 AI 相关改动都先切 feature 分支跑完全部测试再合入绝不偷懒。第二个教训别让 AI 在“没有规则”的状态下自由发挥。一开始我没写AGENTS.mdAI 改代码时用了完全不同的命名风格把驼峰改成下划线我 review 的时候差点没认出来。后来我花了一个下午把所有项目的AGENTS.md补齐世界清净了。第三个教训AI 不是搜索引擎。有些问题它回答得非常自信但答案可能是错的。尤其是“这个 API 的某个参数怎么传”这种时效性很强的问题还是要去查官方文档。AI 写业务代码我很放心但涉及底层 API 的最新签名我习惯让它把官方文档链接一起贴出来我再核实。6. 什么场景我会重新打开 VSCode6.1 嵌入式开发与底层调试我必须承认AI 写代码并不是万能的至少在我最熟悉的嵌入式领域VSCode 依然有一席之地。比如 STM32 开发环境涉及交叉编译链、J-Link 调试、寄存器查看、内存窗口这些传统 IDE 的能力Agent 很难完全替代。不是不能生成代码而是调试过程的“临场感”很重要。当程序跑飞了你要看寄存器、看调用栈、看外设状态这些操作在编辑器里做比在命令行里做高效得多。我上个月就重新打开过 VSCode配了一次 STM32 的调试环境用 J-Link 单步跟踪一个 RTC 初始化问题。这种场景我不会强行让 AI 来扛。6.2 深度 review大段 diff 还是需要 IDE 视图AI 改完代码之后我总是要自己在编辑器里看一遍最终的 diff。命令行里看 diff 虽然也可以但复杂改动时图形化的对比视图明显更清楚能快速看到哪一行被改了、哪里的缩进乱了、哪个函数被挪走了。所以我的工作流不是“永远不开 VSCode”而是“AI 输出阶段不开人工审阅阶段开一下”。审阅完没问题我再回到终端继续下一个任务。它对我来说就像验货台而不是生产线。6.3 什么时候我宁可不让 AI 写最后说一个更重要的判断标准涉及钱、安全和并发的地方我宁可自己手写。支付回调、库存扣减、分布式锁、幂等控制——这些场景一旦出错后果不是“改个 bug”能弥补的。AI 写这类代码我总是不敢直接信任哪怕它逻辑看起来没问题我也要自己一行一行抠。不是因为 AI 一定出错而是这些代码的验收标准不只是“测试通过”还需要考虑竞态、数据一致性、异常恢复等边界条件这些恰恰是 AI 最容易被训练数据掩盖的盲区。所以我的原则很简单普通业务代码大胆放权核心底层逻辑牢牢握住。这不是对 AI 的不信任而是对工程质量的基本敬畏。我自己这半年最大的体会是工具链的重心从“编辑器”变成了“对话”但该有的代码能力一点都没消失反而更重要了。AI 写得越快你需要判断的地方就越多。那些以为“AI 写代码之后程序员就躺赢”的人大概率会在项目越来越乱的时候被现实教育。如果你也想试试这条路我的建议是别想着一步到位。先挑一个你熟悉的小项目写一份AGENTS.md找个顺手的 AI 工具让它帮你完成一次带测试的小范围重构。完整跑通一次之后你会自然体会到“让 AI 干活、你来做验收”到底是一种什么感觉。到那时候VSCode 多久打开一次就只是个数字问题了。