Vibe Coding 时代学习编程还有意义吗？
2023 年初，Andrej Karpathy 在一条推文里写道："The hottest new programming language is English." 那条推文转发了几万次，但大多数人把它当成一句玩笑。
两年后，这已经不是玩笑了。
而在这个节骨眼上，我这种叛逆基因爆炸的人第一个想到的事情是应该学个新的编程语言玩玩了。比如我从来没好好玩过 JavaScript 和 Go，我从小喜欢的就是 C 和 Linux 底层相关的原理性质的东西，上一个好好玩的语言还叫 Ruby。当时 Ruby 标榜的是一个非常先进且优雅的设计哲学：用尽可能接近人类自然语言的表述方式创造一门编程语言，如今这个理念很好地被这个时代迭代实现了。
于是我去 YouTube 上丢了几个关键词：2026 , learn programming, worth it? 能出来一大堆 Content Creator 在讨论这个问题，那就是现在学编程到底还有没有意义。
一、"Vibe Coding"到底是什么
"Vibe Coding" 这个词由 Andrej Karpathy 在 2025 年初正式提出，指的是一种完全用自然语言驱动 AI 生成代码、不去细读甚至不理解生成代码的开发模式。你描述你想要什么，AI 生成，你运行，出错了继续描述，直到跑通。
这个定义里有一个关键词容易被忽略："不去细读甚至不理解"。
这不是说 AI 辅助编程，那早就存在了（从自动补全到 Copilot）。Vibe Coding 特指的是那种完全的黑盒依赖：不需要读懂代码，不需要理解为什么这样写，只需要结果能运行。
这个定义拉开了辩论的真正战线——不是"要不要用 AI"，而是"要不要理解你用的东西"。
二、"编程已死"这一派，说的有什么道理？
这一派的核心论点不是"AI 很厉害"这种废话，而是在说一件更有意思的事：编程语言本身就是历史的偶然，而不是必然。
NVIDIA CEO 黄仁勋在多个公开场合表达了这个观点：未来的技术门槛不会是 C++ 或 Java，而是生物学、金融学、制造工艺这类真实世界的领域知识（Domain Knowledge）。人类语言，而不是形式语言，将成为驱动计算的原生接口。
前哈佛计算机科学教授 Matt Welsh 在他的博客里走得更远。他认为，编程语言之所以存在，是因为传统的 CPU 和操作系统是"愚蠢的机器"——它们无法理解人类意图，所以需要一套精确的中间语言来做翻译。但 LLM 在某种意义上是一种新型的计算引擎，它的"原生指令集"就是 Token 序列，也就是自然语言。SudoLang、DSPy 等早期探索已经在尝试让 AI 直接作为运行时来执行逻辑，跳过 Python 这个中间层。
更实用层面，这一派还有一个有些刺耳的论点：代码本身的价值正在归零。 如果 AI 能在 10 秒内重写一个模块，那"代码可维护性"和"代码质量"就变成了边际成本极低的问题。当重写比维护更便宜，"屎山代码"的概念本身也就失去了意义。
这些论点都有其内在逻辑，不应该被轻易嘲笑。
三、但它们都回避了同一个问题
把这三个论点放在一起看，发现它们共同忽略了一件事：它们描述的都是"已经成功运行"之后的世界。
黄仁勋描述的是：你用自然语言下达指令，AI 精确执行，系统正确运行。
Welsh 描述的是：LLM 作为运行时，正确理解你的意图，输出正确的结果。
"代码是消耗品"描述的是：AI 重写后的代码，仍然能正确跑通。
这些图景有一个共同的前提假设：AI 是可靠的执行者，"正确"这件事是有保证的。
但现实是 AI 生成的代码会产生幻觉。它会用看起来合理但实际上不存在的 API。它会把两个相似的函数签名混淆。它会在处理边缘 case 时静默失败，不报错，只是悄悄返回错误的结果。它不会告诉你它有多少把握，因为它没有"把握"这个概念。
所以，"验证 AI 是否正确"这件事，就成了整个系统里最关键、最无法被 AI 自身解决的环节。
而做这件验证工作，需要的恰恰是技术理解能力。“出错”这种事几乎不会因为技术得不断迭代而完全杜绝。
四、"开心路径"陷阱：为什么非技术人员做不了生产级产品
技术博主 Philipp Lackner 提出了一个概念，我觉得是目前关于 Vibe Coding 讨论里最清晰的一个切割点：Happy Path 和 Unhappy Path。
所谓"开心路径"，是指用户完全按照系统设计的预期行为操作的流程。比如：用户打开 App，输入合法的邮箱，密码满足要求，网络正常，服务器响应正常，操作成功。
Vibe Coding 通常能把开心路径做得相当好，甚至相当快。问题在于，真实世界几乎不是开心路径。
真实世界是：用户在 3G 网络下提交表单，中途断网了，同一条数据被写了两次。用户输入了包含特殊字符的密码，后端没有正确转义，SQL 注入了。用户的账户余额在高并发的抢购下被扣成了负数，因为你没有处理竞态条件（Race Condition）。用户上传了一个 10GB 的文件，你的内存溢出了。
这些不是刁钻的攻击，这是正常的业务现实。一个懂技术的工程师在设计 API 接口时，脑子里会自动过滤一遍：这个参数有没有边界？这个操作是不是幂等的？这里有没有竞态风险？
不懂技术的人做不了这个心理过滤，因为他们根本不知道"竞态条件"是什么，也不知道"幂等性"意味着什么。他们唯一的反馈机制是"功能跑通了/没跑通"，而缺少"功能是不是安全的"、"是不是在所有情况下都正确"这两个维度的判断力。
所以 Vibe Coding 的天花板非常清晰：它可以让你快速做出演示（Demo），但它无法保证你做出的是一个可以交付给真实用户的产品（Product）。
五、能力幻觉：一个更深层的认知陷阱
Tech With Tim 观察到一个让我觉得相当准确的现象：过度依赖 AI 正在制造一种"能力幻觉"，正好前两天也有一个 YouTuber 抨击 AI 让现在的各路 CEO 出现各种不小的"能力幻觉"。
具体表现是：一个初中级开发者把 AI 给的代码 copy-paste 进去，功能跑通了，他会产生一种"我会这个了"的感觉。但如果你问他：为什么用 Redis 而不是 Memcached？这里为什么要加索引？这个 async/await 是什么意义？他说不出来。
这不只是个人学习的问题，这在团队里会形成一种更隐性的风险：没有人真正理解系统，但每个人都以为系统没问题。
这种状态有一个专门的词叫"Cargo Cult Programming"——像二战时期太平洋岛民模仿飞机起降来"召唤货物"一样，只模仿了表层行为，完全不理解背后的因果逻辑。
AI 时代的 Cargo Cult 更危险，因为它包装得更像真实能力。代码能跑，功能能用，测试能过，但这一切都建立在一个沙基上：没有人能在系统出问题时真正诊断问题。
六、底层原理：在 AI 时代变贵了，不是变便宜了
现在回到底层原理的价值。
例子一：内存管理
一段典型的 Vibe Coding 生成的 Python 数据处理代码，可能会在循环里反复创建大型的 Numpy 数组而不释放，导致内存占用随处理量线性增长，最终在生产环境里把服务器内存吃满。
这个 bug 不会在本地开发环境里复现，因为数据量小。它只会在真实的生产负载下出现。
AI 生成这段代码时完全合理——每一步逻辑都对。但懂 C 内存管理的工程师会下意识地问："这个对象在什么时候被释放？"他会做 profiling，会用 tracemalloc，会找到这个内存泄漏。
不懂内存概念的人，甚至不会意识到这是一个需要问的问题。
例子二：并发与竞态条件
AI 写的数据库操作代码，通常是先查询余额是否充足，再扣减。这在单线程下完全正确。但在高并发的场景下，两个请求可能同时通过了余额检查，然后同时扣减，导致余额变为负数。
这是一个经典的"检查-操作"竞态（Check-Then-Act Race Condition）。修复方式需要懂数据库事务隔离级别、乐观锁或悲观锁的选择。
一个不懂并发原理的人，即使 AI 生成的代码在功能上完全正确，他也无法意识到这个系统性风险的存在。
例子三：安全边界
AI 生成的代码通常会尽量满足你的需求，这意味着它有时候会生成过于"方便"的实现——比如直接把用户输入拼接进 SQL 查询，或者在 URL 参数里传递用户 ID 而不做服务端权限验证。
如果你不懂 SQL 注入的原理，你不会在 code review 时 catch 这个问题。如果你不理解水平越权（IDOR）的概念，你不会意识到"用户可以通过修改 URL 里的 ID 来访问他人数据"这个逻辑漏洞。
这些安全知识很难通过 Vibe Coding 习得，因为 AI 不会主动警告你它生成的代码存在安全风险，除非你明确知道要问这个问题。
七、那么，我们到底该学什么？
这是最关键的问题，也是争论双方都在回避的问题。
我调研下来大多数硬核技术博主的答案是：学编程的目标，从"产出代码"转向"理解系统"。
具体来说，这意味着：
一、不要跳过算法和数据结构。 不是因为你需要手写红黑树，而是因为理解时间复杂度让你在面对一个 O(n²) 的嵌套循环时能感知到风险。理解哈希表让你知道为什么某些操作是 O(1) 而不是 O(n)。这些概念是和 AI 协作时的沟通语言。
二、一定要学操作系统基础。 进程、线程、文件描述符、信号——不是为了手写操作系统，而是为了在 AI 生成的代码出现奇怪的系统行为时，你能理解问题出在哪一层。
三、亲自动手写一些 C。 不是作为主要工作语言，而是为了让"内存是有限的物理资源"这件事变成你的本能认知，而不只是一个你知道的事实。写过指针，你才会真正理解 Python 的 GC 帮你做了什么，以及它没帮你做什么。
四、学会在不依赖 AI 的情况下调试问题。 会用 gdb、strace、tcpdump 这些工具，不是因为 AI 不能帮你调试，而是因为在最关键的时刻——生产环境崩溃、数据正在丢失——你需要能独立行动，而不是等 AI 给你答案。
五、建立安全意识。 OWASP Top 10 不是一份备考清单，而是你和 AI 协作时应该持续追问的问题列表。
换句话说，我认为编程教育和学习的重心应该从很早被技术圈骂了个遍的"北大青鸟"式打字员培训转向真正理解系统和事情到底是怎么运转起来的“卡耐基梅隆古法教育”。
八、对不同人群的不同建议
这个问题对不同的人，答案其实是不一样的。
如果你是想转行的非技术人员： Vibe Coding 确实大幅降低了门槛，你现在可以构建很多以前需要团队才能做的东西。但你应该把节省下来的时间投入到理解计算机基础概念上，而不是全押在 prompt 技巧上。你的护城河是"懂业务 + 有技术审美"，而不只是"会描述需求"。
如果你是初学编程的学生： 这是最需要抵抗诱惑的阶段。用 AI 来加速理解某个概念是好的，但在你真正理解之前就把代码生成出来交差，是在欺骗自己。你在这个阶段积累的是日后判断 AI 输出质量的能力，不要用短期的"交付感"换掉它。
如果你是有经验的工程师： AI 对你的增益是最直接的，因为你有足够的判断力来验证 AI 的输出。你现在面临的真正问题不是"要不要用 AI"，而是"如何在使用 AI 的同时保持深度技术能力的锐度"。定期做一些不依赖 AI 的代码实践，是值得的。
非常简单暴力的用一句话来总结就是：理解程序员为什么从0开始数数这件事对你有多重要？
结语：从翻译官到审判官
有一个关于自动驾驶的讨论可以作为这篇文章的注脚。
自动驾驶技术越来越强之后，有人提出：既然 AI 开得更好，为什么还要让人类保持驾驶技能？但后来研究发现，当自动驾驶遇到它无法处理的边缘情况需要接管时，长期不开车的人类司机的接管表现极差——他们已经失去了状态感知能力。
代码也是一样。
AI 会越来越好地"开车"，但边缘情况永远存在。那个能在系统崩溃时接管、在安全漏洞出现时判断、在架构决策时拍板的人，仍然需要在底层有真实的能力积累，而不只是会说"帮我继续开"。
过去学编程，是为了成为机器的翻译官。现在学编程，是为了成为系统的审判官。
翻译官的工作正在被 AI 接管，但审判官的席位，AI 离坐上去还很远。
本文创作构成
| 构成 | 占比 | 说明 |
|---|---|---|
| 🖊️ 人工调研与写作 | 25% ████░░░░░░░░░░░░ | 选题、资料整理、核心观点 |
| 🤖 Claude | 40% ██████░░░░░░░░░░ | 内容扩写、结构优化 |
| ✨ Gemini | 30% █████░░░░░░░░░░░ | 初稿调研、素材整理 |
| 👁️ 人工审核 | 5% █░░░░░░░░░░░░░░░ | 事实核查、最终校对 |
