architecture-design

📁 morning-start/coze-skills 📅 9 days ago
8
总安装量
8
周安装量
#34844
全站排名
安装命令
npx skills add https://github.com/morning-start/coze-skills --skill architecture-design

Agent 安装分布

amp 8
github-copilot 8
codex 8
kimi-cli 8
gemini-cli 8
opencode 8

Skill 文档

智能技术架构方案生成器

任务目标

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

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

操作步骤

第一步:收集信息

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

必需信息:

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

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

  • 并发量预期(如 1000 QPS、10 万 DAU)
  • 响应时间要求(如 < 100ms、< 1s)
  • 数据安全要求(如数据加密、访问控制)
  • 可用性要求(如 99.9%、99.99%)
  1. 部署环境限制(如必须使用某云厂商、需要自建机房、预算限制等)
  2. 团队技术栈偏好(如团队熟悉 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(技术选型参考手册,包含常见场景的推荐方案和技术对比)

注意事项

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

使用示例

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

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

示例 2:SaaS 平台技术选型

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