Vibe session · Learning mode阅读、尝试、提问都留在同一个工作区
Course Map
练习进度 0/55
Learning Guide
Build session

Vibe Coding vs Spec Coding — 两种范式,两种活法

warmup · 8-10 min · 步骤 1/3

你跟 AI 说话的方式,决定了你在做哪种编程

你有没有注意到一个现象?同样是用 AI 写代码,有的人三分钟就搞出一个能用的东西,有的人折腾了三天结果还是一堆 bug。

很多人觉得这是"Prompt 写得好不好"的问题。是,但也不完全是。更根本的原因是:他们在用两种完全不同的方式跟 AI 协作,而自己可能都没意识到。

Traditional developers vs Vibe coding developers——两种开发者的能力曲线对比

这两种方式,业内现在有了比较明确的叫法——Vibe CodingSpec Coding

Vibe Coding:跟着感觉走

Vibe Coding 就是 Karpathy 在推文里描述的那种状态——"see stuff, say stuff, run stuff, copy paste stuff"。你不写详细的需求文档,不画流程图,不定义接口类型。你有一个大概的想法,你跟 AI 说,AI 给你一坨东西,你看看效果,不满意就继续说,满意就往下走。

整个过程非常像聊天。你和 AI 之间是一种松散的、即兴的、探索式的关系。

什么是 Vibe Coding——交互式开发过程、真实对话案例与适用场景

一个典型的 Vibe Coding 场景长这样:

你:帮我做一个番茄钟计时器,25 分钟工作 5 分钟休息,好看一点
AI:(生成了一个带圆形进度条的计时器)
你:不错,但我想要深色背景,倒计时数字再大一点
AI:(改了)
你:可以了,再加一个声音提醒
AI:(加了)
你:完美,部署到 Vercel 上吧

你看,整个过程没有任何文档、没有任何规范、没有定义任何数据结构。你就是在"对话"中把东西做出来了。

这种方式的优势很明显:快、爽、门槛低。对于个人项目、快速验证想法、做 demo 给别人看,Vibe Coding 简直是神器。我自己周末做小工具基本都是这个模式——打开 Cursor,想到什么说什么,十分钟一个小工具就出来了。

但 Vibe Coding 有一个致命的问题:它不 scale。当你的项目从一个页面变成十个页面,从一个人用变成一百个人用,从"能跑就行"变成"不能出错"的时候,Vibe Coding 就开始扛不住了。

为什么?因为你没有任何文档。三天前你让 AI 做的那个功能,你自己都忘了当时是怎么描述的了。AI 当时做的那些设计决策,你也没记录。新加一个功能的时候,AI 可能会把之前做好的东西改坏,而你甚至不知道哪里变了。

Spec Coding:先写规格,再写代码

Spec Coding 是另一个极端。在这种模式下,你在让 AI 动手之前,先花大量时间做准备工作。

你可能会写一个 PRD(产品需求文档),定义清楚每个功能的输入输出、边界条件、成功标准。你会写一个技术设计文档,规定用什么技术栈、数据库 schema 长什么样、API 接口怎么设计。你可能还会写一个 CLAUDE.md 或 .cursorrules 文件,把项目的编码规范、命名习惯、禁止事项全部列出来。

然后你才开始跟 AI 说:"请根据 PRD 第三节的需求,实现用户注册功能。"

这种方式听起来又慢又笨?确实慢。但它解决了 Vibe Coding 的核心问题——可追溯、可维护、可协作

Amazon 最近有一个新闻特别说明问题:他们的开发团队用 AI 辅助编程之后,因为缺乏规范化的流程管理,导致了几次严重的生产环境事故。后来他们的解决方案不是"不用 AI",而是建立了更严格的 Spec 流程——每一个 AI 生成的代码改动,都必须有对应的需求文档和代码审查。

Amazon 的 IDE 工具 Kiro 甚至直接把 Spec-driven Development 做成了产品核心功能——它会强制你先写 spec,然后 AI 才会开始编码。

什么是 Spec Coding——需求明确 + 先写规范 + AI 执行的开发模式

不是二选一,而是看场景

如何选择和切换 Vibe & Spec Coding——判断框架与混合使用模式

这里要说一个很多人搞混的点:Vibe 和 Spec 不是"好"和"坏"的关系,而是"不同工具适合不同场景"的关系。

你不会用电钻来拧螺丝,也不会用螺丝刀来打孔。同样的道理,你不应该用 Vibe Coding 来做金融交易系统,也不应该用 Spec Coding 来做一个周末的个人小项目。

维度Vibe CodingSpec Coding
核心态度"跟着感觉走,先做出来再说""先想清楚,再让 AI 动手"
前期准备几乎没有需求文档 + 技术设计 + 规范文件
适合场景原型、demo、个人工具、学习实验正式产品、团队协作、长期维护
速度极快(分钟级)较慢(小时到天级)
质量下限不稳定,看运气相对可控
可维护性差——三天后你自己都看不懂好——有文档可查
容错空间大——做坏了重来就行小——生产环境容不得翻车
话说回来,真实的开发场景里,大部分人用的其实是两者的混合体。你可能先用 Vibe 快速出一个原型给老板看,老板说"不错,继续做",然后你再切换到 Spec 模式,把需求文档补上,把代码规范定好,进入正式开发阶段。

Simon Willison(Django 的共同创建者)说过一句话很精辟:"Not all AI-assisted programming is vibe coding."(不是所有 AI 辅助编程都是 Vibe Coding。)他的意思是,用 AI 写代码和 Vibe Coding 是两回事。你完全可以用 AI 写代码的同时保持严谨的工程规范——这就是 Spec Coding。

所以你现在要建立的认知是:Vibe 和 Spec 是一个光谱的两端,你需要学会根据场景在这个光谱上滑动。 个人项目?偏 Vibe。公司项目?偏 Spec。快速验证想法?先 Vibe 再 Spec。上线前最后冲刺?纯 Spec。

这就是为什么这门课既会教你怎么 Vibe(快速出东西),也会教你怎么 Spec(用 PRD、CLAUDE.md、Context Engineering 这些工具让 AI 更可控)。两种能力你都需要。

Vibe Workspace
Live build context

两种编程范式:Vibe 和 Spec

同样是让 AI 写代码,但态度和方法完全不同

自动保存在此设备
理解 Vibe Coding 和 Spec Coding 各自的定义和适用边界能根据具体场景判断应该用哪种范式避免在不该 Vibe 的时候 Vibe、在不该 Spec 的时候 Spec
Home| Vibe Lab
草稿自动保存