Spec-Coding 实战系列教程：从规格到代码的自动化之旅

第1篇：环境搭建与第一个 Spec-Coding 项目

1.1 什么是 Spec-Coding

Spec-Coding 是一个开源的规格驱动代码生成工具，它的核心理念是：用结构化规格文件定义"做什么"，自动生成"怎么做"的代码骨架。与传统的 SDD（规格驱动开发）不同，spec-coding 不仅停留在文档层面，而是直接将规格转化为可编译、可运行的代码工程。

项目地址：https://github.com/dingyuana/spec-coding

核心价值：

• 统一团队编码规范：规格文件本身就是代码风格和架构的强制约束
• 消除样板代码：Controller、Service、Repository 层自动生成
• 需求变更可追溯：规格文件的每次修改对应代码的确定性变更
• 新人上手快：阅读规格文件即可理解项目全貌

1.2 环境准备

1.2.1 基础依赖

# 系统要求
- JDK 17+
- Maven 3.8+
- Git 2.30+

1.2.2 克隆项目

git clone https://github.com/dingyuana/spec-coding.git
cd spec-coding

1.2.3 项目结构解读

spec-coding/
├── spec-coding-core/          # 核心引擎：规格解析 + 代码生成
│   ├── src/main/java/
│   │   └── com/speccoding/
│   │       ├── parser/        # 规格文件解析器
│   │       ├── generator/     # 代码生成器
│   │       └── model/         # 中间表示模型
│   └── pom.xml
├── spec-coding-maven-plugin/  # Maven 插件：构建时自动生成
│   └── src/main/java/
├── spec-coding-examples/      # 示例项目
│   └── user-service/          # 用户服务完整示例
└── pom.xml

1.2.4 构建项目

# 编译安装到本地 Maven 仓库
mvn clean install -DskipTests

# 验证安装
mvn spec-coding:version

预期输出：

Spec-Coding Maven Plugin v1.0.0

1.3 第一个规格文件

1.3.1 创建项目

mkdir my-first-spec && cd my-first-spec

创建 pom.xml：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>my-first-spec</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <properties>
        <java.version>17</java.version>
        <speccoding.version>1.0.0</speccoding.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>com.speccoding</groupId>
            <artifactId>spec-coding-annotations</artifactId>
            <version>${speccoding.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.2.0</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>com.speccoding</groupId>
                <artifactId>spec-coding-maven-plugin</artifactId>
                <version>${speccoding.version}</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

1.3.2 编写第一个规格文件

在 src/main/resources/specs/ 目录下创建 hello-world.spec.yml：

api:
  name: hello-world
  version: 1.0.0
  description: 第一个 Spec-Coding 项目

models:
  - name: GreetingRequest
    description: 问候请求
    fields:
      - name: name
        type: String
        required: true
        description: 用户名称
        constraints:
          - notBlank
          - maxLength: 50

  - name: GreetingResponse
    description: 问候响应
    fields:
      - name: message
        type: String
        description: 问候消息
      - name: timestamp
        type: LocalDateTime
        description: 响应时间

services:
  - name: GreetingService
    description: 问候服务
    operations:
      - name: greet
        description: 生成问候语
        method: GET
        path: /api/greet
        parameters:
          - name: name
            type: String
            in: query
            required: true
        response: GreetingResponse
        businessRules:
          - "当 name 为空时，返回 'Hello, World!'"
          - "当 name 不为空时，返回 'Hello, {name}!'"

1.3.3 生成代码

mvn spec-coding:generate

生成后的项目结构：

src/main/java/com/example/
├── model/
│   ├── GreetingRequest.java      # 自动生成
│   └── GreetingResponse.java      # 自动生成
├── service/
│   └── GreetingService.java       # 自动生成
└── controller/
    └── GreetingController.java    # 自动生成

自动生成的 GreetingService.java：

package com.example.service;

import com.example.model.GreetingRequest;
import com.example.model.GreetingResponse;
import org.springframework.stereotype.Service;

import java.time.LocalDateTime;

@Service
public class GreetingService {

    /**
     * 生成问候语
     *
     * 业务规则：
     * - 当 name 为空时，返回 'Hello, World!'
     * - 当 name 不为空时，返回 'Hello, {name}!'
     */
    public GreetingResponse greet(String name) {
        // TODO: 实现业务逻辑
        String message;
        if (name == null || name.isBlank()) {
            message = "Hello, World!";
        } else {
            message = "Hello, " + name + "!";
        }

        GreetingResponse response = new GreetingResponse();
        response.setMessage(message);
        response.setTimestamp(LocalDateTime.now());
        return response;
    }
}

1.3.4 运行验证

mvn spring-boot:run

# 测试接口
curl "http://localhost:8080/api/greet?name=Spec-Coding"
# 输出：{"message":"Hello, Spec-Coding!","timestamp":"2026-07-16T10:00:00"}

1.4 本篇小结

本篇我们完成了 spec-coding 的环境搭建，并编写了第一个规格文件，亲眼看到从 YAML 规格到可运行的 Spring Boot 接口的全过程。下一篇我们将深入规格文件的编写规范，掌握数据模型定义、校验规则、业务规则描述等核心技巧。

第2篇：规格文件编写指南

2.1 规格文件总览

规格文件是 spec-coding 的「单一真相来源」，采用 YAML 格式，是整个代码生成的输入。一个完整的规格文件通常包含以下顶层节点：

api:        # API 元信息
models:     # 数据模型定义
services:   # 服务接口定义
enums:      # 枚举类型（可选）
errors:     # 错误码定义（可选）

2.2 数据模型定义详解

2.2.1 基础字段类型

models:
  - name: User
    description: 用户实体
    fields:
      - name: id
        type: Long
        description: 用户ID
        constraints:
          - notNull

      - name: username
        type: String
        description: 用户名
        required: true
        constraints:
          - notBlank
          - minLength: 3
          - maxLength: 20
          - pattern: "^[a-zA-Z0-9_]+$"

      - name: email
        type: String
        description: 邮箱
        constraints:
          - email

      - name: age
        type: Integer
        description: 年龄
        constraints:
          - min: 0
          - max: 150

      - name: balance
        type: BigDecimal
        description: 账户余额
        constraints:
          - decimalMin: "0.00"
          - decimalMax: "99999999.99"

      - name: status
        type: UserStatus
        description: 用户状态

      - name: createdAt
        type: LocalDateTime
        description: 创建时间

  - name: UserCreateRequest
    description: 创建用户请求
    extends: BaseRequest
    fields:
      - name: username
        type: String
        required: true

      - name: password
        type: String
        required: true
        constraints:
          - minLength: 8
          - maxLength: 64
          - pattern: "^(?=.*[A-Za-z])(?=.*\\d).+$"

支持的基础类型：

支持的校验约束：

2.3 枚举定义

enums:
  - name: UserStatus
    description: 用户状态
    values:
      - ACTIVE
      - INACTIVE
      - SUSPENDED
      - DELETED

  - name: OrderStatus
    description: 订单状态
    values:
      - name: PENDING_PAYMENT
        description: 待支付
        code: 1
      - name: PAID
        description: 已支付
        code: 2
      - name: SHIPPED
        description: 已发货
        code: 3

生成的 Java 枚举：

public enum UserStatus {
    ACTIVE,
    INACTIVE,
    SUSPENDED,
    DELETED
}

public enum OrderStatus {
    PENDING_PAYMENT(1, "待支付"),
    PAID(2, "已支付"),
    SHIPPED(3, "已发货");

    private final int code;
    private final String description;

    OrderStatus(int code, String description) {
        this.code = code;
        this.description = description;
    }
}

2.4 服务接口定义

2.4.1 基础 CRUD 操作

services:
  - name: UserService
    description: 用户管理服务
    path: /api/users
    operations:
      - name: createUser
        description: 创建用户
        method: POST
        request: UserCreateRequest
        response: User
        businessRules:
          - "用户名必须唯一，重复时抛出 DUPLICATE_USERNAME 错误"
          - "密码需加密存储，使用 BCrypt 算法"
        errors:
          - DUPLICATE_USERNAME
          - VALIDATION_ERROR

      - name: getUserById
        description: 根据ID查询用户
        method: GET
        path: /{id}
        parameters:
          - name: id
            type: Long
            in: path
            required: true
        response: User
        errors:
          - USER_NOT_FOUND

      - name: updateUser
        description: 更新用户信息
        method: PUT
        path: /{id}
        parameters:
          - name: id
            type: Long
            in: path
            required: true
        request: UserUpdateRequest
        response: User
        errors:
          - USER_NOT_FOUND
          - VALIDATION_ERROR

      - name: deleteUser
        description: 删除用户（软删除）
        method: DELETE
        path: /{id}
        parameters:
          - name: id
            type: Long
            in: path
            required: true
        response: void
        errors:
          - USER_NOT_FOUND

      - name: listUsers
        description: 分页查询用户列表
        method: GET
        parameters:
          - name: page
            type: Integer
            in: query
            defaultValue: 1
          - name: size
            type: Integer
            in: query
            defaultValue: 20
          - name: status
            type: UserStatus
            in: query
        response: Page<User>

2.4.2 复杂业务规则描述

spec-coding 支持用结构化的方式描述复杂业务规则，生成对应的验证代码骨架：

services:
  - name: OrderService
    operations:
      - name: createOrder
        description: 创建订单
        method: POST
        path: /api/orders
        request: CreateOrderRequest
        response: Order
        businessRules:
          - rule: "库存校验"
            description: "下单时检查商品库存是否充足，不足时抛出 INSUFFICIENT_STOCK 错误"
            trigger: "BEFORE_CREATE"
            errorCode: INSUFFICIENT_STOCK

          - rule: "金额计算"
            description: "订单总金额 = 商品单价 × 数量 - 优惠金额 + 运费"
            trigger: "DURING_CREATE"
            formula: "totalAmount = unitPrice * quantity - discountAmount + shippingFee"

          - rule: "状态流转"
            description: "订单创建后状态为 PENDING_PAYMENT，支付成功后变为 PAID"
            trigger: "AFTER_CREATE"
            initialState: PENDING_PAYMENT

          - rule: "超时取消"
            description: "创建后 30 分钟内未支付自动取消"
            trigger: "SCHEDULED"
            delay: 30m
            action: CANCEL

生成的代码骨架：

@Service
public class OrderService {

    public Order createOrder(CreateOrderRequest request) {
        // [BusinessRule] 库存校验: BEFORE_CREATE
        validateStock(request);

        // [BusinessRule] 金额计算: DURING_CREATE
        BigDecimal totalAmount = calculateTotalAmount(request);

        // 保存订单
        Order order = saveOrder(request, totalAmount);

        // [BusinessRule] 状态流转: AFTER_CREATE
        order.setStatus(OrderStatus.PENDING_PAYMENT);

        // [BusinessRule] 超时取消: SCHEDULED (30m)
        scheduleCancelTask(order.getId(), Duration.ofMinutes(30));

        return order;
    }

    private void validateStock(CreateOrderRequest request) {
        // TODO: 实现库存校验逻辑
        // 不足时抛出 InsufficientStockException
    }

    private BigDecimal calculateTotalAmount(CreateOrderRequest request) {
        // TODO: 实现公式 totalAmount = unitPrice * quantity - discountAmount + shippingFee
        return BigDecimal.ZERO;
    }
}

2.5 错误码定义

errors:
  - code: USER_NOT_FOUND
    httpStatus: 404
    message: "用户不存在"
    description: "根据ID查询用户时，用户不存在"

  - code: DUPLICATE_USERNAME
    httpStatus: 409
    message: "用户名已存在"
    description: "创建用户时，用户名重复"

  - code: VALIDATION_ERROR
    httpStatus: 400
    message: "参数校验失败"
    description: "请求参数不符合规格约束"

  - code: INSUFFICIENT_STOCK
    httpStatus: 400
    message: "库存不足"
    description: "下单时商品库存不足以满足订单数量"

  - code: INTERNAL_ERROR
    httpStatus: 500
    message: "系统内部错误"
    description: "未预期的运行时异常"

生成的错误码类和全局异常处理器：

public enum ErrorCode {
    USER_NOT_FOUND(404, "用户不存在"),
    DUPLICATE_USERNAME(409, "用户名已存在"),
    VALIDATION_ERROR(400, "参数校验失败"),
    INSUFFICIENT_STOCK(400, "库存不足"),
    INTERNAL_ERROR(500, "系统内部错误");

    private final int httpStatus;
    private final String message;
}

2.6 本篇小结

本篇详细介绍了 spec-coding 规格文件的编写规范，涵盖了数据模型、枚举、服务接口、业务规则和错误码的全部定义方式。有了这些基础，下一篇我们将学习如何编写业务逻辑实现，把 TODO 注释变成真正的代码。

第3篇：业务逻辑实现与测试

3.1 实现策略

spec-coding 生成的代码遵循 「生成骨架 + 手写实现」 的分层策略：

┌─────────────────────────────────┐
│  spec-coding 自动生成（不可修改）  │
│  - Model / DTO                  │
│  - Controller                   │
│  - Service 接口/骨架            │
│  - 异常类 / 错误码              │
├─────────────────────────────────┤
│  开发者手写实现（可修改）          │
│  - ServiceImpl                  │
│  - Repository / Mapper          │
│  - 单元测试                      │
│  - 业务逻辑                      │
└─────────────────────────────────┘

spec-coding 通过 protected region（保护区） 机制，在生成代码中保留开发者手写的业务逻辑。每次重新生成时，只有保护区外的代码会被覆盖。

3.2 保护区机制

以 UserServiceImpl.java 为例：

@Service
public class UserServiceImpl implements UserService {

    private final UserRepository userRepository;

    public UserServiceImpl(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // ===== SPEC-CODING GENERATED: createUser =====
    @Override
    public User createUser(UserCreateRequest request) {
        // SPEC-CODING PROTECTED REGION START: createUser
        // 在此区域内编写的代码不会被覆盖
        if (userRepository.existsByUsername(request.getUsername())) {
            throw new BusinessException(ErrorCode.DUPLICATE_USERNAME);
        }

        String encodedPassword = passwordEncoder.encode(request.getPassword());

        User user = new User();
        user.setUsername(request.getUsername());
        user.setPassword(encodedPassword);
        user.setEmail(request.getEmail());
        user.setStatus(UserStatus.ACTIVE);
        user.setCreatedAt(LocalDateTime.now());

        return userRepository.save(user);
        // SPEC-CODING PROTECTED REGION END: createUser
    }
    // ===== END GENERATED =====

    // ===== SPEC-CODING GENERATED: getUserById =====
    @Override
    public User getUserById(Long id) {
        // SPEC-CODING PROTECTED REGION START: getUserById
        return userRepository.findById(id)
                .orElseThrow(() -> new BusinessException(ErrorCode.USER_NOT_FOUND));
        // SPEC-CODING PROTECTED REGION END: getUserById
    }
    // ===== END GENERATED =====
}

3.3 为规格生成测试用例

spec-coding 不仅生成实现代码，还能根据规格中的约束和业务规则自动生成测试用例骨架：

mvn spec-coding:generate-tests

生成的测试文件 UserServiceTest.java：

@SpringBootTest
class UserServiceTest {

    @Autowired
    private UserService userService;

    @Autowired
    private UserRepository userRepository;

    @BeforeEach
    void setUp() {
        userRepository.deleteAll();
    }

    // 自动生成：基于规格字段 required=true 和 notBlank
    @Test
    void shouldThrowValidationErrorWhenUsernameIsBlank() {
        UserCreateRequest request = new UserCreateRequest();
        request.setUsername("");  // 违反 notBlank 约束
        request.setPassword("ValidPass123");

        assertThrows(BusinessException.class, () -> {
            userService.createUser(request);
        });
    }

    // 自动生成：基于 minLength=8 约束
    @Test
    void shouldThrowValidationErrorWhenPasswordTooShort() {
        UserCreateRequest request = new UserCreateRequest();
        request.setUsername("validuser");
        request.setPassword("Ab1");  // 违反 minLength=8

        assertThrows(BusinessException.class, () -> {
            userService.createUser(request);
        });
    }

    // 自动生成：基于业务规则 "用户名必须唯一"
    @Test
    void shouldThrowDuplicateUsernameErrorWhenUsernameExists() {
        // Arrange
        UserCreateRequest first = new UserCreateRequest();
        first.setUsername("duplicate");
        first.setPassword("ValidPass123");
        userService.createUser(first);

        // Act & Assert
        UserCreateRequest second = new UserCreateRequest();
        second.setUsername("duplicate");
        second.setPassword("AnotherValid456");

        BusinessException exception = assertThrows(BusinessException.class, () -> {
            userService.createUser(second);
        });
        assertEquals(ErrorCode.DUPLICATE_USERNAME, exception.getErrorCode());
    }

    // 开发者补充的业务测试
    @Test
    void shouldCreateUserSuccessfully() {
        // Arrange
        UserCreateRequest request = new UserCreateRequest();
        request.setUsername("newuser");
        request.setPassword("ValidPass123");
        request.setEmail("newuser@example.com");

        // Act
        User user = userService.createUser(request);

        // Assert
        assertNotNull(user.getId());
        assertEquals("newuser", user.getUsername());
        assertEquals(UserStatus.ACTIVE, user.getStatus());
        assertNotNull(user.getCreatedAt());

        // 密码应被加密，而非明文存储
        assertNotEquals("ValidPass123", user.getPassword());
    }
}

3.4 规格变更与代码演进

spec-coding 的核心优势在于规格变更驱动的代码演进。当需求发生变化时：

步骤 1：修改规格文件

# 新增 email 字段唯一性约束
businessRules:
  - rule: "邮箱唯一"
    description: "用户邮箱必须唯一，重复时抛出 DUPLICATE_EMAIL 错误"
    errorCode: DUPLICATE_EMAIL

步骤 2：重新生成

mvn spec-coding:generate

步骤 3：保护区内的代码被保留，新增骨架自动插入

// SPEC-CODING PROTECTED REGION START: createUser
// ... 原有业务代码不受影响 ...

// 自动插入的新验证（在保护区内开发者可自由调整位置）
if (userRepository.existsByEmail(request.getEmail())) {
    throw new BusinessException(ErrorCode.DUPLICATE_EMAIL);
}
// SPEC-CODING PROTECTED REGION END: createUser

3.5 本篇小结

本篇介绍了 spec-coding 的保护区机制和测试用例自动生成能力，展示了「修改规格 → 重新生成 → 保留手写逻辑」的完整开发闭环。下一篇我们将学习如何将 spec-coding 集成到 CI/CD 流水线中，实现规格合规性自动检查。

第4篇：CI/CD 集成与团队协作

4.1 规格合规性检查

在 CI 流水线中，spec-coding 提供 verify 目标，用于检查：

mvn spec-coding:verify

检查规则：

4.2 GitHub Actions 集成

# .github/workflows/spec-coding-check.yml
name: Spec-Coding Compliance Check

on:
  pull_request:
    branches: [ main, develop ]
  push:
    branches: [ develop ]

jobs:
  spec-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Cache Maven packages
        uses: actions/cache@v4
        with:
          path: ~/.m2
          key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}

      - name: Install spec-coding plugin
        run: mvn install -pl spec-coding-maven-plugin -DskipTests

      - name: Verify spec compliance
        run: mvn spec-coding:verify

      - name: Check code generation diff
        run: |
          mvn spec-coding:generate
          if [ -n "$(git diff --name-only)" ]; then
            echo "❌ 生成的代码与仓库不一致，请重新运行 mvn spec-coding:generate"
            git diff
            exit 1
          fi
          echo "✅ 代码与规格一致"

      - name: Run generated tests
        run: mvn test

4.3 团队协作流程

spec-coding 推荐的团队协作流程：

4.4 最佳实践总结

1. 规格先行：任何功能开发前，先提交规格文件的 PR 并通过评审
2. 保护区最小化：保护区范围尽量小，减少 merge 冲突概率
3. 测试驱动生成：优先利用 generate-tests 生成测试骨架，再用 TDD 填充
4. 定期同步：每次拉取最新代码后先运行 mvn spec-coding:generate，确保代码与规格一致
5. 规格即文档：将规格文件纳入项目文档体系，新人通过 .spec.yml 文件理解项目架构

4.5 本篇小结

本篇介绍了 spec-coding 在 CI/CD 中的集成方式，以及推荐的团队协作流程。通过将规格检查纳入持续集成流水线，可以确保代码始终与规格保持一致，有效防止「规格文档沦为摆设」的常见问题。

第5篇：实战——构建一个完整的电商订单系统

5.1 需求概述

构建一个简化版电商订单系统，包含以下核心能力：

• 商品管理：商品 CRUD、库存管理
• 订单管理：下单、支付、发货、取消
• 用户管理：注册、登录、信息维护

5.2 完整规格文件

src/main/resources/specs/order-system.spec.yml：

api:
  name: order-system
  version: 1.0.0
  description: 电商订单系统

enums:
  - name: OrderStatus
    values:
      - PENDING_PAYMENT
      - PAID
      - SHIPPED
      - DELIVERED
      - CANCELLED
      - REFUNDED

models:
  - name: Product
    fields:
      - name: id
        type: Long
      - name: name
        type: String
        required: true
        constraints:
          - notBlank
          - maxLength: 100
      - name: price
        type: BigDecimal
        required: true
        constraints:
          - decimalMin: "0.01"
      - name: stock
        type: Integer
        required: true
        constraints:
          - min: 0
      - name: status
        type: String
        defaultValue: "ON_SALE"

  - name: OrderItem
    fields:
      - name: productId
        type: Long
        required: true
      - name: productName
        type: String
      - name: unitPrice
        type: BigDecimal
      - name: quantity
        type: Integer
        required: true
        constraints:
          - min: 1
          - max: 999

  - name: Order
    fields:
      - name: id
        type: Long
      - name: orderNo
        type: String
      - name: userId
        type: Long
      - name: items
        type: List<OrderItem>
      - name: totalAmount
        type: BigDecimal
      - name: status
        type: OrderStatus
      - name: createdAt
        type: LocalDateTime

services:
  - name: OrderService
    path: /api/orders
    operations:
      - name: createOrder
        method: POST
        request: CreateOrderRequest
        response: Order
        businessRules:
          - rule: "库存校验与扣减"
            description: "下单时需检查所有商品库存并原子性扣减"
            trigger: BEFORE_CREATE
            errorCode: INSUFFICIENT_STOCK
          - rule: "订单金额计算"
            description: "totalAmount = SUM(item.unitPrice × item.quantity)"
            trigger: DURING_CREATE
          - rule: "超时自动取消"
            description: "创建后 30 分钟未支付自动取消并恢复库存"
            trigger: SCHEDULED
            delay: 30m
            action: CANCEL

      - name: payOrder
        method: POST
        path: /{orderNo}/pay
        response: Order
        businessRules:
          - rule: "状态校验"
            description: "只有 PENDING_PAYMENT 状态的订单可以支付"
            trigger: PRE_CHECK
            allowedStatuses:
              - PENDING_PAYMENT
          - rule: "状态流转"
            description: "支付成功后状态变更为 PAID"
            trigger: POST_ACTION
            targetStatus: PAID

5.3 生成代码与运行

# 生成代码
mvn spec-coding:generate

# 生成测试骨架
mvn spec-coding:generate-tests

# 运行测试
mvn test

# 启动应用
mvn spring-boot:run

5.4 系统架构图

5.5 本篇小结

通过这个电商订单系统的实战案例，我们完整演示了从需求分析、规格编写到代码生成的全流程。spec-coding 的价值在于：当需求变更时（如新增退款流程、修改超时时间），只需修改规格文件并重新生成，保护区内已有的业务逻辑代码不受影响。

系列总结

本系列教程围绕 spec-coding 项目，从环境搭建、规格编写、业务实现、CI/CD 集成到项目实战，系统介绍了规格驱动代码生成的完整开发模式。

核心收获：

1. 规格即代码：YAML 规格文件是唯一的真相来源，代码生成完全由规格驱动
2. 保护区机制：生成骨架与手写实现清晰分层，变更不丢代码
3. 自动化测试：基于规格约束自动生成测试用例，提升测试覆盖效率
4. CI/CD 友好：将规格合规性检查纳入流水线，确保代码与规格始终保持一致

规格写一次，代码处处一致——这就是 spec-coding 的核心理念。

参考资料

• spec-coding 项目：https://github.com/dingyuana/spec-coding
• YAML 规范：https://yaml.org/spec/
• Spring Boot 官方文档：https://docs.spring.io/spring-boot/docs/current/reference/html/