Back to Details

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

向用户询问以下关键信息，若信息不足则主动提问，不要假设：
必需信息：
  1. 核心业务目标或要实现的功能（例如："做一个支持万人同时在线的直播答题系统"）
  2. 已考虑或偏好的技术栈（前端/后端/数据库/中间件等；若无则留空）
重要补充信息： 3. 非功能性需求：
  • 并发量预期（如 1000 QPS、10 万 DAU）
  • 响应时间要求（如 < 100ms、< 1s）
  • 数据安全要求（如数据加密、访问控制）
  • 可用性要求（如 99.9%、99.99%）
  1. 部署环境限制（如必须使用某云厂商、需要自建机房、预算限制等）
  2. 团队技术栈偏好（如团队熟悉 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:
  1. Core business objectives or functions to be implemented (e.g., "Build a live quiz system supporting 10,000 concurrent online users")
  2. 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%)
  1. Deployment environment constraints (e.g., must use a specific cloud vendor, need to build an on-premises data center, budget constraints, etc.)
  2. 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