| name | 5w-explainer |
| description | 使用 5W 结构（What 是什么、Who 给谁用、When 什么情况用、Where 用在什么地方、Why 为什么需要）来系统地解释任何概念、技术、产品或流程。当用户要求解释、说明或了解某事物时使用此技能，包括"什么是X"、"X是什么意思"、"解释一下X"、"帮我了解X"等表达方式。无论用户是否明确提到 5W，只要是需要系统性解释的请求，都应该使用此技能。 |
5W 解释器
当用户要求解释或了解某个概念、技术、产品、流程时，使用 5W 结构提供系统性的解释。
什么是 5W 结构
5W 是一个经典的解释框架，通过五个维度全面阐述一个主题：
- What（是什么）：定义、核心概念、本质特征
- Who（给谁用）：目标用户、适用人群、相关方
- When（什么情况用）：使用场景、时机、条件
- Where（用在什么地方）：应用领域、环境、平台
- Why（为什么需要）：存在价值、解决的问题、重要性
如何使用 5W 解释
第一步：识别解释对象
首先明确用户想要了解什么。这可能是：
- 一个概念（如"微服务"、"敏捷开发"）
- 一项技术（如"React"、"Docker"）
- 一个产品（如"Notion"、"Figma"）
- 一个流程（如"代码审查"、"持续集成"）
第二步：用 5W 结构组织答案
按照以下格式进行解释。每个维度都应该详细展开，用简明清晰的中文表达。
What（是什么）
给出清晰的定义，说明这个事物本质是什么。避免使用过于专业的术语，如果必须使用，要附带简单解释。
要点：
- 一句话定义
- 核心特征或组成部分
- 与类似事物的区别（如果有助于理解）
示例格式：
**What（是什么）**
微服务是一种软件架构风格，它将一个大型应用程序拆分成多个小型、独立的服务。每个服务专注于完成单一的业务功能，可以独立开发、部署和扩展。
与传统的"单体架构"不同，微服务架构中的服务之间通过 API 通信，而不是共享代码库。
Who（给谁用）
说明这个事物的目标用户是谁，谁会从中受益。
要点：
- 主要使用者
- 间接受益者
- 需要具备的基础知识（如果有）
示例格式：
**Who（给谁用）**
微服务主要面向：
- **中大型团队**：当团队规模增长时，微服务可以让不同团队独立开发和部署不同功能
- **需要快速迭代的产品**：频繁更新的产品可以从微服务的独立性中受益
- **对系统稳定性要求高的业务**：微服务可以实现故障隔离，一个服务出问题不会影响整个系统
采用微服务通常需要团队具备一定的分布式系统经验和 DevOps 能力。
When（什么情况用）
描述在什么场景或时机下使用这个事物。
要点：
示例格式：
**When（什么情况用）**
适合使用微服务的场景：
- 应用程序复杂度高，单体代码库难以维护
- 不同模块需要不同的技术栈
- 团队规模较大，需要并行开发
- 对系统可用性和可扩展性有高要求
不适合使用微服务的场景：
- 初创公司的简单应用（过早优化是浪费）
- 团队规模小，技术能力有限
- 业务逻辑简单，拆分收益不大
Where（用在什么地方）
说明这个事物应用在哪些领域、环境或平台上。
要点：
示例格式：
**Where（用在什么地方）**
微服务广泛应用于：
- **互联网企业**：如 Netflix、Amazon、Uber 等大规模在线服务
- **金融行业**：银行、支付系统等需要高可用的场景
- **电商平台**：商品、订单、用户等模块天然适合拆分
微服务通常运行在云平台上（如 AWS、阿里云），并配合容器技术（Docker、Kubernetes）进行管理。
Why（为什么需要）
阐述这个事物的价值和它解决的问题。
要点：
- 解决的核心问题
- 带来的价值或好处
- 为什么它比替代方案更好
示例格式：
**Why（为什么需要）**
微服务解决了单体架构的核心痛点：
1. **部署灵活**：单体应用任何小改动都需要重新部署整个应用，而微服务可以只部署变更的服务
2. **技术自由**：不同服务可以选择最适合的技术栈，而不是全公司统一一种
3. **故障隔离**：一个服务的故障不会导致整个系统崩溃
4. **团队自治**：小团队可以全权负责一个服务，从开发到部署独立决策
5. **弹性扩展**：可以根据负载情况只扩展需要的服务，节省成本
当然，微服务也带来了分布式系统的复杂性（网络延迟、数据一致性等），这是使用时需要权衡的。
第三步：审查和优化
在提供答案前，检查：
- 完整性：是否覆盖了所有 5W 维度？
- 清晰性：语言是否简明易懂？是否避免不必要的术语？
- 准确性：信息是否正确？如果是技术内容，概念是否准确？
- 平衡性：每个维度的篇幅是否合理？不要某个维度过于简略
重要原则
- 用户视角：始终从用户理解的角度出发，而不是专家炫耀的角度
- 中文友好：使用自然的中文表达，避免翻译腔
- 详略得当：根据主题复杂度调整解释深度，简单主题不要过度展开
- 客观中立：说明优点时也要提及缺点或限制，让用户有全面认识
- 实用导向：解释的目的帮助用户理解并在实践中应用，而不是单纯的知识展示
特殊情况处理
用户已经了解某部分
如果用户说"我知道 X 是什么，但想知道为什么需要它"，可以：
主题过于简单
如果主题非常简单（如"什么是按钮"），5W 结构可能显得过度设计。此时可以：
- 合并某些维度
- 使用更简洁的语言
- 适当说明"这个概念比较简单，5W 结构可能不是最佳解释方式"
主题过于抽象
对于高度抽象的概念（如"爱"、"正义"），5W 结构可能不完全适用。此时可以：
- 优先解释 What 和 Why
- 用具体例子帮助理解
- 说明 5W 结构的局限性
输出格式模板
[主题名称] 的 5W 解析
**What（是什么）**
[定义和核心特征]
**Who（给谁用）**
[目标用户和适用人群]
**When（什么情况用）**
[使用场景和时机]
**Where（用在什么地方）**
[应用领域和环境]
**Why（为什么需要）**
[价值和解决的问题]
