SKILL.md 6.4 KB


name: course-factory tags: [education, course-development, knowledge-base, llm-wiki, repo-management] creator: 传鹏 description: |- 做课系统总入口。以 llm-wiki 思路管理的课程开发知识库:原材料单向进入 → LLM 整理成结构化 md 知识库 → 从库里取材生成课程。负责整体激活、状态诊断、意图分流与库维护编排。

触发词:做课系统、知识库、同步资料、增量入库、整理资料、做课、开发课程、课程大纲、讲义、检查知识库、库健康、课程工厂、知识库维护、回滚知识库

做课系统 · 总入口

这个系统是什么

一条单向管道:原材料(只进不改)→ 知识库(全 md,LLM 维护)→ 课程产出。

00-原材料/  ──整理──▶  10-知识库/  ──取材──▶  20-课程产出/
 (is input)            (is memory)           (is output)
    ↑                      ↑                      ↑
    └────── 90-工具/kb.py 管结构,30-技能/* 管语义 ──────┘

分工铁律(违反必出错):

谁 管什么 不管什么
kb.py 文件指纹、差异计算、关系图、索引重建、回滚 任何内容语义
你(LLM) 读源、抽取、归纳、写页、写摘要 任何需要"记住"的状态

永远不要让 LLM 用记忆去判断"哪些文件新增了" —— 跑 kb.py scan。这是这套系统和裸聊天的唯一区别。


两种模式,规则相反

进这个库的请求只有两类,判断错了后面全错:

补料(往库里加) 取材(从库里拿)
典型说法 丢了资料、同步、整理、删了源 做一门课、查一下、出大纲、要课件
能不能补充原文件没有的 不能 能(组合、提炼、编排)
出处要求 指回原文件具体段落 每个数字标 [^脚注] 或 [[页面]]
缺东西时 标「待核实」,不许猜 明说「库里没有」,不许编
证据等级 按原文件性质如实定 不得高于所用素材最低级
写完必须 kb.py mark 登记 在 03-缺口与补料.md 记缺口

补料在给库里攒信用,取材在花信用。 补料时随手编一句,三个月后做课就会把它当事实讲给客户。


第 0 步:定位仓库(每次激活必做)

python 90-工具/kb.py status
  • 若报 No such file,说明 cwd 不在仓库根。按顺序探测:① 当前目录含 90-工具/kb.py;② 默认路径 C:\Users\15858\WorkBuddy\2026-11-04-18-25-54\做课系统。
  • 输出会告诉你:原料数、页面数、待处理新增/删除、待重建、陈旧页。
  • status 是唯一可信的库状态来源。不要凭对话历史推断库里有几篇文档。

第 1 步:意图分流

用户说 走哪个技能 判据
"同步""整理新资料""我丢了几个文件" kb-sync 有 pending new/changed
"删了源文件怎么办""清理" kb-sync 的 retract 分支 有 pending gone
"查 XX""库里有没有 XX""关于 XX 的资料" kb-query 只想读
"做一门课""出大纲""要讲义""要 PPT" course-outline → course-slides 要产出
"检查库""有没有问题""整理得乱不乱" kb-lint 维护
"索引不对""找不到页面" kb-index 索引重建
只是问"这系统怎么用" 直接答,别跑脚本 —

分流不确定时,先跑 status,库的状态会告诉你用户大概率想干什么:

  • 有 10 个未入库文件 → 大概想说"同步"
  • 有 3 个 stale → 大概想说"检查/修复"
  • 库是干净的空库 → 大概想"建库/丢资料"

第 2 步:维护编排

日常同步(最高频)

status → scan → 逐个 ingest → graph → lint → 汇报

详见 kb-sync。

每周健康检查

kb.py check → 按问题类型分派修复 → graph

kb.py check 一次跑两件事:

  • kb.py lint 管结构(死链、孤儿、缺字段、证据等级虚高)
  • check-content.py 管内容(AI 腔、长句、没出处的数字)

结构对了不等于能拿去做课。两边都要过。

每月沉淀

  • 看 _meta/changelog.jsonl,找出长期没人访问的 topic 页 → 考虑合并或归档
  • 看 topics/_index.md,检查是否有"同一件事拆成多页" → 合并

全局规则

  1. 先证后写 — 写进知识库的每个事实必须能追到某个源文件的某一段。追不到的标「(推测)」。
  2. 只增不改原材料 — 任何人不得修改 00-原材料/ 里已入库的文件。要改就放新版本进去,让 kb-sync 识别为 NEW,旧版由用户手动清理。
  3. 写完必登记 — 每整理完一个源,必须 kb.py mark <路径> --pages <页面列表>,否则下次还当它是新的,白干一遍。
  4. 删了必回滚 — 源文件消失必须跑 kb.py retract,否则知识库里留下"引用不存在的源"的僵尸页。
  5. 索引不手写 — _index.md 一律由 kb.py graph 生成。要改就改页面 frontmatter。
  6. 做课先查库 — 用户说"做一门课"时,禁止直接凭模型知识写大纲。必须先 kb-query 取材,并在产出里标出每个模块的素材出处。库里没有的,明说"库里缺 X,建议补料",而不是编一个。
  7. 每页必标证据等级 — evidence: A/B/C/D,木桶规则(不得高于来源最低级)。做课的讲授内容里 A+B 不低于 60%,D 级一律不上课件。 这是"课经不经得起追问"的唯一量化保证。
  8. 说"某机构测算",不说"数据显示" — B 级内容当 A 级讲,是这门生意最容易翻车的地方。学员或客户里总有一个人会问"这个数据哪来的"。
  9. 提交前跑 kb.py check — 结构 + 内容两项都过再交付。结构干净但满是"值得注意的是"的知识库,做出来的课一样没人看。

汇报格式

每次操作结束,用这个格式回给用户(不要贴原始 JSON):

这次同步
  新增   3 个源 → 派生了 7 个页面
  变更   1 个源 → 重建 2 个页面
  删除   0
  待重建 0
  健康分 92/100

库里现在:42 页(源 18 / 主题 15 / 实体 6 / 模块 3)
下一步建议:topics/客户画像 还是空的,要不要补一份客户访谈记录?

末尾给一个具体的下一步建议,不要空泛地说"还需要什么随时告诉我"。