1. SDD（Spec-Driven Development）相对 TDD/BDD 的本质差异中规格是产品契约而非测试用例，如何驱动 AI 与人类协同实现？
问题
SDD（Spec-Driven Development，规格驱动开发）相对于 TDD（测试驱动开发）和 BDD（行为驱动开发）的本质差异是什么？如何理解"规格是产品契约而非测试用例"，并依靠这一契约驱动 AI 与人类协同实现？
考察点
- SDD 与 TDD/BDD 的定位差异：规格是"是什么"（契约），测试是"验证"（手段）
- 规格作为产品与技术之间的单一事实来源（Single Source of Truth）
- 规格如何同时约束 AI 与人类，形成协同实现
答案
TDD 的核心是"先写失败测试再写实现"，把测试当作可执行的需求规格；BDD 强调用 Given/When/Then 的通用语言描述行为，让测试同时承载业务与实现。而 SDD 把"规格（Spec）"提升为独立于代码与测试的产品契约：它描述系统"应该做什么、约束是什么、如何验收"，是产品、测试、实现的共同源头。关键差异在于，TDD/BDD 中规格被"揉进"测试代码里，而 SDD 中规格是一份独立、可评审、可版本化的文档（markdown 或类型化结构），测试只是从规格推导出的验证物。在 AI 时代，规格是给 LLM 的"精确 prompt"：人类把业务意图写成规格，AI 依据规格生成代码与测试，人类再按规格验收。这样"规格—实现—验证"三者闭环，既防止 AI 各说各话，也约束人类不偏离需求。
解析
本质区别是"先有契约还是先有测试"。TDD 中测试先行，但测试往往只覆盖"实现者的局部理解"；SDD 中规格先行，规格描述的是"产品意图"而非"代码行为"，因此更能防止 AI 生成"自洽但业务错误"的结果。规格是产品契约，意味着它同时约束需求方、实现方（人+AI）与验证方，是三方协同的锚点。
示例代码
# Spec: 订单取消（Order Cancellation）
## 输入
- orderId: 已存在且状态为 PAID 的订单
## 行为
- 将订单状态置为 CANCELLED，记录取消原因
- 若已支付则触发退款流程
## 约束
- 幂等：同一订单重复取消只生效一次
## 验收
- 取消后订单状态为 CANCELLED
- 退款流程被触发且仅触发一次