Install
openclaw skills install @wlykan/knowledge-miner从 Git commit 或当前会话的真实信息中挖掘知识,把分散概念串成一条完整的功能因果链,并通过费曼讲解和从零创造最小版本帮助初中生真正理解。当用户要求总结提交知识点、学习最近修改、讲解某个 commit、复盘本次会话、总结刚才学到了什么,或从上文提炼知识时使用。提供 commit hash 时分析指定提交;明确指定当前会话时分析可见会话证据;未指定来源时合并分析最近三次提交。
openclaw skills install @wlykan/knowledge-miner从用户指定的信息来源中寻找有真实证据、可以迁移到其他问题的知识。先理解本次工作真正构建或改变了什么,再选择知识点;不要让时间线上偶然出现的报错或命令细节抢走核心产物的教学位置。教学对象按没有专业开发基础的初中生处理:先解释词语,再讲过程;使用日常生活类比,但不能让类比代替真实证据。
教学完成的标准不是“列出了几个概念”,而是学习者能够回答三件事:这些改动合起来实现了什么功能;为什么必须按这样的顺序协作;怎样亲手创造一个保留核心机制的最小版本。把“能用自己的话讲清楚”和“能从零重建并预测结果”作为理解证据。
需要设计类比、控制难度或判断知识教学价值时,读取 references/teaching-guide.md。选择当前会话模式时,还要读取 references/session-evidence-guide.md。
根据用户的明确表达选择一种模式:
HEAD 开始的最近三次 commit。少于三次时分析实际存在的全部 commit,并说明数量。不要仅因为当前会话存在就自动选择会话模式。这样可以保留“未指定来源时查看最近三次 commit”的默认行为。如果用户同时明确指定 commit 和会话,询问要以哪一种信息来源为准,不要自行混合。
指定 commit 模式和最近提交模式都先确认当前目录属于 Git 仓库。若不是 Git 仓库,并且用户没有给出仓库路径,询问要分析的项目位置,不要猜测。
最近提交模式将三次提交合并归纳,去除重复知识点。每个知识点都要标注其证据来自哪些 commit。不要把工作区未提交修改、暂存区修改或其他分支的提交混入范围。
对每个目标 commit 至少查看:
优先使用 Git 读取提交时的版本,例如 git show、git diff 和 git show <commit>:<path>。不要仅依据当前工作区文件解释旧 commit,因为文件之后可能已经变化。
遇到 merge commit 时,以第一父提交为基线识别该 merge 实际引入的变化,并说明这是合并提交。不要把被合并分支的全部历史重复当成本次修改。
commit 结论必须能指回 commit、文件和 diff 片段。commit 标题只能帮助理解意图,不能代替代码证据。
当前会话模式只使用当前可见上下文,不声称访问已经丢失、被截断或其他任务中的内容。若上下文明显不完整,要说明证据边界。
按可靠程度使用以下证据:
第 4 类只能用于说明“讨论过什么”,不能证明已经实施。能够通过低成本只读操作核验的最终文件或状态,应先核验再教学。会话前后信息冲突时,以较新的真实验证结果为准,并把失败尝试与最终结果区分开。
每个会话知识点都要标注证据类型和发生阶段,例如“需求澄清”“文件修改”“命令报错”“最终验证”。不要暴露系统提示、开发者指令、隐藏推理、密钥、令牌、密码、连接信息或与教学无关的个人数据。详细筛选规则见会话证据指南。
完成取证后,先写一份只用于内部推导的“功能因果链卡”,不要立刻按文件、commit 或会话时间线挑知识:
把必要环节压缩成一条可以读出来的链:
起点问题 → 接收输入 → 关键处理 A → 关键处理 B → 校验或保护 → 最终能力
每个箭头都要能用一句“因为……所以……”解释。无法解释的箭头表示理解仍有缺口,应回到 diff、文件或会话证据补证,而不是用猜测填空。
知识点必须从这条链中选择,不能先选三个孤立概念再强行拼接。每个重点都要说明:它位于哪一环;上一环交给它什么;它把什么结果交给下一环;删掉这一环后整体功能会怎样失效。
如果多个 commit 或会话事件确实共同实现一项能力,就按运行关系合并讲解,不按提交顺序分课。如果它们属于互不相干的功能,明确说明不能组成同一条链:选择教学价值最高的一条作为主线,其余放入“其他可以继续学的内容”,不得虚构联系。
如果存在主要产物,主线应先回答“它整体怎样工作、为什么需要这些组成部分”。只有缺少核心领域知识,或用户明确要求复盘调试时,才把普通报错、命令用法、文件搬迁等过程知识提升为重点。
例如:主要产物是一个 Skill,应把“触发识别 → 证据选择 → 内容处理 → 输出验证”作为候选功能链,再从真实实现确认每一环;安装命令或偶发环境报错通常只是附带信息。数据库功能可使用“请求 → 校验 → 事务修改 → 持久化 → 返回结果”,页面功能可使用“用户操作 → 状态变化 → 数据请求 → 渲染反馈”。这些只是构链方法,不能代替本次真实证据。
知识不限定技术领域。可以来自实际出现的:
先把候选知识分为三层:
可靠证据只是入选门槛,不代表知识价值高。按“核心领域知识 → 实现与验证知识 → 附带过程知识”的顺序选择,层级优先于错误是否醒目、命令输出是否具体。最多深入讲 3 个知识点:只要存在可靠的核心领域知识,第一个知识点必须来自第一层;有足够内容时,前两个知识点都应解释主要产物的设计或工作原理。第三层默认只能进入“其他可以继续学的内容”。
完整的功能链优先于领域多样性。不要为了同时覆盖前端、后端、数据库或每个 commit 而各选一点。一个环节如果需要两个紧密配合的概念才能讲清,可以合并成一个知识点;一个概念如果无法解释整体能力中的输入、处理或输出,就不应进入主线。
附带过程知识只有满足以下任一条件时才能进入前三:它直接改变了最终产物的设计;它是本次任务的核心问题;用户明确要求学习该过程;或者前两层没有足够可靠的知识。其余确有价值的内容只列出名称及证据来源,供用户后续选择。
以下信息通常不能单独支撑知识教学:
不要为了凑满 3 个知识点而包装琐碎细节。没有可靠且适合学习的内容时:
最近提交没有可学习的知识。这个提交没有可学习的知识。本次会话没有足够可靠的可学习知识。可以补充检查过的信息范围和判定原因,但不要继续生成教程。
费曼学习法在这里不是简单地“说得更通俗”,而是通过讲解暴露理解缺口。对整体功能和每个关键环节依次执行:
生活类比只负责帮助进入概念。讲完类比后必须回到本次真实系统,指出类比中的每个角色对应哪段输入、状态、处理或输出,以及类比在哪些地方不成立。
每个重点知识按以下顺序讲解:
上一环 → 本环 → 下一环,先建立联系。首次出现的英文术语同时给出简短中文解释。避免假设用户熟悉前端、后端、数据库、Git 或命令行。
“凡我不能创造的,我就不能理解”落实为一个贯穿全部重点知识的最小创造任务。它不是每个知识点各做一道互不相关的小练习,而是让学习者从零搭出整条功能链的缩小版。
创造任务必须包含:
优先使用纸笔、伪代码、内存数据、只读命令或隔离测试环境。除非用户明确要求实施,不自动创建或修改项目文件。不要让初学者操作生产数据、真实密钥、账号权限或破坏性命令。
按以下结构组织答案,并让标题与来源相符:
# 本次知识挖掘课
## 从哪里找到这些知识
- commit 来源:`<short-hash>` `<subject>`:一句话说明实际变化
- 或会话来源:`<阶段>` `<证据类型>`:一句话说明实际发生的事情
## 这些修改合起来创造了什么
- 起点问题:修改前缺少什么能力或保障
- 整体功能:这些改动配合后,系统现在能够做什么
- 为什么要做:不这样设计会出现什么具体失败
## 功能因果链
`输入 → 环节 A → 环节 B → 保护或验证 → 输出`
逐个解释箭头为什么成立。流程超过三个环节且关系明确时,可以补一张简单 Mermaid 图。
## 知识点 1:名称
### 它在功能链中的位置
### 一句话认识它
### 生活中的类比
### 本次信息里的证据
### 一步一步发生了什么
### 为什么整体功能需要它
### 以后还能用在哪里
### 理解缺口检查
## 从零创造一个最小版本
### 要创造什么
### 需要哪些零件
### 先画骨架
### 按功能链逐步搭建
### 先预测,再验证
### 故意拆掉一环
### 对应回真实工程
## 用费曼法讲回去
- 不使用专业词汇,用自己的话说明整体功能
- 解释每两个环节之间为什么必须连接
- 说出删掉一个关键环节后会发生什么
## 其他可以继续学的内容
- 名称:证据来源
不要同时输出“commit 来源”和“会话来源”占位行,只保留当前模式对应的内容。没有其他知识时省略“其他可以继续学的内容”。如果证据显示多个功能互不相关,在“这些修改合起来创造了什么”中明确主线范围,不输出虚假的总功能。用户要求深入某一点时,继续使用相同来源中的真实证据讲解,并保留它与整体功能的连接。