System Design

核心用法

System Design (Deep Workflow) 是一套结构化的系统设计方法论，采用七阶段递进式框架：

1. 需求澄清 — 区分功能性与非功能性需求，明确用户行为、读写比例、延迟目标、一致性要求，并划定非目标防止范围蔓延
2. 容量与SLO草图 — 粗略估算 QPS、存储、带宽，识别潜在瓶颈类别（数据库、网络、扇出、存储）
3. 高层架构 — 绘制分层架构图，并回答"为何不用更简单的单体"，考虑 CQRS、异步处理、CDN 等
4. 数据模型与存储 — 根据查询模式选择存储类型（关系型、文档、宽列、图），规划分片、缓存、搜索策略
5. API 与流量模式 — 设计 REST/RPC/GraphQL 接口，处理实时通信、限流、认证、分页
6. 可靠性与故障模式 — 将故障视为常态，设计降级策略：重试、熔断、只读模式、灾备方案
7. 权衡与演进 — 明确 v1 与 v2 路径，使用特性开关、绞杀者模式逐步迭代

显著优点

• 结构化决策：强制在约束条件下显式权衡，避免"先写代码再想架构"
• 面试实战导向：针对系统设计面试优化，提供时间盒策略（广度优先，再深入单点）
• 工程可落地：区分"面试模式"与"真实项目模式"，涵盖 RFC、微服务拆分、多区域部署等实际场景
• 反模式警示：强调"恰好一次"神话、热点键、扇出问题、背压等高频陷阱
• 演进思维：拒绝大爆炸重构，主张渐进式系统演化

潜在缺点与局限

• 深度依赖使用者经验：框架提供结构，但关键判断（如分片键选择、一致性级别）仍需领域知识
• 轻量级系统可能过度设计：对小系统建议"轻量运行各阶段"，但使用者可能忽视此警告
• 未覆盖特定领域：如嵌入式系统、硬件协同设计、AI 训练 infra 等专用领域需额外补充
• 安全认证缺失：来源报告为占位文本，未执行实际安全扫描

适合人群

• 准备系统设计面试的软件工程师（初级到高级）
• 设计新系统或重大重构的技术负责人、架构师
• 撰写 RFC、进行技术评审的工程师
• 从单体向微服务、单区域向多区域迁移的团队

常规风险

| 风险类别 | 说明 |

|---------|------|

| **过度工程** | 在小规模场景套用完整流程导致不必要的复杂度 |

| **估算偏差** | 粗略容量计算可能因业务特性（如突发流量）严重偏离实际 |

| **一致性误解** | 使用者可能误将"最终一致性"应用于需要强一致的场景 |

| **演进路径执行失败** | 规划 v1→v2 但业务压力导致技术债累积 |

| **安全盲点** | 框架未显式涵盖安全设计（威胁建模、数据加密、审计） |

使用建议

• 面试场景：严格控制时间，先走完全流程再深入单点；准备 60 秒版本的核心瓶颈总结
• 真实项目：重点关注数据所有权边界与迁移风险，增量变更优先于推倒重来
• 持续校准：定期对照"最终审查清单"验证设计决策是否仍然成立

核心用法

该 Skill 是一个纯文档型的系统设计深度工作流框架，采用七阶段结构化方法指导用户完成复杂系统的设计决策。用户通过自然语言触发关键词（如"设计 Twitter"、"微服务重构"）即可激活工作流，Agent 将依次引导完成：需求澄清、容量估算、高层架构、数据模型、API 设计、可靠性保障、权衡与演进七个阶段。每个阶段均提供明确的退出条件和决策检查点，支持面试模式（限时广度优先）与真实项目模式（深度挖掘）两种用法。

显著优点

1. 方法论体系完整：覆盖系统设计的全生命周期，从功能/非功能需求澄清到架构演进路径，弥补了多数开发者"画图有余、决策不足"的短板。
2. 决策导向明确：强调"为什么不用更简单方案"的追问机制，强制进行显式权衡（trade-offs），避免过度工程化。
3. 面试实战适配：专门区分 interview 模式与 real project 模式，提供 60 秒总结模板和时间盒策略，直接服务技术面试场景。
4. 关键风险点内置：主动提示热点键（hot keys）、扇出（fan-out）、背压（backpressure）、幂等性等分布式系统核心陷阱。
5. 零依赖零风险：纯 Markdown 文档，无可执行代码、无网络调用、无数据收集，即开即用。

潜在缺点与局限性

1. 无动态交互能力：作为 T-MD 类型 Skill，无法自动生成架构图、执行容量计算或连接真实数据源，所有输出依赖用户手动整理。
2. 内容更新依赖作者：当前为个人开发者（T3）维护，无组织背书，内容演进速度与长期维护存在不确定性。
3. 场景覆盖偏向通用：针对特定技术栈（如特定云厂商服务、特定数据库选型）的细节指引不足，用户需自行补充。
4. 缺少案例库：未内置真实企业级系统的拆解案例，初学者可能难以将抽象框架映射到实际问题。

适合的目标群体

• 技术面试候选人：准备字节、阿里、Google 等厂系统/架构设计面试的开发者
• 架构师与 Tech Lead：负责服务拆分、多区域部署、实时系统设计的工程决策者
• RFC 撰写者：需要结构化输出技术方案文档的团队成员
• 分布式系统学习者：希望通过实战问题理解 CAP、一致性、可用性等核心概念的进阶开发者

使用风险

• 评级上限约束：因来源为 T3 个人开发者，安全认证评级封顶为 A，组织级部署时建议内容复核
• 方法论执行依赖用户：框架本身不强制约束执行质量，设计深度完全取决于用户配合度
• 无版本控制联动：与真实代码仓库、基础设施即代码（IaC）无集成，设计产出与实际落地可能存在偏差
• 领域特异性不足：金融级一致性、医疗合规等特殊领域的额外约束需用户自行补充