上周接了个老项目的需求给一个跑了多年的定时任务服务加个新的调度策略。放以前我的流程很固定打开VSCode等项目索引转完CtrlShiftF 全局搜关键词翻着一堆历史代码慢慢理解脉络然后新建分支小心翼翼改代码最后手动跑一遍测试。但这次不太一样——我打开电脑后直接进终端在项目根目录敲了一句命令把需求用三行大白话丢给背后的 AI 编程工具让它自己先读代码、列改造方案。等我倒了杯水回来看它已经把改动落到分支里测试也跑完了还贴心地列了三个需要人工确认的风险点。这个场景在一年前我会觉得离谱但这半年确确实实发生了。我的 VSCode 图标在 Dock 栏上一直待在原来的位置一直没被点开过。不是刻意不用是真的没有打开它的动机了。今天把这段时间的完整过程和真实手感写下来包括我到底在用什么工具、怎么把需求翻译给 AI、踩过哪些坑以及哪些场景我最后还得老老实实回到编辑器里。1. 从打开编辑器到下发指令我的日常写码流程彻底变了1.1 一次普通需求的前后对比先说个具体的例子。之前那个定时任务服务需求是按用户等级分配不同的重试次数超过阈值进死信队列。以往在 VSCode 里的做法大概是全局搜索retry或者死信找到处理入口顺着调用链往下读确认配置项从哪里加载在脑子里画一张模块依赖图再决定改动哪个文件改完代码继续写单测生怕影响别的地方手动跑 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 编程工具看着很多本质上是三条路线路线代表工具核心特点适合场景IDE 内嵌插件GitHub Copilot、Codeium补全、对话、局部修改人写 AI 补仍然以人为主力独立 AI 编辑器Cursor、Windsurf把 AI 能力揉进编辑器交互介于补全和自主执行之间的折中命令行 AI AgentClaude Code、Codex CLI、开源 agent 框架直接拿到终端权限自主完成多步任务我这种下发需求、回收结果的模式三条路线我都认真用过。说实话如果只是写写脚本、改改前端页面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 替我写代码但替不了我理解代码。