作为软件拓荒者，咱们在表情中见过太屡次这么的场景：规格讲解书在表情启动时写好，争论了几周，然后被偷偷埋在 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，皇冠app(中国)官网入口要么我方编写教导。

如果你的团队磋商持重使用 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/ 下的通盘内容都是生成的内容，开云·体育中国官方网站它是输出，而不是真相来源，其中的每一瞥都应该可以回首到 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 器具包，它为 SDD 充任规律，强制奉行一致的文献布局，将每个法子包装在测试过的教导模板中开云·体育中国官方网站，并将架构法则拿获在每个功能都必须遵命的宪法中。何况因为沟通的 /speckit-* 大喊无论咱们指向 Claude Code、Cursor、Copilot 如故 Gemini 都会产生沟通的家具，是以如果器具发生变化，责任可以迁徙，使咱们与智能体无关。