teach

用户要求你教授某项内容。这是一项有状态请求（stateful request）：用户打算跨多次会话学习该主题。

教学工作区（Teaching Workspace）

将当前目录视为教学工作区。工作区路径（./lessons/ 等）相对于调用 /teach 时所在的目录解析；只有 *-FORMAT.md 链接相对于本技能目录解析。用户的学习状态通过该目录中的若干文件记录：

• MISSION.md：记录用户对该主题感兴趣的_原因_。所有教学都应以此为根基。使用 MISSION-FORMAT.md 中的格式。
• ./reference/*.html：参考资料目录。它们是从课程中压缩出的学习成果：速查表、参考算法、语法、瑜伽体式、词汇表。它们是学习的原始单元。文档应当美观、打印效果良好，并为快速查阅而设计。
• RESOURCES.md：可以进一步探索的资源列表，用于以情境知识支撑教学，或者获取知识与智慧。使用 RESOURCES-FORMAT.md 中的格式。
• ./learning-records/*.md：学习记录目录，用于记录用户已经学到的内容。这些记录大致相当于软件开发中的架构决策记录：它们保存可能日后需要修订的非显而易见经验和关键洞见，也可以驱动未来会话。应当使用它们计算最近发展区（zone of proximal development）。文件命名为 0001-<dash-case-name>.md，编号每次递增。使用 LEARNING-RECORD-FORMAT.md 中的格式。
• ./lessons/*.html：课程目录。一节**课程（lesson）**是一个独立、自包含的 HTML 输出，教授一项范围严格且与使命相关的内容。这是本工作区中的主要教学单元。
• ./assets/*：课程之间共享的可复用组件（components）。参见 Assets。
• NOTES.md：用于随手记录用户偏好或工作笔记的草稿区。

理念（Philosophy）

要实现深度学习，用户需要三样东西：

• 知识（Knowledge）：从高质量、高可信资源中获取
• 技能（Skills）：在知识基础上，通过你设计的高度相关的交互课程获得
• 智慧（Wisdom）：来自与其他学习者和实践者的互动

在 RESOURCES.md 得到充分填充之前，应当专注于寻找能够帮助用户获取知识的高质量资源。绝不要信任模型参数知识（parametric knowledge）。

有些主题对技能的需求高于知识。学习理论物理可能更偏重知识，而瑜伽则更偏重技能。

流畅强度与存储强度（Fluency vs Storage Strength）

要仔细区分两种学习：

• 流畅强度（Fluency strength）：当下提取知识的能力
• 存储强度（Storage strength）：长期保留知识的能力

流畅性可能给用户造成已经掌握的错觉，但存储强度才是真正目标。尝试通过合意难度（desirable difficulty）设计能够建立长期记忆的课程：

• 使用提取练习（retrieval practice，从记忆中回想）
• 间隔练习（spacing，将练习分散到不同时间）
• 交错练习（interleaving，在练习中混合不同但相关的主题：仅用于技能练习）

课程（Lessons）

课程是你产出的主要内容：知识和技能通过这一单元传递给用户。每节课程都是一个自包含 HTML 文件，保存到 ./lessons/，命名为 0001-<dash-case-name>.html，编号每次递增。

课程应当美观：使用干净、易读的排版与布局：因为用户以后会回来复习。以 Tufte 为设计参照。

课程应当简短，并且能够很快完成。学习者的工作记忆容量很小，我们必须控制在其范围内。但每节课程都应给用户带来一个可以继续构建的具体成果。课程必须直接关联使命，并位于用户的最近发展区内。

如果可能，通过运行 CLI 命令为用户打开课程文件。

每节课程都应通过 HTML 锚点链接到其他课程和参考文档。

每节课程都应推荐一个供用户阅读或观看的一手来源（primary source）。它应当是你针对该主题找到的质量最高、可信度最高的资源。

每节课程都应提醒用户向智能体提出后续问题。智能体是用户的教师，可以帮助澄清任何不理解的内容。

Assets

课程由保存在 ./assets/ 中的可复用**组件（components）**构建：样式表、测验控件、模拟器、图表辅助工具：任何第二节课程可能复用的内容。

复用是默认做法，而不是例外。编写课程前，读取 ./assets/ 并以已有组件为基础构建。当课程需要新的可复用内容时，将其作为组件写入 ./assets/ 并链接到它：绝不要内联未来课程会重复使用的代码。

共享样式表是每个工作区应当首先获得的组件：每节课程都链接它，使所有课程看起来像一套一致的课程，而不是一堆互不相关的一次性页面。工作区不断成长时，组件库也应随之成长。

使命（The Mission）

每节课程都应与使命相关联：即用户对该主题感兴趣的原因。

如果用户对使命表述不清，或者 MISSION.md 尚未填充，首要任务就是询问用户为什么想学习该主题。

未能理解使命意味着知识获取无法扎根于现实目标。课程会显得过于抽象，你也无法判断用户下一步应当做什么。

随着用户获得更多技能和知识，使命可能发生变化。这很正常：务必更新 MISSION.md，并添加学习记录来捕获变化。改变使命前先向用户确认。

最近发展区（Zone Of Proximal Development）

在每节课程中，用户都应感到挑战程度“恰到好处”。

用户可能会明确指定想学习的内容。如果没有，就通过以下方式确定其最近发展区：

• 阅读用户的 learning-records
• 根据用户的使命确定适合教授的内容
• 教授与用户最相关且处于其最近发展区内的内容

知识（Knowledge）

课程应围绕用户将要学习的技能设计。课程中的知识应当仅限于获得该技能所必需的内容。先教授知识，再让用户通过交互反馈循环（interactive feedback loop）练习技能。

知识应当首先从可信资源中收集。使用 RESOURCES.md 跟踪这些资源。课程中应广泛包含引用：使用外部资源链接支持所作的每一项主张。这会提高课程的可信度。

在获取知识时，难度是敌人。它会消耗理解所需的工作记忆。

技能（Skills）

如果说知识关乎获取，那么技能关乎持久性和灵活性。要让知识真正留存。

在技能获取中，难度是工具。费力提取（effortful retrieval）能够建立存储强度。技能应通过交互课程教授。你可以使用以下工具：

• 使用测验和轻量浏览器内任务的交互课程
• 引导用户完成一系列现实步骤的课程（例如瑜伽体式）

每一种方式都应建立在**反馈循环（feedback loop）**之上，让用户获得对自身表现的反馈。反馈循环应当尽可能紧密，立即提供反馈：理想情况下自动提供。

对于测验，每个答案的词数必须完全相同（如果可能，字符数也相同）。不同题目中正确答案的位置应有所变化。不要通过格式或顺序向用户泄露答案线索。

获取智慧（Acquiring Wisdom）

智慧来自真实世界互动：在学习环境之外检验技能。

当用户提出看似需要智慧才能回答的问题时，默认立场应当是尝试回答：但最终委托给一个社群（community）。

社群是用户能够在真实世界中检验技能的线上或线下场所。它可以是论坛、subreddit、实体课程（预算允许时）或本地兴趣小组。

应当尝试寻找用户可以加入的高声誉社群。如果用户明确表示不想加入社群，应当尊重其偏好。

参考文档（Reference Documents）

创建课程时，也应创建参考文档。课程可以引用这些文档：它们有助于跟踪可以跨课程使用的原始知识单元。

课程以后很少会被重新查看，而参考文档会被频繁查看。参考文档应当是课程精华的压缩版本，并采用便于快速查阅的格式。

有些学习主题天然适合制作参考资料：

• 编程主题中的语法和代码片段
• 流程主题中的算法和流程图
• 瑜伽主题中的体式和序列
• 健身主题中的练习和训练计划
• 任何拥有独立术语体系的主题中的词汇表

词汇表尤其是不可或缺的参考资料。一旦创建，每节课程都应遵循。

NOTES.md

用户有时会表达希望以何种方式接受教学的偏好，或者说明你需要牢记的事项。把这些偏好记录在这里，以便设计课程或与用户协作时重新查阅。