你越来越熟练地把活甩给 AI 了。老实说，

需求丢过去。它给你写 controller；需求丢过去，它给你搭 domain；不过，需求丢过去，它给你跑 JaCoCo。可你最近有没有这种感觉——同一个约束你跟它讲了三遍、五遍、十遍，它还是按它"印象里"的样子写？

不是 AI 学不会，是 AI 每次都是从基础开始学。

它不知道你们用 Java 还是 Kotlin、不知道你们 Header 全小写、不知道你们 domain 层零 Spring、不知道你们 P0 红线包括 SSO Cookie 必须 JS 写。它每接一个新会话、每开一个新分支，都把这些事重听一遍。你觉得它学得越来越快——是的，快到把你每次口头告知的技术约束全都"重新发明"了一遍。

这一篇专门解决这件事——给 AI 立第三道秩序。也就是 SDD，

你可能早就看过"规范驱动开发""Spec 驱动"这类词，知道要把规范写下来。你缺的不是这个动作，是怎么让规范真正"长期挂"在 AI 工作台里让工程师只聊业务、让 AI 自动按规范落地、不再每次重复告知。

这一篇不讲 SDD 的全套理论，只讲AI 时代最该抓住的那一段——Spec 端打底、Story 端交付、留白区让 AI 飞。三件事讲清楚，AI 协作的"第三道秩序分水岭"就立起来了。

一、AI 协作的最大痛点——工程师每次都要重复告知技术约束

AI 越来越聪明，约束告知应该是越来越轻松才对啊？

AI 越来越大、记忆能力越来越强、Agent 循环越来越稳；以前得说三遍的事，现在一遍它就记住了。

听起来很有道理。可真实现场不是这样，

我先把现场摆给你看。我过去一年在多个 AI 协作项目里看到的剧本，几乎都是这么演的。

第一个会话你跟 AI 说："帮我写一个 Tenant 聚合根。"它给你整出 constructor、factory、setter、equals、hashCode，整整齐齐一坨。话说回来，打开一看——好家伙。Tenant 直接调 tenantRepository.savedomain 层 import 了 Spring。

这时提醒它："domain 层不能 import Spring。再看"它点点头，"好的，下次注意。"

第二个会话你又拉了一个新会话，让它写另一个聚合根。它又一次凭"印象"写——上次会话的提醒它早就忘了domain 层又 import 了 Spring。 提醒一次它又点头。

第三个会话你新开一个分支，让它写一个新的限流器。它还是 import 了 Spring，还是在 domain 层调了 Redis 客户端。还是在 Service 层用了 RestTemplate。 提醒，一遍遍重复。

第六个月打开 PR 列表。发现——同一个约束，已经跟 AI 讲了不下二十遍，每一次都点头，却每一次都忘记。

这不是 AI 太笨，这是约束没有被长期挂载。

AI 没有"团队约束的本能". 看到 domain 层不该有 Spring，就会想起“框架依赖倒置原则 + 六模块分层铁律 + AGENTS.md P0 红线”。这整套判断是多年工程纪律和团队规范堆出来的，而 AI 没有这堆纪律。只看到字符、命名、文件位置还有最近一次提到的偏好。AI 能写语法正确的代码，却写不出“团队规范上的对”。

更扎心的是它不是在犯错，而是在用最快的速度忘掉所有告诉过它的信息。

• Ai 会话结束后记忆清零；下次开工，又从“语料库平均值”那个工程师开始写。
• 工程师每次都要重复告知技术约束——SDD 就是要让这件事不再发生。

为什么这件事过去没人提

过去不需要：

• Ai 替代老员工后“老员工”角色消失。你不再带新人 onboarding，你带的是 AI 读规范文档。但 AI 不会“一遍读完 wiki 就记住”。每次会话都从基础开始，需要重新告知技术约束。这种“口头告知”无法磨平。需要把规范焊进 AI 工作台：Spec 长期挂载 = 工程师只聊业务，不再重复告知。
• Ai 不读文档就忘，“贴墙上的告示”根本不起作用.

二、什么是 SDD 双端——Spec 端打底 + Story 端交付。两端各管一段

S D D 全名 Spec-Driven Development，二十多年前已有实践。怎么说呢，但它升级为“双端架构”。因为Ai 没有团队约束本能，需要通过长期挂载来让其遵循规范。

至于一句话故事，为什么团队规范会“漏”

实际案例：

• Ai 每次新会话都会忘记 “domain 层零 Spring”。即使团队每天提醒，也因频繁重复而产生疲劳感；最终没人再提醒，Ai 又回到错误方法。
• Ai “扫一眼”规章文档便走过不记住关键红线如 “SSO Cookie 必须 JS 写”。导致 PR 提交后才发现问题，大幅增加返工成本。

两本手册的观点是，Spec 端 + Story 端

• 第一本手册：- 挂在厨房墙上记录完整技术栈、编码规范等，为新人提供入门教材。也是 Ai 在训练阶段读取并吸收的内容.
• 第二本手册：- 服务员手里的菜单，仅记录业务需求，工程师只负责业务对话，不涉及技术细节.

两端各管一段，互不越界

• Spec 端，人全责：- 团队负责整理与更新规范；Ai 吸收并遵循.
• Story 端，工程师唯一入口：- 工程师只沟通业务目标/流程/价值/验收;Ai 自动匹配 Spec 落地代码.
• Ai 永远只接收两样东西：1）Spec 基线；2）Story 输入.
• 混用导致旧模式回归：技术细节 进入 Story，对话变成“重复告知”。

三、Spec 端——AI 工作台前置打底

Spec 端沉淀什么——六大类团队技术范式

1. 团队技术栈：- 如语言 Java。框架 Spring Boot,消息 Kafka 等.
2. 编码规范：- 命名规则、Header 小写等;说起来，Google Java Format;SLF4J+Logback;单一 DomainException 等.
3. 类结构设计习惯：- 六模块分层;聚合根充血模型，仓储接口定义位置等.
4. 惯用设计模式：- AggregateRoot 基类,BaseRepository 通用接口,幂等消费 Aspect,响应包装 R.
5. 内部架构方案：- 双文档程序,PBAC 权限码模型,Header透传 ThreadLocal + ContextTaskDecorator。全 WebFlux 禁止 RestTemplate 等.
6. 长期最优落地实践：- 覆盖率门槛,Mock 边界规定,P0 红线清单,Given-When-Then 测试命名规则等.

人全权负责整理、迭代、更新

Ai 不参与制定或修改，只负责吸收记忆。怎么说呢，人必须定期 review Spec 并同步到 AI 工作台。否则旧规仍然被 Ai 持续复刻。

领域案例的观点是，Spec 端“长期挂载”省了多少成本

• Tencent Cloud BMAD 网站将 architecture.md 永久挂载至 Ai 工作台 → 上下文重复提示词成本下降显著;
\
• aixcoder 在某银行私有化部署后进行模型微调 + 持久挂载 → 合规代码比例提高显著,生成准确率提高显著;
\
• {} → **规格长期挂载 = 重复告知成本暴跌 + 代码质量跃升**.
\

四、Story 端——FDE 工程师唯一交互入口

Story 端工程师只聊什么

• 业务目标 ： 示例：“SaaS 网站客服需要查询租户下所有使用者信息，用于处理投诉。说起来，”
• 使用者流程 ： 示例：“客服登录 → 租户管理 → 查看使用者列表 → 分页查询。话说回来，”
• 业务价值 ： 示例：“处理效率从 X 分钟降至 Y 分钟。”
• 验收场景 ： 示例：“手机号前缀查询返回全部匹配；列表倒序，不过，分页参数返回对应页。老实说，”

Engineer must not talk about:

... ...

...

---