MoreRSS

site iconVicalloy | 天地一沙鸥修改

程序员与技术爱好者,曾用ID zbird,现在vicalloy,杭州居住,擅长多种编程语言,喜欢分享开源作品和软件开发经验。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Vicalloy | 天地一沙鸥的 RSS 预览

红楼梦读书笔记

2026-04-04 20:40:12

题注:因较为认同“癸酉本”对《红楼梦》的剧情解读,八十回后的情节走向参考“癸酉本”。

红楼梦讲了什么

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

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

红楼梦众生相

贾母

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

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

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

王熙凤

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

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

贾宝玉&林黛玉

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

贾宝玉

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

林黛玉

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

薛宝钗

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

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

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

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

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

尤三姐/尤二姐

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

史湘云

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

小说创作 SKILLS 的设计

2026-04-02 20:10:00

前情提要:《用AI写小说的尝试》

使用的 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 列表,避免出现伏笔丢失,人物去向没有交代的问题。

用AI写小说的尝试

2026-03-24 10:31:53

前情提要我的 AI Agent 实验项目 Sequoia

小说完成情况

  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元。

三国演义阅读笔记:英雄的荣光与无奈

2026-03-20 21:04:00

四大名著中,其余三部多少都掺杂了作者的“私货”。透过文字揣摩作者真正想表达的东西,是阅读的乐趣之一。《三国演义》则是一部正统的英雄史诗,写的是英雄的崛起和落幕。对我而言,读《三国》的魅力在于对比小说与历史的差别,看真实历史人物面对机遇和困局时的抉择。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我的 AI Agent 实验项目 Sequoia

2026-03-17 20:09:47

今年 OpenClaw 的忽然爆火,让我有些难以理解。在我看来 OpenClaw 似乎没有太多实质性的创新。除了不支持 IM 控制外,给任何一个 AI Client 加上 SKILLS 和 MCP 似乎都可以做到类似的事情。在对 OpenClaw 有了些了解后,虽然依旧认为 OpenClaw 不存在太多颠覆性的东西,但要做好并不容易。

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 一边不定期更新。

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

杭州的四季

2026-03-08 19:29:10

不觉间又到了杭州的春季,看花开花谢,竟有些不舍。忽然想写写杭州的四季,虽留不住时间,却能留下当下的心情。

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

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

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

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

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

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

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