架构设计提示词：让 AI 当架构师

AI 能当架构师吗

不能。但它可以当一个非常好的架构助手。

架构设计需要对业务的深度理解、对技术的全面把握、对团队的了解——这些 AI 做不到。但 AI 擅长的是：

1. 快速生成架构方案的初稿
2. 系统性地列出技术选型的对比维度
3. 帮你检查架构设计中的遗漏
4. 生成规范的设计文档
5. 从不同角度挑战你的设计决策

我们来看一套架构设计场景的提示词。

---

提示词 1：系统设计

你是一个资深系统架构师。请根据以下需求设计系统架构。

业务需求：
[详细描述业务需求]

非功能需求：
- 用户规模：[DAU/MAU]
- 性能要求：[响应时间、吞吐量]
- 可用性要求：[SLA]
- 数据量：[存储量、增长速度]
- 安全要求：[合规、加密]

约束条件：
- 团队规模：[人数和技术背景]
- 预算：[范围]
- 时间：[上线时间]
- 现有基础设施：[描述]

请输出：
1. 架构概览图（文本描述）
2. 核心组件和职责
3. 数据流设计
4. 技术选型和理由
5. 扩展性设计
6. 风险和应对方案

实际示例

业务需求：
设计一个实时协作文档编辑系统（类似 Google Docs），支持：
- 多人同时编辑同一文档
- 实时看到其他人的光标和编辑
- 离线编辑，上线后自动同步
- 文档版本历史
- 评论和批注

非功能需求：
- DAU：10 万
- 同时在线编辑同一文档：最多 50 人
- 编辑延迟：< 200ms
- 可用性：99.9%
- 文档数量：1000 万

AI 输出：

## 架构概览

客户端（Web/Mobile） ↕ WebSocket 负载均衡（Nginx/ALB） ↕ 协作服务层 ├── WebSocket Gateway（连接管理） ├── CRDT Engine（冲突解决） ├── Presence Service（在线状态） └── Sync Service（同步服务） ↕ 数据层 ├── PostgreSQL（文档元数据、用户） ├── Redis（在线状态、会话） ├── S3（文档内容存储） └── Kafka（事件流）

## 核心组件

### 1. CRDT Engine
选择 CRDT（Conflict-free Replicated Data Type）而非 OT（Operational Transformation）：
- CRDT 不需要中心服务器协调，天然支持离线编辑
- 实现复杂度低于 OT
- 推荐使用 Yjs 库

### 2. WebSocket Gateway
- 管理客户端连接
- 广播编辑操作给同一文档的其他用户
- 使用 Redis Pub/Sub 实现跨节点广播

### 3. Sync Service
- 定期将 CRDT 状态持久化到 S3
- 处理离线客户端的同步
- 生成文档快照（用于版本历史）

## 数据流

编辑操作流程：
1. 用户在客户端编辑 → 本地 CRDT 更新
2. 通过 WebSocket 发送操作到 Gateway
3. Gateway 广播给同文档的其他客户端
4. 其他客户端的 CRDT 合并操作
5. 异步：Sync Service 持久化到 S3

## 扩展性设计

- WebSocket Gateway：按文档 ID 分片，同一文档的连接路由到同一节点
- 数据库：读写分离，文档内容存 S3 避免数据库压力
- 水平扩展：Gateway 无状态（状态在 Redis），可以随意加节点

---

提示词 2：技术选型

请帮我做技术选型分析。

选型场景：
[描述需要选型的场景]

候选方案：
- 方案 A：[描述]
- 方案 B：[描述]
- 方案 C：[描述]（可选）

评估维度：
1. 功能满足度
2. 性能
3. 学习成本
4. 社区活跃度和生态
5. 运维复杂度
6. 成本
7. 长期可维护性

团队背景：
[团队的技术栈和经验]

请输出：
1. 多维度对比表格
2. 每个方案的优缺点分析
3. 推荐方案和理由
4. 迁移成本评估（如果是替换现有方案）

输出示例

选型场景：消息队列选型

| 维度 | RabbitMQ | Kafka | Redis Streams |
|------|----------|-------|---------------|
| 吞吐量 | 中（万级/秒） | 高（百万级/秒） | 中高（十万级/秒） |
| 延迟 | 低（毫秒级） | 中（毫秒-十毫秒） | 低（毫秒级） |
| 消息持久化 | 支持 | 支持（强） | 支持（弱） |
| 消息顺序 | 队列内有序 | 分区内有序 | 有序 |
| 消费模式 | Push + Pull | Pull | Pull |
| 死信队列 | 原生支持 | 需自建 | 需自建 |
| 运维复杂度 | 中 | 高 | 低 |
| 学习成本 | 中 | 高 | 低 |
| 适用场景 | 任务队列、RPC | 日志、事件流 | 轻量级消息 |

推荐：
- 如果是任务队列（如异步邮件发送）→ RabbitMQ
- 如果是事件流（如日志收集、数据管道）→ Kafka
- 如果已有 Redis 且消息量不大 → Redis Streams

你们团队已经在用 Redis，且消息量预估在每秒 1000 条以内，
推荐先用 Redis Streams，后续如果消息量增长再迁移到 Kafka。

---

提示词 3：架构评审

请对以下架构设计进行评审。

架构描述：
[架构图和说明]

业务场景：
[业务需求]

请从以下维度评审：
1. 功能完整性：是否满足所有业务需求？
2. 可扩展性：能否应对 10 倍增长？
3. 可靠性：单点故障在哪里？容灾方案？
4. 安全性：数据安全、访问控制
5. 可维护性：是否过度设计？团队能否维护？
6. 成本：是否有更经济的方案？

输出格式：
对每个维度给出评分（1-5）和具体建议。
最后给出整体评价和 Top 3 改进建议。

评审输出示例

架构评审报告

| 维度 | 评分 | 说明 |
|------|------|------|
| 功能完整性 | 4/5 | 缺少离线支持的详细设计 |
| 可扩展性 | 4/5 | WebSocket 分片策略合理，但缺少数据库分片方案 |
| 可靠性 | 3/5 | Redis 是单点，需要集群化 |
| 安全性 | 3/5 | 缺少文档级别的访问控制设计 |
| 可维护性 | 4/5 | 组件职责清晰，但 CRDT 实现复杂度需要评估 |
| 成本 | 4/5 | 合理，S3 存储成本低 |

Top 3 改进建议：
1. Redis 改为集群模式，避免单点故障
2. 添加文档级别的 ACL（访问控制列表）设计
3. 添加 CRDT 状态的定期压缩机制，避免历史操作无限增长

---

提示词 4：设计文档生成

请根据以下架构设计，生成正式的技术设计文档。

架构信息：
[架构描述]

文档模板：
1. 概述
   - 背景和目标
   - 范围
   - 术语表
2. 架构设计
   - 系统架构图
   - 组件说明
   - 数据流
3. 详细设计
   - 数据模型
   - API 设计
   - 关键算法
4. 非功能设计
   - 性能
   - 安全
   - 可用性
   - 可观测性
5. 部署方案
6. 风险和缓解措施
7. 里程碑和排期

---

提示词 5：可扩展性分析

请分析以下系统的可扩展性，并给出扩展方案。

当前架构：
[架构描述]

当前规模：
- 用户数：[数量]
- QPS：[数量]
- 数据量：[大小]

目标规模（1 年后）：
- 用户数：[数量]
- QPS：[数量]
- 数据量：[大小]

请分析：
1. 当前架构能支撑到什么规模？
2. 哪些组件会先成为瓶颈？
3. 每个瓶颈的扩展方案
4. 扩展的优先级和时间线
5. 扩展的成本估算

输出示例

可扩展性分析

当前架构瓶颈预测：

| 组件 | 当前容量 | 瓶颈点 | 扩展方案 | 优先级 |
|------|---------|--------|---------|--------|
| 单机 PostgreSQL | 5000 QPS | 1 万 QPS | 读写分离 → 分库分表 | P0 |
| 单机 Redis | 10 万 QPS | 不是瓶颈 | Redis Cluster | P2 |
| API 服务 | 3000 QPS/实例 | 水平扩展即可 | 增加实例 + LB | P1 |
| 文件存储 | 1TB | 10TB | 已用 S3，无瓶颈 | P3 |

扩展路线图：

阶段 1（现在 → 3 个月）：
- PostgreSQL 读写分离
- API 服务扩展到 5 个实例
- 预估成本增加：$500/月

阶段 2（3 → 6 个月）：
- 引入缓存层（Redis 缓存热点数据）
- 数据库连接池优化
- 预估成本增加：$300/月

阶段 3（6 → 12 个月）：
- 数据库分库分表
- Redis Cluster
- 预估成本增加：$1000/月

---

提示词 6：Trade-off 分析

架构设计的核心是做 Trade-off。让 AI 帮你系统性地分析：

请分析以下架构决策的 Trade-off。

决策：[描述你面临的架构决策]

选项 A：[描述]
选项 B：[描述]

请从以下维度分析 Trade-off：
1. 一致性 vs 可用性（CAP）
2. 性能 vs 成本
3. 简单性 vs 灵活性
4. 开发速度 vs 技术债务
5. 自建 vs 购买/使用云服务

对每个维度，说明两个选项的取舍，并给出建议。

经典 Trade-off 场景

场景：微服务 vs 单体

| 维度 | 单体 | 微服务 |
|------|------|--------|
| 开发速度（初期） | 快 | 慢 |
| 开发速度（后期） | 慢 | 快 |
| 部署复杂度 | 低 | 高 |
| 团队独立性 | 低 | 高 |
| 运维成本 | 低 | 高 |
| 技术栈灵活性 | 低 | 高 |
| 数据一致性 | 简单 | 复杂 |
| 性能（服务间调用） | 无开销 | 有网络开销 |

建议：
- 团队 < 10 人，业务还在探索期 → 单体
- 团队 > 20 人，业务已稳定，需要独立迭代 → 微服务
- 折中方案：模块化单体（Modular Monolith）

---

提示词 7：架构决策记录（ADR）

请根据以下架构决策，生成 ADR（Architecture Decision Record）。

决策内容：
[描述做了什么决策]

背景：
[为什么需要做这个决策]

ADR 格式：
# ADR-[编号]: [标题]

## 状态
[提议/接受/废弃/替代]

## 背景
[问题描述和上下文]

## 决策
[做了什么决策]

## 理由
[为什么选择这个方案]

## 考虑过的替代方案
[其他方案及其被否决的原因]

## 后果
[这个决策带来的正面和负面影响]

ADR 示例

# ADR-007: 使用 PostgreSQL 替代 MongoDB 作为主数据库

## 状态
接受（2026-03-11）

## 背景
项目初期选择了 MongoDB 作为主数据库，因为 Schema-less 的特性方便快速迭代。
但随着业务发展，我们遇到了以下问题：
1. 数据关系越来越复杂，MongoDB 的 JOIN 性能差
2. 事务支持不够完善
3. 数据一致性问题频发

## 决策
将主数据库从 MongoDB 迁移到 PostgreSQL。

## 理由
1. 业务数据高度关系化，PostgreSQL 的 JOIN 性能远优于 MongoDB
2. PostgreSQL 的 ACID 事务支持完善
3. PostgreSQL 的 JSONB 类型可以满足少量 Schema-less 需求
4. 团队对 SQL 更熟悉

## 考虑过的替代方案
- MySQL：功能满足，但 PostgreSQL 的 JSONB 和扩展生态更好
- 保持 MongoDB + 添加 PostgreSQL：增加运维复杂度，不值得

## 后果
正面：
- 数据查询性能提升 3-5 倍
- 数据一致性问题消除
- 开发效率提升（SQL 比 MongoDB 查询语法更直观）

负面：
- 迁移需要 2-3 周开发时间
- 需要重写数据访问层
- 失去 Schema-less 的灵活性（用 JSONB 部分弥补）

---

架构设计检查清单

在提交架构设计之前，用这个提示词做最后检查：

请用以下检查清单审查我的架构设计：

架构设计：
[你的设计]

检查清单：
- [ ] 是否有单点故障？
- [ ] 数据库是否会成为瓶颈？
- [ ] 是否考虑了数据备份和恢复？
- [ ] 是否考虑了安全（认证、授权、加密）？
- [ ] 是否考虑了监控和告警？
- [ ] 是否考虑了日志和可观测性？
- [ ] 是否考虑了灰度发布和回滚？
- [ ] 是否过度设计？
- [ ] 团队是否有能力实现和维护？
- [ ] 成本是否在预算内？

---

总结

场景	提示词	核心价值
系统设计	提示词 1	快速生成架构初稿
技术选型	提示词 2	系统性对比分析
架构评审	提示词 3	多维度检查遗漏
设计文档	提示词 4	规范化文档输出
扩展性分析	提示词 5	预判瓶颈和规划
Trade-off	提示词 6	理性决策支持
ADR	提示词 7	决策记录和传承

架构设计没有标准答案，只有适合不适合。AI 帮你更快地探索方案空间、更系统地分析 Trade-off，但最终的决策还是要基于你对业务和团队的理解。

好的架构不是最先进的架构，而是最适合当前阶段的架构。用 AI 帮你看得更远、想得更全，但别忘了——最好的架构是能让团队高效交付的架构。