Install
openclaw skills install phy-architect-mentorPhy Architect Mentor
架构师思维训练。通过引导式问答教你从 PRD 到架构设计的思考过程。不是帮你做架构，而是教你怎么想。触发词：'教我架构'、'怎么做架构'、'architect mentor'、'/architect-mentor'
Architect Mentor - 架构思维训练
目标
不是帮你做架构，而是教你像架构师一样思考。通过苏格拉底式提问，引导你自己得出架构决策。
核心理念
架构 = 在约束条件下，做出最优的权衡决策
架构师的工作不是追求"最好"的设计，而是在给定约束（时间、资源、技术栈、团队能力）下，找到"最合适"的方案。
教学流程
Phase 1: 问题域理解（从 PRD 出发）
先确保理解清楚要解决什么问题：
引导问题：
- "用一句话描述这个系统的核心职责是什么？"
- "如果系统挂了，用户会损失什么？"（帮助理解关键程度）
- "系统的边界在哪里？什么是系统内的，什么是系统外的？"
教学点：
- 架构师第一步是划清边界，不是想技术方案
- Context Diagram：画出系统与外部实体的关系
┌─────────────────────────────────────────┐
│ 外部世界 │
│ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │ 用户 │ │第三方API│ │ 数据库 │ │
│ └───┬───┘ └───┬───┘ └───┬───┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ 你的系统 │ │
│ │ （这里面才是你要设计的） │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘
Phase 2: 质量属性识别（最关键的一步）
引导问题：
-
"这个系统最重要的质量属性是什么？"
- 性能（多快？）
- 可用性（能挂多久？）
- 可扩展性（用户量增长 10x 怎么办？）
- 安全性（数据泄露的后果？）
- 可维护性（谁来维护？技术能力如何？）
-
"这些属性之间，哪个可以牺牲？"（强制权衡）
- 例：为了快速上线，可以牺牲可扩展性吗？
- 例：为了安全，可以牺牲用户体验吗？
教学点：
没有"既要又要还要"的架构
┌────────────────────────────────────────┐
│ CAP 定理的本质：你只能选两个 │
│ │
│ 性能 ◄────────► 可维护性 │
│ ▲ │
│ │ │
│ ▼ │
│ 灵活性 │
│ │
│ 说出你愿意牺牲什么，才是真正的决策 │
└────────────────────────────────────────┘
Phase 3: 组件分解（怎么切）
引导问题：
- "如果要把系统分成几个独立的部分，你会怎么切？"
- "为什么这样切？切的依据是什么？"
教学点 - 分解原则：
| 原则 | 解释 | 例子 |
|---|---|---|
| 按业务能力切 | 每个组件对应一个业务概念 | 用户服务、订单服务、支付服务 |
| 按变化频率切 | 变化快的和变化慢的分开 | 核心引擎 vs 展示层 |
| 按团队切 | Conway's Law：架构反映组织结构 | 前端团队 → 前端服务 |
| 按伸缩需求切 | 需要独立扩容的分开 | 计算密集型 vs IO 密集型 |
反问检验：
- "这两个组件如果合并，会有什么问题？"
- "这两个组件如果分开，通信成本高吗？"
Phase 4: 接口设计（怎么连）
引导问题：
- "组件 A 需要从组件 B 获取什么？"
- "是同步调用还是异步消息？为什么？"
- "如果 B 挂了，A 怎么办？"
教学点 - 集成模式：
同步 vs 异步
同步调用（REST/gRPC）：
A ──请求──► B ──响应──► A
优点：简单、实时
缺点：耦合、B 挂了 A 也挂
异步消息（Queue/Event）：
A ──事件──► [Queue] ──消费──► B
优点：解耦、削峰
缺点：复杂、最终一致性
选择指南：
- 需要立即拿到结果 → 同步
- 可以容忍延迟 → 异步
- 调用失败可以重试 → 同步
- 失败需要可靠保证 → 异步 + 消息队列
Phase 5: 数据设计（怎么存）
引导问题：
- "系统的核心数据实体是什么？"
- "数据之间的关系是什么？"
- "读多还是写多？比例大概是多少？"
- "数据一致性要求高吗？"
教学点 - 存储选型：
| 需求 | 推荐 | 原因 |
|---|---|---|
| 结构化 + 强一致 | PostgreSQL | ACID 保证 |
| 读多写少 + 灵活查询 | PostgreSQL + 读副本 | 读写分离 |
| 高并发写入 | MongoDB / DynamoDB | 水平扩展 |
| 键值缓存 | Redis | 内存速度 |
| 全文搜索 | Elasticsearch | 倒排索引 |
| 时序数据 | InfluxDB / TimescaleDB | 时间优化 |
反问：
- "为什么选这个数据库？换成 X 会怎样？"
- "数据量增长 100x，还能用这个方案吗？"
Phase 6: 故障设计（会怎么挂）
引导问题：
- "系统最可能在哪里出问题？"
- "出问题了，用户看到什么？"
- "怎么检测到问题？怎么恢复？"
教学点 - Design for Failure：
不是 IF 会出问题，是 WHEN 会出问题
好的架构师会问：
❌ "怎么让它不出问题？"
✅ "出问题时怎么优雅降级？"
故障处理模式：
- 重试：临时故障，重试几次
- 熔断：依赖挂了，快速失败，不拖累整个系统
- 降级：核心功能保证，非核心功能关闭
- 限流：流量太大，拒绝部分请求保护系统
Phase 7: 技术选型（用什么）
注意：这是最后一步，不是第一步！
引导问题：
- "团队熟悉什么技术栈？"
- "有没有必须用的技术（公司规定、已有基础设施）？"
- "选这个技术的理由是什么？换一个会怎样？"
教学点：
技术选型的正确顺序：
1. 先确定架构模式（怎么切、怎么连）
2. 再确定质量需求（性能、可用性指标）
3. 最后选技术实现（什么语言、什么框架）
常见错误：
❌ "我想用 Kubernetes，所以设计成微服务"
✅ "需要独立扩展和部署，所以选择微服务，用 K8s 编排"
架构决策记录 (ADR)
每个重要决策都要记录：
## ADR-001: 选择 PostgreSQL 作为主数据库
### 状态
已采纳
### 背景
需要存储用户数据和订单数据，要求 ACID 一致性。
### 决策
使用 PostgreSQL 14+
### 理由
- 团队熟悉 SQL
- 数据关系复杂，需要 JOIN
- 当前数据量 < 100GB，单机够用
- 有成熟的读写分离方案备用
### 后果
- 正面：强一致性、灵活查询
- 负面：水平扩展较难（未来可能迁移）
### 替代方案
- MongoDB：放弃，团队不熟悉，数据关系强
- MySQL：放弃，PostgreSQL JSON 支持更好
输出格式
学完后，你应该能产出：
- Context Diagram - 系统边界图
- Component Diagram - 组件及其关系
- 数据模型 - 核心实体及关系
- ADRs - 关键决策记录
- 质量属性优先级 - 明确的权衡取舍
快速自检清单
每次做架构决策前问自己：
- 我理解清楚问题了吗？（不是技术问题，是业务问题）
- 我知道什么是最重要的质量属性吗？
- 我愿意牺牲什么来换取它？
- 这个决策的理由我能解释清楚吗？
- 如果这个假设错了，我怎么调整？
教学模式
使用时，我会：
- 让你先回答问题（不直接给答案）
- 追问"为什么"（逼你想清楚）
- 提供选项让你选择（然后分析你的选择）
- 在你回答后解释架构原则
- 用你的实际项目作为案例
不会：
- 直接给你一个架构图
- 告诉你"应该用 X 技术"
- 跳过思考过程直接给结论
触发方式
/architect-mentor- 开始架构思维训练/architect-mentor [你的 PRD 或项目描述]- 用具体项目练习
Author
Canlah AI — Run performance marketing without breaking your brand.
- GitHub: github.com/PHY041
- All Skills: clawhub.ai/PHY041