architecture-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

智能技术架构方案生成器

Intelligent Technical Architecture Solution Generator

任务目标

Task Objectives

本 Skill 用于帮助用户从模糊需求出发，逐步构建出可落地、结构清晰、具备演进能力的技术架构方案。

能力包含：需求分析、技术选型评估、架构设计、替代方案建议、方案输出
触发条件：用户提出"设计架构"、"技术选型"、"系统设计"等需求，或需要评估技术方案

This Skill is designed to help users build implementable, well-structured, and evolvable technical architecture solutions starting from vague requirements.

Capabilities include: requirement analysis, tech stack selection evaluation, architecture design, alternative solution suggestions, solution output
Trigger conditions: Users put forward requirements such as "design architecture", "tech stack selection", "system design", or need to evaluate technical solutions

操作步骤

Operation Steps

第一步：收集信息

Step 1: Information Collection

向用户询问以下关键信息，若信息不足则主动提问，不要假设：

必需信息：

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

重要补充信息： 3. 非功能性需求：

并发量预期（如 1000 QPS、10 万 DAU）
响应时间要求（如 < 100ms、< 1s）
数据安全要求（如数据加密、访问控制）
可用性要求（如 99.9%、99.99%）

部署环境限制（如必须使用某云厂商、需要自建机房、预算限制等）
团队技术栈偏好（如团队熟悉 Java/Go/Python）

Ask users for the following key information; if information is insufficient, take the initiative to ask instead of making assumptions:

Required Information:

Core business objectives or functions to be implemented (e.g., "Build a live quiz system supporting 10,000 concurrent online users")
Considered or preferred tech stacks (frontend/backend/database/middleware, etc.; leave blank if none)

Important Supplementary Information: 3. Non-functional requirements:

Expected concurrency (e.g., 1000 QPS, 100,000 DAU)
Response time requirements (e.g., < 100ms, < 1s)
Data security requirements (e.g., data encryption, access control)
Availability requirements (e.g., 99.9%, 99.99%)

Deployment environment constraints (e.g., must use a specific cloud vendor, need to build an on-premises data center, budget constraints, etc.)
Team tech stack preferences (e.g., team is familiar with Java/Go/Python)

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

Step 2: Requirement Sorting & Tech Stack Supplement

需求分析：

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

技术栈评估：

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

常见问题识别：

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

Requirement Analysis:

Identify core modules (user management, business logic, data storage, message communication, monitoring logs, etc.)
Analyze key interaction flows (complete link from user request → processing → response)
Identify performance bottlenecks (hot data, high-frequency queries, long transactions, etc.)

Tech Stack Evaluation:

Evaluate the applicability of the tech stack provided by users:
- Whether it meets performance requirements (e.g., can SQLite support high concurrency)
- Whether it fits the business scenario (e.g., is MongoDB suitable for relational data)
- Whether there are technical risks (e.g., immature ecosystem of new frameworks)
If the tech stack is insufficient or inappropriate, proactively propose alternative suggestions and explain the reasons

Common Problem Identification:

Missing necessary components (no cache, no message queue, no monitoring system)
Architecture design defects (single point of failure, no disaster recovery, data consistency not considered)
Mismatched tech stack selection (e.g., using relational databases to process document-type data)

第三步：迭代完善

Step 3: Iterative Improvement

呈现初步架构： 以模块化方式呈现架构，包括：

前端层（Web、移动端、小程序等）
API 网关层
服务层（核心业务服务）
数据层（数据库、缓存、文件存储）
基础设施层（部署、监控、日志、安全）

技术选型方案： 针对每个模块，提供：

推荐技术（主选方案）
备选方案（替代方案）
选择依据（性能、生态、学习成本、维护成本）

主动引导：

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

循环优化： 根据用户反馈调整方案，重点关注：

成本是否可接受
团队是否能驾驭
风险是否可控
是否具备演进能力

Present Preliminary Architecture: Present the architecture in a modular manner, including:

Frontend layer (Web, mobile, mini-program, etc.)
API Gateway layer
Service layer (core business services)
Data layer (database, cache, file storage)
Infrastructure layer (deployment, monitoring, logging, security)

Tech Stack Selection Plan: For each module, provide:

Recommended technology (primary option)
Alternative solutions (substitute options)
Selection basis (performance, ecosystem, learning cost, maintenance cost)

Proactive Guidance:

Ask users if they have preferences or restrictions on certain technologies (e.g., "Do you have to use a cloud vendor? Can you accept Serverless?")
Confirm whether key non-functional requirements are met
Understand whether the team's technical capabilities match the recommended solutions

Circular Optimization: Adjust the plan based on user feedback, focusing on:

Whether the cost is acceptable
Whether the team can handle it
Whether risks are controllable
Whether it has evolvability

第四步：输出最终方案

Step 4: Output Final Solution

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

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 阶段（成熟期）：微服务化，容器化，自动化运维
演进里程碑和技术债务管理

Output the complete architecture suggestion in a clear structure, including the following content:

1. Overall Architecture Diagram Use Mermaid syntax or layered description, example:

Frontend Layer
  ├─ Web Application (React/Vue)
  ├─ Mobile Application (Flutter/React Native)
  └─ Mini Program

API Gateway Layer
  ├─ Route Distribution
  ├─ Authentication
  └─ Rate Limiting & Circuit Breaking

Service Layer
  ├─ User Service
  ├─ Order Service
  ├─ Payment Service
  └─ Notification Service

Data Layer
  ├─ Relational Database (MySQL/PostgreSQL)
  ├─ Cache (Redis)
  ├─ Search Engine
  └─ Message Queue (Kafka/RabbitMQ)

Infrastructure Layer
  ├─ Container Orchestration
  ├─ Monitoring & Alerting (Prometheus + Grafana)
  ├─ Log Collection (ELK)
  └─ CI/CD Pipeline

2. Tech Stack Selection and Reasons for Each Module Explain in the form of tables or lists:

Module name
Recommended technology
Selection reasons (performance, reliability, ecosystem, cost, team skills)
Alternative solutions and switching scenarios

3. Key Data Flow or Interaction Process Describe the data flow path of core business, for example:

User Request → API Gateway → Authentication Service → Business Service → Database → Response Return

4. Key Points of Scalability and Disaster Recovery Design

Horizontal scaling strategies (stateless design, database sharding, read-write separation)
High availability design (multi-availability zone deployment, failover)
Data consistency solutions (transactions, eventual consistency, compensation mechanisms)
Disaster recovery backup strategies (regular backups, active-active across regions)

5. Subsequent Evolution Suggestions

Stage V1 (MVP): Quickly validate the business, monolithic architecture, focus on core functions
Stage V2 (Growth Period): Split core services, introduce cache, optimize performance
Stage V3 (Mature Period): Microservices, containerization, automated operation and maintenance
Evolution milestones and technical debt management

资源索引

Resource Index

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

Domain References: See references/tech-selection-guide.md (Tech Stack Selection Reference Manual, including recommended solutions and technical comparisons for common scenarios)

注意事项

Notes

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

Avoid over-engineering: Prioritize mature, community-active technologies that are easy for the team to adopt
Pragmatism: Solutions must be implementable; do not consider fancy but practically useless technologies
Cost awareness: Balance performance, reliability and cost to avoid resource waste
Evolvability: Design should be scalable to support future business growth
Team matching: Tech stack selection should consider team capabilities and learning costs
Risk control: Identify potential risks and provide response plans

使用示例

Usage Examples

示例 1：电商系统架构设计

Example 1: E-commerce System Architecture Design

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

Function Description: Design a technical architecture for a medium-sized e-commerce platform
Requirement Information: 100,000 DAU, supports flash sale activities, requires high availability
Execution Method: The agent leads the four-step process, looking up tech stack selection suggestions for e-commerce scenarios in references/tech-selection-guide.md
Key Outputs: Layered architecture diagram, tech stack selection table, flash sale scenario design plan, evolution roadmap

示例 2：SaaS 平台技术选型

Example 2: SaaS Platform Tech Stack Selection

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

Function Description: Evaluate technical solutions for a multi-tenant SaaS platform
Requirement Information: Needs to support multi-tenant isolation, high data security requirements, limited budget
Execution Method: The agent analyzes multi-tenant scenario requirements, compares database solutions (independent database vs shared database)
Key Outputs: Multi-tenant isolation solution comparison, database selection suggestions, cost estimation, risk warnings