本文永久链接 – 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 小时正确地实现它。”

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

1. 从“对话漂移”到“稳定文档”：AI 对话上下文易混乱。而一份 .md 格式的 Spec 文档是稳定的，是可靠的真理来源。

2. 从“单人独舞”到“团队协作”：AI 聊天记录是私人的。而一份 Spec 文档，你可以轻松地把它交给同事，或者自己过一周再捡起来，上下文清晰如初。

3. 从“毫无章法”到“版本控制”：Git 无法追踪对话历史。但它可以完美追踪一份 WidgetFeature.md 的演进。

4. 从“功能蔓延”到“范围明确”：一个模糊的请求可能被 AI 无限解读。而一份明确的 Spec 则彻底杜绝了功能蔓延。

5. 从“上下文丢失”到“即时恢复”：项目搁置一周，忘了当初为何这么设计？有了 Spec，你可以瞬间恢复全部上下文。

6. 从“空白页恐惧症”到“结构化开始”：面对新功能不知从何下手？现在，AI 成了你的文档助理，帮你提出结构，你只需批判和填充。

7. 从“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技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/07/01/predicting-the-future-of-distributed-systems

大家好，我是Tony Bai。

身处技术浪潮之中，我们每个人或许都曾有过这样的焦虑：新的数据库、新的编程模型、新的 AI 框架层出不穷，我该如何选择？选错了，会不会让团队陷入泥潭，给自己留下难以偿还的技术债？

最近，特斯拉首席工程师 Colin Breck 在 Craft 2025 大会上做了一场题为《预测分布式系统的未来》的精彩分享。他并没有给出非黑即白的答案，而是提供了一个极其强大的思维武器，来帮助我们拨开迷雾，做出更有效的工程决策。这个武器，就是源自亚马逊创始人 Jeff Bezos 的——“单向门 vs. 双向门”决策框架。

今天，我们就以这个框架为钥匙，跟随 Colin 的思路，去打开分布式系统的未来之门。

决策的“导航仪”：单向门 vs. 双向门

在深入技术细节之前，我们必须先理解这个核心框架。它将决策分为两类：

1. 单向门 (One-Way Door)： 这类决策后果严重，且难以逆转，甚至根本无法回头。一旦你迈进了这扇门，想再出来就要付出巨大的代价。对于“单向门”决策，Bezos 的建议是：必须极其谨慎，放慢速度，召集最相关的人，尽可能多地收集信息再做决定。

2. 双向门 (Two-Way Door)： 这类决策的影响不大，即使做错了，也可以轻松地“退出来”，再选择另一扇门。它的试错成本很低。对于“双向门”决策，应该快速、轻量地由个人或小团队做出，以保持高效率。

这个框架最大的价值在于，它提醒我们警惕一个致命的错误：把一个“单向门”决策，当作“双向门”来草率处理。 这种失误，可能会让你的组织背上沉重的技术包袱，长达数年。

现在，让我们带着这个“导航仪”，去审视 Colin 预测的分布式系统三大趋势。

趋势一：对象存储 —— 充满“双向门”的乐园

Colin 的第一个预测是，对象存储（以 S3 为代表）正在从过去的分析型负载，越来越多地走向事务型和操作型负载，成为下一代数据库和系统的基石。

为什么这个趋势如此确定？因为它为我们创造了大量的“双向门”。

过去，我们选择一个数据库（比如 MySQL），我们的数据、查询方式、扩展模式都被这个“整体”方案深度绑定。想从 MySQL 迁移到 PostgreSQL？这是一项艰巨的任务，更像一扇“单向门”。

而基于对象存储的新架构正在“解体”(Disaggregation) 传统数据库，将其拆分为多个可自由组合的组件：

• 统一的存储层： S3 API 已成为事实标准。你可以用 AWS S3，也可以用 Google Cloud Storage，或者在本地部署 MinIO。更换存储后端的门是“双向”的。
• 开放的数据格式： Parquet、ORC等开放格式让你的数据不再被数据库私有格式锁定。今天你可以用 Spark 分析它，明天可以用 DuckDB 查询它，后天可以加载到 Snowflake。更换计算引擎的门是“双向”的。
• 可插拔的计算/查询引擎： DuckDB、DataFusion 这类库的崛起，让我们能像使用 SQLite 一样，直接对 S3 上的 Parquet 文件执行高性能 SQL 查询。这个查询引擎不满意？换一个！这扇门也是“双向”的。

这种架构的核心是互操作性与可移植性。它通过标准化和解耦，极大地降低了我们的决策风险和迁移成本。 正因为到处都是“双向门”，开发者可以放心大胆地拥抱这个趋势。

趋势二：新编程模型 —— 遍布“单向门”的迷宫

与对象存储的清晰图景相反，Colin 认为下一代编程模型的未来则要模糊得多，充满了艰难的“单向门”决策。

我们当前的开发模式（容器 + 应用代码 + 一堆库）存在很多问题：每个应用都在重复解决持久化、重试、状态管理等难题；安全补丁也难以管理。

为了解决这些问题，涌现出了一批新的编程模型，例如：

• 持久化工作流平台： 如 Temporal
• 分布式应用运行时： 如 Akka Platform、WasmCloud
• 独特的运行时环境： 如 Gollum、Unison

它们的目标很宏大：让开发者只关心业务逻辑，把持久化执行、状态管理、部分失败处理等分布式难题下沉到基础设施。

但选择其中任何一个，都几乎是一个不可逆的“单向门”决策。为什么？

1. 巨大的投资： 这不仅是金钱投入，更是整个团队的学习成本和思维模式的转变。
2. 深度锁定： 你的核心业务逻辑将与平台的 API 和抽象深度绑定，想迁移出去？难于登天。
3. 生态系统风险： 这个平台或框架五年后还活着吗？如果它死掉了，你的系统怎么办？

正因为这些决策都是沉重的“单向门”，大多数团队宁愿继续使用 Kubernetes + 应用容器这种“我们已经知道”的模式，也不愿轻易踏入这个迷宫。

趋势三：AI 工程化 —— 可能是打开“单向门”的催化剂

那么，僵局如何打破？Colin 认为，催化剂可能就是 AI。

他一针见血地指出：“所谓的 AI 工程化（Operationalizing AI），其本质就是系统工程。”

那些时髦的术语背后，无论是 AI 工作流（AI Workflows）还是智能体（Agentic AI），其核心都是在解决经典的分布式系统难题：如何管理长周期任务、如何保证持久化执行、如何处理状态、如何容错……正如那句经典吐槽：“到35岁，你应该已经重复造过工作流引擎、任务队列和对象关系映射的轮子了。”

AI 的浪潮带来了巨大的需求压力和创新动力，使得人们愿意去冒更大的风险，去尝试那些能解决这些复杂问题的“单向门”方案。一个创业公司为了快速实现一个复杂的 AI Agent，可能会选择直接拥抱 Temporal，因为从头造轮子的成本更高。

但这同样是一个陷阱。Colin 警告说，要警惕那些看似“先跑起来再说”的“双向门”决策，比如随便搭一个临时的任务队列来驱动 AI 应用。这种决策很可能在未来演变成一笔巨大的、难以偿还的技术债，最终变成一个你当初没意识到的“单向门”。

给 Gopher 的启示：用“门”的思维审视我们的技术栈

这个决策框架对我们 Gopher 来说，同样具有极强的指导意义。我们可以用它来审视日常的技术选型：

• 选择 Web 框架（Gin vs. 标准库）： 这更像一个“双向门”。Gin 遵循了标准库的 http.Handler接口，即使以后想换，迁移成本也是可控的。
• 引入一个新的数据库（PostgreSQL vs. TiDB）： 这更偏向“单向门”。它涉及到数据模型、ORM、运维、团队知识储备等方方面面，一旦深入使用，更换成本极高。
• 采用一个微服务框架（Go-kit vs. Kratos）： 这也接近“单向门”。它会深度影响你的项目结构、RPC 方式、服务治理逻辑，更换起来伤筋动骨。

反观 Go 语言自身的设计哲学——简洁、小接口、组合优于继承——是不是正是在鼓励我们创造更多的“双向门”？Go 避免了庞大而笨重的“全家桶”式框架，而是提供小而美的标准库和可组合的组件，让我们能以更低的锁定风险构建系统。这本身就是一种降低决策成本的智慧。

小结：决策的智慧，在于选择正确的“门”

Colin Breck 的分享，并没有给我们一张未来的藏宝图，而是给了我们一个更宝贵的东西：一个决策的指南针。

技术世界里没有绝对的“好”与“坏”，只有在特定场景下的“合适”与“不合适”。“单向门 vs. 双向门”框架的价值，不在于帮你找到唯一的正确答案，而在于帮你为不同类型的决策，建立起正确的决策流程。

对于那些充满不确定性、一旦走错就万劫不复的“单向门”，请务必保持敬畏，放慢脚步。而对于那些无伤大雅的“双向门”，不妨大胆尝试，快速迭代。

正如 Colin 在结尾引用的那句话：“让我们的抽象保持流动性。” 这或许不仅是对技术架构的建议，更是对我们决策方式的邀请——去寻找和创造尽可能多的“双向门”，以降低风险、拥抱变化，并保护我们最宝贵的投资：时间和精力。

你最近面临过哪些“单向门”或“双向门”决策？你是如何思考的？欢迎在评论区分享你的故事。

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

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。