• 原文地址：https://dev.to/incomplete_developer/spec-driven-development-return-of-best-practices-44b0
• 原文作者：Incomplete Developer

---

AI 已经极大地改变了开发人员编写软件的方式。借助现代 AI 编码工具，开发人员可以在短时间内生成大量代码。

这种转变催生了如今许多人所说的 “氛围编程（vibe coding）”。开发人员编写简短的提示词，让 AI 生成解决方案。

这种方法确实有效 —— 但仅限于它失效之前。

尤其是在正式的企业环境中，团队规模庞大，软件工程最佳实践是无可妥协的。

纯粹氛围编程的问题

氛围编程代表了软件生成方式的最大变革之一。AI 能够以惊人的速度产出大量代码。

但最大的问题 不是氛围编程本身。

真正的问题在于，开发人员开始把 AI 当作 魔法棒，完全依赖快速提示，而忽略了那些本可以产出可靠软件的工程实践。

随着时间的推移，许多开发人员开始丢弃诸如：

• 架构规划
• 用户故事与待办事项管理
• 验收标准
• 任务拆分
• 编码规范
• 测试策略

所有这些实践之所以存在，是有原因的：它们提高了交付高质量产品的可能性。

企业级软件开发从来 不只是快速写代码。

而是要构建 可被团队维护、扩展和理解 的系统。

企业开发远不止代码

在真正的企业团队中，软件开发通常遵循 敏捷工作流。

这意味着：

• 特性被定义为 用户故事
• 故事在 迭代或冲刺 中实现
• 每个故事都有 验收标准
• 每个故事被拆分为 技术任务
• 代码必须与 现有架构 集成
• 必须避免重复功能

当开发人员仅依赖氛围编程时，这些保障措施常常消失。

结果可能是：

• 技术债务
• 意大利面条式代码
• 重复模块
• 糟糕的架构
• 难以维护的系统

氛围编程擅长 快速生成代码，但如果它取代了结构化开发，很容易引入长期问题。

当氛围编程遇到现实

网上关于 AI 生成令人印象深刻的代码却很快变成混乱代码库的段子，完美地捕捉了这个问题。

它们说明了当氛围编程被用于构建 复杂的企业级系统 时会发生什么。

真正的软件项目是 长期持续的努力。

它们会在多个迭代、版本和冲刺中不断演进。构建一个严肃的产品是 一场马拉松，而不是短跑。

但 AI 聊天会话有 上下文限制。它们无法记住一个大型项目在数月开发中的全部历史。

没有结构，AI 很快会丢失：

• 架构决策
• 之前实现的功能
• 业务规则
• 系统中的约束

代码质量随之下降。

老派规则仍然适用

这就是 规格驱动开发（Spec-Driven Development） 的用武之地。

规格驱动开发是为那些使用 AI 构建 专业、可扩展软件 的开发人员设计的。

它摒弃了自由发挥的提示，转而引入 结构和规划。

在规格驱动的工作流中，与 AI 互动的乐趣和随性被更传统的东西取代：

• 书面需求
• 产品愿景
• 用户故事
• 验收标准
• 架构计划
• 测试和编码标准

换句话说，就是 专业团队几十年来所依赖的所有“枯燥”流程。

在规格驱动的开发方法流行之前，许多开发人员在没有这种结构约束的情况下使用 AI 生成代码。

结果往往是一堆 支离破碎的代码，修复它比生成它花费的时间更长。

从氛围编程到规格驱动开发

规格驱动开发引导 AI 代理更像 有纪律的高级开发人员 那样行事，而不是代码生成机器。

它适用于可能需要 数月才能完成 的项目，其中 AI 必须保持有关产品需求的上下文并跟踪开发进度。

开发人员不是发送即时提示词，而是创建一份 规格（“spec”）。

这份规格成为 AI 的 唯一事实来源。

它通常包括：

• 高层应用概述
• 技术选型
• 架构约束
• 业务规则
• 实施指南

然后 AI 在 该规格的边界内 生成代码。

规格驱动的工作流

“规约” 这个词可能听起来令人生畏，但它也可以简单理解为给应用创建一个 结构化计划。

典型的工作流包括：

1. 高层应用信息

产品的描述、目标及其主要组件。

2. 架构与实施计划

系统应如何构架，以及模块之间如何交互。

3. 用户故事与开发任务

必须构建的功能，拆分为可管理的工作单元。

开发人员不一定需要手动编写所有这些内容。

一些新兴框架有助于自动化这个过程，包括：

• OpenSpec
• GitHub Speckit
• BMAD

这些工具有助于生成结构化规格，同时 让开发人员负责审查和批准该计划。

真正的好处：强制执行最佳实践

规格驱动开发的真正力量不仅仅在于改进 AI 提示。

更在于 强制开发人员在生成代码之前思考架构和设计 这个过程。

它还鼓励团队 一次只关注一个特性，类似于敏捷团队在现实中的工作方式。

就像在 Scrum 中一样：

• 每段代码都关联一个 待办项
• 每个故事都有 完成定义
• 每个任务都适配 计划的迭代

因此，规格驱动的工作流复刻了专业团队构建软件的方式。

AI 无法替代的部分

关于规格驱动开发最重要的洞见是：

它带回了软件开发中那些无法外包的部分 —— 即使给 AI 也不行。

那些部分包括：

• 编码之前进行思考
• 定义产品愿景
• 就需求达成一致
• 设计架构
• 确立完成定义

对于独立开发者，规格充当的是 思考框架。

对于团队，它成为 活的文档，捕捉对产品的共同理解。

AI 帮助生成代码，但 人类仍然对思考负责。

氛围编程仍有其用武之地

氛围编程仍然非常有用。

它非常适合：

• 原型验证
• 探索 API
• 快速实验
• 构建小型工具

但在企业环境中，软件开发远不止于快速生成代码。

它关乎 构建长久的系统。

而规格驱动开发重新引入的实践 —— 规划、架构和共享文档 —— 它们的存在是有理由的。

AI 可以加速开发，但 良好的工程纪律仍然是防止复杂系统崩溃的关键。