AI 写代码越快，你的代码库死得越快——除非补上这一层

AI 写代码的速度正在突破人类理解的边界。一个需求丢给 Agent几分钟内产出几百行代码三个 Agent 并行一天能堆出一个模块Cloud Code 协作下团队的交付量翻了两三倍。看起来我们正站在软件工程史上最幸福的时代。但真相是AI 写代码越快你的代码库死得越快。问题不会在第 1 天暴露甚至不会在第 10 天暴露。它像一种慢性病等你闻到代码库腐烂的气味时技术债务已经复利滚到了无法收拾的地步。2026 年主流叙事给出的解药是 SDDSpec-Driven Development。GitHub Spec Kit、Amazon Kiro、Tessl——所有人都在说「Intent is Truth」只要规格写得够细AI 就能稳定输出。我也是这么信的。我们从「想到什么需求就指挥 Agent 开发」的随意状态升级成了基于需求池、设计、实现、测试、上线的标准化流水线。Constitution、Specification、Plan、Tasks 一层套一层规格文档写得前所未有地细。但两周后代码库还是以一种诡异的方式失控了。一、同样的 Spec第 20 个模块和第 1 个模块长得不一样问题最初很隐蔽。第一个 Agent 实现用户模块时把业务逻辑写在了 Application 层。第二个 Agent 处理订单模块时认为「核心业务逻辑应该下沉到 Domain Service」。第三个 Agent 写支付模块时直接绕过了 Repository在 Handler 里调用了原生 SQL。单独看每个模块都能跑通。单独看每个实现都「符合规格」——因为 Spec 里只写了「需要支持用户注册」「需要处理订单状态流转」「需要完成支付回调」并没有规定「这段逻辑应该放在哪一层」。但当我想把这三个模块串起来跑一个端到端流程时我崩溃了。同一个概念在不同模块里有不同的命名。同一种数据流有的走领域模型有的走 DTO 拼接。代码库没有劣化到不能用的程度但它已经开始散发出那种熟悉的、令人不安的气味——技术债务的复利正在累积。这让我意识到一件事SDD 能保证「代码是否忠实实现了规格中的功能描述」但它无法保证「代码在跨模块、跨迭代中保持一致的架构风格」。规格说明可以告诉 AI「要做什么」却无法约束「怎么做」。当多个 Agent 并行工作、codebase 规模扩大时缺乏统一骨架的代码库会迅速劣化。二、SDD 的四个边界我后来复盘把 SDD 的盲区归纳成四个边界。这些边界不是 SDD 的设计缺陷而是它的能力半径。边界一对齐意图但不兜底结构这是最根本的边界。SDD 解决的是「需求 ↔ 代码」之间的对齐问题。只要代码实现了 Spec 里描述的功能SDD 的任务就算完成了。但它不关心• 第 1 个 Agent 生成的模块和第 20 个 Agent 生成的模块是否在架构风格上一致• 跨模块的数据流是否符合统一的领域模型• 新增功能是否复用了已有的领域逻辑还是重复造了轮子• 代码库在长期迭代中是否保持了可维护的拓扑结构类比来说SDD 像是建筑图纸上的「功能布局图」哪里是卧室、哪里是厨房但它不是「结构工程图」承重墙在哪里、地基怎么打。功能布局图可以告诉施工队「这个房间要放一张床」但不会告诉施工队「楼板钢筋应该怎么配」。边界二规格写到多细是个悖论你可能以为规格写得越细AI 的发挥就越稳定。但实际情况是当你试图把「用户下单」这个需求的所有歧义都消灭时你的规格已经膨胀到了 3000 字——包含了状态机、异常分支、数据校验规则、回调时序。这已经不是规格这是披着自然语言外衣的伪代码。Agent 拿到这份「超级规格」后completion 率反而下降了。SWE-AGI Benchmark 验证了这个悖论规格强度增加到某个阈值后AI 的完成率会出现边际递减——因为过长的规格本身就成了新的认知负担Agent 的上下文窗口被规格淹没留给「思考如何实现」的带宽所剩无几。于是你陷入两难•写粗了AI 自由发挥各模块风格不一•写细了规格变成伪代码失去「What vs How」分离的意义AI 还被压垮这意味着靠「把规格写得更细」来兜底代码结构本身就是一条死路。边界三代码阅读瓶颈大于代码生成瓶颈这是最容易被低估的边界。随着 codebase 增长AI Agent 的瓶颈从「生成代码」转向「理解已有代码」。SDD 只管「新功能怎么生」不管「旧代码怎么被理解」。如果代码库没有稳定的结构每次 Agent 介入都需要重新学习一堆碎片化、风格不一的代码。Agent 的上下文窗口被大量「这是啥这怎么工作的」占据留给「我要怎么实现新需求」的带宽就所剩无几。这恰恰是「Agent 烧脑」的技术根因之一——不是 AI 不够强是代码库的结构不够友好导致 AI 把大部分算力花在了「阅读理解」上。边界四多 Agent 的隐性假设冲突这是最隐蔽的边界。即使所有 Agent 共享同一份 Spec不同 Agent 在实现同一服务的不同方法时仍可能对内部状态结构做出不同假设Agent A 认为构造函数返回的是 List of TupleAgent B 认为同一个字段是 Dict of Entity。两者单独看都「符合规格」但集成时会结构性崩溃。这种specification gap是 SDD 单点流程无法解决的——它需要的是代码层面的结构约定。三、关键洞察横向对齐 vs 纵向稳定把上述四个边界放在一起看我意识到 SDD 本质上是一个横向层。它解决的是「从需求到实现」这条水平线上的对齐问题Constitution架构宪法↓Specification需求规格↓Plan技术规划↓Tasks可执行任务↓Implement代码实现↓Validate验证这条链路确保了「意图不被扭曲」。但它没有回答一个问题实现之后的代码在垂直方向上如何保持结构稳定代码库的健康度不仅取决于「每一行代码是否实现了正确的功能」还取决于• 不同模块之间是否有统一的领域模型• 业务逻辑是否被正确地分层和隔离• 查询和命令是否被合理地分离• 新增代码是否自然地嵌入已有架构而不是打补丁这需要一个纵向层从战略设计到战术设计从领域边界到代码骨架从接口契约到实现填充。SDD 负责横向对齐DDD CQRS 负责纵向稳定。两者不是竞争关系而是互补的两极。四、解法上篇DDD 提供领域骨架在 AI Coding 之前DDD领域驱动设计是个「高手专属」的方法论。它要求架构师对业务有深刻理解同时熟练掌握 DDD 的各种概念和模式。但在 AI Coding 环境下DDD 的门槛被大幅降低了——你可以把业务人员的调研内容直接喂给 AI让它辅助输出战略设计和战术设计。更重要的是DDD 给 AI 提供了「领域层面的确定性」。战略设计划定边界战略设计的核心是限界上下文Bounded Context。它明确了• 哪里是核心域哪里是支撑域• 不同业务模块之间的边界在哪里• 跨上下文的集成方式是什么这相当于给 AI 画了一张「行政区划图」。当 Agent 接到一个新需求时它首先知道「这个功能属于哪个上下文」不会把用户逻辑写到订单里也不会把支付逻辑泄漏到库存中。战术设计统一结构战术设计深入到每一个具体需求的实现层面。它规定了• 聚合根Aggregate Root是什么• 实体Entity和值对象Value Object怎么区分• 领域服务Domain Service和应用服务Application Service的边界在哪里• 统一语言Ubiquitous Language贯穿规格、代码和对话这相当于给 AI 提供了一套「建筑规范」。Agent 不再自由发挥而是在既定的结构里填充内容。五、解法下篇CQRS 提供代码容器如果说 DDD 提供了「领域层面的骨架」那么 CQRS 提供了「代码层面的容器」。CQRSCommand Query Responsibility Segregation在 AI Coding 下的价值被放大了因为它给 AI 提供了一个高度可预测的「填充模板」。Command命令定义↓Command Handler业务处理↓Application Layer应用层编排↓Domain Layer领域逻辑↓Entity / Aggregate实体/聚合↓Repository仓储接口↓Unit of Work工作单元↓Infrastructure基础设施实现对 AI 来说这不是一个抽象概念而是一个「每次收到需求都知道往哪里填代码」的确定性结构。• 读需求 → 提取 Command → 写 Handler → 调用 Domain Service → 持久化到 Repository• 查询需求 → 绕过 Domain 层 → 直接用 SQL/DTO 拼接 → 返回 Read Model这种「骨架固定、血肉可变」的模式极大提升了 AI 在大型 codebase 中的输出稳定性。因为骨架是固定的Agent 不需要猜测「这段逻辑应该放在哪里」。它只需要判断「这是一个命令还是一个查询」然后沿着既定的层次结构填充即可。同时Repository 层天然适合 TDD测试驱动开发。你可以先写测试让 AI 实现 Repository 接口再验证行为。这进一步提高了代码质量的确定性。六、我们的实践时间分配与流水线的转变在我们的团队里这套方法论带来了两个显著变化。变化一从「随意指挥」到「骨架先行」以前产品经理丢一个需求过来我们直接把它喂给 Agent「实现一个用户注册功能。」Agent 自由发挥代码能跑但结构各异。现在我们的流水线是1. 从原始需求中提炼信息形成文档2. 将文档交给 AI输出 DDD 的战略和战术设计3. 基于设计文档让 AI 按照 CQRS 的结构进行编码和测试4. 人工审查集中在「设计是否正确」和「骨架是否健康」Agent 不再从零开始创造结构而是在既定的骨架内填充领域逻辑。变化二时间分配的根本反转我们做了一个粗略的统计•60% – 80%的时间花在需求和设计的 Review 上•20% – 40%的实现和自动化测试工作交给 AI这意味着人类的核心价值不再是「写代码」而是「定义结构」和「判断结构是否健康」。虽然在 AI Coding 时代你不需要了解每一个方法实现的细节但你必须对整个代码的骨架层次、领域边界、模块拓扑有清晰判断。只有这样才能持续保障代码库处于一个相对健康的状态。七、结论AI Coding 的完整公式回到文章开头的问题SDD 是不是 AI Coding 的终极答案我的回答是SDD 是必要非充分条件。没有 SDDAI 编程就是高级的 vibe coding——需求漂移、上下文丢失、Agent 各行其是。但只有 SDD没有结构层兜底codebase 会在 3–6 个月内劣化到难以维护。Matt Pocock 警告过「specs-to-code 是在撤资系统设计」。我的进一步判断是SDD 本身不是撤资SDD 被误用为「替代架构」时才是撤资。正确的用法是把 SDD 当作「意图层的基础设施」同时在下方铺设 DDD/CQRS 的「结构层地基」。最终AI Coding 的完整公式可以写成SDD 保证「做的对」→ 功能符合需求DDD/CQRS 保证「做的稳」→ 代码库不劣化、可维护、可扩展或者更简洁地说骨架稳定 血肉自动生成。在这个范式下人类负责不可压缩的复杂性——领域边界、战略设计、接口契约。AI 负责可自动化的复杂性——CRUD、boilerplate、测试桩。2026 年的 AI 编程所有人都在比拼「生成速度」但真正的高手在比拼另一件事谁能在闪电般的产出中保持代码库的长期健康。速度是廉价的。结构才是杠杆。你正在用 AI 写代码吗你的代码库是越写越健康还是越写越改不动如果你也踩过「AI 写得快、改不动」的坑欢迎聊聊你的真实经历和应对方法。本文方法论基于团队真实实践相关技术背景可参阅《领域驱动设计》《实现领域驱动设计》及 GitHub Spec Kit 官方文档。