2026年的智能体时代已经过去了四个月，Vibe Coding（氛围编程）这个词也在口口相传。
有人说，编程变成了一项零门槛的工作，曾经被认为最不可替代的程序员也要失业了。
也有人说，Vibe Coding就是个玩具，每次写出来的都是烂摊子（shit mountain），压根取代不了人类。
这些茶余饭后的吐槽，被GitHub上的一次PR拉上了台面，摇身一变成为了一个值得整个AI领域深思的议题：
Vibe Coding到底是不是一场生产力的骗局？
时间回到今年1月，知名的JavaScript运行时环境Node.js的核心贡献者Matteo Collina在GitHub上提交了一个PR，用于给Node.js引入内置的虚拟文件系统node:vfs。
这种底层架构级别的重量级更新，本来应该理所当然地成为社区期待已久的里程碑。
然而，真正引起关注的，却是他在PR描述中坦承的一句话：
“我使用了大量的Claude Code token来创建这个PR，并且已经亲自审核过所有改动。”
令人细思极恐的是，这次PR足足有19000行代码，其中大部分全部由AI生成。
在程序员的圈子中，这就像是往平静的湖面扔下了一颗核弹。
无论是GitHub还是Hacker News，国内外论坛瞬间激起辩论，支持者、中立者、怀疑者、否定者各成一派，众说纷纭。
两个月后，重量级的回应登场了。
Node.js技术指导委员会（TSC）前成员Fedor Indutny发起了一份请愿书，并迅速火爆全网。
《You Don’t Know JS》的作者Kyle Simpson、Zig创始人Andrew Kelley等一众软件工程师大佬接连实名签字，目标只有一个：
要求投票禁止使用大语言模型生成的代码直接重写核心模块。
事情发展到这个地步，已经远远不止于一场关于AI代码质量的争论，它还揭露了一个更深层的职业危机：
Vibe Coding正在全方位挑战传统软件工程的底层逻辑。
01
Vibe Coding的三阶段困境
说起Vibe Coding，第一次见到这个词可能觉得有些奇怪，但亲手使用过就知道这个命名方式其实极为准确。
开发者无需再沉溺于每一行代码语法的精雕细琢，只要描述意图，调整“氛围”，就可以驱动AI代理来实现自己的目标。
与其称之为一项AI时代新诞生的技术，不如说它是AI编程发展到一定阶段时的必然产物。
3年前，在那个OpenAI封禁东亚区IP导致人们只能使用中转的“盗版”ChatGPT-3.5时，为了完成读研期间的课程作业，我试图让AI帮我实现一些最基础的金融数据调用和分析。
那时的AI还很笨拙，数据源的API或是找不到，或是胡编乱造，python语法也是各个版本混用，写出来的代码别说“能用”，连顺利运行都需要若干次调试。
尽管功能实现极不靠谱，但那时的AI编程却有几个令人十分惊喜的闪光点：
第一，它编写代码的思路大体是正确的，这意味着在用户只提供最终目标的情况下，它能选取正确的技术路径；
第二，它的语法、格式和结构是标准的，没有各种新手常犯的原则性错误或是错误拼写、缩进；
第三，它对于python中各种常用库的调用十分熟练，用户需要懂一点python，但完全不用对着接口文档一行行查找。
其实，这就是Vibe Coding的雏形，这些如今看起来不值一提的功能，已经足以让过去的程序员们欣喜若狂。
但现在，对于Vibe Coding的看法却开始两极分化。
视频网站上到处都是用Vibe Coding教人赚钱的教程，可实际使用后的反差感让程序员们吃尽了苦头：
这就是程序员们在各种Coding Agent中最常见的反馈。
在实际的工程落地中，Vibe Coding正面临着一个残酷的“三阶段衰退曲线”：
前期（发展期）：AI展现出惊人的爆发力，能迅速生成逻辑闭环的小型功能或样板代码，也就是三年前的“高光时刻”；
中期（拉扯期）：随着系统复杂度增加，模块之间的耦合越发微妙。此时，人类需要介入，排查AI生成代码中的细微逻辑错误，成本逐渐与人工编码持平。
后期（崩溃期）：随着长上下文累积，AI的指令遵循能力出现断崖式下跌，频繁出现“错的地方没改对，对的地方改错了”的现象。
这也解释了为什么Vibe Coding发展至今，人们的心理落差反而越来越大。
现有的Vibe Coding最擅长的是“实现功能”，而软件工程追求的是“推出成品”。
前者所需的无非逻辑跑通，但后者要求健壮性、可维护性、安全性、架构一致性缺一不可。
Vibe Coding几乎清除了从0到0.5的门槛，但在0.5到1的路上让无数开发者陷入了“生成→混乱→重来”的死循环。
02
当Review变成一种惩罚
Vibe Coding的这种特点，利好了那些完全不懂编程的用户和轻度程序员，但却引起了开源社区的极大不满。
开源社区之所以能够良性运转，核心机制在于一种隐形的社交契约：
我呕心沥血写出来的优雅代码，你出于对专业精神的敬畏进行深度的审查。
这种彼此认真、严谨对待代码的态度，推动了技术的公开和进步。
但是，如果说Vibe Coding是一种无视契约的捷径，那Collina的1.9万行PR就等同于让这一纸契约直接作废。
毕竟，用户自娱自乐Vibe Coding出来的代码对其他人没什么影响，可这1.9万行代码是实实在在要被嵌入到Node.js的底层机制中，并被数以百万计的人们实际应用的。
它在各种各样的应用场景中都不能出错，同时还要兼顾效率，因此必须要经过重重审核才能使用。
一位Hacker News用户的评论一针见血：
按每行代码需要审查2分钟计算，看完这1.9万行需要90个工作日。你动动嘴皮子5分钟生成的代码，要让社区管理员付出3个月的时间来审阅？这不是效率问题，而是对他人的极度不尊重。
Vibe Coding让代码的产出成本无限趋近于token的价格，但审查成本却依然保持线性增长，于是开源社区的审查流程就变成了一种纯粹的“体罚”。
有人会问，为什么不能让AI审查以降低成本呢？
答案是强化学习机制的存在，使得AI在面对Vibe Coding生成的代码时无法学习到任何有用的知识。
而人类审查员面对铺天盖地而来的AI代码模板，同样无法积累任何技能，只能在重复的劳作中耗尽热情。
03
法律的灰色地带与官方的妥协
尽管事到如今Vibe Coding生成的代码已经被大部分程序员和业内人士定义为“烂摊子（shit mountain）”，但必须承认，它的本质仍然是一份代码作品。
而AI生成代码和AI生图、AI配音、AI生视频一样，都不可避免地要面对版权问题。
在美国，司法机构倾向于认为纯AI生成的作品不受版权保护。
这就意味着，如果一个核心项目包含大量AI生成的代码，它可能无法通过现有的MIT或Apache等开源协议进行授权。
为了规避法律风险，Indutny的请愿书中也明确写道：AI的训练数据来源存疑，我们不能让Node.js这种支撑了数百万台服务器的基础设施，建立在偷来的代码和法律的沙堆之上。
在开源社区中，Vibe Coding的代码版权问题还只是争议；但在闭源的商业竞争中，这就是赤裸裸的利益侵占。
面对汹涌的反对浪潮，Node.js的母基金会OpenJS展开了密集的内部辩论。
在Issue Is AI-assisted development allowed? #1509中，双方可谓是针锋相对。
ljharb主张“一刀切”，禁止一切“看起来像AI生成”的代码；而Collina则反击：“在这个时代禁用Copilot或Cursor，无异于摧毁项目的贡献率。”
但结果，大家都已经心知肚明。
毕竟，2026年如雨后春笋般诞生的各种Coding Plan和桌面代理背后的商业利益已经给出了答案。
最后，OpenJS基金会也宣布，允许AI辅助开发。
理由很务实，禁止AI在现实中已经根本无法执行，因为没人能证明一段代码到底是不是人写的。
基金会表示，未来将成立AI工作组，指定IP政策，并为维护者提供处理AI滥用的指南。
04
程序员的傲慢与无私
在这场争论中，有关程序员的两种极端观点也交织在一起。
有人说，程序员是傲慢的。
他们守着多年前手敲代码的习惯，看不起AI生成的烂摊子，拒绝Vibe Coding给不懂编程的人带来生产力的提升。
这种傲慢源于对匠人精神的执着，每一行代码都应该是思考的结晶，精准而优雅。
也有人说，程序员是无私的。
如果少了这种近乎偏执的演进，就不会诞生GitHub这种自愿贡献的开源技术社区。
他们深知自己提交的每一行代码都会成为别人的负担或基石，所以让代码整洁、抽象合理、易于维护都是义务所在，不给别人添麻烦才是开源精神的底色。
Vibe Coding带来的矛盾正在于此：它鼓励开发者快速交付、延后思考，但项目的严谨性要求必须抵制这种未经审视的“平庸”。
Anthropic此前发布的一篇AI相关就业调查报告显示，大部分程序员其实并没有受到AI冲击而失业的影响。
如今看来，未来每家企业内程序员的分工都将被剧烈重塑：
有人会作为AI使用者，使用自然语言指挥AI完成一次性、低风险、可丢弃的任务，比如内部工具和原型设计；
有人会作为代码审阅者和集成者，他们具备“能看懂并纠正AI错误”的核心竞争力，不一定写代码最快，但“兜底”能力一定最强；
有人会作为系统架构师，定义规范，构建那些AI无法预测、需要人类工程判断力的核心架构。
Vibe Coding就像一面镜子，照出了AI在当前复杂工程中的疲软，和程序员在生产力爆炸面前的迷茫。
它带来的趋势不可阻挡，软件工程最终也会演化成一场关于“意图”的概率游戏。
人类唯一不可替代的资产，可能只剩下“对确定性的敬畏”。
至少，在那1.9万行代码背后，想要支撑起这个数字世界，目前还不能只靠token。
热门跟贴