| 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(为什么需要)**
[价值和解决的问题]