先说清楚，harrypotter09-2不是某个哈利波特游戏的破解补丁，也不是资源站神秘代号。这是我个人内容整理项目的命名——第 09 号专题的第二版迭代，主题只有一个：把《哈利·波特》魔法世界里散落的人物、咒语、生物、事件和魔法物品，整理成一套自己能快速检索、随时调用的结构化档案库。很多人觉得“喜欢哈利波特”就是多看几遍书和电影，但真当你想写同人、做考据视频、或者单纯想在聊天时一秒报出“某件魂器在哪一部第几章被摧毁”的时候，就会发现自己脑子里的记忆根本不够用。
这个项目适合三类人：一是哈利波特深度爱好者，想给自己的热爱建一个“数字档案库”；二是做内容创作的人，需要快速查阅世界观细节，不用每次翻原著；三是想练习个人知识库搭建、静态站点发布的内容整理控。这个项目我前后迭代了两版，第一版还能看，第二版算是真正跑通了从收集、分类、校验到发布的全流程。下面就把这版的设计思路、字段方案、实操流程和踩坑记录都摊开讲。
1. 项目定位：从“爱好收藏”变成“可检索档案库”
1.1 为什么非要把哈利波特资料“结构化”
很多人觉得整理哈利波特资料，建个文件夹存图存文就完了，没必要搞那么重。我一开始也这么想，但实际用下来发现几个痛点。
第一个痛点是“找回成本”太高。今天想确认“赫敏第一次使用时间转换器是三年级还是三年级下学期”，这种问题靠脑子回想很容易混淆，靠搜索又要翻半天网页，而且网页质量参差不齐。第二个痛点是“跨媒介差异”很难对应。原著和电影之间的人物外形、事件顺序、咒语效果都有出入，聊天和写作时混用会出错。第三个痛点是随着收集越来越多，散落的笔记、截图、网页收藏之间没有关系网，根本串不起来。
于是第二版我定了这样一个核心原则：不是做“资料囤积库”，而是做“可交叉检索的档案库”。所有信息都拆成最小单元，每个单元有独立条目、分类标签、来源标记和关联指向。比如哈利·波特这个人，不只存“出生于1980年7月31日”，还关联到他的父母、教父、魔杖、扫帚、守护神形态、魂器关联物件、主要事件列表。这样任何一个入口进去都能顺藤摸瓜。
1.2 整体信息架构：八张核心表打通魔法世界
第二版我把整个魔法世界的档案分成了八类，这八类可以覆盖绝大部分需要查证的内容。分类数量不是拍脑袋定的，而是做过一次“考古挖掘”——把第一部到第七部中频繁出现的专有名词全部列出来，按词性归并后总结出来的。
第一类是人：人物档案，涵盖主角、配角、幽灵、画像中的人物、历史人物。第二类是咒：所有咒语、魔咒、不可饶恕咒以及魔法能力（比如大脑封闭术、阿尼玛格斯）。第三类是器物：魔法物品，包括魂器、死亡圣器、日常魔法道具。第四类是地点：包括现实地点和魔法地点，从女贞路到霍格沃茨各楼层都要能定位。第五类是生物：从龙、鹰头马身有翼兽到摄魂怪、家养小精灵。第六类是组织：凤凰社、邓布利多军、食死徒、魔法部各司。第七类是事件：按时间线排列的大事件。第八类是书籍与学科：课本、教材、预言家日报、唱唱反调这类信息媒介。
每一条档案都有自己的唯一编号。比如人物编号前缀是CHAR-，咒语是SPEL-，器物是ARTI-，事件是EVNT-。这八个类别相互独立，但通过关联字段深度连接，形成一个随时可以拆开重组的信息网络。
1.3 版本号迭代逻辑：为什么叫 09-2 而不是 v2.0
这个项目取名看起来随意，实际上有自己的一套命名规则。09 代表这是我整理的第九个大主题专题，之前还有八个主题，分别是不同的小说和影视世界观。由于整理的深度和复杂度在所有专题里最重，所以它单独占了一个编号。
09-2 的“2”代表第二版大迭代。第一版是 09-1，当时的整理方式很简单：用 Word 和 Excel 做了一堆表格，字段没有统一规范，来源标记也不完整，做了一半就膨胀到几千行，检索起来很痛苦。第二版推倒重来，把所有条目全部改成 Markdown 文件 + 统一字段模板，变成了文本化、可版本管理的格式。
命名里带版本号最大的好处是：随时可以回退，也随时可以跟旧版对比差异。当你在一套内容体系里连续迭代超过半年，就会明白“版本边界清晰”比“内容多”重要得多。我甚至会把每一次批量修改记录在更新日志里，方便之后查某个字段为什么变成了现在的样子。
2. 字段设计与实体拆分：让每条档案都能被调用
2.1 人物档案的字段模型与关系设计
人物档案是整个档案库中最核心也最复杂的实体。一个完整的人物条目，需要记录的信息不只是“姓名-学院-血统”，还有人物在整个世界观网络中的位置。
我的字段模型是这样的：基础身份（姓名、别名、出生/死亡日期、血统、国籍）、魔法属性（学院、守护神、魔杖、博格特）、关系网络（家庭成员、恋人、好友、宿敌、师生关系）、关键事件（每次出现时参与了什么大事，事件编号关联到 EVNT）、履历轨迹（从入学到最终结局的逐年变化）、出处与备注（这个人在原著第几章首次出场、电影由谁饰演，以及任何值得标注的个人推测）。
每条字段尽量可枚举，比如学院这一项用下拉选项而不是自由文本，避免“格兰芬多”和“格来芬多”这种同义词导致检索分裂。
人物与人物之间的关系不要堆在一个长文本里，而是拆成若干条独立关系记录。比如“哈利·波特”和“西里斯·布莱克”的关系可以拆成两条：“教子—教父”和“詹姆·波特的好友—詹姆·波特的儿子”。每一条关系都单独存一个文件，方便反查：想知道“某人的教子教父是谁”，只需要全库搜索“教父”这个关系标签，而不是去读每个人的长传记。
2.2 咒语和魔法物品的字段要点
咒语档案是另一个容易做乱的部分。原著中的咒语信息高度碎片化，同一个咒语的完整效果往往分散在好几部书里，而且有的咒语只有名字没有详细效果，有的咒语是电影原创。
我给每个咒语设计了这几个字段：咒语名（拉丁原文、中文译名）、类型分类（决斗类、防护类、恶咒类、治疗类、变形类、召唤类、幻影类）、效果描述、施法动作或者手势要求、已知使用者、首次出现位置、后续升级版本（比如“呼神护卫”在后期有没有出现过实物守护神）。
实体档案的设计关键在于“跨媒介标记”。比如“活点地图”这个条目，我会在“首次出现”中写清是《阿兹卡班的囚徒》原著第十章，而在“媒介差异”字段里备注电影里它的展示方式有所不同。这样不会把两个媒介的信息混为一谈。
有一类特殊物品——魂器和死亡圣器——需要加单独的追踪字段，记录每个物件目前的保管链条：谁制造、谁持有、在哪里被摧毁、被什么方式摧毁。比如“赫奇帕奇金杯”的链条是：赫尔加·赫奇帕奇→赫普兹巴·史密斯→伏地魔→贝拉特里克斯·莱斯特兰奇（古灵阁金库）→赫敏（潜入金库）→罗恩与赫敏在密室中用蛇怪的毒牙摧毁。这个链条字段的价值极高，写同人和讨论战力时可以一秒引用。
2.3 书影差异的“裂痕管理”方案
原著七本书与八部电影之间信息不一致是老生常谈的问题。我在第一版时强行统一，结果两边的事实对不上，越改越乱。第二版换了一个思路：不统一，而是建立“平行记录”并加差异说明。
每条档案中凡是涉及书、影信息不一致的地方，都会拆开成两个内容块：原著版本与电影版本，同时用“差异说明”字段标注冲突点和影响范围。比如“西弗勒斯·斯内普的守护神和莉莉的关系”这件事，原著和电影在表现方式上是基本一致的，不加说明；有的细节如果电影省去或改编了，就单独说明“仅出自原著”。
这种平行记录方式最大的好处是不需要做真伪裁决，把资料工作从主观判断变成了客观陈列。适合内容创作引用，也适合给新粉解释“为什么有人说某设定变了”。我在做同人素材拆解时，可以直接拿原著字段做底稿，再拿电影字段做视觉参考，互不污染。
3. 搭建实操：从空文件夹到完整档案库的落地过程
3.1 文件目录结构与索引命名规范
第二版彻底放弃了数据库表格文件，改用纯文本 Markdown + 固定目录结构。目录骨架很长这样：
harrypotter09-2/ ├── README.md ├── _index/ │ ├── index_all.md │ ├── index_char.md │ ├── index_spell.md │ └── index_event.md ├── 01_characters/ │ ├── CHAR-HarryPotter.md │ ├── CHAR-HermioneGranger.md │ └── ... ├── 02_spells/ │ ├── SPEL-Expelliarmus.md │ └── ... ├── 03_artifacts/ ├── 04_places/ ├── 05_creatures/ ├── 06_organizations/ ├── 07_events/ ├── 08_media/ └── _assets/ └── images/目录用两位数字编号加英文复数命名，文件用“类型前缀 + 对象名（英文驼峰）”的方式命名。这样做的目的有三个：目录扫一眼就能知道整体结构，文件按名称排序后条目顺序是稳定的，而且在任何支持文本搜索的工具（VS Code、Obsidian、Grep）里输入前缀加关键词就能秒级定位。
索引文件是这套系统的门面。index_all.md 维护全量清单，每行格式是“编号 | 名称 | 分类 | 一句话摘要 | 文件相对路径”，这个文件看起来简单，但价值非常高。我每次整理完一批内容都会重新生成一次索引，并用脚本检查有没有文件被遗漏或者编号重复。
3.2 内容录入流程：从原著摘录到档案成文
录入一条新档案的流程，可以归纳成“取证—拆解—关联—校验”四步。
第一步取证。把原著电子版、电影片段、官方设定集（如《哈利·波特与被诅咒的孩子》剧本之外的周边参考书）放在手边，优先引用原著，而不是搜索网页。第二步拆解。把引用的原文摘录到“原始素材”字段里，摘录后面必须标注来源，比如“《凤凰社》第25章”，避免之后想溯源的时候找不到原始出处。第三步关联。把字段中出现的所有事物与人名替换成对应的内部编号，比如写邓布利多时写CHAR-AlbusDumbledore而不是“老校长”。第四步校验。跑一次自动关联检查，看有没有编号指向不存在的文件。
我不建议边看书边录入，效率太低了。实际操作更推荐“按实体批量收集”，先把某一本或某一部的专项实体全部摘完，再统一拆字段。例如只整理第三部《阿兹卡班的囚徒》中的时间转换器相关内容，整理完时间线相关的事件后，再回到时间转换器的器物条目，把事件编号关联进去。这样每次整理的信息范围都可以验证，不会漏掉某个细枝末节的出处。
3.3 用脚本做交叉引用与完整性检查
做实体多到一定程度，手工检查不再可靠。我写了一些小脚本进行自动检查。按经验看，这个检查脚本是第二版质量最关键的保障。
脚本的功能主要有四块。第一块是编号完整性检查：扫描所有 Markdown 文件中出现的CHAR-、SPEL-等编号，把提到的编号集合和实际存在的文件集合做差集，输出“引用了但不存在”和“存在但从未被引用”的两种情况。第二块是索引更新：读取目录下的文件头信息，自动生成 index_all.md。第三块是双链解析：把[[编号]]形式的内容解析出来，生成一个链接关系矩阵。第四块是格式检查：看看每个文件是否包含了必填字段，比如人物必须有“学院”和“魔杖”字段，没有的话就输出告警。
这里给出一个简化版的编号检查示例，用 Python 写，思路足够理解：
import re import pathlib root = pathlib.Path("harrypotter09-2") prefix_map = { "CHAR": "01_characters", "SPEL": "02_spells", "ARTI": "03_artifacts", } existing = set() for prefix, folder in prefix_map.items(): for p in (root / folder).glob(f"{prefix}-*.md"): existing.add(p.stem) referenced = set() for md in root.rglob("*.md"): text = md.read_text(encoding="utf-8") for pid in re.findall(r"(CHAR|SPEL|ARTI)-[A-Za-z0-9]+", text): referenced.add(pid) missing = referenced - existing unused = existing - referenced print("缺失引用:", missing) print("孤立条目:", unused)这个脚本大概只有二十行，但跑一次能省掉两三个小时的肉眼检查。建议整理到 500 条以上之后每两周跑一次，比用到再查要稳得多。
3.4 发布与多端同步：把纯文本档案转成可浏览站点
档案库做到能查只是第一步，如果想让朋友或者未来的自己能像逛 Wiki 一样使用，还得做一层发布。第二版我用的是静态站点生成的方式：脚本读取上面那套 Markdown 文件，自动生成带侧边栏、搜索框、标签系统的静态页面。
用静态站点生成器的好处是文本文件依然是唯一事实来源，生成的网站只是渲染层。不用维护数据库，不用考虑服务器动态运行，push 到托管平台后自动构建，全站就能访问。搜索功能可以通过简单的 JS 索引实现，条目之间的双链通过站点生成器自带的 backlink 功能展示，不需要额外写逻辑。
如果你不想折腾静态站点生成，有一个更简单的过渡方案：直接用 VS Code 打开整个目录，装一个 Markdown 预览增强插件，在预览窗口里点击[[CHAR-HarryPotter]]这种链接也能跳转文件。文本化方案最大的优势就在这里，从个人查看到对外发布之间，不需要动核心数据，换一套壳子就行。
4. 常见问题与排查技巧实录
4.1 资料源冲突：裁决原则是分层分级
整理过程中会频繁遇到不同来源的信息冲突。总结下来，冲突来源主要有三类：原著内部矛盾（作者后补设定导致的）、原著与电影矛盾、电影周边资料与原著矛盾。
处理原则我试验过几轮，最终确认分层裁决的方案最实用。第一优先级是原著文本，以中文版和英文版对照为准；第二优先级是官方剧本与作者后续访谈；第三优先级是电影和官方视觉设定集；第四优先级是粉丝考据圈共识。同一字段如果存在多层冲突，直接采用“平行记录 + 差异说明”的方式，而不是强行合并成一条。
千万避免在字段里写“应该”“可能”“大概是”这种词。一旦加入主观推测，档案的可信度就崩了。个人推测如果实在要记录，放到独立“备注”字段，用括号标注“个人推测”。
4.2 孤岛条目和重复条目的清理
项目中期最容易出现的问题是孤岛条目：文件录入了，但内容里没有任何链接指向其他条目，也没有任何其他条目引用它。这种条目的信息往往只是摘抄，没有贡献到关系网络里。
我每周检查一次孤岛条目，数量连续增多说明录入流程出问题了。一般原因是录入时只求数量、跳过了字段关联。解决办法是给索引文件加“关联数”列，凡是关联数小于 2 的条目单独列一页标记为待完善，不在完整度不足时强行发布。
重复条目也是很常见的坑。同一人物“汤姆·马沃罗·里德尔”和“伏地魔”如果录入的人没有觉察，很容易建成两个条目。我在人物档案的词条命名上统一采用“原始姓名”作为主文件名，把所有别名、外号放到“别名”字段里，同时在条目正文中标注“请使用此条目指代伏地魔的各个时期”。用别名做检索跳转到主条目，而不是用别名建新文件。
4.3 剧透分级与粉丝友好度设计
如果你准备把这个档案库公开分享，需要额外加一层剧透分级控制。魔法世界的剧情魅力有相当一部分来自解谜和反转，很多条目天然带剧透属性，魂器真相、斯内普的身份、邓布利多的计划，这些内容一旦被索引出来就没有回旋余地。
第二版我在分类基础上增加两级阅读权限：一般条目不设防，涉及重大剧情反转的字段标记为“六级剧透”，比如“阿不思·邓布利多请求斯内普杀死自己”就属于这一类。发布时在页面上加折叠组件，新粉访问默认看不到具体细节，考据党可以手动展开。
这种设计并不是作秀，是真实需求。一个以“分享哈利波特世界观”为目的的站点，如果首页直接展示“斯内普是邓布利多安排杀死自己的人”，那对所有想从头探索故事的人都是不友好的。分级控制保证了这个仓库既是考据工具，也不毁掉故事体验。
4.4 最容易翻车的归档操作有哪些
最后说三个我踩过不止一次的坑，都是实际发生过的事故级问题。
第一个是文件名改动后没有更新所有引用。某次我把“HermioneJeanGranger.md”改成“HermioneGranger.md”，全库所有指向旧文件名的链接全部失效，花了半天才用脚本找到所有旧引用。所以现在如果要改文件名，我一定先跑一遍引用扫描再动手。
第二个是录音频或笔记时混入了电影情节但没有做标记。某次整理“韦斯莱魔法把戏坊”相关的条目时引用了电影场景，而原著中相关描述位置完全不同，导致同一句话前后矛盾。现在所有素材摘录严格区分“原著”和“电影”，绝不混记。
第三个是备份策略的问题。本地稿、云盘同步、网页版本之间如果不理清同步方向，偶尔会出现新文件被旧文件覆盖。我目前的做法是：所有编辑只在本机目录进行，云同步只做单向备份，发布流程从本机目录直接构建。绝不把发布目录当编辑目录使用。
这三条坑一旦踩上，代价都很惨痛，而且越到后期数据量越大越难救。前期就把规则立好，比后期花时间修复要划算太多。
在我实际整理这个项目第二版的时候，最明显的感受是：内容整理这个事，最后拼的不是勤快，而是稳定的规则。前几百条录入可能全靠热情驱动，到后半程还能跑得下去，靠的就是那套字段规范、编号系统和自动检查脚本在托底。如果你也想给自己的热爱建一个类似的档案库，我的建议是从一个最小集开始：选一个你最有把握的条目，把字段模板定好，再一点点扩大范围。规则先立住，内容会慢慢长出来。
