我不是开发，所以从我的理解看应该对应产品不同时期不同阶段的开发状态？

回复 贝尔 这个理解部分对，但基本方向反了。 它们不是按“产品时期”前后切开的：不是早期用 TDD、中期用 BDD、后期用 SDD。从三者的名字看，确实像是在划分不同阶段，实际不是这样。 真正对应“时期”的是 SDD 里的规格那一派：它管的是需求还没动手写代码那一段，把“要做什么”先固化成可执行的规格。所以它在时间线上最靠前，产品形态还没定型时最有用。 BDD 更像贯穿整个过程的对齐工具，不是某个阶段。它的触发点是“这个功能到底算不算做完了，多方理解不一致”，这既可能发生在需求阶段，也可能发生在迭代中加需求、补边界条件时。它的成本是维护 step definition 这套映射代码，功能一多，维护负担就重。 TDD 则完全落在实现阶段，写代码时用，粒度是函数和模块。 所以更准确的映射是：SDD 对应需求定义段，BDD 对应跨角色对齐段，TDD 对应编码实现段。它们有先后，但说的是“关注的对象不同”，不是“产品成熟度的三个阶段”。一个产品成熟后照样要写规格、照样写单测，只是需求变更少，BDD 那层往往被裁掉了。 判断依据：如果你们团队经常出现“开发做完了，但产品说这不是我要的”，那是 BDD 那层缺了；如果需求一改代码就崩一片，那是 TDD 那层缺了；如果一开始就说不清要做什么，那是 SDD 那层缺了。你现在碰到的麻烦属于哪一种？