AI 架构设计：如何避免一上来就把项目做复杂

很多人让 AI 做架构设计，最后会得到一个非常"豪华"的方案：

• 微服务。
• 消息队列。
• Redis 缓存。
• Kubernetes。
• 领域驱动设计。
• 监控告警。
• 多环境 CI/CD。

这些东西不一定错，但对一个第一版产品来说，可能太重了。

架构设计不是把所有高级名词堆上去，而是用合适的结构支撑当前目标，并给未来留一点余地。

AI 可以帮你做架构设计，但你要会约束它。

架构设计要回答什么

对大多数小项目来说，架构设计先回答 7 个问题就够了：

• 前端怎么组织？
• 后端怎么组织？
• 数据怎么存？
• 权限怎么做？
• 接口怎么定义？
• 测试怎么覆盖？
• 第一版怎么部署？

不要一开始就问"请给我一个高并发架构"。

更好的问法是：

基于上面的 MVP 需求，请设计一个第一版可落地的技术架构。
要求：
1. 优先简单可维护
2. 不要过度设计
3. 说明为什么选择这个方案
4. 列出未来扩展点
5. 输出目录结构、数据模型、接口清单和部署方式

这句话的重点是"第一版可落地"。

第一步：让 AI 给出 2-3 个方案，而不是一个答案

架构设计不是标准题。

你可以让 AI 先比较方案：

请给出 3 个架构方案：
1. 最简单方案
2. 中等复杂度方案
3. 适合团队协作的方案

请从开发成本、维护成本、扩展能力、部署难度、适用阶段进行比较。
最后推荐一个方案。

比如一个个人记账 App，AI 可能给出：

• 本地优先方案：前端 + 浏览器本地存储。
• 单体 Web 方案：Next.js + SQLite/PostgreSQL。
• 前后端分离方案：React + API 服务 + PostgreSQL。

如果只是验证需求，本地优先可能就够了。

如果需要账号和云同步，单体 Web 方案更稳。

如果有多人团队和复杂业务，再考虑前后端分离。

第二步：限制技术栈选择

AI 很容易推荐它熟悉但你团队不熟的技术。

所以你要明确约束：

我们的团队熟悉：
- 前端：React + TypeScript
- 后端：Node.js
- 数据库：PostgreSQL
- 部署：Docker + 单台云服务器

请在这些技术范围内设计架构。
除非必要，不要引入新技术。

这句话很重要。

技术选型不是"哪个更先进"，而是"团队能不能稳定交付和维护"。

AI 不知道你的团队能力，除非你告诉它。

第三步：让 AI 输出目录结构

架构设计不能只停留在概念。

你可以要求：

请输出推荐目录结构。
要求：
1. 只包含第一版需要的目录
2. 每个目录说明职责
3. 不要为了未来可能性创建过多抽象层

例如：

src/
  app/              页面和路由
  components/       可复用 UI 组件
  features/         按业务功能组织代码
  lib/              通用工具
  server/           服务端逻辑
  tests/            测试辅助代码

目录结构的意义不是好看，而是让后续开发有地方放代码。

如果目录设计太复杂，AI 后面改代码时也会迷路。

第四步：让 AI 定义接口和数据模型

进入代码前，至少要有接口草案。

提示词：

请基于推荐架构，输出第一版接口清单和数据模型。
要求：
1. 接口包含方法、路径、请求参数、响应字段
2. 数据模型包含字段、类型、必填、索引建议
3. 标注哪些设计是为了 MVP，哪些是为未来扩展预留

比如：

POST /api/transactions
GET /api/transactions?month=2026-05
PATCH /api/transactions/:id
DELETE /api/transactions/:id
GET /api/statistics/monthly?month=2026-05

这些接口后面可以直接进入开发任务拆分。

第五步：让 AI 做风险评估

好的架构设计不是只讲优点，还要讲风险。

可以这样问：

请审查这个架构方案。
重点指出：
1. 可能过度设计的地方
2. 第一版可能遗漏的关键风险
3. 未来扩展时最可能重构的部分
4. 哪些地方需要测试保护

AI 可能指出：

• 如果一开始不做登录，后面加云同步会改数据归属。
• 如果金额用浮点数，后面会有精度问题。
• 如果分类删除规则不明确，历史统计会出错。
• 如果统计逻辑只在前端做，后面多端同步会不一致。

这些就是架构阶段最有价值的输出。

小项目也需要架构，但不需要大架构

架构不是大公司的专利。

小项目同样需要基本结构，否则 AI 生成的代码会越来越散。

但小项目不需要一开始就上复杂架构。你真正需要的是：

• 能跑起来。
• 能测。
• 能改。
• 能部署。
• 未来不至于完全推倒。

这就是第一版架构的合格标准。

一个完整提示词模板

下面是当前 MVP 需求：
<粘贴需求分析结果>

请帮我做第一版架构设计。

要求：
1. 给出 2-3 个可选方案并比较
2. 推荐一个最适合第一版的方案
3. 输出技术栈选择和理由
4. 输出目录结构
5. 输出核心数据模型
6. 输出接口清单
7. 输出测试策略
8. 输出部署方式
9. 指出过度设计风险和未来扩展点

约束：
- 优先简单、可维护、可验证
- 不要引入团队不熟悉的技术
- 不要为了未来功能提前做复杂抽象

最后

AI 很擅长生成架构方案，但它不知道你的资源、阶段和团队能力。

所以你要给它约束：第一版、MVP、可验证、不要过度设计。

好的 AI 架构设计，不是看起来多高级，而是能让接下来的代码开发更顺，让测试和部署有明确路径。

下一篇我会写：如何让 AI 参与代码开发，重点讲"小步修改、看 diff、跑测试"的真实工作流。

先简单、可维护、可验证

• 不要引入团队不熟悉的技术
• 不要为了未来功能提前做复杂抽象

最后

AI 很擅长生成架构方案，但它不知道你的资源、阶段和团队能力。

所以你要给它约束：第一版、MVP、可验证、不要过度设计。

好的 AI 架构设计，不是看起来多高级，而是能让接下来的代码开发更顺，让测试和部署有明确路径。

下一篇我会写：如何让 AI 参与代码开发，重点讲"小步修改、看 diff、跑测试"的真实工作流。