我去年年底换了台新电脑装完环境之后VSCode 的图标就一直在程序坞里吃灰。前两天一个关系不错的同事偶然看到惊讶地问我“你转行了”我说没有代码我天天在写只是打开编辑器的次数确实已经半年多没怎么碰过了。他一脸难以置信接着问“那你在哪儿写”“在对话里写在浏览器里写有时候直接在命令行里让 Agent 自己写。”我没有凡尔赛的意思这是个特别实在的状态当 AI 接手了大部分“把需求翻译成代码”的机械劳动之后VSCode 这个曾经的日常主场就真的退居成了后台验收工具。这篇内容就想跟还在用传统方式堆代码的朋友聊聊我这半年是怎么把写代码的主阵地从编辑器挪到 AI 对话和 Agent 工作流里的以及这个过程里踩过的坑、守住的红线和真正留下来的习惯。先泼盆冷水这个标题容易让人误解成“我啥都不干了全靠 AI 生成”。真实情况远没那么轻松更像是角色变了干的活从“码字”变成了“拆需求、喂上下文、审结果”。如果你也想试试这种工作方式或者正在被 AI 编程工具吸引但还没找到感觉这篇文章应该能给你一套可以照着调整的参考路径。1. 半年不开 VSCode准确说是它的角色从“主战场”变成了“验收台”先把这个状态定义清楚免得有人觉得我在吹牛。我并不是完全不用编辑器而是编辑器的打开频率从“一天十几个小时”降到了“一周几次”。现在大部分代码的产出路径是我在对话窗口里把需求描述清楚AI 生成方案和实现我确认无误后再让 Agent 直接落到项目里。整个过程里我面对的是聊天界面、命令行、以及那些离线的工程化工具。VSCode 只有在三种情况下才会被打开审查 AI 生成代码的 diff、调试一个 AI 怎么都绕不过去的疑难杂症、以及写那些需要极度精准的领域底层逻辑。1.1 为什么编辑器会退场核心是“上下文”的转移传统开发模式里编辑器是写代码的地方更是“上下文”的载体——你打开项目目录看到文件结构搜索函数定义脑子里装着整个模块的设计。AI 编程把这些上下文直接吃进了自己的模型里。比如我在对话里贴一段接口文档加上项目目录树再说清楚约束条件它给出的代码就已经是贴合项目现状的不再是我打开一个文件开始敲函数。换句话说代码的“生成现场”从编辑器转移到了对话上下文里编辑器自然就没了用武之地。正因为“上下文”是决定 AI 代码质量的关键我花了很多精力研究怎么在对话里高效地构建上下文。常用的方式有三种直接把相关文件内容复制进对话让 AI 基于当前实现来改使用 Agent 工具让它自己去读仓库里的文件、运行命令把结果带回对话建立项目级说明文档类似 README 加架构说明每次对话先让它读这个文档再开工。这三种方式各有适用场景。文件内容粘贴适合小范围改动Agent 自动读库适合跨多个文件的重构项目级文档则适合长期维护、每次都让新对话快速进入状态。实测下来维护好项目说明文档的收益最大因为 AI 不需要每次重新猜项目结构产出质量稳定很多。1.2 这种工作方式到底节省了什么最明显的是省掉了“从脑海到文件”的转换成本。以前写一个接口我要先想清楚参数、写注释、补类型、处理异常再考虑要不要加日志。现在这些事我只需要在需求里说清楚AI 直接就给你铺开了。我粗略统计过一个中等复杂度的 CRUD 模块以前手动写至少小半天现在从对话到落地验收一个小时以内完全可以搞定产出代码的风格还比我写的更统一。但有一点必须强调省下来的时间并没有变成休息而是转移到了更靠前的需求分析、更仔细的代码审查、以及更频繁的测试验证上。代码行数少了不代表责任小了反而因为生成速度快了出错的传播速度也快了验收环节比以前更重要。2. 从需求到落地的完整工作流拆解、投喂、生成、验收四步法很多人觉得 AI 编程就是“把需求打进去代码吐出来”实际根本不是这样。我磨合了快一年才形成稳定的四步工作流每一步都有明确的动作和目标。这套流程未必适合所有人但至少能让你少走很多弯路。2.1 第一步把需求拆成 AI 能执行的任务这是整个流程里最考验人的一步。AI 不像人它不会主动问你“这个需求背后到底解决什么问题”它只会按字面意思执行。你要是说“写一个用户登录接口”它给你一个标准的登录实现但你的系统可能早就有了统一的认证框架或者你的登录逻辑需要对接第三方平台。所以我的习惯是在对话里写清楚三样东西业务目标、现有约束、验收标准。举个例子我曾经需要一个批量导入用户的功能。一开始我只写了“实现用户批量导入”结果 AI 给的是 CSV 解析加数据库插入完全没考虑重复数据、权限控制、导入失败回滚这些问题。后来我把需求改成这样业务目标管理员通过上传 CSV 批量创建用户账号 现有约束用户表有唯一索引需要跳过重复项并记录失败原因导入操作仅限管理员角色每批最多 5000 条 验收标准导入完成后返回成功数、失败数、失败明细重复数据不中断导入流程。AI 给出的实现质量立刻上了一个档次。2.2 第二步构建好上下文让 AI 真正“了解”你的项目这一步是决定代码是否贴合的胜负手。我有几个固定的“喂上下文”动作基本上每次大任务都会执行项目目录结构让 AI 知道模块划分涉及修改的文件原文让它基于真实代码改动而不是凭空重写相关的接口定义或数据库表结构防止它自己编造字段项目里的编码规范片段比如错误处理方式、日志格式。如果你用的是类似 Claude Code 这样可以访问仓库的工具那上下文投喂可以更省力。记得有一次我让它加一个新接口它自己打开 service 层和 model 层看了一圈然后复用了我已有的分页公共方法效果比我手动贴文件还准确。这个过程让我深刻体会到AI 编程的质量上限取决于你给它看的东西有多接近真实项目状态。2.3 第三步让生成过程有节奏不要一次憋大招我早期犯过一个特别蠢的错误以为任务描述得越大AI 越能一次性搞定。结果给了一个“实现整个订单系统”的需求AI 回了一千多行代码看着挺像回事但一跑起来全是问题字段命名不一致、模块依赖缺失、风格五花八门。后来我改成按模块拆、逐层推进先建数据模型再写接口雏形接着补业务逻辑最后加异常处理和测试。每一步都在对话里确认有偏差立刻修正这样虽然对话轮次多了但最终代码的可靠性和可维护性都强很多。你可以理解为AI 写代码就像带新人干活你把一个大任务扔给他他会懵你拆成一个个小步骤每一步都验收一下出来的东西才靠谱。2.4 第四步验收这是 AI 编程时代的核心技能代码生成之后真正决定质量的是验收这一关。我的验收动作有三件套先看 diff重点检查有没有夹带私货AI 喜欢加一些多余的重构和明显不符合项目规范的写法然后跑测试本地快速验证主流程必要的时候让它自己写测试用例最后在代码审查清单里过一遍错误处理完整吗边界条件覆盖了吗有没有硬编码日志是否可追踪之前有一次 AI 帮我写数据迁移脚本我犯懒没仔细看结果它把时间字段的时区处理写错了数据导入之后所有时间都差了八小时。这种问题如果不靠验收环节揪出来上线就是事故。从那之后我定了一个死规矩AI 生成的代码必须经过代码审查流程和同事写的代码同一个标准不能因为是 AI 生成的就放宽。3. AI 代码的能力边界哪些活它能干哪些活它真不能碰用了半年多我发现了一个特别反直觉的实际情况AI 代码能力的强弱不完全取决于任务复杂度更多取决于任务的“上下文完整度”和“反馈可验证性”。有些看起来很难的事它做得很好有些看起来很简单的事它能把你坑到哭。3.1 它真正擅长的事情我总结为“高重复、强模式、快验证”首先是样板代码和 CRUD 模块这是 AI 的绝对舒适区。比如给一个表结构写标准的增删改查接口它写得又快又工整比我手动敲效率高太多了。其次是代码迁移和重构比如把一个模块从 JavaScript 改成 TypeScript或者把一个老框架的写法升级到新版本这种“有明确模板可循”的工作AI 几乎可以全自动完成。再次是测试代码和脚本的生成给函数写单测、给部署写脚本这些任务的验证路径非常清晰——测试能不能跑过脚本有没有执行成功一眼就能看出来。还有一个场景是解释陌生代码这个特别有用。接手旧项目或者看开源代码的时候不懂的逻辑直接扔给 AI它能帮你梳理清楚模块之间的调用关系减少理解成本。3.2 它真正不擅长的事情是你只能用判断力兜底的事情一类是“业务决策隐藏得很深”的逻辑。比如一个促销活动的价格计算看起来就那么几行但背后可能牵涉折扣叠加规则、优惠券优先级、平台补贴上限。这类逻辑每一个分支都可能隐含一个决策AI 生成的是逻辑但它不懂决策背后为什么这么做。另一类是性能敏感和安全性要求极高的代码比如高频核心路径里的优化、权限校验的边界、加解密和支付相关逻辑。这类代码出错的代价极高而 AI 的错误往往是“逻辑上说得通但实际场景里就是有问题”排查成本比手动写还高。3.3 判断任务适不适合 AI 的三条标准我给自己定了一套决策标准每次遇到任务先过一遍上下文是否足够完整如果这个任务需要查阅大量领域知识才能做对那 AI 强项发挥不出来出错代价是否可控如果是核心支付、核心数据迁移这类出不得错的活宁可手动写或至少手动复核每一步结果是否可快速验证如果写了代码但无法立刻验证正确性那么 AI 的“自信输出”反而成了风险源。用这三条标准我能把一个看起来“AI 都能干”的需求快速区分成三类直接交 AI、AI 辅助人工写、只能纯人工写。分类做得越清晰后面踩坑的概率越低。任务类型AI 表现我的处理方式样板代码、CRUD、脚本高效稳定全流程交给 AI重点验收模块重构、技术栈迁移质量不错拆步骤推进每步验证业务规则复杂的逻辑容易自洽但不正确人工主导AI 辅助生成框架性能敏感、安全关键代码不敢信任完全人工写AI 只当参考陌生项目代码解读帮助巨大只管用注意核对关键结论4. 这半年踩过的五个坑每一个都让我付出了真金白银的时间光说流程和能力边界容易让人觉得这套打法很理想。实际上半年里我踩的坑一点都不少挑五个典型的说出来每个的背后都是一次真实的教训。4.1 上下文丢失对话长了之后AI 会忘掉你前面立的规矩AI 对话有上下文窗口限制一旦超过一定长度早期约定的约束条件就慢慢失效了。有一次我让 Agent 做整个模块开发前面明确说了“不要用外键用逻辑关联”结果写到后半段它自己开始往建表语句里加外键约束代码风格也开始漂移。后来我学乖了长任务必须分段执行每一段开始时重新声明核心约束再配合项目根目录放一个“开发规范.md”每次新对话先让它读一遍上下文丢失的问题就基本解决了。4.2 依赖幻觉AI 会用一些你没装过的库而且学得有模有样这个坑尤其隐蔽。AI 生成代码时偶尔会用一些根本不存在的小众库或者把一个功能写成调用某个库的 API但那个库不是你项目里的依赖。最麻烦的是它写出来的代码语法完全正确编译都不报错只有运行到那一步才会崩溃。我现在养成了一个习惯凡是 AI 生成的代码里出现不认识的 import一律先去查这个包是否真实存在、版本是否兼容、是否已经加入依赖清单。不要盲目相信 AI 引用的外部资源它有时候是真的在“编造”。4.3 过度自信AI 说测试通过了但它根本没跑有一次我让 Agent 补一个异常分支的测试它过了一会儿回复“测试通过”我打开测试报告一看它所谓通过是指编译没报错根本没有真正执行测试用例。这种“口头通过”在 Agent 工具里特别容易发生它可能跳过了某些步骤直接汇报了结果。现在我对 Agent 汇报的验证结果一律保持怀疑凡是要确认的我就在命令行里自己跑一遍把真实输出贴回对话再判断。4.4 本地与云端环境差异在 A 环境能跑在 B 环境就崩我的开发环境有本地和云端两套AI 生成代码的时候默认场景只有一套很容易出现“代码没问题但环境不对”的情况。典型的就是 C/C 选手经常遇到的动态库缺失比如运行时提示找不到 msvcp140.dll 之类的依赖问题还有 Python 环境里用了没安装的包Node 项目里版本不匹配。这些问题从 AI 的角度看都不是代码逻辑错误但真实运行就是过不了。走进这个坑之后我所有项目的依赖描述都细化到文件级并且在验收阶段增加“干净环境跑一遍”的步骤极大减少这种“本地能跑别人那儿跑不了”的尴尬。4.5 合规与数据安全红线不是所有代码都能喂给 AI这个坑严格来说不是技术问题而是流程意识。公司项目里有些代码涉及核心商业逻辑或用户数据这些内容原则上不应该直接作为上下文发给外部服务。我一开始为了方便把整段代码直接贴进对话后来被提醒才意识到这有多危险。现在我的规矩是涉密或敏感代码先做脱敏再投喂或者干脆只描述逻辑不贴代码涉及公司知识产权的项目优先使用本地部署的模型或经过审批的内部工具。这条红线怎么强调都不过分。5. 提示词和规范资产化效率的真正来源不是工具是沉淀用了半年 AI 编程之后我最深的体会是AI 写代码的上限取决于你喂给它的东西是否成体系。同样是“帮我写一个接口”我现在的产出效率可能比新手高出好几倍原因不是我会用更多工具而是我积累了大量的“规范资产”。5.1 我的项目级提示词模板可以拿来即用这里分享一个我常用的提示词结构基本覆盖了上下文投喂、约束声明和验收标准三块内容你完全可以复制改造成自己习惯的版本背景我要在 [项目名] 中实现 [功能]项目用了 [技术栈]核心架构见 [文件路径]。 已有模块[相关代码文件或结构说明]。 需求 1. [具体功能点 1] 2. [具体功能点 2] 约束 - 遵循项目现有代码风格尤其是 [风格说明] - 使用现有公共组件/方法不要重复造轮子 - 不改动无关文件 验收标准 - [功能行为验证] - [测试要求] - [错误处理要求] 请先给出实现方案确认后再写代码。关键在最后那句“请先给出实现方案确认后再写代码”。它逼着 AI 把你的需求拆成可以推敲的方案而不是直接闷头写。方案有问题的话这个时候就能暴露出来比写了一堆再返工划算得多。5.2 把 AI 代码审查清单固化成肌肉记忆我整理了一份 AI 代码生成后的检查清单不长但每一项都在实际项目里拦过问题改动范围是否严格限定在需求涉及的文件是否有新增的依赖或外部调用它们的来源合法性和版本兼容性错误处理是否覆盖了主要异常和边界条件是否存在硬编码的密钥、地址、配置项是否引入重复代码有没有复用已有的公共方法时间、时区、金额等敏感计算是否有明确处理测试用例是否验证了真实行为而不是只过了编译是否符合项目的数据安全和合规要求。这套清单现在沉淀成了我的“标准动作”不管 AI 生成的代码看起来多顺眼我都会逐条过一遍。有些问题确实要花额外时间但它拦下的事故价值远远大于这点付出。5.3 多 AI 协作的新场景让一个 AI 写代码另一个 AI 审代码最近我还在实验一种新的玩法用多个 AI 互相协作一个负责写另一个负责审。写法不变但生成完之后把代码丢给另一个不同模型的 AI让它以“严格代码评审员”的身份找问题。它经常能提出一些写代码的那个 AI 没注意到的边界情况或者指出可读性方面的改进建议。这种“写审分离”的思路本质上是人类审查的延伸目前体验下来效果不错但最终决定权仍在我手里AI 之间互相认不认账不能代替人的判断。5.4 回到 VSCode 的时刻什么时候我会主动打开它虽然标题写着半年没打开 VSCode但我不否认它依然有价值。我主动打开编辑器的时候通常是这几类情况排查复杂的并发或内存问题时需要断点调试和逐步跟踪调试 AI 生成的代码在真实运行环境里的异常行为以及手工调整那些对精度要求极高的算法实现。换句话说VSCode 没有过时只是从“日常使用工具”变成了“专项问题处理工具”。AI 编程不是消灭编辑器而是改变了编辑器和人之间的关系。另外我也见过不少同事坚持在 VSCode 里装 AI 插件让 AI 以内联补全和对话面板的形式嵌入编辑器。这也是一种完全可行的工作方式人和 AI 的协作密度可能更高。我只是个人更喜欢对话式的长上下文工作流所以走的是另一条路。工具本身没有高低适合自己习惯的就是好的。最后再说一点个人体会如果你也想尝试把更多开发工作交给 AI不要一开始就追求“彻底不打开编辑器”。从单个模块开始把上下文投喂、验收审查这套流程跑顺你会发现 AI 编程真正带来的不是“不用写代码”的轻松而是把精力从代码搬运挪到了更有价值的设计和判断上。这种转变才是这半年对我来说最值得的地方。