你越来越熟练地把活甩给 AI 了。
需求丢过去，它给你写 controller；需求丢过去，它给你搭 domain；需求丢过去，它给你跑 JaCoCo。可你最近有没有这种感觉------同一个约束你跟它讲了三遍、五遍、十遍，它还是按它"印象里"的样子写？
不是 AI 学不会，是 AI 每次都是从零开始学。
它不知道你们用 Java 17 还是 Java 21、不知道你们 Header 全小写、不知道你们 domain 层零 Spring、不知道你们 P0 红线包括 SSO Cookie 必须 JS 写。它每接一个新会话、每开一个新分支，都把这些事重听一遍。你觉得它学得越来越快------是的，快到把你每次口头告知的技术约束全都"重新发明"了一遍。
这一篇专门解决这件事------给 AI 立第三道秩序。也就是 SDD。
不是教你 SDD 是什么。你可能早就看过"规范驱动开发""Spec 驱动"这类词，知道要把规范写下来。你缺的不是这个动作，是怎么让规范真正"长期挂"在 AI 工作台里，让工程师只聊业务、让 AI 自动按规范落地、不再每次重复告知。
这一篇不讲 SDD 的全套理论（二十多年前的方法论一篇讲不完），只讲AI 时代最该抓住的那一段------Spec 端打底、Story 端交付、留白区让 AI 飞。三件事讲清楚，AI 协作的"第三道秩序分水岭"就立起来了。
下面我们一段一段拆。
一、AI 协作的最大痛点------工程师每次都要重复告知技术约束
你可能觉得这标题反了------AI 越来越聪明，约束告知应该是越来越轻松才对啊。AI 上下文窗口越来越大、记忆能力越来越强、Agent 循环越来越稳；以前得说三遍的事，现在一遍它就记住了。
听起来很有道理。可真实现场不是这样。
我先把现场摆给你看。我过去一年在多个 AI 协作项目里看到的剧本，几乎都是这么演的。
第一个会话 ，你跟 AI 说："帮我写一个 Tenant 聚合根。"它给你整出 constructor、factory、setter、equals、hashCode，整整齐齐一坨。你打开一看------好家伙，Tenant 直接调 tenantRepository.save()，domain 层 import 了 Spring。你心里咯噔一下，提醒它："domain 层不能 import Spring。"它点点头："好的，下次注意。"
第二个会话，你又拉了一个新会话，让它写另一个聚合根。它又一次凭"印象"写------上次会话的提醒它早就忘了，domain 层又 import 了 Spring。你又提醒一次。它又点点头。
第三个会话 ，你新开一个分支，让它写一个新的限流器。它还是 import 了 Spring，还是在 domain 层调了 Redis 客户端，还是在 Service 层用了 RestTemplate（该用 WebClient）。你又、又、又提醒一遍。
第六个月，你打开 PR 列表，发现------同一个约束（domain 零 Spring），你跟 AI 讲了不下二十遍。每一遍它都点头、每一遍它下次又忘。约束没有沉淀下来，约束成了你每次会话必带的"开场白"。
这不是 AI 太笨，这是约束没有被长期挂载。
AI 没有"团队约束的本能"。你看到 domain 层不该有 Spring，立刻会想起"框架依赖倒置原则 + 六模块分层铁律 + AGENTS.md P0 红线"------这一整套判断是多年工程纪律和团队规范堆出来的。
AI 没有这堆纪律。它看到的是字符、命名、文件位置、上下文里你最近一次提的偏好。它能写语法正确的代码，但它写不出"团队规范上的对"。
更扎心的是，它不是在犯错，它是在用最快的速度忘掉你跟它讲过的一切。会话一关，记忆清零；下次开工，又从"语料库平均值"那个工程师开始写。
所以这个反直觉的结论你得先吞下去------
AI 协作的最大痛点，不是 AI 不够聪明，是工程师每次都要重复告知技术约束------SDD 就是要让这件事不再发生。
这一句你得记牢。它是这一篇的底色。
Spec 端把团队规范长期挂载，AI 训练时吸收记忆；Story 端把工程师对话聚焦到业务目标------"聊天即交付"是 SDD 双端的终极目标。
这两句合起来，就是 AI 时代 SDD 的真正价值------不是教你写更全的规范文档，是给 AI 立一套它"开机就读得到"的技术规范基础设施。
为什么这件事过去没人提
你可能想问：规范、规约、约束，是软件工程的"老生常谈"，为什么二十多年过去，今天才突然被 AI 时代捧成"第三道秩序分水岭"？
因为过去不需要。
2002 年到 2022 年那段时间，团队规范是写在 wiki、写在 onboarding 文档、写在老员工脑子里------新人入职看一遍、老员工带一遍、code review 复审一遍。流程跑二十年，团队规模从 5 人到 50 人，规范能磨平、传递能到位。
AI 时代情况反过来了。
AI 进来之后，"老员工"这个角色被 AI 替代了------你不再带新人 onboarding，你带的是 AI 读规范文档。可 AI 不会"看一遍 wiki 就记住"，AI 每次会话都从零开始。你不能把团队规范写进 wiki 就指望 AI 自动遵循------AI 读 wiki 跟读小说一样，扫一遍就忘。
每一次新会话都得重新告知。每一次新分支都得重新对齐。
这件事靠"口头告知"磨不平------你不能让团队里每个工程师、每次新会话、每次新分支都重新告知一次"domain 零 Spring、Header 全小写、P0 红线包括 SSO Cookie 必须 JS 写"。
怎么办？把规范写进文档还不够，得把规范焊进 AI 工作台 。SDD 在 AI 时代的真正用法，是把团队规范长期挂在 AI 训练阶段------AI 开工前自动读、自动吸收、自动记成自己的"团队习惯"；工程师只聊业务、不再重复告知。
这件事过去没人提，是因为过去没有 AI 需要"读这份规范"。今天有 AI 进场了，规范才变成"必须长期挂载"的基础设施。
所以 SDD 的价值从来没变------把团队规范沉淀下来。变的是它今天服务的对象：过去给老员工 onboarding，今天给 AI 训练。过去是文档备查，今天是 AI 开机就读。
那到底怎么立？这套规范基础设施长什么样？下一节我们正式讲 SDD 双端是什么。
二、什么是 SDD 双端------Spec 端打底 + Story 端交付，两端各管一段
我们把 SDD 摆到桌面上。
SDD 全名 Spec-Driven Development，规范驱动开发。这不是什么新方法论------二十多年前软件工程就有"先把规范写下来再写代码"的实践。今天在 AI 时代，SDD 突然从"好习惯"升级成"双端架构"------原因就是上一节说的，AI 没有团队约束的本能，得靠规范长期挂载。
这套双端架构的"骨架"由两件事组成------Spec 端（训练阶段，人全权沉淀）+ Story 端（交付阶段，工程师唯一入口）。两件事就是 SDD 在 AI 时代的核心骨架。把它们讲清楚，你就看懂了 SDD 在 AI 时代的一半。
下面我们按"先讲为什么需要它，再讲它是什么"的顺序拆。整套讲述我用厨房两本手册作主线比喻------这套比喻不是装饰，是帮你从厨房的物理直觉直接推出 SDD 的工程结论。
一句话故事：为什么团队规范会"漏"
我先给你讲一个真实的小故事。
有一次，我跟一个团队的架构师聊他们的 AI 协作流水线。他说："我们团队规范写得很全------六模块分层、AGENTS.md、coverage-rules、P0/P1/P2，文档加起来 200 多页。"
我点点头，问："那 domain 层 import Spring 这种事，AI 还会犯吗？"
他叹口气："会。"
"为什么？"
"因为 AI 每次新会话都从零开始。规范文档它读一遍就忘，下次开工又回到它'印象里'的工程师那套写法。我让团队每个工程师每天提醒 AI 不要 import Spring------可工程师们又不是复读机，提醒三遍五遍他们自己也烦，最后变成没人提醒，AI 该 import 还是 import。"
更糟的是，团队花了三个月写的规范文档，AI 完全不读------它"扫一眼"就过去了，连"SSO Cookie 必须 JS 写"这种最关键的 P0 红线都没记住。
你听出问题在哪了吗？规范文档有了，可 AI 不读、读了也记不住。规范成了"贴墙上的告示"，AI 路过看一眼、走过去了。
传统开发里，这种"漏"靠老员工盯、靠 code review 拦、能磨平。
AI 时代磨不平。AI 写代码的速度是人工的几十倍，reviewer 看不完；AI 不读规范文档，reviewer 想拦也拦不住------PR 提上来才发现问题，已经晚了。
怎么办？
两本手册：Spec 端 + Story 端
SDD 在 AI 时代的解法，是把"团队规范 + 工程师对话"切成两个完全独立的端------Spec 端和 Story 端。两端各管一段，AI 只跟这两端打交道。
我用"厨房两本手册"作最直觉的比喻。
一家像样的餐厅，后厨一定有两本手册------
第一本手册挂在墙上，叫"团队操作手册 + 设备清单"------封面印着"Spec 端"。这本手册长期挂在厨房墙上，记录团队的整套技术规范：灶具怎么用、刀具怎么选、调料怎么配、菜品有哪些标准做法。新人入职第一天，主厨指着手册说："这本先读透，后续做菜不用每次问师傅。"
这本手册对应 SDD 的 Spec 端 ------AI 工作台前置打底，人在训练阶段全权沉淀、AI 训练时吸收记忆。规范不是"贴墙上的告示"，是新人入职必读的入门教材。
第二本手册是服务员手里的，叫"顾客点菜单" ------封面印着"Story 端"。这本手册没有技术细节，只记录"顾客要什么"------"我要一份七分熟的牛排"、"我要一碗不要辣的酸辣汤"。服务员（工程师）拿菜单接单，厨师（AI）看到菜单后自动按 Spec 端手册匹配团队技术规范落地。
这本手册对应 SDD 的 Story 端------交付阶段，工程师唯一交互入口。工程师只聊业务（目标、流程、价值、验收），不涉及任何团队技术规范、架构细节、Header 命名、P0 红线。AI 看到 Story，自动按 Spec 端沉淀的团队规范写代码。
两本手册各管一段------
- Spec 端（团队规范手册）：长期挂在厨房墙上，AI 训练时读一次就吸收成自己的"团队习惯"，后续做菜（写代码）自动按手册规范来做------不用每次提醒"用这把刀、这个灶、这个调料"。
- Story 端（顾客点菜单） ：服务员只听顾客要什么，厨房收到菜单自动按 Spec 端手册匹配团队技术规范做菜。服务员（工程师）全程没碰过技术细节------他只对顾客说"好的，七分熟牛排"，转身交给厨房。
这就是 SDD 在 AI 时代的核心创新------双端架构。
Spec 端把团队规范长期挂载，AI 训练时吸收记忆；Story 端把工程师对话聚焦到业务目标------人机分工彻底切分。
这一句你记下来。它是 SDD 的核心命题，也是 AI 时代工程师给 AI 加的第三道秩序分水岭。
两端各管一段，互不越界
Spec 端和 Story 端不是两件事，是一套分工纪律------
Spec 端，人全责------团队规范由人全权整理、迭代、更新。AI 不参与规范的制定，AI 只负责吸收、记忆整套技术范式。人定 Spec、AI 记 Spec；规范改了人改、AI 跟着改。
Story 端，工程师唯一入口------交付阶段，工程师只沟通业务目标/用户流程/业务价值/验收场景，不涉及任何团队技术规范/架构细节。AI 收到 Story 自动匹配 Spec 基线落地------输出代码、跑测试、提 PR。
AI 永远只接收两样东西：一是 Spec 端长期挂载的团队规范（背景知识），二是 Story 端工程师的业务对话（任务输入）。AI 不需要工程师每次重新告知技术约束，也不需要工程师在 Story 里塞技术细节。
两端绝不混用------Spec 端不写业务对话，Story 端不写技术约束。一旦混用，就回到"AI 凭印象写代码"的旧模式------约束每次都讲一遍、每次都漏一次。
到这里你大概有感觉了：SDD 双端的核心不是"两份文档"，是人机分工纪律。Spec 端把"立规矩"这件事长期挂在 AI 训练阶段，Story 端把"做业务"这件事聚焦到工程师唯一入口。两端切分清楚，工程师从"重复告知约束"里彻底解放出来。
那 Spec 端具体沉淀什么？Story 端具体长什么样？下一节我们先讲 Spec 端。
三、Spec 端------AI 工作台前置打底
我们把 Spec 端摆到桌面上。
Spec 端是 SDD 双端里的"训练端"------AI 工作台前置打底，把团队技术规范长期挂载、人全权负责整理、AI 训练时吸收记忆。
Spec 端要沉淀的内容不是零散的"几条规矩"，是一整套团队技术范式------技术栈、编码规范、类结构、惯用设计模式、架构方案、最优实践，六大类缺一不可。这套范式被 AI 吸收成自己的"团队习惯"，后续写代码自动按这套习惯来。
下面我们一段一段拆。
Spec 端沉淀什么------六大类团队技术范式
Spec 端要沉淀的不是一份几十页的"规范大全"，是AI 读一遍就能照着做的六类核心内容。我把它们列出来，你按你团队的实际情况增减：
第一类：团队技术栈------项目用的是什么语言、什么框架、什么版本。
比如：
- 语言：Java 17
- 框架：Spring Boot 3.3 / Spring Cloud 2023
- 消息中间件：Kafka
- 数据库：MySQL 8.0
- 缓存：Redis 7
- 工具库：Lombok / Guava
- 测试框架：JUnit 5 / Mockito / JaCoCo
AI 读完这一类，下次写代码就默认用 Java 17 + Spring Boot 3.3 ，不再写 var 用 Java 11 风格、不再调 RestTemplate（该用 WebClient）、不再用 com.sun.* 内部 API。
第二类：编码规范------团队约定的代码风格、命名规则、注释规则、Header 规范。
比如：
- 命名：
UserId / TenantId / OrderId强类型 ID 值对象，禁止用 String 或 Long - 命名：
UserStatus.ACTIVE / DEACTIVATED / LOCKED枚举，禁止魔字符串 - 命名：
x-user-id / x-tenant-id / x-tenant-ids全小写 Header，禁止 X-User-Id - 格式：Google Java Format
- 日志：SLF4J 门面 + Logback 实现，禁止 System.out.println
- 异常：单一
DomainException类 + 工厂方法，禁止自定义 Exception 子类 - 注释：业务方法必须有 Javadoc + 中文说明
AI 读完这一类，下次写代码就默认按团队的命名风格来------不再混用驼峰和下划线、不再到处写 System.out、不再每个 service 造一个自己的 Exception。
第三类：类结构设计习惯------团队偏好的代码组织方式、分层纪律、模块边界。
比如：
- 分层：六模块（bootstrap / interfaces / application / domain ⭐零 Spring / infrastructure / common ⭐零框架）
- 依赖方向：
bootstrap → interfaces → application → domain → common、infrastructure → domain → common - 充血模型：业务逻辑归聚合根（
Order.pay()/Order.cancel()），service 只编排不实现 - 仓储接口：定义在 domain 层，实现在 infrastructure 层
- 领域事件：
@NoArgsConstructor+ 字段禁止 final（Jackson 反序列化要求）
AI 读完这一类，下次写代码就默认按分层纪律来------不再把 Spring 注解写进 domain 层、不再让 service 直接调 repository、不再给 DomainEvent 字段加 final。
第四类：惯用设计模式------团队偏好的模式选择和落地方式。
比如：
- 聚合根基类：
AggregateRoot自带private final List<DomainEvent>+registerEvent()+clearDomainEvents() - 仓储模式：
BaseRepository<T, ID>通用接口 + 各聚合根专用接口 - 幂等消费：
@OnEvent+IdempotentAspect自动幂等（业务代码完全无需手写幂等） - 响应包装：
R<T>+ResponseBodyWrapper（Controller 不手动包 R）
AI 读完这一类，下次写代码就默认用团队偏好的模式 ------不再自己造轮子写 BaseEntity、不再每个 service 手写幂等、不再 Controller 里手动 .data(...) 包响应。
第五类：内部架构方案------团队的整体架构选择、技术选型、模块边界。
比如：
- 双文档体系：
readme.md人友好 +AGENTS.mdAI 友好------同一套秩序两种表达 - 权限模型：PBAC 权限码
资源:操作规范（USER:CREATE / USER:DELETE / ORDER:VIEW） - 网关 Header 透传：
AppContext请求级 ThreadLocal + 异步线程ContextTaskDecorator - 反应式纪律：全 WebFlux + Reactor，禁绝
Mono.block()/RestTemplate - SPI 接口：
@ConditionalOnMissingBean让 AI 按需替换默认实现
AI 读完这一类，下次写代码就默认按团队架构来------不再自己选 WebFlux 还是 MVC、不再自己定义权限模型、不再 Header 透传写 ThreadLocal 还是别的方案。
第六类：长期最优落地实践------团队踩过的坑、验证过的最佳实践。
比如：
- 覆盖率门槛：common + domain 各层 ≥ 90%（行/分支双门槛），作为 P0 准入
- Mock 边界：禁止 Mock 实体 / ValueObject / Command / Query，必须真造真测
- P0 红线清单：domain 层零 Spring / SSO Cookie 必须 JS 写 / Header 全小写不能改
- Given-When-Then 强制：
AGENTS.md§6.3 测试方法命名规范
AI 读完这一类，下次写代码就默认按团队纪律来------不再把覆盖率刷成 60%、不再 mock 实体、不再用 Servlet API 写 Cookie。
六类合起来，就是 Spec 端沉淀的完整团队技术范式 。每一类都不是"贴墙上的告示"，是AI 训练时吸收成自己习惯的入门教材。
人全权负责整理、迭代、更新
Spec 端的关键纪律只有一条------人全权负责。
团队规范不是 AI 写的，是人写的。AI 不参与规范的制定、修改、迭代；AI 只负责吸收、记忆整套范式。
为什么必须人全责？因为 AI 一定会改。AI 给数字"感觉合理"、给命名"看着舒服"------可它不知道你这个项目的上下文历史痛点，不知道以前哪个 P0 红线是因为漏掉出了生产事故。它只看当下的代码和当下的语境，把"我看着合理"当作"项目应该这样"。
所以规范必须由人定、AI 记------人定期 review Spec、更新 Spec、迭代 Spec；AI 训练时读一次、按 Spec 写后续所有代码。
Spec 端不是一锤子买卖。规范随项目一起演化------新技术栈引入时加进 Spec、老红线不再适用时从 Spec 移除、新的最优实践被验证后写进 Spec。人改 Spec、AI 跟 Spec，两端切分清楚。
行业案例：Spec 端"长期挂载"省了多少成本
Spec 端长期挂载是不是真的能省成本？我给你一组行业数据，你判断。
腾讯云 BMAD 平台 把团队的 architecture.md 永久挂载 在 AI 工作台------AI 每次编码自动读取团队架构 Spec，不需要工程师每次重复告知架构约束。结果是------上下文重复提示词成本下降 65%。
aiXcoder 在某银行做私有化部署 时，把行内完整技术规范做模型微调 + 工作台长期挂载------AI 不再"凭印象写代码"，按行内规范落地的代码合规性提升 50%，代码生成准确率从 10% 提升到 35%。
腾讯云 + aiXcoder 两个案例摆在一起看 ------一个靠 Spec 文档长期挂载（BMAD），一个靠模型微调 + 工作台挂载（aiXcoder），结果都指向同一件事：规范长期挂载 = 工程师重复告知成本暴跌 + 代码质量跃升。
Spec 端不是"贴墙上的告示"，是 AI 工作台的"开机启动项"。规范在那里，AI 就按规范写；规范不在那里，AI 就按印象写。
四、Story 端------FDE 工程师唯一交互入口
我们把 Story 端摆到桌面上。
Story 端是 SDD 双端里的"交付端"------交付阶段，工程师唯一交互入口。工程师只沟通业务，不涉及技术细节；AI 收到 Story 自动匹配 Spec 基线落地。
Story 端的目标只有一个------让工程师从"重复告知技术约束"里彻底解放出来，只聊业务。
下面我们一段一段拆。
Story 端工程师只聊什么
Story 端的输入是业务对话------工程师跟 AI 说的话，只围绕四件事：
业务目标------这个 Story 要解决什么问题、为谁解决、解决到什么程度。
例子：
"我们 SaaS 平台的客服部门需要一个功能：让客服能查询某租户下的所有用户信息，包括用户名、手机号、最近登录时间。这是为了处理'租户投诉某用户违规'的场景。"
用户流程------用户怎么走到这一步、前置条件是什么、后置效果是什么。
例子：
"客服登录后台 → 进入'租户管理' → 选择具体租户 → 点击'查看用户列表' → 输入查询条件（用户名/手机号） → 看到用户列表。列表要分页，每页 20 条。"
业务价值------这个功能上线后，业务上有什么变化。
例子：
"上线后，客服处理租户投诉的效率从 30 分钟降到 5 分钟；用户满意度提升。"
验收场景------怎么算"做对了"。
例子：
"验收场景 1：输入手机号前缀 138，能查到所有 138 开头的用户；验收场景 2：用户列表按最近登录时间倒序；验收场景 3：分页参数 page=2&size=10 返回第 11-20 条。"
这四件事讲清楚，业务对话就完了。不需要工程师讲"用什么语言"、"用什么框架"、"Header 怎么写"、"P0 红线有哪些"。这些事 Spec 端已经沉淀好，AI 自动按 Spec 落地。
Story 端工程师绝不聊什么
反过来，Story 端工程师绝不聊以下内容------
- ❌ "用 Java 17 写、用 Spring Boot 3.3"
- ❌ "domain 层不要 import Spring"
- ❌ "Header 写 x-user-id 不要写 X-User-Id"
- ❌ "SSO Cookie 必须用 JS 写"
- ❌ "覆盖率达到 90% 才算过"
- ❌ "Mock 不要 mock 实体"
- ❌ "DomainEvent 子类字段禁止 final"
这些事都在 Spec 端------AI 训练时已经读过、已经吸收成自己的"团队习惯"。工程师再讲一遍，就是重复告知；重复告知在 SDD 双端架构里是冗余、是浪费、是体系失效的征兆。
工程师在 Story 端讲技术约束，相当于把已经贴在墙上的告示再口头念一遍 ------告示还在墙上，没人去看；工程师念完，没人记得。两端切分就是要把"念告示"这件事从工程师的日常工作里彻底拿掉。
行业案例：Story 端"只聊业务"提了多少效
Story 端"只聊业务"是不是真的提效？我给你两组行业数据。
SpecStory Studio 在一家海外 SaaS 团队落地 SDD 双端后------
- 澄清轮次仅 1.01 次（即 AI 平均只需要被澄清 1 次就能交付，远低于传统开发的 5-10 次）
- 日均提交代码量是传统开发的 10 倍
- 首次交付通过率达 85.7%（即 10 次提交有 8.5 次一次就过，剩下的 1.5 次打回改改就过）
海外某 Fintech 公司 14 人团队用 SDD 双端落地后------
- 9 个月业务 roadmap 压缩到 11 周交付
- 上线故障从 17 个降至 3 个（下降 82%）
两组数据摆在一起看------一个靠"澄清轮次 + 日均提交 + 首次交付"衡量（SpecStory Studio），一个靠"交付周期 + 故障数"衡量（Fintech 14 人）。两组数据都指向同一件事------Story 端只聊业务，AI 自动按 Spec 落地，工程师从重复告知里解放出来，交付效率和代码质量同时跃升。
工程师只聊业务，AI 自动匹配技术规范落地------"聊天即交付"是 SDD 双端的终极目标。
这一句你记下来。它是 SDD 双端的最终归宿，也是 AI 时代 FDE 工程师的核心工作方式。
五、核心创新------留白区，把自由还给 AI
我们把留白区摆到桌面上。
留白区是 SDD 这套方法论的差异化亮点------前三道秩序（DDD / TDD / Spec 端）把规矩焊死了，规矩之间"留出来的空间"就是留白区。留白区完全交 AI 自主发挥，工程师不该再管。
留白区不是"放任 AI 乱写"，是在三层刚性约束之间，给 AI 留出"怎么实现"的自由空间。
下面我们一段一段拆。
三层刚性约束焊死
第一层------DDD 锁业务赛道（上一篇讲过的边界）。
业务边界 = AI 边界。AI 进了哪个限界上下文，就说哪个上下文的术语；出上下文就停下来问人。限界上下文、聚合根、统一语言------这三件事焊死业务赛道，AI 不会越界。
第二层------TDD 卡审计红线（上一上篇讲过的试菜员）。
覆盖率 ≥ 90% + Given-When-Then + P0/P1/P2 分级阻塞 + Mock 边界焊死。AI 写完代码，CI/CD 流水线自动试菜------逻辑不对直接打回，违规红线直接拦截。审计红线焊死，AI 不会"逻辑上不对"地交付。
第三层------Spec 固技术基线（这一篇刚讲的）。
团队技术栈、编码规范、类结构、设计模式、架构方案、最优实践------六大类范式长期挂载，AI 训练时吸收、后续写代码自动按规范来。技术基线焊死，AI 不会"凭印象写代码"。
三层合起来------DDD 锁赛道 + TDD 卡审计 + Spec 固技术 = 三层刚性约束。这三层之外，就是留白区。
留白区------三层之外的自由空间
留白区是"菜单没写但厨师可自由发挥的部分"------比如：
- 非核心中间件适配------比如日志中间件用 Logback 还是 Log4j2、AI 自主选
- 设计模式落地------比如领域事件发布是同步还是异步、AI 自主选
- 类拆分------比如一个 service 该拆成三个还是五个、AI 自主决定
- 工具函数实现------比如字符串处理是用 Apache Commons 还是 Guava、AI 自主选
- 分支算法------比如某种业务分支该用 if-else 还是策略模式、AI 自主决定
- 局部变量命名 ------比如
List<User>叫users还是userList、AI 自主决定 - 注释风格------比如某个方法要不要加 Javadoc、AI 自主决定
这些事不影响业务验收、不影响审计红线、不影响技术基线------纯技术实现细节，AI 怎么写都对，工程师不该再管。
工程师管这些事会怎样？回归到"重复告知"的旧模式------工程师告诉 AI "这里用 if-else"、AI 下次又按印象写 "这里用 switch"、工程师再告诉它一遍......无限循环。
留白区的设计价值是------既杜绝 AI 篡改业务、越界架构，又不束缚 AI 批量生成的灵活性。三层约束守"做对的底线"，留白区让 AI 在底线之上自由发挥。
平衡风险管控与交付效率
留白区的关键洞察是------风险管控和交付效率不是反义词，是同一件事的两面。
不留空间------AI 只会抄模板，写出来的代码死板、没优化、读着别扭；过度发挥------AI 越界，业务糊掉、架构腐化、故障满天。只有"焊边界 + 放选择"才能让 AI 在风险可控的前提下充分释放产能。
我用厨房比喻把这件事讲透------
三层刚性 = 厨房的三道焊死的规矩：
- DDD = 后厨工种分区焊死（切配不能跑炒锅区）
- TDD = 出菜口试菜员焊死（不合格不上桌）
- Spec 端 = 墙上挂的手册焊死（团队规范全员遵守）
留白区 = 工种区之间的过道、调料台、装盘装饰区------
- 葱花怎么摆------AI 自己决定
- 盘边用什么装饰------AI 自己决定
- 调料配比微调------AI 自己决定
这些细节不影响"味道对不对"（DDD + TDD 守住）、不影响"团队规范守没守"（Spec 端守住），纯粹是"美感"和"效率"的发挥空间。
留白区是这套方法论的差异化亮点------DDD 锁赛道 + TDD 卡审计 + Spec 固技术，这三层之外，完全交给 AI 自由发挥。
这一句你记下来。它是 SDD 的差异化亮点，也是 AI 时代工程师给 AI 的"最后一层自由度"。
适用边界：留白区不是万能解药
留白区不是"放之四海皆准"的设计模式------它有严格的适用边界。
留白区适用于：
- 复杂业务系统------业务跨多个限界上下文、有清晰的领域边界
- 企业业务服务------长期演化的核心系统、团队稳定、规范沉淀成本高
- FDE 一线交付场景------工程师和 AI 协作密集、效率是核心 KPI
留白区不适用于：
- 小型工具------一次性脚本、几小时写完的小工具，Spec 端沉淀成本远高于收益
- 独立脚本------单文件、单函数的轻量活，AI 凭印象写就够
- 探索性原型------业务边界还没定、规范还没沉淀，硬上 Spec 端就是过度工程
这套方法论仅针对复杂业务系统 / 企业业务服务 / FDE 一线交付场景------不适用小型工具 / 独立脚本。把 SDD 硬套到小工具上，就是把杀鸡刀用在蚂蚁上。
六、完整四阶段工作流------SDD 怎么落地到日常交付
我们把 SDD 的完整落地工作流摆到桌面上。
Spec 端 + Story 端 + 留白区，是 SDD 的三块拼图。这一节把它们拼成一条完整的、可实操的 FDE 工程师日常工作流。
整条工作流分四个阶段------前置工程（一次性）→ 需求对话（Story 端）→ AI 自动开发（Spec 基线匹配）→ TDD 全流程审计（自动拦截）→ 上线交付。
下面我们一段一段拆。
阶段一：前置工程------平台搭建（一次性）
前置工程是 SDD 的"造厨房"环节------一次性投入，把 Spec 端的基础设施搭好。
责任人 ：架构师 / 平台工程师 产出物：
- framework 工程骨架 ------六模块分层铁律、双文档体系（
readme.md+AGENTS.md）、覆盖率门槛、P0 红线清单、Given-When-Then 规范、Mock 边界规范 - Spec 端知识库------团队技术栈、编码规范、类结构、设计模式、架构方案、最优实践------按六大类整理成结构化文档
- CI/CD 流水线------Maven 配置、JaCoCo 配置、P0 阻断脚本、GitHub Actions 触发器、PR 模板
关键工具：framework 仓库（开源工程底座）+ Spec 端整理工具
前置工程的产出物就是 SDD 的"基础设施"------它一旦搭好，新服务 clone 下来就自带团队规范、AI 训练时直接读、不用从零搭。
阶段二：需求对话------Story 端工程师唯一入口
需求对话是 SDD 的"接单"环节------工程师只聊业务，把 Story 端的输入讲清楚。
责任人 ：FDE 工程师 产出物：
- 业务 Story 卡片------业务目标、用户流程、业务价值、验收场景，按上一节讲的"四件事"结构化整理
- 用例规约（可选）------如果业务复杂，把每个动作展开成"输入/输出/边界/异常路径"的结构化描述
关键工具：工程师的嘴 + 纸笔 / 任务卡工具
需求对话的关键纪律------只聊业务，不聊技术。工程师不讲"用什么语言"、"用什么框架"、"Header 怎么写"。这些事 Spec 端已经写好，AI 自动按 Spec 落地。
阶段三：AI 自动开发------Spec 基线匹配
AI 自动开发是 SDD 的"做菜"环节------AI 收到 Story 自动按 Spec 端团队规范落地。
责任人 ：AI 产出物：
- 代码------controller / service / domain / repository / dto / tests
- 单元测试------Given-When-Then 结构、真造真测、覆盖率门槛满足
- 领域事件 （如需要）------
@NoArgsConstructor+ 字段禁止 final - PR------提交流水线
关键工具：AI + Spec 端知识库 + framework 工程骨架
AI 自动开发的关键纪律------按 Spec 写、按留白区发挥。技术栈、命名、分层、Header、P0 红线------这些都按 Spec 来；非核心中间件、设计模式、类拆分、工具函数------这些在留白区自由发挥。
阶段四：TDD 全流程审计------自动拦截
TDD 全流程审计是 SDD 的"试菜"环节------CI/CD 流水线自动跑单元测试 + 集成测试 + 覆盖率检查 + P0 红线扫描。
责任人 ：CI/CD 流水线 产出物：
- 测试结果------单元测试绿/集成测试绿/E2E 测试绿
- 覆盖率报告------JaCoCo 统计的 LINE / BRANCH 覆盖率
- P0 检查报告------domain 层零 Spring / SSO Cookie JS 写 / Header 全小写 / Mock 边界等
- 拦截 / 通过------任意一项不达标，PR 打回 AI 重做；全绿，PR 进主分支
关键工具：JaCoCo + P0 阻断脚本 + GitHub Actions
TDD 全流程审计的关键纪律------流水线 24 小时在线、不累、不跳着看、不走神。AI 写得再快，流水线跟得上。
阶段五：上线交付------灰度 / 监控 / 回滚
上线交付是 SDD 的"出菜"环节------代码进生产、灰度发布、监控告警、故障回滚。
责任人 ：FDE 工程师 + 运维 产出物：
- 可上线版本------每个上下文独立版本号、独立发版
- 灰度策略------按上下文粒度灰度（auth-center 先灰 10%、观察稳定后 50%、最后 100%）
- 监控指标------每个上下文独立 QPS / 错误率 / 响应时间
- 回滚预案------事务回滚 / 事件反向补偿
关键工具：CI/CD 流水线 + 监控告警 + 配置中心
上线交付的关键纪律------版本化、灰度化、可回滚、可监控。AI 部署按规矩发版、按规矩灰度、按规矩回滚、按规矩监控，不出格、不翻车。
五个阶段合起来的全景图
五个阶段连成一条流水线------前置工程（一次性）→ 需求对话（Story）→ AI 自动开发（Spec 匹配）→ TDD 审计（拦截）→ 上线交付（灰度）。每个阶段有明确的产出物 + 责任人 + 关键工具。
FDE 工程师拿到这条流水线，日常工作就两件事------
- 业务对话（Story 端）------跟业务方聊清楚"做什么、为什么、验收什么"
- 平台复用（Spec 端 + framework）------直接用前置工程搭好的基础设施，不用从零搭
剩下的活（代码怎么写、测试怎么跑、规范怎么守、审计怎么过、上线怎么发）------AI 自动按 Spec 端团队规范 + TDD 审计红线落地，FDE 工程师不需要重复告知。
七、写在最后------SDD 双端 + 留白区，AI 时代工程师的第三道秩序
回到开头那个反直觉的判断------AI 协作的最大痛点，不是 AI 不够聪明，是工程师每次都要重复告知技术约束。
你可能还在想：以前没这么麻烦啊。规范写进文档、onboarding 带一遍，不就够了吗？
这是把 SDD 当"文档备查"了。SDD 在 AI 时代不是文档备查，是给 AI 立一套它"开机就读得到"的技术规范基础设施。规范不长期挂载在 AI 工作台，AI 就每次从零开始；规范挂在那里，AI 就按规范写------这就是"Spec 端打底"的真正含义。
所以 SDD 在 AI 时代的角色，不是教你写更全的规范文档，是给 AI 立一套它能照着走的"团队规范基础设施"。
这套基础设施我们用"厨房两本手册"这个最日常的比喻串了一整篇------
- Spec 端 = 厨房的"团队操作手册 + 设备清单"。长期挂在墙上，新人（AI 训练）读一遍就吸收成自己的"团队习惯"，后续做菜（写代码）自动按手册规范来做------不用每次提醒"用这把刀、这个灶、这个调料"。
- Story 端 = 厨房的"顾客点菜单"。服务员（工程师）只听顾客要什么（七分熟牛排、不要葱），厨房（AI）收到菜单自动按 Spec 端手册匹配团队技术规范做菜。服务员全程没碰过技术细节。
- 留白区 = 菜单没写但厨师可自由发挥的部分。DDD 锁赛道 + TDD 卡审计 + Spec 固技术，三层刚性之外完全交 AI 自主------葱花怎么摆、盘边怎么装饰，AI 决定。
- 完整四阶段工作流 = FDE 工程师日常交付的标准化流水线。前置工程（一次性搭基础设施）→ 需求对话（只聊业务）→ AI 自动开发（按 Spec 匹配）→ TDD 审计（流水线拦截）→ 上线交付（按规矩发版）。
Spec 端把团队规范长期挂载，AI 训练时吸收记忆；Story 端把工程师对话聚焦到业务目标------人机分工彻底切分。
这一句你记下来。它是 SDD 的核心命题，也是 AI 时代工程师的第三道秩序分水岭。
你可能会问：DDD + TDD + SDD 三件套听起来都是给 AI 立规矩，规矩立完了 AI 哪还有发挥空间？
有的------就是留白区。
留白区是这套方法论的差异化亮点------DDD 锁赛道 + TDD 卡审计 + Spec 固技术，这三层之外，完全交给 AI 自由发挥。
三层约束守"做对的底线"，留白区让 AI 在底线之上自由发挥。这就是 AI 时代工程师给 AI 的"最后一层自由度"------既杜绝 AI 篡改业务、越界架构，又不束缚 AI 批量生成的灵活性。
DDD 锁赛道、TDD 卡审计、Spec 固技术、留白区让 AI 飞------这四层加在一起，才是 AI 时代工程师的完整秩序。
这一句你记下来。它是这一篇的收束，也是 29-32 四篇一组的总结。
光说不练假把式。下一篇我们到 framework 仓库里去看一份完整的乐谱怎么谱出来------DDD / TDD / SDD 三件套在 framework 里怎么长成可跑可用的工程骨架，怎么让 AI 在四层秩序里真正飞起来。
你会在 framework 里看到------六模块分层铁律、零 Spring 依赖、JaCoCo 90% 强制覆盖率、P0 / P1 / P2 分级、双文档体系、SPI 软秩序------这套工程骨架把 DDD / TDD / SDD 三件套从方法论落到代码，新服务 clone 下来第一天就有完整秩序。这就是 32 篇要讲的------framework 是一座已经搭好的厨房。
关于 ArchAIHarness
这篇文章是「看懂 AI 与智能体」专栏的一部分，由 ArchAIHarness 持续输出。
ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产，主张：
架构师定义秩序，AI 在秩序中生长。人立法，AI 执行，体系审计。
如果你也希望 AI 在明确的架构边界内协作，而不是在混沌中碰运气，欢迎到 GitHub 上看看我们在做什么：
- 组织主页 ：github.com/ArchAIHarne... --- 了解完整理念与资产全景
- 本专栏 ：
zhuanlan-ai-and-agents--- 所有文章的源码与发布记录 - 实践指南 ：
docs--- 架构哲学、工程方法和落地指南 - 开源工具 ：
agent-workflows--- 可复用的 AI 协作 Agents、Skills 与 Tools - 工程样例 ：
framework--- DDD + AI 协作的工程底座，展示如何在开发中融合 AI
Engineered by Architects · Empowered by AI · Audited by Discipline