文章深入探讨了 2025 年末 AI 开发领域的新兴趋势：规范驱动开发（Spec-Driven Development），并重点介绍了 GitHub 开源工具 SpecKit。作者首先分析了当前 AI 开发的两大模式：氛围式编程和 AI 辅助开发，指出规范驱动开发是更平衡、务实的方向。随后，文章详细阐述了 SpecKit 的安装、核心概念（如 Constitution、Specification）和八个工作流阶段（包括澄清、规划、检查清单、任务分解、分析验证和实现），并配以丰富的图示和示例流程。最后，作者分享了个人对 SpecKit 的评测，肯定了其在提升开发效率、产出质量和减少模糊点方面的价值，同时也指出了在大型项目中的审查挑战和流程复杂性，并提供了实际使用建议。整体而言，文章为 AI 开发者提供了一个新颖且实用的开发范式和工具。
src="https://api.eyabc.cn/api/picture/scenery/?k=5c07fa97&u=https%3A%2F%2Fmmbiz.qpic.cn%2Fsz_mmbiz_jpg%2FmeG6Vo0MevjqMkiczqnuIWSILqDQ1T4zsDFd3LzkUzlusJFUyBcRia2Rwhn6CEFkZWXqc2nFc7x9gq3TRK7blGVA%2F0%3Fwx_fmt%3Djpeg">
前言
主要探讨了在 2025 年末人工智能开发领域的新趋势，特别是规格驱动开发（Spec-Driven Development）及其开源工具 SpecKit。今日前端早读课文章由 @Mario Bittencourt 分享，@飘飘编译。
译文从这开始～～
在 2025 年底，AI 开发领域正处在一个颇为有趣的阶段。与此同时，人工智能依然是新闻热点，头条上不断出现 Nvidia、OpenAI、AMD 等巨头的大规模投资消息，也伴随着 “AI 泡沫是否即将破裂” 的讨论。
与此同时，围绕 AI 在软件开发中的应用，行业讨论也在变化。人们逐渐从 “开发者将被取代”“未来只靠提示词写代码” 这样的极端观点，转向了更为平衡、务实的方向。
其中一个代表性思路，就是 “基于规范的开发”（Specification-driven development），也称为 “基于需求的开发”（Requirements-driven development）。
本文将介绍这个领域中的一个新秀 ——SpecKit，探讨它为何可能成为你 AI 工具箱的自然延伸，以及它目前仍有哪些不足之处。
spec-kit：https://github.com/github/spec-kit
AI 开发现状
我认为当前的 AI 开发格局可以大致分为两类：
1、Vibe Coding（氛围式编程）
这类工具旨在提供一种 “一键生成” 的体验 —— 用户输入提示词后，AI 能自动生成完整应用，甚至直接部署。
2、AI 辅助开发
这是更 “传统” 的路线：通过代码补全、代码生成以及工具调用来辅助开发。
在第二类中，Visual Studio Code + GitHub Copilot、Cursor 和 Windsurf 是最受欢迎的选择。这些 IDE 会在用户交互中自动添加更多上下文，例如当前文件、相关文件、代码差异以及自定义指令，从而帮助 AI 生成更合适的输出。
如果你刚开始尝试 AI 辅助开发，我建议先从这种 “传统方式” 入手，让自己熟悉 AI 的使用场景，并了解它在哪些方面还无法满足你的预期。
生活很好…… 但还可以更好！
当你掌握了各种技巧后，很多开发者的下一步，往往是创建一组自定义指令文件，用于记录和规范自己的开发流程。这些文件的目的，是让 AI 助手在生成代码时遵循特定规则，从而让开发过程更可预测，也能在团队成员之间形成一致的工作方式。
基于这一思路，一些新工具开始涌现，例如 Kiro。
它试图将 “开发流程” 变成开发体验中最重要的部分，不再依赖零散的自定义指令文件，而是让 “需求（规范）” 本身成为整个开发过程的核心，在开发者与 AI 的持续交互中被生成、维护和更新
Kiro IDE：以 “规范（Specification）” 为核心。来源：Kiro.dev
它本质上遵循 “需求（Requirements）→ 设计（Design）→ 实现（Implementation）” 的开发路径。
Kiro 的工作流程及常见生成产物
由于这一流程与 IDE 紧密集成，生成的产物会成为项目的一部分，因此可以纳入版本控制并实现共享。这种方式能让我们达到理想的平衡点：既保持 “人类参与” 的开发闭环，又能享受自动化代码生成带来的高效，同时对生成内容进行治理，并在新功能加入时持续保持可用。
认识 SpecKit
SpecKit 是一种开源替代方案，采用了与 Kiro 相似的 “基于规范驱动开发（Spec Driven）” 思路。
不同的是，Kiro 基于 Visual Studio Code 的分支并提供专有功能，而 SpecKit 则采取了另一种更开放的路径。
它由一系列自定义提示词文件（prompt files）和配套的 shell 脚本组成，构成一个包含若干必选和可选步骤的工作流。
SpecKit 的总体流程图。圆形结构表示流程可以多次迭代。
SpecKit 的工作流程包括以下几个阶段：
-
Constitution（基本准则） —— 用于定义项目必须遵循的一系列核心条件。
-
Specification（规范说明） —— 用于定义你要开发的应用或功能的具体需求。
-
Clarification（澄清）【可选】—— 用于处理规范说明中不清楚或模糊的部分。
-
Plan（规划） —— 分析规范说明与基本准则，并生成相关产物，如研究报告、数据模型、API 细节等。
-
Checklist（检查表）【可选】—— 创建质量检查清单，用于验证需求的完整性、清晰性和一致性。
-
Task（任务分解） —— 将计划拆解成更小的可执行任务。
-
Analyze（分析）【可选】—— 检查生成产物之间的逻辑一致性，并允许你进行调整。
-
Implement（实现） —— 进行代码生成。
示例流程
安装
SpecKit 可用于全新项目（greenfield）或已有项目（brownfield），也就是说，你既可以从零开始，也能将其集成到现有项目中。
它提供两种主要的安装方式：
使用 uv 安装：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git使用 uvx 安装：
uvx --from git+https://github.com/github/spec-kit.git specify init PROJECT_NAME # 用于新项目初始化或
uvx --from git+https://github.com/github/spec-kit.git specify --here # 用于将 SpecKit 添加到现有项目官方推荐使用 UV 工具 进行安装，因为它只需安装一次即可全局可用，无需每次都访问 GitHub 服务器。
安装完成后，你就可以使用它来 “初始化” 你的项目了。
安装 SpecKit
在安装过程中，你可以选择要使用的工具类型，并决定是否安装 PowerShell 或 bash 脚本。
选择要使用的脚本格式。
接下来，安装过程会自动开始。
将提示词、脚本和模板添加到项目中。
安装完成后，打开你的项目，会发现多了两个文件夹：.github 和 .specify。
.github 文件夹中包含了一组提示文件，这些文件代表了 SpecKit 提供的可执行命令。
新增命令其实就是自定义提示文件。
.specify 文件夹则包含 SpecKit 使用的各种产物、脚本和模板。
这些模板包括大部分生成产物的定义，以及由命令触发的辅助脚本。
除此之外，系统不会发生任何其他更改。由于所有文件都位于项目目录中，因此可以直接纳入版本控制。这些文件都是常规的 shell 或 .md 文件，你还可以根据需要进一步自定义它们。
Constitution（基本准则）
SpecKit 将这一部分称为 “不可协商项”（non-negotiables）—— 也就是应用中必须遵循的核心规则。这部分内容与许多开发者已经在使用的 copilot-instructions.md 文件非常相似。
我在其中添加了自己的代码规范、文件夹结构、常用库以及测试的定义。
样例 Constitution 文件，定义了项目标准与全局约束。
执行后，SpecKit 会开始运行并更新 constitution.md 文件，同时更新 plan 和 task 模板。
更新后的 constitution 文件和模板。
打开 constitution.md 后，可以看到它还会自动记录更改历史。
constitution 文件中包含变更日志，标明修改内容。
它的妙处在于 —— 你不需要一次性想清楚所有 “不可协商项”。可以随时通过额外的 constitution 命令进行补充。
你可以不断迭代，完善 Constitution 文件。
SpecKit 会根据你新增的信息自动更新 Constitution 内容。
新的修改会被标注出来，方便查看最近的变更。
当你觉得基本准则定义完善后，就可以进入下一个阶段。
Specification（规范说明）
Specification 阶段是你用来描述计划开发的功能的地方。在这里，你应重点说明要做什么（What）以及为什么要做（Why），而不是怎么做（How）。
举个例子，假设我们要开发一个电影追踪应用，那么规范说明中可能包含以下内容（仅展示开头部分）：
为应用或功能添加规范说明。
执行后，系统会自动创建一个新的分支以及一个 spec 文件夹，用来保存当前功能的规范文件。
新建的 Git 分支，用于存放规范及后续生成的产物。
这种做法的好处是，你可以在主分支之外独立地进行实验和功能开发。运行规范生成命令后，SpecKit 会根据你的描述生成包含用户故事和功能需求的内容。
生成的规范片段，展示了部分功能需求。
与 Constitution 阶段类似，如果你发现有遗漏的需求，也可以再次运行 specify 命令，为多个项目补充规范内容。
Clarification（澄清）
到目前为止，我们已经构建并更新了 Constitution，并添加了想要开发的功能规范。在进入下一阶段前，一个推荐的步骤是 —— 找出其中存在的模糊或不明确的地方并加以澄清。
执行 clarify 命令后，SpecKit 会检查 Constitution 和 Specification，并生成 5 个需要回答的问题，用于帮助你理清需求。
用于澄清需求不明确之处的首个问题（共 5 个）。
你可以在提供的选项中选择，或输入简短回答。SpecKit 会根据你的回复自动更新相关的项目产物。
Plan（规划）
当 Constitution 和 Specification 都完成审阅后，就可以进入规划阶段（Plan）。在这个阶段，模型会综合前两步的信息，进行一定的研究，并提出一个实现方案。
从研究和设计决策（数据模型、API 合约等）开始规划实现方案。
生成的产物数量和类型会根据应用的不同而有所差异。在我们的示例中，Plan 阶段生成了以下文件：
例如，data-model.md 文件中包含了系统对持久化层中实体结构的建议方案。
与规范相匹配的数据模型设计方案。
Checklist（检查清单）
Checklist 是 SpecKit 工具链中最新加入的功能，它可以帮助你为特定主题（如 UX、Security、API 等）生成质量检查清单。
执行命令时，系统会先询问与你选择的主题相关的 3 个问题。例如，下面的示例中，我们选择了 Security（安全） 作为主题。
帮助定义所选主题检查项的三个问题，不同主题内容会有所不同。
根据你提供的答案，SpecKit 会在 checklists 文件夹下生成一个或多个文件，文件中列出了在继续开发前需要验证的要点。
我们的安全性检查清单，其中列出需在继续开发前解决的项目。
与之前的步骤类似，你可以针对不同主题多次运行该命令，以生成更有针对性的检查清单。此步骤为可选项。
Tasks（任务分解）
到目前为止，我们已经完成了 Constitution（基本准则）、Specification（规范说明），并基于它们进行了研究和规划，得出了实现方案。在正式进入代码实现之前，我们需要将整体工作拆分成更小、更易管理的阶段。
这种做法既能让 LLM（大语言模型） 获得更明确、专注的指令，也方便你在代码生成过程中逐步跟踪与审查结果。
Task 生成结果：将规划拆分为用户故事和具体任务。
生成的任务清单大致如下所示，其中带有 [P] 标记的任务表示可以并行执行（如果你的开发工具支持）。
各个任务及其可并行执行标识。
Analyze（分析验证）
还跟得上吧？🙂在真正开始实现之前，还有一个可选的验证步骤。因为我们已经生成了多个产物，而它们之间可能存在不一致的情况。
执行 analyze 命令可以进行交叉比对，让你在正式实施前有一个 “最后机会” 来发现并解决这些差异。查看下面片段
比对 Constitution、Specification 和 Tasks，找出潜在不一致。
建议优先处理那些严重级别较高的问题，以确保接下来的实现阶段尽可能符合预期。
我指示系统先解决关键问题，结果如下：
关键问题处理完毕，可以进入下一阶段。
Implementation（实现阶段）
终于到了实际编码的时刻 🎉
执行实现命令时，系统会首先检查你是否还有未完成的检查清单（Checklist）。
Implementation 命令运行时，首先提示存在未完成的检查项。
你可以选择直接继续，也可以先处理这些检查项再往下执行。如果选择继续，SpecKit 将根据 tasks.md 中的阶段划分和用户故事顺序开始生成代码。
接下来，你可以自行选择开发方式：
-
自动接受文件；
-
逐个审查任务生成的代码；
-
或等所有任务完成后再整体审阅。
在执行过程中，系统会实时标记已完成的任务。
实现阶段根据任务文件标记执行进度。
最终结果如下：
最终生成成果展示。
如果你想查看生成的完整代码，可以访问对应的代码仓库：https://github.com/bicatu/speckit-demo
我的评测（My Review）
经历了这一整套流程后，你可能会好奇我对基于规范驱动开发（Spec Driven Development），特别是对 SpecKit 的最终看法。简而言之（TL;DR）：总体评价是积极的 —— 至少对我来说如此。下面我将详细说明原因，以及在 greenfield 和 brownfield 中使用它时的一些收获。
SpecKit 提供了一种非常细致的 AI 辅助开发流程。
它利用辅助脚本和带有自定义提示词的 LLM，将你的输入（无论是 Constitution 还是 Specification）扩展成符合你需求的结果，在大多数开发场景中都能做到 “八九不离十”。
其中的 Clarify（澄清） 和 Analyze（分析） 两个环节尤其值得称赞。它们能帮助发现那些你往往容易忽略的模糊点 —— 否则这些问题可能只会在编码中途才被注意到，不得不中断开发去询问他人，甚至因此被卡住。
在实现阶段（Implementation），整体体验也相当顺利。SpecKit 会按阶段推进任务，对于较大的阶段还会细分成更小的实现循环。例如，在我的应用中，“阶段 3” 被拆分成四个实现循环，分别完成了 45%、60%、69%，最后一个循环完成剩余部分。
总体来看，它确实能生成一个符合规范要求、可直接运行的解决方案，速度也比我手动编写代码快得多。并且由于使用了 Constitution 文件，生成的代码风格与我的要求基本一致。
当然，也有一些小偏差，比如它自动创建的接口名称采用了 ISomething 的命名模式 —— 我并未明确指定这一点，但也并未要求禁止，因此它 “合理推测” 出了这种结构。
另一个小问题是：它没有自动生成登录 / 登出功能。我以为因为在 Constitution 中提到了身份验证，它会自动补充这一点，但事实并非如此。这也提醒了我 —— 一定要明确说明期望内容。模型会根据已有信息做出合理假设，但不会主动 “填补空白”。
在 brownfield 项目中使用 SpecKit 的体验出乎意料地更好，主要因为项目范围更小。在我的示例项目中，生成的阶段和任务数量相当可观，部分情况下，创建或更新的文件数量超过了 30 个。这让在点击 “Keep” 之前逐个审查文件的过程变得既繁琐又耗时。
我的建议是：尽量将 SpecKit 应用在较小的功能或特性开发上。这样可以确保 “人类在循环中”（human in the loop）的模式真正发挥作用 —— 让你能在代码生成过程中就审查结果，而不是等到最后一并处理。
否则，体验可能就像你加入一个新团队，要通过阅读整个代码库来了解领域逻辑 —— 当然是可行的，但并不算愉快。
最后一个可能让人犹豫的点是：流程的复杂性。采用 SpecKit 意味着你必须遵循一个包含 5 到 8 个步骤的完整流程，而且其中一些步骤需要多次执行。对某些人来说，这可能显得冗长，甚至 “形式主义”；尤其是那些追求 “氛围式编程（vibe coding）” 的开发者，可能会觉得这套流程太过繁琐。
但如果你和你的项目并不属于这类极端情况，那么 SpecKit 确实有潜力显著提升你的开发效率与产出质量。
关于本文译者：@飘飘作者：@Mario Bittencourt原文：https://itnext.io/up-your-ai-development-game-with-spec-driven-development-f5175cf59c7c
