Vibe Coding 与 Spec-Driven Development：2026 Q2 软件开发的两条新文化线

Vibe Coding 与 Spec-Driven Development

flowchart LR
  A["软件开发的两条新文化线"]
  A --> B["Vibe Coding (Karpathy 2025-02)"]
  A --> C["Spec-Driven Dev (大厂 2026)"]
  B --> D["不读代码，只看效果"]
  C --> E["规约 > 代码"]

一年前，“vibe coding” 还只是 Karpathy 一条推特里的玩笑——“我已经不读代码了，只看效果，让模型继续改”。到 2026 Q2，这件事已经从段子变成两件实质的事：一边是创业者 / 独立开发者用 vibe coding 6 个月做出过去 18 个月才能做的产品；另一边是大厂在反方向上把 spec-driven development 做成了规范流程。这是两条看似相反但同样真实的变化。

这篇文章会讲什么

070b Coding Agents v2 讲的是工具层（Cursor / Devin / Claude Code），本文讲的是这些工具被使用的方式——以及这些使用方式背后的文化分裂：

Vibe coding 派：自然语言为主、不深入读代码、把模型当协作者、追求”出活儿快”
Spec-driven 派：把 spec / contract 作为单一事实源、代码是从 spec 派生的、追求”规模化稳定”

这两派会同时存在，在不同场景里各有适用。本文会回答：

Vibe coding 到底是什么？为什么有人觉得是革命，有人觉得是灾难？
Spec-driven development 在大公司里长什么样？
什么时候用 vibe coding，什么时候用 spec-driven？
两派之间的”中间状态”——大多数团队实际在做的事

先说结论

Vibe coding 真实存在且在某些场景能用——特别是个人项目、原型、小团队产品的 0→1 阶段
Vibe coding 在维护期会爆炸——代码质量不一致、知识不在团队脑子里、bug 修复时需要回头读 AI 写的代码
Spec-driven development 是大公司的反方向选择——把 spec / contract 而不是代码作为团队真正维护的资产
大多数团队在中间——用 Cursor / Claude Code 做 day-to-day 开发，但有 spec / 评测 / CI 作为 guard rails
关键判断不是”vibe vs spec”，而是”这段代码未来谁负责维护”——如果是你 + 6 个月内不动，vibe ok；如果是团队 + 长期，spec-driven 更稳

1. Vibe Coding 是什么

1.1 Karpathy 的原文

2025 年 2 月，Andrej Karpathy 在 X (Twitter) 写了一段：

“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 it mostly works.”

这条推文当时被很多人当段子看。但 18 个月后回头看，它精准描述了一种正在变成主流的工作方式。

1.2 工作方式

典型 vibe coding 流程：

有想法
  → 在 Cursor / Claude Code / Bolt / Lovable 描述
  → Agent 生成多文件代码 + 跑通
  → 看效果（视觉 / 功能）
  → 不满意？继续描述要改的地方
  → Agent 改
  → 满意？继续下一个 feature

关键特征：

几乎不直接读 / 写代码
不深究内部实现
主要看”看起来对不对”和”跑起来对不对”
错误信息 / stack trace 直接复制给模型让它自己修
关注”新功能 / 新效果”，不关注”代码组织”

1.3 谁在做 vibe coding

到 2026 Q2，几个明显在做的人群：

人群	做什么	用什么
独立开发者	1 个人 6 个月做完一个 SaaS	Cursor + Claude Opus 4.7
创业者 (非技术背景)	自己写 MVP 验证想法	Bolt / v0 / Lovable
设计师 / PM	做交互原型	v0 / Cursor
科研人员	写一次性数据分析脚本	Cursor + Aider
产品负责人	周末做内部小工具	Lovable / Bolt
学生	做作业 / 学习项目	Cursor / Bolt

1.4 为什么 H1 才规模化

几件事同时到位才能让 vibe coding 真正可用：

Coding Agent SWE-bench Verified 80%+（参见 078）——一发就能跑、改两次就 work 的成功率到了
Cursor 2.0 background agents / Claude Code 1.0——长任务 / 多文件改不再卡
Bolt / v0 / Lovable 这类”prompt to deployed app”工具成熟——非技术背景的人也能用
MCP 让 Agent 能接入数据库 / 业务系统——不再只是写 toy app

2. Vibe Coding 的真实优势

2.1 速度 (个人项目里是真的)

一个常见的对照：

任务	传统方式	Vibe coding
个人 SaaS MVP（前端 + 后端 + 数据库）	2–4 周	1–3 天
内部小工具	半天	1 小时
数据分析脚本	几小时	几分钟
设计 mockup → 可点击原型	几天	几小时

2.2 进入门槛降低

非技术背景的人可以做出过去做不到的东西。这件事的影响在创业 / 教育 / 科研里已经出现：

创业：单人创业 SaaS 在 H1 出现了几个公开案例（年收入 $1M+ 的独立开发者数量明显增加）
教育：编程教学的”门槛”正在重新定义
科研：非 CS 背景的研究人员可以自己做数据 pipeline

2.3 创意空间扩大

很多想法过去因为”实现太花时间”被砍掉，现在可以快速验证。这是 vibe coding 最被低估的价值——它不仅让原本能做的事更快，还让原本不会做的事变成可能。

3. Vibe Coding 的真实代价

3.1 维护期会爆炸

这是 H1 已经开始大规模显现的问题。一个典型轨迹：

Week 1–4:  vibe coding 飞快，产品出来了
Week 5–12: 用户反馈进来，需要改 bug / 加 feature
Week 13+:  代码已经成你不熟悉的样子，每个 bug 都要回头读
            模型也开始"在它自己写的烂代码上加更多烂代码"
            最终：项目不可维护，要么重写，要么放弃

这个轨迹在 H1 已经有大量公开复盘。Vibe coding 的”快”是有时效的——通常 6 个月内你能维持速度，之后会断崖式下降。

3.2 知识不在团队脑子里

传统写代码的副产品是：你理解了系统。Vibe coding 的副产品是：你记住了你描述的功能，但不一定理解实现。等你需要：

调试一个非显而易见的 bug
解释为什么系统这样做
给新人 onboard
讨论架构决策

时，会发现知识是断的。

3.3 隐性的技术债

模型写的代码经常有这样的特征：

重复多个相似但不完全相同的函数（因为模型每次都”重新想”）
引入不必要的依赖（因为”用最常见的库”是模型的偏好）
错误处理不一致（每个文件用不同 pattern）
命名风格漂移
测试覆盖看起来高但其实测的不是真正的边界

这些不会在你 vibe 期出现问题，会在维护期突然爆发。

3.4 协作问题

Vibe coding 是个人体验。一旦多人协作，问题立刻出现：

两个人对同一段 AI 代码的理解不一样
PR review 失去意义（reviewer 也不深读）
责任划分模糊（“那段是 AI 写的，不是我写的”）

3.5 安全 / 合规盲区

参见 044b AI 安全 v2。Vibe coding 的人通常不会主动做：

依赖 OSV scan
安全 review
数据流梳理
权限边界设计

这些事在 vibe 流程里”看不见”，会变成长期风险。

4. Spec-Driven Development：另一极的反应

4.1 是什么

Spec-driven development（SDD）的核心想法：spec 才是团队真正维护的资产，代码只是 spec 的一个实现版本。

传统：       人写 code → code 是事实源 → 文档是 derived (常常过时)
SDD：        人写 spec → spec 是事实源 → code 是 derived (从 spec 生成)

这不是新想法（Design by Contract、形式化方法、TDD 都是邻居），但有了能力强的 Coding Agent 之后，SDD 第一次在工程实践里变成可行。

4.2 在 H1 怎么落地

主流 SDD 实践包括：

实践	工具	作用
OpenAPI / GraphQL spec 驱动	spec → 客户端 / 服务端 / mock 全部生成	API 边界稳定
类型驱动开发 (Type-Driven)	TypeScript / Rust 强类型 + Agent 在类型约束内写实现	编译期保证一致
行为驱动测试 (BDD)	Gherkin + Agent 实现	测试就是 spec
Contract testing	Pact / Spring Cloud Contract	多服务 spec 一致
Agent skills / cursor rules	Markdown spec → Agent 行为约束	团队 spec 共享
”Spec 先行”评审流程	PR 必须先有 spec 改动	spec drift 被阻止

4.3 大公司为什么往这个方向走

几个真实驱动力：

代码量爆炸：Coding Agent 让代码生产速度提了 5–10×，靠人类 review 已经追不上
责任链断裂：传统 code review 假设 reviewer 能深读 author 的代码——AI 代码情况下这个假设失效
架构稳定性：大公司不能容忍每次 vibe coding 改动都引入不可预测的架构漂移
跨团队协作：spec 是跨团队对话的共同语言，代码不是

4.4 SDD 在 H1 的真实形态

不是”先写 1000 行 spec 再写代码”那种瀑布。更现实的形态是：

PR 改动            → 自动检查：是否影响 spec？
影响 spec？        → 是 → 必须先改 spec → reviewer 评审 spec → 通过后改代码
不影响？          → 走轻量 review，主要看 spec 一致性

这套流程让”代码生成速度变快、spec 仍然稳定”成立。

4.5 GitHub Spec Kit（H1 重要事件）

2026 Q1 GitHub 推出 Spec Kit，把 OpenAPI + Contract Testing + Agent skills 整合成一个 GitHub-native 的工作流。这是 SDD 第一次有了一个跨团队的”标准实现”。如果你公司在用 GitHub，这是个值得跟踪的方向。

5. 两派的真实分布与”中间路线”

5.1 实际分布 (估算)

群体	占比 (Q2 估算)	主导方式
个人 / 独立开发者 / 1–3 人小团队	~40%	Vibe coding 为主
中小团队 (4–20 人)	~35%	中间路线
中大团队 (20–100 人)	~20%	中间路线偏 SDD
大公司 (100+ 工程师)	~5%	SDD / 严格流程

注意：vibe coding 用户在快速增长，但 SDD 用户也在增长——它们不是 zero-sum，是不同人群在选不同方式。

5.2 中间路线长什么样

大多数中小团队实际做的事：

用 Cursor / Claude Code 做 day-to-day 开发——AI 写大部分代码
但有这些 guard rails：
- 每个 PR 必须有自动化测试
- 关键模块（auth / payment / data）有 contract test
- 团队约定的 cursor rules / claude code skills（参见 058 Agent Skills）作为团队 spec
- Code review 仍然有，但聚焦 in 架构 / 安全 / 业务逻辑，不抠语法
不全 vibe，也不全 spec——而是”AI 加速 + 人类 keep guard rails”

这是 H1 最务实、最常见的形态。

5.3 决策框架：你该选哪种

你的场景	建议
个人项目 / 周末实验	Vibe coding，享受速度
创业 0→1 / MVP / Pre-PMF	Vibe coding 为主，加最基本的测试
Pre-Series A / 团队 5–10 人	中间路线：cursor rules + 测试 + code review
已 PMF / 团队 20+	中间路线偏 SDD：contract test + spec 评审
高合规 / 金融 / 医疗	SDD + 全面 spec + 严格 code review
内部工具 / 一次性脚本	Vibe coding，不要过度工程

6. 给团队的几条实用建议

6.1 如果你在 vibe coding 阶段

接受这是有时效的——给自己一个”什么时候转向中间路线”的触发条件（比如 $10K MRR / 第一个 paying customer / 第一个团队成员加入）
至少加一层测试——AI 写代码 + AI 写测试，比完全没有强很多
至少有一个数据库 migration 文件——不要让数据 schema 变成 vibe 状态
保留 ROLLBACK 能力——deploy 必须能撤回
每周至少花一小时读一次代码——不是为了改，而是不让自己彻底不懂自己产品

6.2 如果你在转向中间路线

从 cursor rules / claude code skills 开始——把团队约定写进 markdown，让 AI 自动遵守
关键模块加 contract test——auth / payment / external API 必须有
PR 流程升级：reviewer 看 spec 一致性 + 安全边界 + 架构合理性，不抠 coding style（让 AI 做）
OSV scan 接入 CI（参见 044b 第 16 节）
建评估集（参见 071 Eval Harness）——把”重要 case”做成可重复评估

6.3 如果你在做 SDD

看 GitHub Spec Kit——目前最完整的 SDD 工具链
OpenAPI / GraphQL 作为团队公共语言——所有跨服务通信走 spec
Contract testing 接 CI——Pact 或类似
spec 改动单独 review——不和实现 PR 混在一起
训练全员”读 spec 而不是读 code”——这是文化转变，需要时间

7. 几个常被问的问题

7.1 “vibe coding 是不是会让程序员失业”

短期：不会让程序员失业，但会让”只会写 boilerplate” 的初级工种压缩。

长期：会让”软件工程师”这个角色重新定义——更接近”产品 + 架构 + AI 协作管理”，不是”打字机器”。

7.2 “我应该让团队学 vibe coding 吗”

如果团队主要做：内部工具、prototype、个人产品 → 是如果团队主要做：大型生产系统、合规场景 → 学技巧但不要全套照搬

7.3 “spec-driven 是不是又是一次瀑布回潮”

不是。SDD 不要求”先把 spec 全写完再开始”，要求的是”每次改动让 spec 和代码同步”。这件事在 AI Coding Agent 时代第一次真正可行——因为 AI 可以根据 spec 增量生成 / 调整代码。

7.4 “Vibe coding 出来的代码到底能不能维护”

诚实答案：能维护，但需要主动转型。继续 vibe 是不行的。维护期需要：

至少一次大型 refactor（把混乱代码重新组织）
加测试覆盖
写最关键模块的文档
引入 cursor rules / skills 约束未来改动

这一步在 H1 已经有越来越多公开复盘——独立开发者们在产品到 $10K MRR 时几乎都做过一次这种 refactor。

8. 与其他主题的关系

与 070b Coding Agents v2 的关系：那篇是工具层，本文是工作方式层
与 058 Agent Skills 的关系：cursor rules / claude code skills 是 SDD 在 Agent 时代的载体
与 044b AI 安全 v2 的关系：vibe coding 的安全盲区在 044b 第 16 节有讨论
与 041 评估体系 / 071 Eval Harness 的关系：中间路线和 SDD 都需要建评估集
与 047 产品模式图谱的关系：v0 / Lovable / Bolt 这些”prompt to app”工具在产品模式上是 vibe coding 的承载

小结

2026 Q2 软件开发文化分裂成两条线：

Vibe coding 让”个人 / 小团队产出突然提升”成为现实——这是真的革命，但有时效
Spec-driven development 让”大团队规模化处理 AI 生成代码”成为可能——这是另一种真的革命，更稳但更慢

绝大多数人会在中间：用强 Coding Agent 加速 day-to-day 开发，同时用 cursor rules / contract tests / 评估集作为 guard rails。

最关键的不是哪派赢——是判断你这段代码未来谁负责维护：

个人 + 短期 → vibe ok
团队 + 长期 → spec-driven 或中间路线
别的都是过渡形态

这是 H1 最重要的”软件工程文化变化”——比工具层的代际更新影响更深。