By name: learning-plan description: "TRIGGER FIRST: 学习计划/学习路线/怎么学/系统学习/从零开始/备考/面试准备/求职准备/技能提升/考试复习/课程规划/知识体系梳理 -> use this skill. 生成结构化长期学习计划 JSON + HTML 交互学习应用需求文档，拆分阶段、活动、练习和评估。" allowed-tools: read, write, exec
Learning Plan — 长期学习计划生成
将用户的学习目标转化为两样东西：
- 学习计划 JSON — 描述学什么、怎么学、以什么顺序学
- HTML 交互应用需求文档 — 描述配套的交互式学习应用长什么样、怎么交互
两者通过 html_app_id 关联。
理解输入
用户可能以多种方式提供学习需求：
方式 A：提供资料文件 用户指定一个目录，里面有文本文件作为学习资料。读取所有文件，从中提取知识体系。
方式 B：对话描述 用户直接描述想学什么，如"我想准备 Python 后端面试"或"帮我规划机器学习的学习路线"。此时需要基于自身知识构建知识体系。
方式 C：混合 用户既有资料文件，又有口头补充。两者结合。
无论哪种方式，第一步都是一样的：搞清楚用户要学什么、为什么学、当前水平如何。如果用户没有说清楚这些，主动问。这些信息直接决定计划的深度和广度。
输出
<output_dir>/
├── learning_plan.json # 学习计划主文件
├── html_specs/ # 每个交互应用一份需求文档
│ ├── app_0101_01.md
│ └── ...
└── metadata.json # 元信息
默认输出目录：!echo "${CLAUDE_CONFIG_DIR:-$HOME/.claude}"/workspace/learning-plan/output/
工作流程
第一步：理解知识领域
不管输入是文件还是对话，目标是构建一张知识地图：
- 核心概念有哪些？
- 前置依赖是什么？（学 B 之前必须会 A）
- 难度分布怎样？（哪些是入门级，哪些是进阶）
- 哪些知识适合交互式学习？（下面会展开）
这一步的质量直接决定后面计划的质量。宁可在这里多花时间，也不要急着生成输出。
第二步：规划学习路径
确定计划规模
计划的大小应该匹配学习目标的复杂度：
| 场景 | Phases | Stages/Phase | 总天数参考 |
|---|---|---|---|
| 单个技能点（如"学会用 Git"） | 2-3 | 2-3 | 7-14 天 |
| 中等主题（如"Python 数据分析"） | 3-4 | 3-4 | 30-60 天 |
| 大型体系（如"全栈开发"） | 5-7 | 3-5 | 90-180 天 |
这只是参考，根据实际内容灵活调整。关键原则：每个 Stage 应该是一个用户可以在 1-3 天内完成的学习单元。如果一个 Stage 需要一周才能完成，说明粒度太粗，应该拆分。
学习路径设计原则
这些不是教条，而是经过验证的学习科学原理，理解它们能帮你做出更好的设计决策：
间隔重复（Spaced Repetition） 人的记忆遵循遗忘曲线——新学的东西如果不复习，几天后就忘掉大部分。所以重要概念应该在后续阶段以不同形式出现。比如"递归"在第一阶段作为概念学习，第二阶段在树的遍历中实际应用，第三阶段在动态规划中再次强化。
认知负荷控制（Cognitive Load） 每个学习单元不要同时引入太多新概念。一般来说，一个 Stage 引入 3-5 个新知识点是合适的。如果某个知识点本身很复杂（如"动态规划"），那么这个 Stage 可能只有 1-2 个知识点，但用更多的活动来消化。
主动学习优先 阅读是最被动的学习方式，效果也最差。交互练习、动手实践的记忆留存率远高于被动阅读。所以每个 Stage 应该以交互或练习活动为主，阅读只是铺垫。
及时反馈 学习者需要知道自己学得对不对。每个 Stage 都应该有某种形式的检验——可以是交互式测验，也可以是实践项目。
层级结构
Phase（大阶段）→ Stage（小阶段）→ Activity（学习活动）
- Phase：对应知识体系的一个大模块，有清晰的学习目标和里程碑
- Stage：1-3 天可完成的学习单元，包含若干相关知识点
- Activity：具体的学习动作（阅读、交互、练习、复习）
第三步：选择交互类型
不是所有内容都需要 HTML 交互应用。选择交互的标准是：这个知识点用交互方式学，是否比纯文字/练习明显更好？
| 场景 | 为什么适合交互 | 交互类型 |
|---|---|---|
| 抽象概念（如指针、递归） | 难以靠想象理解，可视化后豁然开朗 | 动画/可视化 |
| 算法流程 | 需要看到每一步的变化 | 步骤模拟器 |
| 术语记忆 | 重复练习比阅读高效 | 翻卡片/配对 |
| 操作技能（如 SQL） | 需要动手试错 | 沙盒/模拟器 |
| 概念辨析（如 stack vs queue） | 对比操作更直观 | 拖拽分类 |
| 综合检验 | 游戏化提高参与度 | 闯关/情景模拟 |
一般来说，一个 Phase 中有 2-4 个交互应用是合理的。过多会导致开发成本高，过少则失去交互式学习的优势。
第四步：生成学习计划 JSON
按照 references/plan_schema.json 的 Schema 生成 learning_plan.json。
结构概览：
learning_plan.json
├── meta # 元信息（ID、标题、时间）
├── overview # 总览（目标、受众、总天数、难度曲线）
└── phases[] # 大阶段
├── phase_id, title, goal, milestone, estimated_days
├── prerequisites[] # 前置阶段
└── stages[] # 小阶段
├── stage_id, title, knowledge_points[]
├── learning_activities[]
│ ├── type: text_reading | html_interactive | practice | review
│ ├── html_app_id # 仅 html_interactive 类型
│ └── estimated_minutes
└── assessment # 阶段评估
关于 JSON 内容的质量要求：
description字段要具体。"学习排序算法"是差的描述；"通过逐步执行冒泡、选择、插入排序，观察每一步的比较和交换操作，建立对 O(n²) 复杂度的直觉"是好的描述。milestone要可验证。"理解链表"不可验证；"能手写链表反转并通过 LeetCode #206"可验证。estimated_minutes要务实。阅读通常 15-30 分钟，交互 20-40 分钟，练习 30-90 分钟。
第五步：生成 HTML 需求文档
为每个 html_app_id 生成独立的 Markdown 需求文档，放在 html_specs/ 目录。
需求文档参考：references/html_spec_example.md
关键质量要求：
- 内容数据必须具体。不要写"题目列表"，而是列出实际的题目内容。不要写"卡片数据"，而是写出每张卡片的正反面。需求文档的读者（可能是另一个 AI 或开发者）需要足够的信息来直接实现这个应用，而不需要再去查资料。
- 交互流程必须完整。从用户打开应用到完成学习，每一步发生什么。
- 界面描述要用 ASCII 布局图。比纯文字描述清晰得多。
第六步：生成元信息并验证
生成 metadata.json（包含生成时间、输入来源、统计数据），然后验证：
- 所有
html_app_id在 JSON 和需求文档之间一一对应 - 阶段依赖关系无环
- 所有必填字段完整
- 输出摘要告诉用户生成了什么
html_app_id 命名规则
格式：app_{phase两位}{stage两位}_{活动序号两位}
app_0101_01→ Phase 1, Stage 1, 第 1 个交互活动app_0203_02→ Phase 2, Stage 3, 第 2 个交互活动- 评估用交互：
app_{phase}{stage}_assess
使用示例
用户：我想准备 Python 后端面试，有三个月时间，目前会基础语法
→ 方式 B，直接从对话构建知识体系
用户：这个目录里是我的课程笔记，帮我做个复习计划
→ 方式 A，从文件提取知识体系
用户：我在学 React，这是官方文档的摘要，另外我还想加上 TypeScript
→ 方式 C，文件 + 对话补充