[译]Spec-driven development with AI: Get started with a new open source toolkit
开发者可以使用他们选择的 AI 工具，借助这一开源工具集进行规范驱动开发。
作者： Den Delimarsky | 发布日期： 2025年9月2日
随着编程智能体变得越来越强大，一种模式浮现了出来：你描述你的目标，然后拿到一段代码，但往往……它看起来是对的，实际上却不太能用。这种”氛围编程”（vibe-coding）的方式对于快速原型来说可能很好，但在构建严肃的、关键任务的应用程序或与现有代码库协作时就不那么可靠了。
有时代码甚至无法编译。有时它解决了部分问题，却遗漏了真正的意图。技术栈或架构可能也不是你想要的。
问题不在于编程智能体的编码能力，而在于我们的使用方式。我们把编程智能体当作搜索引擎来用，而实际上应该把它们当作较真的结对程序员来对待。它们擅长模式识别，但仍然需要明确的指令。
这就是为什么我们要重新思考规范——不再将规范视为静态文档，而是将其视为与项目共同演进的、活的、可执行的产物。规范成为了共享的真理来源。当有些事情说不通时，你回到规范上；当项目变得复杂时，你优化规范；当任务感觉太大时，你把它们拆解开来。
Spec Kit 是我们新开源的面向规范驱动开发的工具集，它提供了一个结构化的流程，将规范驱动开发带入你的编程智能体工作流中，支持 GitHub Copilot、Claude Code 和 Gemini CLI 等工具。
💡 什么是规范驱动开发？
在规范驱动开发中，你不是先写代码再补文档，而是从一个规范开始（没错，就是你想的那样）。这是一份关于你代码应如何工作的契约，也是你的工具和 AI 智能体用来生成、测试和验证代码的真理来源。结果是更少的猜测、更少的意外和更高质量的代码。
使用 Spec Kit 的规范驱动流程是怎样的？
Spec Kit 将你的规范置于工程流程的中心。不是写一份规范就搁置一旁，而是由规范驱动实现、检查清单和任务拆解。你的主要角色是指引方向；编程智能体负责大部分具体编写工作。
整个过程分为四个阶段，每个阶段都有明确的检查点。但这里的关键洞见是：每个阶段都有其特定的职责，在当前阶段的工作被充分验证之前，你不会进入下一个阶段。
流程拆解如下：
制定规范（Specify）：你提供关于你要构建什么以及为什么要构建的高层描述，编程智能体生成一份详细的规范。这不是关于技术栈或应用设计，而是关于用户旅程、用户体验，以及成功是什么样的。谁会使用它？它为他们解决了什么问题？他们将如何与它交互？什么结果才是重要的？可以把它想象成绘制你想要创造的用户体验地图，然后让编程智能体来充实细节。关键在于，它会成为一份活的产物，随着你对用户及其需求的了解加深而不断演进。
制定计划（Plan）：现在进入技术层面。在这个阶段，你向编程智能体提供你想要的技术栈、架构和约束条件，编程智能体则生成一份全面的技术计划。如果你的公司对某些技术有标准化要求，这就是你要说明的地方。如果你需要集成遗留系统、有合规要求或需要达到某些性能目标……所有这些都在这里体现。你也可以要求提供多种计划变体，以便比较和对比不同的方法。如果你把内部文档开放给编程智能体，它可以将你的架构模式和标准直接融入计划中。毕竟，编程智能体在开始参与之前需要先理解游戏的规则。
分解任务（Tasks）：编程智能体基于规范和计划，将其分解为实际的工作项。它会生成小而可审查的任务块，每个任务解决一个特定的子问题。每个任务都应该能够独立实现和测试；这一点至关重要，因为它给了编程智能体一种验证其工作并保持在正确轨道上的方式，就像为你的 AI 智能体设计的一种测试驱动开发过程。而不是”构建身份认证”这样的大任务，你会得到像”创建一个验证邮箱格式的用户注册接口”这样具体的任务。
实现（Implement）：你的编程智能体逐一处理这些任务（或者在适用的情况下并行处理）。但这里的区别在于：你不是审查上千行代码的堆砌，而是审查专注于解决特定问题的聚焦式变更。编程智能体知道要构建什么，因为规范告诉了它；知道如何构建，因为计划告诉了它；知道具体要做什么，因为任务告诉了它。
关键的是，你的角色不仅仅是引导方向，更是验证。在每个阶段，你都需要反思和优化。规范是否准确捕捉了你真正想构建的内容？计划是否考虑到了现实世界的约束？AI 是否有遗漏或未覆盖的边缘情况？这个流程在每个阶段都内置了明确的检查点，让你对生成的内容进行评审，发现漏洞，并在继续前进之前修正方向。AI 负责生成产物；你负责确保它们是正确无误的。
如何在你的智能体工作流中使用 Spec Kit
Spec Kit 可以与 GitHub Copilot、Claude Code 和 Gemini CLI 等编程智能体配合使用。关键在于使用一系列简单的命令来引导编程智能体，然后由它来完成生成产物的繁重工作。
设置非常简单。首先，安装 specify 命令行工具。这个工具会初始化你的项目并设置必要的结构。
1 | uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME> |
项目初始化后，使用 /specify 命令提供一个高层的提示词，编程智能体会生成完整的规范。专注于项目的”做什么”和”为什么”，而不是技术细节。
接下来，使用 /plan 命令引导编程智能体创建技术实现计划。在这里，你提供高层次的技术方向，编程智能体会生成一份尊重你的架构和约束的详细计划。
最后，使用 /tasks 命令让编程智能体将规范和计划分解为一组可执行的任务列表。然后你的编程智能体将使用这个列表来实现项目需求。
这种结构化的工作流将模糊的提示词转化为清晰的意图，让编程智能体能够可靠地执行。
但为什么这种方法在模糊提示词失败的地方却能够成功呢？
为什么这样做有效
这种方法之所以能在”只是向 AI 提问”失败的地方取得成功，源于语言模型工作的一个基本事实：它们非常擅长模式补全，但不擅长读心术。一个像”给我的应用加个照片分享功能”这样的模糊提示词，会强迫模型在数千个未声明的需求上进行猜测。AI 会做出合理的假设，但其中一些会是错误的（而且你往往直到实现已经很深入时才会发现哪些不太对）。
相比之下，预先提供清晰的规范，配合技术计划和聚焦的任务，给编程智能体更多的清晰度，从而提升它的整体效能。它不需要猜测你的需求，而是知道要构建什么、如何构建以及按什么顺序构建。
这就是为什么这种方法适用于不同的技术栈。无论你是在用 Python、JavaScript 还是 Go 进行开发，根本的挑战是相同的：将你的意图转化为可工作的代码。规范清晰地捕捉意图，计划将意图转化为技术决策，任务将决策拆解为可实现的单元，而你的 AI 编程智能体负责实际的编码。
对于大型组织，这还解决了另一个关键问题：你所有的安全策略、合规规则、设计系统约束和集成需求应该放在哪里？通常，这些东西要么只存在于某个人的脑子里，要么埋在没人阅读的维基页面里，要么分散在事后根本找不到的 Slack 对话中。
有了 Spec Kit，所有这些内容都会被写进规范和计划中，AI 可以真正地使用它们。你的安全需求不是事后才补上的，而是从第一天起就融入到规范中。你的设计系统也不是后来才附加的，而是技术计划中指导实现的一部分。
这种方法的迭代特性赋予了它真正的力量。传统开发会把你锁定在早期的决策里，而规范驱动让改变方向变得简单：只需更新规范，重新生成计划，然后让编程智能体处理剩下的事情。
三个这种方法特别有效的场景
规范驱动开发在以下三种场景中特别有用：
绿地项目（从零到一）：当你开始一个新项目时，很容易直接就写代码。但少量的前期工作来制定规范和计划，可以确保 AI 构建出你真正想要的东西，而不是一个基于通用模式的通用解决方案。
现有系统中的功能开发（从 N 到 N+1）：这是规范驱动开发最强大的地方。在复杂且已有的代码库中添加功能是很困难的。通过为新功能制定规范，你迫使自己清晰地思考它应该如何与现有系统交互。然后计划会将架构约束编码进去，确保新代码感觉是项目原生的，而不是一个硬塞进去的附加物。这使得持续开发更快、更安全。要做到这一点，可能需要高级的上下文工程实践——我们将另外详细讨论。
遗留系统现代化：当你需要重建一个遗留系统时，原始的意图往往已随时间流逝而丢失。借助 Spec Kit 提供的规范驱动开发流程，你可以在现代规范中捕捉核心业务逻辑，在计划中设计全新的架构，然后让 AI 从零开始重建系统，而不会继承过去积累的技术债务。
核心收益在于将稳定的”做什么”与灵活的”怎么做”分离开来，从而实现迭代开发而无需昂贵的重写。这让你能够构建多个版本并快速实验。
我们的前进方向
我们正从”代码即真理来源”转向”意图即真理来源”。有了 AI，规范成为了真理来源，决定了什么被构建出来。
这不是因为文档变得更重要了。而是因为 AI 使规范变得可执行了。当你的规范自动转化为可工作的代码时，它就决定了什么被构建出来。
Spec Kit 是我们将这一转变变为现实的实验。我们将它开源，因为这种方法比任何单一工具或公司都更宏大。真正的创新是这个流程本身。我们很快会分享更多内容，特别是关于如何将规范驱动开发的实践与上下文工程相结合，在你的 AI 工具集中构建更高级的能力。
我们很乐意听到你使用它的效果以及我们可以改进的地方！如果你正在使用规范驱动的模式进行构建，请分享你的经验。我们特别好奇以下几个方面：
让工作流更吸引人、更易用：阅读大段的文字可能很枯燥。我们如何让这个过程真正令人愉悦？
可能的 VS Code 集成：我们正在探索如何将这个工作流直接带入 VS Code。对你来说什么样的方式最自然？
比较和对比多个实现版本：在多个实现之间进行迭代和对比打开了创造性的可能性。在这方面什么对你最有价值？
在组织中大规模管理规范与任务：管理大量的 Markdown 文件可能会让人不堪重负。什么能帮助你保持井井有条和专注？
我们期待看到你利用 AI 来找到更好的方式，将人类的创造力转化为可工作的软件。
首席产品经理