7.9 KiB
name, description
| name | description |
|---|---|
| what-is-it | 从零解释陌生概念、技术、系统或知识领域，帮助用户建立整体认知框架和可用于独立推理的心智模型，而不只是给出定义或堆砌术语。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）
优先回答以下问题，按主题合并组织，不必机械逐条编号：
- 一句话直觉：它是什么？用最少的新术语描述本质。
- 问题与动机：它在解决什么痛点？如果没有它，人们通常如何处理？为什么需要它？
- 系统边界：它是什么、不是什么；与相邻概念、替代方案有什么关系？
- 组成和结构：核心部分有哪些？分别承担什么职责？它们之间的关系是什么？
尽量给出一幅可记忆的文字地图：例如“输入 → 关键环节 → 输出”，或“核心对象 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，但不理解它们之间如何协作。
输出的目标是让用户最终能够独立回答：“它是什么、为什么存在、如何运作、什么时候适合、条件变化时会怎样？”