作为软件开发者，咱们在阵势中见过太屡次这么的场景：规格阐述书在阵势启动时写好，争论了几周，然后被暗暗埋在 sprint 看板、Jira 工单和"咱们代码评审时再看"的借口之下。

最终，代码成了唯独的真相起首，而规格阐述书则沦为逾期的罗列。

当今，AI 编程智能体正在调动这一模式，一个新术语也应时而生：表率驱动开发（Spec-Driven Development，简称 SDD）。其背后的理念很浮浅，关于那些风俗以文献和 Pull Request 为单元想考的东说念主来说，以致有点令东说念主不安：

表率，而非代码，才是咱们应该惊叹的首要居品。代码只是从表率中生成的居品。

代码作为真相起首 vs 表率作为真相起首

在这篇著作中，我将先容表率驱动开发是什么，它怎样重塑软件开发生命周期，以及在咱们使用 Spec Kit 和 Claude Code 构建一个微型 REST API 时，它在践诺中是什么面目。

1、什么是表率驱动开发？

表率驱动开发是一种构建软件的方式，其中结构化、可践诺的表率处于职责经由的中心。

与其径直从 Jira 工单跳到代码，咱们领先精准描摹系统应该作念什么、必须盲从哪些按捺、以及变更的范围在何处。然后，AI 智能体使用这些表率来诡计、组织和实施职责，更首要的是，表率在代码生成后仍然保合手活力。

这与很多团队在往日几年中使用 AI 助手的方式酿成了特意旨的诊治。标签补全式编码（巧合被亲切地称为"氛围编程"）关于小段的胶水代码来说遵守可以，但在团队范围上它有一个无人不晓的失败模式：

智能体对系统的意图莫得共同的相识，每个开发者用略有不同的领导来影响它。断绝是快速、不一致且难以演进的。

2、传统开发 vs 表率驱动开发

SDD 直采取制了这个问题。表率不再是藏在 Confluence 页面里的 Word 文档，

它是仓库中一个版块化、可审查的文献，AI 智能体阅读它的方式与新团队成员阅读它的方式相通。

一个直不雅的对比：

传统开发：需求 → 代码（代码是真相起首）

表率驱动开发：需求（表率） → AI 智能体 → 代码（表率是真相起首）

GitHub 的开源阵势 Spec Kit 是这一理念最显眼的达成之一，而 Kiro 和 Tessl 等用具也在探索类似的领域。它们并非透顶相通，但分享一个共同的骨架：一小套结构化文档和一小套由 AI 驱动的阶段，将这些文档诊治为可职责的软件。

3、SDD 怎样调动软件开发生命周期

传统的软件开发生命周期（SDLC）包括分析、联想、达成、测试、部署和惊叹。每个阶段都会产生居品（需求文档、联想文档、源代码、测试阐述），而这些居品中的大大批会渐渐脱节。

SDD 并莫得烧毁 SDLC，而是从新组织了每个阶段的核焦灼点：

分析不再只是是为了将来阅读而创建文档，它当今产生径直交流畅成的表率。咱们的问题变得愈加精准，因为无极的恢复会在几小时而不是几个月内表露为 bug。

联想诊治为智能体或开发者可以遵命的了了策画。它明确记载架构决议、期间选型和非功能性按捺，时时以**"宪法"立场**的文档局势出现，概括项策画强制性执法。

达成是智能体完成大部分打字职责的处所，但开发者仍然对断绝负责。变装从"写每一溜代码"诊治为"审查意图、考证举止，并在代码暴夸耀缺失细节时完善表率"。

测试与表率愈加雅致地对皆。表率中概括的验收尺度作为智能体创建的驱动测试，让东说念主类和智能体都能在总结测试期间参考表率。

惊叹可能是长久收益最大的处所。当表率保合手最新时，引入新工程师或启动新的智能体会话不需要反向工程代码库。你提供表率，其他一切就会各就诸位。

阶段保合手不变，但当今表率在通盘过程中充任主要指南，而不是在达成入手时被丢弃。

4、表率驱动开发的用具链

表率驱动开发主如果一种次序，但还是出现了一批用具包来裁汰践诺它的摩擦。筹备最多的三个是 GitHub 的 Spec Kit、AWS 的 Kiro 和 Tessl。

Spec Kit 是开源的、由 CLI 驱动的选项，它与大大批团队还是在使用的智能体集成得最为顺畅：Claude Code、Cursor、Copilot、Gemini 和 Codex，因此我将在本文的其余部分重心先容它。

5.1 装配 Spec Kit

Spec Kit 作为一个名为 specify 的微型 Python CLI 发布。在你的机器上通过 uv 装配一次：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

specify --version

然后，在你想要使用 SDD 的阵势里面驱动化它：

specify init . --ai claude

--ai claude 标志将 Spec Kit 的领导模板接入 Claude Code，同样的标志也接受其他智能体（cursor、copilot、gemini、codex）。在 specify init 之后，Claude Code 的斜杠菜单中会出现五个斜杠呐喊：

/speckit.constitution：界说阵势范围内不可协商的事项。

/speckit.specify：从当然说话描摹生到手能表率。

/speckit.plan：从表率和期间按捺生成达成策画。

/speckit.tasks：将策画理解为有序的任务列表。

/speckit.implement：践诺一个或多个任务。

三个出奇的援救剧本用于审查和完善：

/speckit.clarify：在需求到达策画阶段之前符号无极之处。

/speckit.analyze：交叉查验表率、策画和任务之间的不一致性。

/speckit.checklist：生成可以交给东说念主类审查者的审查清单。

specify init 呐喊本体上会创建这些文献：

运行 "specify init" 呐喊青年景的文献

5.2 Spec Kit 呐喊与原生 Claude Code 呐喊的对比

咱们本体上并不需要 Spec Kit 来进行表率驱动开发。它是一个便利层，类似于其他智能体（如 Claude Code）中的职责流运行，通过惯例领导让智能体在相通的文献夹中生成相通的文献。

宪法层以致内置了 Claude Code /init 呐喊的部分类似物，它在阵势根目次下搭建一个 CLAUDE.md，Claude 在每个会话中都会读取它。这两个文献位于项策画归拢层，但恢复的问题略有不同：

"CLAUDE.md" 主如果描摹性的（"阵势是这么布局的，用这个呐喊运行测试"），而 "constitution.md" 主如果章程性的（"这些是每个功能必须盲从的不可协商执法"）。

其他 Spec Kit 呐喊，如 /speckit.specify、.plan、.tasks 和 .implement，透顶莫得原生的 Claude Code 等价物，你必须么装配 Spec Kit，要么我方编写领导。

如果你的团队策画厚爱使用 SDD，装配 Spec Kit 值得付出小小的前期资本，而不是依赖原生的 Claude Code 呐喊息争放局势的领导。

因为相通的 "/speckit.*" 呐喊不管你指向 Claude Code、Cursor、Copilot 照旧 Gemini 都会产生相通的居品，是以如果你更换智能体，项策画表率也聪颖净地迁徙。

6、践诺示例：Spring Boot 预订 API

让咱们入手吧。假定咱们想要构建一个微型的 REST 服务来管搭理议室预订。在传统经由中，我会创建一个 Spring Boot 阵势，起草一个 Booking 实体，添加一个截止器，纠合一个仓库，并在过程中摸索考证执法。

在表率驱动经由中，第一个居品不是类，而是一个与源代码并存并处于版块截止之下的表率文献目次。

.specify/memory/constitution.md 文献包含每个功能必须盲从的阵势范围执法，包括编码尺度、测试战术和安全基线。

specs// 文献夹存放每个功能的居品。src/ 下的总共内容都是生成的内容，凤凰体育(FHSports)官方网站它是输出，而不是真相起首，其中的每一溜都应该可以挂牵到 specs/ 下的某个文献。

在装配了 Spec Kit 并有了宪法之后，以下是预订 API 的四步职责经由。

Claude Code 中 /speckit-specify 技巧的新技巧钩子架构存在一个 bug，这在较新版块的 Spec Kit 中有所体现。在 .specify/extensions.yml 中，咱们有 auto_execute_hooks: true 和一个强制的 before_specify 钩子，它领先运行 /speckit-git-feature：

before_specify:

- extension: git

command: speckit.git.feature

enabled: true

optional: false # 强制的

1️⃣ 表率

这一步从开发者编写当然说话领导入手。智能体将该领导诊治为结构化的 spec.md 文献。开发者随后审查并裁剪它。

我会输入到智能体（Claude Code）中的领导：

/speckit.specify 构建一个服务，让职工可以预订会议室的特定时辰段。它必须驻扎归拢房间的双重预订。预订只可由创建它们的用户取消。职工还应该粗略列出给定房间和日历的预订。

运行 "/speckit.specify" 呐喊后的 Claude Code 断绝

智能体将断绝写入 specs/001-meeting-room-bookings/spec.md，内容大要如下：

# Feature Specification: Meeting Room Booking

**Feature Branch**: `001-meeting-room-booking`

**Created**: 2026-05-08

**Status**: Draft

**Input**: User description: "Build a service that lets employees reserve a meeting room for a defined time window. It must prevent double-booking of the same room. Bookings can only be canceled by the user who created them. Employees should also be able to list bookings for a given room and day."

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Reserve a Meeting Room (Priority: P1)

An employee wants to reserve a specific meeting room for a team discussion. They select a room， specify a start and end time， and submit the reservation. If the room is available for that time window， the booking is confirmed. If the room is already booked for any overlapping period， the request is rejected with a clear explanation.

**Why this priority**: This is the core capability of the service — without the ability to create a booking， no other functionality has value.

.

.

.

防卫 spec.md 文献中莫得 Spring Boot、莫得 JPA、莫得 REST 动词、莫得 DTO 称号。这是特意为之的，表率描摹的是问题，而期间选型属于下一步。

在 /speckit-specify 写入 spec.md 之后，该技巧还会生成 /checklists/requirements.md，一个表率质料查验清单，它同期亦然诡计前的就绪查验点。它是一个固定的 markdown 结构，包含三个部分（内容质料、需求完好意思性、功能就绪度），涵盖诸如"莫得达成细节闪现到表率中"、"莫得留传的 [NEEDS CLARIFICATION] 符号"、"到手尺度是可臆测且与期间无关的"以及"每个功能需求都有明确的验收尺度"等阵势。智能体逐项查验表率，斥地任何失败的阵势（最多 3 次迭代），暂停盘问任何未管制的澄澈问题，并将断绝与表率一皆提交。

"/speckit-specify" 呐喊生成的文献

咱们在这个阶段的职责是审查。如果繁重某个执法（时区、最大预订范围，或者什么四肢归拢个"天"），咱们径直裁剪 spec.md 或条款智能体修改它。然后该文献像任何其他源代码居品一样提交到仓库。咱们也可以审查和更新 requirements.md，但联想假定你时时不会这么作念，而当你这么作念时，你应该特意志地琢磨你果然在斥地的是哪个文献。

2️⃣ 策画

有了 spec.md 之后，开发者领导智能体制定期间策画，提供特意从表率中不祥的期间按捺：

诡计的领导：

/speckit-plan 使用 Java 25 和 Spring Boot 4.0*.x。使用 Spring Data JPA 合手久化到 PostgreSQL。在* /api/v1/bookings 下表露 REST 端点。使用 Jakarta Bean Validation 考证输入。在数据库层面强制践诺类似留心，而不单是是在诈欺范例代码中。使用 JUnit 5 和 Testcontainers 进行测试。

运行 "/speckit-plan" 呐喊后的 Claude Code 断绝

智能体读取 spec.md 加上这个领导，然后写入 specs/001-meeting-room-bookings/plan.md。使用 Spec Kit 时，它时时还会在归拢个文献夹中生成撑合手文献：

data-model.md 描摹实体局势

contracts/ 目次存放 OpenAPI 片断

research.md 记载为什么采取某个特定的库或法子

"/speckit-plan" 呐喊生成的文献

生成的 plan.md 的简约版块：

# Implementation Plan: Meeting Room Booking

**Branch**: `main` | **Date**: 2026-05-09 | **Spec**: [spec.md](./spec.md)

**Input**: Feature specification from `/specs/001-meeting-room-booking/spec.md`

## Summary

Build a RESTful Spring Boot 4.0.x service (Java 25) that lets employees reserve， cancel， and list meeting room bookings via `/api/v1/bookings`. Double-booking prevention is enforced at the PostgreSQL level using an `EXCLUDE USING GIST` constraint on a `tstzrange` column; the application handles concurrent conflicts by catching constraint violations and returning HTTP 409.

## Technical Context

**Language/Version**: Java 25

**Primary Dependencies**: Spring Boot 4.0.x， Spring Data JPA (Hibernate 7)， Spring Web MVC， Jakarta Bean Validation (Hibernate Validator)， Flyway

**Storage**: PostgreSQL 16+ via Spring Data JPA; EXCLUDE USING GIST constraint for overlap prevention

**Testing**: JUnit 5， Testcontainers (PostgreSQLContainer)， Spring Boot Test， Mockito

**Target Platform**: Linux server (JVM / containerized)

**Project Type**: web-service (REST API)

**Performance Goals**: 95% of operations within 2 seconds under organizational load (SC-006); booking listing within 2 seconds (SC-004)

**Constraints**: Zero double-bookings (SC-002); concurrent conflict → exactly one booking succeeds (SC-005)

**Scale/Scope**: Organizational scale — tens of rooms， hundreds of employees

.

.

.

与上一步类似，智能体起草，开发者领有。如果策画采取了不想要的依赖或作念出了咱们不快乐的架构采取，我用纯文本提议异议，智能体会修改 plan.md。

3️⃣ 任务列表

下一个呐喊将表率和策画诊治为具体的待劳动项列表：

领导：

/speckit-tasks

使用 Spec Kit 时，该呐喊不需要出奇的领导，智能体还是有 spec.md 和 plan.md 可以职责。它写入 specs/001-meeting-room-bookings/tasks.md：

---

description: "Task list for Meeting Room Booking implementation"

---

# Tasks: Meeting Room Booking

**Input**: Design documents from `/specs/001-meeting-room-booking/`

**Prerequisites**: plan.md， spec.md， research.md， data-model.md， contracts/openapi.yml

**Tech Stack**: Java 25， Spring Boot 4.0.x， Spring Data JPA， PostgreSQL， Flyway， Jakarta Bean Validation， JUnit 5， Testcontainers

**Tests**: Included — JUnit 5 + Testcontainers explicitly required by the feature spec.

**Organization**: Tasks are grouped by user story to enable independent implementation and testing.

## Format: `[ID] [P?] [Story] Description`

- **[P]**: Can run in parallel (different files， no dependencies on incomplete tasks)

- **[Story]**: Which user story this task belongs to (US1， US2， US3)

- Each task includes the exact file path to create or modify

## Path Conventions

Single Spring Boot project at repository root:

- Source: `src/main/java/com/example/booking/`

- Resources: `src/main/resources/`

- Tests: `src/test/java/com/example/booking/`

- Test resources: `src/test/resources/`

---

## Phase 1: Setup (Shared Infrastructure)

**Purpose**: Initialize the Spring Boot 4.0.x Maven project with all required dependencies and base configuration.

.

.

.

运行 "/speckit-tasks" 呐喊后的 Claude Code 断绝

实用技巧：在实施前审查。 /speckit-tasks 是在问题变成代码之前发现它们的最低廉时机。从新到尾阅读生成的列表，并盘问每个任务是否有明确的验收尺度，礼貌是否合理（数据库迁徙在实体之前，公约测试在截止器之前），以及任何缺失是否因为表率缺失了它（在这种情况下，且归裁剪 spec.md，而不是 tasks.md）。在这里运行 /speckit-analyze 也值得多花几秒钟 —— 它交叉查验 spec.md、plan.md 和 tasks.md，符号你可能在实施到一半时才发现的不一致性。

4️⃣ 达成

直到这时，智能体才入手将本体的 Java 文献写入 src/。开发者按任务缓缓驱动这一步：

达成的领导：

/speckit-implement 只运行 Phase 1 中的任务 T001*。*

实用技巧：按任务缓缓达成，并开启策画模式。 一次性运行 /speckit-implement 并让智能体在单次运行中完成 tasks.md 中的每个任务是很有诱导力的。不要这么作念。一次驱动一个任务（只运行任务 T001 来自 Phase 1），并在每次之前切换到 Claude Code 的策画模式（Shift+Tab 直到屏幕底部夸耀 plan mode on）。策画模式让智能体写出逐文献的策画，并在触碰任何代码之前恭候你的批准，这是表率与相反之间的果然查验点。每个任务完成后，快速审查相反，运行测试，然后再不息。如果某个任务揭示了表率中的缺失细节，停驻来先更新 spec.md，不要"在代码中斥地"然后就完事了。

当改日的变更恳求到来时，举例允许重复预订，咱们领先更新 "spec.md"，然后从更生成受影响的 "plan.md""、"tasks.md"" 和联系 Java 文献的部分。表率与系统保合手同步，因为它是变更参预的唯独阶梯。

7、扫尾语

表率驱动开发不是银弹，也不成替代工程判断。它更侧重于 AI 无法为咱们完成的职责部分，举例澄澈意图、衡量采取以及考证构建的内容是否如实是需要的。

智能体负责打字。咱们负责想考。

如果你想在果然阵势中尝试 SDD，我建议从小处入手，举例，从一个功能、一个仓库入手，并抵制住"我还是知说念要作念什么"就跳过表率的诱导。这种捷径恰是 SDD 试图冲突的风俗。一朝表率就位，SDLC 的其余部分就会嗅觉不那么像一系列脱节的派遣，而更像一条从意图到运行代码的单一、可挂牵的线。

我也很可爱使用 Spec Kit 作为 SDD 用具包凤凰体育app官网入口，它为 SDD 充任次序，强制践诺一致的文献布局，将每个要津包装在测试过的领导模板中，并将架构执法拿获在每个功能都必须盲从的宪法中。况兼因为相通的 /speckit-* 呐喊不管咱们指向 Claude Code、Cursor、Copilot 照旧 Gemini 都会产生相通的居品，是以如果用具发生变化，职责可以迁徙，使咱们与智能体无关。