遇到 Seed Evolving，我终于把脑海里的小说世界图谱做出来了：《斗破苍穹》篇
背景
小说爱好者集合啦！
作为一个资深小说爱好者，我看过的小说可能已经有几百部。玄幻、仙侠、历史、都市，只要故事足够吸引人，我就能顺着一个世界一直读下去。看小说时，我的脑海里经常会自动生成一张图。
主角现在站在哪里？刚刚遇到的人是谁？两个人之前发生过什么？这个家族和那个宗门是什么关系？城池外面是山脉、坊市还是学院？一场战斗结束后，人物的身份、实力、处境和关系又发生了哪些变化？
这些信息并不是一张静态的人物表，而是一个随着剧情不断扩展的世界。人物会从陌生人变成伙伴，也可能从合作走向冲突；地图会从一个小镇扩展到更大的区域；新的家族、学院和宗门会陆续登场；前面看似普通的一次相遇，也可能在几十章之后成为重要线索。
阅读量越来越大之后，我发现自己记住故事的方式，并不是背诵人物介绍，而是在脑海里维护这样一张"小说世界图谱"。
它有地图、有时间、有关系，也有正在变化的人和势力。
可惜，这张图一直只存在于脑海中。一本小说读到几百章，中途停几天再回来，我仍然要往前翻：这个人是什么时候出现的？他和主角发生过什么？这个地方属于哪个势力？某段关系是在什么时候改变的？
其实我觉得，最正宗的看小说的方法是：不带脑子去看，身临其境。但是，脑海中自然地会有这样一个地图。
我一直想把脑海里的这张图真正做出来。
不是做一张只能观看的关系图截图，而是做一个能够跟着章节生长、能够点击人物、查看地点、梳理势力和回顾事件的交互式小说世界。
于是，我借助 Doubao-Seed-Evolving 开发了"小说迷图谱 Skill"。
它会把小说正文整理成"章节---人物---关系---地点---势力---事件---证据"数据，再生成一个可以直接在浏览器打开的交互式 HTML。阅读者不必重新翻几十章，只要打开图谱，就能重新进入小说中的人物网络和世界结构。
为了把想法做成一个可以验证的真实案例，我选择了自己熟悉的《斗破苍穹》。公开案例先完成前 100 章，把人物、场景、势力、关系和事件逐步整理出来，再用这个案例反过来优化整套 Skill。
效果展示
生成的小说迷图谱包含四个主要视图：人物关系图、场景地图、势力图谱和事件时间线。
《斗破苍穹》在线体验：lucianaib2004.github.io/novel-fan-g...
Skill 开源仓库：github.com/LucianaiB20...
人物关系图负责回答"谁和谁发生了什么"。
每个角色都有独立的圆形头像，友好、互助、亲属、师徒、合作和敌对关系使用不同颜色的连线。点击人物后，右侧会展示其身份、登场章节、当前地点、所属势力、与主角的关系以及参与过的重要事件。
随着章节推进，人物会陆续出现，身份和状态会变化，关系也会进入新的阶段。你将看到的不只是"人物A认识人物B"，而是这段关系在故事中如何发生和演化。
场景地图负责回答"故事发生在哪里"。
山脉、阁楼、坊市、拍卖场、学院等地点拥有对应的语义图标。人物去过哪里，事件发生在哪里，地点之间有哪些连接，都可以从图中继续追踪。小说中的场景因此不再只是一个个地名，而是逐渐组成一个能够理解的空间。
势力图谱负责回答"这个世界由哪些组织构成"。
家族、学院、宗门和商业组织分别落在自己的板块中。势力之间的合作、敌对和其他联系会用不同线条表达。点击某个势力时，板块保持稳定，不会因为重新计算布局而突然散开。
事件时间线则负责回答"故事一路发生了什么"。
关键相遇、交易、战斗、身份变化和关系转折都会按照章节排列。忘记某段剧情时，可以沿着时间线快速找到它发生的位置，再结合人物、地点和势力继续理解前因后果。
前 100 章案例整理出 20 个人物、22 条人物关系、14 个地点、6 个势力、37 个关键事件和 99 条可回查证据。
我还顺手加了一个阅读进度功能：选择某一章时，图谱只展示当时已经出现的信息，未读章节标题和后续变化暂时隐藏。它并不是项目想表达的核心，但能让读者在阅读过程中放心使用这张图。
小说迷图谱真正想做的，是把人物经历、空间场景、势力结构和故事变化放到同一个可以探索的世界里。
模型介绍
Seed Evolving
本项目开发使用的全部是由 Doubao-Seed-Evolving 完成。
它强调持续演化的模型理念，可以按照周级别持续更新。开发者围绕一个稳定入口构建项目，不需要因为模型能力迭代频繁调整整套调用方式。
模型详情：ark.volcengine.com/region:cn-b...
对小说迷图谱这种需要连续读文件、修改代码、运行测试和反复检查页面的长程任务来说，订阅方案省去了频繁切换接入方式的麻烦。不同类型的任务可以按需选择模型，而本文的项目开发与能力体验主要围绕 Doubao-Seed-Evolving 展开。
在小说迷图谱中，我尤其看重两项能力：百万级长上下文，以及 Coding & Agent 场景下的长程任务处理。
小说天然是一个长上下文场景。
一个人物可能在前面以"黑衣人""老者"或其他临时称谓出现，几十章后才正式具名；某个地点早期只是被提到，后面才成为主要舞台；一段关系也可能经历陌生、接触、合作和冲突。
如果模型只能看到零散片段，就很容易把人物认错、把地点混在一起，或者只记住当前章节而忘记前面的铺垫。
实际实现时，我没有把数百万字正文不加处理地塞进一次请求，而是先解析章节，再按连续章节分批提取，并让模型同时参考前序实体索引、数据规则和当前正文。长上下文让这些信息能够在同一个任务阶段里保持关联，稳定 ID 则让人物、地点和势力可以跨批次延续。
Agent 能力负责把想法推进成真实工程。
它需要读正文，也需要操作文件、编写脚本、构建数据模式、生成 HTML、运行测试、查看错误、进入浏览器检查页面，再根据使用体验继续修改。小说迷图谱并不是模型回答一个问题后的产物，而是一轮轮开发、反馈和验证之后形成的项目。
Agent Plan
这次我并不是单独按量调用模型接口，而是直接购买了火山方舟的 Agent Plan 来进行测试和完成项目。
获取地址：ark.volcengine.com/region:cn-b...
我购买的订阅包包含火山自家的 Seed 系列，也支持 GLM、MiniMax、DeepSeek、Kimi 等国内主流模型。使用时可以根据任务需要自由切换，也可以开启 Auto 模式，让平台根据任务自动调度模型。
对于接入AI 工具以及接入方式，也是极其简单。
评论区留下你目前正在看的小说，我现在小说已经看完了，下一本我看谁推荐的小说，我的火山API，他直接拿去便用。
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 仍然可以继续生成属于那本书的世界。
如果你也是一个会在脑海里自动建立人物关系、地图场景和剧情时间线的小说爱好者，也许你会理解我为什么想做这件事。
我们真正想记住的，从来不只是人物名字和章节梗概。
而是阅读过程中，那个逐渐变得真实、辽阔，又只属于这本小说的世界。
如果觉得有用，点个「赞」和「在看」支持一下 💪