背景

小说爱好者们，这里是你们的专属聚集地！

对于资深的小说迷来说，读过的网文作品可能早已数以百计。从玄幻、仙侠、历史到都市，只要故事足够精彩，就能沉浸在一个世界中持续阅读。每当翻开一本小说，脑海中便会不由自主地浮现出一张动态的图景。

主角此刻身处何方？刚刚遭遇的角色是谁？两人之间有何过往？这个家族与那个宗门之间又是什么关系？城池外围是连绵山脉、热闹坊市，还是庄严学院？一场激战过后，人物的身份、实力、处境以及彼此之间的关系又经历了怎样的演变？

这些信息并非一张静态的人物介绍表，而是一个随着剧情不断拓展的鲜活世界。人物可能从陌生人变为战友，也可能从合作走向对立；地图会从一个小镇逐步扩展到更广阔的疆域；新的家族、学院和宗门会陆续登场；前文看似寻常的一次偶遇，也可能在数十章之后成为揭开谜团的关键线索。

当阅读量日益增长，你会发现，自己记住故事的方式，并非依靠背诵人物简介，而是在脑海中维护着这样一张“小说世界图谱”。

这张图谱包含着地图、时间线、人物关系，以及不断变化的势力和个体。

遗憾的是，这张图通常只存在于想象之中。当一本小说读到几百章，中途搁置几天再回来时，往往需要向前翻找：这个人是什么时候出现的？他和主角之间发生过什么？这个地方归属于哪个势力？某段关系是在什么时候发生转折的？

其实，最纯粹的阅读方式，是“不带脑子去看，身临其境”。但脑海中，自然会浮现出这样一张地图。

我一直渴望将脑海中的这张图真正构建出来。

这并非一张仅供观看的静态关系截图，而是一个能够伴随章节生长、支持点击人物、查看地点、梳理势力以及回顾事件的交互式小说世界。

于是，借助 Doubao-Seed-Evolving 模型，我开发了“小说迷图谱 Skill”。

该工具能将小说正文整理成“章节—人物—关系—地点—势力—事件—证据”的完整数据，并生成一个可直接在浏览器中打开的交互式 HTML 页面。读者无需重新翻阅数十章内容，只需打开图谱，就能快速重新进入小说的人物网络和世界结构。

为了将这一想法转化为可验证的真实案例，我选择了熟悉的《斗破苍穹》。公开案例率先完成了前 100 章，逐步梳理出人物、场景、势力和事件，并借助这个案例反向优化了整套 Skill。

效果展示

生成的小说迷图谱包含四个主要视图：人物关系图、场景地图、势力图谱和事件时间线。

在线体验地址：https://lucianaib2004.github.io/novel-fan-graph/

Skill 开源仓库：https://github.com/LucianaiB2004/novel-fan-graph

人物关系图的核心功能，就是精准回答“谁和谁之间发生了什么”。

每个角色都拥有独立的圆形头像，友好、互助、亲属、师徒、合作和敌对关系通过不同颜色的连线清晰区分。点击人物后，右侧会展示其身份、登场章节、当前地点、所属势力、与主角的关系以及参与过的重要事件。

随着章节推进，人物会陆续登场，身份和状态会不断变化，关系也会进入新的阶段。你看到的将不只是“人物A认识人物B”，而是这段关系在故事中如何发生、发展并最终演变的完整过程。

场景地图负责解答“故事发生在哪里”。

山脉、阁楼、坊市、拍卖场、学院等地点都配有对应的语义图标。人物到访过哪里，事件发生在何处，地点之间有哪些连接，都可以从图中进行追踪。小说中的场景因此不再只是一个个孤立的地名，而是逐渐构成一个可以理解的空间网络。

势力图谱负责解答“这个世界由哪些组织构成”。

家族、学院、宗门和商业组织分别呈现在各自的板块中。势力之间的合作、敌对及其他联系，会通过不同线条加以表达。点击某个势力时，板块保持稳定，不会因为重新计算布局而突然散开。

事件时间线则负责解答“故事一路走来发生了什么”。

关键相遇、交易、战斗、身份变化和关系转折都会按照章节顺序排列。当你忘记某段剧情时，可以沿着时间线快速定位其发生位置，再结合人物、地点和势力继续理解前因后果。

前 100 章案例共整理出 20 个人物、22 条人物关系、14 个地点、6 个势力、37 个关键事件和 99 条可回查证据。

我们还额外加入了一个阅读进度功能：选择某一章时，图谱仅展示当时已经出现的信息，未读章节标题和后续变化暂时隐藏。这并非项目的核心功能，但能让读者在阅读过程中放心使用这张图。

小说迷图谱的真正目标，是将人物经历、空间场景、势力结构和故事变化，融合到同一个可供探索的世界中。

模型介绍

Seed Evolving

本项目开发全部由 Doubao-Seed-Evolving 完成。

其核心思路是“持续演化”，可以按周级别进行持续更新。开发者围绕一个稳定入口构建项目，无需因模型能力迭代而频繁调整整套调用方式。

对于小说迷图谱这种需要连续读文件、修改代码、运行测试和反复检查页面的长程任务而言，订阅方案省去了频繁切换接入方式的麻烦。不同类型的任务可以按需选择模型，而本文的项目开发与能力体验主要围绕 Doubao-Seed-Evolving 展开。

在小说迷图谱中，我们尤其看重两项能力：百万级长上下文，以及 Coding & Agent 场景下的长程任务处理。

小说天然是一个长上下文场景。

一个人物可能在前面以“黑衣人”“老者”或其他临时称谓出现，几十章后才正式具名；某个地点早期只是被提及，后面才成为主要舞台；一段关系也可能经历陌生、接触、合作和冲突的演变过程。

如果模型只能看到零散片段，就很容易将人物认错、将地点混淆，或者只记住当前章节而忽略前面的铺垫。

实际实现时，我们并未将数百万字正文不加处理地塞进一次请求，而是先解析章节，再按连续章节分批提取，并让模型同时参考前序实体索引、数据规则和当前正文。长上下文让这些信息能够在同一个任务阶段里保持关联，稳定 ID 则让人物、地点和势力可以跨批次延续。

Agent 能力负责将想法推进成真实工程。

它需要阅读正文，也需要操作文件、编写脚本、构建数据模式、生成 HTML、运行测试、查看错误、进入浏览器检查页面，再根据使用体验继续修改。小说迷图谱并非模型回答一个问题后的产物，而是一轮轮开发、反馈和验证之后形成的项目。

Agent Plan

这次我们并非单独按量调用模型接口，而是直接购买了火山方舟的 Agent Plan 来进行测试和完成项目。

购买的订阅包包含火山自家的 Seed 系列，也支持 GLM、MiniMax、DeepSeek、Kimi 等国内主流模型。使用时可以根据任务需要自由切换，也可以开启 Auto 模式，让平台根据任务自动调度模型。

对于接入AI 工具以及接入方式，也极其简单。

Skill 核心介绍

小说迷图谱 Skill 的核心，是将“阅读时形成的整体理解”转化为一条可复用的处理流程。

工作流会先确定小说文件和目标章节范围，再用解析器识别正文中的真实章节。目录、简介、重复标题、倒序编号和章节缺号，都不能直接交给模型自由判断，需要先通过明确规则进行处理。

章节整理完成后，正文会按照连续范围分批进入提取流程。模型从中识别人物、别名、身份、状态、关系、地点、势力和事件，并为每条新增或变化信息记录章节号。

人物、地点和势力都会获得稳定 ID。即使一个人物早期只有临时称谓，后面才公开姓名，也能够通过揭晓记录连接到同一实体，而不是生成两个互不相关的人。

关系同样不是一个固定标签。师徒、亲属、朋友、同伴、合作、敌对、救助、追捕等关系会根据正文证据建立，后续发生变化时再添加新的阶段。两个人只是同场出现或说过话，不会被模型随意升级成朋友或敌人。

为了保证图谱不是模型凭印象“编”出来的，每条关键事实都需要对应章节和原文证据。数据验证器会检查实体是否已经登场、关系阶段是否按章节排列、事件是否引用了尚未出现的地点和势力；证据验证器则会检查引文能否在对应章节逐字找到。

数据通过验证后，生成器才会将图谱数据和人物头像嵌入单文件 HTML。使用者不需要搭建服务器，打开文件就能浏览人物关系、地图、势力和时间线。

交付内容还包括章节 JSON、核心数据、证据映射、图谱数据、重建脚本和浏览器验收清单。换一本小说时，开发者可以继续复用这套流程，而不必从一张空白关系图重新开始。

Skill 开发过程中遇到的问题

把想法说出来并不难，真正困难的是让它面对一部长篇小说时仍然保持可靠。

最先碰到的，就是原文本身的问题。

《斗破苍穹》文本约 663 万字符，解析后发现 1170 个有效唯一章节（可能和小说获取来源有关），编号范围却延伸到 1—1623。文件里存在目录、重复标题、章节缺号和编号跳跃。如果把正则匹配到的标题数量直接当作真实章节数，后续人物与事件都会落到错误位置。

Doubao-Seed-Evolving 将问题拆成正文边界、编号单调性、重复标题和缺失占位等规则，再把这些规则写进确定性解析器。模型负责理解复杂情况，脚本负责让每次处理都得到一致结果。

人物识别也比想象中复杂。

小说里经常先出现称谓，后出现姓名；同一个人可能有别名、身份变化和所属势力变化；两个相似称谓也不一定是同一人物。模型需要结合上下文判断候选关系，但又不能只依靠自己对小说的记忆。

为此，Skill 把原文设为事实来源，要求每条信息附带章节和短证据。无法找到原文支持的候选事实会被删除，身份揭晓只从实际出现的章节开始记录。

验证阶段确实发现过人物身份与状态顺序倒置，以及关系阶段早于关系起始章节的问题。模型没有降低验证规则，而是根据错误信息回到数据中修正，再重新运行验证。

页面开发同样经历了多轮调整。

没有关系的人物如果参与主关系网的排斥计算，会把整个图推离视口。模型把这些角色放进同页独立陈列区：人物仍然可见、可点击，但不会干扰主关系网。

势力节点早期会在点击后重新扩散，读者很难建立稳定的空间记忆。模型将势力图改成固定板块布局，让家族、宗门、学院和商业组织始终留在自己的区域中。

章节栏也出现过切换到第 89 章后丢失后续章节的问题。仅检查 HTML 文本和 JavaScript 语法无法发现它，模型通过真实浏览器切换不同章节，确认状态更新和列表渲染之间的问题，再让章节容器始终保留完整内容。

这些问题后来都被写进测试和验收清单。案例不再只是 Skill 的展示品，它反过来告诉 Skill：下一次生成小说图谱时，哪些地方容易出错，应该提前怎样验证。

为什么选择这个模型来制作 Skill

因为这个项目既需要理解一个长故事，也需要完成一段长工程。

小说中人物、地点、势力和事件彼此关联，任何一部分被孤立处理，图谱都会失去整体感。长上下文让模型能够同时参考正文、前序实体、数据规则和已经完成的项目结构，减少多轮开发中的信息断裂。

而长程任务能力让它不只停留在“给一个方案”。

在开发过程中，我们陆续提出了完整章节列表、人物卡、圆形头像、关系语义配色、场景图标、固定势力板块、孤立人物同页展示、主题切换、主题记忆、README 和 GitHub Pages 发布等要求。

这些需求并不是一次性写好的。很多细节来自真实打开页面后的感受：这里太空，那里会漂移，头像显示不完整，章节切换后内容消失。模型需要记住项目原本的目标和结构，再把新反馈接回代码、测试和文档中。

Doubao-Seed-Evolving 在这个过程中体现出的价值，是能够在较长的任务链中继续推进：读文件、修改、验证、发现问题、回归，再把解决方案沉淀到 Skill。

它也不是没有需要继续改进的地方。长文本整理和人物素材处理会花费较多时间；关键事实仍然需要证据验证；生成的单文件 HTML 因为嵌入人物图片约 15 MB，首次从 GitHub Pages 打开会稍慢。

但对一个想把模糊想法真正做成作品的人来说，更在意的不是模型能否迅速写出一段漂亮回答，而是它能否把任务推进到可以打开、可以点击、可以复查、可以重建和可以交付。

写在最后

小说迷图谱的起点，其实是一个很个人的阅读习惯。

看过很多小说之后，人物、地图、势力和事件会自然在脑海里建立联系。只是一直没有找到合适的方式，把这个内在世界完整地表达出来。

现在，这张图终于从脑海里走到了浏览器中。

它可以展示人物之间发生过什么，可以把零散地名组织成场景地图，可以梳理家族、学院和宗门，也可以沿着时间线回看故事如何一步步发展。

Doubao-Seed-Evolving 帮助处理的不仅是一段小说文本，而是从想法、数据、代码到页面交付的完整过程。百万级长上下文使长篇故事的跨章节联系更容易保留下来，长程 Agent 能力则让多轮开发和反复验证能够持续推进。

小说迷图谱 Skill 也不只是《斗破苍穹》的一张图。

《斗破苍穹》前 100 章是一个案例，也是一块试验场。案例中遇到的章节解析、人物识别、关系演化、场景表达和页面交互问题，已经沉淀为可以复用的 Prompt、脚本、验证器和验收规则。

未来换成另一部玄幻、仙侠、历史或都市小说，这套 Skill 仍然可以继续生成属于那本书的世界。

如果是一个也会在脑海里自动建立人物关系、地图场景和剧情时间线的小说爱好者，也许能理解为什么想做这件事。

真正想记住的，从来不只是人物名字和章节梗概。

而是阅读过程中，那个逐渐变得真实、辽阔，又只属于这本小说的世界。