红楼梦讲了什么

《红楼梦》讲的什么一直存在争议。考据派认为讲的是清朝江南曹家的兴衰，索隐派则认为《红楼梦》是悼明之作。近代考据派占据主流话语权，作者是曹雪芹的说法也源于考据派。近年来，特别是自“癸酉本”问世后，索隐派在民间渐有抬头之势。考据派与索隐派之争，此处不再展开详述。

《红楼梦》是古代文人凭借高超文学造诣创作的一部“谜语书”。作者运用拆字、谐音、隐喻、象征、对比、对仗等多种手法，隐藏并暗示故事线索与人物命运。因此，解谜本身便成为阅读此书的一大乐趣。开篇即以“假语存，真事隐”及“风月宝鉴”提醒读者：须看文字背面。神瑛侍者和将诛仙草的故事，是告诉我们贾宝玉和林黛玉才是真正的主角。书中更以判词形式早早预示主要人物的命运——这种写法在古今中外文学作品中几乎绝无仅有。或许作者深知某些内容即便写出也难以流传，故处处埋设伏笔，甚至从开篇起就布下密码，使后文难以被随意篡改或伪造。红楼梦讲的是因果循环，家族的兴衰轮回，王朝的更替轮回。

红楼梦众生相

贾母

贾母是作者在书中的代言人与情感投射，许多作者的观点与态度皆借贾母之口表达。《红楼梦》开篇即对才子佳人故事的俗套加以批评，后又借贾母之口重申一次，实为暗示贾母的代言人身份。

书中贾母对宝玉和林黛玉的偏爱，对薛宝钗的疏远，代表了作者的态度。

前八十回所写的最后一个中秋，虽是佳节，却弥漫着难以言说的落寞。贾母作为清醒者，承受着清醒者的痛苦：大厦将倾，自己已无力回天。小辈们不识愁滋味，甚至浑然不觉风雨将至。晚宴上，贾母久久不愿散席——这或许已是她生命中最后的团圆时光。虽有万般不舍，却也无可奈何。未来的风雨，只能由小辈们独自面对。站在作者的角度，社稷已亡，纵使心中百感交集，亦不能明言，唯余无尽悲凉。“商女不知亡国恨，隔江犹唱后庭花。”

王熙凤

如果说贾母是作者的代言人，王熙凤则是贾府中不可或缺的执行者。她是贾母的工具人，努力维持着贾府表面的风光，替贾母干了贾母不方便干的脏活，维护了贾母的体面。王熙凤精明强干、口齿伶俐、手段狠辣，八十回后期又表现了她脆弱和无奈的一面。作者对王熙凤这个角色的塑造并不是简单的好坏，但整体还是偏正面的。

很多人接受不了癸酉本的王熙凤还魂报仇。《红楼梦》讲的王朝更替，因果轮回，但总体基调还是劝善。癸酉本中坏人多没有好报，王熙凤下界报仇其实是这理念的极端表现。善恶终有报，恶人没有人收也有天收。情节虽有些突兀却也不是不可理解。再者，《水浒传》中也有张顺还魂报仇的情节。

贾宝玉&林黛玉

作为书中的主角，作者无疑对他们有所偏爱。二人聪慧而貌美，却并不完美。他们始终无法超脱儿女情长，面对时代洪流，显得格外无力。尤其是贾宝玉，自始至终近乎一名旁观者。

贾宝玉

神瑛侍者下界历劫。剧本已经写好，贾宝玉只是体验者和旁观者不能也不会有太多主观能动性。王夫人逼死金钏儿，晴雯被赶，贾宝玉没有做任何实质性的努力。有观点认为贾宝玉隐喻玉玺。对于玉玺，众人相争实则身不由己，自己什么也做不了。

林黛玉

聪慧、漂亮、心地善良，却也孤傲、刻薄小性、内心敏感。黛玉惹人怜爱却又拒人千里。现实中这样的人就如一只刺猬，只要靠近就会受伤。伤痛他人的同时也伤了自己。

薛宝钗

虽也有可爱之处，但在字里行间明显可以感觉到作者并不喜欢这个角色。文中的傅秋芳虽有才情却拖成了23岁的大龄剩女，很难说不是在影射薛宝钗。

螃蟹宴席间贾母提到王熙凤虽爱说笑礼数却周全，很难不让人联想到贾母是否对螃蟹宴不满。“我们家四个女孩儿算起，全不如宝丫头”，表面上夸薛宝钗，实际是明确说林黛玉是自家人，薛宝钗不是。后面带刘姥姥游贾府的时候更是说到“螃蟹不是好东西”。薛宝钗借史湘云的名头请客，却安排自己和贾母一桌，让史湘云这个名义上的主人坐边桌，就别怪贾母不乐意了。

刘姥姥算出螃蟹宴要花20两银子。20两对刘姥姥来说很多，但对于贾家这个层次则上不了台面。这里更多的是表现薛家的小家子气。

菊花诗，表面是给史湘云当参谋协助出题，实则是为了提前拿到考题。“考试时”更是急不可耐的当着所有人的面抢下了自己心仪的题目毫不客气。

滴翠亭嫁祸黛玉更是洗不清的污点。可能滴翠亭事件中薛宝钗并不是有心要嫁祸林黛玉，但这种下意识的举动恰恰说明薛宝钗是那种为了自己利益可以随时牺牲他人的人。

尤三姐/尤二姐

尤二姐性格温婉顺从，一心想要找个可依附的男人。尤三姐看似泼辣豪放的性格只是自己的保护色，内心传统专一。最终两人都红颜薄命。没有靠山的弱女子在乱世中似乎没有出路。

史湘云

直爽率真，惹人怜爱。后期贾母没有前期喜欢湘云，几乎没有互动。诗社时贾宝玉求了很久才去接。贾母喜欢聪明的孩子，长大后的湘云太憨，被卖薛宝钗了还给替人数钱。螃蟹宴上和贾母没有明显的互动，不过从贾母和薛宝钗的互动上看，贾母对史湘云还是有心维护只是怒其不争。

使用的 SKILLS 以及生成的小说：novel-skills

现阶段 AI 在各个领域都得到了广泛 的应用。AI 很能好地保证产品的下限，但若不深度参与，仅靠 AI 自动驾驶还是难以产出优秀的作品。现阶段 AI 更多的能担任辅助角色，全功能的 AI 只能寄望于其进一步进化。

用 AI 写小说是我探索其能力边界的一次尝试。从产出来看结果不算理想，不过整个过程还算是有趣。

SKILL 编写流程

Skill 的编写也是一个循序渐进的过程，下面是这个 Skill 调教的一个大致过程。

1. 先按照自己的理解给定基础框架，然后让 AI 帮助完善细节。该阶段可借助 Copilot、Codex 等工具辅助进行 Skill 的编写。
2. 让 AI 使用 Skill 开始按章进行写作。观察 Skill 的工具调用情况，了解 AI 是否有按照预定的流程进行工作，有哪些流程可以优化。对于未按预期执行的步骤，调整 Skill 加强约束。
3. 查看产出的小说摘要文件，完善 Skill 摘要生成的约束。
4. 随着小说长度的增加，摘要文件持续增加。密切关注摘要内容的变化，及时修改 Skill 调整摘要以适应小说的创作。

小说创作 SKILL 的设计

• 大多 AI 模型只有 128K 的上下文，换算成中文字符大约为15万。要加上系统prompt、控制字符、对话历史等，实际留给小说的上下文远低于这个数。为了让 AI 对完整剧情有所了解，必须将小说内容先总结成摘要再喂给 AI。
• 过于简洁的摘要会让 AI 缺少必要的信息，导致剧情不连贯甚至矛盾。过于详细的摘要不但会导致上下文超限，更会分散 AI 宝贵的注意力，适得其反。可以说摘要设计是这个 SKILL 设计的核心难点。
• 设计初期考虑使用图数据库、向量数据来辅助 AI 理解小说情节。实际操作下来发现对于小说创作而言，经过合理设计的 Markdown 已可以很好的满足需求。引入数据库反而是在自找麻烦。
• 小说的摘要按照树形结构进行组织。
  • 小说总纲，里面包含小说总体的剧情简介以及完整章回简介。总纲里的章回简介只包含标题和一句话简介。每章的具体摘要放在独立文件中。每章的具体简介里包含关键剧情，情节伏笔等。
  • 角色小传放在单独文件夹里。角色索引文件里将角色分为主角、配角、组织等，并给各角色一个简要介绍。每个角色的详细介绍放在独立文件中。角色详细介绍包括人物性格、和其他人物关系以及关键剧情介绍等。
  • 世界观设定也有独立的索引文件。索引文件中包含简要的世界观介绍。核心场景、关键设定有自己独立的设定文件。
• 摘要的维护和使用。
  • SKILL 里明确要求每章完成后必须对相关的摘要文件进行更新。
  • 最初设计是让 AI 根据情节需求自己决定需要读取哪些摘要。实际使用过程中发现 AI 经常漏读关键内容。对轮工具调用不但费 Token，速度还慢。考虑当前的章回数还不是很多，因此写了个 tools 一次性加载所有摘要。注：最初想设计成 SKILL 的 Script，但其执行前会做很多环境检查，使用体验不佳。
• 当前 SKILL 需要改进的地方。
  • 现在的摘要有些太“啰嗦”，随着作品长度的增加很容易超过上下文限制。需要进一步优化摘要约束，只保留重要内容。
  • 在作品长度增加后一次性加载所有再要摘要将不再可行，需要回归按需加载。需对摘要加载工具进行调整，一次性加载必要的摘要文件。然后在 SKILL 里给出详细的按需加载指导。
  • 设计初期没有考虑分卷问题。每卷也应当有各自独立的摘要，利用该摘要来指定本卷的创作方向。
  • 需要设计 checklist 列表，避免出现伏笔丢失，人物去向没有交代的问题。

小说完成情况

1. 已完成 10 万字左右，总共24章。
2. 小说名字： 《他们都劝我冷静，然后我疯了》 发布在番茄小说。通过 签约认证 ，未通过 作品推荐 审核。
3. 由于让 AI 写小说的主要目的是验证 AI 能力，近期应当不会继续更新。

小说创作系统搭建

1. 使用 LangChain Deep Agents 作为 Agent 开发框架。
2. 小说创作知识通过 SKILL 提供。
3. 通过 tools 为平台提供图数据库读写等额外的能力（未实际使用）。

遇到的问题以及解决方案

根据我的最初预想，小说的摘要及人物小传等知识使用层次化的 Markdown 来存储，方便人工审阅。人物关系等信息通过图数据库存储，并通过向量数据库提供前期剧情的搜索。实际使用过程中发现，图数据库和向量数据库的使用必须给定详细的规范，如果只提供基础的读写接口，AI 无法很好的利用数据库能力来辅助写作，引入的问题远高于解决的问题。此外良好的 Markdown 结构设计已足以支持小说写作。

当使用一个工具时，该工具的所有知识需要加入到对话的上下文中。如果 Agent 用到的工具很多，且这些工具都有详细的使用知识，则会占用很多宝贵的上下窗口。为了解决该问题可以将这个工具作为独立的 SubAgent，将工具使用的详细说明放到 SubAgent 中。

Deep Agents 默认提供了文件读写工具，通常情况使用该工具实现文件读写即可。但在明确要求加载 outline 目录内设有知识的情况下依旧会根据自己的判断只加载部分文件。似乎在上下文过长时 AI 的遵从性会下降（注： AI 所使用的 Transformer 本就是 注意力机制 ，AI 和人一样，内容多了就容易丢失重点）。

为了保证摘要的完整加载，同时文件分别加载所带来的 AI 多次决策问题，需要提供一个一次性加载所有摘要知识的接口。尝试在 SKILL 里增加加载摘要的脚本。可能是出于安全等问题的考量， Deep Agents 在执行脚本前会对脚本做非常多的检查，即使在 SKILL 里明确要求直接执行也无法避免。最终将该脚本封装成 LangChain 的工具。

阿里百练平台为每个模型提供了 100 万免费 token。使用过程中发现只进行了几轮对话一百万 token 就会耗尽。后切换到 DeepSeek。DeepSeek 应当是主流 API 里最便宜的了，如果缓存命中，每百万的输入0.2元。对于小说写作任务，有着大量的缓存命中。随着章节的增加，写一章小说的 Token 消耗会持续增加。写到20章时，写一遍，再审阅一遍，一章花费1～2元。

《三国演义》作为历史小说，为了通俗性和故事性将人物进行了脸谱化处理。原本复杂的权力博弈和利益权衡被简化成了忠奸仁义。小说在神化部分人物的同时，又不可避免地将部分人物进行了降智。对于真实的历史而言，人远比小说里复杂。东汉末年，群雄逐鹿；面对时代的洪流，有的是英雄的荣光与无奈。

《三国演义》故事性最强的部分主要集中在中期。前期的群雄逐鹿主要是交代故事背景和人物；后期英雄的落幕，本身就缺乏爽点。

三国故事重点放在刘备身上，一方面是宣扬汉室正统的需要，另一方面刘备也最具故事性。故事中的刘备起势初期几乎一无所有，唯一的依仗只有皇室宗亲的名号以及仁义的声誉。刘备有着极强的韧性，在乱世的夹缝中艰难求生又不忘初心。可以说，刘备是作者以及很多人理想主义的化身。历史上的刘备作为一代枭雄，肯定要复杂得多，只是作者为了故事性进行了取舍。

刘备驻徐州时出于战略考量和吕布达成战略结盟，关张二人对此多有微词。从这点看，关张二人毫无战略素养。

陈琳讨伐曹操的檄文让我印象深刻。这篇檄文好到让我这么一个对文字并不敏感的人也可以体会到文字之美。

火烧赤壁这场战役非常重要，它奠定了三国分立的局面。作者花费了大量的笔墨将这场战役写得精彩纷呈。不过从实战的角度看，故事里火烧赤壁的计策太过复杂，这么复杂的计策任何一个意外就会失败。故事里的计策用到现实中大概率是要翻车的。

赤壁之战后，刘备总算有了自己的地盘，不过为了后续的发展，刘备必须拿下益州。但不管怎么操作，抢占益州都于理不合。刘备为了保全声誉没有速战。这虽在一定程度上让场面好看了一些，不过也浪费了本就不多的窗口期。或许失荆州和没有速战也有一定的关系。事后回看，很难说刘备的选择是对是错。

荆州太平太久了，关羽有些闲不住，外加看到汉中战事不断，自己也想立功。刘备给关羽“假节钺”，是想让关羽试探东吴的动向，只是没想到高估了关羽的战略眼光。荆州是刘备的命脉，对东吴也是。东吴没有强取荆州不是畏惧蜀国，只是在等待一个合适的时机。关羽北伐襄阳对东吴毫无防备，以致荆州归吴，自己也兵败身死。

刘封因为没有及时支援关羽被刘备所杀。其实以当时的情况，即使刘封出兵也无力回天。未能支援关羽只是刘封被杀的借口。刘封作为刘备的义子，在刘备有了刘禅后，悲剧就早已注定。刘备自知年事已高，他必须及早处理刘封，为自己亲生孩子继位扫清障碍。

故事里刘备因关羽被杀而伐吴。实际上，刘备在关羽被杀一年多后才出兵伐吴。相比兄弟义气、替关羽报仇，刘备伐吴更多的是战略考量。丢荆州就丢了未来，不得不战。此时恰逢曹丕称帝，人心未定，魏国主要精力都放在安内上，暂时不用担心魏国的骚扰。这个战略窗口期极其难得，也极其短暂。

小说中刘备伐吴的早期优势非常大，真实情况并非如此。吴国虽求和，但多为忌惮魏国，并没有提出归还荆州等实质性条件。蜀国的优势都在吴国的可控范围内。为了让历史线收束，刘备不得不轻敌自大，以至兵败，之后彻底放弃荆州。

孟获这个章节写得像是《西游记》打怪，和整体风格不搭。孟获不是蛮人老大，也无七擒七纵。历史上孟获就是个带路党外加傀儡，也只放了一次。如果真放了这么多次，诸葛亮底下的人早反了。

诸葛亮北伐是明知不可为而为之，用进攻来做防守。相比军事方面的考量，北伐更是为了凝聚人心。刘备得益州存在争议，如果没有统一目标，内部先乱。从战略方面看，如果北伐大获全胜，吴国必反。况且北伐道路险阻，即使胜了也只是多了一块孤地，难以防守。诸葛亮没有用魏延的子午谷奇谋，也是因为知道这个方案不但高风险，即使成功了也难守胜果。蜀国要一统天下注定无解。

蜀国没了诸葛亮后，再无人能平衡各方势力。以魏延的死为开局，内部矛盾以最惨烈的方式集中爆发。从此文官治国。北伐是为了凝聚人心的权宜之策，蜀国本就最弱，转向蜗居可以说是必然。

姜维得以在内乱中安稳落地，并在后来进行了多次北伐，得益于他是降将。姜维缺乏威信，没人把他当一回事，也获取不到太多资源。如果姜维真有威信，早被反对派办了。三国末期大局已定，凉州早属魏国，百姓也已经认可魏国了。打着兴复汉室的口号伐魏，似乎有些无力。伐魏从蜀国的存在意义变成了姜维的个人意义。

姜维在刘禅投降后，依旧对复国抱有幻想，最终以身殉国。不过姜维即便投降，亦难以善终。伐蜀的功臣钟会、邓艾也未能活着回朝。蜀地天险，若有强势武将盘踞，必成大患。魏主绝不会容许大将久居蜀地，因此无论姜维还是钟会、邓艾，都注定难逃一死。

“乐不思蜀”常被用来表明刘禅的“傻”和昏庸无能，称其为“扶不起的阿斗”。但事实上，“乐不思蜀”恰恰体现了刘禅作为亡国之君的自觉，也正因如此，他得以善终。相比之下，南唐后主李煜因一句“小楼昨夜又东风，故国不堪回首月明中”而招致杀身之祸。

OpenClaw 本质是一个带记忆模块的Agent管理工具，并通过 IM 的集成极大增强了用户体验（虽然现阶段依旧是个玩具）。或许 OpenClaw 这样可以通过 “记忆” 持续学习并可以通过 SubAgent 分工合作完成任务的 AI 工具会成为今后一段时间 AI 的发展方向。

为了探索 AI 能力的边界，开了一个试验性项目 Sequoia 。Sequoia（红杉）世界上最大的树，寓意一颗小小的种子终有一天可以长成参天大树。

AI Agent 框架选型

为了方便验证想法，因此希望框架可以帮忙完成MCP/SKILL调用、交互界面、SubAgent创建等大部分常规工作。这样我可以聚焦记忆模块和关键工具模块的设计。同时尝试通过prompt让 AI 自己决定如何来使用这些工具。在研究过主流AI开发框架后最终选定了 LangChain Deep Agents。下面是考虑的一些框架。

Pydantic AI

可以说 Pydantic 是 Python 界数据校验框架的事实标准。在很早之前就简单了解过 Pydantic AI，Pydantic AI 的 API 也算是比较易用。但实际使用过程中发现 Pydantic AI 的 SubAgent 管理功能非常弱，涉及 SubAgent 的操作会很不方便。且 Pydantic AI 没有配套的 UI，想要一个易用的交互 UI 得花不少功夫。

CrewAI

CrewAI 是个多代理编排框架。强项是 SubAgent 的协同管理，可以轻松实现多 Agent 协同。CrewAI 的发展势头不错，且非常易用。不过 CrewAI 的记忆模块和框架深度绑定。由于我想探索如何精确的管理 AI 的记忆，因此放弃。

LangChain Deep Agents

LangChain 是使用最为广泛的 AI 框架，拥有完整的生态。Deep Agents 是 LangChain 团队推出的 Agent 框架，可以完美的融入 LangChain 生态。记忆模块作为独立组件，可以方面用户自行扩展。可以使用 Agent Chat 和自己的 Agent 交互，免去了 UI 的相关工作。

项目现状

目前搭建了基础的项目框架。利用 Deep Agents 框架本身能力提供了 SKILLS支持、SubAgent 管理、本地文件读写等功能。

按照我的预想，记忆应当通过“文本+图数据库+向量数据库”共通管理。为此我自己添加了向量数据库和图数据库的集成。

考虑如果一开始就将应用定位成一个带记忆，可以自主学习的完整“人”实现起来会非常困难。最初会尝试利用这个框架来写小说。

小说生功能设计及问题

小说的写作知识完全通过 SKILL 教给 AI。框架只提供文件读写、数据库读写工具，具体怎么用这些工具完全由 AI 自己决定。

AI 对于长文写作的一大难点是 LLM 的上下文长度限制。为了突破 LLM 的限制，必须将小说大纲、设定、章节摘要等信息分别保存，让 AI 在需要时再自行加载。

尝试用 AI 生成了一篇小说的前两章（使用 qwen3-plus）。似乎 AI 对指令的依从性不是很高。虽明确要求使用图数据库保存人物关系等信息，但在我主动要求前没被触发。明确强调了要读取 outline 目录下所有文件，AI依旧会根据自己的想法只读部分内容。

Token 的消耗速度非常惊人。没跑几次就把 qwen3-plus 赠送的 100 万 token 用完了。随着文章长度的增加，上下文长度会持续增长， token 的消耗量也会快速增加。根据最新情况，写完一章后再手动让 AI 审阅一遍 100万 token 就花光了。

后续应当会一边调整 SKILL 一边不定期更新。

小说链接：《他们都劝我冷静，然后我疯了》

春

曾无法理解古人笔下的春天，在我看来春天有的只有无尽的阴雨。来了杭州后慢慢的理解了古人为何会伤春。

杭州的花季从一月底的梅花开始，到三月底的桃花结束。在这短短的两个月里，你方唱罢我登场，百花争艳。桃花过后纵有千般不舍也只能再待来年。杭州的春天明丽却又短暂，韶华易老，春花易逝。

夏

杭州的夏天不是不美，只是对于久居江南的我而言，绿水青山、映日荷花都只是日常。美则美矣，只是美的有些平淡。

秋

春天犹如一位少女，扭动着自己婀娜的身姿，肆无忌惮的展现着自己的美。秋天则如一枚花火，在冬天来临前一次性的释放了自己所有的能量，绚烂的毫无保留。

杭州最美的秋色等到11月中旬。乌桕、水杉、枫叶、银杏将杭城装点点的五颜六色，然后又在阵阵寒风中褪去了所有色彩。

冬

冬日的杭州有着几分萧瑟，不过因为雪，让人多了几分期待。雪后的西湖有着自己独特的美。千山暮雪、断桥残雪是穿越千年的浪漫。

近年来城区很少积雪，不过好在还好可以去杭州周边的山区看雪。

AI的发展高度依赖其训练所用的语料。互联网的蓬勃发展为AI提供了海量且高质量的训练素材。然而，随着AI的普及，大量由AI生成的低质量内容开始反噬互联网，造成严重的信息污染。内容的数量在激增，但整体质量却在下降。寻找纯净、高质量的语料库，正变得前所未有的困难。

二、传统编程技术的末路？

随着AI技术的突破，“vibe coding”已进入实用阶段。或许在不久的将来，新入行的编程人员只需要掌握这种交互方式即可，而传统的编程语言则会像如今的汇编语言一样，退居幕后，只需少数专业人士掌握。

对于新兴的编程语言和框架而言，由于AI对其不够熟悉、难以熟练运用，可能陷入无人问津的恶性循环，最终难以发展。除非新的编程技术从一开始就围绕“如何让AI高效使用”来设计，否则很难获得成长空间。近年来，Go、Rust、TypeScript、Swift等语言蓬勃发展，本以为是高级语言新一轮演进的开始，没想到却遇到了AI这个分水岭。或许，它们就是最后一代能被广泛使用的高级语言了。

AI阅读代码的速度远超人类，但它也有自身的极限。大多数软件在代码彻底失控之前，可能就已经寿终正寝了。对于一些简单的应用，纯“vibe coding”或许不是问题；但对于复杂的软件系统，如果任由AI不断堆砌代码，最终形成的“屎山”就连AI自己也会无能为力。

如果“vibe coding”成为主流编程方式，低质量代码对语料库的污染，将远比其他领域的知识污染更为严重。

三、生产力革命与社会结构重塑

回顾历次技术革命，其本质都是对人类劳动的替代。工业革命用机器取代了体力劳动，机械技术的发展使得普通手工业者无论如何努力，其生产效率和质量都无法与机器抗衡，因此市场只留下了少数满足个性化需求的“匠人”。这些被释放的人力，最终流入了脑力行业和第三产业。

今天的AI革命则更进一步，开始取代人的智力劳动。类似地，AI的发展也将使大多数智力平平者难以企及AI的能力，智力劳动领域同样只需保留少数顶尖的“匠人”。然而，这一次被释放的大量脑力工作者，似乎还没有找到合适的承接领域。

经济活动最终要服务于人的消费。如果生产力的提升导致大量人口失业，就必须建立新的分配规则，否则将引发生产过剩的经济危机，进而导致大萧条。生产力决定生产关系，当AI将生产力推升到一个新高度时，旧有的生产关系必然面临调整。

如果不能妥善应对AI带来的这一系列挑战，现有的社会秩序很可能面临崩溃的风险。

想必水浒传的作者有着作弄读者的恶趣味并将此当成一种荒诞的艺术。作者通过好汉的视角来展示这个世界，让故事有种快意恩仇的爽感。一旦脱离好汉们的主角滤镜就会发现好汉们的很多事情十分龌蹉。为了达到作弄读者的目的，作者一面暗中提醒读者好汉们并不完美，一面又通过各种手段让用户来同情并带入角色。

第一章中洪太尉误放了108魔星，这些魔星沉寂多年后才开始作乱。暗中已经说明108将并不是单纯的英雄，魔星作乱实是世风日下社会动荡妖魔丛生。

为了让读者更好的带入好汉，好汉的道德底线是一步步被突破的。开始鲁智深的打抱不平，林冲的被陷害，杨志的作死，再到武松的私刑，宋江的赚人上山。随着角色的带入，读者开始不自觉的将好汉们的恶行合理化。

很多人不喜欢水浒70回后，金圣叹更是认为70回后的剧情应当全部砍掉。不过在我看来，水浒正是有了招安的剧情才完整。留白固然美好，却不如悲剧来的震撼，也避免了作者意图被曲解（参照红楼梦）。

前70回中宋江在刚流落江湖时就已明确提出了有心招安，面对敌将时也多次以招安作为劝降说辞。从心态上说，宋江是必然会将招安作为自己的追求。从客观条件看，梁山的精英大多出于体制，也是因宋江的招安许诺才暂居梁山。如果宋江安心的做山大王，这些人大概率是不满的。好些的情况是因不满而出走，更坏的情况是梁山内乱，将宋江做投名状送与朝廷。

从实力上看，梁山虽然取得了多次胜利，但此时朝廷并未认真对待，且很多胜利过于依赖梁山的地利。如朝廷认真对待，且采取围困策略，梁山是没有机会的。作为对照，方腊是一个有完整行政体制的政权，从军事实力及制度的完备性上都远高于梁山。方腊都败于朝廷，就更别说因义而聚，依靠“借粮”为生的梁山了。

招安看似梁山的众多选择中的一个，实际上是梁山的唯一出路。面对腐败的朝廷，招安后的惨烈也是必然，只是宋江没得选。对宋江而言，招安也算是求仁得仁。

方腊篇可能缺乏爽点，但少了方腊篇的水浒是不完整的。方腊是梁山的平行宇宙，一个正面写，一个反面写。方腊和梁山一体两面，方腊是剥离滤镜后的梁山。梁山杀人放火的事也不少，只是被英雄叙事淹没了。

水浒对于好汉们的结局写的也是非常好。张顺归神，武松断臂，鲁智深圆寂，宋江毒杀李逵，即符合人物性格也应因果。鲁智深性格火爆，闻潮悟道圆寂，得到内心平静。武松断臂，实则是通过断臂还了杀孽，终得善终。李逵最爱的还是他的公明哥哥，即使被毒杀也绝无怨言，可能唯一的遗憾只是公明哥哥没有让他自己选。

如果说招安是梁山的唯一出路，战方腊是水浒的悲剧美学。破辽则是作者对好汉们最大的温柔。只是在我看来破辽的相关篇章写的太过儿戏。从故事完整性看，招安后抗辽，收回丢失的郡县已经足够体面了。现在破辽则有些过于浪漫和繁复，同整体剧情有很强的割裂感。按我的理解原本中可能有少量的抗辽情节，但断不会是我们现在看到的。现有的很多情节大概率是其他作者后加的。即使将破辽篇全部删除也不会对后续剧情产生任何影响，且破辽后没有任何封赏也是离谱。

可能受时代局限性的影响，水浒中的好汉其实并不是普通百姓，他们只是体制内的失意者。这些失意者因为各种原因聚集在了梁山，并力求回归体制。只是乱世中没有救赎，他们中的大多人未能善终。

宋江，虽然出场稍晚，但毫无疑问是水浒里绝对的主角。

有人觉得宋江被这么多人仰慕难以理解。宋江似乎武力不行，钱也不会太多，没什么拿的出手的。实际上宋江是好汉中少有的有脑子的。宋江除了钱外更重要的是能在好汉落难后帮忙出主意，安排去处。宋江是好汉们的及时雨，是周旋于黑白两道的掮客。宋江深谙江湖规则，和底层官场规则。只是宋江的这套知识体系并不适合朝堂，招安后被很快清算。

梁山的好汉们大多抱着“今朝有酒今朝醉”的态度过活。宋江是这群人中少有的具有远见者——他深知梁山泊没有未来。面对誓死抵抗终被朝廷剿灭，与接受招安后被逐步瓦解这两条路，他选择了后者。一条在他看来更为体面的死法。

林冲，少数真正意义上被逼上梁山的好汉。林冲是个身怀一技之长（武力）却胸无大志的普通人。风雪山神庙之所以经典，很大程度上能让普通人产生共情，是退无可退后的情感爆发。

风雪山神庙是林冲的高光，却也将林冲燃尽。林冲表面上很能隐忍，实际上每次隐忍都留下了明显的心理创伤。每次爆发都容易造成无法挽回的后果，非常不可控。林冲杀完王伦，得知妻子死去的那刻起林冲的故事就已经结束。林冲已经失去了人的情感，只有战斗才能让他体会到自己的存在。林冲在火并王伦后就兵器化，少了人的属性。真正的林冲在更早之前就已经死了，死在了风雪山神庙。

利刃本无情，存在的价值只是为人所使。没有人使用的利刃只能逐渐腐朽，对应林冲病逝的结局。

李逵，说好听点是纯真，实则是兽性。李逵一意孤行的要背母上梁山，完全没有考虑大哥甚至母亲的意愿。母亲没有了，李逵的愤怒多于伤心，似乎是丢了玩具的孩子。李逵伤心的不是和母亲的情感联系，是别人有父母自己没有。

误会宋江强抢民女可能不是出于道义。即使宋江明媒正娶，李逵也不会高兴。李逵眼里只有“哥哥”，下意识的认为宋江也只爱李逵，有自己的爱被人分走的愤怒。强抢民女只是李逵的说头。李逵被毒死也并无怨言，可能唯一伤心的是宋江没有让李逵自己喝。

水浒的最后还是回到了忠君叙事，把锅都给谗臣背了。可能是时代局限性，作者找不到解决方案，只能祈求明君。

2025 年在喜马拉雅上收听了《红楼梦》、《西游记》，《水浒传》还在收听中。第一次发现读原版故事其实是一件有趣的事。在古代识字的人少，小说的阅读有一定的门槛，作者也很喜欢将自己的一些小心思藏在书中。作者的这些小心思经过影视化等途径通俗化后所剩无几。听完《水浒传》后应当还会继续收听《三国演义》，之后就告一段落了。作为一个喜新厌旧的人，需要寻找其他“有趣”的事情了。

py-cggtts 是一个为高精度时间传递领域打造的 Python 工具包，它基于 Rust 编写的高性能 CGGTTS 库（GitHub 仓库），提供了对 BIPM CGGTTS 2E 格式文件 的完整解析能力。CGGTTS（Common-View GNSS Time Transfer Standard）是由国际计量局（BIPM）制定的标准格式，广泛应用于全球守时实验室之间通过 GNSS 卫星进行远程原子钟比对。

项目背景

CGGTTS 本身是纯文本结构，解析起来并不困难。不过 Python 性能一般，且已经有了 Rust 的完整实现，于是尝试将 Rust 的 CGGTTS 库导出 Python 接口。目前将 Rust 导入 Python 生态的技术已经成熟，不少 Python 库都通过 Rust 来提升性能。

项目的主要代码都由 AI 完成。对于接口封装这类本身不复杂但又繁琐的工作，在 AI 的加持下变的轻松加愉快了。