AI时代xDD的正确打开方式

背景

如果你在软件行业待过几年，大概率听过不止一次："我们要推 TDD"、"我们要落地 DDD"、"我们要写好 BDD"。然后呢？大多数团队试了一阵子，最后都不了了之。文档没人看，测试跟不上，模型图画完就过期。

本文尝试把 xDD 的来龙去脉讲清楚，主要包括：

它们是什么时候出现的？
为什么过去难落地？
AI 时代有什么不同？
最近火起来的 SDD 是什么？
SDD 有什么争议？
SDD 怎么和传统 xDD 结合落地？

从 TDD 到 SDD

传统 xDD

我们按时间线梳理一下这些方法论的出现：

TDD（Test-Driven Development，测试驱动开发） 的实践在极限编程（XP）社区酝酿多年后，于 2002 年由 Kent Beck 出版的《测试驱动开发》（Test-Driven Development: By Example）一书正式系统化。书中不仅以案例形式呈现了 TDD 的原则和方法，还详尽阐述了 TDD 的模式和最佳实践，为 TDD 技能向普通程序员的传播奠定了基础。核心思想是"先写测试，再写实现"，用测试来驱动设计，保证代码的正确性可回归。

DDD（Domain-Driven Design，领域驱动设计） 由 Eric Evans 在 2003 年出版的同名书籍《领域驱动设计：软件核心复杂性应对之道》中系统提出。核心思想是用统一语言对齐业务与技术，用边界上下文划分系统，让代码结构反映业务结构。

BDD（Behavior-Driven Development，行为驱动开发） 大约在 2006 年由 Dan North 提出，可以看作 TDD 的演进。它强调用"Given-When-Then"格式描述行为场景，让业务、开发、测试能对齐理解，解决的是"TDD 的测试应该测什么"的问题。

我们统称这些方法论为 xDD，它们都有一个共同的愿景：用某种形式化的"规范"来驱动开发，让软件构建更可控、更可验证。TDD 用测试做规范，BDD 用场景做规范，DDD 用领域模型做规范。

但现实是：这些方法论大多没有真正落地成功。团队试了一阵子，发现写规范太费时间、维护规范更费时间、反馈太慢看不到收益，最后又回到了"直接写代码"的老路。

SDD

SDD（Spec-Driven Development，规范/规格驱动开发） 是近年才提出的新概念，伴随着大模型和各种编程 Agent（如 Cursor、Copilot Workspace、Devin 等）的流行而兴起。

SDD 的 S 代表 Spec，可以翻译为"规范"或"规格"。它的核心主张是：先写好 Spec（规范/规格），再让 Agent 根据 Spec 生成代码。Spec 成为人与 Agent 之间的"契约"，目的是让 AI 生成的代码更符合人的意图。

为什么需要 SDD？因为直接让 AI 写代码，往往会出现"看起来对、其实错"或者"不是我想要的"的情况。Spec 的作用是：把你的意图结构化、无歧义地表达出来，降低 AI 理解偏差的概率。

但 SDD 一出来，质疑声就不少。很多人说：过去 TDD、BDD、DDD 都没落地成功，凭什么 SDD 就能成功？于是，大家很自然地把 SDD 也归入了 xDD 大家族——它们都是"用某种规范驱动开发"的思路，只是 Spec 的形式不同：TDD 的 Spec 是测试，BDD 的 Spec 是场景，DDD 的 Spec 是领域模型，SDD 的 Spec 是……嗯，就叫 Spec。

与此同时，社区里有三个问题被反复追问，直指 SDD 的要害：

拷问一：Spec 从哪里来？ SDD 说"先写 Spec，再让 Agent 生成代码"。问题是：过去我们就写不清楚需求文档，现在换个名字叫 Spec，就能写清楚了吗？Agent 的确能帮我们写得更快更全，但前提是"你自己脑子里有东西"。Agent 很神奇，但它不可能无中生有。如果你自己都说不清楚想要什么，Agent 写出来的只会是"看起来像那么回事"的幻觉。

拷问二：Spec 是不是代码的重复？谁是唯一可信信息源？ 文档写完了，代码改了，文档没跟上——几乎每个团队都经历过。久而久之，大家默认"看代码就行，文档别信"。SDD 的 Spec 如果只是另一份"会过期的文档"，它的命运不会比需求文档好到哪里去。

拷问三：开发者愿不愿意维护 Spec？ 说实话，看到一堆 Markdown 文件，大多数人是头疼的。写起来费时间，读起来找不到重点，改起来不知道改哪里。如果 Spec 不能被轻松阅读、轻松更新、自动校验，它就很难长期存在。

这三个拷问不仅针对 SDD，其实也是传统 xDD 面临的共同挑战。无论是 TDD 的测试、BDD 的场景，还是 DDD 的模型，都面临同样的问题：写 Spec 很贵（写场景、写测试、写模型，都需要时间和精力）；维护 Spec 更贵（代码改了 Spec 要跟着改，链路一旦断掉就很难接上）；反馈太慢（Spec 写完要等人评审，问题发现得越晚修复成本越高）。

所以，xDD 落地失败，往往不是方法不对，而是 成本结构不对。方法论的价值是真实的，但实现它们的成本太高，收益又不够直接，团队自然坚持不下去。

AI 时代 xDD 价值回归

Agent “编译”意图

在 AI 原生开发的语境下，我们常说 Agent 在“编译”意图。这里的“编译”不是把 Go 语言转成机器码，而是一个更广义的过程：将高层级、模糊的、非结构化的人类意图，逐步转换、细化，并固化为低层级、精确、结构化的机器可执行指令（代码与测试）。

想象一下你和 Agent 协作的场景：你先用自然语言描述想做什么，Agent 帮你整理成结构化的需求规范；你确认后，Agent 帮你生成技术方案；方案敲定后，Agent 帮你拆成一个个可独立验收的任务；最后，Agent 帮你写测试、写代码、跑通、重构。

这个过程就像一条“编译流水线”：

iagent-pipeline.png

这里有一个关键认知：Agent 不是传统编译器。传统编译器是确定性的：同样的 Go 代码，编译出来的机器码一定相同。但基于 Transformer 的大语言模型做不到这一点，它能做的是“降低不确定性”，而不是“消灭不确定性”。

这意味着我们仍然需要快速反馈、持续迭代、不断演进，没有人（AI 更不行）能一次性把设计做到完美。

演进式设计更加重要

敏捷开发最大的收益之一，就是演进式设计，这一点在 AI 时代不仅没有过时，反而更加重要。

evolutionary-design.png

演进式设计强调让设计尽量“保持简单”，对不确定的变化需要“延迟决策”，直到被某个方向上的“第一颗子弹”击中时，再通过应对变化的设计能力进行调整，并将新的设计及时重构进 Spec 中，让系统在该方向上保持弹性。

这一过程必须频繁发生、及时完成，而不能长期堆积。这依赖于自动化测试与持续反馈，才能让设计与代码的演进保持低成本、低风险。

为什么演进式设计在 AI 时代更重要？
因为 Agent 让“写代码”变快了，但“想清楚”依然需要时间。演进式设计的价值在于：承认我们一开始想不清楚，但可以通过快速反馈和持续迭代逐步逼近正确答案。Agent 加速了每一轮迭代，但不能替代迭代本身。

成本结构变化

AI 时代，xDD 的实现成本大幅降低：

表达变便宜了：过去写一份完整的需求文档可能要一两天，现在你把关键想法告诉 Agent，它能在几分钟内生成结构化的 Spec 草稿。你的角色从“写作者”转为“审阅者与校正者”。
验证变容易了：测试用例生成、边界条件补齐、回归覆盖检查、静态分析——这些过去高度依赖人工的工作，现在可以自动化或半自动化完成，反馈周期从“等人”变成“秒级”。
一致性可以工程化了：文档与代码的一致性不再依赖个人自觉，而可以被设计进流程中，通过自动检查、触发机制和告警系统持续维护。

xDD 的长期价值重新变得可持续

过去 xDD 的价值一直是真实存在的：

DDD 帮你对齐业务语言、划清边界；
BDD 帮你用场景对齐理解、减少争论；
TDD 帮你把正确性变成可回归的事实。

问题不在于“值不值”，而在于“做不做得起”。在很多团队中，xDD 不是被否定，而是被放弃。

Agent 改变了这一点，它帮你快速表达、快速验证、持续维护一致性。xDD 的内在价值并未改变，但实现这些价值的工程成本显著下降，使得它们的长期收益首次在大多数团队中变得可持续。

用一个不太恰当的比喻：过去 xDD 像是“有机蔬菜”，大家都知道好，但太贵了；现在 Agent 把价格打下来了，“有机蔬菜”终于能进入寻常百姓家。

xDD 如何与 Agent 协作

我们系统地讲讲每个 xDD 是什么、解决什么问题、怎么与 Agent 配合。

DDD：让软件复杂度逼近业务本质复杂度

DDD（领域驱动设计）不是为了画图好看，而是为了解决一个根本问题：业务逻辑散落在代码各处，没人能说清楚整体是什么样子。

DDD 的核心思想是"统一语言"：业务方说"订单"，开发也说"订单"，而且说的是同一个东西。听起来简单，但现实中经常出现：产品说"优惠"，开发理解成"折扣"，测试理解成"减免"，三个人说的其实不是一回事。

DDD 还强调"限界上下文"：谁负责什么，边界在哪里。订单服务负责订单，优惠服务负责优惠计算，它们之间通过明确的接口交互。边界清晰了，改动的影响范围就可控了。

与 Agent 结合的方式：你把业务描述告诉 Agent，让它生成候选的"领域词汇表"和"边界划分"，你负责拍板和纠偏。在写代码的时候，Agent 可以提醒你：这个命名是否违背了统一语言？这个逻辑是否跨越了上下文边界？

BDD：用"场景"代替"争论"

BDD（行为驱动开发）的核心是：用具体的例子对齐理解，而不是用抽象的描述争论。

当产品说"VIP 用户有额外优惠"，开发可能理解成"VIP 折扣更大"，测试可能理解成"VIP 有专属优惠券"。与其争论谁对，不如写几个具体场景：

场景 A：VIP 用户，满 200 减 30
场景 B：普通用户，满 200 减 20

场景一摆出来，理解就对齐了。BDD 的 Given-When-Then 格式，就是一种标准化的场景描述方式。

与 Agent 结合的方式：你把产品需求告诉 Agent，让它转换成一组 GWT 场景，并补齐你可能遗漏的反例和边界情况。评审的时候，重点看场景是否真实、是否覆盖关键边界，而不是纠结措辞是否漂亮。

TDD：把"正确性"变成可回归的事实

TDD（测试驱动开发）的核心是：先写测试，再写实现。

为什么要先写测试？因为测试是"可执行的验收标准"。你写完测试，就等于定义了"什么叫正确"。然后你写实现，让测试通过，就证明了实现是正确的。之后你重构代码，测试还是绿的，就证明重构没有破坏正确性。

在 AI 时代，TDD 的价值反而更大。为什么？因为 Agent 写代码很快，但也更容易出现"看起来对，其实错"的情况。测试是一个硬锚点：只要测试在，就不怕重构和迭代。

与 Agent 结合的方式（强烈推荐）：你给 Agent 轻量 Spec 和关键例子，Agent 先生成最小集合的测试（只满足当前故事，不做过度设计），再生成实现，跑测试，修到绿，最后重构。整个过程 Agent 都可以参与，你负责把关每一步的产出。

SDD：把一切串起来的"骨架"

SDD（规范驱动开发）不是一个新方法论，而是一种"把 xDD 产品化"的方式。它定义了从意图到代码的全流程，以及每个阶段应该产出什么、由谁负责、如何验证。

你可以把 SDD 理解成一个"骨架"，而 DDD、BDD、TDD 是"肌肉"：

xdd-agent.png

SDD 的价值是：让这些好东西不再依赖个人自觉，而是变成可重复、可验证的工程流程。

案例

前面讲了每个 xDD 是什么，现在用"订单优惠计算"案例把它们串起来，看看实际怎么协作。

场景描述

假设你在做一个电商系统，现在要实现"订单优惠计算"功能。业务规则是这样的：

普通用户：满 200 减 20
VIP 用户：满 200 减 30，且可以叠加一张优惠券
优惠券有多种类型：满减券、折扣券、无门槛券
最终优惠不能超过订单总额

听起来不复杂，但细节很多：VIP 怎么判断？优惠券怎么叠加？"满"是按什么金额算？边界情况有哪些？

第一步：用 DDD 对齐业务语言

在动手写代码之前，先和 Agent 对齐一下业务概念。你可以这样提问：

"我要做一个订单优惠计算功能，涉及用户等级、优惠券、满减规则。帮我梳理一下核心的领域概念和它们的关系。"

Agent 会帮你整理出一份"领域词汇表"：

订单（Order）：包含商品列表、原始金额、用户信息
用户等级（UserLevel）：普通用户、VIP 用户
优惠策略（DiscountStrategy）：满减、折扣、无门槛
优惠券（Coupon）：有类型、门槛、优惠金额/折扣率、有效期
优惠结果（DiscountResult）：最终优惠金额、优惠明细

这一步的价值是什么？是让所有人（包括你、Agent、未来的维护者）对"订单"、"优惠券"、"优惠策略"这些词有统一的理解。你不用画复杂的 UML 图，一份简单的词汇表就够了。

Agent 在这里的作用：帮你快速生成候选词汇表，你负责拍板和纠偏。比如 Agent 可能会把"折扣"和"满减"混在一起，你需要明确区分。

第二步：用 BDD 写验收场景

概念对齐后，下一步是把业务规则变成具体的验收场景。你可以让 Agent 帮你生成一组 Given-When-Then 场景：

场景 1：普通用户满减

Given：用户是普通用户，订单金额 250 元
When：计算优惠
Then：优惠 20 元，实付 230 元

场景 2：VIP 用户满减

Given：用户是 VIP，订单金额 250 元
When：计算优惠
Then：优惠 30 元，实付 220 元

场景 3：VIP 用户叠加优惠券

Given：用户是 VIP，订单金额 250 元，有一张满 200 减 15 的优惠券
When：计算优惠
Then：优惠 45 元（30+15），实付 205 元

场景 4：优惠不能超过订单总额

Given：用户是 VIP，订单金额 100 元，有一张无门槛减 50 的优惠券
When：计算优惠
Then：VIP 满减不生效（未满 200），优惠 50 元，实付 50 元

场景 5：边界情况——刚好满足门槛

Given：用户是普通用户，订单金额 200 元
When：计算优惠
Then：优惠 20 元，实付 180 元

这些场景就是你的"验收标准"。评审的时候，产品、开发、测试看的是同一份场景，争论的焦点是"场景对不对"，而不是"代码写得对不对"。

Agent 在这里的作用：帮你根据业务描述生成场景草稿，并主动补齐你可能遗漏的边界情况（比如"刚好满足门槛"、"优惠超过订单总额"），你负责确认哪些场景是真实需要的。

第三步：用 TDD 把场景变成测试

场景确认后，下一步是把它们变成可执行的测试。这就是 TDD 的核心：先写测试，再写实现。

你可以让 Agent 根据 BDD 场景生成测试代码。以 Go + GoConvey 为例：

func TestOrderDiscount(t *testing.T) {
    Convey("订单优惠计算", t, func() {
        Convey("普通用户满减", func() {
            Convey("given 用户是普通用户，订单金额250元", func() {
                user := User{Level: Normal}
                order := Order{Amount: 250, User: user}
                
                Convey("when 计算优惠", func() {
                    result := CalculateDiscount(order, nil)
                    
                    Convey("then 优惠20元，实付230元", func() {
                        So(result.DiscountAmount, ShouldEqual, 20)
                        So(result.FinalAmount, ShouldEqual, 230)
                    })
                })
            })
        })
        
        Convey("VIP用户叠加优惠券", func() {
            Convey("given 用户是VIP，订单金额250元，有满200减15的优惠券", func() {
                user := User{Level: VIP}
                order := Order{Amount: 250, User: user}
                coupon := Coupon{Type: FullMinus, Threshold: 200, Amount: 15}
                
                Convey("when 计算优惠", func() {
                    result := CalculateDiscount(order, &coupon)
                    
                    Convey("then 优惠45元（30+15），实付205元", func() {
                        So(result.DiscountAmount, ShouldEqual, 45)
                        So(result.FinalAmount, ShouldEqual, 205)
                    })
                })
            })
        })
        
        // ... 其他场景
    })
}

这些测试一开始是红的（因为还没有实现）。然后让 Agent 根据测试生成实现代码，跑测试，修到绿，再重构。

Agent 在这里的作用：先生成测试，再生成实现，跑测试，修 bug，重构——整个 TDD 循环 Agent 都可以参与。你的角色是把关：测试覆盖了关键场景吗？实现逻辑正确吗？重构后测试还是绿的吗？

第四步：用 SDD 把全流程串起来

上面三步（DDD 对齐概念、BDD 写场景、TDD 写测试和实现），其实就是 SDD 的核心流程。SDD 做的事情是：把这些步骤产品化、流程化、可重复。

一个典型的 SDD 流程是这样的：

输入：你提供业务目标、约束、3～10 个关键例子
产出 1：Agent 帮你生成轻量 Spec（含领域词汇、GWT 场景、验收标准）
产出 2：Agent 帮你生成技术方案（关键设计决策、取舍）
产出 3：Agent 帮你拆成任务列表（按依赖排序、可独立验收）
产出 4：Agent 执行 TDD 循环（测试→实现→跑绿→重构→再跑绿）
持续治理：自动检查 Spec-测试-代码的一致性

整个过程你会发现：你的精力从"写代码"转移到了"给例子、做决策、把关质量"。这就是 AI 时代开发重心的"反转"：过去我们以代码为中心，把大量精力用在实现上；现在实现成本下降，开发者更应该把精力投入到业务建模、架构设计和工程实践上。

落地指南

回应三个灵魂拷问

问题 1：Spec 从哪里来？

答案是：Spec 来自你的脑子，Agent 帮你表达。

Spec 不是凭空写出来的，它应该来自三类输入：

业务目标：要解决什么问题、成功指标是什么
约束条件：技术栈、性能、安全、合规、成本、时间
例子与边界：典型流程、反例、异常、边界值

你不用写长篇大论，只需要提供关键的例子和约束，Agent 会帮你组织成结构化的 Spec，并主动追问缺失项，你负责纠偏和拍板。

问题 2：Spec 是不是代码的重复？

答案是：让代码是权威事实，Spec 是意图与验收的入口。

Spec 应该尽量短、尽量结构化，指向测试与契约，而不是重复实现细节。分工非常明确：

Spec 写"为什么做、做什么、怎么验收"
代码写"怎么做"
测试把验收变成机器可验证的事实

这样 Spec 就不会和代码重复，因为它们说的是不同层次的事情。

问题 3：不想维护 Spec 怎么办？

答案是：把维护变成"顺手"，并尽量自动化。

让 Spec 可维护的关键不是"提高自觉"，而是"降低摩擦"：

轻量：一页纸说清目标、场景、验收标准，不要写成百科全书
模块化：按领域/能力拆分，避免巨型文档
强链接：每条验收标准能定位到测试/接口契约/指标
流程化：变更时自动检查 Spec 是否需要更新，由谁确认，如何告警

把维护变成流程的一部分，而不是额外的负担。

落地闭环

SDD 的落地需要形成一个闭环：

feedback-loop.png

这个闭环的关键是：每一步产出都是可验证的。

Spec 可验证：场景是否真实？是否覆盖关键边界？
测试可验证：测试是否通过？覆盖率是否达标？
代码可验证：是否符合契约？是否通过静态分析？
结果可验证：指标是否达成？用户反馈如何？

反馈会回流到 Spec，驱动下一轮演进。这样 Spec 就不再是"写完就过期的文档"，而是一个能持续迭代、持续对齐的工程资产。

常见误区

误区 1：把 Spec 写成百科全书。 有人觉得 Spec 越详细越好，结果写了几十页，没人看，也没人维护。正确做法是：Spec 只写"意图 + 验收"，其余让测试与代码承载。

误区 2：让 Agent 自己补需求。 Agent 可以帮你追问、补齐候选项，但关键例子必须由你提供。如果你自己都说不清楚，Agent 补出来的就是"幻觉式需求"——看起来很合理，但不是你真正想要的。

误区 3：一次性就能设计完美。 没有人能一次把设计做到完美，AI 也不行。正确做法是：用最小可验证闭环推进，快速反馈，持续演进。先做一个最简单的版本，验证方向对不对，再迭代。

误区 4：没有把一致性维护工程化。 如果更新 Spec 全靠自觉，它一定会过期。正确做法是：把"更新 Spec"写进流程和检查里，让维护变成默认动作，而不是额外负担。

必须正视的两个深层问题

除了上面的误区，SDD 还面临两个更根本的质疑，值得认真讨论。

问题一：SDD 会不会变成"双重负担"——既要维护 Spec，又要维护代码？

这是很多人对 SDD 最大的担忧：如果 Spec 和代码都要维护，那不是比以前更累了吗？

担忧是合理的。如果 Spec 写得很重、很细、和代码高度重叠，那确实会变成双重负担。改一次需求，Spec 要改一遍，代码要改一遍，测试还要改一遍——这种模式谁都坚持不下去。

但问题的根源不是"SDD 不该用"，而是"Spec 的粒度和定位没搞对"。

正确的做法是：Spec 只负责"意图层"，代码负责"实现层"，它们是不同层次的东西，不应该重复。

具体来说：

Spec 写什么：业务目标、关键约束、验收场景（Given-When-Then）、边界条件。一页纸能说清的事，不要写成十页。
Spec 不写什么：具体的实现细节、数据结构、算法逻辑，这些是代码的事。
谁是权威：代码和测试是权威事实（Single Source of Truth），Spec 是"入口"和"索引"，指向测试和契约，而不是复述它们。

如果 Spec 足够轻量、足够聚焦，它的维护成本就不会高。而且在 AI 时代，Spec 的更新可以让 Agent 辅助：你改了需求，让 Agent 帮你检查 Spec 哪些地方需要同步更新，而不是自己一行行找。

当然，如果你发现维护 Spec 的成本已经超过了它带来的收益，那说明 Spec 写得太重了，或者你的场景根本不需要 SDD。SDD 不是银弹，不是所有项目都适合。

问题二：对于遗留系统，SDD 是否合适？

这是另一个很现实的问题。大多数团队不是从零开始写代码，而是在维护一个已经存在多年的遗留系统。这种情况下，SDD 还能用吗？

坦白说，SDD 对遗留系统的适用性是有限的。

原因有几个：

第一，遗留系统通常没有 Spec。 SDD 的前提是"先有 Spec，再有代码"。但遗留系统的代码早就存在了，而且往往没有配套的规范文档。你要用 SDD，就得先"反构"出 Spec——这本身就是一项巨大的工作，而且很可能不划算。

第二，遗留系统的"真相"在代码里，不在文档里。 多年的修修补补，业务逻辑已经沉淀在代码的各种 if-else 里，很多行为连原作者都说不清楚"为什么要这么写"。这时候你写一份 Spec，很可能和代码实际行为对不上——而代码才是真正在跑的东西。

第三，遗留系统的改动风险高，SDD 的"编译"模式不太适用。 SDD 的理想流程是"Spec→Agent 生成代码→测试验证"。但遗留系统的改动往往是"小心翼翼地改一行，跑一遍回归，祈祷不出问题"。让 Agent 大刀阔斧地重新生成代码，风险太大。

那遗留系统应该怎么办？

比较务实的做法是：不追求全面 SDD，而是在"增量"和"局部"上应用 xDD 的思想。

新功能用 SDD：遗留系统里要加新功能，可以对这个新功能写 Spec、走 SDD 流程，但不去动老代码。
重构时用 TDD 兜底：如果要重构遗留代码，先补测试（哪怕是"特征测试"，只验证现有行为），再让 Agent 辅助重构，测试保障不破坏现有行为。
逐步提取"核心领域"：如果遗留系统里有一块核心业务逻辑特别重要、改动频繁，可以考虑把它单独提取出来，用 DDD 建模、用 BDD 写场景、用 TDD 保障，形成一个"干净的内核"，和遗留代码通过接口隔离。
文档补全靠 Agent 辅助：可以让 Agent 阅读遗留代码，帮你生成"当前行为的描述"（不是 Spec，而是"现状说明"），作为后续改造的参考。

所以对于遗留系统：不要强推全面 SDD，而是在增量和局部上借鉴 xDD 的思想，逐步改善。

总结

回到开头的问题：xDD 在 AI 时代还有没有价值？

答案是：不仅有价值，而且价值更大。

xDD 解决的问题——把意图变成可验证的结果，从来都没有消失。DDD 帮你对齐业务语言，BDD 帮你用场景对齐理解，TDD 帮你把正确性变成可回归的事实，这些价值都是实打实的存在。

过去 xDD 难落地，是因为成本太高、反馈太慢、维护太痛。今天有了 Agent 这个"更强的大脑"，"把意图编译成代码"的成本大幅下降。xDD 的价值没有变，但实现它们的成本变低了——这就是 AI 时代 xDD 更有价值的根本原因。

SDD 做的事情，是把 xDD 装进一个端到端的流水线里，让它们不再依赖个人自觉，而是变成可重复、可验证的工程流程。Agent 在每个阶段做加速与校验，你负责给例子、做决策、把关质量。

如果本文的内容你只能记住一句话，那请记住：用 DDD 对齐业务语言，用 BDD 把验收写成场景，用 TDD 把验收变成机器事实，用 SDD 把全流程产品化，然后再让 Agent 在每个阶段做加速与校验。

这就是 AI 时代 xDD 的正确打开方式。

AI时代xDD的正确打开方式