第十一章:什么是氛围编程(Vibe Coding)#
mindmap
root((氛围编程的诞生))
Vibe Coding定义
Karpathy 2025
自然语言编程
拥抱指数增长
核心理念
意图优先
AI执行
快速迭代
与传统编程对比
编码方式变化
技能要求变化
工作流变化
适用场景
快速原型
个人项目
探索学习
争议与讨论
质量担忧
技能退化
民主化编程
历史定位
编程范式演进
第四次变革
I just see things, say things, run things, and copy-paste things, and mostly it works.
—Andrej Karpathy, 2025 年 2 月
11.1 一条推文引发的范式讨论#
2025 年 2 月,前特斯拉 AI 总监、OpenAI 联合创始人 Andrej Karpathy 在社交媒体上发布了一条看似随意的帖子,却在整个软件工程界掀起了轩然大波。他写道:
There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. I just see things, say things, run things, and copy-paste things, and mostly it works.
有一种新的编码方式,我称之为"氛围编程"(Vibe Coding),你完全沉浸在氛围中,拥抱指数级增长,甚至忘记代码的存在。我只是看着、说着、运行着、复制粘贴着,而且大部分时候它都能工作。
这条帖子迅速获得了数百万次浏览,引发了开发者社区激烈的讨论。支持者认为这是编程民主化的里程碑,反对者则担忧这是对软件工程专业性的亵渎。无论立场如何,所有人都不得不承认:一种全新的编程范式正在悄然兴起。
11.1.1 Karpathy 的背景与可信度#
要理解 Vibe Coding 这一概念的分量,我们需要了解提出者的背景。Andrej Karpathy 并非一个不懂编程的外行人——恰恰相反,他是深度学习领域最具影响力的研究者和工程师之一:
斯坦福大学博士:师从计算机视觉大师 Fei-Fei Li,研究深度学习与计算机视觉
OpenAI 联合创始人:参与了 GPT 系列模型的早期研发
特斯拉 AI 总监:领导了特斯拉自动驾驶(Autopilot)的视觉系统开发
顶级程序员:其开源项目 minGPT、nanoGPT 被广泛使用和引用
当这样一位顶级技术专家说"我不再真正编码了",这不是因为他不会编码,而是因为他发现了一种更高效的方式。这正是 Vibe Coding 概念如此震撼的原因——它来自一个最有资格谈论编程的人。
11.1.2 时代背景:为什么是 2025 年#
Vibe Coding 的出现并非偶然,它是多个技术趋势汇聚的必然结果:
技术趋势 |
关键进展 |
|---|---|
大语言模型能力飞跃 |
GPT-4、Claude 3.5 Sonnet、Gemini 等模型在代码生成方面达到了前所未有的水平 |
AI 编程工具成熟 |
Cursor、GitHub Copilot、Windsurf 等工具从"补全"进化到"生成" |
上下文窗口扩大 |
从 4K 到 200K tokens,AI 可以理解整个项目的上下文 |
多模态能力 |
AI 可以从截图、草图直接生成代码 |
Agent 能力涌现 |
AI 不仅能写代码,还能运行、调试、修复代码 |
11.2 Vibe Coding 的定义#
11.2.1 核心定义#
氛围编程(Vibe Coding) 是一种以自然语言为主要交互方式的编程范式,开发者通过描述意图和需求,让 AI 生成、修改和调试代码,而开发者的角色从"代码编写者"转变为"意图引导者"和"结果验证者"。
用更通俗的话说:
你告诉 AI 你想要什么,AI 帮你写出来,你看看对不对,不对就再说说哪里不对,直到满意为止。
11.2.2 Vibe Coding 的核心特征#
我们可以从以下几个维度来理解 Vibe Coding 的本质特征:
1. 自然语言优先(Natural Language First)
在 Vibe Coding 中,自然语言取代编程语言成为主要的"编程"工具。开发者不再需要记住语法细节、API 签名或框架约定,而是用人类语言描述自己的意图。
# 传统编程:你需要知道 Flask 的 API
from flask import Flask, jsonify, request
from functools import wraps
import jwt
import datetime
app = Flask(__name__)
app.config['SECRET_KEY'] = 'your-secret-key'
def token_required(f):
@wraps(f)
def decorated(*args, **kwargs):
token = request.headers.get('Authorization')
if not token:
return jsonify({'message': 'Token is missing!'}), 401
try:
token = token.split(' ')[1]
data = jwt.decode(token, app.config['SECRET_KEY'], algorithms=["HS256"])
except:
return jsonify({'message': 'Token is invalid!'}), 401
return f(*args, **kwargs)
return decorated
@app.route('/api/protected')
@token_required
def protected():
return jsonify({'message': 'This is a protected endpoint'})
# Vibe Coding:你只需要描述意图
"帮我创建一个 Flask API,有一个受 JWT 保护的端点 /api/protected,
未认证用户返回 401,认证用户返回欢迎消息。"
2. 结果导向(Outcome-Oriented)
Vibe Coding 关注的是"程序做了什么",而非"代码写了什么"。开发者通过运行程序、观察结果来验证 AI 生成的代码是否正确,而不是逐行审查代码逻辑。
3. 迭代式对话(Iterative Dialogue)
Vibe Coding 的开发过程是一系列对话式的迭代:
graph TD
A[描述需求] --> B[AI 生成代码]
B --> C[运行/预览]
C --> D{结果满意?}
D -->|是| E[继续下一个功能]
D -->|否| F[描述问题/调整需求]
F --> B
E --> A
4. 接受模糊性(Embracing Ambiguity)
这是 Vibe Coding 最具争议的特征——开发者可能并不完全理解 AI 生成的每一行代码,但只要程序按预期工作,就接受这种状态。正如 Karpathy 所说:“I’m building a project or webapp, but I’m not really coding.”
11.2.3 一个形象的类比#
如果把编程比作建造房屋:
传统编程:你是建筑工人,亲手搬砖、砌墙、接水管
AI 辅助编程:你是工头,指挥工人干活,但你懂每个工序
Vibe Coding:你是业主,告诉建筑师你想要什么样的房子,建筑师(AI)负责设计和施工,你负责验收
11.3 与传统编程的本质区别#
11.3.1 范式对比#
维度 |
传统编程 |
AI 辅助编程 |
Vibe Coding |
|---|---|---|---|
主要交互方式 |
编程语言 |
编程语言 + AI 补全 |
自然语言 |
开发者角色 |
代码编写者 |
代码编写者 + AI 协作者 |
意图引导者 |
代码理解程度 |
完全理解 |
完全理解 |
部分理解或不理解 |
核心技能 |
编程语言、算法、架构 |
编程 + Prompt 工程 |
需求表达、结果验证 |
开发速度 |
慢 |
中等 |
快 |
适用人群 |
专业开发者 |
专业开发者 |
所有人 |
调试方式 |
阅读代码、设断点 |
阅读代码 + AI 解释 |
描述问题让 AI 修复 |
11.3.2 从"How"到"What"的转变#
传统编程的核心是告诉计算机 如何(How) 完成任务——你需要精确地指定每一个步骤、每一个条件、每一个循环。而 Vibe Coding 的核心是告诉 AI 做什么(What)——你描述期望的结果,AI 负责找出实现路径。
这种转变可以用 SQL 的历史来类比。在关系数据库出现之前,程序员需要手动编写数据遍历和查找的逻辑。SQL 的出现让程序员可以声明式地描述"我要什么数据",而不需要关心"如何查找数据"。Vibe Coding 正在将这种声明式的理念推广到整个软件开发领域。
-- SQL 是早期的"Vibe Coding":声明你要什么,而非怎么做
SELECT u.name, COUNT(o.id) as order_count
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.created_at > '2025-01-01'
GROUP BY u.name
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC;
# Vibe Coding 将声明式推向极致
"查询 2025 年以来下单超过 5 次的用户,按订单数降序排列,
显示用户名和订单数量。"
11.4 Vibe Coding 的典型工作流程#
11.4.1 完整工作流#
一个典型的 Vibe Coding 工作流程包含以下步骤:
flowchart LR
A["🎯 构思"] --> B["💬 描述"]
B --> C["🤖 生成"]
C --> D["👀 审查"]
D --> E["▶️ 运行"]
E --> F{"✅ 通过?"}
F -->|Yes| G["📦 提交"]
F -->|No| H["🔄 反馈"]
H --> C
第一步:构思(Ideation)
在动手之前,先想清楚你要构建什么。这一步与传统开发没有区别,甚至更加重要——因为你的描述质量直接决定了 AI 生成代码的质量。
第二步:描述(Description)
用自然语言向 AI 描述你的需求。好的描述应该包含:
功能目标:要实现什么
技术约束:使用什么技术栈
质量要求:性能、安全性等非功能需求
上下文信息:与现有代码的关系
第三步:生成(Generation)
AI 根据你的描述生成代码。现代 AI 工具通常会:
生成完整的文件结构
包含必要的依赖配置
添加基本的错误处理
提供简要的代码说明
第四步:审查(Review)
快速浏览 AI 生成的代码,重点关注:
整体结构是否合理
是否使用了正确的技术栈
是否有明显的安全问题
第五步:运行(Run)
运行代码,观察实际效果。这是 Vibe Coding 中最关键的验证步骤。
第六步:反馈与迭代(Feedback & Iterate)
如果结果不满意,描述具体问题,让 AI 修改。
11.4.2 实际对话示例#
以下是一个真实的 Vibe Coding 对话流程:
👤 用户:
创建一个 React 组件,显示一个待办事项列表。支持添加、删除、
标记完成。使用 TypeScript,样式用 Tailwind CSS。数据存储在 localStorage。
🤖 AI:
[生成完整的 TodoList 组件代码,约 120 行]
👤 用户:
看起来不错,但我想要添加拖拽排序功能,
而且完成的任务要有删除线效果,移到列表底部。
🤖 AI:
[修改代码,添加 @dnd-kit 拖拽库,调整样式和排序逻辑]
👤 用户:
拖拽的时候有点卡顿,能优化一下吗?另外加一个过滤功能,
可以只看未完成的任务。
🤖 AI:
[优化拖拽性能,添加 useMemo 和 useCallback,增加过滤功能]
👤 用户:
完美!再加个导出功能,可以把待办事项导出为 Markdown 格式。
🤖 AI:
[添加导出按钮和 Markdown 生成逻辑]
整个过程中,开发者没有写一行代码,但通过 4 轮对话,构建了一个功能完善的待办事项应用。
11.5 Vibe Coding 的哲学#
11.5.1 接受不完全理解#
Vibe Coding 最具颠覆性的哲学观点是:你不需要完全理解代码也能构建软件。
这在传统软件工程看来几乎是异端邪说。几十年来,"理解你写的每一行代码"被视为专业开发者的基本素养。但 Karpathy 提出了一个反问:
你理解你使用的每一个库的源码吗?你理解操作系统内核的每一行代码吗?你理解编译器是如何将你的代码转换为机器指令的吗?
事实上,现代软件开发早已建立在层层抽象之上。一个 Web 开发者使用 React 时,不需要理解虚拟 DOM 的 diff 算法细节;使用 PostgreSQL 时,不需要理解 B+ 树的实现。Vibe Coding 只是将这种抽象推进了一步——AI 成为了一个新的抽象层。
11.5.2 编程的民主化#
Vibe Coding 的另一个重要哲学意义在于编程的民主化。长期以来,软件开发是一项需要多年专业训练的技能。Vibe Coding 大幅降低了这个门槛:
产品经理可以直接将需求转化为原型
设计师可以将设计稿变成可交互的前端页面
数据分析师可以构建自己的数据处理工具
创业者可以在没有技术合伙人的情况下构建 MVP
历史的回响
每一次编程范式的变革都伴随着"民主化"的争论。从汇编到高级语言,从命令行到图形界面,从原生开发到低代码平台——每一次都有人担忧"降低门槛会导致质量下降",但每一次都推动了更大规模的创新。
11.5.3 从"工匠"到"导演"#
Vibe Coding 重新定义了开发者的角色。传统开发者像工匠,亲手打磨每一个细节;Vibe Coding 时代的开发者更像导演,负责构思愿景、指导执行、把控质量。
这并不意味着技术能力不再重要。恰恰相反,一个懂技术的"导演"能够:
给出更精确的指令
更快地发现问题
做出更好的架构决策
在 AI 犯错时及时纠正
11.6 争议与讨论#
11.6.1 支持者的观点#
“这是生产力的巨大飞跃”
支持者认为,Vibe Coding 将开发效率提升了一个数量级。原本需要数天的工作,现在可能只需要数小时。这种效率提升对于创业公司、独立开发者和快速原型验证尤为重要。
“编程应该是手段,而非目的”
软件的价值在于解决问题,而非代码本身。如果 AI 能更快地将想法转化为可工作的软件,为什么要坚持手写每一行代码?
“这是自然的进化方向”
从机器码到汇编,从汇编到 C,从 C 到 Python,编程语言一直在向更高层次的抽象演进。自然语言编程是这条进化路径的逻辑延伸。
11.6.2 反对者的观点#
“不理解代码是危险的”
反对者最核心的担忧是:如果开发者不理解代码,就无法预见和处理边界情况、安全漏洞和性能问题。在关键系统(金融、医疗、航空)中,这种"不理解"可能导致灾难性后果。
“这会导致技能退化”
如果新一代开发者从一开始就依赖 AI 写代码,他们可能永远无法建立深层的编程能力。当 AI 出错时(AI 一定会出错),他们将无力应对。
“Vibe Coding 只适用于简单场景”
批评者指出,Karpathy 展示的 Vibe Coding 案例大多是简单的 Web 应用和脚本。对于复杂的分布式系统、高性能计算或底层系统编程,Vibe Coding 的效果大打折扣。
11.6.3 一个更平衡的视角#
作者观点
Vibe Coding 既不是银弹,也不是毒药。它是一种强大的新工具,适用于特定的场景和阶段。关键不在于"是否使用 Vibe Coding",而在于"何时以及如何使用 Vibe Coding"。
对于原型验证、个人项目、快速迭代——Vibe Coding 是极好的选择。 对于生产系统、安全关键系统、需要长期维护的代码——需要更加审慎。
最理想的状态是:具备深厚编程功底的开发者,善用 Vibe Coding 来加速开发。这样既能享受效率提升,又能在关键时刻把控质量。
11.7 Vibe Coding 的光谱#
Vibe Coding 并非一个非黑即白的概念,而是一个光谱。不同的开发者可以在这个光谱上找到适合自己的位置:
级别 |
描述 |
典型行为 |
|---|---|---|
Level 0:纯手写 |
完全不使用 AI |
所有代码手动编写,手动查文档 |
Level 1:AI 补全 |
使用 AI 代码补全 |
接受 Copilot 的行级建议,但主导代码结构 |
Level 2:AI 协作 |
与 AI 对话式编程 |
让 AI 生成函数/模块,自己审查和整合 |
Level 3:轻度 Vibe |
大部分代码由 AI 生成 |
描述需求,审查关键逻辑,快速浏览其余部分 |
Level 4:深度 Vibe |
几乎所有代码由 AI 生成 |
只关注结果是否正确,不深入审查代码 |
Level 5:纯 Vibe |
完全依赖 AI |
“看着、说着、运行着、复制粘贴着” |
大多数专业开发者目前处于 Level 2-3 的位置,而 Karpathy 描述的是 Level 4-5 的体验。随着 AI 能力的持续提升,整个光谱可能会向右移动。
11.8 本章小结#
Vibe Coding 是 AI 时代软件开发的一个重要里程碑。它代表了一种全新的人机交互方式——开发者用自然语言表达意图,AI 负责将意图转化为代码。
关键要点
Vibe Coding 由 Andrej Karpathy 于 2025 年 2 月提出,指用自然语言引导 AI 生成代码的编程方式
其核心特征包括:自然语言优先、结果导向、迭代式对话、接受模糊性
与传统编程的本质区别在于从"How"到"What"的转变
Vibe Coding 是一个光谱,从 AI 补全到完全依赖 AI 有多个层次
它既带来了巨大的效率提升,也引发了关于代码质量、技能退化的合理担忧
最佳实践是:具备深厚功底,善用 AI 加速
在下一章中,我们将深入探索 Vibe Coding 的工具生态——那些让 Vibe Coding 成为可能的强大工具。
参考文献
Karpathy, A. (2025). “Vibe Coding.” X/Twitter post, February 2025.
Karpathy, A. (2025). “Software in the era of AI.” YouTube presentation.
GitHub. (2025). “The State of AI in Software Development 2025.” GitHub Blog.
Stack Overflow. (2025). “Developer Survey 2025: AI Tools and Practices.”
Brooks, F. P. (1975). The Mythical Man-Month. Addison-Wesley.