说实话我自己也没想到一台装好VSCode的开发机居然能在半年里一次都没被我打开。这半年我照样改代码、跑测试、上线项目Git 提交记录一天都没断过但打开编辑器这个动作确实已经消失了。不是 VSCode 不好而是 AI 写代码这件事已经把我熟悉的开发节奏彻底重构了。如果你和我一样日常工作是写业务代码、维护老系统、偶尔从零搭个小服务那这篇文章应该能给你一些参考。我会把半年里我抛弃传统 IDE 后的真实工作流、工具选型、提示词工程的细节、踩过的坑以及“什么时候还是得乖乖打开编辑器”的边界都摊开来说。适合正在考虑用 AI 从辅助转变为主力的开发者也适合对“AI 能不能自己写项目”有疑问的朋友。1. 从“开IDE”到“开聊天框”我的开发习惯发生了哪些变化1.1 曾经的VSCode日常插件、快捷键、环境配置以前我大概是典型的 VSCode 重度用户。为了一个 Python 环境配置我可以折腾半天 launch.json为了 C 调试还要装 code runner、配置 mingw前端项目更是离不开 eslint、prettier 的一堆配置。说实话这些配置本身是合理的但它占用了我大量的注意力。真正写业务逻辑的时间可能只占三分之一剩下时间都在跟编辑器较劲格式化风格不对、缩进乱了、自动导入的路径错了、调试器断点停在了奇怪的地方。那时候我还收藏了一堆“VSCode 必装插件”的文章什么 GitLens、Better Comments、Remote-SSH装了删删了装。后来发现插件装得越多启动越慢还经常出现插件之间的冲突。最典型的例子是 Python 插件和 Pylance 有时候会抢占解释器路径导致代码提示时好时坏。这些琐碎问题在 AI 介入之后几乎全都变成了无关紧要的事情。1.2 现在的工作台一个终端 一个 AI 客户端我现在的工作台极其简单一个终端窗口一个 AI 客户端的网页或桌面版本我用的是主流的 AI agent 编程工具比如 Claude Code 这类能直接操作文件系统的智能体再加上一个浏览器。日常流程就是在对话界面里描述需求让 AI 生成代码文件它自己会新建文件、修改代码、运行测试然后把结果反馈给我。真正让我下决心的是三个月前的一个小项目。当时要写一个内部的接口聚合服务大概十几个接口涉及鉴权、日志、异常处理。按我以前的习惯先搭框架再写业务逻辑最后写单元测试至少得花一整天。但那一次我尝试用 AI agent 来做我把接口文档丢给它提了几个约束条件不到四十分钟它就把完整项目骨架、核心逻辑和测试用例全部生成了而且我 review 之后只改了几个命名问题。那之后我就发现VSCode 在短平快的任务里已经彻底没有优势了。之前遇到问题去找插件的习惯也变成了“直接把报错丢给 AI让它告诉我怎么改”。1.3 为什么说“VSCode半年没打开”不是噱头很多人听到“半年没打开”的第一反应肯定是夸张。但我回头看了一下自己过去半年的开发记录确实没有一次主动打开过 VSCode。原因很简单AI 已经覆盖了三个核心环节代码生成、调试排查、重构整理。这三个环节是传统编辑器最耗时间的部分。以调试为例以前遇到报错我会自己在代码里来回跳转、加断点、看变量甚至写一堆 print 去猜。现在我直接复制完整的堆栈信息到 AI 的会话里它通常会立刻指出是空指针、资源未释放还是数据格式错位甚至直接给修复补丁。绝大多数情况下这个补丁是能用的。这让我彻底告别了“逐行排查—改错—再排查”的循环。当然并不是说 VSCode 从此没有价值。它仍然是我的最后一道防线尤其是在查看生成的代码是否符合项目架构、处理复杂合并冲突、审查第三方库的深层实现时我还是会打开它。但“默认打开编辑器写代码”的时代对我来说已经结束了。2. AI写代码的工作流搭建工具、规则与提示词工程2.1 主力工具怎么选AI编程助手、智能体与IDE的关系现在市面上的 AI 编程工具五花八门但大致能分三类一类是给传统 IDE 装插件的比如 GitHub Copilot 在 VSCode里做补全一类是独立编辑器形态的 AI IDE比如 Cursor还有一类是真正能独立执行任务的智能体比如 Claude Code、开源项目里常见的 via Agent 这类终端 agent。如果你问我推荐哪种我的建议是不要先选工具先想清楚你需要它做到什么。如果只是想要“Tab 自动补全”那 copilot 已经足够了但如果你想减少打开编辑器的时间你需要的是能直接读写文件、执行终端命令、独立思考怎么改代码的智能体。我最终选了 Claude Code 这类终端型 agent并不是因为它写代码最强而是因为它的工作流最符合“自然语言驱动”的直觉——你不需要先打开某个文件只需要告诉它需求它会自己去翻目录、看代码、改文件。而且它跑起来不需要图形界面对我来说非常干净。我自己还会配上一些开源模型 API 作为备选用来处理简单的一次性脚本省钱。2.2 提示词工程让AI理解项目上下文的关键很多人说 AI 写的代码质量不稳定十次有八次跑不通。我用了半年后发现问题大多出在提示词上而不是模型本身。第一次尝试让 AI 帮我重构一个老模块我只说了句“给这个文件加个缓存”结果它把整个模块的变量命名、函数签名、甚至返回结构都改了差点上线事故。后来我学乖了提示词里必须说清楚“只改哪个函数不动外部接口”并且给它看当前函数签名、调用方代码和测试用例。从这些经验里我提炼出一个提示词的基本盘背景、任务、约束、验收条件。背景是“这是什么项目用的什么框架JDK 版本多少”任务是“我需要实现什么功能”约束是“不要动哪些文件、保持什么风格、不允许引入新的依赖”验收条件是“写完要跑一下哪条命令确保通过”。举个例子同样是“给用户模块加个昵称字段”我现在的完整提示会长这样项目是 Spring Boot 2.7 的电商后端使用 MyBatis-Plus数据库为 MySQL 8。请给用户表增加一个 nick_name 字段需要同步修改实体类、Mapper、Service 以及对应的数据库初始脚本。注意不要改任何已有的接口签名保证现有单元测试全部通过。完成之后运行 mvn test -DtestUserServiceTest 并把结果告诉我。这样写下来AI 的执行路径就非常清楚不会出现“顺手把别处也重构了”的失控情况。这套提示词模板我在团队里让几个同事试过效果明显比“帮我加个字段”好了几个量级。2.3 规则设定项目的约束条件怎么传给AI除了每次在提示词里临时写约束你还可以在项目里放一份规则文件让 AI 每次修改代码前自动读取。我见过有人把规则写到AGENTS.md里也有人用它自己的规则配置文件本质上是一样的把项目约定、代码风格、禁止事项固化下来。我的规则文件里会包含这么几类内容项目技术栈清单避免它擅自引入新依赖、目录结构说明告诉它哪些目录不能动、代码风格要求比如不允许使用any、必须加错误处理、提交规范生成代码后必须跑哪些测试。这些看起来朴素但能够极大提升 AI 的稳定性。还有一种思路是给 AI 喂“正例”和“反例”。我经常直接在规则文件里写“参考src/utils/format.js的写法不要使用dayjs统一用原生Date。” AI 经过一次两次的纠正后后续生成的代码大概率能匹配这些偏好。记住AI 不是你肚子里的蛔虫你给它多少上下文它就能还你多少靠谱。2.4 多AI协作的工作方式我这半年还有一个心得别把鸡蛋放同一个篮子里。不同的 AI 模型在处理不同类型任务上有明显差异。比如写前端组件时某家模型对 React Hooks 和副作用处理很熟练而在写复杂 SQL 或存储过程时另一些模型的思路则更扎实。我的习惯是“主战场”放一个反应更快、能操作文件的 agent另外再准备一个对话版的 AI 用来做 review 和方案讨论。写完一段代码后我会把代码贴给另一个模型问“你觉得有什么边界情况没考虑性能有没有隐患”这样相当于让两个 AI 互相检查能抓到不少主模型自己不容易发现的盲区。实测这套流程能减少大概 30% 的代码返工。3. 一次完整项目复盘让AI从零搭建一个Web服务3.1 需求描述与拆解纸上谈兵说再多不如完整走一遍流程。就拿我上个月帮朋友写的“会员积分查询服务”来举例。需求很简单对接现有用户系统查询积分余额支持每日变动流水输出成 JSON 接口。传统开发方式从初始化项目到上线至少需要两天。这次我全程用 AI agent 开发记录下整个过程。我把需求按提示词模板拆成几条技术栈用 Python FastAPI SQLite数据模型只涉及users和points_transactions接口只需要GET /points/{user_id}和GET /points/{user_id}/transactions鉴权使用调用方传入的 API key支持分页和错误 JSON 格式。我把这些要求打包发给 AI并且告诉它不要用 Docker直接在本地跑生成requirements.txt。3.2 生成代码与自动检查AI 收到任务后先是列出文件结构main.py、models.py、schemas.py、db.py然后在十几秒内生成了各个文件。它甚至还自己初始化了数据库插入了测试数据。我接下来要做的是检查细节而不是从零写起。我让 AI 启动服务然后用curl打接口。结果第一次跑就报了一个错SQLAlchemy 版本更新后declarative_base的导入路径变了。这时候我直接把报错贴回 AI它立刻识别出是依赖版本问题自动生成了一个新版本兼容的写法重新跑通。我给它的“验收条件”起了作用。它自己跑了一遍pytest把四个测试用例全部通过后才说“完成”。相比早期那些“我写好了你检查一下吧”的松散状态这种强验收的流程更符合工程习惯。3.3 调试与迭代AI怎么帮我修bug你以为代码跑通就算完了业务方很快就加了需求需要支持积分过期时间每天凌晨跑一个定时任务把过期的积分清零。接着又有需求查询接口要返回“可用积分”和“冻结积分”两个字段。这些迭代如果放在以前我需要从数据库设计改起一路改到接口层。但现在我只需要把需求变化描述清楚AI 会自己比较现有代码给出增量修改方案。我记得最复杂的改动是“冻结积分”逻辑——当一笔积分被使用时先进入冻结状态第二天确认后才扣除。AI 设计了status字段来表示available、frozen、expired修改了事务逻辑还加了一个异步定时函数的测试。整个过程中我只在最后 review 时调整了两个业务判断分支其余全部原样采纳。3.4 部署上线AI还能管运维吗部署这步我也没开编辑器。我把服务器系统、Python 版本、端口号告诉 AI它生成了 systemd 服务和 Nginx 反向代理的配置还写了一条自动拉取代码并重启服务的一键脚本。我不否认这些内容运维手册里都有但以前我要去搜索引擎翻半天才能拼出一个能用的配置现在 AI 几秒钟就能给你一个经过校验的版本。上线后我遇到过一次请求量稍大导致 SQLite 锁库的问题。AI 的建议是切到 PostgreSQL但作为轻量服务我更需要应急方案。它立刻给了一个平滑的方案开启 WAL 模式、把连接池参数调低然后将写操作放到一个后台队列里。这个建议很务实。整个过程我没有写过一行 SQL 或 Python但服务一直稳定运行到现在。4. 半年里踩过的坑AI生成代码的常见问题与排查4.1 代码“看起来很对”但跑不起来这是我最开始遇到的最大坑。AI 生成的长函数和整个文件通常质量很高但一旦你要改某个函数的内部逻辑它经常会给你一个语法一字不差、但放在原环境里就会报错的代码。原因在于它没看到完整的上下文或者对项目内部工具函数不够了解。后来我的解决办法是要求 AI 在动手前先自己“读文件”。很多智能体本身就有文件读取能力你一定要在提示词里让它先查看相关文件再用完整的内容去改。比如“先打开src/api/user.py阅读update_user函数然后在此基础上修改。”这一步能极大降低“虚空改代码”的概率。另外一个小习惯不要让 AI 直接在终端里运行“可能产生破坏性影响”的命令。比如pip install --upgrade全量升级我踩过一次把环境里的依赖全弄乱了。现在我会强制它先打印出将要执行的命令确认后再运行。说白了就是把 AI 当作一个“胆子有点大”的实习生你得上保障机制。4.2 依赖地狱与版本冲突AI 特别喜欢“通过 pip 安装最新版”来解决问题。比如它写了个代码报错缺包它会顺手pip install requests。如果改到pydantic版本升级的接口它可能会允许你升级主版本但主项目里其他模块是基于旧版本写的一升就全崩。我的经验是在规则里明确写“不允许直接升级第三方库的大版本只能使用项目已有的依赖”同时把requirements.txt或pyproject.toml放进 AI 的上下文里。这样它改代码时就会通过读文件知道当前版本号并用符合该版本的语法。4.3 AI擅长的领域和短板经过几个月高强度使用我总结一下不同场景的表现脚手架、CRUD、单元测试、配置脚本这些是 AI 的绝对强项生成速度快、质量稳定算法设计、复杂状态同步、性能优化的场景它能给思路但很容易停在“看起来优化了实际没变快”的层面最薄弱的是那些需要依赖大量历史决策并判断“为什么当初要这么写”的业务逻辑。它不具备你公司的业务记忆所以你仍然要充当那个提供上下文的人。举个例子让 AI 解释一段晦涩的旧代码它能说出代码的表面逻辑但说不清“这段逻辑是为了兼容哪个历史奇葩需求”。这种时候别勉强它直接把业务背景告诉它它反而能帮你补全很多便于理解的注释甚至主动建议拆分。4.4 什么时候必须打开编辑器半年没开编辑器不等于它没有用。有几种情况我还是会老老实实打开 VSCode首先是处理多个分支合并时的复杂冲突AI 能处理常见冲突但遇到“同一个文件被完全重写两边都有大量变更”时它很容易糊涂合并出既不左也不右的怪代码其次是检查“冷门三方库的底层实现”如果 AI 对某个库不熟悉需要我跳到node_modules或 site-packages 里看源码最后是写代码时想快速验证某个正则、某个样式效果或者浏览器调试器看网络请求——这些交互式操作AI 暂时替代不了。所以准确来说VSCode 不是被淘汰了而是从“生产工具”退居到了“特种工具”。我的常用工作流里它就像一个急诊室只在特殊情况被叫醒。5. 如果现在重新开始我会如何配置这套AI开发环境5.1 最小可用配置如果你也想尝试完全用 AI 来主导开发我建议从这套最小配置开始一台能装 Python/Node 的电脑一个终端智能体就是前文提到的 Claude Code 这类一个代码托管平台账号再加一个备用对话 AI。所有项目文件都放在本地一个固定目录里让 AI 有明确的“工作根目录”。不需要安装任何 IDE连文本编辑器都不用装。我甚至试过在无头服务器上跑完整开发流程AI 在终端里生成和修改文件我用手机浏览器查看 Git 提交记录。只要把 SSH 密钥和 Git 远程仓库配好代码照样能在远端流转。这套配置尤其适合远程容器或云开发场景非常轻量。5.2 适合AI协作的项目结构为了让 AI 更少出岔子项目结构一定要足够规整。我推荐小步子拆分把业务逻辑和外部接口分离每个模块尽量独立比如api/、services/、models/、utils/。如果你让 AI 在只有一个巨大的main.py的项目里改东西它很容易在几百行代码里迷失产生不必要的修改。还要养成写测试用例的习惯。AI 写代码如果完全依赖人工 review效率还是不够高但如果你先把“验收条件”写成测试用例AI 就可以自行跑测试来确认新代码没有破坏旧功能。这也让 AI 的“自查”变得可行。5.3 最后的一点个人体会回想这半年最大的收获不是省了多少时间而是我对“编程”这件事的理解变了。以前我总认为写代码的核心能力是熟练度——记住了多少 API、会配置多少插件、能背出多少种快捷键。现在我发现这些能力正在快速贬值真正值钱的是把模糊需求拆成清晰指令的能力、判断 AI 产出质量的能力、以及在关键时刻给出正确业务约束的能力。我也越来越清楚地看到AI 写代码的上限不取决于模型而是取决于使用者的认知水平。同一套模型有人让它去 “做一个电商系统”它最终只能生成一个玩具有人能一层层拆解把认证规则、商品流转、支付对账、库存同步都交代清楚AI 交付的可能就是一个能直接商用的系统。所以如果你也打算尝试“扔掉 IDE”建议先别急着扔。把 VSCode 留着在它旁边开一个 AI 会话先试着手写一段、生成一段、对比一段。渐渐地你会发现打开 VSCode 的次数不知道从哪一天起就越来越少。而你的关注点也从“怎么按快捷键”变成了“怎么问问题”。这个转变很有意思但对很多人来说也意味着一种全新的开始。