最近很多朋友跟我说，你们程序员要被替代了，AI Coding已经那么强了，我1-2天就写了一个网站了，看看多强大。现在很多的营销号也在宣传“编程将被彻底终结”、“程序员岗位即将消失”.....

能看到全社会都在一起呐喊“将来人人都可以编码，制作软件了”。

作为一名程序员，在这行业中摸爬滚打的coder，已经将近20年；最近一年也确实用了AI Coding在做一些项目，带来极大震撼；也接触了很多身边的程序员，看到了他们的热情/迷茫/焦虑以及浮躁；我太能理解这种复杂的情感从何而来。

其实，我们可以把当下流行的Vibe Coding，看作是编程史上又一次重要的范式转移——每一次效率的飞跃，往往都伴随着原有某种核心能力的悄然退化。

以下，我将从几个维度拆解这种复杂的情感，提供一些共鸣与深度思考。

一、深度思考被即时反馈截断，我们沦为“盲目的裁判员”

以前写代码，大脑里相当于要运行一个“虚拟机”：推演逻辑、预判边界情况、排查潜在Bug，每一步都是深度的“慢思考”，是对逻辑能力的反复锤炼。

但Vibe Coding彻底缩短了反馈回路：你喂给AI一个模糊的想法，它就能吐出几百行代码；如果运行不通，你大概率不会去仔细研读报错堆栈，而是直接把错误粘贴回去，让AI重写。

这里的底层逻辑已经发生了本质变化：我们从“逻辑的构建者”，悄悄变成了“盲目的裁判员”。

付出的代价显而易见：当思考的深度跟不上代码生成的产量，程序员很容易产生“我变强了”的错觉。可这种能力极其脆弱，一旦脱离AI，大脑就可能瞬间“宕机”——因为我们早已习惯了被投喂，而不是主动构建。

二、对确定性的敬畏感消失，从工程师退化为“提示词裁缝”

计算机科学的本质，是追求确定性的艺术。每一个变量的生命周期、每一行指令的资源消耗、每一个逻辑的因果关联，都应该清晰可见、有据可依。

但Vibe Coding却引入了一种概率性的模糊感，现在的编程流程常常是：描述一种“感觉”，让AI猜测你的意图，只要代码能跑通，哪怕你完全不懂背后的原理，也觉得“万事大吉”。

这种“知其然而不知其所以然”的状态，正是浮躁感最肥沃的土壤。当一个开发者不再关心底层原理，只在乎屏幕上的组件是否按预想动起来，就已经从严谨的工程师，退化成了“提示词裁缝”——核心工作不再是写代码，而是研究如何用提示词“驯服”AI。

三、“快”成了唯一价值标尺，沉淀被速度碾压

在Vibe Coding的浪潮下，编程圈开始盛行一种“速度竞赛”：谁能5分钟写出一个App，谁能一个周末搞定一个SaaS产品，成了最能刺激多巴胺的比拼。

这种竞赛让整个行业变得极度功利：重交付、轻架构，只要表面功能光鲜，里面的代码哪怕是“屎山”也无所谓——反正下次改动，依然可以交给AI；重结果、轻沉淀，那些需要通过折腾、报错、查文档才能获得的肌肉记忆，那些藏在细节里的经验积累，都在快餐式的编程中慢慢流失。

四、对抗浮躁：不做Vibe Coder，要做“代码主理人”

这种浮躁感的本质，其实是工具进化的速度，超过了我们心智成熟的速度。AI时代的顶级程序员，不应该只是依赖AI的Vibe Coder，而应该成为“代码主理人”——掌控代码的主动权，而不是被工具牵着走。

对抗浮躁，其实可以从这几点做起：

保持审计权：AI生成的代码，你必须能看懂、能重构，绝不能做“甩手掌柜”；

向下扎根：越是工具便捷的时代，底层基础越重要——这是区分“提示词裁缝”与“编程大师”的唯一护城河；

掌控主动权：利用AI而非被AI驱动，把AI当作提效的“铲子”，而不是代替你思考的“大脑”；

慢下来沉淀：偶尔放下AI，手动复现一个关键模块，仔细研读AI生成的复杂逻辑，保留自己“卷起袖子手动修Bug”的能力——这才是不被AI反噬的底气。

你之所以感觉大家变浮躁了，是因为编程这门手艺，正在从“精雕细琢的匠心之作”，慢慢变成“流水线式的工业快餐”。但真正的核心竞争力，永远藏在那些“慢下来”的沉淀里。

五、亲身案例：被AI“反噬”

• 需要具备技能

之前想做一个electron客户端的项目，通过AI Coding，发现客户端electron的代码已经到了非常不可控的地步；因为我不知道后面编码会怎么变化，本质的原因我不会electron，只知道个大概electron的应用场景，发现后面ai一直在重复的无法解决问题时，我根本无法进行审核代码，修改代码。

• 需要底层设计

在做另一个项目时，因为当初后端程序没有编写，只写了前端代码，所以想让前端代码先把请求api接口先开发了，为了模拟数据，要前端做mock数据。这个需求在用AI Coding时，发现它的设计不合理，根本就没有考虑将来能与后端无缝集成，而且没有采用复用的思想进行编码。这个是特别典型的问题，AI在开发时，如果我们自己没有要求AI做一些设计模式，底层架构设计时，AI往往是不会考虑到的，这个时候如果我们不去设计，那后面的代码会变为“屎山”代码

• 重复功能

在写比较简单的功能，批量删除和单项删除时，AI写了2种方法独自去实现，其实可以合并为同一个方法。大概因原有代码过于复杂，AI的单次上下文无法处理，便“偷懒”新建类，导致代码冗余混乱。这个也是AI经常会范的错误

六、正确的打开方式：把AI当作“初级员工”，而非“替代者”

工程师的大脑，对项目代码的掌握程度，必须与AI的使用同步推进。最好的方式，是把AI当作一名“普通程序员”：给它清晰的指令，明确的要求，并且在它完成工作后，进行即时的Code Review。

系统的整体架构的设计，以及采用什么设计模式，底层应该用什么引擎驱动，这个还要自己去设计，要把这个要求给AI。让AI在你的设计范围里面去工作。

比如，你明确告诉它：“去A文件使用已有的缓存机制，在B文件调用封装好的接口，注意全球时区导致的用户问题——C文件中有对应的规避案例，最终实现D功能”。这种情况下，AI生成的代码基本不会有大问题。

但如果你直接把产品经理写的PRD甩给AI，让它在复杂项目中自主实现功能——很不幸，你的项目最终大概率会变成我之前遇到的样子：代码冗余、逻辑混乱、耦合度极高，最后陷入“AI改不动、自己不敢改”的困境。

【AI是强大的工具，它能帮我们摆脱重复劳动，提升效率，但永远无法替代工程师的深度思考、长期沉淀和全局把控。在Vibe Coding的浪潮中，守住自己的核心能力，不被速度裹挟，不被工具反噬，才能在AI时代走得更远、更稳。】