权游人物关系图谱：用图模型与模拟器解码维斯特洛

打开本地项目文件夹，几十个以日期和数字命名的存档里，“A Game of Thrones(83)” 格外显眼。别误会，这不是剧集第83集，也不是原著第83章，而是我为了弄懂这部作品里盘根错节的人物关系，迭代到第83版的数据项目存档。很多人说《权力的游戏》最厉害的地方是“猜不到谁下一秒会死”，但作为一个常年和数据打交道的作者，我始终觉得，它真正厉害的地方是把一堆人物关系像棋盘一样摊开，让每一个选择都像落子一样产生连锁反应。为了验证这个想法，我把原著文本、人物关系、家族领地这些材料揉在一起，做了一个关系图谱和推演模拟器。这篇文章就从“为什么一个文学作品会让我想到建图建模”说起，记录我从零到一建设这个项目的过程，以及那些常规文档里不会写的坑。

1. 为什么我非要给“权力的游戏”建一个关系模型

1.1 权游的复杂来自关系网络，而不是剧情节点

如果你只是按时间线看权游，很容易陷入“谁登场了、谁死了、谁和谁打起来了”的列表式记忆。但真正让这个故事区别于普通宫廷剧的，是人物之间那条看不见的关系网。举个简单的例子：一个角色在关键时刻背叛另一个角色，表面上看只是一瞬间的决定，但往前翻好几季，你会发现他们之间早就埋了长线，可能是家族旧怨，可能是某次联姻的副作用，也可能是第三方刻意制造的误会。单看剧情节点，这些全是“跳跃”的，可一旦把关系边画出来，一切又会变得异常顺滑。

我最早想做的，就是把这种“顺滑感”变成一张可以看得见的图。每个角色是一个节点，角色之间的关系是一条边，边的正负和粗细代表合作、效忠、仇恨、血缘。听起来很简单，但真正动手之后才发现，这部作品的复杂程度远超想象：主线角色加配角上百人，家族之间的联姻、人质、地盘、盟友关系交错在一起，光靠人工梳理根本梳理不完。这也是为什么我需要用图模型来做，而不是继续靠脑补。

1.2 项目目标不是预测剧情，而是还原“信息差”

做图之前我给自己定了个规矩：这项目不预测谁会死，也不做“强行剧透”。权游最迷人的地方，恰恰是读者和角色之间存在大量的信息差。POV写法让每一章都只能从一个视角去看世界，读者知道的事往往比某个角色多，也可能比某个角色少。很多悲剧不是因为角色愚蠢，而是因为每个人都只拿着拼图的一部分。

所以我的目标变成了另一件事：用一个关系模型去还原“每个角色在某个时间点掌握了哪些关系”。如果把人物关系图当成一张完整的棋盘，那每个角色看到的其实只是棋盘上的一小块。项目要做的不是展示上帝视角，而是模拟出不同角色的“局部视角”。这个目标听起来更温和，可做起来反而更有意思，因为它逼着我去整理每一条关系的“可见时间”和“可见范围”，后来还直接推动了模拟器的设计。

1.3 83个版本是怎么攒出来的

项目文件夹为什么叫“83”？因为真的改了83版。第一版特别幼稚，就是把所有角色塞进一张静态图，连线密密麻麻，根本没法看。第二版好一点，按家族给节点上了颜色。第三版加了时间轴滑动，能看到关系随剧情变化。第四版开始做关系权重，第五版调整布局……后来我越来越觉得，光“看”还不够，得让这张图“动起来”，于是又加了事件推演、回合制模拟、可视化交互。每加一个新想法就可能推翻前面不少设计，文件名里的数字就这样一路涨到了83。

这个过程让我特别有感触：做内容项目也好，做技术项目也好，最不值钱的是“想法”，最值钱的是“迭代后的废弃文件”。83这个数字不是用来炫耀勤奋的，而是用来提醒我，好结构不是一次设计出来的，是反复调整出来的。

2. 数据清洗与关系抽取：最容易劝退人的环节

2.1 数据来源与字段设计

建模型的第一步是搞数据。我手上没有官方数据库，也不可能手动录入几百个角色，所以整合了三类公开来源：角色列表、章节POV信息、以及由爱好者整理的角色关系表。另外，我还从原著文本里跑了一遍实体识别，把每个章节里同时出现的人物名抓出来，作为“共同出现”的辅助信号。

整个项目最后落在三张表上，结构大致是：

这三张表看着简单，实际上是整个项目的骨架。最难的不是设计字段，而是把零散的、互相矛盾的文本信息统一进去。同一个角色在不同资料里的名字可能不一样，同一个事件有的资料说是阴谋、有的资料说是意外，这些冲突必须在清洗阶段就解决，否则后面所有算法结果都会被带偏。

2.2 处理角色别名：同一个人的三个名字

权游里角色别名多到离谱，有人用全名，有人用绰号，有人用私生子的家族姓，同一个角色在不同章节里常常以完全不同的词出现。如果你不做别名表，实体识别会把一个人当成好几个人，图里就会冒出一堆幽灵节点。

我的办法是建一个aliases表，把主ID和所有可能的写法绑定。比如一个私生子角色，早期叫“雪诺”，后来有了新身份，名字也跟着变；再比如一些角色有头衔、有外号、有真名，这些全都要映射到同一个ID上。清洗完这一层，节点数量立刻缩水了差不多三分之一，很多原本看起来没关系的角色，其实只是被你拆成了两个ID。

这里有个小教训：别信现成的实体识别结果，一定要自己抽检。我当时随机抽了五十组识别结果去人工核对，至少五组有合并或拆分错误。比例看着不高，但到了图算法阶段，一点点噪声都会被放大。

2.3 血缘、效忠、敌对三类关系怎么打权重

有了节点，下一步是给边定权重。我一开始贪心，把所有关系都当成平等的一类，结果图变得平面化，看不出主次。后来我把关系分成三大类：血缘、效忠、敌对，每一类给不同的权重区间。

这个权重设计不是拍脑袋。血缘关系最稳定，所以给高基础分；效忠关系会随局势变化，但不能太低，否则体现不出封建体系的力量；敌对关系则要拉开方差，因为“打过一仗”和“互相看不顺眼”完全不是一回事。权游里敌对关系的破坏力往往大于血缘，所以上限给得比血缘还高。

这条规则很快就在图里体现出来了：一些在剧情里呼风唤雨的家族，并不是因为盟友多，而是因为敌对关系带来的“被关注度”太高，让他们天然处在冲突中心。

2.4 代码实现：把表变成有向图

数据清洗完，接数据建模其实只有十几行代码。我用的是 Python 生态里的 NetworkX，它非常适合这种中小规模的图计算。

import pandas as pd import networkx as nx df = pd.read_csv("relations.csv") G = nx.DiGraph() for row in df.itertuples(): G.add_edge( row.source_id, row.target_id, rel_type=row.rel_type, weight=row.weight, reveal_chapter=row.reveal_chapter )

这里我刻意选了有向图而不是无向图。原因是“效忠”和“敌对”都有方向：A效忠B，不意味着B也效忠A；A恨B，也不代表B恨A。如果全用无向边，很多关键信息会丢失。当然，血缘关系天生是双向的，所以我在导数据时会把血缘边同时加两个方向，但权重折半，避免一条血缘关系被算成两条独立关系。

跑完基础统计我有点吃惊：节点数一百多，边数比预想的多得多，平均每个角色和七八个角色有关系。这说明权游的核心角色确实被编织在一张高密度的关系网里，这也为后面的中心度分析埋下了伏笔。

3. 图算法跑完，我发现“权力中心”不是你想的那个人

3.1 用PageRank模拟影响力和信息流动

如果说建图是搭骨架，那跑算法就是第一次给这张图“注入血液”。我最想看的指标是：到底谁才是这张关系网里真正的权力中心。单纯数关系数量太粗糙，所以我用了PageRank算法——也就是搜索引擎判断网页重要性的那套逻辑。放在故事里，它的意思变成了：一个角色是否重要，取决于他是否被其他重要角色关注、依赖或敌视。

pr = nx.pagerank(G, alpha=0.85, weight="weight") top_nodes = sorted(pr.items(), key=lambda x: x[1], reverse=True)[:10]

跑了之后，前十名里确实有几个手握重兵的王位竞争者，但真正的榜首却是一个情报总管。这个结果让我一下子明白了什么叫“信息即权力”。他在绝大多数冲突里不是亲自挥剑的人，却是几乎所有关键人物都会接触的信息节点。国王需要他，王后需要他，连流亡者也愿意听他说话。PageRank抓到的不是“谁最能打”，而是“谁在关系网上最绕不开”。

这个发现给了我很大的冲击：我们看剧时容易记住那些站在铁王座前讲话的人，但真正维系整张关系网的，往往是坐在信息交叉点上的人。权力不只是军队和血统，更是连接所有人关系的那条路径。

3.2 Louvain社区发现：阵营不是按地图画的

光看中心度还不够，我还想知道：如果把关系网自动分成几个派系，算法分出来的会和地图上的家族板块一致吗？我用 Louvain 社区发现算法跑了一遍，结果挺颠覆认知。

预期里“每个家族一个cluster”，实际跑出来是“跨家族的联盟cluster”。比如某个以北方为核心的家族，并不只和自家人聚在一起，而是和多个联姻家族、盟友、甚至曾经的敌人因为共同的短期利益被分进同一社区。更妙的是，同一个家族内部有时会出现分裂信号：家族成员分别被算法分到了不同社区，原因是他们效忠的对象不同，长期目标也不同。

这个结果让我重新理解了“阵营”这个词。地图上的颜色是不变的，但人物关系里的“社区”是随权重变化的。你今天和谁联姻，明天就会被算法划进谁的阵营。权游讲的根本不是地图边界，而是关系边界的持续重构。

3.3 最短路径揭示“阴谋捷径”

另一个有趣的算法是最短路径。权游里很多阴谋之所以成立，是因为两个看似遥远的人之间其实存在着一条极短的“路径”。我做了个小实验：随机挑两组看起来势不两立的人，计算他们之间的关系最短路径。结果中间往往只隔着一两个关键联系人。

这给我一种“六度分隔”照进维斯特洛的感觉。一个在北境边缘的贵族，和一个在君临权力中心的人，最短路径可能只经过一个到处旅行的情报贩子、一个当过俘虏的骑士、或者一个两边都不得罪的商人。任何两条线之间的桥梁角色，都比他的头衔更值得警惕。

对于创作者来说，这个算法特别有启发：如果你想写一场“所有人都没想到”的联合，可以先画一张关系图，找一找两个阵营之间最短路径上的人，让这个中间人成为暗线。权游里那些看似突然的联姻和背叛，很多都是借这种“路径捷径”完成的。

3.4 一个容易被忽略的边权重陷阱

这一节必须单独拿出来写，因为我在这个坑里蹲了很久。一开始我偷懒，把“两个角色共同出现的章节数”直接当成关系权重：同框次数越多，边越粗。结果跑出来中心度榜单前排全是“御前会议常驻成员”“跟着主角长途旅行的跟班”这类人，因为他们戏份多、同框多，但并不掌握真正的权力。

这个噪声本质上来自“共同出现”和“真实互动”的区别。两个人出现在同一场婚礼上，不代表他们之间有有效关系；两个人虽然是陌生人，却可能因为一纸婚约被绑在一起。我后来把共同出现权重降为辅助信号，把血缘、效忠、敌对这些明确事件作为主权重，结果才变得可信。

所以给想做类似项目的人一个建议：关系数据贵精不贵多，别把“共现”当“关系”。先把强关系的边打牢，再拿弱关系做补充，否则算法会被这种虚高权重直接带偏。

4. 从图到模拟器：把静态关系变成看得见的权力更迭

4.1 模拟器的三个核心规则

静态图看久了会腻，而且它只能回答“现在谁和谁有关”，回答不了“下一步谁和谁决裂”。于是在第50版左右，我开始把图改造成模拟器。我的想法是做一个极简回合制推演：每个角色不是被剧本推着走，而是被关系网络推着走。

规则定得很克制，一共三条：

• 每个角色拥有三个内部状态：忠诚倾向、当前影响力、存活状态。
• 每个回合随机抽取一张事件卡，事件卡会改变若干条边的权重或触发节点属性变化。
• 每个势力的总影响力，等于它在当前关系图中所在连通分量内所有存活角色的影响力之和。

这三条规则看着简单，但组合起来效果很惊人。随机事件卡保证了故事不会走向唯一的“理性最优解”，忠诚倾向和个人恩怨又会把结果越推越偏。权游里很多灾难不正是这样来的吗？每个人都按自己的局部理性做选择，最后合起来却是全局失控。

4.2 回合制推演中的状态更新逻辑

模拟器的核心代码并不复杂，最麻烦的是每回合都要重新计算一次影响力分布。我用PageRank作为影响力的动态来源，事件卡先修改图结构，再重新计算PageRank，然后把新数值写回节点状态。

import random events = ["betrayal", "marriage", "assassination", "alliance", "war"] event_probs = [0.2, 0.15, 0.2, 0.25, 0.2] for turn in range(20): event = random.choices(events, weights=event_probs)[0] apply_event(G, event, turn) influence = nx.pagerank(G, alpha=0.85) for node in G.nodes: G.nodes[node]["influence"] = influence[node] record_state(node_states, turn)

这么做的好处是，每一次事件都不会只影响当事人。一场联姻会合并两个家族的若干条关系边，一次暗杀会让所有指向被杀者的边失重。这非常像故事里的“蝴蝶效应”：角色A的一封密信，最终可能改变角色H的命运，只是因为中间隔着一整条关系网。

4.3 在83版里我自己跑出的一场小规模混战

我不想让这个项目变成一个“预先写好的演示”，所以故意把初始关系设置在某卷开篇的节点，然后跑20个回合，看看随机事件会把局势推向哪里。第一次跑出的结果就很有意思：一个边缘家族因为连续抽到两次联姻事件和一次背叛事件，迅速成了连接两个敌对阵营的枢纽，总影响力一路飙升；而另一个开局巨头，因为核心角色接连卷入暗杀事件，盟友纷纷解除效忠，最终从第一梯队滑落。

我当然知道这不是剧情预测，权游的剧本有创作者的主观设计，不可能被随机规则复现。但这个实验让我直观地理解了“权力是流质的”：关系网络里没有一个节点的位置是永久固定的，一次微小的边权重调整，可能让中心迁移。真实故事里的那些“突然反转”，放到模拟器里其实只是某些关键边的增删。

4.4 可视化交互上踩过的真实坑

模拟器跑通了，接下来就是让结果能被看见。这一块踩的坑比建模阶段还多。第一版用标准力导向布局，节点老是飘来飘去，上一秒还看的连线，下一秒就被弹开；浏览器窗口大小一变，布局就像抽风一样重排。后来我不得不给节点设置固定初始位置，并锁定拖动后的坐标，才让画面稳定下来。

节点标签重叠也是个老大难。关系网一密，标签就会互相盖住。最后我只能做分层展示：默认只显示阵营标签，选中某个角色时才展开他的邻居标签。加上边的颜色和图例之后，图才开始真正做到“可读”。性能方面，超过一百个节点、几百条边的图，如果用简单DOM渲染会明显掉帧，这个规模最好交给Canvas或WebGL方案处理。

推广到任何做可视化项目的朋友：先想清楚“用户要读的是关系，不是看线条跳舞”。再酷炫的动态效果，如果让你看不清节点和边，就是负优化。

5. 做完之后我重新理解了“权力的游戏”这五个字

5.1 叙事不是链状，是网状的

在建完图、跑完算法、做完模拟器之后，再回头看权游，我的感受完全不一样了。以前我觉得它的剧情是一条接一条的支线推进，现在我知道它是一张密度极高的网。每个角色的动机来自他在网上的位置，而不只是他内心的“善恶”。那些被观众吐槽“转变突兀”的角色，如果放回关系网里，其实早有征兆，只是你只盯着他一个人的剧情线，没看到他身上那些边的变化。

这个认知可以直接迁移到内容创作上。如果你也在写多人物故事，建议列一张“信任与仇恨清单”，把每个角色和其他人的关系权重都标出来。很多让人记住的情节，往往不是孤立事件，而是某条边从正变负、从弱变强的瞬间。

5.2 “信息差”才是编剧最大的武器

除了网络结构，这个项目还让我看清了一件事：权游最锋利的不是刀剑，是信息差。POV结构让每个视点角色都只能看到关系子图的一部分，读者跟着某个角色走，会误以为自己掌握了全局。可一旦把全局图铺开，你会发现真正的冲突往往来自两个角色各自拥有半条信息，却没有机会交换。

我在模拟器里也做了类似的约束：每张事件卡只对特定阵营可见，模拟过程中会生成一份“角色感知偏差报告”。报告里经常出现令人毛骨悚然的发现：一个角色以为自己的盟友稳如泰山，但在全局图上，那位盟友已经被另一边的高权重关系拉走了。权游的悲剧感，很大程度就来自这种“各自为政的信息孤岛”。

对一个写故事的人而言，这或许是比“反转”更高级的技巧：不是让读者什么都不知道，而是让读者知道得比角色多一些、又不完全多。差出的那一点，就是悬念和共情的双重来源。

5.3 这套建模方法还能用在哪儿

项目做完之后，我把这套“关系建模”的思路抽离出来，发现它远远不限于这部作品。做舆情分析时，可以用来观察关键账号之间的传播路径；做游戏时，可以用来测试角色平衡性，看谁天然处在中心位置；做小说设定时，可以用来检查世界观是否自洽，避免出现“明明有深仇大恨的角色突然亲如兄弟”这种设定断裂。

我现在手头正在试的一个新项目，是把这套图思维用到短篇故事生成上：先随机生成一张小规模关系网，再让它演算出几条冲突线，最后由我改写成文章。效果还不够稳定，但方向让我兴奋。说到底，一个故事和一张关系网络遵循着同一个逻辑：连接产生力量，而力量一旦偏离预期的方向，就成了冲突。83个版本的迭代没有白费，它让我换了一双眼睛看故事，也看清楚了那些藏在文本背后、从不明说却始终在运作的关系。