用了半年的 Vibe Coding，我好像要把自己写废了
约 2623 字大约 9 分钟
AIVibe Coding
2026-06-17
最近有个感觉，我一天下来敲的代码，可能还没敲的提示词多。IDE 打开的次数没少，但真正落到自己手上的活儿却越来越少了。很多人在需求来了，整理一段提示词丢给 AI，等它生成，扫一眼结果，能跑，提交，搞定，一个功能从接到手到上线，更像一个流水线的质检员。
跟几个同事聊天时都在说类似的事，发现这不是我一个人的状态，所以想把这段时间的观察和自己的体感整理出来，算是个 阶段性复盘。
需求还没焐热，代码就已经写完了
以前接一个需求是什么样的？需求评审会上跟产品把每个分支场景掰扯清楚，评审过了做技术方案设计，方案再拉一拨人评审一遍，测试用例出来还得再过一次。三场会开下来，这个业务在你脑子里基本成型了 —— 哪个状态能流转到哪个状态、哪个字段是跟钱相关的不能有精度问题、哪个环节用户会卡住、哪个环节用什么技术方案实现，心里都有数。真正开发的时候再发现一些细节点，拿着具体问题去找产品核对，一来二去，业务流程完整闭环了，人也长本事了。
那时候测试提一个 bug，听两句描述就知道该往哪查。不是记性好，是这套流程走下来，业务认知是长在自己身上的。
现在呢？拿到需求，花十分钟把要点整理成提示词，「很多时候这步也是让 AI 帮忙整理的」，然后丢进去等结果。AI 产出，我审核，看看流程对不对、有没有明显的坑，没大问题就收工。整个过程里，我对这个需求的理解停留在"大概知道它要干嘛"，业务细节都过了一遍眼睛，但没过脑子。说白了就是 业务脱节 了：代码是我的名字提交的，但业务的账，记在了 AI 头上。
都说老程序员工程化经验足，转 ai 更上一层楼，那工程化经验哪来的？以前的代码是一个字母一个字母敲出来的，敲的过程中你会琢磨这个方法要不要抽出去、这个异常该在哪一层兜住、这段查询在数据量上来之后会不会拖垮服务，这些体感都是在键盘上磨出来的。现在代码是 ai 生成的，生成的东西能用，就懒得再抠了，业务体感的沉淀、工程化细节的打磨，这两样东西正逐渐从我们手上溜走。
说一下我个人对接下来程序员走向的判断：往后真实的工程化经验，会越来越值钱。
"能让 AI 写出代码"的人会越来越多，而知道"这段代码上了生产会发生什么"的人会越来越少，所以供需一倾斜，值钱的自然是后者，稀缺的从来不是会用工具的人，是能对结果负责的人。
AI 写出来的，总不是我的味儿
用 AI 写代码，还有个几乎人人都会遇到的槽点，那就是它写出来的东西，经常不是你想要的：
- 方向直接跑偏：你让它做订单超时取消，它顺手给你带一套自己的状态机，跟项目里已有的那套对不上
- 重复造轮子：项目里明明有现成的工具类、现成的组件，它不知道，吭哧吭哧又造一个
- 风格就是不对：代码本身没毛病，但命名习惯、分层方式、异常处理的路数，都自动跟项目里存量代码学习，简直就是在“屎山上拉一泡大的”
后来我是想通了，背后的原因不复杂：AI 不知道你的项目里已经沉淀了什么，也不了解你的口味，它见过全世界的代码，唯独没见过你的。
那怎么让 AI 更像自己，更贴近想要的效果？
简单来说，其实就是在对话时上下文怎么喂、项目规范怎么给、怎么用规则文件约束它的风格，做一个自己开发习惯的 Skill，这些是把 AI 用好的硬功夫，在这里就不展开了，后面我在整理一篇实战经验的时候细说。
学 Python 那阵子，我彻底浮躁了
另一件事是学 Python 的时候。
按理说碰新语言就该老老实实敲，老老实实的码，环境自己搭，报错自己读，小例子自己跑一遍。
但 AI 就在手边，人学着学着就懒了。明明该手敲走一遍的东西，动不动就"让 AI 生成一个看看"，很多时候就有一种看一眼就学会并掌握的感觉，扫个大概就翻篇，速度是快，学完一回头，离了 AI 什么都说不出来。
基础能力被弱化就是这么一点点发生的，不是某一天突然不行了，是每一次"懒得手敲"累积出来的。
听同事讲过一个更扎心的状态：让 AI 写的代码，他自己根本看不懂，但流程是对的，能跑通，"这就得了"，在细品这句话，现在刚入行计算机的学弟学妹们会不会也是这种状态？
这里有个死结
AI 写的代码本该由人把关，可把关的人都看不懂代码，审核就成了走过场，扫一眼就算确认，跑一遍主流程，就算通过了。在我看来多走一道流程不等于多一道保险，把不了关的审核，就算到了上线环节，也还会担心出问题吧。
所以说，该自己走的路，还是得踏踏实实的走，该自己码的代码，还是得老老实实的码！！！
线上出故障的时候，才是真正的裸泳
平时交付的特别顺畅，就跟科目二直接一把过，爽是爽了，但是这些问题都被盖着，当线上出故障那天，全都得还回来。
核心逻辑不是自己写的，对代码的内部逻辑、潜在风险点，就没有直观认知。以前自己写的代码，报错日志扫一眼，凭直觉就能框定个大概范围，因为每个坑都是自己亲手填的。现在面对 AI 生成的代码，日志看半天，脑子里没有地图，只能从入口开始一点点啃。
更悬的是，有同事连排查问题都交给 AI。AI 给出一串分析，说可能是这里、可能是那里，听着头头是道，但结果到底对不对、准不准，他心里没底，最后还是得回到代码里一点点理，有时候绕一大圈，时间花了，故障还在原地。
定位问题的速度和准确性，靠的从来不是工具，是对自己系统的熟悉程度。而这个熟悉程度没有捷径，都是在参与编码的过程中一点点喂出来的。
再往深一层：团队的知识断层
上面说的还是个人层面，把视角拉到团队，问题更麻烦。
以前新人进团队，是被"逼着"成长的：改个 bug 得把上下游代码读一遍，接个小需求得把业务流程啃下来，一年下来人就磨出来了。
而现在这些活儿 AI 都能代劳，新人跳过了被迫啃业务、啃代码的阶段，成长看着是快了，需求产出量确实高，但业务认知的地基没打。
一个团队里，真正懂系统全貌的人会越来越少。老人手上的业务体感本来就是文档装不下的东西，现在连"新人慢慢接手"这个传承通道都变窄了。等老人一走，系统就成了无人区：代码在、文档在，但没人说得清当初为什么这么设计、哪个模块底下埋着雷。
代码质量与工程化隐患，就这么在团队层面慢慢凸显出来。
我们团队现状
我们团队每周都开一次 AI 周会，分享的翻来覆去就是工具怎么用、技巧怎么省事、又淘到了哪个好用的 Skill、工作流还能怎么串起来。可从来没人聊过另一面：除了快，我们还该顾着点什么。有时候不一定以过程为导向，也该多留些心思在底蕴上。
说白了，是咱们偷懒偷过了头
写到这，我也在问自己：这是 AI 的错吗？
其实想想还真不是，AI 帮咱们省时间是真的，写个 CRUD、生成个基础框架，比自己敲快太多了。问题出在编程这件事不光是"写出代码"，更重要的是"写代码的过程"，在这个过程中摸透业务、练熟基础、积累踩坑经验。 现在 AI 把"写代码"这个动作替你做了，那些藏在动作背后的真本事，也就没机会学了。
整体看下来，vibe coding 确实带来了极大的便利，这点没什么好争的。但门槛的降低，反而会把高级人才的重要性往上推。
这篇的结论，一句话
门槛降低，不是让所有人都变强，而是让真正强的人更稀缺，AI 能快速搭骨架，但填血肉、让系统稳定落地的那些工程化细节，还是得靠人的经验去把控。
这篇算是把这半年的反思倒干净了，不知道在座的各位有没有此类感觉？
光反思没用，怎么把 AI 用好、让它写出来的代码更像自己的、怎么在 AI 时代保住自己的基本盘才是重中之重，这些实战层面的东西，留到这个系列后面的文章里一篇篇展开，先到这。