别再直接让 AI 写代码了！试试这个“Vibe Specs”模式，效率提升60%

本文永久链接 – https://tonybai.com/2025/07/02/vibe-specs

大家好，我是Tony Bai。

你是否也曾掉入 AI 编程的“氛围陷阱”？

你坐在 IDE 前，脑海中有一个自以为清晰的任务。你信心满满地打开 AI 助手，给出一个模糊的指令，也就是所谓的“氛围”编程 (Vibe Coding)。结果，AI 像一个过度热情的实习生，还给你一堆看似合理但完全无用的“废话软件”(slop software)，让你陷入无尽的修改和挫败。

如果我告诉你，有一种简单的工作流转变，不仅能解决这个问题，还能将你的功能开发时间减少约 60%，你会不会觉得难以置信？

最近，一篇名为《Vibe Specs: Vibe Coding That Actually Works》的文章分享的正是这样一个简单却颠覆性的模式。它的核心就是：别再直接让 AI 写代码了！

在这篇文章中，我们就来看看文章中提到的Vibe Specs究竟是如何提升AI编码的效率和准确性的。

核心解法：拥抱“规范先行” (Spec-First)

文章提出的新范式，彻底颠覆了传统的 AI 编程流程。它将 Prompt -> Code 的直接路径，转变为一个更稳健、更高效的三步曲：

LLM -> Spec -> Code

这意味着，与 AI 助手的第一步交互，不是让它写代码，而是让它帮你写一份需求规范 (Specification, Spec)。

这里的精髓在于一个关键的角色转变：

你不再需要费尽心机地写一份完美的 Spec，而是由 AI 扮演“产品经理”或“需求分析师”的角色来“采访”你。

它会主动提问，引导你澄清目标、确定范围、明确核心功能、思考边界条件。而你的工作，仅仅是“批判、调整和澄清”。

天壤之别：一个“Before & After”的真实对比

让我们来看一个真实的例子，感受一下“规范先行”的威力。

Before：直接生成代码 (Vibe Coding)

你： “帮我创建一个处理搜索功能的 API 路由。”
AI： （兴奋地）“好的！马上为您实现一个基础的搜索端点！”
- （一顿操作，创建了 pages/api/search.js, utils/searchHelpers.js, lib/database.js 等一堆文件，+98行代码）
AI： “我已经实现了一个全面的搜索 API，支持：全文搜索、分页、模糊匹配、结果排序、缓存层……还需要加上搜索分析吗？”
你：（崩溃地）“天啊，首先这根本跑不起来；其次你用的这些系统我们根本没有；再次……”
- （半个工作日过去了，最终在沮丧中删掉分支）

After：“规范先行” (Spec-First)

你： “帮我创建一个处理搜索功能的 API 路由。”
AI： （礼貌地）“非常乐意！不过在开始编码前，我能先为您创建一份规范 (Spec) 吗？这能帮助我们精准地定义您需要的功能。”
你： “好，就这么办。”
AI： （开始提问）“太好了！请问：
1. 用户要搜索什么？（商品、博客、用户？）
2. 哪些字段需要被搜索？（仅标题，还是标题+内容？）
3. 需要哪些搜索特性？（精确匹配、模糊匹配、大小写敏感？）
4. 您正在使用什么数据库？（PostgreSQL, ES?）
  …”
你： “我们是搜索博客文章，只搜标题和内容字段，不区分大小写的模糊匹配就行。用的是 PostgreSQL，这是个小博客，性能不关键。”
AI： “完美！我来为您生成一份规范文档。”
- （生成一份清晰的 blog-search-api.md 文件，+35行）
你： “看起来很棒，开干吧 (GO)！”
AI： “收到！现在我将基于这份规范来实现 API。”
- （生成一个 pages/api/search.js 文件，仅24行精准、聚焦的代码）
AI： “我已经实现了完全符合规范的 API，它支持：……需要我为您添加一个简单的测试文件吗？”

对比是惊人的。后者不仅代码质量更高、完全符合需求，更重要的是，它尊重了你的时间和认知负荷。

“规范先行”的七大好处：支撑 60% 效率提升的秘密

这种工作流的转变，解决了当前 AI 辅助开发中一系列令人头疼的问题。也正是这些好处的叠加，构成了效率大幅提升的基础。在原文中，作者 Luke Bechtel 分享了他的亲身经历：

“（使用这个模式后）我估计我的功能开发时间减少了约 60%，而且产出的结果质量更高。过去需要花 2-3 小时实现后才发现做错了，现在只需要花 10-20 分钟规划，然后花 1 小时正确地实现它。”

让我们看看这背后是哪七大支柱在起作用：

从“对话漂移”到“稳定文档”：AI 对话上下文易混乱。而一份 .md 格式的 Spec 文档是稳定的，是可靠的真理来源。
从“单人独舞”到“团队协作”：AI 聊天记录是私人的。而一份 Spec 文档，你可以轻松地把它交给同事，或者自己过一周再捡起来，上下文清晰如初。
从“毫无章法”到“版本控制”：Git 无法追踪对话历史。但它可以完美追踪一份 WidgetFeature.md 的演进。
从“功能蔓延”到“范围明确”：一个模糊的请求可能被 AI 无限解读。而一份明确的 Spec 则彻底杜绝了功能蔓延。
从“上下文丢失”到“即时恢复”：项目搁置一周，忘了当初为何这么设计？有了 Spec，你可以瞬间恢复全部上下文。
从“空白页恐惧症”到“结构化开始”：面对新功能不知从何下手？现在，AI 成了你的文档助理，帮你提出结构，你只需批判和填充。
从“Token 浪费”到“高效利用”：与其把 Token 浪费在漫无目的的对话上，不如用它们来生成和解析结构化的 Spec，得到更精准的响应。

小结：慢即是快，LLM -> Spec -> Code

我们总想“快速行动，打破常规”，但正如文章所言：

“如果创造出来的东西是无用的，那么创造得再快也毫无意义。”
(It doesn’t matter how quickly you can create something if it’s useless)

“规范先行”的模式，看似在编码前增加了短短 5 分钟的“文书工作”，但它节省的，是后续数小时甚至数天的重构、调试和返工时间。这才是标题中“效率提升 60%”的真正奥秘，是真正的“慢即是快”。

对AI Agent 同样有效：更高层次的“规范先行”

你可能会想，这套流程对于我们与 Copilot、Cursor 这类“助手”的交互很有效，但如果未来我们使用的是更高级的、自主性更强的 AI Agent 呢？它们不是应该能更好地理解我们的模糊意图吗？

恰恰相反，“规范先行”的思想对于与 AI Agent 的协作可能更为重要。

一个 AI Agent 本质上是一个更强大的执行者，它拥有调用工具、访问文件、执行命令的能力。如果你给它的指令依然是模糊的“Vibe”，它可能会以一种更具破坏性的方式去“自由发挥”——或许会调用错误的 API，修改不该动的文件，甚至陷入昂贵的执行循环。

在这种场景下，“Vibe Specs”扮演的角色，从一份“需求文档”，升级为一份给 Agent 的“行动计划”或“任务指令书”。

输入： 你和 AI Agent 通过对话，共同制定出一份高级别的行动计划（即 Spec），明确最终目标、关键步骤、允许使用的工具、禁止操作的边界、以及衡量成功的标准。
执行： Agent 将这份结构化的计划作为其核心指令，自主地去分解任务、执行步骤。
监控： 这份 Spec 也成为了你监控和评估 Agent 工作表现的基准。你可以清晰地看到它执行到了哪一步，结果是否符合预期。

因此，无论 AI 的形态如何演进，从辅助编码的“副驾驶”，到自主行动的“智能体”，“先定义清楚问题，再着手解决” 这个软件工程的第一性原理依然适用。“规范先行”不仅没有过时，反而在更高阶的人机协作中，扮演了“安全带”和“导航图”的关键角色。

AI 辅助开发的未来，不在于生成更花哨的代码，而在于更精准的需求表达。让我们拥抱 LLM -> Spec -> Code 这一新范式，把 AI 从一个喋喋不休、自作聪明的实习生，变成一个严谨、高效、懂得倾听的资深架构师。

这才是 AI 编程的正确打开方式。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？