把57万字《史记》变成内容生产线：shiji-kb 适合哪些自媒体赛道？
很多历史账号缺的不是选题，而是一个能持续供给、还能反复复用的素材系统。
GitHub 上的 shiji-kb 史记知识库 做的事情，正是把《史记》从一部线性阅读的古籍，拆成可检索、可跳转、可推理、可再创作的知识网络。它不是“输入一个题目，自动生成爆款”的按钮，而是一条更接近内容工厂的生产线。
一、它到底把《史记》拆成了什么？
项目 README 给出的数据口径是：约 57.7 万字原文，14,065 个实体，126,441 次标注，3,198 个历史事件，7,637 条事件关系，以及 130 条交互式时间线。
它的核心思路可以压缩成四层：
1.结构语义：先校勘、分章、编号、切分段落，尽量不破坏原文。
2.图谱语义：识别人名、地名、官职、邦国、时间，抽取事件和人物关系。
3.知识语义：把实体、事件、关系组织成本体、事实和可复用的知识单元。
4.应用语义：把这些知识变成阅读器、时间线、游戏、问答和内容素材。
对应的九步管线是：
校勘 → 结构分析 → 实体构建 → 事件构建 / 关系构建 / 本体构建 → 逻辑推理 → 知识单元化 → 应用构造
这也是它最值得自媒体人学习的地方：先把素材结构化，再开始写内容。
二、真正有用的三个能力
1. 把“查资料”变成可复用的检索
阅读器支持实体高亮、段落锚点和索引跳转；“史记地铁图”把 130 篇篇章和 3,000 多个事件站点放到一张时间线里。你不必每次从头翻书，而是可以围绕一个人物、一个地点或一场战争，迅速拉出相关章节、年份和原文。
2. 把“讲故事”变成可检查的推理
项目还做了跨章节矛盾检测、常识反常检测和史源溯源实验。例如，同一事件在不同篇章中的时间、数量或归因不一致时，系统先把差异列出来，再交给人判断是史源差异、叙事角度不同，还是确实存在疑点。
这意味着历史内容可以从“我听说”升级为：原文依据—结构化事实—待核问题—我的解释。对做知识型账号的人来说，这种证据链比单纯堆金句更值钱。
3. 一份素材，拆成多种内容产品
仓库的应用层已经有语法高亮阅读器、交互式历史时间线和“史记争霸”网页游戏原型；故事、播客、短视频、图片漫画、信息图、专业文献等 Skills 也给出了内容方向。
三、最适合哪些自媒体赛道？
赛道一：历史知识账号
适合公众号、知乎、小红书和视频号。一个人物可以拆成“生平时间线、关键冲突、后世评价”；一场战争可以拆成“事件复盘、地图变化、人物选择”。
赛道二：短视频与中长视频
短视频可以做“10 秒历史冷知识”“人物对比”“名场面解释”；5—30 分钟的视频则适合人物传记、事件还原和制度科普。知识库能提供时间线、人物关系、场景细节和对话出处，减少脚本前期的空想。
赛道三：播客、有声书和音频课
项目规划了“每日一讲”（5—10 分钟）、人物传记（20—30 分钟）和事件解析（30—60 分钟）等结构。对播客主来说，知识库可以承担选题库、时间线和事实核对层。
赛道四：信息图、漫画与历史 IP
人物卡、战役地图、关系网络、四格漫画、长图和表情包，都可以从实体、事件、地点和器物数据中获得稳定素材。
四、如果你是一个人，应该怎么用？
不要一上来下载整个仓库，也不要试图“复刻全部《史记》”。更现实的做法是：
1.先选一个窄主题，例如“韩信的决策失误”或“鸿门宴的权力结构”。
2.用知识库找到原文段落、人物关系和事件时间线。
3.把同一份素材拆成一篇文章、一条短视频脚本和一张信息图大纲。
五、别忽略这三个边界
第一，项目自己也承认 AI 标注会有错误，已知问题包括实体边界、事件粒度、关系过度推断和年代缺口。它适合做研究加速器，不适合替你承担事实责任。
第二，README 标注数据采用 CC BY-NC-SA 4.0，分析脚本是 MIT；商业使用不能简单理解为“随便拿来卖”，应先看许可证并联系作者确认。
第三，故事、音频、视频、信息图和专业写作 Skills 中，有不少仍处于规划状态。最稳妥的定位是：把 shiji-kb 当成历史内容的素材引擎和方法论样板，再接入你自己的写作、设计、剪辑和分发流程。
如果你做的是历史、教育、文化解读或知识型内容，这个项目最值得借鉴的，不是某一篇文章，而是它把“素材整理、证据检查、内容拆分、产品化”连成了一条线。自媒体真正的复利，也往往来自这条线，而不是某一次偶然爆款。
项目地址：https://github.com/baojie/shiji-kb
