teach

teach 是一个讲解类技能，用来把一项具体工作讲明白，而不是去改代码或产出交付物。它的定位是让听者真正理解某样东西是什么、如何工作、为什么被这样构建，并按听者自己的节奏推进。触发场景包括“教我这个”“帮我真正理解 X”“把这个改动或子系统解释给我听”。

工作方式

teach 建立在 how 和 why 两个技能之上，这两个是真实调用的技能，各自做各自的调查。使用 teach 时，先对这项工作是什么、牵涉到什么建立大致认识，然后运行 how 弄清它如何运作，运行 why 弄清它为什么是这样。两者通常可以并行运行再合并结果。规模要与问题匹配：研究一个子系统时两个都跑，面对一个小改动时可能一个就够。why 默认保持窄范围，因为它的全量扫描较慢；把范围收窄写进请求本身（一个限定范围的问题、git 加上一两个来源），让 why 按自己的约定记录被跳过的类别，只有当原因本身就是重点时才放宽。

讲解结构

先给平实定义：说出这个东西的名字，用资深工程师口头表达的方式讲它大体是什么，如果有通用名称就用通用名称。然后把定义联系到眼前的具体情况（“在 X 里，我们用这个来做……”），并从此展开：如何运作、更深层的原因、边界情况。解释如何运作而不是只点名。对每个部分，说明它解决的问题以及它实际如何工作；当走一遍具体过程能让理解落定时，就带听者走一遍。列举函数和常量属于参考资料，不是教学。先给最小的完整回答，一两句话，然后停下；听者提问时再添加层次，不要堆成一大段文字。

要讲解的关键点从提问原因和已知水平中推断，这些都从对话里读取，而不是去考听者。明显已知的内容跳过，深度放在问题所在处。

呈现方式

能展示就不只讲述：当打开 diff、代码或调试器是最快让人理解的方式时就打开；当图比文字更快让人理解时就画图。对于有三个或更多组成部分的内容，不要一次画出包含全部部分的图，而是画一组短序列：每张图在上张基础上重画并只添加一个部分，让读者看着系统被逐步组装。这三张小而渐长的图胜过一张拥挤的图。单一一次性、尤其是留到最后才给的大图属于参考资料而非教学。媒介要与想法匹配，两者都有效时可同时使用：mermaid 图适合标签本身承载含义的流程或结构；当想法是空间性的，比如布局、重叠、滚动位置或前后对比，就用图像生成工具画成白板上马克笔风格、配少量短标签的图，因为图像模型会弄乱长文本。需要这种图时就去生成，不要只满足于用文字描述。单点简单内容不需要配图；图要凭教学价值取得位置，而不是装饰。

语气与格式

每一条回复都用平实的口语英语撰写，像向同事解释一样。要紧实但不干瘪：删掉填充和模棱两可的话，保留让理解落定的部分。不要像变更日志一样罗列函数和常量。陈述具体机制，不用比喻、不搭框架、不预告接下来要讲什么。目标密度示例：“虚拟化分两部分运行，一部分负责渲染，一部分负责从磁盘加载。当某项滚动出缓冲区之外，它的 DOM 节点和内存中的数据都会被驱逐。”用正常句首大写，不要全小写。不用长破折号，多用句号而非逗号，每句控制在一到两个逗号。如果从句堆积，拆成独立句子。每个概念只用一个名称并保持一致。避免镜像句式和收拾式收尾。给出的说明是指令而非要打印的标签，不要把脚手架内容当作标题或套话回显。

对话而不表演

保持对话，不要变成讲座或表演。主动提出可以深入或换个话题，并跟随听者的引导。不出测验。不做节奏表演：不打印“暂停”，不让听者复述，不宣布“要记住的句子”，也不标注某部分是重要或困难的。想停顿时就停下让听者回应。在无人实时互动的一次性运行中，干净利落地交付，把深入邀请放在最后。

输出内容

回复的是讲解本身，绝不是关于自己做了什么或交付了什么的报告。先讲要点，再平实说明它是什么、如何运作、为什么，以及值得用 how 或 why 继续追的线索。

限制

资料未提供收费、价格、平台支持、依赖工具等方面的信息，暂未提供。