1. SSD 是什么？
SSD = Spec-Driven Development，规格驱动开发。
核心思想是：
先把需求、边界、数据结构、接口、状态流转、异常规则写清楚，再让 AI 根据规格去写代码。
也就是说，不是一上来就让 AI：
“帮我实现支付渠道配置功能。”
而是先明确：
功能：支付渠道配置管理
实体：
- pay_channel_config
- pay_app_config
要求：
- 支持支付宝、微信、银联
- 参数配置必须落 MySQL
- 不允许 mock
- 接口返回结构保持统一
- 删除时需要校验是否被应用配置引用
- 修改配置需要记录操作日志
- 敏感字段需要加密存储
然后再让 AI 根据这个规格拆分：
1. 数据库表设计
2. Entity / DTO / VO
3. Mapper / Service / Controller
4. 参数校验
5. 幂等与事务
6. 单元测试 / 集成测试
SSD 提高 AI Coding 效率的原因
AI 最怕的是需求模糊。SSD 可以让 AI 有明确边界：
| 问题 | 没有 SSD | 有 SSD |
|---|---|---|
| 需求理解 | AI 容易猜 | 按规格实现 |
| 数据库设计 | 容易乱建表 | 字段、约束清楚 |
| 接口设计 | 返回格式可能不一致 | 请求/响应固定 |
| 业务规则 | 容易漏 | 明确校验规则 |
| 返工次数 | 多 | 少 |
| 代码质量 | 取决于提示词 | 取决于规格质量 |
一句话：
SSD 让 AI 知道“到底要做什么”。
2. TDD 是什么？
TDD = Test-Driven Development，测试驱动开发。
核心流程是：
先写测试 → 测试失败 → 写代码实现 → 测试通过 → 重构优化
经典流程叫：
Red → Green → Refactor
含义是：
| 阶段 | 含义 |
|---|---|
| Red | 先写测试，测试必然失败 |
| Green | 写最小代码让测试通过 |
| Refactor | 保持测试通过的前提下优化代码 |
例如你要实现一个支付订单创建逻辑，先写测试：
@Test
void createOrder_shouldRejectDuplicateOrderNo() {
CreateOrderRequest request = new CreateOrderRequest();
request.setOrderNo("ORDER_10001");
request.setAmount(new BigDecimal("100.00"));
orderService.createOrder(request);
assertThrows(BusinessException.class, () -> {
orderService.createOrder(request);
});
}
然后 AI 根据这个测试去实现：
@Transactional(rollbackFor = Exception.class)
public Order createOrder(CreateOrderRequest request) {
boolean exists = orderMapper.existsByOrderNo(request.getOrderNo());
if (exists) {
throw new BusinessException("订单号已存在");
}
Order order = new Order();
order.setOrderNo(request.getOrderNo());
order.setAmount(request.getAmount());
order.setStatus(OrderStatus.WAIT_PAY);
orderMapper.insert(order);
return order;
}
TDD 提高 AI Coding 效率的原因
AI 写代码快，但它不一定知道代码是否真的对。TDD 给 AI 一个自动验证机制：
| 问题 | 没有 TDD | 有 TDD |
|---|---|---|
| 代码是否正确 | 人肉检查 | 测试自动验证 |
| 改代码是否破坏旧逻辑 | 很难发现 | 回归测试发现 |
| AI 是否漏业务规则 | 容易漏 | 测试用例约束 |
| 重构是否安全 | 不敢改 | 测试兜底 |
| 多轮 AI 修改 | 越改越乱 | 测试持续校验 |
一句话：
TDD 让 AI 知道“代码写得对不对”。
3. SSD 和 TDD 的区别
| 对比项 | SSD | TDD |
|---|---|---|
| 中文名 | 规格驱动开发 | 测试驱动开发 |
| 关注点 | 需求、设计、边界 | 测试、验证、正确性 |
| 解决问题 | AI 不知道要做什么 | AI 不知道写得对不对 |
| 产物 | 需求规格、接口文档、数据库设计、任务拆分 | 单元测试、集成测试、回归测试 |
| 适合阶段 | 开发前 | 开发中 |
| 对 AI 的价值 | 降低幻觉、减少乱写 | 自动验收、减少返工 |
4. 它们如何配合提升 AI Coding？
最佳实践不是单独用，而是组合使用：
SSD 负责定义目标
TDD 负责验证结果
AI 负责快速实现
推荐流程是：
1. 先写 Spec
↓
2. 根据 Spec 拆分任务
↓
3. 根据 Spec 生成测试用例
↓
4. 让 AI 写实现代码
↓
5. 运行测试
↓
6. AI 根据失败日志修复
↓
7. 测试通过后重构
可以理解为：
SSD：告诉 AI 要建什么房子
TDD：检查房子有没有塌
AI Coding：负责快速施工
5. 对 AI Coding 最有效的写法
不推荐这样问 AI
帮我写一个支付系统。
这个太模糊，AI 很容易瞎编。
推荐用 SSD + TDD 这样问
你是高级 Java 后端工程师。
基于以下规格实现支付渠道配置功能：
技术栈：
- Spring Boot 3
- MyBatis-Plus
- MySQL 8
- Redis
- RabbitMQ
功能要求：
1. 新增支付渠道配置
2. 修改支付渠道配置
3. 查询支付渠道配置
4. 删除支付渠道配置
5. 删除前必须判断是否有关联支付应用
6. 敏感参数需要加密存储
7. 所有操作需要记录审计日志
8. 不允许 mock
9. 数据库结构必须真实落地
请先输出：
1. 数据库设计
2. 接口设计
3. 测试用例清单
4. 再开始生成代码
然后第二步让 AI 写测试：
根据以上规格，先生成 Service 层单元测试和接口集成测试。
测试必须覆盖：
1. 正常新增
2. 重复渠道编码
3. 删除被应用引用的渠道
4. 修改敏感参数
5. 查询分页
6. 参数校验失败
最后再让 AI 实现代码。
6. 最适合你的 Java 项目工作流
你经常要求 不 mock、真实业务、MySQL 落地、代码结构清晰，所以推荐这个工作流：
需求输入
↓
SSD：规格文档
↓
DDD/模块拆分
↓
数据库 DDL
↓
API 契约
↓
TDD：测试用例
↓
AI 生成代码
↓
运行测试
↓
根据错误日志修复
↓
代码审查
尤其适合这些场景：
| 场景 | 推荐程度 |
|---|---|
| 支付系统 | 极高 |
| 订单系统 | 极高 |
| 数据迁移系统 | 极高 |
| RAG 知识库系统 | 高 |
| 导出任务系统 | 高 |
| 普通 CRUD | 中等 |
| 一次性脚本 | 低 |
7. 最核心的一句话
SSD 提升的是“需求准确率”，TDD 提升的是“代码正确率”。
在 AI Coding 里，它们的价值是：
SSD 防止 AI 瞎写
TDD 防止 AI 写错
SSD + TDD = 可控、可验证、可迭代的 AI 编程流程
对于企业级后端项目，尤其是支付、订单、数据迁移这种不能乱来的系统，SSD + TDD 是非常适合 AI Coding 的组合。
