Teach

何时使用

当该工作流匹配用户请求时使用：Teach the user a new skill or concept, within this workspace. 在本工作空间内向用户讲解一项新技能或新概念。

_来源：mattpocock/skills (MIT)。_用户请你教他们一些东西。这是一个有状态的请求——他们打算在多次会话中逐步学习这个主题。

教学工作空间

把当前目录视作教学工作空间。用户的学习状态保存在该目录下的若干文件中：

• MISSION.md：一份记录用户对该主题感兴趣之原因的文档。所有教学都应当以此为出发点。格式遵循 MISSION-FORMAT.md。
• ./reference/*.html：参考资料目录。这些是各课时的压缩产物——速查表、参考算法、语法、瑜伽体式、词汇表等。它们是学习的原子单位，应当是排版精美、可打印的快速参考资料。
• RESOURCES.md：一份可被检索的资源清单，用于让你的教学建立在有上下文支撑的知识之上，或用于获取新知识与智慧。格式遵循 RESOURCES-FORMAT.md。
• ./learning-records/*.md：学习记录目录，记录用户已学到的内容。它们在性质上类似于软件开发中的架构决策记录（ADR）——捕捉非显而易见的经验教训与关键洞察，这些内容日后可能需要修订，或驱动未来的会话。它们被用来计算最近发展区（ZPD）。文件命名格式为 0001-<dash-case-name>.md，其中数字依次递增。格式遵循 LEARNING-RECORD-FORMAT.md。
• ./lessons/*.html：课时目录。课时 是一份独立、自包含的 HTML 输出文件，用于教授一件与使命紧密相关的、范围明确的小事。这是本工作空间中的主要教学单元。
• ./assets/*：可在课时之间复用的组件。参见 Assets。
• NOTES.md：供你随手记录用户偏好或工作笔记的便笺。

教学理念

要进行深度学习，用户需要三件事：

• 知识（Knowledge），来自高质量、高可信度的资源
• 技能（Skills），由你基于知识设计的高度相关的交互式课时所习得
• 智慧（Wisdom），通过与其他学习者与实践者互动而获得

在 RESOURCES.md 被充分填充之前，你的工作重心应放在寻找高质量资源以帮助用户获取知识上。永远不要轻信你自己的参数化记忆（parametric knowledge）。

有些主题可能更偏技能而非知识。例如学习理论物理可能更偏知识，而学习瑜伽则更偏技能。

流利度 vs 储存强度

你需要仔细区分两种类型的学习：

• 流利度（Fluency strength）：即时的知识检索能力
• 储存强度（Storage strength）：长期的知识保留能力

流利度会给用户一种"已掌握"的错觉，但储存强度才是真正的目标。应当通过"合意难度"（desirable difficulty）设计课时，以建立长期记忆：

• 使用检索练习（从记忆中回忆）
• 间隔效应（将练习分散到不同时间）
• 交错学习（混合练习不同但相关的主题——仅适用于技能练习）

课时（Lessons）

课时是你产出的主要内容——知识与技能通过它传递给用户。每个课时是一个独立的 HTML 文件，保存在 ./lessons/ 中，命名格式为 0001-<dash-case-name>.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 密钥或本地环境的支持。
• 在没有用户明确同意的情况下，不会执行破坏性、生产级、付费、或对外发送消息之类的动作。
• 在把生成的产物或建议视为最终结论之前，请用用户真实的来源对其进行验证。