我第一次听到 vibe coding 这个词时，脑子里浮出来的画面有点滑稽：一个程序员靠在椅子上，咖啡放在手边，对着 AI 说几句“给我来个登录页”“再酷一点”“按钮换个颜色”，然后代码自己长出来。听着像周末在家折腾小玩具，带点懒散，带点不严肃。

可最近这段时间，我对这个词的感觉变了。不是因为它更潮了，而是因为它有点太轻。它把一件正在改变软件生产方式的事，讲得像在厨房里随手拌个沙拉。问题是，今天的 AI 编程工具已经不只是帮你补全几个变量名，也不是替你写一段循环那么窄。它开始读代码库，改多个文件，跑测试，看报错，再改一次，甚至能帮你准备提交。

这已经不是“写代码更快”那么一回事了。

真正以写代码为生的程序员都知道，最花时间的常常不是敲代码。敲代码只是露在水面的那一小截。水下面还有一堆东西：这个需求到底要改哪几个模块，老接口有没有兼容问题，数据怎么迁移，灰度怎么做，测试用例覆盖哪里，出了线上问题怎么回退。一个下午写完代码不稀奇，稀奇的是三个月后别人接手时，还能看懂你当时为什么这么写。

现在 AI 最容易让人产生幻觉的地方也在这里。它能很快给你一大段代码，界面能跑，接口能通，测试也许还绿了。屏幕上一片顺眼，人就容易松口气。可软件工程从来不只是“让电脑此刻跑起来”。它还要面对明天的需求变更，下个月的审计，半年后的性能压力，以及某个凌晨两点才冒出来的线上故障。

今天我看到一个公开报道说，Claude Code 的创造者之一 Boris Cherny 对 vibe coding 这个说法已经有些厌倦。他甚至说过类似“软件工程正在死亡”的判断。这话很刺耳，也很适合传播。放到朋友圈里，标题党能跑出一堆。可我更愿意把它理解成一种职业坐标的移动：死掉的不是软件工程，离场的是那种“只要会把需求翻译成代码，就能长期保持稀缺”的旧幻象。

这个变化对程序员并不那么温柔。

过去很多人评价一个程序员，会看他熟不熟框架、能不能独立写功能、改 bug 快不快、对语法细节掌握多少。这些能力仍然有用，但稀缺性正在下降。就像计算器普及后，心算快依旧有价值，却不再是会计的核心壁垒。AI 会写代码以后，拉开差距的，会变成另一套能力：知道该做什么，知道哪些地方不能让 AI 碰，知道系统边界在哪里，知道一段看似漂亮的代码会在什么场景下变成麻烦。

最近看到很多年轻工程师用 AI 写代码，速度开始十分惊人。一个需求刚讲完，他已经让 AI 生成了实现，页面也能点。可到了代码评审，问题一层层冒出来：异常状态没处理，权限校验漏了，接口命名跟项目习惯不一致，某个工具函数和已有逻辑重复，测试只覆盖了最顺的路径。你说这代码没用吗？有用。你说它已经完成工程交付吗？还差很远。

这有点像装修。AI 可以像一个力气很大的施工队，墙能砌，砖能铺，柜子能装，而且速度快到让人来不及催。可房子能不能住得久，还是要看设计图、承重墙、水电走线、防水层、验收标准。一个没有经验的人带着超强施工队，可能不是更省心，而是更快把问题藏进墙里。

所以我不太喜欢把 AI 编程讲成“以后程序员不用写代码了”。这个说法实际上是一种偷懒。更接近现实的画面是：工程师从亲手搬砖的人，变成拿着图纸、检查材料、调度机械的人。搬砖这件事会少很多，但房子塌了，责任不会自动飘到机器身上。

反观大公司，正确的做法是开始把 AI 编程变成一种组织动作。很多公司内部的新代码里，AI 生成的比例已经非常高；也有团队把 Claude Code、Codex 这类工具接入企业开发链路，让它们参与需求拆解、代码修改、测试、提交、审查。具体数字可以保留一点审慎，但方向已经摆在那儿：AI 编程不再只是个人玩具，它正在进入生产体系。

这会改变程序员的岗位定义，改变招聘过程，也会改变普通人的软件体验。

以前面试问你会不会 Java、React、MySQL。以后更要紧的，可能是你能不能把一个模糊需求变成 AI 能处理的任务，能不能让 AI 在大型项目里不乱跑，能不能设计测试和权限边界，能不能看出 AI 生成代码里的长期隐患。一个人会不会写某个框架，仍有意义；但只会这一点，护城河会变薄。

对普通用户来说，变化会更快、更贴身。小公司做一个内部系统，以前可能要找外包，沟通半个月，开发两个月。现在老板、产品、运营加上 AI，也许几天就能做出一个可用版本。个人开发者做小工具、小程序、网页，也会比过去轻松很多。门槛下降，软件会变多，创意会变便宜。

但便宜的另一面，会不会是质量更参差。

未来你会看到更多“看起来能用”的软件。界面不差，按钮也灵，功能说明写得漂亮。可背后有没有权限隔离，数据有没有加密，异常有没有处理，日志里会不会泄露用户信息，这些普通人看不见。就像路边新开的餐厅，装修很亮，菜单很花，可后厨卫生和食材来源，得等时间来检验。

AI 写代码的风险也在这里。它可以把产能放大，也可以把混乱放大。一个工程师本来架构感弱，用 AI 后不是自然变强，而是可能更快产出一堆看似能跑、后续难管的代码。有人把这种东西叫 vibe slop，意思大概是“靠感觉堆出来的软件残渣”。词有点糙，但画面感很足：屏幕上跑得通，仓库里一团乱，谁维护谁头疼。

我还看到有学术研究把 AI agent 生成的代码拿去测功能和安全，结果显示，功能通过不代表安全通过。也有研究观察资深开源开发者使用 AI 工具后的效率，发现某些场景里并没有变快，甚至因为审查、纠错、理解生成代码而耗费更多时间。这个结论并不意味着 AI 没用，它提醒我们：效率不是按钮，按下去就自动出现；效率来自工具、项目、经验、流程之间的配合。

我自己用 AI 写代码时，也越来越像在带一个手很快的实习生。它不怕累，搜索速度快，生成模板快，改重复逻辑快。可我不能把方向盘完全交出去。我得告诉它范围，告诉它不要动哪些文件，告诉它先跑哪些测试，看到它给出的方案时，还得判断这个方案是不是符合项目习惯。

这种工作方式会让一部分程序员很不舒服。因为它削弱了过去那种熟悉感：坐在电脑前，一个字一个字敲，靠手感掌控整个过程。现在你要学会描述、约束、审查、验证。你写得少了，但脑子不能少转。甚至可以说，手上的劳动减少，脑子里的工程判断反而更重。

也会有一部分人变得危险。他们会把 AI 当成外包，把需求丢过去，复制结果，能跑就交。短期看，速度很快；时间拉长，就像把债务藏进抽屉。技术债不会因为是 AI 写的就消失，安全漏洞也不会因为注释写得漂亮就变温柔。系统只认实际动作，不认作者。

还有一部分人会变得更值钱。他们会把 AI 当作工程杠杆，不满足于让它写一个函数，而是让它参与资料梳理、改动定位、测试补齐、代码审查、迁移脚本生成。更重要的是，他们知道在哪里停。遇到支付、权限、隐私、生产数据、核心链路，他们会设置检查点，让人来确认，让测试来证明，让日志能追踪。

这类程序员的价值，不在于比 AI 打字快，而在于知道系统应该长成什么样。

我开始觉得，程序员过去有个误会：以为代码是成果本身。可在公司里，代码只是把业务意图固定下来的材料。工程师交付的不是若干文件，而是一套可理解、可维护、可验证、可演进的系统。AI 可以加速材料生产，但不能自动给出责任感。

这也是“软件工程已死”这句话容易误导人的地方。工程没有离开，反而更重了。因为当代码变得更容易生成，低质量代码也会更容易泛滥。过去一个人一天只能写出一小堆问题，现在借助 AI，一天能制造一大堆。产能越强，治理越重要。

普通人也会被这件事影响。以后买软件、用小程序、把个人信息交给某个服务时，不能只看它是不是做得快、是不是便宜、界面是不是顺眼。背后有没有工程质量，会越来越影响你的隐私、财产和体验。软件世界会像短视频平台一样，创作门槛下降以后，内容数量暴涨，优质内容和粗糙内容混在一起。用户需要辨别，平台需要治理，开发者需要自律。

那程序员该怎么办？

我的看法很朴素：别跟 AI 比手速，去练 AI 暂时替不了你的那部分。需求理解、系统设计、数据建模、测试意识、安全边界、代码审查、故障复盘、长期维护，这些东西听着没有“十分钟做出一个 App”刺激，却决定软件能不能活过演示阶段。

如果你是刚入门的开发者，也别因为 AI 会写代码就跳过基础。基础不是为了让你手写所有代码，而是为了让你看得懂 AI 写了什么。你不懂数据库索引，就看不出它生成的查询会拖垮系统；你不懂权限模型，就发现不了它漏掉的校验；你不懂网络和并发，就会把偶发 bug 当成玄学。

如果你已经工作多年，也别只把 AI 当补全插件。更大的机会在流程层面：把重复检查变成脚本，把常见任务变成模板，把代码评审规则写出来，把测试命令和验收标准固化下来。AI 最怕一团雾，最喜欢边界和证据。你把工程经验整理得越像地图，它越能少走弯路。

所以，vibe coding 这个词也许还会传播一阵。它轻松，顺嘴，有传播感。但我更愿意提醒自己：别被这个词骗了。这里面没有那么多玄学，更多是工程能力重新分配。代码生成会越来越便宜，系统判断会越来越贵；敲代码的手感会被稀释，设计边界和承担责任的能力会被放大。

软件工程没有死。它只是换了一个考场。

过去考你能不能把代码写出来。以后考你能不能让一群不会负责的机器，产出一套有人敢负责的系统。这个差别，才是很多程序员接下来几年必须看懂的事。