我挺讨厌“氛围感编程”这个说法的。

不是讨厌 AI，我自己就是 AI 时代的女客户端程序员，也一直在用 AI 写代码、查问题、拆需求、补一些重复逻辑。

AI 确实好用，但用 AI不是把脑子交出去。

我会自己把控节奏，会 review 代码，会判断它写出来的东西能不能进项目，会看它有没有破坏原来的结构。

所以当我看到很多人把 Vibe Coding 说得特别轻松，好像只要对着 AI 描述一下需求，代码跑起来，事情就结束了，我会本能地皱眉。

软件开发不是这么回事，尤其是客户端项目，最怕的就是表面能跑，里面越来越乱。

一个项目能不能长期跑下去，靠的不是“这一段代码现在能不能执行”，而是结构是不是清楚，边界是不是稳，状态流转是不是合理，后面再改需求的时候，会不会把整个项目越改越乱。

AI 可以很快生成代码，但它不会替你维护项目结构，你不管，它就会一路往前写，能跑就继续写，缺什么补什么，报错了再修一段。

短期看起来很快，长期很可能就是一堆没人想维护的代码垃圾。

快的是生成代码，不是解决工程复杂度

Vibe Coding 最容易让人上头的地方，就是它真的快。

尤其是刚开始用的时候，会有一种很明显的爽感。很多以前要自己慢慢敲、慢慢查、慢慢补的东西，它一下子就能给你吐出来，页面结构、接口样例、工具方法、一些重复逻辑，AI 都能很快生成。

这个时候人很容易产生一种错觉：代码出来了，功能跑了，事情就差不多完成了，但用久了会发现，它替你省掉的，更多是打字、搜索和一些机械劳动。

它没有替你完成真正难的部分

需求到底怎么拆，状态应该放在哪里，页面和业务逻辑的边界怎么划，哪些东西应该抽出来复用，哪些东西不能为了快随便塞进页面里，这些还是要人自己判断。

尤其是客户端项目，最怕的就是一开始看起来没问题，后面越改越乱。

AI 很擅长写一段局部能跑的代码，但项目不是一段代码，项目是一个长期演化的系统。

如果没有人管结构，它就会很自然地往熵增的方向走。今天这里补一段逻辑，明天那里复制一个方法，后天又在另一个页面里写一套差不多的状态处理。

每一处单独看都不一定有大问题，但堆在一起，项目就开始变脏。

页面逻辑越来越重，组件边界越来越模糊，状态散得到处都是。重复代码越来越多，但又不完全一样，后面谁也不敢轻易改。

短期看，是 AI 帮你把功能做快了，长期看，可能只是把维护成本提前藏进了项目里。

所以我觉得 Vibe Coding 最大的问题，不是 AI 不能写代码。

它当然能写

问题是，如果人没有架构意识，没有客户端的工程经验，没有对项目长期维护的敏感度，AI 写得越快，项目烂得也可能越快。

从写代码，变成审代码和做决策

AI 来了以后，程序员真的更轻松了吗？

以前写代码累，累在要一行一行敲，要自己查资料，要自己把逻辑慢慢补完整。

现在这部分确实快了，但快起来以后，人的工作并没有消失，只是换了地方。

AI 生成一段代码，我不能直接闭眼用。

我要看它有没有理解错需求，有没有把本来应该拆开的逻辑揉在一起，有没有引入项目里不该有的写法，有没有复制一套已经存在的东西，有没有埋一个现在看不出来、以后很难改的坑。

它写得越多，我要看的就越多。

有时候一大段代码生成出来，表面上省了时间，实际上我得花更多精力去判断它到底能不能进项目。

以前累在写，现在累在审，而且审代码不是简单看一眼有没有报错。

你要知道这个项目原来是什么结构，这个功能应该放在哪一层，哪些状态已经存在，哪些逻辑不能重复造，哪些地方看起来能跑但以后会拖垮维护。

这种判断比单纯写代码更耗脑子。

更麻烦的是，很多人对 AI 的理解停在“它能写，所以你应该更快”。

老板会觉得，反正你现在有 AI 了，效率应该提高。产品也会觉得，以前这个需求要两天，现在 AI 都能帮你写了，是不是今天就能出。

于是节省下来的时间，并没有真的回到程序员身上，它很快会变成更多需求、更短排期、更高期待。

AI 加速的不是自由。

很多时候，它加速的是需求。

代码生成变快了，需求也跟着变多。功能切得更碎，节奏推得更紧，review 的压力也更大。

最后人没有轻松多少。

只是从以前的“写不完”，变成现在的“看不完、判断不完、兜底不完”。

而线上出问题的时候，责任还是人的。

AI 可以生成错，可以重复，可以不理解项目历史。

但真正把代码合进去的人是程序员。

真正危险的不是 AI 写错，而是人放弃思考

AI 写错，其实没那么可怕。

错了可以改，跑不通可以调，逻辑不对可以重写。

真正危险的是，人开始习惯把 AI 生成的东西当成默认答案。

代码出来了，先跑一下，能跑就先放进去。需求催得急，结构就先不想了。原来有没有类似逻辑，也懒得翻了。这个页面先塞一点，那个页面再补一点，反正 AI 改起来快。

时间一长，项目里到处都是“先这样”的痕迹。

这个页面为了赶进度，把接口处理、状态判断、UI 展示全写在一起。另一个页面遇到类似需求，复制过去改几个字段。后面产品又加状态，原来的逻辑接不住，就在外面再包一层判断。

代码还能跑，但人已经不敢动了。

你不知道改 A 会不会影响 B，也不知道这里的判断当初是为了哪个需求加的。看起来只是改一个小功能，实际要先把一串历史债务翻出来。

这时候 AI 再进来，如果人没有控制结构，它只会继续顺着现有的乱法往下补。

它不会停下来问：这里是不是应该重构一下，它只会很配合地说：好的，我帮你加一个兼容逻辑。

所以我觉得，AI 时代程序员真正重要的能力，不是单纯会不会 prompt。

prompt 当然要会，但那只是入口。

真正重要的是业务理解、架构判断、代码审美、抽象能力、review 能力，还有拒绝坏代码的能力。

拒绝一段看起来能跑的代码，其实不太容易。

因为它表面上已经完成任务了。页面出来了，接口通了，需求也能交差。你要把它删掉、改掉、重写，就必须说清楚：为什么它现在能跑，但不该这样进项目，这才是程序员的价值。

不是比 AI 更会写某个 if else，而是知道这段代码该不该存在，应该放在哪里，会不会破坏原来的结构，会不会把今天的方便变成后面的坑。

AI 可以写代码，但AI不会替你承担出问题的后果。

代码最后要进仓库，要上线，要承接下一次需求，要被别人读，也要在出问题的时候有人查。

真正承担后果的人，是把代码放进项目里的人。

所以 Vibe Coding 到底是在造软件，还是在堆代码垃圾，关键不在 AI 有多强。

关键在写代码的人有没有把工程判断丢掉。

如果人还在思考，AI 是工具。

如果人放弃思考，AI 只是把代码垃圾生成得更快。