/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
摘要：Vibe Coding 让我们体验了\”心想事成\”的开发快感，但代码库也随之堆满逻辑矛盾、风格割裂的\”一次性代码\”——AI 就像一位记忆力只有 7 秒的超级实习生，写得飞快，却不懂你的架构、不守你的规范。本文拆解 Vibe Coding 的三大陷阱：上下文熵增、逻辑隐形腐烂、协作巴别塔，并给出工程化解法 Spec Coding：用一份结构化 Spec 与 AI 签下\”施工合同\”，让它按图施工、照单验收。文章以钉钉免登组件为例，完整演示编写 Spec、AI 生成、变更维护的闭环，并诚实讨论 Spec 的适用边界与成本。
本文要点（TL;DR）
- Vibe Coding：凭感觉用自然语言驱动 AI 写代码，初期快，但约束只存在于对话记忆里，随迭代必然衰减。
- 三大陷阱：上下文熵增、逻辑隐形腐烂、协作巴别塔。
- Spec Coding（规约驱动开发）：用结构化 Spec 写清业务目标、输入契约、异常处理和验收标准，让 AI 按图施工、照单验收。
- 判断标准：代码活得过两周、会被别人维护、触及核心数据结构——任一命中，就必须写 Spec。
一、先问一个扎心的问题
想象你的团队来了位新实习生：编码速度快得惊人，一个下午能干完你三天的活。但他从不看团队的规范文档，每次沟通完转头就忘——上午说好用 Hooks，下午就写成了 Class 组件；交付没有测试、没有文档，你问他\”这个字段是干嘛的\”，他想了想说：“我忘了。”
你会给他转正吗？
大概率不会。但过去一年，我们中的大多数人，正把项目的核心模块交给这样一位\”实习生\”——AI，而且乐在其中。
这种开发方式有个流行的名字：Vibe Coding（氛围编程）——由 OpenAI 联合创始人 Andrej Karpathy 于 2025 年 2 月提出的概念，指开发者不细看代码、不深究实现，全凭感觉用自然语言指挥 AI 生成代码的开发方式，“氛围到位了，代码就接受了”。
必须承认，Vibe Coding 的体验确实上头。聊两句需求，代码就哗哗地生成，项目初期的速度肉眼可见地快。但随着迭代深入，很多人发现了一个危险的趋势：速度的优势，是拿质量抵押换来的——代码库里逐渐堆满了逻辑矛盾、风格割裂的\”一次性代码\”。
说到底，AI 是一位记忆力只有 7 秒的超级实习生：它写代码很快，但它根本不懂你的架构，也不在乎你的规范。
这篇文章，我们就来聊聊怎么给这位实习生立规矩：让 AI 编程从\”凭感觉\”走向\”按契约\”，也就是从 Vibe Coding 进化到 Spec Coding（规约驱动开发）。
二、Vibe Coding 的三大陷阱：上下文熵增、逻辑隐形腐烂、协作巴别塔
Vibe Coding 的核心逻辑是\”人定意图，AI 落地\”，听起来很美好。但在真实工程里，它有三个反复发作的致命缺陷。
陷阱一：上下文的\”熵增\”
在 Vibe 模式下，所有约束都活在对话流里。随着对话轮数增加，早期设定会被 AI 逐渐\”挤出\”记忆：第 3 轮说的\”必须用 Tailwind CSS\”，到第 30 轮已经荡然无存。
结果就是同一个项目里：A 页面用 Hooks，B 页面用 Class 组件；A 接口用 Axios，B 接口用 Fetch；错误处理有的用 Toast、有的用弹窗、有的干脆没有。每块代码单看都能跑，拼在一起就是一座\”风格大杂烩\”。
陷阱二：逻辑的\”隐形腐烂\”
Vibe Coding 缺乏明确的验收标准，\”能跑\”是唯
