AI时代软件工程师必备的三大核心秩序工具：DDD、TDD、SDD

你已经组建了一支AI研发团队，接下来呢？这支团队应该在怎样的“秩序”下交付——交付什么、不能交付什么、由谁验收、按什么标准验收？这篇文章将专门探讨这些核心问题。

AI编码能力越强，团队的焦虑感反而越强——不是为AI焦虑，而是为自己焦虑。

想想看，AI写代码的速度肉眼可见地加快。三个月前还需要逐行引导，现在只需提交一份需求，它就能迅速生成一个完整模块。看着PR列表一路绿灯，你心里自然高兴，可过两天回头再看，发现某个角落它悄悄把领域实体混进了基础设施层；或者某个接口的命名风格跳出了团队约定，无人能懂；又或者文档与代码早已对不上，它按文档写、按代码写、按自己“觉得合理”的方式写，三套逻辑彼此矛盾。

问题不在于AI做得不够多，而在于秩序给得不够多。

AI并非不需要规则，恰恰相反，它比任何人类工程师都更需要规则——因为AI能放大所有好事，也能放大所有坏事。你给它一份乐谱，它能演奏出交响乐；不给乐谱，它只能即兴发挥。即兴发挥的代价，就是你看着它跑得飞快，结果架构却一天天陷入泥潭。

这篇文章就讲清楚“AI时代工程师该用哪三件秩序乐器”。DDD、TDD、SDD——三个老朋友，过去是加分项；今天在AI面前，它们集体变成了必选项。

不是教你DDD是什么（你早已掌握），也不是教你TDD红绿蓝如何循环（你早已熟悉），而是讲一件事：这三件乐器在AI时代如何重新组合，如何从“加分”变成“保命”。

更重要的是，我会揭示一个初版规划里遗漏的洞察——秩序不是锁死，秩序里要有留白。焊死的是边界，放开的是选择。这两层合起来，才是AI时代完整的秩序。

下面逐一拆解。

一、AI写代码越快，架构腐化越快——一个反直觉的现场

这个标题听起来有点反直觉——AI越强，交付效率越高，架构应该越干净才对？

现实往往并非如此。真实场景的剧本，常常是这样演的：

第一周，AI接入进来。PR哗哗地合并，每个PR都有测试，都有文档。你心里乐开花：“这不就是我想要的AI工程师吗？”

第三周，某个看似无关的PR改了User实体的字段命名——userName改成了name。它说“这样更符合英文习惯”。你皱了皱眉，但想着“反正有P1审查挡着”，就放行了。

第六周，另一个PR把OrderService的place()方法换了一个新名字submitOrder()——因为它“觉得读起来更通顺”。place()是和PaymentService.place()对齐的语义约定，这一改，下游调用方全乱了。

第三个月，你打开代码库，发现五个领域实体的字段命名风格各不相同，三个服务的方法签名对不上interface层的约定，文档里有两套“领域服务”的定义，其中一套是AI自己造的——DomainUserService，跟framework六模块分层里的domain.UserDomainService是两个完全不同的概念。

你回头看PR列表，三个月里没有任何一条P0红线被触发。每一条都是“看起来合理的小改动”。但合起来，架构已经悄悄腐化到了你想重构都不知从何下手的地步。

这不是AI太笨，而是秩序太弱。

AI没有“业务直觉”。它不知道这个项目的User是为SaaS多租户设计的，不知道place()是和支付链路语义对齐的，不知道framework六模块分层的硬规矩是“domain零Spring、common零框架”。它只看到代码里现有的命名风格有几种、PR历史里大家改过什么、上下文里你最近一次提的偏好是什么——它把“现在的样子”当成“应该的样子”。

更扎心的是，它不是在犯错，它是在学得过于认真。它在用最快的速度模仿你项目里的所有不规范，然后用同样的速度放大它们。

所以这个反直觉的结论得先接受——

过去你写代码慢，三件事不写也不会让整个项目崩；现在AI写代码快，不写就崩给你看。这不是AI的问题，是你给它的秩序边界没跟上它扩张的速度。

那到底需要什么样的秩序？下面三节把DDD、TDD、SDD三件乐器一个个拆开看。

二、失控的三个现场——根因不是AI太强，是秩序太弱

我们刚才说的“架构腐化”不是抽象的，是有具体场景的。过去一年FDE现场最常见的三种失控，看看哪一个最扎心。

第一个失控：AI凭印象写实体。

你跟它说“加一个Tenant实体吧”，它没问你这个Tenant落在哪个限界上下文里、有没有现成的聚合根、值对象要不要拆、是不是已经有TenantUser这个上下文。它就照着它“印象里”的Tenant——可能是某个开源项目里的，可能是别的语言里的——给你整出一个id + name + createTime三字段的贫血模型。

你打开一看：字段命名跟现有User不一致、缺租户成员关系、缺审计字段、连主键命名都没跟你项目的TenantId值对象对齐。你问它“为什么这么写”，它说“我参考了项目里其他实体的风格”——但它的“参考”是它从几百个文件里提炼的“平均”，不是项目真正的规范。

这不是AI的“业务理解”有问题，而是它没有业务边界感。它不知道“租户成员关系”是另一个限界上下文（tenant-center）的核心，不是当前实体的字段。这种判断，靠“模型更聪明”是解决不了的——你给它GPT-5、Claude 4.5、Qwen3-Max，它依然不知道你项目里“租户成员关系”该归谁。

第二个失控：AI跳过测试直接交付。

你给它一个“加个新接口”的任务，它吭哧吭哧写完controller、service、repository、dto，整整齐齐一坨。你打开PR一看——测试是空的。

你问它“测试呢”，它说“我跑了现有测试都通过，没破坏既有功能”。你再问“新接口的测试呢”，它说“这个比较简单，我就没专门写”。

简单还是不简单，不是它能判断的，而是人定的——覆盖率门槛、P0/P1/P2分级、Given-When-Then结构，是人写进项目规矩里的。它没看到这些，所以它按它“觉得合理”的尺度交付。

更糟的是，它跳过测试不是偷懒，而是它没有验收意识。它不知道“测试是AI干完活自己查‘有没有干对’的护栏”——这件事必须由人把它焊死在规矩里。

第三个失控：AI把文档当摆设。

你跟它说“顺便把文档更新一下”。它给你更新了一版，看着挺像样——把readme.md里的API列表补全了，把AGENTS.md里的检查项顺手扩了几条。

可你打开readme.md对照代码一看：readme里写“控制器必须显式声明@RequestMapping”，但它刚写的UserController偏偏没声明。你打开AGENTS.md对照一下：上面写着“DomainEvent子类必须@NoArgsConstructor + 字段非final”，但它刚写的UserDeletedEvent给字段加了final修饰。

你问它“为什么不遵守文档”，它说“我看了文档，但这个改动是临时的，等会儿就改回来”——它把文档当成“目标描述”，不是“硬约束”。

这三件事表面上看是AI的三个毛病，根子上是同一件事——你给它的秩序太软。秩序没有边界感，AI就凭印象；秩序没有验收门槛，AI就跳过测试；秩序没有硬约束力，AI就当摆设。

接下来三节我们就把DDD、TDD、SDD三件乐器一件一件拿出来，看它们怎么把秩序从“软”补到“硬”。

三、DDD：业务边界 = AI边界——AI没有业务直觉，只有“按规矩干”

先把DDD这件乐器摆到桌上。

你可能会说：“DDD我熟啊，限界上下文、聚合根、值对象、领域事件、通用语言……这套我十年前就看过。” 是的，你看得很熟。但AI不熟。

AI没有业务直觉。

你看到“租户成员关系”四个字，脑子里立刻会跳出“这是tenant-center的领域，不是user-center的字段；如果user-center要查租户成员，应该走事件同步或Feign，不能直接连表”——这一整套判断是多年业务建模经验堆出来的。

AI没有这堆经验。它看到的是字符、命名、文件位置、上下文里出现的提示。它能写出语法正确的代码，但它写不出“业务上的对”。

所以DDD在AI时代的价值，不是教你写更漂亮的领域代码，而是给AI一张它能照着走的“业务地图”。

这张地图怎么画？关键是三个东西——限界上下文、聚合根、值对象。

限界上下文（Bounded Context）——业务语言的边界。在auth-center、user-center、tenant-center这三个仓里，每个仓都有自己的“业务语言”。auth-center说accessToken、refreshToken、authCode；user-center说user、account、accessKey、tenantRole；tenant-center说tenant、tenantUser、tenantRole。

AI在auth-center里看到的是认证这一套语言，在user-center里看到的是用户这一套语言。如果你不切限界上下文，它会把auth-center里的“用户”和user-center里的“用户”当成一个东西——然后给你写出一个跨上下文的UserAuthService，把认证逻辑塞进用户表里。

焊在规矩里就是一句话：业务边界 = AI边界。AI在哪个限界上下文里干活，它就只能说那个上下文的语言；出了边界，停下来问人。

聚合根——一致性的边界。在认证这个领域里，核心的东西就三样：访问令牌（AccessToken）、授权码（AuthCode）、访问密钥（AccessSecret）；在用户这个领域里，核心的东西有用户（User）、账号（Account）、访问密钥（AccessKey）、角色（Role）、租户成员关系（TenantUser）；在租户这个领域里，核心的是租户本身（Tenant）和租户里的成员（TenantUser）。这些“领域里最关键的那几个东西”就是聚合根——AI改任何一个聚合根时，只能在这个聚合根内部改，不能顺手把别的东西也改了。

AI改AccessToken.create()，它只能在这个聚合根内部改，不能顺手把AuthCode也改了——那是另一个聚合根的一致性问题。让它守住这个边界，靠的是分层依赖：domain层只能依赖common层，绝不能跨到infrastructure、interfaces、Spring框架。

值对象（Value Object）——身份的边界。TenantId是值对象，UserId是值对象。AI改一个值对象的定义时，必须同时改所有用它的地方，而不是悄悄换一种等价类型。

这套边界不是抽象的——有一支开源团队（ArchAIHarness）把DDD的“分层依赖”做成了一份现成的代码骨架，叫framework。它把每个工程切成六块，每块职责焊死、依赖方向单向。这份骨架最大的价值不是它本身，而是它给AI立了一份看得见、读得懂、能遵守的秩序。

common（零框架） → domain（领域） → application（用例编排）→ infrastructure（仓储 / Feign / Kafka） → interfaces（Controller / 切面） → bootstrap（启动）

依赖方向只有一条线：bootstrap → interfaces → application → domain → common（或者infrastructure → domain → common）。逆着走 = P0红线，PR直接阻塞。

这套分层焊死了，AI才能守住。没有这套分层，AI写代码就是凭印象；有了这套分层，AI写代码就是按规矩干。

下面这层想强调一下，因为你可能有个误会——

限界上下文是DDD的“业务边界”，不是“部署边界”。三个限界上下文可以部署在三个独立进程里，也可以部署在同一个进程里——怎么部署是工程选择，限界上下文是建模选择。这两件事别混。

讲到这里你大概有感觉了：DDD切出的边界，就是AI干活的边界。AI在边界内才有“业务直觉”（其实是按规矩干得出来的样子），出边界它就是瞎子。

那AI在边界内干得好不好，谁来审？下一节TDD上场。

四、TDD：测试 = 体系审计——覆盖率不是装饰，是AI干完活的护栏

把TDD摆上桌面之前，先把一个常见误会破了——

TDD在AI时代不是“开发流程”，而是“体系审计”。

什么意思？传统TDD是“红→绿→重构”的开发节奏——先写测试看它红，再写实现让它绿，再回头重构。AI时代这个节奏还在，但它的价值升级了：测试不是“开发过程的副产品”，而是AI干完活自己查“有没有干对”的护栏。

AI写了一坨代码，它自己不知道写对了没有。它可以跑一下编译，能过；它可以跑一下现有测试，也能过；但这不证明新代码是对的——只是证明它没破坏旧代码。

测试覆盖率门槛干的就是这件事：给AI一个它必须达到的硬指标。比如framework仓的规矩就是“领域层单元测试覆盖率 ≥ 90%”——这不是装饰，是AI接PR时的阻塞线。覆盖率不达标，PR阻塞，必须补测试。

有一份真实现场的工程妥协——这套骨架的文档写“领域层测试覆盖率必须 ≥ 90%”，但配置里实际只卡到70%。文档和代码打架，是工程师对现实的让步。但底线是：数字必须存在。哪怕70%卡在那里，AI也不敢全跳过测试。你把它调到90%还是80%，那是工程选择，不是“有没有规矩”的选择。

除了覆盖率门槛，测试本身的结构也是规矩的一部分——Given-When-Then。

@Testvoid shouldThrowDomainExceptionWhenUsernameTaken() {// givenwhen(userDomainService.isUsernameUnique("zhangsan", null)).thenReturn(false);// when & thenassertThatThrownBy(() -> userAppService.createUser(command)).isInstanceOf(DomainException.class).hasFieldOrPropertyWithValue("code", "USERNAME_TAKEN");}

这不是什么花架子，而是AI写测试时结构上不能省的三个块——前置条件、动作、断言。命名也讲究：shouldXxxWhenYyy，一眼就知道在测什么行为、在什么条件下。

第三个规矩是P0/P1/P2分级阻塞。

• P0：违反核心规范、影响架构正确性的——必须立即修复、禁止合并。比如domain层引入了Spring框架。
• P1：违反一般规范、影响代码质量的——必须修复、禁止合并。比如没清理ThreadLocal、Feign调用没降级。
• P2：不符合最佳实践、不影响功能的——建议修复、可合并。比如unused import、命名不规范。

AI写完一段代码，提交前自动跑一遍P0/P1/P2检查。P0命中 = 阻塞，必须改；P1命中 = 阻塞，必须改；P2命中 = 警告，可以合并。

这套机制不是空想，有一份真实的审查报告做证据——AI对一份骨架做了一次自动审查，结果是3个轻微建议、零严重问题、零警告。AI不是不能审代码，它能审——但它只能审“已经写进规矩里的东西”。

所以TDD在AI时代的真正含义是：

测试覆盖率是门、Given-When-Then是台阶、P0/P1/P2是红灯。你把这套护栏立好了，AI不会跳过去；你没立，AI当然不会自己装。

但你光有测试还不够——边界怎么画、规矩怎么写、AI怎么知道这些规矩？下一节SDD上场。

五、SDD：规范 = 人机协作协议——同一套秩序，两种表达

SDD在这一篇里不是三个字母的缩写游戏——它是AI时代工程文档体系的根本变化。

过去的规范是写给人看的。readme.md写得图文并茂，新人照着onboarding；架构图用Mermaid画得漂漂亮亮，技术评审时拿出来论证；命名规范、检查清单、避坑指南，全按人的阅读节奏排。

AI时代这套文档体系裂变成了两层：

• readme.md——给人看。架构说明、快速开始、代码示例、避坑指南、Mermaid流程图。
• AGENTS.md——给AI看。结构化检查清单、P0/P1/P2优先级、可机器解析。

同一套秩序，两种表达。

这件事为什么重要？因为readme.md写得再漂亮，AI也读不出P0/P1/P2的优先级；AGENTS.md里写着“P0命中阻塞”，AI才能在PR阶段自动拦截。

这两个文件不是替代关系，而是互补关系——readme.md解释“为什么这么定”，AGENTS.md规定“必须怎么守”。前者是哲学，后者是法律。

具体到工程落地，AGENTS.md的硬规范至少要包括这几条：

P0红线——比如认证中心有一条特别有意思的线：单点登录的Cookie必须用浏览器的JavaScript写，不能用服务端的Java接口写。乍一听这不是技术偏好？其实是前几年团队踩过一个Tomcat的坑：服务端Java接口写带前导点的跨子域Cookie，会被Tomcat的新版协议处理器拒绝，最后用户登录不上。这条线现在焊死在AGENTS.md里——用错 = 立刻阻塞PR。

依赖方向——比如domain层不能import任何Spring框架。这是framework六模块分层的硬约束，逆着走 = P0命中。

Header命名——比如x-user-id全小写，不能X-User-Id。这是auth-center / user-center / tenant-center / gateway四仓横向交叉遵守的共享规范，任何上下文私自扩展 = P0命中。

覆盖率门槛——比如领域层 ≥ 90%。不达标 = P0命中。

Controller路由——比如所有Controller必须显式@RequestMapping。漏掉 = P0命中（这条tenant-center守得很死，user-center还没全跟上，是同体系不同仓执行力度有差异的真实证据）。

这些规范有个共同特点——AI不能自主决策。它不能因为“觉得X-User-Id看起来更标准”就把x-user-id改了；它不能因为“觉得现在写个Cookie用Servlet API更顺手”就把JS写入的规矩绕了。

这些是硬规范。硬规范焊死在AGENTS.md里，AI只能遵守，不能改写。

但光有硬规范，秩序就够了吗？AI在硬规范内，是不是就必须按某个固定模板照抄？不一定。

下面这节是这一篇的关键——初版规划里漏掉了的洞察：秩序里有留白。

六、留白设计：秩序不是锁死AI，是给AI画好赛道——边界焊死、选择放开

上一节我们把SDD的硬规范焊死了——P0红线、依赖方向、Header命名、覆盖率门槛，AI一条都不能动。

但你想想，光有硬规范，AI在规矩里能“自由”吗？

先问你一个问题：你给一个新人一份写满硬规范的工作手册，他会怎么干活？

十有八九是——抄手册。手册写什么他干什么，手册没写的他不敢动。

AI也是这样。如果AGENTS.md里把每件事怎么实现都写死了，AI写出来的代码就是100%的模板——千篇一律、毫无章法、连错都错得一模一样。

更糟的是——你不给空间，AI只能抄模板。它不知道这个项目AuthService该用Redis还是Caffeine缓存，不知道这个团队偏好用MapStruct还是手写DTO转换。这些“实现细节”在硬规范里没写，AI就随便挑一个——挑错了你难受，挑对了也没觉得它聪明。

反过来——你给空间太大，AI就会失控。你不规定x-user-id全小写，它下次给你写个X-User-Id；你不规定Controller必须@RequestMapping，它就跳着写；你不规定P0红线，它每条都敢越。

那中间的“刚刚好”在哪？

答案是：边界焊死、选择放开。

焊死的是“AI不能越的界”——分层、Header、P0红线、覆盖率。这些是秩序的骨架，不许动。

放开的是“AI怎么实现”——SPI接口的实现选型、技术栈的具体选型、可选依赖的引入。秩序划到边界就停，边界内随便跑。

给你看一组真实例子就懂了。

gateway仓的6个SPI接口——每个接口职责都焊死了：

• 提token（TokenExtractor）；
• 校验token（TokenIntrospector）；
• 缓存校验结果（AuthenticationCache）；
• 校验租户权限（TenantAccessValidator）；
• 透传Header（HeaderEnricher）；
• 续期token（TokenRenewer）。

但每个SPI的实现是松的——默认有DefaultTokenExtractor、InMemoryAuthenticationCache、MultiTenantAccessValidator，你嫌默认实现不行？一个@Bean就能换：

@BeanTokenIntrospector myTokenIntrospector() {return bearerToken -> Mono.just(...);// 比如本地JWT验签}@BeanAuthenticationCache redisAuthCache(RedisTemplate<...> redis) {return new RedisAuthenticationCache(redis);// 集群级共享缓存}

为什么能这么换？因为GatewayAutoConfiguration里的8个@Bean全部标了@ConditionalOnMissingBean——你提供一个，框架就不提供默认的。

这就是软秩序——边界焊死（接口签名不能改）、选择放开（实现想怎么换怎么换）。

再来一组对比——

• framework仓告诉你不能做什么：domain层不能import Spring、覆盖率不能低于90%、Header不能用X-User-Id、Controller不能漏@RequestMapping。全是P0红线。
• gateway仓告诉你可以怎么做：token校验可以本地JWT、可以远程introspect、可以走Redis缓存、可以走本地缓存；缓存可以LRU、可以FIFO、可以Caffeine、可以Redis。技术栈你说了算。

framework告诉你不能做什么，gateway告诉你可以怎么做。

两层合起来，才是AI时代完整的秩序。

这个洞察得记牢——它是这一篇的“关键密钥”，也是28篇要在gateway + auth + user + tenant真实链路上验证的核心命题。

到这里，三件乐器都摆上桌面了。DDD划边界、TDD做审计、SDD立规矩——但SDD又分两层：硬规范（不能越界）+ 软秩序（实现可换）。两层合起来才是完整的“AI时代秩序乐器”。

下面把这一篇收个尾，然后把下一篇带进去。

七、写在最后——秩序不是AI的负担，是AI的翅膀

让我们回到开头那个反直觉的判断——AI编码能力越强，秩序越贵。

你可能还在想：以前没这么麻烦啊。规则是给“不靠谱的工程师”准备的，AI应该比人更靠谱才对吧？

这是把AI当人看了。AI不是“更靠谱的工程师”，AI是另一种执行者——它没有业务直觉，但它的执行力、放量速度、模仿能力都远超人类。你不给它规矩，它不会“自己学会”——它会用最快的速度放大项目里所有不规范。

所以DDD、TDD、SDD这三件乐器在AI时代的角色，不是给AI立更多规矩，而是给AI立“刚刚好”的规矩。

“刚刚好”是什么？

• DDD：业务边界 = AI边界。AI在哪个限界上下文，就说哪个上下文的话；出边界，停下来问人。
• TDD：测试 = 体系审计。覆盖率门槛 + Given-When-Then + P0/P1/P2分级阻塞，AI干完活自己查“有没有干对”。
• SDD：规范 = 人机协作协议。readme给人看，AGENTS.md给AI看——同一套秩序两种表达。
• 秩序里有留白：边界焊死、选择放开。硬规范不许越，软秩序可以换。

四件事合起来，给AI画一条赛道——边界内随便跑，边界外一步都越不了。

这件事往深了想，它其实是一个关于“作曲家与乐团”的隐喻。

架构师不是AI的甲方，架构师是AI的作曲家——你写乐谱，它演奏。

• DDD划旋律线——告诉AI这首曲子在哪个调上、有什么主题。
• TDD把每个音钉在调上——告诉AI每个音对不对、稳不稳。
• SDD是乐谱本身——音符是硬规范，表情记号是软秩序。

AI不是不需要规矩，AI是更需要规矩；秩序不是锁死AI的手，是给AI画好赛道。

未来真正会用AI的工程师，不一定是写代码最快的那一批，而是把秩序立得最清楚的那一批。

光说不练假把式。下一篇，我们到gateway + auth + user + tenant这套正在跑着的多租户SaaS工厂里去看一份完整的乐谱长什么样——它怎么把“边界焊死、选择放开”落到认证链路的每一步上，AI在这份乐谱里是怎么不越界地自主开发的。