领域驱动 + AI 协同开发

7 阅读5分钟

核心立场:AI 不是银弹。AI 是“放大器”,不是“替代者”。在软件工程中,领域设计与关键决策必须掌握在开发者手中,AI 负责加速实现,而不是主导架构。


一、问题背景:为什么不能“直接把需求丢给 AI”

在实践中我们很容易发现:

  • 直接描述功能 → AI 自动生成代码
  • 初期开发速度极快

  • 但很快出现问题:

    • 代码结构混乱、隐含假设多(ai幻想)
    • 业务逻辑散落在各处
    • 只有 AI 自己“理解”这些代码
    • 人类维护成本反而更高

结论是:

如果 AI 决定了结构,那么这套代码最终只能由 AI 维护。

而在核心业务系统中,这是不可接受的。


二、核心原则:把精力从“写代码”转移到“做设计”

在 AI 助力下:

  1. 写代码 → 变得便宜
  2. 改代码 → 变得容易
  3. 设计错误 → 代价反而更大

因此核心策略是:

设计先行,AI 受约束实现。

开发者的角色发生转变:

过去的开发模式:

  • 开发者更像是 砌墙的工人
  • 按照 MVC、分层结构
  • 一块一块把代码“砌”进系统里
  • 更多关注的是:这一块怎么实现

新的开发模式(AI 时代):

  • 开发者更像是 建筑设计师

  • 负责画图纸、定结构、算受力

  • 要清楚:

    • 哪里是承重结构
    • 哪里是风险集中区
    • 哪些地方一旦出问题会影响整体
  • AI 是施工方:

    • 砌墙的工人
    • 喷漆的工人
    • 按图施工、加速实现

如果图纸是错的,施工再快,塌得也越快。

传统模式AI 协同模式
主要时间写代码主要时间做设计
代码即事实设计文档是事实

三、方法论基础:领域驱动设计(DDD)

DDD 在 AI 时代反而变得更重要,因为它提供了:

  • 稳定的业务抽象
  • 清晰的边界与职责
  • 天然适合作为 AI 的约束输入

在本方法中,我们重点关注:

  • 核心领域(Core Domain)
  • 领域模型(Entity / Value Object)
  • 领域行为(Domain Behavior)
  • 聚合与不变量

AI 不能随意突破这些结构。


四、维护 AI 记忆:关键实践

为什么要“维护 AI 记忆”

如果让 AI 每次通过“读代码”来理解系统:

  • Token 消耗大
  • 理解不稳定
  • 不同轮次结论可能不一致

解决方案:

让设计文档成为 AI 的唯一事实来源。


约束 AI 的工作方式

强制规则:

  • AI 修改任何代码时:

    • 必须同步修改相关设计文档
  • 设计文档 > 代码

  • 代码只是设计的实现

📄 这些文档本身就构成了 AI 的长期记忆载体。


带来的收益

  • AI 响应速度更快
  • 功能变更影响分析更准确
  • 减少“同一问题,不同答案”的情况

五、开发流程

与 ChatGPT:形成初始设计共识

目标:定方向、定边界、定约束

输出内容:

  • 项目目标
  • 核心业务假设
  • 非功能性约束(性能、并发、一致性等)
  • 架构边界与禁止事项

📄 产出物:项目约束文档(Project Constraints)


与 Claude:交叉验证与设计辩论

目标:挑战既有设计,避免思维盲区

做法:

  • 将 ChatGPT 的结论完整输入给 Claude

  • 重点讨论:

    • 设计是否过度 / 不足
    • 潜在的复杂度风险
    • 是否有更简洁的领域建模方式

📄 产出物:设计评审补充说明


分模块输出子模块设计文档

以 DDD 为核心,每个模块都需要明确:

  • 模块职责(Why)
  • 核心领域对象(What)
  • 领域行为与规则(How)
  • 对外依赖与边界(With whom)

📄 产出物:模块级设计文档(Design Doc)


按优先级分模块开发

原则:

  • 从核心领域开始
  • 非核心模块可以允许 AI 更自由
  • 核心模块必须强约束

开发方式:

  • 人提供:设计文档 + 约束
  • AI 输出:代码骨架 + 实现

单模块内代码审查(人类主导)

这是不可跳过的一步。

重点检查:

  • 是否违反领域边界
  • 是否出现隐式状态或副作用
  • 是否存在“为了实现而实现”的代码

这个过程的本质是:

训练 AI 逐渐接近你的代码风格与思维方式。


整体模块串联与系统级校验

最后一步关注:

  • 模块之间的调用是否符合最初设计
  • 是否出现跨领域的逻辑渗透
  • 是否需要重新划分边界

六、代码审查是必然的,而不是可选的

对 AI 开发保持“工程化怀疑”

AI 的代码特点:

  • 看起来合理
  • 实际可能隐藏问题
  • 对边界与极端情况不敏感

永远不要完全信任。


推荐的安全策略

  • 大改动前执行 Git Commit
  • 不满意 → 快速回滚
  • 每次 AI 修改后进行人工审查

长期收益

  • AI 的输出会逐渐贴近你的风格
  • 人类理解成本持续下降
  • 审查成本呈递减趋势

前期审得越细,后期付出的精力越小。


七、总结

领域驱动 + AI 并不是为了更快写代码,而是为了:

  • 更稳定的系统
  • 更可控的复杂度
  • 更低的长期维护成本

一句话总结:

人类负责“想清楚”,AI 负责“干得快”。