一、背景与现状
在当前快速迭代的软件工程实践中，开发效率与系统可靠性之间的矛盾日益突出。传统开发流程面临诸多挑战，如需求模糊、接口契约不清、测试覆盖不足等，导致返工、线上缺陷频发以及团队协作成本上升。与此同时，人工智能技术迅速发展，尤其是大语言模型（LLM）在代码理解与生成方面的突破，为软件开发带来了全新可能。
二、核心痛点与 Spec Kit 解决方案
Spec Kit 专注解决以下核心痛点：
-
从模糊指令到可验证契约AI生成代码时常出现“看似正确但无法运行”的问题。Spec Kit通过结构化流程，杜绝即兴且不靠谱的编码。
-
构建结构化开发流程缺乏清晰步骤导致后期大量修改。Spec Kit明确“Specify（规范）→ Plan（计划）→ Tasks（任务）”流程，确保开发有序可控。
-
确保代码正确性与可维护性强制推行测试驱动开发等最佳实践，保证AI生成的代码不仅可用，更加可靠、可维护。
类比说明：
Spec Kit 就像建筑领域的“施工蓝图”，要求开发者在动工前，先定义清晰、可验证的规范，后续开发、测试与AI辅助均严格依规执行，大幅提升交付效率与系统可靠性。
三、Cursor简介
Cursor由 Anysphere Inc. 开发，是一款基于 VS Code 构建的AI原生代码编辑器，深度集成大型语言模型（如 GPT-4、Claude 等），支持：对话式编程、自动补全、代码生成、错误修复、代码解释。
Cursor 是面向未来的AI编程环境，不仅是写代码的工具，更是“与AI结对编程的伙伴”。
四、Spec Kit 详细介绍
1. 工具简介
GitHubSpec Kit（Specification-Driven Development Toolkit）是 GitHub 官方推出的规范驱动开发开源工具链。它以“需求规范”为起点，深度集成 AI 编程助手（如 Copilot、Claude、Cursor 等），实现从自然语言描述到可运行代码的自动化生成与迭代。
通过结构化“斜杠命令”（/command），Spec Kit 引导开发者和AI协同工作，将产品想法逐步细化为项目原则、功能规范、技术方案、任务列表，并最终自动执行实现。
2. 核心思想
-
规范先行：编码前先写出清晰、可执行或可验证的规范；
-
规范即契约：规范描述“应该做什么”，而非“如何做”；
-
规范可验证：通过工具自动检查规范是否被实现满足（如测试、模型检测、类型系统等）。
3. 主要目标
- 提升软件设计的清晰度和一致性
- 减少沟通成本，对齐产品、设计与工程团队
- 利用 AI 自动生成高质量、可测试的代码骨架
- 构建可追溯、可验证、可演进的系统架构
五、安装与环境配置
1. 安装 uv 工具
Spec Kit 提供命令行工具（CLI），推荐通过uv安装。
- Windows
C:\Users\DELL>powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
添加 PATH 安装过程中会显示文件路径，可手动添加或重启 shell。 验证安装
C:\Users\DELL>uv --version
#命令结果
uv 0.9.10 (44f5a14f4 2025-11-17)
定位安装路径
C:\Users\DELL>where uv
#命令结果
C:\Users\DELL\.local\bin\uv.exe
- Linux
curl -fsSL https://astral.sh/uv/install.deb.sh | sudo bash
sudo apt install uv
或
curl -LsSf https://astral.sh/uv/install.sh | sh
- mac
brew install uv
2. 安装 Spec Kit
环境要求
- Linux/macOS（或 Windows 上的 WSL2）
- 支持的 AI 编码代理
- Python 3.11+ 和 uv
安装步骤
- 官方推荐：一次性安装
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME> --ai <AI_MODEL>
- 持久安装
git clone https://github.com/github/spec-kit.git cd spec-kit uv sync
- 支持的模型/开发工具
copilot, claude, gemini, cursor-agent, qwen, opencode, codex, windsurf, kilocode, auggie, codebuddy, roo, q, amp, shai
- 示例命令
1.使用 cursor：
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai cursor-agent
2.使用 claude：
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai claude
3.初始化过程中选择脚本类型-Choose script type
Windows 下选 PowerShell，Enter 后开始项目初始化。 4.成功提示:Project ready.5.生成的项目目录结构
my-project/
├── .cursor/commands/ # cursor下相关指令，如plan、specify、tasks
│ ├── speckit.constitution.md
│ ├── speckit.plan.md
│ ├── speckit.specify.md
│ ├── speckit.tasks.md
├── ./specify/memory/
│ ├── constitution.md # 项目宪法和原则
├── ./specify/
│ └── scripts/ # 自动化脚本
│ └── templates/ # 模板文件
└── cursor.md # AI会话记录
六、Spec-Kit常用命令介绍
使用Spec Kit的基本流程遵循严格的阶段划分：宪法制定 → 规范定义 → 技术规划 → 任务分解 → 实现执行。每个阶段都有明确的输入输出和质量标准。
1./constitution——定规则：确立项目“宪法”
作用：定义项目的基础原则与质量底线，为后续所有决策提供约束依据。
类比：就像国家的宪法，规定“什么能做、什么不能做”。
没有/constitution，AI 可能生成“能跑但不符合团队标准”的代码。有了它，AI 就知道：不仅要实现功能，还要代码规范。
输出：
- memory/constitution.md：项目宪法文档
- 治理清单和合规要求
- 质量标准和验收准则
2./specify——写需求：聚焦“做什么”，而非“怎么做”
作用：用用户视角描述功能目标，明确行为契约，避免过早陷入技术细节。
关键原则：说清“效果” + “交互” + “边界”。
/specify产出的是可验证的规范，后续可直接用于生成测试用例、UI 原型或 API 合约，确保开发始终对齐业务目标。
输出：
- specs/001-feature-name/spec.md：功能规范文档
- 用户故事和验收标准
- UI设计和交互流程
3./plan+/tasks——选技术 & 拆任务：从蓝图到施工清单
这两个命令紧密衔接，构成技术落地路径：
- /plan：选择技术栈与架构方案 “后端使用XX技术，前端使用XX技术，数据库采用XX；架构方案等”
/plan输出：
- /tasks：将计划拆解为原子级开发任务 ✅特点：
自动生成任务列表
这一步把模糊的需求，转化为可分配、可追踪、可验证的具体行动项，极大降低协作成本。
/tasks输出：
-
specs/001-feature-name/tasks.md：详细任务清单
-
任务依赖关系和优先级
-
预估工作量和资源分配
-
4./implement——自动实现：按图施工，交付可靠代码
作用：AI 根据前面定义的规则（/constitution）+ 需求（/specify）+ 计划（/plan）+ 任务（/tasks），自动生成完整、合规的代码。
✅特点： 代码符合/constitution中的质量标准功能严格满足/specify描述的行为技术选型遵循/plan的约束按/tasks顺序逐项实现，支持增量生成 不再是“随机生成一段代码”，而是在规范约束下的确定性交付——这才是 AI 编程从“玩具”走向“生产力工具”的关键。
输出：
-
完整的可执行应用程序代码
-
测试套件和文档
-
部署配置和运维脚本
5. 整体流程图
/constitution → /specify → /plan → /tasks → /implement
↓ ↓ ↓ ↓ ↓
定规矩 写需求 选技术 拆任务 自动实现
（质量基线） （用户契约） （技术锚点）（执行路径）（可靠交付）
这四个命令共同构建了一个“规范先行、AI 执行”的现代开发闭环：
- 人负责定义 What 和 Why（规则、需求、标准）
- AI 负责处理 How（技术选型、任务拆解、代码生成）
它让开发者从“码农”回归“设计师”角色，同时确保 AI 输出可控、可信、可维护——这正是 Spec Kit 与 Cursor Agent 结合的核心价值。
七、案例
1. 步骤一：定义宪法
使用 /constitution 命令定义项目宪法文档，示例：
# 电商商城项目宪法文档（Constitution）
> **项目名称**：E-Commerce Platform (PC Web)
> **版本**：1.0
> **生效日期**：2025-11-21
> **适用范围**：所有微服务模块、前端应用、基础设施及自动化流程
---
## 一、架构原则
1. **微服务边界清晰**
- 每个业务域（如商品、订单、购物车、用户）独立为一个微服务，禁止跨服务直接访问数据库。
- 服务间通信仅通过 **RESTful API（同步）** 或 **RabbitMQ（异步事件）**。
2. **前后端分离**
- 前端（Vue3 + Element Plus）通过调用后端 BFF（Backend For Frontend）或聚合 API 获取数据。
- 禁止前端直连微服务，需通过网关（Spring Cloud Gateway）统一入口。
3. **数据一致性**
- 跨服务操作（如下单减库存）必须通过 **Saga 模式** 或 **可靠消息最终一致性** 实现，禁止使用强分布式事务（如 Seata），除非经架构委员会特批。
---
## 二、技术栈规范
| 层级 | 技术选型 | 版本要求 | 约束说明 |
|------|--------|--------|--------|
| 后端语言 | Java | ≥17 | 使用 Records、Pattern Matching 等现代特性 |
| 微服务框架 | Spring Boot + Spring Cloud | 2023.x+ | 统一注册中心（Nacos）、配置中心 |
| 数据库 | MySQL | 8.0+ | 主从读写分离，每个服务独享 schema |
| 搜索引擎 | Elasticsearch | 8.x | 商品信息实时同步，支持关键词+属性过滤 |
| 消息队列 | RabbitMQ | 3.12+ | 用于订单创建、库存扣减、通知等异步解耦 |
| 前端框架 | Vue 3 | ≥3.4 | Composition API + TypeScript |
| UI 组件库 | Element Plus | ≥2.7 | 禁止自定义主题覆盖核心样式 |
| 构建工具 | Vite | ≥5.0 | 开启生产环境压缩与 Tree-shaking |
---
## 三、代码质量标准
### 3.1 编码规范
- **后端**：遵循 [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html)，使用 Spotless 自动格式化。
- **前端**：TypeScript 严格模式（`strict: true`），禁用 `any` 类型，组件命名采用 PascalCase。
### 3.2 测试要求
- 单元测试覆盖率 ≥ 70%（Jacoco 统计）
- 核心链路（如下单、支付）必须包含集成测试（使用 Testcontainers 模拟 MySQL/ES/RabbitMQ）
- 前端关键路径需包含：
- Vitest 单元测试（组件逻辑）
- Cypress E2E 测试（用户主流程）
### 3.3 API 设计
- 所有 RESTful 接口遵循 [OpenAPI 3.0](https://swagger.io/specification/) 规范
- 接口必须包含明确的请求/响应 Schema，并通过 Swagger UI 可视化
- 错误码统一格式：`{ "code": "ORDER_NOT_FOUND", "message": "订单不存在" }`
---
## 四、安全与运维
### 4.1 安全基线
- 所有用户输入必须校验（后端使用 Hibernate Validator + 自定义注解）
- 敏感操作（如修改密码、下单）需记录操作日志并支持审计追溯
- JWT Token 有效期 ≤ 2 小时，Refresh Token 存入 Redis 并设置滑动过期策略
### 4.2 可观测性
- 集成 Micrometer + Prometheus + Grafana 监控系统指标（QPS、延迟、错误率）
- 关键链路（搜索、下单、支付）接入 Sleuth + Zipkin 实现全链路追踪
- 应用日志统一采集至 ELK，格式为结构化 JSON
### 4.3 部署要求
- 所有服务容器化（Docker），提供标准 `Dockerfile`
- 支持 Docker Compose 本地开发部署，生产环境运行于 Kubernetes
- 每个微服务拥有独立 CI/CD 流水线（推荐 GitHub Actions）
---
## 五、AI 辅助开发约束（Cursor Agent 使用规范）
1. **生成代码必须遵守本宪法**
- AI 不得绕过输入校验、不得硬编码配置、不得使用已废弃或非标 API。
2. **规范优先于实现**
- 在执行 `/implement` 前，必须先完成 `/specify`（功能契约）和 `/plan`（技术方案）。
3. **可解释性要求**
- 所有 AI 生成的复杂逻辑（如状态机、并发控制）必须附带注释，说明设计意图、边界条件及异常处理策略。
4. **禁止“黑盒生成”**
- 任何由 AI 生成的代码必须经过人工审查，确保符合本宪法第 1–4 章要求。
---
> ✅ **宪法效力说明**
> 本文件是项目所有开发活动的强制性依据。任何偏离本宪法的行为（包括 AI 自动生成内容）必须提交 RFC（Request for Change）并经架构委员会评审通过后方可实施。
使用建议：
- 将此文件命名为CONSTITUTION.md，置于项目根目录；
- 在.cursor/rules或团队 Wiki 中引用该文件，作为 Cursor Agent 的上下文约束；
- 在 CI 流程中可加入“宪法合规检查”
2. 步骤二：定义规范
使用 /specify 命令定义功能需求，示例：
# 电商商城功能行为规范（/specify）
> **说明**：本规范描述系统在用户交互下的**可观测行为**，不包含技术实现细节。所有实现必须满足以下契约。
---
## 1. 首页（Homepage）
### 1.1 核心目标
用户打开网站首页后，应能快速了解平台主营商品、热门活动，并便捷进入搜索或分类浏览。
### 1.2 行为规范
| 场景 | 用户动作 | 系统响应 |
|------|--------|--------|
| **加载首页** | 用户访问 `/` | - 页面在 1.5 秒内完成首屏渲染<br>- 显示顶部导航栏（含 Logo、搜索框、购物车图标、用户登录状态）<br>- 展示轮播广告区（最多 5 张，自动轮播，3s/张） |
| **查看推荐商品** | 无操作（自动展示） | - “热销商品”区域展示 8 个商品卡片<br>- 每个卡片包含：商品主图、名称（≤20 字）、价格、促销标签（如“限时折扣”） |
| **点击商品卡片** | 点击任意商品卡片 | 跳转至该商品的详情页（URL: `/product/{id}`） |
| **点击购物车图标** | 点击顶部导航栏购物车图标 | 若购物车为空：显示“购物车为空”提示；<br>若非空：跳转至 `/cart` 页面 |
| **未登录状态** | 用户未登录 | 导航栏显示“登录 / 注册”按钮；<br>不显示订单、个人中心等私有入口 |
### 1.3 边界条件
- 轮播图数量为 0 时，广告区隐藏
- 商品名称超长时自动截断并显示“…”
- 首页不支持 SEO 动态渲染以外的 SSR（服务端渲染）要求，但需保证 CSR 下核心内容可访问
---
## 2. 产品搜索页（Product Search）
### 2.1 核心目标
用户可通过关键词或筛选条件快速找到目标商品，结果按相关性排序，支持分页浏览。
### 2.2 行为规范
| 场景 | 用户动作 | 系统响应 |
|------|--------|--------|
| **发起搜索** | 在首页搜索框输入“手机”并回车 | 跳转至 `/search?q=手机`，页面加载搜索结果 |
| **查看搜索结果** | 进入搜索页 | - 显示搜索关键词（如“手机”）<br>- 左侧显示筛选面板（品牌、价格区间、评分）<br>- 右侧展示商品列表（默认按“综合排序”）<br>- 每页最多 20 个商品 |
| **应用筛选** | 勾选“品牌：Apple”，设置价格区间 5000-8000 | URL 更新为 `/search?q=手机&brand=Apple&minPrice=5000&maxPrice=8000`<br>商品列表实时刷新，仅显示符合条件项 |
| **切换排序** | 点击“价格从低到高” | 商品列表按价格升序重新排列，URL 更新 `sort=price_asc` |
| **翻页** | 点击第 2 页 | 加载第 21–40 条结果，页面滚动至顶部，URL 更新 `page=2` |
| **无结果** | 搜索“不存在的商品” | 显示提示：“未找到与‘xxx’相关的商品”，并推荐热门搜索词 |
### 2.3 数据与性能要求
- 搜索响应时间 ≤ 800ms（95 分位）
- 支持关键词模糊匹配（如“苹国”应匹配“苹果”）
- 价格筛选区间动态根据当前结果集计算（非全局固定）
- 商品卡片内容与首页一致（图、名、价、标签）
---
## 3. 下单流程（Checkout Flow）
> **流程范围**：从购物车 → 结算 → 提交订单
### 3.1 核心目标
用户能清晰、安全地完成从选择商品到生成订单的全过程，关键步骤不可逆且信息透明。
### 3.2 行为规范
#### 步骤 1：进入结算页
| 用户动作 | 系统响应 |
|--------|--------|
| 在购物车页点击“去结算” | 跳转至 `/checkout`<br>- 自动加载收货地址（默认最近使用）<br>- 显示所选商品清单（不可编辑）<br>- 显示商品总价、运费（默认包邮）、订单总金额 |
#### 步骤 2：管理收货地址
| 用户动作 | 系统响应 |
|--------|--------|
| 点击“新增地址” | 弹出表单，必填字段：收货人、手机号、省市区、详细地址<br>提交后地址列表更新，新地址设为默认 |
| 选择已有地址 | 订单预览区立即更新收货信息 |
#### 步骤 3：提交订单
| 用户动作 | 系统响应 |
|--------|--------|
| 点击“提交订单” | - 发起创建订单请求<br>- 成功后跳转至 `/order/success?orderId=xxx`<br>- 购物车中已下单商品自动移除 |
| 提交时库存不足 | 弹出提示：“部分商品库存不足，请返回购物车调整”，停留在结算页 |
| 提交时网络失败 | 提示“网络异常，请重试”，保留已填信息，不跳转 |
### 3.3 业务规则（强制约束）
- 同一商品在结算时若库存 < 购买数量，整单失败（不允许部分成功）
- 订单总金额 = Σ(商品单价 × 数量) + 运费（当前阶段运费固定为 0）
- 用户必须登录才能进入 `/checkout`
- 订单创建后，系统必须通过 RabbitMQ 发送“订单创建”事件供后续服务消费
### 3.4 安全与体验
- 结算页 URL 不可直接访问（需来自购物车或有效来源）
- 敏感操作（提交订单）需防重复点击（按钮置灰 3 秒）
- 成功页显示订单号、预计送达时间、返回首页/查看订单按钮
---
这份规范文档可直接用于：
- 在Cursor中作为上下文，执行/plan（技术方案设计）和/tasks（任务拆解）
- 自动生成前端组件接口定义（TypeScript interface）
- 编写后端 API 契约（OpenAPI spec）
- 构建E2E 测试用例（Cypress / Playwright）
3. 步骤三：技术规划
使用 /plan 命令制定技术方案，示例：
# 下单流程微服务技术方案（/plan）
> **模块名称**：Order Checkout Flow
> **关联规范**：[SPECIFICATIONS.md - 下单流程](#3-下单流程checkout-flow)
> **适用服务**：`cart-service`, `order-service`, `product-service`, `user-service`
> **架构风格**：事件驱动微服务 + 最终一致性
---
## 1. 整体架构设计
### 1.1 服务职责划分
| 服务 | 职责 | 关键接口 |
|------|------|--------|
| **`cart-service`** | 管理用户购物车状态 | `GET /carts/{userId}/selected`（获取待结算商品） |
| **`product-service`** | 提供商品信息与库存校验 | `POST /products/validate-stock`（批量校验库存） |
| **`user-service`** | 管理用户地址与基本信息 | `GET /users/{userId}/addresses`（获取收货地址） |
| **`order-service`** | **核心**：创建订单、管理状态、发布事件 | `POST /orders`（创建订单） |
### 1.2 数据流（用户点击“提交订单”后）
sequenceDiagram
participant Frontend as 前端 (Vue3)
participant OrderService as order-service
participant CartService as cart-service
participant ProductService as product-service
participant UserService as user-service
participant RabbitMQ
Frontend->>OrderService: POST /orders {userId, addressId, items[]}
OrderService->>UserService: GET /users/{userId}/addresses/{addressId}
OrderService->>CartService: GET /carts/{userId}/selected
OrderService->>ProductService: POST /products/validate-stock [{skuId, quantity}]
alt 库存充足 & 数据有效
ProductService-->>OrderService: 200 OK
OrderService->>OrderService: 1. 创建订单<br/>2. 扣减本地库存快照<br/>3. 清空购物车（发消息）
OrderService->>RabbitMQ: publish "order.created" event
OrderService-->>Frontend: 201 Created {orderId}
RabbitMQ->>CartService: consume "order.created" → clear cart
RabbitMQ->>NotificationService: send order confirmation
else 库存不足或数据无效
ProductService-->>OrderService: 400 Bad Request {errors}
OrderService-->>Frontend: 400 {code: "INSUFFICIENT_STOCK", ...}
end
## 2. 技术选型与实现策略
### 2.1 后端（Java 微服务）
### 2.2 前端（Vue3 + Element Plus）
### 2.3 安全与可观测性
## 3. 关键接口契约（OpenAPI 片段）
### 3.1 创建订单（POST /orders）
略。
此/plan文档可直接用于：
- 在Cursor中执行/tasks，自动拆解为开发任务（如“实现 order-service 的订单创建接口”）
- 生成Spring Boot 项目骨架（含 Entity、Controller、DTO）
- 编写集成测试用例（使用 Testcontainers 启动 MySQL + RabbitMQ）
4. 步骤四：任务分解
使用 /tasks 命令拆解任务，示例：
# 下单流程开发任务列表（/tasks）
> **目标**：实现从购物车结算到订单创建的完整流程
> **依据**：
> - [CONSTITUTION.md](CONSTITUTION.md)
> - [SPECIFICATIONS.md#3-下单流程](SPECIFICATIONS.md)
> - [PLAN_order-checkout.md](PLAN_order-checkout.md)
---
## 一、后端任务（Java 微服务）
### 1. `order-service` 核心开发
| 任务 ID | 任务描述 | 验收标准 |
|--------|--------|--------|
| ORD-01 | 创建 `order-service` Spring Boot 项目骨架 | 包含 `pom.xml`（Spring Web, Data JPA, Cloud Stream, OpenAPI） |
| ORD-02 | 设计并实现订单领域模型 | 实体：`Order`, `OrderItem`, `OrderAddress`；使用 JPA 注解映射 MySQL 表 |
| ORD-03 | 实现 `POST /orders` 接口（含 DTO 校验） | 支持请求体校验（Hibernate Validator），返回 400 错误码 |
| ORD-04 | 集成 `user-service` 获取地址信息 | 通过 FeignClient 调用 `GET /users/{userId}/addresses/{id}` |
| ORD-05 | 集成 `cart-service` 获取选中商品 | 调用 `GET /carts/{userId}/selected`，转换为订单项 |
| ORD-06 | 实现库存校验逻辑 | 调用 `product-service` 的 `POST /products/validate-stock`，处理 4xx 响应 |
| ORD-07 | 实现订单创建与数据库持久化 | 使用 JPA Repository 保存订单，生成唯一 `orderId`（雪花 ID） |
| ORD-08 | 发布 `order.created` 事件到 RabbitMQ | 使用 Spring Cloud Stream，消息包含 `orderId`, `userId`, `items[]` |
| ORD-09 | 实现幂等性支持（X-Request-ID） | 相同请求 ID 重复提交返回相同结果，不重复创建订单 |
| ORD-10 | 添加 OpenAPI 3.0 文档注解 | 访问 `/v3/api-docs/order` 可查看接口定义 |
### 2. 其他服务适配
| 任务 ID | 任务描述 | 验收标准 |
|--------|--------|--------|
| CART-01 | `cart-service` 监听 `order.created` 事件 | 消费消息后清空对应用户的选中商品 |
| PROD-01 | `product-service` 实现库存校验接口 | 支持批量 SKU 校验，返回不足详情（非简单 true/false） |
| USER-01 | `user-service` 确保地址接口返回快照数据 | 地址信息变更不影响已创建订单 |
---
## 二、前端任务（Vue3 + Element Plus）
### 1. 页面与组件开发
| 任务 ID | 任务描述 | 验收标准 |
|--------|--------|--------|
| FE-01 | 创建 `/checkout` 路由与页面组件 | 使用 Vue Router，布局含地址区、商品清单、金额汇总 |
| FE-02 | 实现地址管理模块 | - 展示地址列表<br>- “新增地址”弹窗表单（含手机号正则校验）<br>- 默认地址高亮 |
| FE-03 | 实现商品清单展示 | 从 API 获取选中商品，显示图、名、价、数量（不可编辑） |
| FE-04 | 实现金额计算逻辑 | 实时计算总价 = Σ(单价×数量)，运费=0，总金额=总价 |
| FE-05 | 实现“提交订单”按钮逻辑 | - 点击后置灰 3 秒<br>- 携带 JWT Token 和 X-Request-ID<br>- 处理 400 错误并友好提示 |
### 2. 状态管理与工具
| 任务 ID | 任务描述 | 验收标准 |
|--------|--------|--------|
| FE-06 | 创建 Pinia store：`useCheckoutStore` | 管理地址选择、商品列表、加载状态 |
| FE-07 | 封装 API 服务：`checkoutApi.createOrder()` | 使用 Axios，自动注入 Token 和 Request ID |
| FE-08 | 实现路由守卫 | 未登录用户访问 `/checkout` 重定向至 `/login?redirect=/checkout` |
| FE-09 | 创建成功页 `/order/success` | 显示订单号、返回首页/查看订单按钮 |
---
## 三、测试与质量保障
| 任务 ID | 任务描述 | 验收标准 |
|--------|--------|--------|
| TEST-01 | 为 `order-service` 编写单元测试 | 覆盖库存不足、地址无效、正常创建等场景（JUnit 5 + Mockito） |
| TEST-02 | 编写集成测试（Testcontainers） | 启动 MySQL + RabbitMQ 容器，验证端到端流程 |
| TEST-03 | 前端组件单元测试（Vitest） | 测试地址表单校验、金额计算逻辑 |
| TEST-04 | E2E 测试（Cypress） | 覆盖主路径：登录 → 加购 → 结算 → 提交订单 → 成功页 |
| TEST-05 | 性能与安全扫描 | 使用 OWASP ZAP 扫描 API，JMeter 压测订单创建接口（≥100 TPS） |
---
## 四、DevOps 与部署
| 任务 ID | 任务描述 | 验收标准 |
|--------|--------|--------|
| OPS-01 | 为 `order-service` 编写 Dockerfile | 基于 openjdk:17-slim，暴露 8080 端口 |
| OPS-02 | 配置 GitHub Actions CI | 代码推送后自动运行单元测试 + 构建镜像 |
| OPS-03 | 更新 Kubernetes Helm Chart | 添加 `order-service` 部署配置（含 RabbitMQ 连接信息） |
---
5. 步骤五：任务执行
使用/implement执行任务，自动执行所有任务并生成代码。此时，你可以去喝茶了。开发任务交给AI数字程序员干活了。
经过实践证明，只要不出现网络问题和token限制，Cursor可按小时做为基本单位，持续编码。
八、总结
Spec Kit 代表了软件开发范式的根本性变革：它将规范从静态的指导文档，转变为动态、可执行的核心开发资产。通过规范驱动开发（SDD），开发者得以聚焦于业务逻辑与用户体验，而将具体的实现细节交由 AI 编码助手在规范约束下自动生成，从而实现高效、可靠且可验证的软件交付。
开发任务交给AI来干，你可以去喝茶、喝咖啡去了。打场球回来，代码写好了，也调试好了。干得不好，你还可以骂他！
