给《史记》加上语法高亮：一个人+一群AI的55小时

https://mp.weixin.qq.com/s/u4kHDdZHXLMGuBMZOlOmcg

给《史记》加上语法高亮：一个人+一群AI的55小时

原创 01fish 01fish 01fish;)

_2026年3月8日 18:22_

在小说阅读器中沉浸阅读

AI时代的阅读

创造者：西瓜以下为第一人称撰写

打开任何一个现代IDE——VS Code、Cursor、JetBrains——你看到的代码永远是彩色的。关键字蓝色，字符串绿色，注释灰色，函数名黄色。程序员早就无法想象，在一片纯白底黑字的世界里写代码是什么体验。

语法高亮不改变一个字符。它只是给不同类型的文本涂上不同颜色。但就是这么简单的一件事，彻底改变了人类阅读代码的效率。

2026年1月22日上午8点47分，我对着Claude Code打了一条指令：

请对人名、地名、书名、年号、纪年、官职这些命名实体识别出来，用下划线、黑体、颜色等视觉辅助方法辅助阅读。先实验001章。

001章，是《史记·五帝本纪》。

这条指令的背后，是一个酝酿了二十多年的念头——能不能让AI像IDE给代码加语法高亮一样，给古文也加上"语法高亮"？

如果可以，那57万字的《史记》，130篇，11类命名实体，全部标注上颜色——人名棕色、地名金黄、官职深红、时间青色、朝代紫色……读者不需要任何古文功底，一眼扫过去就能看出谁在哪里做了什么。

20分钟后，我看到了第一版效果。黄帝和轩辕变成了棕色带下划线。

这一刻，一件有趣的事情正在发生：人提供判断，AI提供规模。一个人一辈子也标不完57万字（经统计）古文里的每一个人名地名官职。但一个人加一个AI，也许可以。

事后统计，整个项目跨13天、23个工作会话，总投入55到70小时。其中真正属于人的部分——发指令、做判断、纠正错误——大约25到30小时。剩下的都是AI在跑。130篇、57万字、71,857次实体标注。烧掉了5.73亿token，等价API费用约1,000美元。

但这只是1%的工作。目前做的只是最基础的实体高亮——人名地名官职涂上颜色。实体之间的关系没有标注，知识单元没有标签化，离最终的目标还差得远。

最终想做什么？适配AI时代的最佳阅读器。

先看效果：https://baojie.github.io/shiji-kb

我用的方法，第一是与ai对话下指令，第二是用pdf2skill去提炼构造本体。

若你对AI辅助阅读也感兴趣，欢迎来这里交流

（若群满了，可以添加 18501790646 备注 ai阅读）

接下来我们开始讲故事，故事还是要从一个更根本的问题讲起：人类为什么一直在发明新的排版方式？

01 排版简史：让语义结构可见

你阅读一篇文章的时候，大脑在做什么？

在不停地解析语义结构。

每读到一个字，你的大脑都在判断：这个字是人名的一部分还是动词？这句话是叙述还是对话？这段话在论证还是在举例？这个章节和上一个章节是什么关系？

阅读，本质上是人脑对文本进行实时语义解析的过程。

而人类几千年来发明的所有排版手段，做的都是同一件事——把文本内在的语义结构外化，减轻人脑的解析负担。

公元前91年左右，司马迁完成了《史记》——57万字，130篇，横跨2,800年（从黄帝到汉武帝），为约3,200人立传。他只用了4,753个不同的汉字，就构建了一整部文明史。那时候的文本长这样：

黄帝者少典之子姓公孙名曰轩辕生而神灵弱而能言幼而徇齐长而敦敏成而聪明

没有标点，没有段落，一片密密麻麻的方块字。读者的大脑需要独自完成全部的语义解析——先断句，再辨人名，再理关系。这就是"句读"，古代读书人的入门课。韩愈说"句读之不知，惑之不解"，句读和解惑并列，可见负担之重。

然后，人类开始发明排版工具来分担这个负担：

句子 — 最早的发明。用句读把连续的字流切割成一个个意义单元。

段落 — 把相关的句子聚合在一起，用空行隔开不同的意群。

章节 — 更大尺度的结构。章节标题告诉你"接下来要讲什么"，让读者可以跳读。

标点符号 — 1920年，中国第一次有了官方标点。逗号标记停顿，句号标记完结，引号标记他人之言。这些符号不增加内容，但让句子的边界可见。标点符号让"人人可读"成为可能——你不再需要句读训练。

字体 — 宋体、黑体、楷体、斜体。字体的变化传递元信息：黑体是重点，斜体是引用，楷体是批注。

页眉、页脚、页码 — 让读者知道自己在文档的什么位置。

脚注、附注、附录 — 把补充信息从正文中剥离，保持正文的叙事流畅，又不丢失细节。

色彩 — 彩色印刷让视觉区分成为可能。重点用红色，链接用蓝色。

超链接 — 互联网时代的发明。文本不再是线性的，它可以指向其他文本。引用、出处、延伸阅读——知识之间的关系第一次变得可点击。

多媒体 — 图片、视频、音频嵌入文本。一张地图胜过一千字的地理描述。

每一次发明，都是同一件事：把人脑原本需要自己做的语义解析工作，交给排版系统来完成。

这条进化线持续了两千多年。而它的下一步——是AI。

程序员的世界已经先走了一步。1985年左右，语法高亮编辑器出现。关键字蓝色，字符串绿色，注释灰色。不改变任何代码，只是让语法角色可见。今天没有程序员愿意在没有语法高亮的编辑器里写代码。

（最早的语义高亮器）

那古文呢？

"和"可以是人名，可以是动词，可以是形容词。"龙"可以是动物，可以是修饰语（“龙颜”），可以是部落图腾。古文的实体识别不是关键词匹配能解决的——它需要语义理解。

2025年之前，这件事只能靠专业学者一个字一个字地标注。传统历史研究需要"皓首穷经"——终其一生钻研古籍，在浩如烟海的文献中寻找线索。一个团队标注57万字的《史记》，可能要数年。我自己在2025年2月试过手工写RDF知识图谱，从《高祖本纪》的两个小节开始——极其缓慢。

2026年1月，大模型改变了这个局面。Claude不仅能理解古文语义，还能判断"岳曰"里的"岳"是人名而不是地名——偶尔判错，但纠正它只需要一句话。

AI让排版进化线上的下一步，第一次变得可行。

02 两天，从零到一

内容与样式分离

2026年1月22日上午9点51分，处理第二章《夏本纪》时碰到一个问题。

第一版的标注用的是内联HTML样式：

<spanstyle="color: #8B4513; text-decoration: underline;">黄帝</span>

效果是有了。但原始文件变得没法看了。一行古文，有一半是HTML标签。内容和样式搅在一起，修改样式就得修改内容，改一个颜色要在57万字里全局替换。

于是让Claude把内容和样式拆开——内容与样式分离。

之前：

<spanstyle="color: #8B4513; text-decoration: underline;">黄帝</span>居<spanstyle="color: #B8860B; text-decoration: underline;">轩辕之丘</span>

之后：

@黄帝@居=轩辕之丘=

用最少的符号包裹实体。@人名@，=地名=， $官职$ ，%时间%——每种实体类型一对标记符号，正则表达式一遍扫描就能转换成HTML。标记文件（.tagged.md）人眼可读，机器可处理。

这个设计后来被证明是整个系统的地基。

Token标记体系

到1月22日结束时，11种实体标记符号全部敲定：

|
标记

实体

颜色


`@人名@`

人名

#8B4513 棕色

|
| =地名= |

地名

#B8860B 金黄

|
| $官职$ |

官职

#8B0000 深红

|
| %时间% |

时间

#008B8B 青色

|
| &朝代& |

朝代/氏族

#9370DB 紫色

|
| ^制度^ |

制度/典章

#4682B4 钢蓝

|
| ~族群~ |

族群/部落

#2F4F4F 深灰

|
| *器物* |

器物/书名

#CD853F 秘鲁棕

|
| !天文! |

天文/历法

#483D8B 深蓝紫

|
| ?神话? |

神话/传说

#8B008B 深洋红

|
| 🌿动植🌿 |

动植物

#228B22 森林绿

前10类用的是ASCII特殊字符。到第11类动植物时，ASCII符号用完了——于是用了emoji 🌿。

这种"用完就换"的实用主义，贯穿了整个项目。不追求理论上的完美对称，只追求工程上的够用。

渲染器把这些标记转换成HTML时，有一个不起眼但关键的细节——正则替换的顺序。**粗体** 必须在 *器物* 之前处理，否则Markdown的粗体语法会把器物标记吃掉。@人名@ 放在最后，因为人名最常作为嵌套的内层标记（比如 $@安国君@$ 是官职包裹人名）。11条正则，顺序错一条，渲染就乱。

除了实体标记，渲染器还处理对话高亮——"曰"字在整部《史记》中出现了5,936次，排所有汉字的第8位。那些最让人血脉偾张的句子几乎都是对话：“王侯将相宁有种乎！”（陈胜）、“彼可取而代也。”（项羽）、“大丈夫当如是也！”（刘邦）。斜体加淡褐底色，让对话从叙述中浮现出来，但不打扰阅读。

Purple Numbers：致敬计算机先驱

1月23日中午，我给每个段落加上了编号锚点。

最初的设计用的是紫色背景——这是对计算机先驱Doug Engelbart的致敬。Engelbart在1960年代提出了"增强人类智力"的愿景，他的NLS系统给文档的每个段落分配永久编号，使得精确引用和知识链接成为可能。这套编号系统被称为"Purple Numbers"。

在史记语法高亮系统中，每个段落都有一个可点击的编号。点击后，URL会变成 #pn-42，你可以把这个链接发给别人，对方打开就直接跳到第42段。

两千年前的文字，通过一个计算机先驱六十年前的想法，变得可以被精确引用和链接。

紫色背景后来改成了淡米色小框——视觉更柔和，但名字保留了"Purple Numbers"的致敬含义。

第一波冲刺：23小时

回顾1月22日到23日的记录，日历上跨了两天，活跃时间约23小时——其中人的判断时间可能只占零头。

这23小时里完成了：

• 11类实体标注规范

• Token标记系统（内容与样式分离）

• 核心渲染器 render_shiji_html.py

• 完整CSS样式体系

• 对话语法高亮

• Purple Numbers段落编号

• 段落拆分和结构化逻辑

• 52/130章的实体标注

约800+条人机消息。但人发出的指令可能只占其中的几十条。剩下的都是AI在自主工作——识别实体、写代码、调样式、处理文件。

人提供方向和判断，AI提供规模和速度。

03 从标注到知识图谱

130章全量完成

搭好架构后，2月6日进入规模化生产。

批量处理的关键是并行。Claude Code可以同时运行多个子任务——我一边监控进度，一边手动调度：“你可以选几个手工来做，给你的agent重新分配任务。”

这种工作模式很有意思：人类变成了AI的项目经理。不是一个人指挥一个AI，而是一个人调度一群AI agent。

2月8日，最密集的一天——17.4小时，从凌晨干到深夜。130篇《史记》全部完成语法高亮标注和HTML渲染。

第二波冲刺（2月6日到10日）的5天里，投入了约43小时，烧掉了4.6亿token——其中2月8日一天就消耗了2.22亿token的cache读取，相当于AI把越来越长的对话上下文反复重读了无数遍。

130篇覆盖了《史记》的全部"五体"——这是司马迁独创的史书体裁：

|
体裁

篇数

字数

占比

内容

本纪

94,522

15.0%

帝王编年

|
|

表

5,010

0.8%

年表（最难渲染的部分）

|
|

书

51,559

8.2%

制度专题

|
|

世家

165,572

26.3%

诸侯世系

|
|

列传

311,803

49.6%

人物传记

12,527个实体词条的分布同样有意思：

|
实体类别

词条数

典型

👤 人名

4,142

孔子、项羽、萧何

|
|

🎖️ 官职

2,504

丞相、太尉、将军

|
|

🗺️ 地名

1,820

咸阳、邯郸、长安

|
|

🏺 器物

1,017

鼎、玉璧、印绶

|
|

📅 时间

979

元年、正月、春秋

|
|

📜 制度

661

郡县制、封禅、正朔

|
|

🌿 动植物

384

龙、凤、桑

|
|

🏛️ 朝代

304

秦、汉、周

|
|

⭐ 天文

283

彗星、二十八宿

|
|

🐉 神话

250

黄帝、女娲、禹

|
|

👥 族群

183

匈奴、夷狄、三苗

一共一万出头个实体，完整实体列表在这个 https://github.com/baojie/shiji-kb/blob/main/entity\_index.json （这个文件比较大，有26万行）

人名最多，4,142个——《史记》本质上是一部以人为中心的史书。官职第二多，2,504个——说明司马迁对权力结构的关注。地名第三，1,820个——每一个事件都有空间坐标。

工程投入的账单：

|
指标

数值

标注章节

130/130（100%）

|
|

总字数

628,466字（57万字）

|
|

标注总次数

71,857次

|
|

人名别名

~570条

|
|

语义消歧

1,281处

|
|

实体索引

9,700+ 条目

|
|

Git commits

92个

|
|

API 调用

5,856次

|
|

Token 总吞吐

5.73亿

|
|

等价 API 费用

~$1,000

57万字，71,857次标注——平均每9个字就有一个实体被识别并上色。

语言DNA：词频里的史记

在标注实体的过程中，一份副产品自然产生了——整部《史记》的词频分析。57万纯汉字（不含标点），只用了4,753个不同的汉字。字符丰富度仅0.82%——意味着司马迁用不到五千个字，构建了一部横跨三千年的文明史。

高频字符揭示了《史记》的"语言DNA"：

|
排名

字

出现次数

它告诉我们什么

之

13,201次

每50个字就有一个"之"——文言文的骨架

|
|

王

8,191次

政治史的底色

|
|

曰

5,936次

对话驱动的叙事——验证了对话高亮的必要性

|
|

秦

3,111次

唯一进入Top 20的国名——秦是整部《史记》的主角之一

高频词组更有意思。"天下"出现1,214次，"诸侯"954次，“将军"863次——这三个词勾勒出了《史记》的核心母题：天下是棋盘，诸侯是棋手，将军是棋子。而"孔子"以394次成为唯一进入高频词Top 20的具体人名——在一部帝王将相的史书中，一个没有权力的思想家拥有最高的"词频权重”。

这些数字本身就是一种"语法高亮"——它们让《史记》的语言结构从数据层面变得可见。

这个密度意味着什么？打开任何一章的渲染结果（https://baojie.github.io/shiji-kb ），你看到的不再是一片黑色方块字，而是一幅有结构、有层次、有色彩的信息图。棕色的人名像路标，金黄的地名像坐标，深红的官职像信号灯——你的眼睛会自动被这些颜色引导，快速抓住一段文字的核心信息。

语义消歧：AI的古文理解力

在标注过程中，遇到了一个经典的NLP难题——同名消歧。

"武王"这两个字，在《周本纪》里是周武王，在《秦本纪》里可能是秦武王。"昭王"可以指秦昭王、燕昭王、楚昭王。"惠王"更复杂——秦惠王、魏惠王、燕惠王、周惠王都有可能。

最终采用了4层启发式策略：

1. 共现全名：如果同一段落里出现了"秦昭王"的全称，那后文的"昭王"就指秦昭王

2. 附近国名（80字窗口）：往前看80个字，如果出现"秦"字，大概率指秦昭王

3. 前置国名：前面最近出现的国名

4. 章节主题国：比如《秦本纪》里的默认指向秦国

结果：1,281处自动消歧 + 11处手工修正，覆盖率90%。

另一个有趣的标注难题是动植物实体。规则很讲究：

• 标记名词性用法：🌿马🌿、🌿柳🌿

• 不标记动词性用法："蚕食"中的"蚕"是动词，不标

• 不标记比喻用法："龙颜"中的"龙"是修饰语，不标

• 神兽也标记：🌿龙🌿（单独出现时）、🌿凤🌿

这些规则，大模型基本能遵守，偶尔犯错时人工纠正。关键不在于AI的准确率是100%还是95%，关键在于人纠正一个错误只需要一句话，而不再需要通读全文。

还有一个被低估的难题：别名。古人一生有名、字、号、谥号、庙号、封号——同一个人在不同章节以完全不同的名字出现。刘邦这一个人，在《史记》中就有五种写法：“沛公”“汉王”“高祖”“高帝”“刘季”。项羽也有三种：“项籍”“项王”“西楚霸王”。整个项目积累了约570条别名映射关系，让这些散落的名字最终指向同一个人。

另一层语义增强是年份映射。《史记》横跨多套历法——夏历、周历、秦历、汉历，叙事中的"元光六年"对应公元前129年，"鲁哀公十六年"对应公元前479年。项目建立了一个年份数据库，覆盖288种年份格式，让叙事年份自动映射到公元纪年。

从语法高亮到知识图谱

语法高亮只是起点。

当你把57万字中的所有实体都识别出来之后，自然会问下一个问题：这些实体之间是什么关系？

刘邦和项羽是什么关系？萧何和曹参之间发生过什么？秦始皇的统一战争打了多少次仗，每次仗里哪些将领参与了？

为了回答这些问题，项目从"语法高亮"进化成了一个知识图谱——shiji-kb。

知识图谱的结构分三层：

第一层：事实单元（Factual SKU）

434项知识单元，覆盖14个主题：

434 项知识单元：

https://github.com/baojie/shiji-kb/blob/main/ontology/facts\_index.md

|
类别

数量

例子

人物传记

192

管仲、孟尝君、屈原

|
|

诸侯国与世家

吴、齐、鲁、晋

|
|

夏商周三代

禹、商汤、周武王

|
|

匈奴与边疆

冒顿单于、和亲政策

|
|

汉朝政治

文景之治、七国之乱

|
|

军事与战役

长平之战、巨鹿之战

|
|

……

每个知识单元是一个结构化的"事实包"——包含定义、上下文、关联实体、原文出处。

第二层：技能单元（Procedural SKU）

这是最有意思的部分。241项可操作的"技能"，从《史记》的叙事中提炼出来：

241个SKILL：

https://github.com/baojie/shiji-kb/blob/main/ontology/skills\_index.md

|
分类

数量

例子

治国理政

中央集权建设、郡县制推行

|
|

军事战略

围魏救赵、背水一战

|
|

外交谈判

合纵连横、危机谈判

|
|

继承与权力交接

禅让制、嫡长子继承

|
|

人才选拔

识人用人、客卿制度

|
|

危机应对

政治自保、韬光养晦

|
|

……

换句话说，《史记》不只是一部历史书，它还是一本古代的管理学教材。241个SKILL，每一个都可以从原文中追溯到具体的历史案例。"围魏救赵"不是成语，是一次有具体时间、地点、人物、兵力的军事行动，附带战术分析和结果评估。

第三层：实体关联

7,500个实体被关联到知识单元。一个JSON文件展示了这种关联的结构：

{"sku_id":"sku_010","entities":{"dynasty":["夏后","姒氏","姬氏"],"person":["帝喾高辛","帝尧","帝禹","帝舜","黄帝"],"place":["有虞","高阳"],"tribe":["姬氏"]},"entity_count":23}

同一个"黄帝"，既出现在人物分类中，也出现在朝代分类和神话分类中——因为在不同的叙事语境里，黄帝承担的语义角色不同。

12,527个实体词条，7,497个实体关联，覆盖了整部《史记》的语义网络。

十表的特殊处理

《史记》中有一种特别的文体——“表”。十篇年表，用表格形式记录历史年代。传统纸质出版中，这些表格密密麻麻，几乎不可用。

以十二诸侯年表（https://baojie.github.io/shiji-kb/chapters/014\_十二诸侯年表.html ）为例：14列（周 + 鲁齐晋秦楚宋卫陈蔡曹郑燕吴）× 365行，覆盖公元前841年到公元前479年，362年间14个政权的兴衰更替。一张表，就是整个春秋的全景图。

在纸质书上，这张表几乎没有可用性——密密麻麻的小字，翻一页就忘了表头对应哪个诸侯国。

渲染系统为表格做了专门的处理：

• 全视口宽度：表格突破正文限制，占满屏幕（width: 100vw）

• 表头吸顶：sticky header，无论滚到第几百行，始终能看到"周·鲁·齐·晋·秦·楚"的列名

• 交替行背景色，悬停高亮当前行

• 表格单元格内的实体照样标注高亮——公元前632年那一格里的"晋文公"是棕色人名链接，点击跳转到人名索引

• 对于特别宽的表（如"秦楚之际月表"，31列），自动拆分为两个子表

362年、14个诸侯国、637行数据——两千年来最难用的历史年表，第一次变得可以舒服地滚动阅读。

一个意外产出：史记争霸游戏

在做知识图谱的过程中，积累了大量结构化的历史数据——人物、势力、地理、事件。这些数据自然而然催生了一个副产品：一个策略游戏。

史记争霸（https://github.com/baojie/shiji-kb/tree/main/app/game ）让玩家在春秋战国的棋盘上做决策——选择合纵还是连横，起用韩信还是范增。游戏的底层数据全部来自知识图谱：人物能力值基于《史记》对他们的描述，势力版图基于标注的地名关系。

这不是项目的目标，但它验证了一件事：当文本变成结构化知识，应用场景会自己冒出来。

人机协作的分工

回顾整个项目，人和AI的分工非常清晰：

人做的事：

• 提出愿景：“让史记活起来”

• 做审美判断：“去掉bold”、“0.03透明度”

• 纠正语义错误：“岳是人名”

• 把控质量：“小节划分要有意义，不能是’段落40’这样”

• 调度任务：“你选几个手工做，给agent重新分配”

AI做的事：

• 大规模实体识别（57万字）

• 代码开发（渲染器、索引生成器、消歧工具）

• CSS样式实现

• 批量文件处理

• 并行子任务执行

一个人加一群AI agent，55到70小时的总投入（其中人的思考和判断约25到30小时），5,856次API调用，5.73亿token——完成了传统团队可能需要数年的工作量。

但这只是1%。

04 只做了1%

说回来，目前做到了什么？

只做了实体高亮。

人名涂上了棕色，地名涂上了金黄，官职涂上了深红。对话被标记出来了，诗歌被标记出来了。这是排版进化线上的一小步——让实体的类型可见。

但文本内在的语义结构，远不止"这个词是人名"这一层。

还没有做关系——事理图谱。 刘邦和项羽不只是两个人名——他们之间有"对手"“曾同盟”"最终胜负"的关系。萧何举荐了韩信，韩信受封于刘邦，鸿门宴、破釜沉舟、约法三章——每一个历史事件都有时间、地点、参与者、原因、经过、结果。这些关系目前在文本中是隐含的，没有被显式标注和链接。下一步是构建事理图谱：事件本体（战争、政变、改革、会盟、封禅），事件之间的因果链条和影响网络。

还没有做时间图谱。 《史记》跨越三千年，涉及多套历法——夏历、周历、秦历、汉历。"元年"在不同篇章指不同的绝对年份。目前只做了初步的公元纪年映射，完整的时间图谱——绝对时间轴、相对时序、历法转换、多级时间粒度——还没有。

还没有做知识单元的标签化。 项目已经整理出了241个SKILL（可操作的历史技能，如"围魏救赵"“合纵连横”）和434项知识单元（结构化的事实包），但这些知识单元还没有被回标到原文中。读者读到长平之战，应该能直接看到"这一段对应SKILL #047：包围歼灭战术"——这一步还没做。

更没有做推理。 当关系和标签都打好之后，理论上可以做跨章节的知识推理：哪些将领同时出现在多场战役中？哪些政策模式在不同朝代反复出现？一个人物在不同章节中的描述是否矛盾？

回到第一节的框架——人类排版进化线的每一步，都是把人脑的语义解析工作外化一层：

|
排版工具

外化了什么

句子、标点

句子的边界

|
|

段落、章节

意群的层次

|
|

字体、色彩

重点和类型

|
|

脚注、附录

主次关系

|
|

超链接

文本间的引用关系

|
|

实体高亮（已做）

词的语义角色

|
|

关系标注（未做）

实体之间的关系

|
|

知识标签（未做）

段落的知识属性

|
|

推理层（未做）

跨文本的模式识别

目前，我们只走到了这张表的第七行。

最终想做的，是这张表的最后一行——也就是说，一个阅读器，它能让读者在阅读的每一个瞬间，都能触达文本内在的全部语义结构。实体是什么类型，一目了然。实体之间什么关系，hover就能看到。这段话在整个知识体系中处于什么位置，侧边栏直接展示。类似的论述在其他章节出现过几次，交叉引用自动呈现。

适配AI时代的最佳阅读器。

这个愿景的本质，其实和两千年前的句读是同一件事。句读是人类第一次尝试让文本的语义结构外化——在一串连续字流中标出停顿的位置。今天，AI让我们有能力把外化的程度推到一个前所未有的深度——不只是标出停顿，而是标出每一个词的角色、每一对实体的关系、每一段文字的知识归属。

现在没有人再会读没有标点符号的文章，未来也不会有人愿意读没有语法高亮的文章。

从《史记》开始。57万字，130篇，目前完成了实体高亮。

但《史记》只是中国正史的起点。二十六史的全貌是这样的：

|
阶段

包含

字数

已完成

史记

57万字

|
|

近期目标

汉书、后汉书、三国志

~200万字

|
|

中期目标

晋书至隋书（魏晋南北朝8史）、南北史、新旧唐书

~1,500万字

|
|

远期目标

宋辽金元明清各史

~2,000万字

|
|

通鉴系列

资治通鉴、续资治通鉴、明通鉴、清通鉴

600-700万字

|
| 合计 | 二十六史 + 通鉴系列 | ~5,000万字 |

再往后？诸子百家、四库全书（3,000多部典籍）、全唐诗、全宋词。中国古籍的总量以亿字计。

关键在于：方法可复制。整个项目沉淀出了一套6阶段管线：文本准备 → AI语义标注 → HTML渲染 → 实体索引 → 语义增强（消歧、别名、年份映射）→ 知识工程（SKU生产、关系提取）→ 发布。其中7个核心组件可以直接复用——渲染器、实体索引生成器、别名检测器、消歧工具、CSS样式体系、Purple Numbers段落编号、发布脚本。

换一部书，需要调整的只是：实体类型（佛经可能需要增加"佛教术语"类）、体裁分类（编年体和纪传体的提示词不同）、别名规则（每部书的称谓习惯不同）、年份体系。框架不变，参数变。

具体的工时和Token规模估算：

|
古籍

字数

预估工时

预估Token

史记（已完成）

57万

55-70h

5.7亿

|
|

汉书

74万

70-90h

~7亿

|
|

后汉书

90万

80-100h

~9亿

|
|

资治通鉴

300万

200-250h

~25亿

|
|

二十四史全集

4,600万

人年级别

~400亿

从57万字到5,000万字，不是做80倍的工作，而是跑80倍的token。

这个项目也留下了几条经验教训：

• 先粗后细：先用AI快速标注全部章节（允许错误），再迭代修正。第一版不完美没关系，有了全局数据后，系统性的错误反而更容易发现和修复。

• 消歧比NER更难：AI识别出"武王"是人名不难，难的是判断它是周武王还是秦武王。这需要上下文理解，目前的4层启发式策略只覆盖了90%，剩下10%仍需人工。

• 别名是冰山一角：一个人有五六种称呼是常态。570条别名映射关系，只是最基础的归并。

• 克制的设计更持久：视觉样式宁可淡雅也不要花哨。0.03透明度的对话底色、暗色系的实体颜色——半年后回看，仍然觉得舒服。

现在没有人再会读没有标点符号的文章，未来也不会有人愿意读没有语法高亮的文章。

排版进化线已经走了两千年。AI让它可以再走一大步。

我们刚起步。

在线体验：https://baojie.github.io/shiji-kb

免责声明：本项目由AI辅助生成，标注中不可避免地存在错误和疏漏。每一次迭代都会让数据质量更好一点。如发现错误，欢迎到 GitHub（https://github.com/baojie/shiji-kb ）提交Issue。

调研 & 撰写：AI（Claude） 主导 & 审校：鲍捷 创作时间：基于2025年2月至2026年3月的项目开发记录（92个git commits, 5,856次API调用）