素材来源：本文由 Obsidian 仓库中 [[提示词技巧]] 一文深度挖掘扩展而成。
原始素材包含三条线索：GitHub 热榜的自动提示词优化项目、让 AI 少说套话的反问提示词、以及"封神提示词 · 一条指令"（反向追问法）。
标签：#提示词 #PromptEngineering #AI工具 #AI编程 #AI Agent
目录
一、为什么你写的提示词总是"不好用"
原始素材里那三句话——"输入想法自动生成专业级提示词"、"让 AI 少说套话"、"先反问再回答"——看起来是三个零散的窍门，其实是同一个问题的三种解法：
模型不是在回答你的问题，而是在猜测你想要什么。猜得越准，输出越可用。
大多数"提示词不好用"的真实原因，从不是模型不够强，而是下面这四类信息缺失：
缺失类型 | 典型表现 | 补齐方式 |
|---|
目标模糊 | "帮我写个方案"→ 得到一份正确的废话 | 明确"给谁看、要他做什么决策" |
上下文缺失 | 不知道你的行业、读者、已有素材 | 补角色、场景、受众、约束 |
格式缺失 | 要Markdown 表格，拿到的是散文 | 显式声明输出结构与长度 |
失败态缺失 | AI 不确定时就"编一个" | 显式声明"没有就说什么都没有" |
这四类缺失对应到本文的技巧 3、技巧 7、技巧 6、技巧 2。也就是说，那条"封神提示词"的本质不是咒语，而是把 AI 从"生成器"临时改造成"审题器 + 追问器"——先用反问补齐缺失信息，再进入生成。
理解了这一点，提示词就不再是"运气好就灵"的玄学，而是一条有输入、有过程、有输出、有评估的工程链路。
二、教程：七个核心技巧的重构
技巧 1 · 反问式澄清：让 AI 先审题再答题
对应原始素材：「封神提示词 · 一条指令惊艳所有人」——"请你在回答前先向我提问，要求只问一个问题。请根据我的回答继续追问，直到你有 95% 的信心完全理解我的真实需求和目标时，再给出最终方案。"
为什么它有效
这条指令的本质是一次推理链的前置外置。模型默认行为是"收到指令 → 立刻生成"，因为生成是它的训练目标。你显式插入一个"审题阶段"，等于在它生成之前强行插入了一段校验逻辑，把一次性赌注变成多轮收敛。
它同时解决了提示词工程的两个核心难题：
用户不知道自己缺什么——专业用户能提出问题却常给不出约束，反问帮他把隐性需求挖出来。
一次性描述的成本太高——改一轮提示词往往比重述一遍更贵，反问把纠错成本前置。
适用场景
场景 | 推荐强度 | 说明 |
|---|
需求模糊、一次性任务 | ★★★★★ | 最优先使用，收益最大 |
长文/长报告写作 | ★★★★☆ | 可要求先确认大纲再展开 |
代码重构/调试 | ★★★★☆ | 先确认约束（性能、兼容性） |
翻译、格式转换 | ★☆☆☆☆ | 需求已确定，反问是纯浪费 |
批量自动化任务 | ★☆☆☆☆ | 反问会破坏可程序化性 |
操作步骤
前置声明：把"先审题"放在提示词第一句，不要放在末尾。指令位置会影响遵循度。
限定提问节奏：一次只问一个问题 是关键约束，防止 AI 抛出 10 条问卷把你劝退。
给出收敛条件：直到你有 95% 的信心 或 最多问 3 个问题 ——前者是心理锚，后者是硬上限。
声明终止态：理解后再给出最终方案 ——否则 AI 可能问完就走，不给方案。
人工兜底：当时间成本高于质量收益时，用如果信息已足够，直接开始，不必提问 提前退出。
正例
请在回答前先向我提问，要求一次只问一个问题。
请根据我的回答继续追问，直到你有 95% 的信心完全理解我的真实需求和目标时，
再给出最终方案。理解完成后，用一句话复述我的需求，然后开始输出。
需求：我想把这周的门店销售数据做成一份给区域总监看的复盘。
补充规则：
- 如果某一轮你判断信息已经足够，直接进入方案，不要再确认。
- 最多问 3 个问题。
反例
帮我分析一下这周的销售数据。
结果：AI 会输出一份泛泛的"数据复盘方法论"，讲清楚了什么叫复盘，但没复盘你的数据。
常见误区
❌ 把 95% 当成真概率。它只是给模型的一个心理终止符，不是校准过的置信度。别指望它真的量化了什么。
❌ 叠加多层反问。"先问我问题" + "分三步思考" + "逐条自我检查"一起上，往往导致模型在提问环节反复绕圈。
⚠️ 在 Agent / 自动化链路里使用。程序化调用时没有人类回答反问，流程会直接卡死。这类场景应改用静态的上下文模板（见技巧 7）。
技巧 2 · 去套话约束：把"废话开关"关掉
对应原始素材：「让 AI 少说套话的反问提示词」——先分析假设、缺失信息和常见错误，再反问用户。
问题定义
大模型的默认输出是"有帮助的、礼貌的、面面俱到的"。这在聊天场景是优点，在交付场景是成本：开头一段共情铺垫、结尾一段总结升华、中间每个论点都加一句"这非常重要"。你付了token钱，买到的是三成有效信息。
适用场景
报告、代码评审、邮件草稿、数据分析、任何"要直接用的东西"。
操作步骤
点名要删的具体套话，而不是泛泛说"简洁一点"：
"不要用'随着……的发展''众所周知''综上所述''让我们一起'"
"不要在开头写共情句、在结尾写总结段"
给正向目标：直接给出第一句正文，不要任何铺垫（只写否定容易让模型陷入防御式表述）
给可执行的结构要求：第一段直接给结论，之后每条结论后跟 1 句论据
给长度锚点：给字数范围，而不是"简短"。
正例
写一段 200 字的客户跟进邮件。
要求：
- 第一句直接进入正题，不要"希望这封邮件能帮到你"这类开场。
- 不要使用"赋能""抓手""闭环""值得注意的是"。
- 结构：一句结论 + 三个具体论据 + 一个明确的行动请求。
- 不写总结段，不写客套结尾。
反例
简洁地写一段客户跟进邮件。
"简洁"在模型内部没有对应的量化标准，结果通常是一篇缩水版但同样套话的公文。
常见误区
技巧 3 · 结构化框架：RTF / CO-STAR / CRISPE
框架的价值
框架不是形式主义，它解决的是"你会忘记写某一项"这个人类固有的认知漏洞。多数人写提示词凭直觉，直觉里没有"受众"和"语气"。
框架 | 组成 | 适用场景 | 难度 |
|---|
RTF | Role 角色 / Task 任务 / Format 格式 | 日常快问、代码评审、摘要。覆盖约 80% 场景 | ★ |
RACE | Role / Action / Context / Expectation | 有明确交付物的任务，如招聘文案 | ★ |
RICE | Role / Instructions / Context / Examples | 需要模型模仿特定风格 | ★★ |
CRISPE | Capacity / Role / Insight / Statement / Personality / Experiment | 探索性创意、需要多个方案对比 | ★★ |
RISEN | Role / Instructions / Steps / End Goal / Narrowing | 复杂多步任务、需要逐步收敛 | ★★★ |
CO-STAR | Context / Objective / Style / Tone / Audience / Response | 对外传播内容，语气与受众决定成败 | ★★ |
CREATE | Context / Role / Exact Task / Action Format / Tone / Examples | 长文生成、复杂提案 | ★★★ |
APE | Action / Purpose / Expectation | 极简单次请求 | ★ |
官方推荐路径：先学RTF，遇到语气敏感任务加 CO-STAR，需要风格模仿加 Examples。
选型决策表
你要写的东西→ 需要考虑语气/受众吗？
├ 否 → 结果需要多方案对比吗？
│ ├ 否 → RTF（最快）
│ └ 是 → CRISPE
└ 是 → 需要展示"好"的样例吗？
├ 是 → CO-STAR + Examples
└ 否 → CO-STAR
正例（CO-STAR 完整版）
【Context】我们是一家做仓库管理的 B2B SaaS，下个月要面向中小物流公司推广。
【Objective】目标是让运营主管来注册试用，重点是降低决策门槛。
【Style】具体、少形容词、用数字说话。
【Tone】像同行交流，不像销售推销。
【Audience】30-45 岁的物流运营主管，技术背景弱，关心出错率和人力成本。
【Response】一段 120 字的落地页首屏文案，不超过 3 个卖点。
反例
帮我写个仓库管理软件的落地页文案。
常见误区
❌ 框架堆叠。七个框架拼一个提示词，模型会顾此失彼。一个任务一个主框架，最多补两个组件。
❌ 角色扮演当万能药。"你是一位世界级专家"对输出质量的影响远小于你补充了受众和约束。真正有用的是角色附带的判断标准，不是头衔。
⚠️ RTF 里没有约束位。这是 RTF 的已知缺口——它装不下 tone、examples 和 edge case，复杂任务要主动补齐这三项。
中国家谱寻根资源地图 · 开源项目 / 家谱资料 / 迁徙线索
01
中文原生的开源家谱系统
这批项目从 UI 到数据模型都按中文语境设计（字辈、排行、世系、堂号），可以直接部署成家族网站或桌面应用。
pure-genealogy ↗
★ 407
MIT
Next.js 15 + Supabase
2026-01 活跃
目前中文社区最完整、最"能打"的一体化族谱系统，单 Supabase 实例即可跑起来，适配 Web 与 H5。
- 数据模型：单表 family_members 自引用（father_id）建世系；字辈走姓名第二字统计；residence_place 记录居住地迁移；remarks 存 Slate.js 富文本生平
- 2D 族谱图：Dagre 层级树 + 水墨"世代标尺" + 金线溯源（高亮祖先路径）/ 金扇繁衍（高亮子孙路径）
- 3D 力导向关系图，支持自动巡游（自动规划两人最短关系路径并飞行浏览）
- 统计仪表盘（性别/在世比例/世代增长/字辈频率）、家族时间轴、Living Book 拟物翻书详情页
- 导入导出：Excel / CSV；族谱图可导出高清 PNG
⚠ 不支持 GEDCOM —— 与其他软件交换数据要靠 Excel 中转。适合想立刻上线一个好看家族网站的团队。
Branchloom · 有谱 ↗
Apache-2.0
桌面端 Electron/TS
支持 GEDCOM
2026-09 活跃
"本地优先"路线的代表：数据存在你自己手里，不依赖任何会倒闭的网站。想做的是家谱界的 Obsidian。
- 数据模型最接近学术规范：人物 / 关系 / 事件 / 地点 / 史料来源 / 引文 / 附件
- GEDCOM 导入导出全支持，另提供完整项目包 .blp
- 可用自己的 GitHub 私有仓库做备份并与家人异步协作 —— 同步前先预览，字段冲突必须手动确认
- 带 CLI 与 AI Agent Skill，可辅助批量整理；但写入前强制"先预览再确认"，避免 AI 改坏族谱
- 跨平台：macOS / Windows / Linux
✔ 如果你在意"数据永流传、不被平台绑架"，这是首选。缺点：社区很小（★6），生态早期。
LyGenealogy · 屈氏宗谱 ↗
Apache-2.0
Nuxt3 + Vue3 + Express
pnpm Monorepo
一个真实姓氏（屈氏）落地过的族谱数字化平台，工程结构规范，适合宗亲会/姓氏研究会自建。
- 三层结构：Express + TS 的 REST API ／ Nuxt 3 公共前端（SSR/SSG/ISR、PWA、H5 适配）／ Vue3 + Element Plus 管理后台
- 功能：族谱库列表与详情（谱籍、字辈摘要）、字辈查询、成员搜索、亲缘关系递归展示、世系树
- 姓氏文化、百科、新闻等内容模块统一管理，支持多姓氏扩展
- SQLite 持久化，支持多族谱、多地区
✔ 适合"一个姓、一批人、长期维护"的场景，前端 SSR 对搜索引擎友好，方便对外展示。
mumuy/relationship ↗
★ 3734
MIT
JavaScript
2026-09 活跃
中国亲戚关系计算器。它不是家谱管理工具，而是称谓/辈分引擎——恰好是家谱系统最难写的那块。
- 核心算法三段式：中文称谓 → 内部关系链（f=父, m=母, s=子, d=女, &o/&l 表长幼）→ 反向生成称谓
- 能力：称谓计算、辈分计算、关系链还原、两人关系合称（如"儿女亲家"）
- 区域模式：默认普通话 / 北方 / 粤语，且支持 setMode 注册自定义地区称谓
- 支持"二舅"这类排行修饰词、同义词扩展与口语化输入（"吾之""家的"）
✔ 强烈建议作为依赖嵌入你的家谱系统：把谱系数据直接翻译成"该叫表叔还是堂伯"，并可用于辈分逻辑校验。
guyue55/FamilyTree ↗
MIT
Django 5 + Vue
支持 GEDCOM
功能设定偏"企业级"的族谱系统：权限、协作、全文检索、多语言一应俱全。
- 后端 Django 5 / Python 3.12 + DRF + JWT/OAuth2；PostgreSQL、Redis、Celery、Elasticsearch
- 核心：多族谱管理、成员 CRUD、复杂关系网络、交互式族谱图、多媒体资料上传
- 高级：基于角色的权限控制、多用户协作编辑、GEDCOM 导入导出、全文搜索、统计分析
- WebSocket 实时同步 + 响应式设计 + 国际化
✔ 技术栈重但齐全，适合有 Python 运维能力、想要"多家族/多租户"的机构。注意：★0，作者近期才起步。
qiaoshouqing/familytree ↗
★ 557
MIT
TypeScript
极简开源家族树网站。轻、干净、易改，是"自己动手改一个"的性价比之选。
✔ 想要简单可控、愿意自己改代码的前端同学优先看这个。
选型速判
要「立刻能用的中文家族网站」→ pure-genealogy；要「数据永流传 + GEDCOM + 家人协作」→ Branchloom；要「宗亲会/姓氏研究会」→ LyGenealogy；只要「称谓辈分算法」→ mumuy/relationship 直接引依赖。
02
GEDCOM 成熟生态（中文可用）
国际家谱领域有二十多年的工程积累，数据模型和交换标准（GEDCOM）远比国内项目成熟。它们都有完善的中文界面，是"认真修谱"的稳妥底座。
Gramps ↗
★ 3123GPL-2.0
PythonGEDCOM 5.5
开源家谱软件的事实标准，数据模型设计最严谨，插件生态最丰富。
- 完整数据模型：Person / Family / Event / Place / Repository / Citation / Source / Media / Note，并细分 Name、Surname、ChildRef、EventRef 等
- GEDCOM 5.5 导入导出广泛支持（多字节 UTF-8 编码可正确处理）；建议用 .gramps 原生格式备份避免信息丢失
- 内部统一 Unicode/UTF-8，提供简体中文界面，所有报告支持 Unicode 字体
- 插件体系：Views / Reports / Tools / ImportExport / Gramplets，启动时注册，无需改动核心代码
✔ 学术级规范 + 可扩展。做过"史料来源—引文—结论"三层溯源，这正是修谱最需要的可信度结构。
webtrees ↗
★ 824GPL-3.0
PHPGEDCOM 5.5.1
自托管的在线协作家谱系统，多人同时修谱体验成熟。
- 数据模型完全围绕 GEDCOM 5.5.1：Trees → Records(INDI/FAM/SOUR) → Facts(事件/属性) → Places → Dates
- 对东亚姓名友好：支持 ROMN（罗马化姓名变体）与 FONE（拼音变体）标签，可同时保存汉字名与拼音
- 多语言界面（I18N::translate），权限/隐私分级、媒体文件管理
✔ 想要"多人一起在线修谱"且不介意自己架 PHP 服务，这是最省事的选择。
GEDKeeper ↗
★ 214GPL-3.0
C# / .NET含简体中文
老牌跨平台个人家谱库软件，Windows 用户体验最接近国产桌面软件习惯。
- 完整 GEDCOM 5.5.1 支持，人数与代数无限制
- 家族树打印/导出为图片、PDF、Excel、RTF、HTML
- 动态地图（Google Maps）呈现地理数据 —— 对看祖籍分布很有用
- 亲属关系度计算器、统计、幻灯片、Lua 脚本与插件
✔ 不想碰命令行、只用 Windows 桌面的话，体验最"顺手"。
为什么绕不开 GEDCOM
GEDCOM 是家谱数据的交换标准（当前版本 5.5.1 与 GEDCOM 7）。国内多数项目（含 pure-genealogy）不支持它，意味着数据进去就出不来。若你打算长期维护几代人的资料，优先选支持 GEDCOM 进口出口的工具，把数据主权留在自己手上。上图家谱平台则另建了一套更细粒度的「家谱本体」（文献/姓/人/地/时/事），见下一节。
03
家谱资料与开放数据源
这一节是"资料本身"。按权威度和可编程程度排序，第一条是唯一能直接写进代码的官方家谱数据入口。
中国家谱知识服务平台（上海图书馆）↗
权威可编程
10万+ 种630 家馆藏机构
全国最大的家谱联合目录与知识服务平台，2016 年上线，年浏览量 100 万+ 人次，也是国内数字人文的标杆案例。
- 收录 10 万余种家谱，其中上图馆藏 3.7 万余种、7 千余种对外网开放全文查阅
- 服务内容：家谱元数据、全文影像、先祖名人介绍、谱系图、家规家训
- 多维探索：人 / 地 / 时 / 事 分面检索、数据可视化、地理空间服务
- 众包功能：上传家谱、在线识谱、在线修谱，可直接捐献影像
- 实体展陈（上图东馆）：「君从何处来」家谱迁徙图、「探姓觅谱」AR 姓氏墙（前 300 大姓）、「生生不息」3D 家谱树（胡适/李鸿章/盛宣怀）、「华夏一家」谱籍分布图
✔ 寻根第一站。先在这里搜你的姓 + 祖籍地，看有没有可查的家谱。
上海图书馆开放数据平台 ↗
API关联数据
SPARQL需 APIKey
把上面那个平台的底层数据以面向机器的方式开放出来，是整个中文家谱生态里最值得开发者深挖的一块。
- 三种取数方式：① 资源 URI 取 RDF（JSON-LD 三元组）② 类型查询接口（姓氏 / 先祖名人 / 地点 / 机构 / 朝代 / 书目，每次最多 20 条）③ SPARQL Endpoint（复杂查询）
- 规范控制基础库：人名规范库、历史纪年表、地理名词表、华人姓氏列表、收藏机构名录
- 家谱本体定义 文献 / 姓 / 人 / 地 / 时 / 事 六类概念及关联，字段尽量复用已有规范词表（便于与其他数据整合）
- 需注册取 APIKey：
data.library.sh.cn/jp/userlogin/tologin
- 另在 OpenKG 上有镜像条目「华人家谱关联数据集」，含家谱本体与接口说明文档下载
✔ 想做"输入姓氏+祖籍地，自动列出相关家谱与先祖名人"这类应用，就用这个接口。
CBDB 中国历代人物传记资料库 ↗
★ 230哈佛/北大/中研院
SQLiteCC BY-NC-SA
唐至清（7–19 世纪）中国历史人物关系型数据库，截至 2026 年 5 月已收录 65.7 万+ 人。GitHub 仓库持续更新最新 SQLite 版本。
- 核心表：Person（姓名/拼音/性别/朝代/生卒年/籍贯）· Kinship（亲属关系及代码表）· Office posting（职官任免）· Association（社会关系）· Address（各类型地址：出生地/居住地/祖籍…）
- 另有大量 code table：亲属关系码、入仕途径码、机构码、地名码等，支持网络分析与 GIS 空间分析
- 多种形态：可下载单机库（Access/SQLite）、在线查询、API、CBDB Linked Open Data；配套 MARKUS 文本标注与 CHGIS 历史地理系统
- 数据来源：正史、科举题名录、职官表、地方志、墓志铭、文集等
⚠ 偏"精英人物"（官员、科举、名士），不是平民家谱。但如果你家明清出过读书人/官员，这里是查证祖先生平最硬的证据库。
Genealogy-MBW · 华谱网数据集 ↗
1869万节点图数据模型
已脱敏
面向家谱文化与图数据研究的开放数据集，截至 2026 年 5 月累计 1869 万人物节点 + 2380 份家谱。
- 统一图模型：节点 = 家谱人物，边 = 亲属关系，节点属性存人物描述
- 知识密度高：含人物世系、代际演化、迁徙关联、血缘关系、过继关系、隔代后代
- 处理链路完整：多源异构采集 → OCR 与版式理解 → 人物关系抽取与消歧 → 谱系结构建模 → 图数据库设计 → 清洗校核 → 一致性校验 → 隐私脱敏
- 涉及领域规则：血亲 vs 过继区分、同名异人/异名同人判定、缺失世系链接还原、历史地名变迁识别
✔ 想做族谱知识图谱 / 迁徙网络可视化，这是目前最"现成"的高质量中文族谱图数据。
CGED / CUSD（港大李-坎贝尔团队）↗
清代民国约200万人CSV/Excel
与 CBDB 协作的两个"大社科数据"项目，是目前唯一整建制研究中国官僚体系的微观数据库。
- CGED：1700–1950 年文官与专业生涯，含约 200 万人、337 万条军政职位记录，附个人家族与地理来源信息
- CUSD：1890–2010 年含中国香港在内的中国大学生社会来源
- 特别适合"查某位先祖的人事档案"；提供 CSV/Excel 下载与中文使用指南
✔ 祖上若在清代做过官或有功名，这条路比家谱更可能直接查到名字。
其他可用数据源一览
| 数据源 | 规模 / 内容 | 形态与许可 | 怎么用 |
|---|
中国家谱总目数据集
OpenDataLab / Chinese-Genealogy |
52401 条家谱条目，608 个姓氏，1200 万字（上海图书馆牵头编纂） |
文本，81.3MB，CC BY-NC 4.0 |
做姓氏分布/谱籍地统计、训练家谱领域模型 |
ChineseNames
R 包 · psychbruce |
1806 个姓氏 + 2614 个取名用字，1930–2008 全国频次（覆盖约 12 亿汉族人口）
★188 · GPL-3.0 |
R 包 / 数据集 |
校验字辈用字、判断名字时代特征与地域分布 |
老家河南家谱馆 · 中华家谱数据库
jiapudata.com |
民间藏谱汇编，持续建设中；有各地宗亲会合作 |
网站检索 |
查河南地区姓氏族谱，联系宗亲会 |
FamilySearch
familysearch.org |
全球最大免费线上族谱服务，含中文馆藏与检索 |
网站 / 开放 API |
查海外华人支系、下南洋后裔 |
| 新加坡华人传记数据库 |
1819–2019 八代新加坡华人人物，含关系网络与祖籍地 |
CSV / Excel 可下载 |
查下南洋家族在东南亚的支系 |
姓氏源流类 API
天行数据 / apihz 百家姓 |
姓氏历史来源、得姓始祖、郡望堂号、迁徙分布、姓氏图腾 |
JSON API（有免费额度） |
做产品时补"姓氏介绍"页，省得自己编 |
04
祖先故事与迁徙线索
家谱里找不到答案时，靠的是"迁徙史 + 地名暗号"。下面这张时间轴可以直接当成检索关键词清单用。
核心方法：上图「君从何处来」迁徙图是怎么做的
上海图书馆把平台里 7 万多种家谱，用机器学习基于事件本体做数据提取，专门抽取始祖和始迁祖的迁徙事件，转成语义化关联数据，再通过可视化与交互设计，做成一张可按朝代查看迁徙趋势的航线图；并对数据密集的几波移民潮做重点展演。这套"从家谱原文抽迁徙事件 → 语义化 → 可视化"的思路，你自己修谱时完全可以照搬：把每位祖先的始迁时间 + 迁出地 + 迁入地结构化下来，就能画出自家一支的迁徙线。
307 – 453 年
永嘉南迁
八王之乱 + 五胡乱华，中原士族与富户大规模渡江南下，约 90 万人，占刘宋人口六分之一。今南京—镇江一带北方侨民甚至多于原住民。
路线：东线循邗沟与淮河东南向／西线循汉水南下，汉中与襄阳为集散地；关陇流民入汉水与川北
755 – 9 世纪
安史之乱后南迁
河南、河北、陕西居民南下江淮、西入四川，历时一个半世纪，完成中国经济文化中心南移。荆州至常德一带户口因移民增加十倍。
路线：东路走大运河入淮南江南再入赣闽；中路出南阳襄阳沿汉水入岭南；西路越秦岭入汉中与四川盆地
1126 年 – 13 世纪
靖康之乱南迁（最大一次）
金兵南下、高宗南渡，累计南下移民约 500 万。最密集区是从苏州到宁波一带，杭州城内高度集中。今天世界性的「客家人」族群正是这次移民形成的。
路线：与唐后期相同，七个较大阶段；南宋内部另有江西→淮南、福建→潮梅、江西→湖南等支线
1371 – 1417 年
明初洪洞大槐树移民（规模最大）
明朝在洪洞大槐树下设局驻员 50 年，大规模迁民 18 次、约百万人，遍布京冀豫鲁苏鄂等 18 省。洪武年间全国移民总数达 1340 万，占人口 19%。
路向：山西南部 → 河南（93 万）／山东（121 万）／河北（41 万）；同期还有江西→湖广、湖广→四川
元末 – 清代
江西填湖广 · 湖广填四川
晚清魏源记："江西人入楚，楚人入蜀，故当时有江西填湖广、湖广填四川之谣。"麻城曾收集 142 套族谱，其中 125 支可溯自江西。
路向：江西饶州等地 → 以鄱阳瓦屑坝中转 → 鄂皖湘；湖广黄州府 → 四川（川北多陕西、川东多湖广、川西多广东）
清中期 – 民国
走西口 · 闯关东 · 下南洋
自发性经济移民。闯关东：1912–1945 年关内流向关外约 991 万人；下南洋：到 1905 年海外华侨总数已达 700 万，闽粤人占 95% 以上。
路向：晋陕 → 内蒙归化与河套（走西口）／冀鲁豫 → 东北，多由古北口、张家口、喜峰口出关／闽粤 → 东南亚与台湾
持续千年 · 五次大迁徙
客家民系形成与迁川
客家人祖先本居黄河流域，因战乱南迁至闽粤赣边区。清初康雍乾三朝（约 1680–1800）第五次大迁徙中大批入川，仅仪陇一县客家人曾占总人口 33%，至今约 11.8 万。
迁川路线：粤北 → 湖南汝城/桂东/茶陵/醴陵/浏阳/平江 → 长江；或 粤北 → 宜章/郴州/祁阳/邵阳/常德 → 长江；两路经鄂西溯江入川
地名"暗号"：家谱里写到这些地方，就等于给了你迁徙线索
民间广泛流传"北有山西洪洞大槐树，南有江西鄱阳瓦屑坝"。这些地名多数不是真实最后的祖籍，而是移民集散地/中转站，是身份认同符号 —— 看到它们就说明你的祖先属于某一次特定移民潮。
山西洪洞大槐树 · 老鹳窝明初官方移民集散地 → 豫冀鲁皖苏。民谣："问我祖先来何处，山西洪洞大槐树"
江西鄱阳瓦屑坝鄱阳湖边古渡口，洪武大移民主要中转站 → 鄂皖湘，湖北江汉平原三分之二来自南昌府一带
湖北麻城孝感乡四川移民后裔最普遍的祖籍认同。麻城四乡之一，嘉靖年间析入黄安（今红安）
苏州阊门苏北扬州、淮安一带移民普遍自称来自苏州阊门，实为集散地符号
南京杨柳巷云贵驻留军士后裔多自称祖籍南京杨柳巷，对应明初军籍移民
山东枣林庄与洪洞大槐树、瓦屑坝、麻城孝感乡齐名的"移民发源地"符号
把线索变成证据的三步
① 先从家谱/口传里抠出"始迁祖名 + 迁出地 + 迁入地 + 大致年代"四要素；② 用上表时间轴判断它属于哪一次移民潮，再去该移民潮的集散地（大槐树/瓦屑坝/孝感乡…）方向上找对应姓氏族谱；③ 到 jiapu.library.sh.cn 按「姓氏 + 谱籍地」检索上图及 630 家机构馆藏，并在 data.library.sh.cn 用 API 拉规范化的地名与人名做交叉验证（历史地名变迁务必用它的地理名词表校准）。
05
老谱数字化链路（把纸变成数据）
纸质族谱是竖排繁体、生僻字多、版面复杂，通用 OCR 基本没法用。这条链路是目前可落地的最优解。
PaddleOCR / PP-StructureV3 ↗
Apache-2.0百度飞桨
繁体竖排2025-05 v3.0
古籍 OCR 的首选底座。PP-OCRv5 单模型即同时支持简体中文、繁体中文、中文拼音、英文、日文，覆盖手写体、竖排文本、生僻字。
- 古籍场景实测：文本检测精度 +43%，生僻字识别精度 +95%，微调后字符准确率 94%+
- PP-StructureV3 版面分析：区分标题/正文/表格/图片/公式区域并判断阅读顺序 —— 这正是竖排古籍"从右到左"不乱序的关键
- CPU 也可跑（默认启用 MKL-DNN，Intel CPU 提速约 2.3 倍），也支持昆仑芯、昇腾等国产硬件
- 输出 Markdown / JSON / DOCX / XML，可直接进后续结构化流程
✔ 关键参数：lang=chinese_cht（繁体）、降低 det_db_thresh 到 0.3 以适应墨色浅的老谱。
Chinese-Ancient-OCR ↗
PaddleOCR 封装竖排自动排序
基于 PaddleOCR 的古籍识别工具，把"竖排排序"这个最烦的坑直接填了，开箱即用。
- 智能文字排序：自动识别竖排古籍并按"从右到左、从上到下"正确排序
- 单图识别 + PDF 批量处理（自动分页渲染、逐页识别、生成独立与合并文本）
- 可自定义 DPI 提升精度；输出 TXT / JSON / 可视化标注图片
✔ 只想把一本电子化族谱快速转成文字，用这个比从零搭 PaddleOCR 省事得多。
推荐处理流程（七步）
STEP 1扫描 ≥300 dpi300 是精度与体积的平衡点，低于 300 会明显掉识别率。保存级图像 + 元数据一并留存。
STEP 2抽样试识别先识别几页，摸清版面类型（双行小注/批注/套印）与主要错误类型，再决定参数。
STEP 3图像预处理OpenCV：灰度化 → 高斯去噪 → 投影分析纠偏 → 高斯自适应二值化（对老化泛黄、光照不均更稳）。
STEP 4版面分析PP-Structure：切分标题/正文/表格/图片区域并确定阅读顺序，避免竖排错行。
STEP 5文字识别PP-OCRv5 繁体模型；保存文字 + 坐标 + 置信度，低置信度的地方留给人工。
STEP 6后处理纠错形近字表纠错（己/已、曰/日、未/末、戌/戍…），但人名务必人工复核，不要被自动纠错改错。
STEP 7双层 PDF 归档图像层 + 透明文字层，既可保真又可全文检索；版本化发布，保留原文影像与修订记录。
必须提醒的一句
OCR 输出永远是「可校对的初稿」，不是成品。字符准确率高不代表人名、日期、地名、官职正确 —— 而这四类字段恰好是家谱的全部价值所在。务必按"字符 / 字段 / 版面"三层验收，风险字段 100% 人工过一遍。
06
落地路径建议
按你的真实目的直接对号入座。
| 你的目的 | 推荐组合 | 为什么 |
|---|
| 想快速有个好看的家族网站 |
pure-genealogy（★407, MIT） |
一个 Supabase 即跑，中文体验最完整，2D/3D 谱图与 Living Book 直接可用。缺点：无 GEDCOM，数据需靠 Excel 出。 |
| 想数据几十年不丢 + 家人一起改 |
Branchloom（有谱）+ 私有 GitHub 仓库 |
本地优先、Apache-2.0、GEDCOM 全支持、冲突手动确认、AI 写入前强制预览 —— 数据主权完全在你手上。 |
| 宗亲会 / 姓氏研究会自建 |
LyGenealogy（屈氏宗谱）架构即用 |
Monorepo 工程规范、支持多姓氏扩展、前端 SSR 便于对外展示、含字辈查询与亲缘递归。 |
| 认真修谱，要学术级规范 |
Gramps（本地主编）+ webtrees（在线协作） |
数据模型含 Source/Citation/Repository 三层溯源；GEDCOM 互通，不会被任何单一软件锁死。 |
| 查祖上到底是谁 |
jiapu.library.sh.cn 检索 → CBDB / CGED 查名人 → 老家河南家谱馆找民间藏谱 |
先用 10 万+ 种联合目录定位家谱，再用数据库交叉验证人物生卒、职官、籍贯。 |
| 做迁徙/族谱可视化产品 |
上图开放数据 API + 上图迁徙图方法论 + Genealogy-MBW 图模型 |
数据层用官方 RDF/SPARQL，结构层仿"始祖→始迁祖→迁入地"事件本体，展示层参考航线图与谱籍分布图。 |
| 把纸质老谱数字化 |
PaddleOCR PP-StructureV3 ＋ Chinese-Ancient-OCR |
唯一能同时处理竖排、繁体、生僻字与复杂版面的可用开源方案。 |
| 要把谱系翻译成"该怎么称呼" |
mumuy/relationship（★3734）当依赖嵌入 |
称谓/辈分/关系链算法直接可用，含北方与粤语模式，还能注册自家地区的叫法。 |
最后一条建议
家谱这件事，工具会过期，数据不能。无论你最终用哪个系统，都请做到三件事：① 保留一份 GEDCOM 或纯文本导出；② 原始家谱影像单独存档、不要只留 OCR 文本；③ 每条祖先信息标注来源出处（哪本谱、第几页、谁口述）。做到这三点，数据就能跨过任何一次软件换代，真正"永流传"。
此处内容已隐藏，「密码可见」
