1. SSD 是什么？

SSD，全称是 Spec-Driven Development，即规格驱动开发。 它的核心思想很简单：与其让AI一上来就“猜”你要什么，不如先把规矩定清楚了再动手。这就好比盖房子，你总得先给施工队一张设计图纸，而不是说“你给我盖个能住人的东西”。 所以，正确的姿势不是直接对AI说“帮我写个支付模块”，而是先把规格定义清楚： - **功能**：支付渠道配置管理 - **实体**：`pay_channel_config`, `pay_app_config` - **要求**： - 支持支付宝、微信、银联 - 参数配置必须落MySQL - 不允许使用Mock对象 - 接口返回结构保持统一 - 删除时需要校验是否被应用配置引用 - 修改配置需要记录操作日志 - 敏感字段需要加密存储 有了这份明确的规格说明书，AI在执行时才能按部就班。接下来，它才能准确地完成：数据库表设计、Entity / DTO / VO、Mapper / Service / Controller、参数校验、幂等与事务，以及单元测试 / 集成测试这一系列任务。 **SSD 提高 AI Coding 效率的原因** AI最怕的就是需求模糊。一份清晰的规格，等于给AI画了一个明确的边界，让它能在框定的范围内精准发挥。 | 问题 | 没有 SSD | 有 SSD | | :--- | :--- | :--- | | 需求理解 | AI 容易凭空猜测 | 按规格精准实现 | | 数据库设计 | 容易乱建字段和表 | 字段、约束一清二楚 | | 接口设计 | 返回格式可能五花八门 | 请求/响应结构固定 | | 业务规则 | 容易遗漏关键逻辑 | 校验规则明确写入 | | 返工次数 | 多次，浪费时间 | 极少，一步到位 | | 代码质量 | 完全取决于提示词 | 取决于规格本身的质量 | 一句话总结：**规格越清晰，AI犯错越少。**

2. TDD 是什么？

TDD，Test-Driven Development，测试驱动开发。 这套流程大家应该不陌生：**先写测试 → 测试失败 → 写代码实现 → 测试通过 → 重构优化**。经典的“红-绿-重构”循环。 - **Red**：先写一个注定会失败的测试用例。 - **Green**：编写最精简的代码，让测试通过。 - **Refactor**：在测试的保护下，放心地优化代码结构。 举个例子，假设你要实现一个支付订单创建逻辑。传统做法是先写代码，再人肉检查。但TDD的玩法是，先写一个测试，验证“重复订单号应该被拒绝”这个规则： ```ja va @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根据这个测试去写出对应的实现代码。AI会看到这个测试，明白它必须实现“检查订单号是否存在”的逻辑，否则测试就会失败。这就形成了一个自动的验证闭环。 **TDD 提高 AI Coding 效率的原因** AI写代码很快，但它自己不知道代码写得对不对。TDD就像安排了一个不知疲倦的“代码检验员”，随时随地进行自动化验证。 | 问题 | 没有 TDD | 有 TDD | | :--- | :--- | :--- | | 代码是否正确 | 全靠人肉检查，易出错 | 测试自动验证，结果明确 | | 改代码是否破坏旧逻辑 | 很难发现，风险极大 | 回归测试秒级发现 | | AI 是否漏掉了业务规则 | 容易遗漏边界条件 | 测试用例形成约束 | | 重构是否安全 | 不敢轻易动代码 | 测试兜底，放手重构 | | 多轮 AI 修改 | 越改越乱，逻辑可能错乱 | 测试持续校验，保证质量 | 一句话总结：**测试即文档，测试即契约，它能让AI的产出变得可验证。**

3. SSD 和 TDD 的区别

这两个概念各有侧重，放在一起看更清晰： | 对比项 | SSD | TDD | | :--- | :--- | :--- | | 中文名 | 规格驱动开发 | 测试驱动开发 | | 关注点 | 需求、设计、业务边界 | 测试、验证、代码正确性 | | 解决问题 | AI 不知道要做什么 | AI 不确定做得对不对 | | 产物 | 需求规格、接口文档、数据库设计、任务拆分 | 单元测试、集成测试、回归测试集 | | 适合阶段 | 代码开发前 | 代码开发中及重构时 | | 对 AI 的价值 | 降低幻觉、减少乱写 | 自动验收、减少返工 |

4. 它们如何配合提升 AI Coding？

SSD和TDD不是二选一的关系，而是王炸组合。正确的玩法是： - **SSD** 负责定义目标和边界。 - **TDD** 负责验证和结果。 - **AI** 则负责快速实现。 推荐的工程流程如下： 1. **先写 Spec**：把需求规格化，形成明确的文档。 2. **根据 Spec 拆分任务**：将大需求拆解成可独立实现的小功能点。 3. **根据 Spec 生成测试用例**：编写TDD需要的测试代码。 4. **让 AI 写实现代码**：AI根据Spec和测试用例，编写具体的业务逻辑。 5. **运行测试**：验证AI生成的代码是否正确。 6. **AI 根据失败日志修复**：如果测试失败，把错误日志喂给AI，让它自行修复。 7. **测试通过后重构**：在测试的保护下，持续优化代码结构。 这个流程可以通俗地理解为： - **SSD**：告诉 AI 要建什么风格的房子。 - **TDD**：用一套严密的验收标准，确保房子质量过关。 - **AI Coding**：它就是个任劳任怨、效率极高的施工队。

5. 对 AI Coding 最有效的写法

**不推荐这样问 AI：** “帮我写一个支付系统。” 这话太模糊，AI会陷入选择困难，很容易开始自由发挥，结果就是你想要的“幻觉”。 **推荐用 SSD + TDD 这样问 AI：** 首先，给出一个完整的上下文和规格，就像这样： “你是高级 Ja va 后端工程师。基于以下规格实现支付渠道配置功能： 技术栈：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 根据这些测试用例去实现核心代码。这一步一步下来，AI的产出质量会高很多。

6. 最适合你的 Ja va 项目工作流

很多朋友的项目要求很严格：不能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的工程化实践。