AI 时代还需要买课吗？我用 Skills + Markdown + HTML 搭了一套自学系统

AI 时代还需要买课吗？我用 Skills + Markdown + HTML 搭了一套自学系统

每一次对话都很有启发，但学习状态很难持续。

今天问了 RAG，明天问了 Agent，后天又让 AI 解释 LangGraph。每次 session 都像一次临时辅导，但长期看，课程目标、学习进度、复盘记录、掌握度评分都散落在不同对话里。

所以我开始做一套自己的 AI 自学系统：

仓库地址：

https://github.com/huajiexiewenfeng/learning-companion-skills

它不是一个复杂 App，也不是一个 Prompt 模板集合。

我更愿意把它理解成：

Skills = 学习流程执行层 Markdown = 本地学习数据层 Static HTML = 学习状态展示层 GitHub = 可选同步和资产沉淀层

这篇文章不是单纯介绍一个工具，而是分享我最近尝试的一种 AI 自学方式：让 AI 不只回答问题，而是长期维护你的学习系统。

1. 我为什么要做这套 AI 自学系统

AI 时代，资料其实不缺。

真正缺的是一套能持续运行的学习系统。

长期学习至少需要回答这些问题：

• 我的最终目标是什么？
• 这门课为什么这样安排？
• 今天应该学什么？
• 今天最低完成标准是什么？
• 学完以后怎么验证？
• 我是“看过了”，还是“真的掌握了”？
• 下次应该继续、复习，还是降低任务难度？
• 学习记录能不能沉淀下来，而不是丢在聊天记录里？

普通 AI 对话很擅长解释知识点，但它不是天然的学习状态数据库。

所以我把系统拆成两段：

一句话概括：

course-designer负责把目标编译成课程，learning-companion负责让课程长期跑起来。

2. 整体效果：从一句目标到一个本地学习看板

最终我希望达到的效果很简单：

用户不是每次都重新问 AI：“我今天该学什么？”

而是可以有一套稳定流程：

1. 说出自己的学习目标 2. AI 引导确认 North Star 3. AI 设计个性化课程 4. 用户确认后导入 learning-companion 5. 自动生成本地 Markdown 学习数据 6. 自动生成 learning-console.html 学习看板 7. 每天回复 1 开始学习 8. 学完回复 下课，进入复盘和打分 9. dashboard / log / map / HTML 看板自动更新

这个系统目前已经能跑通最小闭环。

它不需要数据库，不需要后端服务，也不需要安装复杂软件。学习数据就在本地项目目录里。

典型结构如下：

learning-companion/ index.md learning-console.html plans/ <plan-id>/ dashboard.md map.md log.md

其中：

【截图 ：生成后的learning-companion/目录结构】

【截图 ：learning-console.html静态学习看板， 五个模块】

3. 第一步：用 course-designer 确认 North Star

我不太喜欢从“知识点清单”开始设计课程。

比如：

• 学 RAG
• 学 LangChain
• 学 Java
• 学英语
• 学数学

这些说法都太散。

真正有效的课程应该先问：

学完以后，你到底要形成什么能力？

这就是 North Star。

比如我自己的技术学习目标不是简单“学 RAG”，而是：

打通企业 AI 转型的一条完整架构线路：RAG / Knowledge Runtime -> Role Agent Copilot -> Agentic Workflow 工程化 -> AI Native App 产品化重构 -> Autonomous Operation 受控自治。

这个目标比“学一个框架”更大，也更接近真实工作里的能力要求。

course-designer的作用，就是把这样的目标拆成课程包。

它会引导确认：

• North Star
• 学习者背景
• 时间节奏
• 约束条件
• 阶段划分
• 每个阶段的可见产出
• 第一天从哪里开始
• 如何导入learning-companion

【截图 ：用户输入学习目标，AI 引导确认 North Star】

确认 North Star

【截图 ：course-designer 输出课程包 / 阶段地图 / 导入预览】

4. 第二步：导入 learning-companion，课程变成本地状态

课程设计好以后，不能停留在聊天里。

用户确认导入后，learning-companion会把课程转换成本地文件：

learning-companion/ index.md learning-console.html plans/ <plan-id>/ dashboard.md map.md log.md

这里有一个最近升级的新能力：

导入计划后，默认生成learning-console.html。

也就是说，用户不需要额外再说“创建学习面板”。只要课程导入成功，系统就会同时生成 Markdown 数据和静态 HTML 看板。

这一步很关键。

因为 Markdown 适合 AI 维护，HTML 适合人查看。

Markdown 负责事实 HTML 负责展示 Skill 负责更新

【截图 ：learning-companion 导入计划预览】

【截图 ：导入完成后自动生成learning-console.html】

5. 静态学习看板：不是复杂 App，而是本地状态视图

这次升级里，我最满意的不是“多了一个页面”，而是明确了一个边界：

learning-console.html只是展示层，不是事实来源。

真正的数据来源仍然是：

dashboard.md map.md log.md index.md

HTML 里只维护一个结构化数据块：

window.learningData={generatedAt:"",workspace:"",sourceFiles:[],plans:[],activePlanId:"",dashboard:{},today:{},mapItems:[],logEntries:[],contentPreview:{},masteryStats:{}}

刷新看板时，Skill 不需要重写整个 HTML，也不需要改 CSS 或布局，只需要更新window.learningData。

这对 AI Agent 很友好。

因为让 AI 改一整页 HTML，风险很高；但让 AI 更新一个结构化数据对象，风险低很多。

看板目前只展示五个模块：

这里我刻意删掉了一些看起来“像产品”的指标。

比如：

• 累计学习时长
• 补救次数
• 阻塞状态
• 复杂的 rescue 流程看板

原因很简单：

没有稳定数据来源的指标，不应该出现在 dashboard 里。

这也是我希望这套系统保持克制的地方。它可以慢慢演进，但不能为了看起来完整而造数据。

6. 每天怎么用：回复 1，开始学习

长期学习系统最怕每天启动成本太高。

所以learning-companion设计了一个低摩擦协议：

当用户回复：

1

系统会做两件事：

1. 把今天的学习状态更新为 studying
2. 如果learning-console.html已存在，自动刷新window.learningData

注意，这里不会重写 HTML 布局。

它只更新数据块。

这意味着用户打开学习看板以后，可以看到当前学习状态已经变化。

7. 下课复盘：真正判断是否掌握

我认为下课是这套系统里最重要的设计之一。

因为很多学习系统最大的问题是：

听懂了，被当成学会了。

但真正的学习应该经过复述和验证。

当用户回复：

下课

learning-companion会进入 close-out review：

1. 让用户用一句话说出今天学懂了什么
2. 问 1-3 个验证问题
3. 根据回答给 mastery score
4. 更新dashboard.md
5. 更新log.md
6. 必要时更新map.md / index.md
7. 如果learning-console.html已存在，自动刷新window.learningData

这里有一个边界也很重要：

老师模式不会直接推进 effective progress。只有下课复盘后的评分，才会影响有效进度。

这让系统不会把“AI 讲了一遍”误判成“用户真的掌握了”。

【截图 ：用户回复下课后，AI 提出复盘问题】

【截图 ：复盘后log.md更新】

【截图 ：下课后 HTML 看板自动刷新】

8. Teacher Mode：AI 可以教，但不能替你掌握

learning-companion不是一个纯记录工具。

当用户说：

继续学习 你来教我 我不明白 换个例子 老师模式

它会读取当前 dashboard，围绕今天的学习项做轻量教学。

比如今天学的是chunk 与 metadata，老师模式不会泛泛讲 RAG，而是会围绕：

• chunk 是什么
• metadata 为什么重要
• 它们如何影响召回
• 错误 metadata 会造成什么问题
• 如何用一个例子检查是否理解

老师模式的流程很短：

1. 用简单语言说明核心概念
2. 连接到学习者当前计划或项目
3. 给一个具体例子
4. 点出一个常见误区或边界
5. 只问一个检查问题

但它只负责“教”。

真正的状态更新，还是要回到下课复盘。

9. 技术设计：为什么是 Skills + Markdown + HTML

我没有一开始就做一个完整 Web App。

原因是：这套系统的核心问题不是界面，而是流程。

如果流程不清楚，做成 App 也只是更漂亮的空壳。

所以我先选择了更轻的架构：

这套架构有几个好处：

• 用户不需要安装复杂系统
• 所有学习数据都在自己的 workspace
• Markdown 可读、可改、可版本管理
• HTML 可以直接打开
• GitHub 可以作为长期资产库
• AI Agent 更新结构化数据比维护复杂应用更稳定

换句话说：

这不是把 AI 包成一个 App，而是让 AI Skill 直接参与维护你的学习状态。

10. 我的真实学习记录

我自己用它管理过一个学习计划：

Agent/RAG Knowledge Runtime 转行计划

当前记录：

部分 mastery score：

这份记录最大的价值，不是证明我学了多少，而是让我知道：

• 哪些主题只是看过
• 哪些主题能解释
• 哪些主题能迁移到项目
• 哪些主题没有达到有效掌握
• 下一步应该学什么

【截图 ：真实learning-companionlog / mastery score 记录】

11. 不只适合技术学习

这套系统不是只为技术学习设计的。

因为它抽象的是“学习状态”，不是某个学科。

技术学习里，今天的任务可能是：

孩子的一年级应用题课程里，今天的任务可能是：

一个是技术学习，一个是小孩数学。

但它们背后的学习状态模型是一样的：

• 今天学什么
• 最小完成标准是什么
• 怎么验证掌握
• 当前进度是多少
• 下次应该如何继续

【截图 ：小孩应用题课程 dashboard】

截图2

12. GitHub 化：把学习变成可积累资产

我现在还会把学习计划和笔记同步到 GitHub。

相关仓库：

• learning-companion-skills：存放course-designer和learning-companionskills
• enterprise-ai-transformation-runtime：存放我的企业 AI 转型学习计划、笔记和后续作品集材料

这样学习过程就不只是聊天记录，而是逐步变成可积累资产：

• 课程计划
• 学习日志
• 阶段复盘
• 架构图
• schema
• demo
• 作品集 README

【截图 ：enterprise-ai-transformation-runtime仓库 README】

13. 总结：AI 时代，自学能力应该产品化

我越来越觉得，AI 时代真正重要的不是“会不会问问题”。

更重要的是：

能不能用 AI 给自己搭一套长期运行的学习系统。

这套系统不一定一开始就是复杂产品。

它可以很轻：

用 Skill 执行流程 用 Markdown 保存事实 用 HTML 展示状态 用 GitHub 沉淀资产

course-designer + learning-companion还只是早期版本，但它已经表达了一个我很认同的方向：

AI 不只是帮我们回答问题，也可以帮我们维护自己的成长系统。

以后学习不一定要从买课开始。

更好的起点可能是：

1. 确认自己的 North Star
2. 定制适合自己的课程
3. 导入长期学习系统
4. 每天完成一个小任务
5. 学不会时进入老师模式
6. 学完后下课复盘并打分
7. 让学习记录和看板自动更新
8. 把学习过程沉淀成自己的长期资产

这才是 AI 时代更值得掌握的自学能力。