有一家人，家族树里写着某人“死于瑞士”。
后人照着这条线索去翻瑞士的死亡登记。翻不到。翻了很多年，还是翻不到。真相是他死在法国境内，一场狩猎事故，出事地点离边境线很近，近到当地一家瑞士报纸把它当本地新闻报了。于是有人读成了“死于瑞士”，写进树里。
这条错的地点，到现在还在别人的树里活着。
家谱数据最反直觉的地方就在这儿：它的错误不可撤销。你手上那份能改，别人从你这里抄走的那份，你改不了。而家谱这门活儿天然就是要抄的。网上家谱站那么多，每家都有免费档，你只要在某个已有成果的人那里找到一个共同祖先，就能把他上游几百人直接接过来。这不是偷懒，这是这个领域默认的工作方式。
复制是默认动作，撤销不是。
（你可能会问，那加个“最后更新”字段不就行了？不行。字段能跟着数据被抄走，“我后来改过”这件事不会自动追到别人的副本里。你改的是你的树，不是概念上的那棵树。）
这里最容易被搞混的是“家族树”这个词。我们脑子里想的是树状图，落到文件层面，它根本不是一棵树，是一堆断言。每条断言长这样：某人于某地某时做了某事。后面再挂一条“这断言从哪来”。GEDCOM 就是这么设计的。这个格式 1984 年就有了，最后一次大更新停在 1996 年，2019 年补了个 5.5.1，2021 年有人把它重启成 7.0，但兼容的工具很少，所以实际在用的还是那个 1996 年的老规范。
老规范里有两个字段，一个叫 SOUR，一个叫 QUAY。SOUR 记这条断言从哪个来源来，QUAY 记这条断言有多可信。
这两个最好拆开看。有来源和有质量是两回事。网上大多数个人页面都带来源链接，但你把那链接点开，指向的是另一个用户的树。这是循环引用，不是证据。
QUAY 的取值里最高一级，通常是留给官方行政记录或宗教记录的。有人做家谱就是靠这个字段管理自己的文件：只有拿到原始记录才标最高级，其余一律按假设对待。说人话就是——没有实证支撑的推断，必须在文件里长得就像推断。
插一句，QUAY 不是为这个用法设计的。它是 GEDCOM 原生的一个质量标注字段，拿它当“假设标签”用是借用，不是规范要求。但这个借用很聪明，因为它让不确定性变成了数据的一部分，能跟着文件一起版本控制、一起被校验。
也可以这么说：QUAY 不是给数据打的诚实分，是留给未来自己的一张警告条。三年后你打开这个文件，看见一家三口里两个人标着最高级、一个人空白，你就知道那第三个人当初是怎么来的。
这个类比到这儿就差不多了。再往前推会有个坑——QUAY 只能标“这条断言整体有多可信”，标不了“这条断言里哪一部分是猜的”。地点是猜的、日期是确证的呢？一个字段装不下。老规范里没有更好的表达方式，实际做法是把这种细节写进 NOTE，但 NOTE 写多了文件会迅速膨胀。有人干脆用文件外的检索笔记索引加任务单来记缺失的出处。这是工具撑不住的地方，不是方法错。
机制铺完了，说 AI 在这个循环里的位置。
有人把家谱当软件工程项目管：git 做版本控制，一个平台托管开发中的仓库，另一个只放镜像。工作流是循环的——挑一个父母信息未知的人，让助手去检索家谱站和当地民事档案，找到记录就转录、写进 GEDCOM、跟他的子女建关联、登记来源、提交，然后换下一个人，直到找不到为止。
这个循环里，模型做得好和做得差的部分分得很清。
做得好的是转录。扫描件图片到纯文本，这是模式识别，是模型的强项。有实际用过的人说 Claude Code 在这件事上表现不错，而且默认比较谨慎。注意“谨慎”这个词，它不是模型的美德，是它在不确定的时候倾向于不乱补。
做得差的是认人。一个小村子里好几个同名的人，你要找的那个是哪一个？模型不是从档案里“挑出”正确的那个，它是根据上下文生成一个概率最高的补全。这两件事在输出上长得一模一样，你看不出来这一条是查到的还是猜的。
这里最容易被搞混的是：很多人以为模型在检索事实。它其实一直在生成“最可能的事实形态”。转录错了会被下游的结构校验抓住，认错了人，文件完全合法，校验器一声不吭。
而且认人这件事，越往深处追溯越难，难的方式还不止一种。
第一层是同名。小型村落里同姓扎堆，常见的做法是给名字加区分标识，有的地方这个标识会写进民事记录，有的地方不写。不写的那种能把人逼疯。有些地区干脆在同一辈人里加上第二个姓氏来区分，那是当地约定，不是通用规则。
第二层是正字法还没固定。同一条记录里，写记录的司铎可能用两种拼法写同一个姓。你今天看觉得是笔误，人家当年不觉得。
第三层是记录改用拉丁文。一个普通的法国名字 Pierre，在拉丁文档案里写成 Petrus，还带变格，同一个名字在不同格位下形态不同。
再往前，有些支系根本没有姓氏，只能记为“某地的某某”。这三层叠起来，模型要在这里“认人”，成功率是往下掉的。原因也不神秘——训练语料里这些形态的样本密度本来就低，越古老、越地方化、越不规范，它见过的就越少。
上面说的是把猜测当成了事实。还有一种错误方向相反，同样普遍：把“没查到”当成了否定。
法国的民事记录在事件发生 75 年后才对公众开放。在此之前，申请人必须证明自己是当事人或直系后代。所以像戴高乐这样公众人物的出生证明可以公开查阅，可以用来追他的祖先，而你自己祖辈 1955 年的那份，你今天还看不到。
这意味着，一条记录找不到，至少有四种互不重叠的解释：记录本身没留存下来、还在封存期、相关馆藏根本没人去检索过、或者这个人确实不在这里。
四种情况在输出上都长一样，都是一个空白。助手最容易被这种空白带偏，因为它倾向于把“没找到”读成“此路不通”，然后拐去查别的支系。问题是它拐走之前不会停下来想想这次空白属于哪一种。更麻烦的是，它拐走之后的每一步，都是搭在前一个空洞上的。
顺带一提，这个领域的人际网络意外地好。有人发出去的询问基本都有人回，最顺利的一次还因此认识了一位写过相关专著的史学家。这事跟机制没关系，但确实是真的。打住，拉回来。
所以真正让这套流程跑得起来的东西，不是模型能力，是那些不起眼的护栏。
第一个是提交前的结构校验。本地挂个 pre-commit 钩子，或者用托管平台上的远程任务，每次提交都跑一遍 GEDCOM 格式检查。为什么必要？因为模型逐 token 生成，没有任何一步在确认“整个文件到现在为止还是合法的”。合法性是生成完之后才知道的事。文件小的时候它蒙对的概率很高，文件涨到几百人、几千行，它开始漂，前面几层的一致性早就顾不上了。
而且这件事有个时间窗口。隔三次提交发现结构坏了，回滚一下就好。隔三十次才发现，中间那些新数据全得重新落盘，基本等于重做。文件越大越容易被写坏，这是同一条规律的两面。
第二个是技能。这个概念值得单独拆一层：技能是包含指令、脚本、资源和参考材料的可复用集合，它最大的好处是默认不占上下文——只有它的描述跟当前提示匹配的时候才会被加载进来。
为什么要这么设计？因为系统提示每一轮都在烧 token，是固定成本。你要是把“怎么转录档案图片”“怎么在这个网站里导航”“怎么跑长时间会话”这些操作规范全塞进系统提示，它们每一轮都在计费。换成技能就是把它们挪到外面，用得着才读进来，用不着零成本。比如一个“把记录图片转录为纯文本”的技能，描述里写清楚什么时候该用它，剩下的内容就一直躺在磁盘上不烧配额。这套机制的叫法业内不统一，有人叫渐进式披露，实质一样。
第三个是子代理。一个研究任务跑下来要读一堆网页、产生一堆中间输出，这些东西如果全留在主代理的上下文里，等你想干正事的时候，桌面上已经堆满了。子代理的做法是让一个分身去把脏活干完，只把结论交回来。有人总结出来的结构是：子代理在各自的 worktree 分支上提交，主代理负责检查和合并。串行跑，不并行。
串行这条值得说一句。并行的收益是墙钟时间，代价是两个子代理改同一份文件之后的合并。合并这件事本身要消耗上下文，而且合并逻辑不在校验范围内，出了问题很难定位。串行慢，但每一步的状态是能解释的。
顺带说一句模型选择，这条很浅但有用：配额是有限的，用最强的模型干“把这行数据填进模板”这种活，和用弱模型干“连续检索十几步再判断一个家族关系”这种活，都不划算。后者的失败方式不是慢，是给出一个错的结论还煞有介事。
有人一个月推进到的深度，有些人要花好几年。这话听着像在夸工具，其实不全是。
工具提速的是获取那一段——检索、转录、写入、提交，这一段确实快了几十倍。但这段从来不是家谱研究的瓶颈，瓶颈一直是确认，是这条断言到底有没有证据。而这套流程真正的价值，是它逼着人把证据也当成数据来管：每条断言有来源字段、有质量等级、有提交记录、有校验钩子。
这些动作没有一个需要 AI 参与。但一个只用 AI 查资料、不用 AI 管数据的流程，跑得越快，错的也传得越快。前面那条“死于瑞士”就是这么来的，只不过传它的是人手。
再往下就是同名消歧到底能不能自动化了。这牵扯到模型能不能表达“我不确定”这件事，这个坑先留着，改天单独填。