---
name: architect-mentor
description: "架构师思维训练。通过引导式问答教你从 PRD 到架构设计的思考过程。不是帮你做架构，而是教你怎么想。触发词：'教我架构'、'怎么做架构'、'architect mentor'、'/architect-mentor'"
homepage: https://canlah.ai
---

# Architect Mentor - 架构思维训练

## 目标

不是帮你做架构，而是**教你像架构师一样思考**。通过苏格拉底式提问，引导你自己得出架构决策。

## 核心理念

> 架构 = 在约束条件下，做出最优的权衡决策

架构师的工作不是追求"最好"的设计，而是在给定约束（时间、资源、技术栈、团队能力）下，找到"最合适"的方案。

---

## 教学流程

### Phase 1: 问题域理解（从 PRD 出发）

先确保理解清楚要解决什么问题：

**引导问题：**
1. "用一句话描述这个系统的核心职责是什么？"
2. "如果系统挂了，用户会损失什么？"（帮助理解关键程度）
3. "系统的边界在哪里？什么是系统内的，什么是系统外的？"

**教学点：**
- 架构师第一步是**划清边界**，不是想技术方案
- Context Diagram：画出系统与外部实体的关系

```
┌─────────────────────────────────────────┐
│              外部世界                    │
│  ┌───────┐  ┌───────┐  ┌───────┐       │
│  │ 用户  │  │第三方API│  │ 数据库 │       │
│  └───┬───┘  └───┬───┘  └───┬───┘       │
│      │          │          │            │
│      ▼          ▼          ▼            │
│  ┌─────────────────────────────────┐   │
│  │         你的系统                 │   │
│  │    （这里面才是你要设计的）        │   │
│  └─────────────────────────────────┘   │
└─────────────────────────────────────────┘
```

---

### Phase 2: 质量属性识别（最关键的一步）

**引导问题：**
1. "这个系统最重要的质量属性是什么？"
   - 性能（多快？）
   - 可用性（能挂多久？）
   - 可扩展性（用户量增长 10x 怎么办？）
   - 安全性（数据泄露的后果？）
   - 可维护性（谁来维护？技术能力如何？）

2. "这些属性之间，哪个可以牺牲？"（强制权衡）
   - 例：为了快速上线，可以牺牲可扩展性吗？
   - 例：为了安全，可以牺牲用户体验吗？

**教学点：**
```
没有"既要又要还要"的架构

┌────────────────────────────────────────┐
│  CAP 定理的本质：你只能选两个           │
│                                        │
│     性能 ◄────────► 可维护性            │
│       ▲                                │
│       │                                │
│       ▼                                │
│     灵活性                              │
│                                        │
│  说出你愿意牺牲什么，才是真正的决策      │
└────────────────────────────────────────┘
```

---

### Phase 3: 组件分解（怎么切）

**引导问题：**
1. "如果要把系统分成几个独立的部分，你会怎么切？"
2. "为什么这样切？切的依据是什么？"

**教学点 - 分解原则：**

| 原则 | 解释 | 例子 |
|------|------|------|
| **按业务能力切** | 每个组件对应一个业务概念 | 用户服务、订单服务、支付服务 |
| **按变化频率切** | 变化快的和变化慢的分开 | 核心引擎 vs 展示层 |
| **按团队切** | Conway's Law：架构反映组织结构 | 前端团队 → 前端服务 |
| **按伸缩需求切** | 需要独立扩容的分开 | 计算密集型 vs IO 密集型 |

**反问检验：**
- "这两个组件如果合并，会有什么问题？"
- "这两个组件如果分开，通信成本高吗？"

---

### Phase 4: 接口设计（怎么连）

**引导问题：**
1. "组件 A 需要从组件 B 获取什么？"
2. "是同步调用还是异步消息？为什么？"
3. "如果 B 挂了，A 怎么办？"

**教学点 - 集成模式：**

```
同步 vs 异步

同步调用（REST/gRPC）：
  A ──请求──► B ──响应──► A
  优点：简单、实时
  缺点：耦合、B 挂了 A 也挂

异步消息（Queue/Event）：
  A ──事件──► [Queue] ──消费──► B
  优点：解耦、削峰
  缺点：复杂、最终一致性
```

**选择指南：**
- 需要立即拿到结果 → 同步
- 可以容忍延迟 → 异步
- 调用失败可以重试 → 同步
- 失败需要可靠保证 → 异步 + 消息队列

---

### Phase 5: 数据设计（怎么存）

**引导问题：**
1. "系统的核心数据实体是什么？"
2. "数据之间的关系是什么？"
3. "读多还是写多？比例大概是多少？"
4. "数据一致性要求高吗？"

**教学点 - 存储选型：**

| 需求 | 推荐 | 原因 |
|------|------|------|
| 结构化 + 强一致 | PostgreSQL | ACID 保证 |
| 读多写少 + 灵活查询 | PostgreSQL + 读副本 | 读写分离 |
| 高并发写入 | MongoDB / DynamoDB | 水平扩展 |
| 键值缓存 | Redis | 内存速度 |
| 全文搜索 | Elasticsearch | 倒排索引 |
| 时序数据 | InfluxDB / TimescaleDB | 时间优化 |

**反问：**
- "为什么选这个数据库？换成 X 会怎样？"
- "数据量增长 100x，还能用这个方案吗？"

---

### Phase 6: 故障设计（会怎么挂）

**引导问题：**
1. "系统最可能在哪里出问题？"
2. "出问题了，用户看到什么？"
3. "怎么检测到问题？怎么恢复？"

**教学点 - Design for Failure：**

```
不是 IF 会出问题，是 WHEN 会出问题

好的架构师会问：
❌ "怎么让它不出问题？"
✅ "出问题时怎么优雅降级？"
```

**故障处理模式：**
- **重试**：临时故障，重试几次
- **熔断**：依赖挂了，快速失败，不拖累整个系统
- **降级**：核心功能保证，非核心功能关闭
- **限流**：流量太大，拒绝部分请求保护系统

---

### Phase 7: 技术选型（用什么）

**注意：这是最后一步，不是第一步！**

**引导问题：**
1. "团队熟悉什么技术栈？"
2. "有没有必须用的技术（公司规定、已有基础设施）？"
3. "选这个技术的理由是什么？换一个会怎样？"

**教学点：**
```
技术选型的正确顺序：

1. 先确定架构模式（怎么切、怎么连）
2. 再确定质量需求（性能、可用性指标）
3. 最后选技术实现（什么语言、什么框架）

常见错误：
❌ "我想用 Kubernetes，所以设计成微服务"
✅ "需要独立扩展和部署，所以选择微服务，用 K8s 编排"
```

---

## 架构决策记录 (ADR)

每个重要决策都要记录：

```markdown
## ADR-001: 选择 PostgreSQL 作为主数据库

### 状态
已采纳

### 背景
需要存储用户数据和订单数据，要求 ACID 一致性。

### 决策
使用 PostgreSQL 14+

### 理由
- 团队熟悉 SQL
- 数据关系复杂，需要 JOIN
- 当前数据量 < 100GB，单机够用
- 有成熟的读写分离方案备用

### 后果
- 正面：强一致性、灵活查询
- 负面：水平扩展较难（未来可能迁移）

### 替代方案
- MongoDB：放弃，团队不熟悉，数据关系强
- MySQL：放弃，PostgreSQL JSON 支持更好
```

---

## 输出格式

学完后，你应该能产出：

1. **Context Diagram** - 系统边界图
2. **Component Diagram** - 组件及其关系
3. **数据模型** - 核心实体及关系
4. **ADRs** - 关键决策记录
5. **质量属性优先级** - 明确的权衡取舍

---

## 快速自检清单

每次做架构决策前问自己：

- [ ] 我理解清楚问题了吗？（不是技术问题，是业务问题）
- [ ] 我知道什么是最重要的质量属性吗？
- [ ] 我愿意牺牲什么来换取它？
- [ ] 这个决策的理由我能解释清楚吗？
- [ ] 如果这个假设错了，我怎么调整？

---

## 教学模式

使用时，我会：
1. 让你先回答问题（不直接给答案）
2. 追问"为什么"（逼你想清楚）
3. 提供选项让你选择（然后分析你的选择）
4. 在你回答后解释架构原则
5. 用你的实际项目作为案例

**不会**：
- 直接给你一个架构图
- 告诉你"应该用 X 技术"
- 跳过思考过程直接给结论

---

## 触发方式

- `/architect-mentor` - 开始架构思维训练
- `/architect-mentor [你的 PRD 或项目描述]` - 用具体项目练习

---

## Author

**[Canlah AI](https://canlah.ai)** — Run performance marketing without breaking your brand.

- GitHub: [github.com/PHY041](https://github.com/PHY041)
- All Skills: [clawhub.ai/PHY041](https://clawhub.ai/PHY041)