当前位置：首页 > news >正文

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

news 2026/5/4 1:33:18

AI 写代码的速度正在突破人类理解的边界。

一个需求丢给 Agent，几分钟内产出几百行代码；三个 Agent 并行，一天能堆出一个模块；Cloud Code 协作下，团队的交付量翻了两三倍。看起来，我们正站在软件工程史上最幸福的时代。

但真相是：AI 写代码越快，你的代码库死得越快。

问题不会在第 1 天暴露，甚至不会在第 10 天暴露。它像一种慢性病，等你闻到代码库腐烂的气味时，技术债务已经复利滚到了无法收拾的地步。

2026 年，主流叙事给出的解药是 SDD（Spec-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 Tuple，Agent 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 提供了「代码层面的容器」。

CQRS（Command 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 不再从零开始创造结构，而是在既定的骨架内填充领域逻辑。