引子

如果你最近用过 AI 写代码，可能会对下面的场景并不陌生：

• 代码不是你写的，你也说不清它为什么能工作，但它确实跑起来了。

你可能没有刻意选择所谓的“vibe coding”，但在某个加班的夜晚、某个赶 demo 的时刻，你已经站在了它的这一边。

如果要追溯 AI coding 真正走入日常开发的时间，大概是在 2023 年前后。 从最初把它当作一个“更聪明的搜索引擎”，到后来可以直接让它生成完整的功能代码，写代码这件事的门槛被迅速拉低了。

在那段时间里，我使用 AI 的方式其实相当保守。更多时候，它只是一个对话窗口： 我会描述一个问题，比如“实现一个 HTTP 协议的标准化器”，然后让模型给出一段实现思路或示例代码。我把代码粘贴到本地，跑一跑、改一改，再带着新的问题继续追问。 在这个阶段，AI 更像是一个随叫随到的助手，而不是代码的真正作者。

变化发生在之后。 随着“快速创造价值”“客户导向”等叙事在一些企业中被不断放大，再叠加管理层对 AI 的过度乐观和人云亦云，开发过程本身也开始被重新定义。效率被无限放大，而工程质量、长期维护这些问题，则被有意无意地后置了。

也是在这样的背景下，我下载并订阅了 Cursor。 从那一刻起，我逐渐发现自己不再像以前那样关心代码结构是否合理、抽象是否清晰。我开始只关注一件事：需求有没有被实现，代码能不能跑。 只要结果是对的，过程似乎变得不再重要。

后来我才意识到，这种状态在技术社区里已经有了一个并不正式、却异常贴切的名字——vibe coding。

本文想聊的，正是这种介于“工程”和“直觉”之间的开发状态，以及它在 AI 时代为什么会变得如此普遍。

vibe coding是什么

什么是vibe-codding，？他和ai codding是啥关系？

说白了，Vibe coding 是一种心态，而 AI coding 是它最常用的外挂。

• AI coding：
  👉 “用 AI 来帮你写代码”（工具、能力层面）

• Vibe coding（更常见写法是 Vibe Coding）：
  👉 “我不太管代码细节，只要感觉对、能跑、能用就行”（心态 / 工作方式层面）

Vibe coding这个词本质上是个 半玩笑、半讽刺 的说法，不是正经技术概念。

核心特征就三点：

1. 不深究实现

   • 不太关心：

     • 架构是否优雅
     • 抽象是否合理
     • 性能是否极致

   • 只关心：
     👉 “现在能不能跑？”

2. 大量依赖直觉 / 感觉

   • “这个库感觉行”
   • “这段代码看起来对”
   • “先 copy 过来试试”

3. 目标导向极强

   • Demo 能不能跑
   • 产品能不能演示
   • 老板能不能点头

所以 vibe coding ≈ “工程理性让位于产出速度”

那它和 AI coding 是啥关系？ AI coding 本来只是工具

比如：

• Copilot
• Cursor
• ChatGPT
• Claude

它们本来是用来：

• 减少重复劳动
• 补全样板代码
• 快速查 API / 写测试

但一结合「vibe」，画风就变成了：

❌「我理解了再写」
✅「AI 你先写，我看看能不能用」

典型 vibe + AI 场景：

“帮我写个能用的就行”
“别解释，先给代码”
“报错了你再改”

这时候：

• 人不再是 设计者
• 而变成了 调参 / 试错 / 拼装的人

举个例子，一个很形象的类比：

传统 coding中，你是厨师

• 懂食材
• 会配比
• 知道火候

AI coding（理想状态）中，你是主厨 + 自动化厨房

• 你定菜单
• 机器干脏活

Vibe coding + AI（现实常见）中，你是外卖点单员

• 看图点菜
• 不问做法
• 能吃就行

为什么最近 vibe coding 特别火？

这里选择知乎上一个高分回答：

• 管理层：无脑吹AI提效，大力鼓励程序员vibe coding

• 底层牛马：能完成需求就行，我也不在意他的实现，中小型公司也没有code review的习惯

总结下来就是：

1️⃣ AI 把「能跑」的门槛拉得太低

• 原来 3 天的 demo
• 现在 30 分钟

于是：

“既然都能跑了，为啥还要纠结？”

2️⃣ 很多场景 本来就不值得精雕细琢

• 内部工具
• 一次性脚本
• 概念验证（PoC）

vibe coding 在这类场景 是合理的

3️⃣ 一部分管理层在「滥用 vibe」

“AI 都能写代码了，架构设计是不是也不重要了？”

然后就会出现：

• demo ≠ 可维护系统
• 能跑 ≠ 能上线
• 现在快 ≠ 以后不炸

为什么感觉vibe coding让程序员越来越浮躁了？

现在回头看，我大概已经算是 vibe coding 的重度使用者了。 一开始是 Cursor，后来变成了 GitHub Copilot、Claude Code（号封了）、Codex 混着用。工具在不断升级，模型也越来越强，但有一个变化我越来越清楚——我自己反而变得浮躁了。

最早用 AI 的时候，其实状态还不错。 它更多是帮我写一些局部代码、零碎逻辑，核心思路和关键实现还是我自己来完成。那时 AI 像是一个效率放大器，人和工具之间的配合是有边界的，用起来也挺舒服。

后来情况变了。 当模型已经可以从零开始生成一个不算小的项目时，开发方式也随之发生了变化。至于代码质量、架构是否合理，往往不是第一关注点，只要最终能跑起来，似乎就已经达标了。

再往后，我开始意识到一个有点尴尬的问题： 既然这些事情 AI 都能做了，那我到底在做什么？

实际上，角色被压缩成了三件事： 先把需求描述清楚，等 AI 写完之后做测试，再配合它一起修 bug。 曾经作为程序员最核心的那部分工作，正在悄无声息地消失。

更麻烦的是，剩下的这些事情本身并不有趣。需求设计、测试、改 bug，本来就不是最让人兴奋的环节，它们很难带来手写代码时那种掌控感和反馈感。 有时候，面对 AI 一次性生成的一大坨代码，我甚至连完整测试的耐心都没有。

而且你心里很清楚： 这类代码里到底埋了多少隐患，未来还能不能扩展，其实是说不准的。它更像是一次性产物，而不是一个可以长期演进的系统。

所以现在回过头来看，我确实变得比以前浮躁了。 至少对我来说，这不是某种进步，更像是一种需要被认真对待、甚至需要“矫正”的状态。

AI coding 在生产一次性代码

很多时候，我会对着一段刚生成完、甚至已经成功跑起来的代码，产生一种很难形容的感觉——它有一种明显的“一次性代码”的味道。

这种味道并不来自某个具体的 bug，也不一定体现在糟糕的性能上。相反，它往往运行正常，功能齐全，甚至在当前场景下表现得相当可靠。问题在于，你几乎无法判断它还能承受多少变化。

你不知道下一次需求调整会不会牵一发而动全身，也说不清它是否真的具备被扩展、被重构的基础。代码像是为了回答某一次提问而存在，而不是为了参与一个长期演进的系统。

更微妙的是，当你意识到这一点时，往往已经失去了深入理解它的耐心。你清楚地知道，继续往里读下去意味着大量的时间投入，而这些时间很可能并不会带来相应的回报。于是，这段代码就被默认成了“暂时可用”的状态。

从这个意义上说，它并不是写给未来的代码，而更像是一种即时产物——解决了当下的问题，却并未真正打算陪你走得更远。

手动 coding 其实并不痛苦

后来我逐渐意识到一个被长期忽略的事实：

• 对大多数程序员来说，手动 coding 本身其实并不痛苦，甚至称得上是有意思的。

真正让人感到疲惫的，往往并不是写代码这件事，而是围绕代码之外的那些事情——无休止的会议、模糊不清的需求、反复拉扯的沟通，以及为了对齐而消耗掉的大量注意力。

“提升开发速度”这个目标，更多时候并不是来自程序员自身的焦虑，而是来自管理层的期待。对个体开发者来说，只要一天坐在工位上，八个小时是确定存在的成本，与其在这些时间里被拆散在各种讨论和对齐中，不如把它们连续地投入到 coding 里。

至少在 coding 的过程中，输入和输出是明确的，反馈是即时的，注意力是可以被完整使用的。那是一种少有的、可以真正掌控节奏的工作状态。

从这个角度看，写代码并不是问题，问题只是我们越来越少被允许安心地写代码了。

当程序员变成"产品经理"

最近这段时间我的代码几乎 全由 AI 写，出错了就把报错贴给它，让它 全盘改。我等它改，我玩手机，特别爽。改完不看代码直接运行，没报错，检查页面也实现了功能。然后继续下一个业务，完全不管代码，就像个 产品经理。

但是最后的结果让我 吃了一惊——我一次出现了 非常严重的问题，无论怎么换 prompt，AI 都 无法解决。最终我只能人工上手，深入查看代码才发现问题所在：五个类管理同一个事情，不同版本的同一个实现满天飞。

• TaskManager 第一版本，后面更改加了新东西减了很多
• 它直接创建了 Simple TaskManager
• 第三版本，它创建了 Unified TaskManager

也就是说，已经不在 TaskManager 上更改，因为它变得 极其复杂，AI 一次的 context 无法解决。前端 UI 很多直接调用底层逻辑，而没有使用 AI 自己写好的封装工具代码。问题巨多，这个时候我才 真正醒悟。

我意识到，在 AI 还不依靠分段式独立指令、多轮对话、短期记忆的推理之前，工程师 不可能不接入，也不可能不协同开发。所有要在深入业务层做得很完善的 “纯 vibe coding”，都是 不现实的。

现阶段，AI 推理的本质是 通过你这一次给它的输入生成结果。即使是多轮对话，也是靠把 完整的多轮内容喂给它。就算你加上各种 RAG 技术提前检索相关文件和代码引用，本质上，在 这一次推理中，你必须提供它所需要知道的所有信息，才能得到合理结果。

问题很明显。现在 AI coding 的解决率一直在上升，原因在于 模型能力越来越强，context 越来越长，它能够在复杂的代码中找到自己想要的答案。

但始终，AI 不能在整个产品周期具有人类一样的长期记忆。

工程师可以在 三个月内清楚地知道自己项目每一块怎么实现，也知道加入新功能时哪些代码可能会有联动效应。超过三个月的代码，别说 AI 了，我自己都得 花上几天才能完全理解。

但 AI 不行。如果你不给它这次改动所需的 关键逻辑，它一定会按照自己认为合理的方式去实现，忽略已有模块和功能。

我现在还用 Cursor，是因为它做了 codebase indexing，我能感知到一个任务它对源代码的匹配程度和兼容性比其他工具高。但即便如此，这个问题仍然存在。

所以，工程师对项目代码的掌握 必须同步跟上，最好把 AI 当成 初级员工：

• 给它 清晰的指令
• 进行 即时 code review

例如，你交给它去 a 文件使用已有缓存，b 文件调用已有接口，注意全球时区导致的用户问题，这一点在 c 文件有例子如何避免，实现 d 功能。这样写出来的代码 基本没什么问题。

但如果你直接在项目里甩给它一个 产品经理写的 PRD，很不幸，你的项目 最终大概率会一团糟。

甚至会变成这样：

当你觉得"我用AI效率提升了3倍"的时候，可能只是你"觉得"而已。

针对管理层想要的**“快速产生价值”**，其实我想问：Vibe code写码不用人看，为何不直接写C或汇编，省掉中间语言（Python、Rust等）挣差价？

庆幸的是，Vibe coding没那么强。它的深意是，如果Vibe coding成功了，基本上就是先消灭除了C系和汇编以外的所有语言。也就是说，现在的LLM根本不需要什么“人类友好的语法糖”，高级语言为了让人读懂而设计的特性，在AI眼里简直是多此一举。

然而结论是：别用C做Vibe coding，真的坑！天坑！

不是说C太难，而是你选语言必须给LLM一个**“纠错反馈循环”**。Rust的编译器会不停提示错误直到改对，Python报错至少不会炸掉内存——但C呢？它默默埋雷，等你上线再给你惊喜。

那有人真的成功做过Vibe coding吗？有，而且有些案例真的离谱。有个大佬用Claude Code配合Opus 4.5，搞了个叫bipscan的东西——扫描公开文本找隐藏的比特币种子短语。用的是Ruby+C+Shell。性能数据看了都傻眼：

• 4分钟扫完12G的pg19文本语料库
• 生成6400多万个候选种子短语
• 并行检查器跑到每秒460个派生地址

还有一个Rust+Python的icon-to-image工具，Rust写核心逻辑，Python做接口绑定，用的是Opus 4.5。也就是说，即便是上古技术栈，Vibe coding仍然可以做到。

但是！翻车案例同样一大堆。

用LLM完成一个简单任务，无论怎么调prompt、怎么指定版本，LLM就是一本正经地编造不存在的函数。训练数据根本没有足够的示例，LLM只能瞎编。

总之，LLM不是不会骗你，而是它骗你的时候特别自信。而最可怕的是，这过程非常浪费时间——全部浪费在排除错误和澄清问题上！

Vibe coding一开始可能还行，试一试就好，但一旦上手，你就上了不归路。发现大把时间花在写给AI“澄清说明”上，等agent跑完再写新的修正，这种start-stop节奏就像刷短视频，让人根本无法深度思考。与其这样，不如回归手动编程，只把无聊的小任务丢给ChatGPT或Claude code。

不仅开发中是这样，学术上也类似。比如arxiv论文2507.09089指出，开发者对AI辅助编程的主观印象和客观测量差距巨大。换句话说，当你觉得“AI帮我效率提升了3倍”时，可能只是你**“觉得”**而已。我自己也经常觉得AI帮了大忙，但实际产出到底多少……真不敢深想。

实际上，只要你不把小quirks、bug处理、写给自己看的注释全外包给LLM，Vibe coding还是可以用的。它能干活，但不能全干。否则你会陷入一个既向前又要向后的二难推理。到了这时，你必须找到平衡点——Vibe coding能干的事十根手指都能数得完。否则，很多语言或项目根本无法胜任。

截至2025年12月，Vibe coding无法写好简单语言的项目，更别提C或者汇编了。C能写吗？简单的能，但最好不要——C是vibe coding的高危选项，训练数据里全是坑。C语言历史悠久，LLM不知道它埋了多少坑。看看Chromium项目的数据，Google顶级C++工程师都能在代码里埋内存炸弹。LLM在海量C代码上训练→学到大量错误模式→生成的代码大概率也有问题。这不是AI不够聪明，而是统计学习的必然结果。

就算是Pegasus恶意软件、Zerodium、Windows零day、Chrome零day……这些都是专家写的C/C++代码里的祖传屎山代码。顶级专家都可能出错，你凭什么相信LLM能比他们强？

不过，Vibe coding还是可以写C和WebAssembly的。我知道的例子里，simonw用GPT写过SQL扩展，实验可行，但上线必须慎重。还有人成功做了Windows托盘小工具，体验“exhilarating”，但他只能玩玩，并放狠话：看不懂就别碰。换句话说，Vibe coding写什么都行，但千万别全外包给它。

用Vibe coding最爽的是Rust，因为Rust编译器的反馈循环非常适合LLM——它会告诉LLM哪里错、怎么错，LLM就能改到编译通过为止。Rust的错误信息是**“designed for humans”**，详细到LLM能理解并修正。

而动态语言出了问题，只能靠测试慢慢试错。Rust in Android案例显示，用Rust省下了处理内存bug的时间，这些时间可以花在修复逻辑错误上，非常有价值。

所以企业级案例里，最佳组合是：Rust写核心逻辑 + Python做接口绑定。理由如下：

• Rust的强制正确性能拦住一大堆bug
• Python的REPL方便快速验证
• 每个PR都附带demo notebook确认功能

总的来说，LLM理解复杂系统没问题，但前提是你给它足够的上下文。

如何看待现阶段坚持不用 AI 的 「古法编程」？

最近冲浪的时候发现，好多码农还在坚持不使用ai工具进行编程，这里采用知乎的一个高赞回答：

---

我算是从VSCode用到Cursor，再到Claude Code一路跟过来的用户，对AI编程的看法几经反转。尤其是Claude Code推出之后，我在第一周就开了git worktree同时做了四个新feature，完全vibe coding。调试居然还挺顺利，我大喜过望——我一度觉得我可以当产品经理了，技术的事全部交给Claude Code就行。

然而好景不长，下周我开发下一个功能时就不行了。我发现AI写的逻辑并不是最优的，有很多逻辑奇怪、冗余的地方，直接导致下一个功能几乎无法开发。我不得不重构上一次AI生成的代码。由于生成的代码大量我看不懂，我必须花很多精力去理解，这对我的要求非常高。花了不少时间后，项目才得以继续。

吃一堑长一智之后，我决定每一次AI的提交都要用眼睛看。这样屎山的问题就不严重了，但我意识到一个矛盾：我开始丢失了编程的感觉，把自己当成了技术经理或者产品经理。而现阶段的AI编程更像一个实习生，不逐行review根本不行，这就要求我必须非常懂编程！实际上，review别人的代码有时候比自己构思还难，所以网上才会有人说vibe coding反而更累。

我戏谑地总结了这个矛盾：如果我不古法编程，就没办法给出好的prompt，AI coding就会失败；如果我古法编程了，那我为什么还需要AI呢？

另一个困难来自等待时间：通常AI生成代码需要1-2分钟，不长不短，无论是去看课还是刷短视频，都可能让思维断片。我很难相信长此以往，我有能力review AI生成的代码并掌控一个复杂项目。

经过一段时间的尝试，我慢慢摸索出了和vibe coding相处的门道，总结出了绝对可以做的事和绝对不能做的事：

可以做的事：

1. 解决bug：AI在搜索关键代码、确定root cause方面非常有用，而且解决bug不会产生太多屎山，人工fix可能几行代码就够了。
2. 讨论新feature的原型：全栈开发时，我有灵感但没头绪落地，可以开新branch，让AI生成UI原型，点一点玩一玩就有新思路。
3. 确定架构：AI可以帮我讨论架构，规定关键函数签名、核心数据结构。
4. 修改视觉UI：各种flex设计、CSS规范，AI非常好用。
5. 小型重构：比如把几个方法抽象成新的模块，AI通常能完成得不错。
6. Code Review：代码写出来后，让AI对已有代码提意见，效果很好，有时能发现隐藏问题。

不能做的事：

1. 不要完全依赖AI，否则会失去对程序的理解。
2. 不好好用git commit/branch。
3. 编程新手不要vibe coding，无法把握。
4. 不要在等待代码生成途中刷短视频。
5. 不要认为编程会被AI取代，否则会懈怠学习技术。

通过这段时间的实践，我发现了一些古法编程不易察觉的优点：

1. 古法编程让大脑更专注：相比AI编程让大脑浮躁，古法编程容易进入产品思考状态，越用越强大、越有精神。我不相信思想上懒惰浮躁的程序员能做出好项目。
2. 古法编程带来更好的prompt：AI编程的结果和prompt质量正相关，要给出好prompt，前提是我充分理解代码。
3. 理解下一个抽象层有益：CSAPP开篇提到抽象很好，但必须理解CPU、内存的运行方式。对项目而言，AI生成的代码必须理解，文档只是辅助，代码+注释才是source of truth。
4. 理解实现有助于新idea：了解数据库表结构、API，就像乐高积木一样，可以组合出新的功能。
5. 番外：不刷短视频时，我建议用草纸设计核心数据结构和方法，或者整理数据调用链条，AI生成后再和它讨论，检查是否按设计实现。

总的来说，古法编程+AI编程的平衡很重要。目前我的古法编程比例比写这篇答案时更高，Cursor重新成为我的主力IDE，Tab仍是我用得最多的AI编程功能。

---

我一直觉得这两条观点特别有意思，也很现实：第一条是，“让不懂代码的客户去问AI，开口就是：‘帮我做个淘宝，帮我做个抖音’。”这句话听起来有点夸张，但其实揭示了一个核心问题——如果你不懂技术，就很容易把AI当成万能工具，直接丢出一个巨大的、模糊的需求。第二条是，“副驾驶就是副驾驶，让它当主驾就别怪它往海里开了。”这句话用比喻说出了AI在开发中的真实定位：AI只能作为辅助工具，不能完全代替人的决策和判断。

结合起来理解就很有意思：客户一上来就想让AI“全权驾驭”，实际上就是把副驾驶当成主驾驶，这很容易导致偏离目标、浪费时间，甚至产生一些完全不符合预期的结果。AI可以帮你加速开发、自动生成代码、解决重复性问题，但它不能理解业务全局，也不会替你做出权衡。只有当你明确需求、掌握方向，把AI当作副驾驶使用，而自己保持主驾位置，才能真正发挥它的价值，而不是被它带着“往海里开”。

你真的得承认程序员的“懒惰”天性——只要有捷径，大家肯定会走。AI生成代码的速度确实惊人：描述需求五分钟，生成代码一两分钟，再调试三分钟，总共十分钟就能完成一套代码，比任何顶级程序员手动敲的速度都快得多。但别高兴太早，真把这些代码直接丢进自己的系统里，运行看看就会发现麻烦接踵而至。擦屁股、找bug，可能要花上两小时，甚至更多。相比之下，自己一步步写出来的代码，不仅更稳当，也省得后续被“AI遗留的问题”折腾。AI可以帮你加速，但它绝不是最终的解决方案，尤其在涉及复杂系统和业务逻辑时。

结尾

说实话，我并不是在贬低 AI coding，而是想强调它在现实中的局限和风险。现阶段的 AI coding 还无法像人类工程师那样真正理解项目。它生成的代码，更多是依赖已有项目、已有模板或者 prompt 约束神经网络的输出，而不是对业务逻辑、架构和长期状态的理解。例如，如果你问一个通用模型“say hi”，它可能输出 "hi"；但问一个 coding 模型，它会输出 print("hi")。这背后体现的是模型所谓的“思考机制”——实际上，这只是模板里加了一个 <think></think> 标签，让模型先生成一段文字作为“思考填充”，再用这段文字约束后续代码输出，而并非真正理解业务或逻辑。

这种机制带来的问题非常明显：非专业人员会误以为模型有自主思考能力，而模型的“思考”只是表面文字，无法真正判断哪个方案可行或者最优。再比如，当你给 AI 一个复杂功能需求时，它会根据训练数据和 prompt 进行拼凑，但可能完全忽略已有模块的接口约束或者项目整体架构。这就导致生成的代码逻辑奇怪、冗余，甚至隐藏 bug，需要工程师花大量时间去理解和重构。

除此之外，AI coding 还存在一些普遍问题：

1. 幻觉（Hallucination）：模型会自信地生成不存在的方法、库、API，甚至引用不存在的论文。比如你要求它操作某个框架的新功能，它可能凭空捏造函数名、参数和使用方法，即使你指出错误，它仍会继续自信输出。
2. 上下文长度限制：当项目代码复杂或者 prompt 太长时，模型会进行剪枝或摘要操作，这不可避免会丢失关键信息。例如多文件项目的函数调用链或类的继承关系，模型可能无法完整处理。
3. 权重滞后与训练集局限：模型只能生成它训练过的模式，当面对新的框架、库或特殊业务逻辑时，它无法自己“学习”，只能泛化已有模式，这种泛化往往带来逻辑错误。
4. 调试和排错能力有限：AI 可以生成代码，但它不会主动考虑测试覆盖、异常处理或边缘场景。你可能得到一段在示例数据上能跑的代码，但上线后出现崩溃、性能问题或安全漏洞的概率很高。
5. 难以理解长期状态和历史版本：人类工程师可以追踪项目几个月甚至几年的代码逻辑，理解新增功能对已有模块的影响；AI 只能依赖一次推理的上下文，很难处理跨版本、跨模块的整体影响。
6. 学习成本与依赖陷阱：虽然 AI 可以快速生成代码，但要让生成结果可用，仍需要工程师对生成的代码进行 review。如果完全依赖 AI，工程师可能失去对项目的掌控，最终增加维护成本。

总的来说，AI coding 可以大幅提升低级重复任务的效率，提供原型和灵感，比如生成 UI 原型、抽象小模块、辅助 refactor、做基础 Code Review 等。但它无法替代工程师对项目整体架构、业务逻辑、异常处理和长期维护的理解。

我们不是抵制 AI，而是希望对它有更合理的预期：AI coding 目前更像一个高级辅助工具或初级实习生，它能加速开发，但不懂业务、不懂上下文、不懂历史。真正驾驭 AI coding 的，是那些经验丰富、理解项目细节、懂得如何设计 prompt 的工程师。只有人机结合，才能让 AI 的效率优势真正落地，而不会陷入“表面快、内里乱”的陷阱。