AI Coding工程化实践：SSD需求定义与TDD验证

2026-06-08阅读 0热度 0

1. SSD 是什么？

SSD，全称是 Spec-Driven Development，即规格驱动开发。它的核心思想很简单：与其让AI一上来就“猜”你要什么，不如先把规矩定清楚了再动手。这就好比盖房子，你总得先给施工队一张设计图纸，而不是说“你给我盖个能住人的东西”。所以，正确的姿势不是直接对AI说“帮我写个支付模块”，而是先把规格定义清楚： - **功能**：支付渠道配置管理 - **实体**：`pay_channel_config`, `pay_app_config` - **要求**： - 支持支付宝、微信、银联 - 参数配置必须落MySQL - 不允许使用Mock对象 - 接口返回结构保持统一 - 删除时需要校验是否被应用配置引用 - 修改配置需要记录操作日志 - 敏感字段需要加密存储

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 的区别

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 项目工作流

7. 最核心的一句话

归根结底，这两个方法论的价值在于： - **SSD** 提升的是“需求准确率”，它是“做什么”的保障。 - **TDD** 提升的是“代码正确率”，它是“做对了”的证明。在AI Coding的语境下，它们的意义是： - **SSD** 防止 AI 失之毫厘，谬以千里（瞎写）。 - **TDD** 防止 AI 代码里埋着定时冲击波（写错）。 - **SSD + TDD = 可控、可验证、可迭代的 AI 编程流程。** 对于那些不能出一丝差错的业务系统，比如支付、订单、数据迁移等，SSD + TDD的组合，确实是目前最适合AI Coding的工程化实践。