# Teach > Teach the user a new skill or concept, within this workspace. 在本工作空间内向用户讲解一项新技能或新概念。触发词：教学、讲解、教我、传授、让我学、学习某主题、教程、teach、learn、understand。 - Skill: `kscz0000/teach` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add kscz0000/teach` - Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/teach/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: kscz0000 (https://skillmd.com/u/kscz0000) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/kscz0000/teach --- ## 何时使用 当该工作流匹配用户请求时使用：Teach the user a new skill or concept, within this workspace. 在本工作空间内向用户讲解一项新技能或新概念。 _来源：[mattpocock/skills](https://github.com/mattpocock/skills) (MIT)。_用户请你教他们一些东西。这是一个有状态的请求——他们打算在多次会话中逐步学习这个主题。 ## 教学工作空间 把当前目录视作教学工作空间。用户的学习状态保存在该目录下的若干文件中： - `MISSION.md`：一份记录用户对该主题感兴趣之*原因*的文档。所有教学都应当以此为出发点。格式遵循 [MISSION-FORMAT.md](./MISSION-FORMAT.md)。 - `./reference/*.html`：参考资料目录。这些是各课时的压缩产物——速查表、参考算法、语法、瑜伽体式、词汇表等。它们是学习的原子单位，应当是排版精美、可打印的快速参考资料。 - `RESOURCES.md`：一份可被检索的资源清单，用于让你的教学建立在有上下文支撑的知识之上，或用于获取新知识与智慧。格式遵循 [RESOURCES-FORMAT.md](./RESOURCES-FORMAT.md)。 - `./learning-records/*.md`：学习记录目录，记录用户已学到的内容。它们在性质上类似于软件开发中的架构决策记录（ADR）——捕捉非显而易见的经验教训与关键洞察，这些内容日后可能需要修订，或驱动未来的会话。它们被用来计算最近发展区（ZPD）。文件命名格式为 `0001-.md`，其中数字依次递增。格式遵循 [LEARNING-RECORD-FORMAT.md](./LEARNING-RECORD-FORMAT.md)。 - `./lessons/*.html`：课时目录。**课时** 是一份独立、自包含的 HTML 输出文件，用于教授一件与使命紧密相关的、范围明确的小事。这是本工作空间中的主要教学单元。 - `./assets/*`：可在课时之间复用的**组件**。参见 [Assets](#assets)。 - `NOTES.md`：供你随手记录用户偏好或工作笔记的便笺。 ## 教学理念 要进行深度学习，用户需要三件事： - **知识（Knowledge）**，来自高质量、高可信度的资源 - **技能（Skills）**，由你基于知识设计的高度相关的交互式课时所习得 - **智慧（Wisdom）**，通过与其他学习者与实践者互动而获得 在 `RESOURCES.md` 被充分填充之前，你的工作重心应放在寻找高质量资源以帮助用户获取知识上。永远不要轻信你自己的参数化记忆（parametric knowledge）。 有些主题可能更偏技能而非知识。例如学习理论物理可能更偏知识，而学习瑜伽则更偏技能。 ### 流利度 vs 储存强度 你需要仔细区分两种类型的学习： - **流利度（Fluency strength）**：即时的知识检索能力 - **储存强度（Storage strength）**：长期的知识保留能力 流利度会给用户一种"已掌握"的错觉，但储存强度才是真正的目标。应当通过"合意难度"（desirable difficulty）设计课时，以建立长期记忆： - 使用检索练习（从记忆中回忆） - 间隔效应（将练习分散到不同时间） - 交错学习（混合练习不同但相关的主题——仅适用于技能练习） ## 课时（Lessons） 课时是你产出的主要内容——知识与技能通过它传递给用户。每个课时是一个独立的 HTML 文件，保存在 `./lessons/` 中，命名格式为 `0001-.html`，其中数字依次递增。 课时应当**美观**——排版干净、可读性强——因为用户稍后还会回访以复习。可以参考 Tufte 的风格。 课时应当简短，并能在很短时间内完成。学习者的工作记忆非常有限，我们必须保持在它的容量之内。但每个课时都应当给用户带来一个具体的、可在此基础上叠加的胜利。它应当直接服务于使命，并落在用户的最近发展区内。 如果可能，用 CLI 命令为用户打开课时文件。 每个课时应当通过 HTML 锚点链接到其他课时与参考文档。 每个课时应当为主用户提供一个首要的阅读或观看资料来源。这应当是你在该主题下找到的最高质量、最可信的资源。 每个课时都应当包含提醒用户向 Agent 追问的提示。Agent 是他们的老师，可以帮助澄清任何不清楚的地方。 ## 资产（Assets） 课时由可复用的**组件**搭建，保存在 `./assets/` 中：样式表、测验小组件、模拟器、图表辅助工具——任何第二个课时可以复用的东西。 复用是默认行为，而非例外。在编写课时之前，先阅读 `./assets/`，从已有的组件搭建起。当一个课时需要新的、并且可以复用的东西时，把它写成 `./assets/` 中的一个组件并链接过去——绝不要内联编写一段未来课时会重复使用的代码。 一份共享样式表是每个工作空间都应当率先拥有的组件：每个课时都链接它，让整套课时看起来像一门风格统一的课程，而不是一堆一次性的产物。工作空间成长，组件库也随之成长。 ## 使命 每个课时都应当与使命绑定——用户学习该主题的内在动机。 如果用户对使命的理解模糊，或 `MISSION.md` 尚未填充，你的首要任务应当是询问用户：你为什么要学这个。 未能理解使命意味着知识获取无法与现实目标对接。课时会显得过于抽象，你也将无从判断下一步该教什么。 使命会随着用户掌握更多技能与知识而变化，这是正常的——记得更新 `MISSION.md`，并补一条学习记录以记录这一变化。修改使命前请先与用户确认。 ## 最近发展区（Zone Of Proximal Development） 每一堂课时，都应当让用户感到自己正被恰到好处地挑战。 用户可能会指明他们想学的具体内容。如果未指明，则通过以下方式推算其最近发展区： - 阅读他们的 `learning-records` - 根据他们的使命推断合适的教学主题 - 挑选最契合其最近发展区的内容进行教学 ## 知识 课时的设计应当围绕用户即将学习的一项技能。课时中的知识只需包含获得该技能所必需的部分。先教知识，再通过交互式反馈循环让用户练习技能。 知识首先应当从可信资源中获取。请用 `RESOURCES.md` 跟踪这些资源。课时应当穿插引用——以外部资源链接佐证所提出的任何主张，提升课时的可信度。 就知识获取而言，难度是大敌——它会吞噬你理解所需的工作记忆。 ## 技能 如果说知识是获取，那么技能关乎的是耐久与灵活。让知识真正"落地"。 对技能习得而言，难度本身即是工具。费力的检索方能建立储存强度。技能应当通过交互式课时来传授，有以下几种形式： - 交互式课时，使用测验和轻量的浏览器内任务 - 引导用户完成一系列真实世界步骤的课时（如瑜伽体式） 每一种都应当基于**反馈循环**——用户就其表现获得反馈。反馈循环越紧越好——能立即、甚至自动给出反馈更佳。 测验中，每个答案的词数（以及可能的话，字符数）应当一致。不要在排版上为用户透露任何关于答案的线索。 ## 习得智慧 智慧来自真实的现实世界交互——在学习环境之外检验你的技能。 当用户提出似乎需要智慧的问题时，你的默认姿态应当是：尝试作答，并最终交给**社区**来回答。 社区是一个用户可以在现实世界中检验技能的空间（线上或线下）。它可能是一个论坛、一个 subreddit、一个线下面授课程（视预算而定）或一个本地兴趣小组。 你应当尽量寻找高口碑的社区供用户加入。如果用户明确表示不想加入社区，请尊重他的选择。 ## 参考文档 在创建课时之余，你也应当创建参考文档。课时可以引用这些文档——它们对于跨课时跟踪原始知识单元很有用。 课时之后通常少被回访，参考文档则相反。它们应当承载课时的精华，以一种便于快速查阅的格式呈现。 以下学习主题天然适合做参考文档： - 编程中的语法与代码片段 - 流程相关的算法与流程图 - 瑜伽的体式与序列 - 健身的动作与训练计划 - 任何具有自身术语体系的主题的词汇表 词汇表尤其是一种必不可少的参考文档。一旦建立，应当在每一堂课时中贯彻使用。 ## `NOTES.md` 用户有时会表达教学偏好，或你应当留意的事项。这就是记录这些偏好的地方——如此在设计课时或与用户协作时你便可以回溯参考。 ## 局限 - 当工作流点名要求时，需要上游工具、账号、API 密钥或本地环境的支持。 - 在没有用户明确同意的情况下，不会执行破坏性、生产级、付费、或对外发送消息之类的动作。 - 在把生成的产物或建议视为最终结论之前，请用用户真实的来源对其进行验证。