# Spec Mint TDD：为AI编程助手引入严格的测试驱动开发流程

> 一个面向AI编程工具的TDD工作流框架，通过强制红绿重构循环、TEST-IMPL任务对交替执行和完整的TDD日志审计，让AI生成的代码具备可验证的质量保证。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-03T07:45:51.000Z
- 最近活动: 2026-06-03T07:54:55.375Z
- 热度: 163.8
- 关键词: TDD, 测试驱动开发, AI编程, Claude Code, Cursor, 软件工程, 测试自动化, 代码质量, Spec Mint, 开发工作流
- 页面链接: https://www.zingnex.cn/forum/thread/spec-mint-tdd-ai
- Canonical: https://www.zingnex.cn/forum/thread/spec-mint-tdd-ai
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**: ngvoicu
- **来源平台**: GitHub
- **原始标题**: specmint-tdd: TDD-first spec workflow for AI coding agents
- **原始链接**: https://github.com/ngvoicu/specmint-tdd
- **发布时间**: 2026年6月3日

---

## 引言：AI编程的测试困境

随着Claude Code、Cursor、Windsurf等AI编程助手的普及，开发者编写代码的方式正在发生根本性变化。但一个核心问题始终存在：AI生成的代码如何确保质量？

现有的"计划模式"（Plan Mode）虽然让AI在编码前进行思考，但这些计划往往是临时的、不可恢复的，更重要的是——它们不强制测试纪律。你无法知道AI是否遵循了测试优先的原则，也无法验证红绿重构循环是否被正确执行。

Spec Mint TDD项目正是为解决这一问题而生。它将传统软件工程中的TDD（测试驱动开发）理念引入AI编程工作流，通过严格的流程约束和完整的审计日志，让AI编程也能产出可验证的高质量代码。

---

## 核心设计理念

### 严格的红绿重构循环

Spec Mint TDD强制执行经典的TDD三阶段循环：

1. **红阶段（Red）**：先编写测试，运行并确认测试失败
2. **绿阶段（Green）**：编写最小实现代码使测试通过
3. **重构阶段（Refactor）**：优化代码结构，确保测试仍然通过

每个阶段的状态都会被记录到TDD日志中，形成完整的审计轨迹。这意味着你可以随时检查AI是否真正遵循了TDD原则，而不是简单地声称自己遵循了。

### TEST-IMPL任务对

项目创新性地引入了任务对的概念。每个功能实现都被拆分为两个紧密耦合的任务：

- **TEST任务**：编写测试代码，验证预期行为
- **IMPL任务**：编写实现代码，满足前述测试

这种交替执行的模式确保了"测试优先"不是一句空话。例如，一个OAuth登录功能的开发流程可能是：

```
[TEST-AUTH-01] 编写JWT生成与验证的测试
[IMPL-AUTH-02] 实现认证中间件（满足TEST-AUTH-01）
[TEST-AUTH-03] 编写用户模型CRUD测试
[IMPL-AUTH-04] 创建Prisma用户模型（满足TEST-AUTH-03）
```

---

## Forge工作流：从需求到实现

Spec Mint TDD定义了一套完整的"锻造"（Forge）工作流，将模糊的需求转化为可执行的计划：

### 深度研究阶段

AI首先进行全面的代码库扫描，读取10-20个实际文件而非仅仅是文件名。同时结合网络搜索、Context7库文档、跨技能研究（如前端设计、数据库技能）以及现有测试基础设施分析（测试框架、模拟模式、测试容器等）。所有研究成果保存到`.specs/<id>/research-01.md`。

### 访谈阶段

基于研究发现，AI提出针对性的问题而非泛泛而谈。例如："我在src/middleware/中看到你在使用Express中间件模式X，认证中间件是否应该遵循相同的模式？"

### 迭代深化

研究-访谈循环会进行多轮，直到每个任务都可以被具体描述，不存在"搞清楚X"这样的模糊任务。

### 规范生成

最终输出一份全面的SPEC.md文档，包含：

- 架构图表（ASCII或Mermaid）
- 测试架构（框架选择、隔离策略、覆盖率目标、测试命令、反模式）
- 库对比表格
- 功能阶段划分与TEST-IMPL任务对
- TDD日志
- 决策日志
- 恢复上下文

---

## SPEC.md文件结构

规范以纯Markdown格式存储在项目根目录的`.specs/`文件夹中，带有YAML前置元数据：

```yaml
---
id: user-auth-system
title: User Auth System
status: active
created: 2026-02-10
updated: 2026-02-11
priority: high
tags: [auth, security, backend]
---
```

### 测试架构部分

SPEC.md中包含专门的测试架构章节，定义：

| 工具 | 选择 | 版本 | 用途 |
|------|------|------|------|
| 测试框架 | Vitest | 3.0.4 | 单元和集成测试运行器 |
| 模拟库 | MSW | 2.7.0 | 外部API的HTTP模拟 |
| 数据库测试 | Testcontainers | 10.18.0 | 集成测试使用真实PostgreSQL |
| 覆盖率 | v8 (Vitest) | 内置 | 行和分支覆盖率 |

### 隔离策略

| 层级 | 方法 | 服务 |
|------|------|------|
| 领域逻辑 | 不模拟；纯函数 | 无 |
| 服务层 | 模拟端口/接口 | OAuth提供商 |
| 数据访问 | Testcontainers | PostgreSQL |
| HTTP客户端 | MSW | Google、GitHub OAuth API |

### TDD日志示例

| 任务 | 红阶段 | 绿阶段 | 重构 |
|------|--------|--------|------|
| [TEST-AUTH-01] | `Expected: valid JWT, Received: undefined` (3失败) | — | — |
| [IMPL-AUTH-02] | — | `3通过` | 提取中间件配置到常量 |
| [TEST-AUTH-03] | `relation "users" does not exist` (4失败) | — | — |
| [IMPL-AUTH-04] | — | `7通过` | — |

---

## 恢复上下文：断点续传

SPEC.md中的Resume Context章节记录了当前执行状态，使得开发会话可以被中断和恢复：

```markdown
## Resume Context
> 已完成Google OAuth循环（TEST-07红，IMPL-08绿+重构）。
> 接下来开始GitHub OAuth回调测试。
>
> 上个周期：[IMPL-AUTH-08] 绿 — 8/8通过，重构了OAuth配置
> 当前：[TEST-AUTH-09] 编写GitHub OAuth测试
> TDD阶段：红（即将编写测试、运行、确认失败）
> 上次测试运行：`npx vitest run tests/auth/` 14:32，8通过/0失败
>
> 下一步：在`tests/auth/oauth/github.test.ts`中编写GitHub OAuth回调测试。
> 使用`tests/auth/oauth/google.test.ts`中相同的模式。
```

这种设计让AI编程助手具备了"记忆"，开发者可以在不同时间、不同会话中继续同一个功能的开发。

---

## 决策日志：可追溯的设计演进

每个重要决策都被记录在决策日志中，包含日期、决策内容和理由：

| 日期 | 决策 | 理由 |
|------|------|------|
| 2026-02-10 | JWT替代Session | 无状态，适合微服务扩展 |
| 2026-02-10 | 刷新令牌轮换 | 限制被盗令牌的损害范围 |
| 2026-02-10 | Vitest替代Jest | 更快；原生ESM；项目已用Vite |
| 2026-02-11 | MSW替代nock | 网络层拦截；浏览器和Node通用 |

这不仅提供了审计线索，也帮助团队成员理解代码为何如此设计。

---

## 兼容性与部署

Spec Mint TDD设计为通用技能，兼容多种AI编程工具：

- Claude Code
- Codex CLI
- Cursor
- Windsurf
- Cline
- Gemini CLI
- 任何能够读取文件的AI编码工具

安装方式也很简单：作为通用技能（universal skill）部署到项目或全局配置中即可。

---

## 总结：让AI编程更工程化

Spec Mint TDD代表了一种趋势：AI编程工具正在从"智能代码补全"向"工程化开发流程"演进。它不是说AI不能生成正确的代码，而是说我们需要可验证、可审计、可恢复的方式来确保代码质量。

通过强制TDD纪律、记录完整日志、支持断点续传，Spec Mint TDD让AI编程助手更像是一个遵循软件工程最佳实践的团队成员，而不是一个随时可能产生技术债务的黑盒。