企业官网建设流程全解析

简介：一套基于知识图谱的三国演义人物关系可视化与问答系统源码，面向计算机相关专业学生与人工智能初学者，可用于课程设计、毕业设计或项目练手。系统将三国人物关系以图谱形式展示，并支持自然语言问答，代码在本地编译运行通过，评审分达95分以上，难度适中，适合学习知识图谱构建与可视化交互实现。压缩包共361个文件，包含12个Python源码、HTML/CSS/JS前端交互文件、ipynb分析笔记、图片素材及CSV数据文件，前端引入Bootstrap等样式框架，整体约8.43MB，目录结构清晰，便于对照学习。已有352人学习下载。资源附带文档说明，可帮助理解人物关系抽取、图谱存储与问答匹配的实现思路；可视页面展示人物关联与属性信息，源码注释完整，便于二次开发，复用价值较高。项目内容经助教审定，是课设、毕设或竞赛练手的良好参考。

1. 三国人物关系可视化与问答系统：用知识图谱回答“刘备和曹操什么关系”

读《三国演义》时，凡纠结过“吕布和董卓到底是义父子还是君臣”“五虎上将之间有没有直接交集”的人，都会想要一张能随时查询的关系网。这个基于知识图谱实现的三国演义人物关系可视化及问答系统，就是冲着这个需求来的：把文本里散落的人物关系抽成结构化三元组，存进图数据库；前端用 ECharts 把整张网络画出来；问答模块通过自然语言问句直接生成图查询，把“谁和谁什么关系”变成一次图遍历。

系统整体是 Python 源码加文档说明的交付形态，开发流程覆盖了知识图谱构建、可视化、问答系统开发三个最主流的环节。对准备毕业设计或想系统学一遍知识图谱的人来说，它是一条完整可跑的链路，不是单个代码片段堆出来的 demo。对已经有工程经验的人，这套结构也方便整体替换数据源，换成公司组织架构、社交网络甚至学术引用关系都能复用。

适合谁来用？第一是计算机相关专业的学生，需要一份图谱类和自然语言处理交叉的课题；第二是刚接触 Neo4j 和 ECharts 的开发者，想看到一个项目怎么把它们串起来；第三是团队要做概念验证，想快速验证“知识图谱比关系型数据库好在哪”。下面直接进入构建环节。

2. 知识图谱构建：把三国演义文本整理成 Neo4j 实体与关系的全过程

2.1 为什么这个项目不选 MySQL 而选 Neo4j

在刚接触知识图谱构建时，最容易犯的错是沿用关系型数据库的选型逻辑。三国人物关系本身数据量不大，几百个节点、几千条关系，MySQL 完全装得下。但等你想查询“刘备手下哪些武将跟曹操交过手”这类多跳问题时，关系型方案就得持续 join 多张表，SQL 写起来极为痛苦；文档型数据库则适合存人物档案，但关系查询仍然要自己在应用层做图遍历。

Neo4j 在这里的核心优势是“关系”被设计成存储和查询的一等公民。人物之间的父子、君臣、兄弟、交战，每条都带类型和属性，存下来自然就是一张图。后续的可视化需要把整图数据导出，问答系统需要做路径查找、邻居查找，用 Cypher 一句话就能表达，不用拼十几行 SQL。社区版对本地开发和课程项目完全免费，一台普通开发机就能跑通全套。

在整条链路里，选 Neo4j 不是为了炫技，而是为了后面两个模块少写代码。可视化部分直接取邻接关系，问答部分直接做路径遍历，这是关系型数据库要绕很多弯才能补上的能力。

2.2 实体与关系的建模：把“义兄弟”建成两条边

常见做法是先把语义层面的人物关系拆成实体和关系两类。我一般会把节点定义如下。

关系上，人物与人物之间是重点。

这里有一个需要特别处理的坑：同一对人物之间往往同时存在多条关系。“刘备”和“关羽”既是结拜兄弟，又是君臣。我的做法是在两个人之间建立两条带不同标签的边，比如“兄弟”和“君臣”分开存，问答时用户问“两人的关系”就可以同时返回，问“谁辅佐谁”则按君臣过滤。边带上的属性，如“排序=二弟”，可以帮助前端悬浮框展示更丰富的信息。

建模完成后就要写导入代码。下面给出一段最小可运行的 Neo4j 写入脚本。

# -*- coding: utf-8 -*- from py2neo import Graph, Node, Relationship # 连接本地Neo4j。auth参数是用户名和密码，按你的安装环境改 graph = Graph("bolt://localhost:7687", auth=("neo4j", "12345678")) # 开发期每次执行先清空，避免重复导人多份节点 graph.delete_all() def create_person(name, style="", faction=""): node = Node("Person", name=name, 别名=style, 势力=faction) graph.create(node) return node def add_relation(a, b, rel, **props): r = Relationship(a, rel, b, **props) graph.create(r) # 搭建一个最小子集：刘备、关羽、张飞 liu_bei = create_person("刘备", "玄德", "蜀汉") guan_yu = create_person("关羽", "云长", "蜀汉") zhang_fei = create_person("张飞", "翼德", "蜀汉") # 兄弟关系用“兄弟”，从属关系用“君臣”，分开存 add_relation(liu_bei, guan_yu, "兄弟", 排序="二弟") add_relation(liu_bei, zhang_fei, "兄弟", 排序="三弟") add_relation(guan_yu, liu_bei, "君臣", 官职="前将军") add_relation(zhang_fei, liu_bei, "君臣") print("写入完成")

代码的关键点有三个：Graph构造函数里的bolt://localhost:7687是 Neo4j 4.x 之后默认的 Bolt 协议地址，端口是 7687，不是 7474；Node和Relationship来自 py2neo，节点属性直接用中文作 key 也没问题，Neo4j 能存储中文；delete_all()只适合开发和测试阶段，交付的项目不要让启动脚本默认执行它，否则历史数据一次全没。

2.3 批量导入：事务能救性能，但救不了混乱的标注

如果是 100 个人物、300 条关系的规模，逐条graph.create()依然能跑，但耗时明显增加，而且每一次 create 都在网络往返上耗费时间。常见做法是开一个事务，把一批节点和关系先攒在内存，最后一次性提交。

from py2neo import Graph, Node graph = Graph("bolt://localhost:7687", auth=("neo4j", "12345678")) people = [ {"name": "曹操", "别名": "孟德", "势力": "曹魏"}, {"name": "袁绍", "别名": "本初", "势力": "袁氏"}, {"name": "孙权", "别名": "仲谋", "势力": "东吴"}, {"name": "周瑜", "别名": "公瑾", "势力": "东吴"}, ] tx = graph.begin() for item in people: node = Node("Person", name=item["name"], **item) tx.create(node) tx.commit()

这里用graph.begin()拿到事务对象，在循环里tx.create()，结束commit()。要注意 py2neo 的事务对象在不同主版本间行为差异很大，如果你把旧版本的免费 python 源码拿来跑，大概率会在这一步翻车，具体排错后面专门讲。

另一点是，事务批量提交的同时必须保证数据本身规范：人物名是否统一、带别名去重、关系方向是否一致、势力名称是不是同一套叫法。“曹操”“曹孟德”“魏武帝”如果各建一个节点，图谱立刻出现一个人分裂成多个点的混乱局面。我一般会先维护一份中间 JSON 文件作为事实表，每个人物固定一个 name，别名放在独立字段里。导入阶段再通过清洗脚本做归一，人物节点直接以name为主键查询。

2.4 索引与约束：问答高频访问的 name 字段要不要加索引

关系查询之前总要先定位节点，尤其问答系统里“刘备”属于每问必查。给 Person 的 name 字段建索引能明显降低响应时间，数据量到几千节点时差距就能直觉地感受到。

graph.run("CREATE INDEX FOR (n:Person) ON (n.name)")

Neo4j 4.x 用上面的语法，5.x 里语法略有变化，建议在文档说明里标注你所用的 Neo4j 版本。创建唯一约束CREATE CONSTRAINT FOR (n:Person) REQUIRE n.name IS UNIQUE还可以防止重复节点再次出现。这条建议放在数据导入之后、问答模块之前，成本几秒钟，后面省的是排查重复节点的几个小时。

3. 人物关系可视化数据流：从 Neo4j 查询到 ECharts 力导向图的 Python 实现

3.1 为什么用 ECharts 的 graph 而不自己画

可视化部分的目标有两个：整体展示人物网络，交互时能看得见谁和谁直接相连。ECharts 是现在前端做知识图谱可视化最常用的方案，它的graph系列内置了力导向图布局，直接扔给它一份 nodes 和 links 数组就能出图。天然支持拖拽、缩放、节点悬浮显示关系类型，基本不需要额外封装。也有别的方案比如 G6、D3.js，但 ECharts 的学习成本最低，和 Flask 接口做 JSON 对接也最直接。

对“三国演义人物关系”这种中等规模网络，ECharts 的 graph 足够支撑的上限大概是一两千个节点，超过之后力导向布局会明显卡顿。所以可视化不是把全部图谱无脑铺上去，而是先按势力或关系类型过滤，保留主角团周围的子图。

3.2 Flask 接口封装：把 Cypher 查询结果转成 ECharts 可用的 JSON

后端和前端之间约定一个最简单的数据结构：nodes 列表存每个节点的 name；links 列表每条存储 source、target、relation。Flask 暴露一个接口，内部执行 Cypher 查询，把结果组装成 JSON。

from flask import Flask, jsonify from py2neo import Graph app = Flask(__name__) app.config["JSON_AS_ASCII"] = False # 让中文不被转成\\uXXXX graph = Graph("bolt://localhost:7687", auth=("neo4j", "12345678")) @app.route("/api/graph") def api_graph(): query = """ MATCH (a:Person)-[r]-(b:Person) RETURN a.name AS source, b.name AS target, type(r) AS relation LIMIT 200 """ rows = graph.run(query).data() # 用字典去重，一个节点只出现一次 node_map = {} links = [] for row in rows: source, target = row["source"], row["target"] node_map.setdefault(source, {"name": source}) node_map.setdefault(target, {"name": target}) links.append({ "source": source, "target": target, "relation": row["relation"], }) return jsonify({ "nodes": list(node_map.values()), "links": links, }) if __name__ == "__main__": app.run(port=5000, debug=True)

几个值得说的参数。LIMIT 200是调试期好帮手，先返回一小部分避免浏览器崩溃，不必每次全图展示。node_map.setdefault()是为了把出现在多条关系中的同一个人物合并成一个节点，没有这一步同一个“曹操”会被画成好几个点。JSON_AS_ASCII=False是 Flask 显示中文的关键设置，不加的话前端 fetch 拿到的会是\u64cd这类转义串，ECharts 能渲染，但调试极其痛苦。

这里还要提醒一点：graph.run().data()的返回结构在 py2neo 不同版本中不同。4.x 里通常能取到列表，某些版本却只返回一个小型可迭代对象。你在复制源码跑的时候，如果发现rows不是列表，第一反应不是改业务代码，而是先print(type(rows))确认 py2neo 和 Neo4j 版本配套。这也是整套流程里最容易踩的问题，后面避坑章节会展开。

3.3 前端渲染：ECharts 关系图的参数怎么调才好看又不卡

HTML 页面放在 Flask 的 templates 目录，核心是后端那个接口地址。前端拿到的 JSON 里 nodes 和 links 结构，直接给 ECharts 就能画。

<!DOCTYPE html> <html lang="zh"> <head> <meta charset="utf-8"> <title>三国人物关系图谱</title> <script src="https://cdn.jsdelivr.net/npm/echarts@5.4.3/dist/echarts.min.js"></script> </head> <body> <div id="graph" style="width:100%;height:800px"></div> <script> fetch('/api/graph') .then(r => r.json()) .then(data => { const chart = echarts.init(document.getElementById('graph')); chart.setOption({ title: { text: '三国人物关系图' }, tooltip: {}, series: [{ type: 'graph', layout: 'force', roam: true, label: { show: true, fontSize: 14 }, force: { repulsion: 300, // 节点间斥力，数值越大布局越散 edgeLength: 120 // 边长，调大让关联较疏 }, data: data.nodes, links: data.links.map(link => ({ ...link, lineStyle: { color: '#aaa' } })) }] }); }); </script> </body> </html>

repulsion和edgeLength是最值得调的两个参数。人物网络里有密集子图，例如蜀汉群臣彼此全连着，斥力小所有节点会挤成一团。有人喜欢把repulsion拉到 500，让离散的势力明显分开。label控制是否显示名字，节点多时先关掉label，鼠标悬停再显示，帧率会好很多。如果还想把不同势力按颜色区分，最简单的方式是给每个节点加category，在 series 里配置categories列表。

3.4 从“可视化大屏”角度扩展

如果答辩或展示时需要更完整的视图，常见做法是把 ECharts 图铺到一块大屏模板里，旁边搭配势力人物统计、关系类型饼图、事件时间线。后端接口不用改，只需要多暴露几个统计接口。像“魏蜀吴各自有多少核心人物”就是一个简单的按势力 GROUP BY 查询。可视化大屏项目经常在企业里做驾驶舱展示，做概念验证时用 ECharts 布局调整即可，不必引入太重的前端工程化体系。

4. 问答系统的意图识别与 Cypher 生成：一整套中文问句处理链路

4.1 先想清楚：问答不是大模型，是模板加实体的组合

这套问答系统不依赖大模型，核心是传统的“实体识别加意图分类”链路，意图分类做成模板规则，准确率在限定领域内已经够用。不是不可以接大模型，但部署成本和结果可控性都是问题，课程设计和中小型工程最常采用的可靠做法依然是规则模板。

用户的问法虽然多样，但归纳成几类即可。

4.2 实体抽取：先归一别名，再在问题里找人物名

实体识别是问答最耗精力的部分。《三国演义》里同名异称太多：关羽又叫“云长”“美髯公”，刘备也叫“玄德”。解决方式是把别名维护成一个映射表，分词后变回正式名。

import jieba alias_map = { "云长": "关羽", "美髯公": "关羽", "翼德": "张飞", "玄德": "刘备", "孟德": "曹操", "阿斗": "刘禅", "仲谋": "孙权", "公瑾": "周瑜", } def extract_entities(question): # 先做别名替换，把“云长”变成“关羽” text = question for alias, formal in alias_map.items(): if alias in question: text = text.replace(alias, formal) # 再从图谱里把所有人物名拿出来，逐个判断是否出现在问题中 persons = [p["name"] for p in graph.run("MATCH (n:Person) RETURN n.name").data()] entities = [] for name in persons: if name in text and name not in entities: entities.append(name) return entities

这个实现的坑也很明显：人物名若互相包含，比如“刘表”和“刘备”同时都会命中出现，容易出误匹配。我实际处理时先把人物名按长度倒序排序，优先匹配长名，同时排除掉已被覆盖的短名。还可以对问题先做 jieba 分词，只把分词结果集合和人物名集合做交集，减少“备”“公”这种单字误伤。

4.3 意图识别与 Cypher 模板：从规则到一条图查询

实体数组里的人物数量，配合关键问法词，能直接推断用户意图。下面是一种规则组合。

def decide_intent(question, entities): if any(w in question for w in ["什么关系", "认识吗", "关系是", "是什么关系"]): return "relation" if any(w in question for w in ["是谁", "介绍", "简介", "是什么人"]): return "intro" if any(w in question for w in ["儿子", "父亲", "手下", "主公", "兄弟", "妻子"]): return "relative" if any(w in question for w in ["谁和", "谁跟", "交过手", "打过", "对手"]): return "opposition" return "intro"

意图定了之后，每个意图配上 Cypher 生成函数。难点在“relation”意图：用户问“刘备和关羽什么关系”，对应图谱上两节点之间的最短路径。

def build_cypher(intent, entities): if intent == "relation" and len(entities) >= 2: # 路径长度限制在4跳，关系类型限定为人物之间常见的几种，避免全图扫 return """ MATCH p = shortestPath( (a:Person {name: $a})-[*..4]-(b:Person {name: $b}) ) RETURN [n IN nodes(p) | n.name] AS path, [r IN relationships(p) | type(r)] AS rels """, {"a": entities[0], "b": entities[1]} if intent == "intro" and entities: return """ MATCH (p:Person {name: $name}) RETURN p.name AS name, p.别名 AS style, p.势力 AS faction """, {"name": entities[0]} if intent == "relative" and entities: # 关系类型要白名单，防止方向搞反和遍历到非目标类型 return """ MATCH (p:Person {name: $name})-[r:父子|兄弟|君臣|夫妻]->(m:Person) RETURN m.name AS target, type(r) AS relation """, {"name": entities[0]} return None, None

上面的 Cypher 用了参数化查询，$a、$b、$name从 py2neo 传入，而不是拼接字符串。这是必须的操作：问句是用户输入，直接拼进 Cypher 可能造成查询注入或破坏语法。关系类型上我做了白名单限制，避免邻居遍历扫出“人物-战役-地点”这类非目标路径。[*..4]限制最多 4 跳，既保证刘备和远房人物仍能出直达路径，又防止在曹操这种高连通节点上炸出上百万条中间路径。

4.4 Flask 接口与前端对话框：把回答带回到页面

问答系统也需要一个 HTTP 接口，方便和可视化页面共用同一个后端进程。

@app.route("/api/qa", methods=["POST"]) def api_qa(): data = request.get_json() question = data.get("question", "") entities = extract_entities(question) if not entities: return jsonify({"answer": "没找到相关人物，换个名字试试。"}) intent = decide_intent(question, entities) cypher, params = build_cypher(intent, entities) if not cypher: return jsonify({"answer": "暂时不会答这类问题。"}) result = graph.run(cypher, params).data() answer_text = format_result(result, intent) return jsonify({"answer": answer_text}) def format_result(result, intent): if intent == "relation": # result 里是路径上的点和关系，拼成“刘备 -> 关羽（兄弟）” if not result: return "这两个人物没有直接联系。" path = result[0]["path"] rels = result[0]["rels"] text = path[0] for i in range(len(rels)): text += f" -> {path[i + 1]}（{rels[i]}）" return text if intent == "intro": if not result: return "查无此人。" p = result[0] return f"{p['name']}，别名{p['style']}，属{p['faction']}阵营。" if intent in ("relative", "opposition"): names = [r["target"] for r in result] return "、".join(names) if names else "没查到对应人物。"

这样一个 POST 请求就能完成问答。前端对话框用 fetch 提交即可。这里我再补充一点：如果你的问答需要更复杂的语义，比如“刘备的军师除了诸葛亮还有谁”，单纯模板会吃力。扩展方向是把问句改成“属性加关系加过滤条件”的槽位填充，本质上仍然是规则，但分解得更细。

5. 避坑指南：Neo4j 乱码、py2neo 版本冲突、ECharts 白屏的现场排查记录

5.1 现象：Neo4j 里的中文人名变成方框或乱码

加载 CSV 导入人物表后，Browser 里看中文全是乱码，或者成了问号。先检查 CSV 的编码格式。Excel 默认保存的是 GBK 或 ANSI，而 Neo4j 导入默认解析 UTF-8，两者一冲突就乱，这是导入阶段出现乱码的主因。

解决方式是统一用 UTF-8 编码保存。如果用 Python 写 CSV，就指定encoding="utf-8-sig"，这样 Excel 打开也不乱，Neo4j 读也不乱。如果是历史数据文件是 GBK，直接用iconv -f GBK -t UTF-8 relations.csv > relations_utf8.csv转换后再导入。这里没有玄学，就是编码对齐问题。

5.2 现象：网上下载的 Python 源码一跑，graph.run就报错或查不到数据

py2neo 3.x、4.x、5.x 之间的 API 差异很大：3.x 用graph.find()之类老写法，4.x 才全面转向graph.run().data()，5.x 又把部分写法调整过。如果你拿到的免费 python 源码大全里的项目用的是老 API，在新环境装新 py2neo 必然不兼容。

解决方法是先看项目里 requirements.txt 锁的版本，在虚拟环境按同版本安装：如果你用的是 Neo4j 4.x，常见搭配是 py2neo 4.x；Neo4j 5.x 则要谨慎看 py2neo 的兼容声明。最稳的操作是pip install py2neo==4.*搭配 Neo4j 4.x，然后再跑一遍graph.run("MATCH (n) RETURN n LIMIT 1").data()验证连通。

注意：先 print 一次返回类型再写后续代码。很多“接口能跑但没数据”的怪异问题，都是把data()和新的返回结构搞混了。

5.3 现象：Flask 接口返回给前端的中文全成了 \uXXXX

后端用 jsonify 返回，浏览器里看到"name":"\\u5218\\u5907"，页面显示正常但调试困难。这是 Flask 对非 ASCII 字符默认做 Unicode 转义的规则，不属于 Bug。

解决方法是启动文件开头加app.config["JSON_AS_ASCII"] = False。注意 Flask 3.x 中某些环境需要配置app.json.ensure_ascii = False才能生效，两种写法都记下来，遇到哪个用哪个。这个问题排查成本很低，但第一次遇到时很容易误判成前端编码问题。

5.4 现象：ECharts 关系图节点画出来了，但一条边都没有，页面还白屏

先排查 links 里 source/target 的值是否和 nodes 里 name 的值完全一致。ECharts 的 graph 要求 link 的 source 和 target 对应 data 中某个节点的 name 或 id，差一个空格都匹配不上。最常见翻车点就是从 Cypher 查出的名称末尾带了换行符，或者自定义 JSON 时把中文空格混进去。

解决方法是直接在页面里console.log(data)，肉眼检查每组 source 和 target。白屏则是数据量过大导致渲染线程长时间阻塞，先加LIMIT 200，再考虑减少显示的节点。

5.5 现象：问答系统问“刘备的儿子是谁”答错或答非所问

这类问题的坑在实体识别阶段就埋下了。人物名互相包含，如“刘备”和“刘表”同时出现在问题里时，如果只靠if name in question做匹配，很容易把“刘”单独识别出来。还有把“曹操的父亲是谁”错误识别成“曹操是谁”导致走 intro 意图。

解决方法是先做分词再匹配，配合别名归一表和意图规则白名单。比如“儿子”“父亲”“手下”是明确的关系词，出现任何一个就先走 relative 意图，不给 intro 分支机会。我还会维护一个打断测试集，把容易混淆的 10 个问法固定下来，每次改完实体抽取就回归一遍。

6. 换一个领域怎么复用：从组织架构到任意实体关系的最小改造法

6.1 怎么判断一个场景适合用知识图谱做

判断标准很简单：第一，实体之间关系是否多样且有查询价值；第二，查询里是否频繁出现“多少跳”或“路径”问题；第三，是否需要同时呈现整张关系网络。三个条件满足任意两条，知识图谱就比普通数据库更合适。公司组织架构里的部门与人员汇报关系、社交平台上用户关注网络、学术论文的作者与引用关系，都是典型场景。

6.2 四个改造步骤与验收方法

把三国项目迁移到新领域时，只需替换数据层、实体类型、关系类型、问答模板四件事。

# 通用化的节点写入函数：第一个参数决定实体类型标签 def create_entity(label, name, **props): node = Node(label, name=name, **props) tx = graph.begin() tx.create(node) tx.commit() return node

事情类似：把 Person 换成组织架构里的 Employee，把“君主”换成“汇报给”，“参与战役”换成“参与项目”。问答的意图模板也要重新归纳一组问法，比如“谁汇报给谁”“哪个部门负责人是谁”。改造数据层后用固定测试集验证，准备 15 到 20 条真实问题，记录准确率基线。我一般会留一套 20 条问题的回归集，每改一次 NLP 逻辑跑一遍，指标掉头就说明改出了问题。

最后说一个我的习惯：全套代码跑通以后，别急着往新项目里复制。先给自己 10 分钟，把问答系统的 20 条测试问题从头过一遍，看返回格式是否统一，再决定要不要加新意图。第一次用知识图谱做课程设计时，我在这上面返工过两轮，血泪经验就是测试集越早建越好。希望帮到你。

本文还有配套的精品资源，点击获取