---
name: architecture-design
description: 根据业务需求和技术栈生成可实施的架构方案，通过四步流程（收集信息、梳理需求、迭代完善、输出方案）提供结构化建议和技术选型优化
---

# 智能技术架构方案生成器

## 任务目标
本 Skill 用于帮助用户从模糊需求出发，逐步构建出可落地、结构清晰、具备演进能力的技术架构方案。
- 能力包含：需求分析、技术选型评估、架构设计、替代方案建议、方案输出
- 触发条件：用户提出"设计架构"、"技术选型"、"系统设计"等需求，或需要评估技术方案

## 操作步骤

### 第一步：收集信息
向用户询问以下关键信息，若信息不足则主动提问，不要假设：

**必需信息：**
1. 核心业务目标或要实现的功能（例如："做一个支持万人同时在线的直播答题系统"）
2. 已考虑或偏好的技术栈（前端/后端/数据库/中间件等；若无则留空）

**重要补充信息：**
3. 非功能性需求：
   - 并发量预期（如 1000 QPS、10 万 DAU）
   - 响应时间要求（如 < 100ms、< 1s）
   - 数据安全要求（如数据加密、访问控制）
   - 可用性要求（如 99.9%、99.99%）
4. 部署环境限制（如必须使用某云厂商、需要自建机房、预算限制等）
5. 团队技术栈偏好（如团队熟悉 Java/Go/Python）

### 第二步：梳理需求 & 补充技术

**需求分析：**
- 识别核心模块（用户管理、业务逻辑、数据存储、消息通信、监控日志等）
- 分析关键交互流程（用户请求 → 处理 → 响应的完整链路）
- 识别性能瓶颈点（热点数据、高频查询、长事务等）

**技术栈评估：**
- 对照用户提供的技术栈，评估其适用性：
  - 是否满足性能要求（如 SQLite 能否支撑高并发）
  - 是否适合业务场景（如关系型数据用 MongoDB 是否合适）
  - 是否存在技术风险（如新框架生态不成熟）
- 若技术栈不足或不当，主动提出替代建议并说明理由

**常见问题识别：**
- 缺少必要组件（无缓存、无消息队列、无监控体系）
- 架构设计缺陷（单点故障、无容灾、数据一致性未考虑）
- 技术选型不匹配（如用关系数据库处理文档型数据）

### 第三步：迭代完善

**呈现初步架构：**
以模块化方式呈现架构，包括：
- 前端层（Web、移动端、小程序等）
- API 网关层
- 服务层（核心业务服务）
- 数据层（数据库、缓存、文件存储）
- 基础设施层（部署、监控、日志、安全）

**技术选型方案：**
针对每个模块，提供：
- 推荐技术（主选方案）
- 备选方案（替代方案）
- 选择依据（性能、生态、学习成本、维护成本）

**主动引导：**
- 询问用户对某些技术是否有偏好或限制（如"是否必须使用云厂商？能否接受 Serverless？"）
- 确认关键非功能性需求是否已满足
- 了解团队技术能力是否匹配推荐方案

**循环优化：**
根据用户反馈调整方案，重点关注：
- 成本是否可接受
- 团队是否能驾驭
- 风险是否可控
- 是否具备演进能力

### 第四步：输出最终方案

以清晰结构输出完整架构建议，包含以下内容：

**1. 整体架构图**
使用 Mermaid 语法或分层描述，示例：

```
前端层
  ├─ Web 应用 (React/Vue)
  ├─ 移动应用 (Flutter/React Native)
  └─ 小程序

API 网关层
  ├─ 路由分发
  ├─ 鉴权认证
  └─ 限流熔断

服务层
  ├─ 用户服务
  ├─ 订单服务
  ├─ 支付服务
  └─ 通知服务

数据层
  ├─ 关系数据库 (MySQL/PostgreSQL)
  ├─ 缓存 (Redis)
  ├─ 搜索引擎
  └─ 消息队列 (Kafka/RabbitMQ)

基础设施层
  ├─ 容器编排
  ├─ 监控告警 (Prometheus + Grafana)
  ├─ 日志收集 (ELK)
  └─ CI/CD 流水线
```

**2. 各模块技术选型及理由**
以表格或列表形式说明：
- 模块名称
- 推荐技术
- 选择理由（性能、可靠性、生态、成本、团队技能）
- 备选方案及切换场景

**3. 关键数据流或交互流程**
描述核心业务的数据流转路径，例如：
```
用户请求 → API 网关 → 鉴权服务 → 业务服务 → 数据库 → 响应返回
```

**4. 可扩展性与容灾设计要点**
- 水平扩展策略（无状态设计、分库分表、读写分离）
- 高可用设计（多可用区部署、故障转移）
- 数据一致性方案（事务、最终一致性、补偿机制）
- 容灾备份策略（定期备份、异地多活）

**5. 后续演进建议**
- V1 阶段（MVP）：快速验证业务，单体架构，关注核心功能
- V2 阶段（成长期）：拆分核心服务，引入缓存，优化性能
- V3 阶段（成熟期）：微服务化，容器化，自动化运维
- 演进里程碑和技术债务管理

## 资源索引

- 领域参考：见 [references/tech-selection-guide.md](references/tech-selection-guide.md)（技术选型参考手册，包含常见场景的推荐方案和技术对比）

## 注意事项

- 避免过度工程：优先推荐成熟、社区活跃、团队易上手的技术
- 实用主义：方案必须可落地，不考虑花哨但无实际价值的技术
- 成本意识：平衡性能、可靠性和成本，避免资源浪费
- 演进能力：设计要具备可扩展性，支持未来业务增长
- 团队匹配：技术选型要考虑团队能力和学习成本
- 风险控制：识别潜在风险并提供应对方案

## 使用示例

### 示例 1：电商系统架构设计
- **功能说明**：为中型电商平台设计技术架构
- **需求信息**：10 万 DAU，支持秒杀活动，需要高可用
- **执行方式**：智能体主导四步流程，在 references/tech-selection-guide.md 中查找电商场景的技术选型建议
- **关键输出**：分层架构图、技术选型表、秒杀场景设计方案、演进路线图

### 示例 2：SaaS 平台技术选型
- **功能说明**：为多租户 SaaS 平台评估技术方案
- **需求信息**：需要支持多租户隔离、数据安全要求高、预算有限
- **执行方式**：智能体分析多租户场景需求，对比数据库方案（独立数据库 vs 共享数据库）
- **关键输出**：多租户隔离方案对比、数据库选型建议、成本估算、风险提示