从感觉编程到规格驱动开发：spec-kit如何重塑AI时代的软件工程实践

1. 项目概述：从“感觉编程”到“规格驱动”的范式革命

最近在GitHub上，一个名为“spec-kit”的项目以惊人的速度冲上了趋势榜，短短时间内就收获了超过98.5k的星标。这个由GitHub官方开源的工具，被许多开发者视为一个明确的信号：它正在将过去几年在AI编程浪潮中盛行起来的“vibe coding”（感觉编程）模式，逐渐扫进历史的垃圾桶。作为一个长期在一线编码的开发者，我最初看到这个标题时，内心是有些怀疑的。毕竟，“vibe coding”虽然听起来玄乎，但它背后代表的是一种高度依赖AI助手（如GitHub Copilot、Cursor）进行直觉式、对话式编程的工作流，这种模式在提升初期原型搭建和代码补全效率上，确实有其价值。然而，当我深入研究了spec-kit及其倡导的“Spec-Driven Development”（规格驱动开发，简称SDD）后，我才意识到，这不仅仅是一个新工具，更是一场关于如何与AI协作、如何构建可靠软件的根本性思维转变。

简单来说，vibe coding就像是你和一位非常聪明但有点“飘”的架构师在合作。你给他一个模糊的想法，比如“帮我写个用户登录的API”，他可能会给你生成一段看起来能用的代码。但这段代码是否考虑了密码加密、会话管理、错误处理、速率限制？可能考虑了，也可能没考虑，全凭AI当时的“感觉”和你提示词（prompt）的运气。最终的代码质量如同开盲盒，充满了不确定性。而spec-kit代表的SDD，则要求你先成为一名严谨的产品经理或系统设计师。在写第一行代码之前，你必须先用一种结构化的、机器可读的“规格”（Specification）语言，清晰地定义出这个API的完整契约：它的端点路径、HTTP方法、请求/响应体的JSON结构、状态码、可能的错误类型、甚至是非功能性需求如性能指标。然后，spec-kit这个工具会利用这个规格文件，作为唯一的事实来源，去驱动后续的几乎所有开发环节：生成初始的框架代码、创建测试用例、验证实现是否符合规格、生成API文档等。

这种转变的核心在于，它将软件开发从一种基于“模糊意图”的生成过程，转变为一种基于“精确定义”的验证过程。AI的角色从一个需要你不断用自然语言去“引导”和“纠正”的创意伙伴，转变为一个严格遵循你制定的蓝图、高效执行具体任务的工程师。这对于构建中大型、需要长期维护、对稳定性和一致性要求极高的项目来说，无疑是更优的路径。接下来，我将结合自己的实践，深度拆解spec-kit如何工作，以及我们如何从“vibe coder”平滑过渡到“spec-driven developer”。

2. 核心思路拆解：规格为何能成为“唯一事实来源”

要理解spec-kit的威力，首先要摒弃“规格书只是给人类看的文档”这种旧观念。在SDD范式中，规格文件（通常是OpenAPI Spec、AsyncAPI Spec或一种更通用的格式）是一个活的、可执行的权威定义。它是整个项目生命周期中，连接需求、设计、开发、测试、文档和协作的枢纽。

2.1 规格驱动开发的核心价值闭环

传统的开发流程往往是线性的，也可能伴随着大量的反复。而SDD构建了一个以规格为中心的闭环，这个闭环主要由以下几个关键环节构成，spec-kit在其中扮演了自动化枢纽的角色：

1. 设计即定义：在编码开始前，团队（包括产品、后端、前端、测试）共同使用规格语言来定义接口。这个过程本身就是一个极佳的设计评审和达成共识的过程。任何歧义都会在早期暴露出来，比如“这个createdAt字段返回的是字符串还是时间戳？时区是什么格式？”。
2. 规格即代码生成蓝图：有了清晰的规格，spec-kit可以调用相应的代码生成器插件。例如，对于一个定义好的OpenAPI 3.0规格文件，它可以生成：
   • 服务器端框架代码：生成Spring Boot的Controller接口、DTO类，或者Express.js的路由和模型定义。
   • 客户端SDK：生成TypeScript的类型定义和API调用函数，或者Java、Python的客户端库。
   • 数据库模型：如果规格中定义了数据实体，甚至可以生成SQL迁移脚本或ORM模型。
   • 这解决了vibe coding中代码结构不一致、风格混杂的问题，因为所有生成的代码都遵循同一套源自规格的模板。
3. 规格即测试套件：这是SDD最强大的特性之一。规格不仅定义了“应该有什么”，也隐含定义了“不应该有什么”。spec-kit可以利用规格自动生成契约测试（Contract Tests）的用例骨架。例如，针对一个POST /users接口，它会自动生成测试：请求体符合规格时是否返回201，缺少必填字段时是否返回400，字段类型错误时是否返回422等。开发者只需要填充这些测试骨架中的业务逻辑断言部分。
4. 规格即最新文档：基于同一份规格文件，可以实时生成美观、交互式的API文档（比如通过Swagger UI或Redoc）。由于文档和代码/测试同源，因此永远不会出现过时的问题。再也不用担心开发者改了代码却忘了更新Wiki。
5. 规格即协作合同：后端和前端团队可以基于这份规格并行开发。前端可以先用生成的TypeScript类型和Mock服务器进行开发，后端则专注于实现业务逻辑并通过契约测试。规格成了团队间不可撼动的“合同”，减少了大量的联调扯皮时间。

实操心得：规格的“活”性刚开始实践时，最容易犯的错误是把写规格当成一个一次性的、繁琐的前置任务。实际上，规格应该是一个随着项目演进而不断迭代的活文档。我的工作流是：在实现一个新功能或修改一个旧接口时，首先去更新对应的规格文件。然后运行spec-kit，让它告诉我，基于新的规格，我的代码实现有哪些地方需要同步修改，我的测试用例需要如何更新。这相当于让规格成为了代码的“编译期检查器”，在运行时错误发生之前就提前预警。

2.2 spec-kit vs. 传统代码生成器与vibe coding

很多人会问，代码生成器（如Swagger Codegen）早就有了，spec-kit有什么不同？而vibe coding用的AI不也能生成代码吗？

• 与传统代码生成器相比：传统的工具往往是“一次性”的。你生成代码后，就与原始的规格文件脱钩了。后续手动修改了生成的代码，这些改动无法同步回规格，导致规格与实现逐渐偏离。spec-kit的设计理念是“双向绑定”或至少是“持续验证”。它更倾向于作为一个守护进程（daemon）或CI/CD流水线中的一环，持续地检查你的代码库是否仍然符合规格定义。它可能不会直接覆盖你手动编写的业务逻辑代码，但会标记出不符合规格的差异，提醒你修复。
• 与vibe coding相比：这是范式层面的区别。vibe coding是“提示词 -> 黑盒 -> 代码”，过程不透明，结果不可预测，且缺乏系统性。spec-kit是“规格（可视为一种高级、结构化的提示词）-> 确定性的生成与验证 -> 符合规格的代码+测试”。它把AI的创造力从“发明实现细节”引导到“辅助编写和优化规格”以及“在规格约束下填充复杂业务逻辑”这两个更可控、价值更高的方向上。你可以用AI来帮你把模糊的产品需求润色成严谨的OpenAPI描述，或者在生成了CRUD框架后，让AI帮你编写核心的业务算法函数。

注意：转向SDD并不意味着完全抛弃AI编程助手。恰恰相反，它们可以结合得更好。你可以用Copilot或Cursor来帮助你更快地编写和修改YAML/JSON格式的规格文件，或者在你用spec-kit生成的基础代码上，让AI助手帮你填充那些重复性高、模式固定的业务逻辑代码。AI从“主驾驶员”变成了“副驾驶”或“高效执行者”，而规格和spec-kit组成的系统则是“导航仪”和“交规”。

3. 实战入门：从零开始一个Spec-Driven项目

理论说了这么多，我们来看一个具体的例子。假设我们要开发一个简单的待办事项（Todo）后端API。我们将使用OpenAPI 3.0作为规格语言，spec-kit作为驱动工具。

3.1 环境准备与规格定义

首先，你需要安装spec-kit。它是一个Node.js工具，可以通过npm全局安装：

npm install -g @github/spec-kit

接下来，创建项目目录并初始化一个OpenAPI规格文件。我强烈建议从一份清晰的规格开始，而不是先写代码。在项目根目录创建openapi.yaml：

openapi: 3.0.3 info: title: Todo List API version: 1.0.0 description: A simple spec-driven todo list API servers: - url: http://localhost:3000/api paths: /todos: get: summary: List all todo items operationId: listTodos responses: '200': description: A list of todos content: application/json: schema: type: array items: $ref: '#/components/schemas/TodoItem' post: summary: Create a new todo item operationId: createTodo requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/CreateTodoRequest' responses: '201': description: Created content: application/json: schema: $ref: '#/components/schemas/TodoItem' '400': description: Invalid input /todos/{id}: get: summary: Get a todo item by ID operationId: getTodoById parameters: - name: id in: path required: true schema: type: string responses: '200': description: Success content: application/json: schema: $ref: '#/components/schemas/TodoItem' '404': description: Todo not found put: summary: Update a todo item operationId: updateTodo parameters: - name: id in: path required: true schema: type: string requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/UpdateTodoRequest' responses: '200': description: Updated content: application/json: schema: $ref: '#/components/schemas/TodoItem' '404': description: Todo not found delete: summary: Delete a todo item operationId: deleteTodo parameters: - name: id in: path required: true schema: type: string responses: '204': description: Successfully deleted '404': description: Todo not found components: schemas: TodoItem: type: object properties: id: type: string format: uuid readOnly: true title: type: string example: 'Buy groceries' description: type: string example: 'Milk, Eggs, Bread' completed: type: boolean default: false createdAt: type: string format: date-time readOnly: true updatedAt: type: string format: date-time readOnly: true required: - id - title - completed - createdAt - updatedAt CreateTodoRequest: type: object properties: title: type: string minLength: 1 maxLength: 255 description: type: string completed: type: boolean default: false required: - title UpdateTodoRequest: type: object properties: title: type: string minLength: 1 maxLength: 255 description: type: string completed: type: boolean required: []

这份规格定义了完整的CRUD接口，包含了数据模型、验证规则（如minLength）和精确的HTTP状态码。注意，我们使用了readOnly来标记哪些字段是服务器生成的，客户端不能修改。这就是“设计即定义”。

3.2 使用spec-kit生成项目骨架

有了规格文件，我们就可以让spec-kit来搭建项目了。spec-kit本身是一个框架，它通过插件系统来支持不同的技术栈。假设我们选择Node.js + Express.js + TypeScript这个技术栈，并且希望使用Prisma作为ORM。

我们需要安装对应的插件。通常，社区或官方会提供如@spec-kit/plugin-express-typescript或@spec-kit/plugin-prisma这样的插件。由于spec-kit生态还在快速发展，具体插件名可能需要查询其官方文档。这里我们以概念性命令演示：

# 假设我们有一个集成的启动插件 spec-kit init --spec openapi.yaml --template node-express-ts-prisma --output .

这个命令可能会做以下几件事：

1. 创建package.json，安装Express、TypeScript、Prisma、Jest等依赖。
2. 根据规格中的components.schemas，生成Prisma的数据库模式文件prisma/schema.prisma，将TodoItem等模型映射为数据表。
3. 在src/routes/目录下，生成对应的路由文件（如todos.ts），其中包含了每个操作（listTodos,createTodo等）的空函数骨架，以及基于Zod或class-validator的请求验证中间件。这些路由已经挂载到了正确的路径（/api/todos）和方法上。
4. 在src/types/目录下，生成与规格对应的TypeScript接口定义文件，确保类型安全。
5. 在tests/contract/目录下，生成基于SuperTest或类似库的契约测试文件，为每个API端点生成基本的正向和反向测试用例。
6. 生成docker-compose.yml用于启动本地数据库，以及基本的CI/CD配置文件（如GitHub Actions工作流）。

实操心得：生成代码的结构控制生成代码虽好，但项目结构是否符合团队习惯？spec-kit的模板（--template）和插件配置通常允许你进行一定程度的定制。在正式用于生产项目前，务必花时间创建一个属于自己团队的、经过打磨的基础模板。这个模板应该包含你们约定的目录结构、代码风格（ESLint/Prettier配置）、日志中间件、错误处理框架、认证授权的基础集成等。这样，每次用spec-kit初始化新服务，得到的都是一个“生产就绪”的起点，而不是一个需要大量改造的玩具项目。

3.3 填充业务逻辑与实现验证

生成的项目骨架提供了“管道”（路由、验证、数据库连接），但核心的“业务逻辑”仍然是空的。例如，在src/routes/todos.ts中，createTodo函数可能长这样：

import { Request, Response } from 'express'; import { CreateTodoRequest } from '../types/openapi'; import { prisma } from '../lib/prisma'; export const createTodo = async ( req: Request<{}, {}, CreateTodoRequest>, res: Response ) => { // TODO: 1. 验证请求体 (已由中间件完成) // TODO: 2. 将数据写入数据库 // TODO: 3. 返回创建的资源 try { const { title, description, completed } = req.body; // 业务逻辑实现开始 const newTodo = await prisma.todo.create({ data: { title, description: description || null, completed: completed || false, }, }); // 业务逻辑实现结束 res.status(201).json(newTodo); } catch (error) { // TODO: 错误处理 res.status(500).json({ message: 'Internal server error' }); } };

现在，开发者的任务就变得非常清晰和聚焦：在// TODO注释的位置，使用Prisma客户端进行数据库操作，并添加适当的错误处理。你可以继续使用AI编程助手来高效地编写这些具体的数据库查询和业务规则代码，因为上下文（函数签名、输入输出类型、可用依赖）已经由规格和生成代码定义得非常明确了。

实现验证是SDD的关键一步。运行spec-kit的验证命令：

spec-kit validate --spec openapi.yaml --implementation-dir ./src

这个命令会扫描你的src目录下的实现代码，检查：

• 所有在规格中定义的路径（/todos,/todos/{id}）是否都有对应的路由处理函数。
• 这些处理函数的输入参数类型、返回值类型是否与规格中定义的schema匹配。
• 是否所有声明的HTTP状态码（200, 201, 400, 404等）在代码中都有对应的返回路径。

如果验证失败，它会给出具体的错误信息，比如“路径/todos/{id}的PUT操作未找到实现函数”或“函数updateTodo的返回类型缺少updatedAt字段”。这就像TypeScript的编译时类型检查，但是在API契约层面。

3.4 运行自动化契约测试

接下来，运行之前生成的契约测试。这些测试不关心你的数据库里具体有什么数据，它们只关心你的API行为是否遵守了签下的“合同”（即规格）。

npm run test:contract

测试套件会自动启动你的应用（或在测试环境中构建一个实例），然后逐一调用API，验证：

• 发送一个符合CreateTodoRequest的POST请求，是否返回201状态码和符合TodoItemschema的响应体。
• 发送一个缺少title字段的POST请求，是否返回400状态码。
• 发送一个不存在的ID给GET /todos/{id}，是否返回404。
• ……

这些测试保证了你的实现与规格的一致性，并且这种保证是自动化的、可重复的。当你在未来修改业务逻辑代码时，这些契约测试能第一时间告诉你，你的修改是否意外地破坏了已有的API约定。

4. 深入解析：spec-kit的高级特性与集成生态

spec-kit不仅仅是一个代码生成器，它的目标是成为规格驱动开发工作流的核心引擎。要发挥其最大威力，需要了解它的一些高级特性和如何融入现有的开发生态。

4.1 插件化架构与生态扩展

spec-kit的核心非常轻量，大部分功能由插件提供。这种设计让它可以灵活适配各种技术栈和工具链。常见的插件类型包括：

• 生成器插件：如前文所示，负责将规格转换为特定框架的代码（Express, Spring Boot, Django, .NET等）。
• 验证器插件：负责检查实现代码与规格的一致性。除了官方提供的通用验证器，社区可以为特定框架（如NestJS）开发更深度集成的验证规则。
• 测试器插件：集成不同的测试框架（Jest, Mocha, Pytest, JUnit），生成和运行契约测试。
• 文档插件：自动生成并部署API文档到特定平台（如GitHub Pages, ReadMe.com）。
• 发布插件：在验证和测试通过后，自动将生成的客户端SDK发布到包管理器（npm, Maven, PyPI）。

配置示例：在你的项目根目录创建一个spec-kit.config.js文件，可以精细控制插件行为：

// spec-kit.config.js export default { spec: './openapi.yaml', plugins: [ { name: '@spec-kit/plugin-express-ts', config: { outputDir: './src/generated', validateResponses: true, // 在开发模式启用响应验证 } }, { name: '@spec-kit/plugin-prisma', config: { schemaFile: './prisma/schema.prisma' } }, { name: '@spec-kit/plugin-jest-contract', config: { testDir: './tests/contract', baseUrl: process.env.API_BASE_URL || 'http://localhost:3000' } } ], workflows: { onSpecChange: ['generate', 'validate'], // 当规格文件变化时，自动重新生成并验证 preCommit: ['validate', 'test:contract'], // 提交代码前自动运行验证和契约测试 } };

通过配置文件，你可以定义自动化工作流。例如，结合Git的pre-commit钩子或监听文件变化，实现规格变更后相关代码的自动同步和校验，确保项目始终处于一致状态。

4.2 与CI/CD流水线的深度集成

规格驱动开发的真正威力在持续集成和持续部署（CI/CD）中才能完全展现。将spec-kit集成到你的CI流水线（如GitHub Actions, GitLab CI）中，可以建立强大的质量门禁。

一个典型的CI流水线步骤可能如下：

1. 代码检出与安装：拉取代码，安装依赖（包括spec-kit及其插件）。
2. 规格语法与规范性检查：使用spectral等工具对openapi.yaml进行静态分析，检查是否符合最佳实践，有无矛盾之处。
3. 生成与验证：运行spec-kit generate和spec-kit validate。这一步可以作为一个“门禁”，如果实现代码与规格不匹配，则CI失败。这强制了开发者在提交代码前必须更新规格或调整代码。
4. 运行契约测试：执行npm run test:contract。契约测试必须全部通过。
5. 运行集成/单元测试：执行业务逻辑相关的测试。
6. 构建与部署：构建应用镜像。同时，可以利用规格文件自动生成最新版的API文档，并部署到文档站点。
7. 发布客户端SDK：（可选）如果这是一个公开API，可以在发布新版本时，自动将生成的客户端SDK发布到对应的包仓库。

实操心得：将“契约测试”作为CI的核心环节在我的团队实践中，我们把契约测试的通过率设为CI流水线能否进入部署阶段的硬性指标。这意味着，任何破坏API向后兼容性的代码变更（比如删除了一个响应字段，或者错误地改变了某个字段的类型），都会在CI阶段被立即发现并阻止。这极大地增强了我们API的稳定性和消费者（前端、移动端）的信心。相比之前依赖人工沟通和偶尔的手动测试，这种自动化的、基于契约的验证为我们节省了大量排查线上问题的时间。

4.3 处理规格的演进与版本管理

API不可能一成不变。如何管理规格的变更，是SDD实践中必须面对的问题。spec-kit鼓励并支持良好的API演进策略。

• 非破坏性变更：这是首选。例如，为响应体添加一个新的可选字段，或者添加一个新的API端点。这类变更不会导致已有的契约测试失败，spec-kit的验证也会轻松通过。你只需要更新规格文件，重新生成代码（可能主要是类型定义），然后实现新的功能即可。
• 破坏性变更：当不得不进行破坏性变更时（如删除字段、修改字段类型），需要引入版本管理。OpenAPI本身支持通过servers.url或路径前缀（如/v2/todos）来区分版本。spec-kit可以配合多份规格文件（openapi.v1.yaml,openapi.v2.yaml）来生成和维护不同版本的代码。在过渡期内，可以同时运行v1和v2的API，并引导消费者迁移。
• 规格拆分与引用：对于大型项目，一个庞大的openapi.yaml文件难以维护。可以使用OpenAPI的$ref语法，将路径、数据模型拆分到不同的子文件中。spec-kit同样可以处理这种引用关系。你可以使用工具（如swagger-inline）甚至编写脚本，从代码注释中提取部分规格信息，实现“代码与规格”的双向同步，但这需要更复杂的配置。

注意：虽然spec-kit强调规格先行，但在实际开发中，尤其是在探索性项目中，完全“规格锁定”后再编码可能不现实。一个更灵活的工作流是：“迭代式规格驱动”。即先快速定义一个最小可行规格（MVP Spec），生成基础代码，然后开始编码。在编码过程中，一旦发现规格需要调整，立即回头修改规格文件，然后利用spec-kit重新生成/验证，确保变更被同步记录和传播。这避免了规格与代码的脱节，形成了“修改规格 -> 自动同步 -> 继续开发”的快速闭环。

5. 常见问题与避坑指南

在从vibe coding转向spec-driven development的过程中，我和团队踩过不少坑。这里总结一些典型问题和解决方案，希望能帮你平滑过渡。

5.1 思维转变的挑战与应对

问题1：觉得写规格太慢，耽误了“真正”的编码时间。这是最常见的初期抵触心理。应对方法是改变对“编码”的定义。在SDD中，编写精确的规格就是最高效的编码前期工作。它消灭了后续的歧义、返工和联调扯皮。你可以通过工具提升效率：使用VSCode的OpenAPI编辑插件获得语法高亮和自动补全；利用AI助手根据你的自然语言描述生成初步的YAML片段，你再进行精修。

问题2：生成的代码不符合我们项目的特殊架构或约定。不要试图让一个通用工具完全理解你所有的内部规范。正确的做法是：定制或创建自己的spec-kit插件或模板。花时间投资一个符合你们团队标准的“黄金模板”，这个模板应该包含你们统一的错误处理中间件、日志格式、认证集成、数据库连接池配置等。之后，所有新项目都将从这个高标准起点开始，长期回报极高。

问题3：业务逻辑复杂，无法在规格中完全表达。规格不是用来描述算法内部如何实现的，它描述的是系统组件的边界和契约。复杂的业务规则、计算逻辑，仍然需要在生成的代码框架内手动实现。规格确保了这个复杂逻辑的输入和输出是符合约定的。你可以把规格看作是函数的类型签名（Type Signature），而业务逻辑是函数的具体实现。

5.2 技术集成中的具体问题

问题4：生成的TypeScript类型和我们的内部类型有冲突。避免在业务逻辑中直接使用生成的“API DTO”类型。应该建立一层映射（Mapping）。例如，生成的类型叫CreateTodoRequest，你的领域模型可能叫Todo。在Controller层，将CreateTodoRequest转换为Todo实体，再传递给Service层。这样，领域层与API层解耦，当API规格变更时，只需调整映射层即可。

问题5：契约测试依赖外部服务（如数据库），运行慢或不稳定。契约测试应该尽可能独立和快速。这意味着：

• 使用内存数据库：在运行契约测试时，使用SQLite或一个临时的、隔离的测试数据库实例。
• Mock外部依赖：对于邮件服务、支付网关等外部HTTP API，使用像Nock、MSW这样的库进行拦截和Mock。
• 测试数据管理：每个测试用例都应该独立地准备和清理数据，避免测试间的相互影响。可以使用事务回滚或每个测试前清空数据库的策略。

问题6：规格文件变得很大，难以阅读和评审。

• 拆分文件：利用$ref将paths和components/schemas拆分到独立的yaml文件中，主文件只做引用。
• 建立目录规范：例如：

  spec/ ├── openapi.yaml # 主文件，包含info, servers, 和全局$ref ├── paths/ │ ├── todos.yaml # /todos 相关路径 │ └── users.yaml # /users 相关路径 └── components/ ├── schemas.yaml # 所有数据模型 ├── parameters.yaml # 公共参数 └── responses.yaml # 公共响应

• 使用可视化工具：在CI中自动生成并发布Swagger UI文档。评审API变更时，直接查看交互式文档比看YAML文件直观得多。

5.3 团队协作与文化构建

问题7：如何让团队其他成员（特别是习惯vibe coding的）接受这种改变？不要强行命令。最好的方式是展示价值。组织一次小范围的工作坊：选择一个大家都很熟悉的、简单的功能（比如用户登录），分别用“传统vibe coding方式”和“spec-driven方式”实现一遍。对比两者在接口定义清晰度、前后端并行开发效率、自文档化、以及后续修改一个字段类型所需的工作量和风险。让数据说话。可以先在一个新的、非核心的微服务中试点，积累成功案例。

问题8：如何保证规格文件的更新不被遗漏？将规格文件的检查自动化并融入流程：

• Git Hooks：设置pre-commit钩子，运行spec-kit validate，如果验证失败则禁止提交。
• CI门禁：如前所述，在CI流水线中设置强制验证步骤。
• Pull Request模板：在PR模板中增加一项检查清单：“是否已更新openapi.yaml及相关文档？”。
• 责任归属：明确约定，修改API接口的人，负责首先更新规格文件。这应该成为团队的一条铁律。

从“感觉编程”到“规格驱动开发”，本质上是从一种依赖个人即时灵感与运气的手工艺模式，转向一种依赖精确定义、自动化验证和团队共识的工程化模式。spec-kit这样的工具，正是这场变革的催化剂和助推器。它并没有消灭创造力，而是将创造力引导到了更值得投入的地方——设计更优雅、更健壮的系统契约，以及实现更复杂、更核心的业务价值。对于追求软件质量、团队效率和长期可维护性的开发者与团队来说，拥抱这种范式，或许正是下一个十年的必修课。