← Back to posts

Go项目架构选择：AI编程时代的思考

AI编程时代的架构选择：哪种更适合你

在AI辅助编程成为主流的今天，选择什么样的架构变得更重要了。AI生成的代码质量参差不齐，好的架构能让AI犯错时有迹可循，坏的架构会让AI的错误像病毒一样扩散。分享一下我的思考。

先说说AI编程的特点

AI擅长什么

  • 生成模板代码，比如CRUD操作
  • 补全重复性逻辑
  • 按照明确需求实现功能
  • 重构代码，优化结构

AI不擅长什么

  • 理解复杂的业务领域
  • 处理跨模块的依赖关系
  • 保证全局一致性
  • 做架构层面的权衡

这意味着：架构要能限制AI的影响范围，让错误不会扩散到整个系统。

三种架构在AI编程下的表现

分层架构

src/
├── models/        # AI生成数据模型
├── controllers/   # AI生成接口
├── services/      # AI生成业务逻辑
└── repositories/  # AI生成数据访问

AI编程体验

  • ✅ AI很熟悉这种结构，生成的代码质量高
  • ✅ 提示词简单：“写一个用户管理的service”
  • ✅ AI能快速生成完整的CRUD流程
  • ❌ AI容易在不同层之间产生不一致
  • ❌ 业务逻辑分散，AI难以维护全局规则
  • ❌ 改一个字段可能要改4个文件，AI容易漏改

实际案例

让AI修改用户状态逻辑：

我：把用户状态从active/inactive改成enabled/disabled/deleted

AI：好的，我改了model和service...

问题：忘了改controller的返回值和repository的查询条件

分层架构下，AI要同时维护多个文件的一致性，很容易出错。

模块化架构

src/
├── user/
│   ├── model.go
│   ├── service.go
│   ├── repository.go
│   └── handler.go
└── order/
    ├── model.go
    ├── service.go
    ├── repository.go
    └── handler.go

AI编程体验

  • ✅ 模块内聚，AI可以独立处理每个模块
  • ✅ 提示词更清晰：“在user模块里添加登录功能”
  • ✅ AI的影响范围被限制在单个模块
  • ✅ 模块间通过接口交互，AI不需要理解全局
  • ❌ 模块间依赖关系，AI可能理解错误
  • ❌ 跨模块的功能，AI需要人工指导

实际案例

让AI在user模块添加功能：

我：在user模块添加用户积分功能

AI：好的，我在user/model.go添加了积分字段，
    在user/service.go添加了积分计算逻辑...

成功：所有改动都在user目录下，AI没有漏掉任何地方

模块化架构下，AI的工作范围明确，出错概率低。

DDD架构

src/
├── domain/              # 领域层：AI需要理解业务
│   ├── user/entity.go
│   └── order/entity.go
├── infrastructure/      # 基础设施：AI生成技术代码
│   └── persistence/
├── application/         # 应用层：AI编排用例
│   └── service/
└── interface/           # 接口层：AI生成API
    └── http/

AI编程体验

  • ✅ 业务逻辑集中在领域层，AI不容易散乱
  • ✅ 充血模型让AI把行为和数据放在一起
  • ✅ 技术代码和业务代码分离，AI可以分而治之
  • ❌ AI很难理解领域驱动设计的概念
  • ❌ 需要大量提示词教育AI什么是领域模型
  • ❌ 实体、值对象、聚合等概念，AI经常用错

实际案例

让AI实现业务规则：

我：订单金额超过1000元需要审批

AI（分层架构）：我在service里加个判断...
   问题：其他地方也可能创建订单，这个规则会被绕过

AI（DDD架构）：我在Order实体里加CanApprove()方法...
   成功：所有创建订单的地方都要经过实体，规则不会被绕过

DDD架构下，业务规则集中，但需要教育AI理解充血模型。

哪种架构更适合AI编程

模块化架构最推荐

原因

  1. 边界清晰：AI的工作范围被限制在单个模块，不会到处乱改
  2. 上下文集中：相关代码都在一个目录，AI更容易理解
  3. 独立性强：每个模块可以单独让AI处理，互不干扰
  4. 易于review：改动集中在一个模块，人工review效率高

最佳实践

让AI工作在模块级别：

"在payment模块添加退款功能"
"在notification模块添加短信发送"
"在user模块修改密码加密方式"

而不是：

"修改系统中的密码逻辑"（AI不知道要改哪些文件）

DDD架构需要更多指导

什么时候用

  • 业务规则复杂且重要
  • 愿意花时间教育AI
  • 有能力review AI的领域模型

如何让AI更好工作

提示词示例：

这是一个DDD项目。请遵循以下规则：
1. 业务逻辑必须在实体内部，不要写在service
2. 实体要有行为方法，不要只有getter/setter
3. 改业务规则时，先改domain层

现在请在Order实体里添加退款逻辑...

分层架构适合快速原型

什么时候用

  • 快速验证想法
  • AI生成一次性代码
  • 后续会重构

注意事项

  • 让AI一次生成完整的CRUD，不要分步骤
  • 改动时让AI改所有相关文件，并明确列出文件名
  • 定期review，防止不一致性积累

AI编程的架构原则

无论选哪种架构，在AI编程时代都要遵循：

1. 高内聚低耦合

AI理解模块边界比理解分散代码容易得多。

2. 明确的依赖方向

单向依赖让AI知道代码应该往哪里写。

3. 一致的命名规范

AI依赖上下文，一致的命名能让AI推断出正确的模式。

4. 最小化跨模块依赖

AI处理跨模块逻辑时容易出错，尽量让模块独立。

5. 清晰的接口边界

通过接口隔离模块，AI只需要知道接口，不需要知道实现。

实战建议

小项目（< 5人）

推荐：分层架构

  • AI生成快
  • 结构简单
  • 后期可以重构

中型项目（5-20人）

推荐：模块化架构

  • AI可以按模块工作
  • 改动范围可控
  • 易于团队协作

大型项目（> 20人）

推荐：模块化 + 部分DDD

  • 核心业务用DDD，保护关键逻辑
  • 周边功能用模块化，提高效率
  • 让AI处理技术代码，人处理领域模型

几个AI编程的坑

让AI改架构

AI适合改代码，不适合改架构。架构决策要人来定，AI来执行。

过度依赖AI生成

AI生成的代码要review，特别是跨模块的依赖。

不给AI足够的上下文

“添加登录功能” vs “在user模块添加基于JWT的登录功能”，后者效果更好。

忽略测试

AI生成的代码更容易有bug，测试是必须的，最好也让AI生成测试。

总结

在AI编程时代，模块化架构是最佳选择：

  • 边界清晰，AI不会乱改
  • 上下文集中，AI容易理解
  • 独立性强，易于并行开发
  • Review效率高，改动可追溯

如果你正在用AI辅助编程，建议从模块化架构开始。它既不像分层架构那样散乱，也不像DDD那样复杂，是AI编程的最佳平衡点。

有问题欢迎讨论。