超越Vibe Coding：我们如何用“Spec Coding”工作流，驾驭AI进行严肃开发

引子：AI编程最大的谎言——“Vibe Coding”

“Vibe Coding”成为今年的年度词汇，这是全球知名的柯林斯词典选定的。

![[Pasted image 20251114103620.png]]

这个词是2025年2月，由特斯拉前AI总监、OpenAI创始工程师安德烈·卡帕西（Andrej Karpathy）提出的概念。“Vibe Coding” 简单来说就是氛围编程，更深一步说，它已经不仅仅是一种新的编程方式，而是让那些原本需要多年才能掌握使用的专业技能，变得即使最普通的小白也可以上手。

你可以不懂代码、你可以不懂设计、你甚至PRD都写不明白，但是你只要能告诉AI你想要什么，AI就能帮你实现。

即使不是程序员，估计Cursor、Claude Code这些工具，也都听说过，甚至用过。如果体验过那种，仅仅用自然语言说一下需求，就能看到刷刷的成百上千的代码出现在你的面前，这时是不是有一种“我什么都能做”的感觉？

这也太爽了，这也太上头了。

但是不要高兴太早，经过将近一年的发展，“Vibe Coding”的后遗症开始显现了。我们正在为这种随心所欲、言出法随而付出代价，那就是无法避免的、而且非常巨大的技术债。这正在吞噬掉Vibe Coding带来前期开发的快感。程序越复杂，迭代越多，使用Vibe Coding所带来的灾难越大。

近期在Hacker News上有个帖子就是在讨论这个问题，标题是为什么 AI 好像并没有帮到初级开发者（Juniors），反而让资深开发者（Seniors）变得更强了？

帖子中说到一个场景，（我想我们也全都经历过）：

在一个 PR 评审会上，你指着一段明显有问题、引入了奇怪依赖的代码，问那个初级开发者：“你为什么这么写？”

对方一脸无辜地回答： “我不知道，Claude 干的。” (I don’t know, claude did that)

这就是当前“Vibe Coding”最大的问题。它一方面会让你感觉很爽，但是另一方面又会让你被AI牵着鼻子走，而且越来越无法自拔，逐步掉进充满幻觉的“兔子洞”（rabbit hole），由此为项目留下一大堆的定时炸弹。

那为什么资深开发者来用AI，反而能得到非常大的提升呢？

因为他们从不“Vibe”。他们不是仅仅给AI一些简单的描述，就等着AI出代码。他们会为项目设计清晰的架构，他们会制定明确的规范。因为他们是在执行 “Spec Coding”，去规范AI、指导AI、审查AI，在AI犯错时，能够第一时间把它拉回来，把问题处理掉。

所以，AI时代的真正生产力，从来都不是“Vibe”，而来自“Spec”——Specification，规格。

这篇文章，就是为你拆解一套我个人正在实践的“Spec Coding”（规范驱动开发） 工作流。它能帮你驾驭 AI 进行严肃开发，将你的团队从“游击队”升级为“正规军”。

我的“Spec Coding”实战流程

这套流程在宏观上分为三个阶段：规划、执行、集成。

[[3_Resources/3.4_Articles/Drafts/_resources/草稿 - 超越Vibe Coding：我们如何用“Spec Coding”工作流，驾驭AI进行严肃开发/211438193b1a914024d23ec07f9aceba_MD5.jpeg|Open: 未命名项目-图层 1.jpeg]] ![[3_Resources/3.4_Articles/Drafts/_resources/草稿 - 超越Vibe Coding：我们如何用“Spec Coding”工作流，驾驭AI进行严肃开发/211438193b1a914024d23ec07f9aceba_MD5.jpeg]]

阶段1：战略规划 —— 拒绝“一句话需求”，逼AI先“对齐”

第一条铁律：在写第一行代码之前，我必须先和AI“对齐颗粒度”。

“Vibe Coding” 最大的坑，就是你直接给AI一个“一句话需求”，就像“帮我做一个登录功能”。AI会非常快地给你吐出1000行代码，但这些代码90%都是基于它“猜”的逻辑，根本没法用，这就是“技术债务”。

所以，我的Phase 1 只有一个目标：禁止AI猜，强迫它先思考。

  1. 我（人类）先做功课： 我会先在Linear 里把这个功能（Epic）的PRD写清楚。然后，我会创建一份“史诗作战计划” (Epic Battle Plan)，这是“战略蓝图”。这份作战计划会根据我们的cursor rule （@rules/230-wf-write-dev-docs.mdc） 来编写，需要写清楚 “What/Why”（规格）和 “How”（技术规划思路）。
  2. 启动“AI评审”（VCA一致性分析）： 这是最关键的一步。我不会直接让AI写代码。我会先进行一轮AI评审，把“作战计划”和“核心工程铁律” (@rules/001-gen-constitution-principles.mdc)都 @ 给它。
  3. 我（对AI）下达指令： “请交叉验证这份‘作战计划’和这份‘铁律’，告诉我：我的规划里，有没有违背铁律的地方？我的技术选型和我的规格目标，是不是一致的？有没有明显的逻辑漏洞？”

在AI **完成本次“AI评审”**后，有问题就让AI直接修改作战计划，如果确认没问题了，这时我才会将其拆分成子任务（Issues）。

这个阶段，不产出任何功能代码，只产出“共识”和“清晰度”。

[[3_Resources/3.4_Articles/Drafts/_resources/草稿 - 超越Vibe Coding：我们如何用“Spec Coding”工作流，驾驭AI进行严肃开发/76f20dba86843db037714cc0c8a52254_MD5.jpeg|Open: CleanShot 2025-11-14 at 12.09.45@2x.png]] ![[3_Resources/3.4_Articles/Drafts/_resources/草稿 - 超越Vibe Coding：我们如何用“Spec Coding”工作流，驾驭AI进行严肃开发/76f20dba86843db037714cc0c8a52254_MD5.jpeg]]

阶段2：战术执行 —— 用“TDD循环”驯服AI，告别黑盒

好了，规划阶段完成，我们现在拿到了清晰、无冲突的作战计划和子任务（Issues）。

但即便是这样，我依然禁止AI直接开始写功能代码。

如果我现在就说：“好了，AI，开始执行任务1吧”，结果会怎样？它会立刻“Vibe” 起来，吐出500行代码，这岂不是又回到了那个“Claude干的” 黑盒陷阱里。这样干肯定不行。

所以，我的Phase 2 只有一个目标：彻底摧毁这个“黑盒”，用“测试驱动开发（TDD）”的纪律，来驯服AI的创造力。

[[3_Resources/3.4_Articles/Drafts/_resources/草稿 - 超越Vibe Coding：我们如何用“Spec Coding”工作流，驾驭AI进行严肃开发/d7e2d6202f41242e0368361fdd78caa3_MD5.jpeg|Open: 未命名项目-图层 1 (1).jpeg]] ![[3_Resources/3.4_Articles/Drafts/_resources/草稿 - 超越Vibe Coding：我们如何用“Spec Coding”工作流，驾驭AI进行严肃开发/d7e2d6202f41242e0368361fdd78caa3_MD5.jpeg]]

这个循环听起来很“学院派”，但在AI时代，它是我能找到的最高效的“人机协作”模式。我的具体做法是：

  1. 我（人类）准备“对话启动器”： 我会为这个子任务，准备一个简短的“AI指令包”。这就像给实习生布置任务的开场白：“这是任务目标（@Issue-123），这是测试策略，这是必须遵守的规范（@rules/220-wf-linear-issue.mdc）”。
  2. 🔴 我指令AI (红环)： “好了，AI。根据指令包，第一步，先给我写一个必然会失败的测试用例。” 这是Spec（规格）先行，我用测试来定义“我想要什么”。
  3. 🟢 我与AI对话 (绿环)： “OK，测试失败了，符合预期。现在，我们来写代码。你的唯一目标，就是用最少的代码让这个测试变绿。” 在这个阶段，我会和AI高频对话（“Just Talk To It”），它写一小段，我验证一下，它再改一小段。
  4. 🔵 我与AI重构 (重构环)： “很好，测试通过了。但代码有点乱。现在，我们来‘打扫战场’。帮我重构它，确保遵循@rules/010-gen-coding-standards.mdc 规范，并且所有测试必须仍然通过。”

这个循环，彻底改变了AI开发流程。

这样一来，AI不再是那个天马行空、无法定位的“魔术师”，它成了我TDD循环 里一个被“纪律”约束的、指哪打哪的“执行者”。我的AI Coding开发工作，从“写一个大功能”，被降维成了“通过一个小测试”。

这个过程的交付物，不再是一堆“黑盒代码”，而是一个个高质量的、经过测试验证的、并严格遵循规范的“原子化提交”。

阶段3：集成与交付

当这个 Epic 下的所有子任务（Issues） 都通过TDD循环 变成了一个个“原子化提交” 后，这些提交就共同构建在了我们的 feature/ 分支上。

最后一步，就是集成与交付：

我们会从这个 feature/ 分支，向 main 主分支发起一个 Pull Request。

在合并之前，我会使用标准化的 PR 模板 (.github/PULL_REQUEST_TEMPLATE.md)，进行最后一次“人类”的自我审查。我会对照着“史诗作战计划” 中的验收标准，逐一确认所有功能均已满足 Definition of Done (DoD)。

只有当所有审查和集成测试都通过后，这个 PR 才会最终被合并（Merge） 到 main 分支，完成交付。

结语：从“AI魔术师”到“AI工程师”

我们都向往“Vibe Coding” 的理想目标——那种“言出法随”的魔法，你只要说话，AI就能完美实现一切。

但我们必须承认一个现实：以当前AI（无论是Claude、GPT还是Devin）的能力，它还远远不足以支撑这个理想。 它依然是一个强大、但极不稳定、充满幻觉、且无法自我验证的“实习生”。

纯粹的“Vibe Coding”，目前带来的还不是“魔法”，而是难以维护的“技术债务”。

而 “Spec Coding” 追求的是“工程”。正因为 AI还不够智能，我们才必须用“VCA一致性分析” 和“TDD循环” 这样的“纪律” 来武装它，来控制它。

AI 工具在变，但软件工程追求清晰、严谨、可验证的本质没变。

这套“Spec Coding”工作流，正是我们“痴迷于‘决策模型’的独立开发者” 身份的完美体现。

你是否也在实践类似的“规范化”流程？你有哪些驾驭AI的独门秘诀？欢迎加入社群，分享你的“AI工程学”。