项目功能、设计目标和适用范围

GitHub 于 2025 年 9 月开源了 Spec Kit 项目，这是一个专为**规格驱动开发（Spec-Driven Development, SDD）设计的工具包。它的主要功能是提供一套结构化流程和 CLI 工具（名为 specify）来引导 AI 编程助手根据规范自动生成高质量软件，实现“规格即代码”**的理念。Spec Kit 旨在改变传统“代码为王”的开发范式，将需求规范提升为第一公民，让代码服务于规范。在 Spec Kit 方法中，规范不再是开发前的临时支架，而是会逐步演化为可执行的“唯一真相”，直接驱动实现代码。

项目整体设计目标是通过结构化的规范和多阶段流程，减少 AI 编码过程中的不确定性和偏差，提升代码与需求意图的一致性。Spec Kit 提供了一系列模板和约定，使开发者专注于产品需求场景而非重复的样板化编码。它将开发分为明确的阶段：

1. Specify (编写规范)

2. Plan (制定技术方案)

3. Tasks (分解任务)

4. Implement (执行实现)

每个阶段都有清晰的产出物，例如需求规格说明、架构设计文档、任务清单和自动生成的代码等。这一过程要求当前阶段完全验证后再进入下一阶段，保证每一步的产物都准确无误。

Spec Kit 的适用范围相当广泛，覆盖从全新项目的开发到现有系统的功能扩展乃至遗留系统的现代化改造等多种场景。

• 对于零开始的新项目：Spec Kit 促使开发者在编码前明确用户故事和成功标准，从而避免不必要的返工。

• 对于在现有代码库上增添新特性：Spec Kit 通过规范澄清新功能与旧系统的交互方式，并在计划中编码架构约束，确保新增代码与现有系统保持一致。

• 对于重构遗留系统：开发者可以借助规范提炼业务逻辑，用全新的架构计划让 AI 从头构建系统而不继承旧的技术债。

总的来说，Spec Kit 被设计为与具体技术、编程语言无关的通用流程，其底层假设是“规格驱动开发是一种不依赖特定技术栈的过程”。因此，无论是前端应用、后端服务还是脚本工具，都可以在 Spec Kit 框架下通过规范来驱动实现。

---

跨编程语言和技术栈的使用方法

Spec Kit 具有技术栈独立性，支持在多种编程语言和环境下使用同样的方法论流程。Spec Kit 本身以 Python 实现（提供了 specify CLI），可在 Linux、macOS 和 Windows (WSL/PowerShell) 等环境安装运行。

初始化 Spec Kit 项目时，用户需要选择所使用的 AI 编码助手（如 GitHub Copilot、Anthropic Claude Code、Google Gemini CLI 等），Spec Kit 会针对不同助手生成相应的提示命令模板和目录结构。例如，通过命令行 specify init 初始化项目时，可以交互选择 AI Agent 为 Copilot 或 Claude Code 等。不同 Agent 会在项目中生成对应的配置（如 .github/ 目录下的 prompt 文件）以适配它们的用法。

在具体编程语言方面，Spec Kit 并不限制使用哪种语言或框架。开发者在 Plan 阶段可以指定偏好的技术栈、架构风格和约束条件。例如，可以在规范中要求前端使用 React 或 Blazor，后端使用 Node.js、Python Flask 或 .NET，以及特定的数据库或云服务。AI 助手会根据这些要求生成相应的详细技术实施计划，以及后续的任务清单。

例如，如果计划选择 Ruby on Rails 实现后台服务，Spec Kit 生成的 plan.md 将包含 Rails 项目的架构设计和依赖说明，tasks 列表中会有诸如“初始化 Rails 项目”、“创建模型和迁移”、“编写控制器和路由”、“编写 RSpec 测试”等具体任务。再比如选择前端用 Angular，则任务清单中会包含运行 ng new、生成组件、编写组件测试等步骤。这些任务文件和计划都会尊重所选技术的最佳实践，因为 AI 模型会将组织提供的原则和技术约定融入输出。

正如官方博客所指出的，Spec Kit 的方法适用于 Python、JavaScript、Go 等任何语言，本质挑战都是将人的意图准确翻译为代码。

因此，Spec Kit 注重的是规范和意图的清晰传达，具体用何种语言实现由开发者和 AI 共同决定。需要注意的是，Spec Kit 依赖 AI 对不同语言的掌握来生成代码。它本身并不内置各语言的代码模板，而是通过规范驱动 AI 来产出代码。这体现了 Spec Kit 的核心理念：规范驱动流程是普适的，“Intent 即真相”，而具体实现语言只是细节。只要规范清晰，AI 就能针对任意技术栈生成符合意图的代码。实践中，开发者需要确保本地已安装相应语言的构建工具（如 Node.js、Python 解释器、JDK 等）和包管理器，以便 Spec Kit 在 Implement 阶段执行任务时能够调用诸如 npm、dotnet、pip 之类的命令完成项目构建。

---

Spec Kit 在软件工程流程中的作用

Spec Kit 引入了一种高度结构化、规范优先的工作流，对传统软件工程的多个环节都有所增强：

需求规格与设计文档的自动化

在传统开发中，需求文档（PRD）和设计文档往往在编码开始后就失去约束力，容易过时或被忽略。而 Spec Kit 要求开发从**规范文档 (spec.md)**入手，将产品目标、用户场景、功能清单等详细记录。这个规范文件相当于团队共享的需求说明和验收标准，并在整个流程中保持更新。随后在 Plan 阶段生成的 plan.md 则是详细的技术设计与架构方案，包括数据模型、接口契约（API 规范）、外部依赖、性能/安全要求等。这些 Markdown 文档存放于项目下的 .specify/ 目录，并与代码一起版本管理，成为工程的一等公民。每当需求变化，团队首先修改规范和计划文档，然后重新生成任务和代码，实现了文档与实现的同步演化，避免了“文档变废纸”的现象。Spec Kit 甚至会在计划阶段自动生成一些辅助文档，例如 api-spec.json（OpenAPI 接口规范）、data-model.md（数据模型说明）、quickstart.md（项目运行或部署指南）等，使得文档体系相当完整。

测试流程与质量保障

Spec Kit 将测试驱动开发 (TDD) 的理念融入流程，确保质量关口前移和全程可控。首先，在 Tasks 阶段由 AI 依据计划文档自动拆解出细粒度的任务，每个任务都涵盖一个可独立实现和验证的功能点。值得一提的是，Spec Kit 的任务模板硬性规定了任务实施顺序：先编写失败的测试用例，再编写通过测试的实现代码，即将 “红→绿→重构” 的 TDD 循环写入了任务文件。这样 AI 在执行 /speckit.implement 时，会严格按照先测试后实现的顺序进行。

除了单元测试和集成测试之外，Spec Kit 还通过 /speckit.checklist 命令生成需求满足检查清单，列出规范中的每条要求并检查是否实现或验证完毕，被称为**“英文的单元测试”**。此外，/speckit.analyze 命令提供了跨文档一致性分析，在实现前核对规范、计划、任务三者是否有矛盾或不完整之处。一位早期用户在 Reddit 评论道，Spec Kit 强制了严格的一致性和测试流程，让整个团队围绕相同规范协作，降低了 AI “自由发挥”导致的偏差。

需求变更与迭代支持

Spec Kit 的流程虽然看似有点“上游文档驱动”的味道，但实际上非常注重迭代。开发者在每个阶段都扮演着审核和调校的角色。例如，在生成初步规范后，团队可以通过 /speckit.clarify 提示 AI 提出一系列澄清性问题，将隐含需求显性化并记录在规范中。同样，在得到技术计划后，开发者需要检查其中的架构决策和技术选型是否合理，若有不符合预期的地方，可以直接编辑 plan.md 或让 AI 修改。

Spec Kit 提倡修改规格而非硬改代码的做法：当需求变化或实现结果不满意时，先回到规范或计划阶段调整描述，然后重新生成后续的计划、任务乃至代码。由于整个过程耗时不长（官方示例中，通过三条命令就能在15分钟内生成包含规范、计划、数据模型、契约、测试场景和任务清单的完整方案），因此这种迭代是高效可行的。

团队协作与知识沉淀

通过规范和任务的形式，Spec Kit 将开发过程中隐含的许多信息显性化，方便团队成员协作和传递知识。规范文档 (spec.md) 本身就是团队对需求共识的体现，比起个人的提示词“黑箱”，它更易让整个团队理解和参与。每一次澄清（Clarifications）都会记录在规范文件中，形成可审计的对话记录。任务清单也能够拆分给不同开发者或 AI 并行工作（任务文件会标记哪些可以并行 [P] 执行）。

由于规范/计划/任务等文档与代码同分支、同演进，每个功能的来龙去脉都可以追溯。有人将 Spec Kit 打造的结构称为**“有据可查的证据链”**。对于大型组织，这种知识的结构化沉淀尤为宝贵：安全政策、合规规则、设计约束等不再散落于人脑或难找的 Wiki 页面，而是明确写入规范和计划文件中，AI 实现时会直接遵循。

综上，Spec Kit 在软件工程中扮演了连接**“需求 – 设计 – 实现 – 测试”各环节的中枢角色**。它让需求规格真正驱动代码生成，并通过模板化、检查点和反馈循环，使这一过程可控、可审、可重复。这既体现了敏捷开发中快速反馈、持续改进的精神，也借鉴了传统工程中先设计后施工的稳健性，被一些专家称为“BDD 的延续或回归更严格规范的开发方式”。

---

与其他规范/契约相关项目或标准的比较

Spec Kit 提出的规范驱动开发理念，与软件工程领域既有的一些规范/契约标准和工具既有区别也有联系。下面将 Spec Kit 与 OpenAPI/Swagger、JSON Schema 以及传统**行为驱动开发（BDD）**进行对比。

比较对象	定位和特点	与 Spec Kit 的关系
OpenAPI/Swagger （REST API规范标准）	OpenAPI（原 Swagger）是一种用于描述 RESTful API 接口的规范格式，包含端点路径、请求/响应模型、认证方式等细节。开发者常用它进行API 设计优先开发，借助工具生成客户端/服务器桩代码和接口文档。	Spec Kit 可以将 OpenAPI 等接口规范视为整体规范的一部分来处理。例如在 Plan 阶段，AI 可以根据功能需求自动生成 OpenAPI 格式的 API 合约文件（如 api-spec.json）。也就是说，Spec Kit 不会取代 OpenAPI 的作用，而是利用其作为接口契约的表达方式。两者相辅相成：Spec Kit 提供宏观流程，OpenAPI 提供微观接口细节。
JSON Schema （JSON 数据模式标准）	JSON Schema 是用于描述 JSON 数据结构和校验规则的标准。例如定义对象的字段类型、必填项、格式模式等。它常用于接口入参验证、配置文件校验等场景。	在 Spec Kit 工作流中，JSON Schema 也扮演着可集成的角色。当规范涉及复杂的数据结构或配置时，AI 可以在 Plan 阶段产出 JSON Schema 来精确定义数据模型。Spec Kit 借助既有标准，将 JSON Schema 视为一种细节实现或契约工具，用于保证数据层面的正确性。Spec Kit 是从更高层次确保需求落地，而 JSON Schema 则是在实现层面对数据格式进行严格约束。
行为驱动开发 (BDD) （如 Cucumber/Gherkin）	BDD 是一种强调以自然语言定义软件行为的开发方法。典型 BDD 框架（如 Cucumber）允许用 “Given-When-Then” 格式编写用户故事和验收测试，然后开发者据此实现功能。	Spec Kit 和 BDD 在理念上有相通之处，都强调先定义意图和行为，再编写实现。Spec Kit 可以看作是将 BDD 思想应用于 AI 开发的新尝试。区别在于： ① 规范表达：BDD 通常用 Gherkin 语法，而 Spec Kit 用结构化的自然语言+Markdown，对 AI 更友好。 ② 自动化程度：BDD 中人手工编码实现，Spec Kit 则由 AI 自动生成代码。 ③ 流程严格性：有专家评论，Spec Kit 将一些过去敏捷中灵活的部分结构化了，被戏称为“瀑布的复仇或 BDD 的更高层次”。 综上，Spec Kit 并非替代 BDD，而是汲取其精华并结合 AI 能力扩展出的新方法论。

Export to Sheets

此外，还有一些新兴工具和项目与 Spec Kit 理念相似，例如 GitHub 的 SpecLang 项目、亚马逊的 AWS Kiro IDE、初创公司的 Codeplain 以及 Specmatic 等。这些项目都预示着业界对**“以规范定义意图，让 AI 执行细节”这一趋势的探索。与它们相比，Spec Kit 的特点在于：作为 GitHub 开源工具，它更关注流程和模板的通用框架**，而非发明新的规范描述语言；它可以结合上述各种标准/工具使用，而不是竞争关系。

---

采用情况、典型应用案例与社区反馈

Spec Kit 发布后迅速引起社区广泛关注。GitHub 官方开源仓库在一个多月内收获了数万星标（截至 2025年10月已有3万+ Star），Issues 和讨论区也非常活跃。

个人开发者的实验与体验

在 Reddit 等论坛上，不少开发者尝鲜使用 Spec Kit。一位用户称其效果“颠覆想象”，特别提到 Spec Kit 提供了一致的规范和更好的上下文，使整个团队基于同一组说明工作。另一位用户分享道，他用 Spec Kit 重构了一个功能，在短短几周内完成了过去难以企及的任务，并生成了大量自动化测试用例，直呼这是“游戏规则改变者”。

“感觉像是在指导一个超级能干但很较真的开发者编程，它完全按我的要求来，一点不多做”。

负面声音和应用局限

当然，也有用户指出 Spec Kit 的不足。

• 对于小的改动或简单修复，遵循完整的 Spec Kit 流程显得“小题大做”，反而增加了开销。

• 存在学习曲线，团队需要熟悉这些命令和模板。

• UI/UX 密集型的工作在 Spec Kit 中不好表述，例如像素级的界面设计、交互体验。

• 如果对 AI 规划的技术选型不满意，需要手动修改 plan.md 或重新运行计划阶段，这方面缺乏明确指引。

团队和企业视角的讨论

一些企业技术负责人和平台工程师希望以 Spec Kit 为基础构建企业级的 AI 开发平台，把组织的编码规范、质量标准都融入 Constitution 和模板，以避免“AID（AI Assisted Development）碎片化”。 另一方面，也有专家持审慎态度。著名软件顾问 Gojko Adzic 评论说，Spec Kit 倡导的严格流程虽然提高了一致性，但可能过于正式化，带回了敏捷希望避免的官僚作风，他把规格驱动开发比作**“瀑布开发的复仇”**。

典型采用案例

目前公开的 Spec Kit 应用案例大多还来自个人项目和社区分享。比如有开发者用 Spec Kit 创建了一个任务管理应用，从建立规范到生成完整前后端代码，仅用几周时间就完成。也有内容创作者录制了视频教程，演示如何用 Spec Kit 七条命令完成从需求到部署的过程。在企业层面，尚未有公开宣布大规模使用 Spec Kit 的案例，但一些中小团队已经把它用于内部项目试验。

总体而言，社区对 Spec Kit 的反馈呈现出**“谨慎的乐观”**态度。一方面，很多开发者认可其解决了 AI 编码中的痛点（上下文不明、质量难控）。但另一方面，也有人提醒不要期待 Spec Kit 一步到位地消除所有问题。它指明了一个方向：下一代开发工具不仅要会写代码，还要理解代码背后的意图。

---

背后的哲学思想与问题解决方法论

Spec Kit 不仅是一套工具链，更蕴含着对软件开发过程和人与 AI 协作的深刻理念变革：

“规范优先，意图为源”

这是 Spec Kit 方法论的基石。过去软件业常说“代码即真理”，但 Spec Kit 倡导将人类意图/规格作为新的真理来源。我们正在从“以代码为中心”转向“以意图为中心”。这种 Intent-First 思想的好处在于：只要意图不变，实现可以不断重构演进；而当意图需要改变时，有明确的规范作为锚点去调整，实现也可以随之重生。

“契约驱动开发”的实践

Spec Kit 强调的 Constitution (项目章程)、Spec (规格) 以及生成的各种 contracts 文件都体现了一种契约精神。项目章程可以被视为团队内部的“社会契约”，规定了代码质量标准、架构原则等铁律；API 规范和数据模型则是服务与服务之间、模块与模块之间的契约。可以说，Spec Kit 是对传统 Design by Contract 思想的一种 AI 时代重现。

分而治之、可组合性的思维

Spec Kit 方法非常强调将复杂问题拆解成小块来解决。它鼓励把系统划分为多个用户故事、功能列表；在计划层面，将高层需求映射为若干模块设计；在任务层面，更是细化到具体的编码任务。这种逐层分解，使 AI 各攻其段。可组合性还体现在 Spec Kit 支持任务并行 [P] 和多路线探索，让团队可以快速试验多个想法。

模板驱动的隐性知识显性化

Spec Kit 的成功依赖于精心设计的模板和提示，它们实际上承载了大量软件工程的隐性知识和最佳实践，被称为“软规范”。

例如，规范模板强制标出所有不明确的地方 [NEEDS CLARIFICATION]，迫使 AI 不得不提问而不能假设；又如明确要求规范写**“what/why”禁止写“how”**，以免 AI 提前给出技术实现细节。

这些模板规则等于把经验丰富的架构师/项目经理脑中对“好规范”的要求，编码到了每次生成中，从而润物细无声地提升了输出质量。

清晰的人机分工与协作

在 Spec Kit 模式下，人和 AI 各司其职、优势互补：人负责提供高质量的输入（需求、原则、偏好）并审阅 AI 的输出，AI 负责在明确指令下完成繁重的代码和文档撰写工作。AI 每一步都需接受人的校准而非一跑到底。这种明确的人机边界和交接协议，正是 AI 开发能够在大型团队推广的关键。当生成式 AI 的能力可以大幅加速编码，那么工程师的价值将体现在对需求的洞察、对架构的权衡以及对质量的把控上。

总结来说，Spec Kit 的哲学融合了规范驱动、契约优先、迭代分解、模板护航和人机协作等方法论要素，目的是破解“AI 写代码不靠谱”这一难题。这种方法论有点像将过去软件工程中的“好习惯”全部前置并自动化。正如作者在博客中所说，“我们开源 Spec Kit，因为这种方法论大于任何单一工具或公司”。

公众号:嵌入式 aLab