Vibe Coding 是什么

这一课你将能做到

1. 说清楚 Vibe Coding 的定义、适用场景和边界
2. 判断一个任务适合「全托管给 AI」还是「AI 辅助、人来把关」
3. 建立 Vibe Coder 的正确心态：你是负责人，AI 是执行者

为什么要学

2025 年 2 月，Andrej Karpathy（前 OpenAI 联合创始人、特斯拉 AI 总监）提出了「Vibe Coding」这个词：你完全沉浸在氛围里，接受 AI 写的代码，甚至忘记代码的存在，只关注结果对不对。这个提法迅速流行，因为它描述了一种真实存在的开发方式——用自然语言描述需求，让大模型生成代码，人来验收。

人话：传统编程是你一行行写砖，Vibe Coding 是你当包工头，AI 是施工队。但包工头必须看得懂图纸、验得了质量，否则楼会塌。

和实际开发的关系：真实项目里，AI 已经能承担 60%-80% 的代码编写量（脚手架、CRUD、单测、正则、SQL），但剩下的 20%-40%——架构决策、边界条件、安全审查——恰恰是决定项目生死的部分。这一课帮你建立「什么时候放手、什么时候抓紧」的判断力。

先建立图像

传统编程：        Vibe Coding：
┌──────────┐     ┌──────────┐
│ 人想需求  │     │ 人想需求  │
│ 人写代码  │     │ 人写提示词│
│ 人调 bug  │     │ AI 写代码 │
│ 人做评审  │     │ 人验收结果│
└──────────┘     │ 人做评审  │ ← 这一步永远不能省
                 └──────────┘

两者的差别不在「谁写代码」，而在「人的时间花在哪」：从写代码转移到描述需求、设计结构、验证结果。

跟着做

步骤 1：体验一次完整的 Vibe Coding 循环

打开任意一个 AI 编程工具（Cursor、Claude Code、Copilot Chat 均可），给一个真实的小需求，比如：

用 Python 写一个命令行工具，读取当前目录下所有 .md 文件，
统计每个文件的行数和字符数，输出为表格，按行数降序排列。
要求：处理文件读取异常；输出包含合计行。

步骤 2：观察 AI 的输出并验收

AI 通常会一次性给出完整脚本。你要做的不是复制粘贴就跑，而是按清单验收：

1. 读一遍代码，确认每段在干什么——读到不懂的地方，贴回给 AI 让它解释
2. 跑一遍，用真实目录测试
3. 故意制造异常（比如放一个无权限的文件），看异常处理是否生效
4. 检查边界：空目录、0 字节文件、非 UTF-8 编码文件、文件名带空格的情况

验收时的心态：把 AI 当成一个能力很强但没有责任心的外包——它交付的东西，你要当验收方逐条过。

步骤 3：做一次「纯 Vibe」和一次「把关 Vibe」的对比实验

• 纯 Vibe：不看代码直接运行，记录遇到的问题
• 把关 Vibe：逐段审查后再运行，对比两者花费的总时间和最终结果质量

这个实验会让你直观理解：小工具纯 Vibe 没问题，但进生产代码必须把关。

步骤 4：建立你的「任务分级」直觉

把你日常的开发任务分成三级：

• A 级（可全托管）：一次性脚本、原型 Demo、学习性代码。出错代价≈0，放手让 AI 干。
• B 级（AI 起草+人审查）：业务功能、API 接口、组件开发。出错代价可控，AI 出初稿，你逐段审。
• C 级（人主导+AI 辅助）：架构设计、支付/鉴权逻辑、并发控制、数据迁移。出错代价高，AI 只当参谋（出方案、查资料、做对比），决策和实现你亲自来。

拿不准的任务就按高一级处理——宁可多审一遍，不要漏审一次。

讲清楚要点

1. Vibe Coding 不等于不负责任：Karpathy 的原话场景是「周末项目、一次性工具」。把它用在生产系统上而不审查，是事故的标准开局。
2. AI 是放大器，不是替代品：它能放大一个优秀工程师的产出，也能放大一个初学者的混乱。你懂多少，决定了你能从 AI 那里拿到多少。
3. 验收能力是核心技能：Vibe Coding 时代，「读代码并判断对错」比「从零写代码」更常用。读不懂的代码，不要合进项目。
4. 上下文决定输出质量：AI 不知道你的项目结构、团队的命名习惯、线上的坑，除非你告诉它。这就是后续「提示与上下文」一课的主题。
5. 迭代式协作优于一次性生成：「先出结构，再填细节，逐步修正」比「一句话要完整系统」成功率高得多。

你可能会懵的地方

• Vibe Coding 是不是就是"不会写代码的人也能开发"？ 能做出 Demo，不等于能维护系统。不懂代码的人用 AI 做出的东西，遇到 bug、安全漏洞、性能问题时会完全卡住。Vibe Coding 降低的是「写」的门槛，没有降低「懂」的要求。

• AI 写的代码版权/责任算谁的？ 算你的。无论代码是谁生成的，合入仓库、部署上线的人是你，责任就是你的。这也是必须审查的法律层面原因。

• 为什么 AI 有时候写得很好，有时候胡说八道？ 大模型是概率生成，不是查表。训练数据里常见的模式（如单例、CRUD）它写得很稳；冷僻 API、新版本特性、你项目特有的逻辑，它可能「幻觉」出不存在的方法。越通用的需求越可信，越特定的越要验证。

• 用 AI 写代码会不会让我的基本功退化？ 会，如果你只复制不读。对抗方法：每段 AI 代码至少读一遍并能向别人解释；定期手写核心算法；把 AI 当「结对伙伴」而不是「外包」。另一个信号检测：如果你离开 AI 连一个二分查找都写不出来，说明退化已经发生了。

• Vibe Coding 和普通「用 AI 补全代码」有什么区别？ 补全是逐行辅助，你还在驾驶；Vibe Coding 是把整个功能乃至应用交出去，你只描述目标和验收。两者是光谱的两端，实际工作流在两者之间移动——同一个项目里，可能上午用补全写算法，下午用 Agent 生成 CRUD 页面。

• 团队里有人完全依赖 AI、有人完全不用，怎么平衡？ 用工程标准统一，不用「用不用 AI」站队。不管代码怎么来的，Review 标准、测试覆盖、安全扫描完全一致。AI 是生产工具，不是信仰。

错法对照

错法	问题	正解
一句话需求要完整系统	上下文不足，AI 自由发挥，返工率高	拆成多轮：先结构、再模块、后细节
生成完直接部署	幻觉 API、安全漏洞进生产	本地跑通 + 审查 + 测试后再上
读不懂的代码也合入	埋下无人敢动的黑盒	让 AI 解释到你懂为止，不懂就重写
一个会话聊到地老天荒	上下文污染，AI 越改越乱	一个任务一个会话，定期总结重开
完全不写文档和注释	三天后自己和 AI 都看不懂	关键决策写入 README 或规则文件

卡点急救

1. AI 生成的代码跑不起来：把完整报错信息和相关代码贴回去，说「运行报这个错，修复它」，比你自己猜快得多。贴报错时带上完整的堆栈，不要只截一行。
2. AI 反复在同一个地方改错：说明上下文里缺关键信息。停下来，把相关文件、数据表结构、接口定义补给它，或开新会话重新组织上下文。继续追问只会让 AI 在错误的上下文里打转。
3. 不知道自己该审什么：用最小清单——这段代码的输入校验在哪？异常怎么处理？有没有硬编码的密钥？依赖包是否真实存在？这四条能拦下 80% 的 AI 低级错误。

面试常问

• 你怎么看 Vibe Coding？团队里怎么用？ 高分回答：认可它对原型和重复性工作的提效（给出量化例子），但强调生产代码必须有审查、测试、安全扫描三道关；能说清「哪些任务托管、哪些不托管」的分级标准，说明你有工程判断力而不是追热点。

• AI 生成代码出了线上事故，责任怎么界定？ 责任在使用者和审查流程，不在工具。合规做法：AI 代码与人写代码走同样的 Code Review、CI 测试和安全扫描；关键系统增加人工复核环节。

• 如何保证 AI 生成代码的质量？ 四层：清晰的提示词与上下文（输入质量）、生成后人工审查（代码质量）、自动化测试（行为质量）、静态扫描与依赖检查（安全质量）。

自测三问

1. Vibe Coding 这个词是谁在什么背景下提出的？它的原始适用场景是什么？
2. 把「给公司写一个订单结算模块」和「给自己写一个整理下载文件夹的脚本」分别分到哪个托管级别？为什么？
3. 验收 AI 生成的代码时，你的最小检查清单包含哪几项？

小结一句话

Vibe Coding 是用自然语言驱动 AI 写代码、人专注需求与验收的开发方式——放手可以，放责不行。

延伸

• Andrej Karpathy 关于 Vibe Coding 的原始讨论（X/Twitter）
• 下一课：项目规划与 AI 协作——动手之前，先教会 AI 你要做什么。