SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场system-architect

system-architect

编程与开发

查看项目

更新于 10-15 16:24

技能介绍

用途

System Architect 是 Phase 3（Solutioning，方案设计）阶段的专业技能，定位为“解决方案专家”，目标是把需求转化为可落地、可论证的技术架构。它的核心输入是需求文档（PRD 或 tech-spec），核心输出是完整的架构文档。

主要能力

  • 基于需求（PRD/tech-spec）设计系统架构
  • 选择技术栈并给出明确理由
  • 定义系统组件、边界与接口
  • 创建数据模型与 API 规范
  • 系统性地覆盖非功能需求（NFR）
  • 关注可扩展性、安全性与可维护性
  • 记录架构决策与权衡

核心原则

  • 需求驱动：架构必须满足全部功能需求（FR）与非功能需求（NFR）
  • 为非功能需求而设计：性能、安全、可扩展性是一等关注点
  • 简单优先：满足需求的最简方案优先
  • 松耦合：组件应相互独立、可替换
  • 记录决策：每个重大决策都有“为什么”

使用方式与关键工作流

  1. 创建系统架构 触发：用户请求架构设计或提到系统设计、技术栈。步骤包括：加载需求文档；提取全部 FR 与 NFR；识别架构驱动因素；按项目复杂度选择架构模式；设计组件、边界与接口；创建数据模型与 API 规范；将每个 NFR 映射到具体架构决策；记录技术栈选型理由；分析并记录关键权衡；生成完整架构文档。输出为 docs/architecture-{project-name}-{date}.md。

  2. 校验架构 触发：用户请求架构校验或评审。步骤包括：加载已有架构文档与需求文档；执行校验（所有 FR 是否被组件覆盖、所有 NFR 是否映射到架构决策、技术选型是否有理由、组件接口是否定义、数据模型是否完整、权衡是否记录）；生成校验报告与改进建议。输出为带通过/未通过状态和建议的校验报告。

  3. NFR 覆盖检查 触发：用户请求 NFR 清单或覆盖分析。步骤包括：运行 NFR 清单脚本识别全部 NFR 类别；检查架构文档的 NFR 覆盖情况；生成覆盖矩阵（已覆盖 vs 缺失）；对缺口给出建议。输出为 NFR 覆盖报告。

架构模式选择（依据项目复杂度与需求）

应用架构：

  • Monolith——简单、单一可部署单元（Level 0-1 项目）
  • Modular Monolith——模块清晰、边界明确（Level 2 项目）
  • Microservices——独立服务 + API（Level 3-4 项目）
  • Serverless——事件驱动函数（特定负载）
  • Layered——传统分层（表现层、业务层、数据层）

数据架构：

  • CRUD——简单增删改查（多数应用）
  • CQRS——读写模型分离（读密集型负载）
  • Event Sourcing——以事件日志为真源（审计要求）
  • Data Lake——集中式分析存储（大数据）

集成模式：

  • REST APIs——同步、面向资源（标准选择）
  • GraphQL——灵活查询、单一端点（复杂 UI）
  • Message Queues——异步、解耦（后台任务）
  • Event Streaming——实时数据流（分析、监控）

NFR 映射方式

按 NFR 类别逐项对应具体架构决策：

  • 性能：缓存策略、CDN、数据库索引、负载均衡
  • 可扩展性：水平扩展、无状态设计、数据库分片
  • 安全：认证/授权模型、加密（传输/静态）、密钥管理
  • 可靠性：冗余、故障转移、熔断、重试逻辑
  • 可维护性：模块边界、测试策略、文档
  • 可用性：多区域、备份/恢复、监控告警

架构文档结构

系统概览（目的、范围、架构驱动因素）、架构模式（含理由）、组件设计（组件、职责、接口）、数据模型（实体、关系、存储策略）、API 规范（端点、请求/响应格式）、NFR 映射（表格式对应）、技术栈（前后端、数据、基础设施选型及理由）、权衡分析、部署架构、未来考虑。

可用脚本

  • NFR 清单：bash scripts/nfr-checklist.sh
  • 校验架构：bash scripts/validate-architecture.sh docs/architecture-myproject-2025-12-09.md

子代理策略

该技能利用并行子代理最大化上下文利用（Claude Sonnet 4.6 / Opus 4.6 上每个代理最高 1M token）。包含三类工作流：需求分析工作流（2 个并行代理分别分析 FR 与 NFR）、组件设计工作流（N 个并行代理，每个设计一个组件）、NFR 映射工作流（6 个并行代理，每类 NFR 一个）。

实施指引（供使用该技能的 LLM）

使用 TodoWrite 跟踪架构章节（通常 8-10 个）；先加载需求；提取全部 FR 与 NFR；识别架构驱动因素；按复杂度选模式；不要过度设计；映射每个 NFR；记录权衡；使用模板；以系统思维思考组件、边界、接口与数据流；对不明确需求提出疑问，不要臆测。

与其他技能的衔接

上游：承接 Product Manager 输出的 PRD 或 tech-spec；与 UX Designer 协作接口架构。下游：向 Scrum Master 交付架构用于冲刺规划；为 Developer 提供实现蓝图。

限制与注意事项

资料未提供具体的收费、价格、平台支持范围或效果保证信息。架构设计结果依赖于输入需求文档的质量与完整性。