这是什么

我们注意到一个反复出现的现象：AI 编程工具（Cursor、Copilot、各类 Agent）让代码产出翻了几倍，但用 AI 写的项目平均三个月后进入'谁也不敢动'状态——改一处崩三处。原因不是 AI 不够聪明，是它不维护项目结构。

工程师社区正在重新讨论一个 20 年前就提出的方法：领域驱动设计（DDD，核心思路是按业务边界划分代码）。具体做法是给每类业务划'房间'——用户管理、Agent、对话、知识库各自独立，需要协作时通过明确的接口调用，而不是直接互相改对方的数据。

这事被重新翻出来，是因为 AI 有一个很典型的倾向：既然这里能直接调别的模块的数据，那就顺手改了。一次看不出问题，几十次后整个项目就变成工程界说的'大泥球'——文件很多，谁负责什么完全说不清。

行业怎么看

支持的一方认为，DDD 的'限界上下文'（bounded context，可以理解成'每类业务代码允许活动的范围'）正好对症：AI 接到新任务时只在对应的小范围内搜索和修改，把一个全局问题变成局部问题。统一业务词汇也很关键——项目里叫 Agent 就不要今天叫 Bot、明天叫 Assistant，否则 AI 自己也搞混。

反对意见也不少。一派认为 DDD 本身概念多、规则细，对中小团队是负担，学完可能比写代码还累。另一派更激进的看法是：这是 AI 编程工具厂商的责任——Cursor、Copilot 这些产品应该内置项目结构感知，而不是甩一套 20 年前的设计方法让用户学。还有一种冷静的声音：现在很多 AI 项目根本活不到'维护阶段'就放弃了，DDD 解决的是一个还不存在的问题。

对普通人的影响

对 企业 IT：让团队大规模用 AI 写代码的公司，建议在项目早期就预留 30-50% 时间做架构治理，否则开发越快、技术债堆得越快，未来重构成本越高。

对 个人职场：程序员的核心能力正在从'写代码'转向'设计边界'，这反而让资深工程师更值钱；刚入行的新人需要补一门'系统设计'课，否则只能写局部代码。

对 消费市场：短期影响不大，但越来越多 AI 写出来的产品上线后会频繁出 bug、经常需要重构，用户会逐渐感受到'这产品怎么老崩'。