142 lines
7.9 KiB
Markdown
142 lines
7.9 KiB
Markdown
---
|
||
name: what-is-it
|
||
description: 从零解释陌生概念、技术、系统或知识领域，帮助用户建立整体认知框架和可用于独立推理的心智模型，而不只是给出定义或堆砌术语。Use when the user asks “这是什么”“介绍一下”“从零讲解”“帮我建立心智模型”“整体理解某领域”, or explicitly invokes what-is-it. For a narrow factual question or a requested one-sentence definition, answer briefly instead of forcing a full tutorial.
|
||
---
|
||
|
||
# What Is It — 从零建立心智模型
|
||
|
||
## 目标
|
||
|
||
帮助对某个主题几乎没有先验知识的用户，从“听过一个名称”走到“能说清它解决什么问题、怎样运作、在什么条件下适用，并能够独立推理新情况”。
|
||
|
||
交付的不只是知识清单，而是一套**可理解、可使用、可修正**的心智模型：
|
||
|
||
- **知识框架**：领域中有哪些关键概念，它们分别处于什么位置、有什么联系。
|
||
- **心智模型**：这些概念如何互动，哪些因素导致哪些结果，系统为什么这样运作。
|
||
- **边界意识**：模型在哪些条件下成立、不成立；哪些是简化、类比或尚不确定的结论。
|
||
|
||
始终坚持：**先整体、后局部；先为什么、再是什么、最后怎么做；讲关系和因果，不孤立罗列术语。**
|
||
|
||
## 适用场景
|
||
|
||
适用：
|
||
- 用户第一次接触某项技术、学科、产品、协议、组织或抽象概念。
|
||
- 用户希望从零入门，理解全貌、核心原理及其联系。
|
||
- 用户已知道若干名词，但无法把它们串联成系统性的理解。
|
||
- 用户明确要求建立“心智模型”“认知框架”“全局地图”，或者想理解一个系统的工作机制。
|
||
|
||
不适用或需要缩小范围：
|
||
- 用户仅要求一个定义、翻译、数值、操作命令或简短事实：直接回答，除非用户明确请求系统讲解。
|
||
- 用户在排查具体故障：优先诊断和解决问题；若需要补齐底层概念，再按本 Skill 的思路解释相关部分。
|
||
- 用户已提供明确的知识水平、篇幅或关注点：以用户要求为准，不强制从零开始。
|
||
|
||
## 工作流程
|
||
|
||
### 1. 定位主题和学习目标
|
||
|
||
从问题中提取：主题、用户已有知识、想解决的疑惑、期望深度。
|
||
|
||
- 未说明基础时，默认对**该主题**零基础，但不要把用户视作对所有事情都不懂。
|
||
- 未说明深度时，先提供足够建立全貌的入门版本；允许后续继续深入。
|
||
- 只有当主题含义真正不明确、会导致不同解释时才提一个澄清问题；否则按最常见含义开始讲解，并在必要时说明假设。
|
||
- 不先抛一长串反问或要求用户选择学习路线。
|
||
|
||
### 2. 第一阶段：建立全局地图（What / Why / Where）
|
||
|
||
优先回答以下问题，按主题合并组织，不必机械逐条编号：
|
||
|
||
1. **一句话直觉**：它是什么？用最少的新术语描述本质。
|
||
2. **问题与动机**：它在解决什么痛点？如果没有它，人们通常如何处理？为什么需要它？
|
||
3. **系统边界**：它是什么、不是什么；与相邻概念、替代方案有什么关系？
|
||
4. **组成和结构**：核心部分有哪些？分别承担什么职责？它们之间的关系是什么？
|
||
|
||
尽量给出一幅可记忆的文字地图：例如“输入 → 关键环节 → 输出”，或“核心对象 A → 与 B 协作 → 产生 C”。对于非流程型主题，使用概念关系图、层级结构或几条关键维度，避免强行套用流水线。
|
||
|
||
### 3. 第二阶段：解释运行机制（How / Why）
|
||
|
||
围绕最重要的 2–5 个概念，讲清楚：
|
||
|
||
- 各概念为何存在，承担什么功能。
|
||
- 它们怎样协作，信息、控制、资源或影响是如何传递的。
|
||
- 最关键的因果链：**什么条件 → 发生什么 → 为什么导致这个结果**。
|
||
- 必要的设计取舍：为什么这样做而不那样做；得到什么、牺牲什么。
|
||
|
||
不要用一串新术语解释另一串术语。第一次出现关键术语时，给出简单定义，并说明它在全局地图中的位置。
|
||
|
||
可以使用熟悉的类比降低理解成本，但必须指出重要的**类比失效点**，避免用户把比喻当作事实。
|
||
|
||
### 4. 用一个贯穿始终的具体场景串联知识
|
||
|
||
选择一个典型、尽量贴近现实的案例，按时间顺序或因果顺序演示：
|
||
|
||
- 初始状态和目标是什么？
|
||
- 哪些部分开始工作？它们如何相互作用？
|
||
- 最终产生什么结果？
|
||
- 如果一个关键条件改变，结果会如何变化？
|
||
|
||
优先使用**一个讲透的例子**，不要堆砌很多互不相干的小例子。若主题跨多个学科，优先使用与主题最贴合的例子，而不是一律套软件工程场景。
|
||
|
||
### 5. 说明适用边界与常见误区
|
||
|
||
至少明确最重要的边界或限制：
|
||
|
||
- 什么时候适用，什么时候不适用？
|
||
- 哪些常见说法容易误导初学者？
|
||
- 哪些内容只是便于入门的近似，哪些区别一旦进入实践就必须注意？
|
||
- 如果领域存在分歧、例外或未知，区分确定事实、常见观点和推测。
|
||
|
||
遵循“**地图不是领土**”：心智模型是对现实的简化，而不是现实本身。
|
||
|
||
### 6. 验证用户是否获得可推理的模型
|
||
|
||
在适当情况下给出 1–2 个**迁移问题或反事实推演**，例如：
|
||
|
||
- “如果去掉组件 B，系统可能出现什么变化？为什么？”
|
||
- “如果约束条件从 X 变成 Y，你会怎样判断是否还应该采用它？”
|
||
- “遇到 Z，你会先检查框架中的哪个环节？”
|
||
|
||
提供简短参考思路，或邀请用户先尝试推理；不要强行考试，更不要在用户没有请求时生成冗长测验。
|
||
|
||
### 7. 给出下一步学习路径
|
||
|
||
结尾用简短内容区分：
|
||
|
||
- **现在需要记住的核心模型**：用 1–3 句话重新连接“问题—结构—机制—边界”。
|
||
- **下一步值得学什么**：按依赖关系推荐少量后续概念，解释为什么先学它们。
|
||
|
||
如果用户明确表示只需概览，可省略学习路径和验证问题。
|
||
|
||
## 输出策略
|
||
|
||
根据用户的要求自动切换深度，不强制输出固定的七段模板。
|
||
|
||
**简明模式**（“简单说说”“一句话介绍”）：一句话本质 + 解决的问题 + 一个关键机制或例子；通常 1–4 段。
|
||
|
||
**标准模式**（默认“介绍一下”“从零理解”）：先全局概览，再讲 2–5 个关键概念及关系、主要运行机制、贯穿案例与边界，最后给出简短的心智模型总结。
|
||
|
||
**深入模式**（“系统讲解”“彻底理解”“深入原理”）：加入历史动机、结构图、逐步推演、设计取舍、例外情况、与替代方案的比较，以及迁移问题。内容较多时按照由浅入深的层次组织。
|
||
|
||
可以使用标题、表格、ASCII 图或简洁流程图辅助理解，但只在它们比纯文字更清楚时使用。**不要为了显得系统而扩大篇幅。**
|
||
|
||
## 回答质量检查
|
||
|
||
完成前快速检查：
|
||
|
||
- 用户能否说清“它解决什么问题”，而非仅复述定义？
|
||
- 用户是否知道关键部件/概念之间的关系，而非只记住术语？
|
||
- 用户能否理解一个“条件改变 → 结果改变”的因果推理？
|
||
- 是否给出真实可感的场景和核心适用边界？
|
||
- 是否引入未解释的专业名词，或把类比误认为事实？
|
||
- 是否匹配用户要求的篇幅和深度？
|
||
|
||
如任何一项明显不满足，优先修正解释结构，而不是简单继续追加知识点。
|
||
|
||
## 使用示例
|
||
|
||
- `$what-is-it Kubernetes 是什么？我没接触过容器编排。`
|
||
- `$what-is-it 帮我从零建立对债券市场的整体认知框架。`
|
||
- `$what-is-it 什么是 EtherNet/IP？先讲清它在工业通信体系中的位置。`
|
||
- `$what-is-it 我知道 DNS、域名和 IP，但不理解它们之间如何协作。`
|
||
|
||
输出的目标是让用户最终能够独立回答：**“它是什么、为什么存在、如何运作、什么时候适合、条件变化时会怎样？”**
|