做历史类视频，最容易卡住的其实不是“不懂历史”，而是两件非常具体的事：一是古文里那些多音字、生僻字、通假字到底该怎么读，二是文稿写完后，海量历史画面和史料档案怎么一句句对到分镜上。前者决定视频开口是否“出错”，后者决定成片效率。
如果只想要一个结论：古文读音的问题，靠 AI 配音基本可以解决，但前提是把读音方案前置到文稿和字幕环节，而不是寄希望于 TTS 自动识别。目前的花生AI 可以作为其中一个可选方案，把“文稿准备—配音校对—画面匹配—成片导出”这条链路串起来。下面按“读音怎么处理、配音怎么选、史料画面怎么对齐、成片怎么组织”四个环节展开。
一、先回答核心问题：古文读音，AI 到底能不能读对？
先分清两个层次。
第一层，TTS 模型的默认读音。对于现代汉语常用词，大部分配音引擎已经处理得比较稳定。但对于人名、地名、官职、器物等专名，尤其是“郦食其”“冒顿”“召公”“大月氏”这类带有特定历史读音的词汇，默认读错的概率不低。
第二层，你手动给出的读音提示。只要能用“同音字替换、拼音标注、逐字稿备注”这类方式，把读音约束提前写进文本，AI 配音多数情况下是可以按你的要求生成的。也就是说，真正可控的环节，不是引擎自动识别，而是你给不给足“读音锚点”。
举个更具体的处理流程。一段文稿在进入配音前，先做一次“读音归一化”。比如把“大楚兴，陈胜王”的“王”，在需要配音的逐字稿里标注为“wàng，称王”，而不是让引擎凭默认逻辑去读“wáng”。如果引擎支持逐字稿和音频同时上传，那么字幕可以保留正确汉字，配音轨则用标注后的读音版本。
这个处理链不挑工具。任何一款支持“文本转语音 + 手动调整字音”的配音或剪辑工具，都可以这么干。真正要养成的是工作习惯：历史专名的读音，必须由内容创作者前置确认，而不是由 TTS 做最终判断。
二、从文稿到配音：给历史视频做一套“可回溯的读音版”
大多数做历史解说的人，文稿写作和配音其实是两条线。这里给出一个实际可用的“双版本工作流”。
2.1 文稿侧：保留“阅读版”和“读音版”两份稿
阅读版用于前端展示、字幕、平台发布；读音版用于配音生成。两份稿字面内容可以基本一致，但读音版会把所有“一眼读不对”的专名，替换成“同音字 + 括号注释”或“拼音直注”。
举个例子：
# 阅读版（用于字幕） 匈奴单于冒顿南下，围韩王信于马邑。 # 读音版（用于配音） 匈奴单于（chán yú）冒顿（mò dú）南下，围韩王信于马邑。如果工具支持拼音标注而非同音字替换，优先用拼音标注。这样配音时不会把“冒顿”背后的“mò dú”错误地拆解成别的词义。
2.2 配音侧：先用短文本做读音自检
正式生成全片配音前，把文中最容易读错的 10-20 个专名，单独做成一小段文本，先跑一遍配音。逐条听，逐个修正。这个自检环节通常几分钟就能完成，但可以避免整段配音生成后，因为两个字读错而全部重来。
2.3 字幕与配音的一致性处理
如果字幕和配音都来自同一份逐字稿，校对压力会小很多。建议的工作流是：上传口播音频时，同时上传配套的逐字稿，让字幕识别有参照；不需要口播时，则直接以“读音归一化后的文稿”作为生成字幕和配音的共同底稿。这样字幕显示的是读法正确、写法也正确的汉字，配音轨则按你标注的读音走。
三、史料画面怎么对齐：把“找素材”变成“分镜级匹配”
历史文献、古代医书、旧档案这类内容，最耗时的往往不是写稿，而是找画面。手动检索、下载、对齐，一条十分钟的视频，光素材环节就能耗掉几个小时。现在更高效的做法，是把“史料配图”拆成两层任务：先让算法根据文稿语义检索素材，再让人负责判断和替换。
这个层级下，分镜规划是核心。一条历史解说视频，通常可以拆成这样的分镜结构：
{"project":"明代卫所制度与边疆军粮","script_duration":540,"segments":[{"id":"seg_01","narration":"洪武年间，卫所军户的屯田来源主要有三类。","start":0,"end":14,"visual":{"type":"historical_material","keywords":["明代屯田","卫所","军户","洪武"],"fallback":"明代地图空镜"}},{"id":"seg_02","narration":"军屯、民屯与商屯并存，构成边军粮饷的主要支撑。","start":14,"end":30,"visual":{"type":"mg_animation","structure":"三类并列关系","animation":"三栏并立，逐栏点亮","fallback":"军粮运输实拍"}}]}这个 JSON 结构的意义不在“给工具传参”，而在于把文稿的每一句都绑定到一个可视化方案上。哪些分镜用实拍影像，哪些分镜用动态图表，哪些分镜用史料图片，提前想清楚。后面无论用什么工具做自动匹配，都只是把“关键词检索 + 画面候选 + 人工替换”这套动作自动化。
在自动匹配阶段，文稿里出现的年代、人名、制度、器物、地名，会作为“语义锚点”参与素材检索。比如提到“《本草纲目》”，系统会优先匹配古籍书页、药材实拍或相关标本影像；提到“明代太医院”，则会向官制图表、药方档案、旧式药房等方向检索。锚点越明确，匹配的可用率越高。
如果手里有自己的史料素材，比如拍摄过的古籍、手稿、旧地图，也可以上传后作为本地素材参与匹配。这样画面不会全部依赖公共素材库，差异化也更强。
四、成片环节：把 MG 动画留给“讲不清的东西”
历史解说视频里，真正需要动态图表的是这几类内容：
- 制度演变，比如从刺史到州牧的权力变化；
- 人物关系，比如某次会盟的参与方与立场；
- 数据对比，比如不同时期的岁入、兵力、税赋；
- 概念关系，比如“嫡长子继承制”的运作路径。
这类内容不适合硬配实拍画面。更自然的做法是，在分镜规划阶段就划出“动画分镜”，让数据、关系、概念用图表或图解呈现。动画生成时，可以用这类句式做描述：
针对第4分镜，添加一个框架型MG动画： 版式为上下分层，上层展示官职结构，下层展示职权关系； 整体风格采用古代文书质感，配色以赭石和黛蓝为主； 文字信息按“中央—地方—边镇”三级递进展示。这种“描述式”的指令，比“帮我做一个好看的动画”更可控。因为你已经把信息层级、视觉风格、结构关系都点出来了。动画只是把这个结构视觉化。
五、一个可复用的历史视频生成链路
把上面的内容收拢成一条可复用的链路，大致是这样：
- 文稿归一化：写作时保留现代通读性，配音前单独处理专名读音；
- 读音自检：把易读错词单独成段，先短后长，逐条听；
- 脚本拆分：把长文稿按语义切分镜，每句绑定画面方案；
- 素材匹配：用语义锚点做首轮素材匹配，再人工替换不合意的分镜；
- 动画补位：数据、制度、人物关系优先走 MG 动画；
- 字幕配音统一：用同一份逐字稿覆盖字幕和配音，减少双轨不一致。
这套链路不绑定单一工具。配音、匹配、动画、剪辑可以在不同工具里完成，也可以集中在一个创作平台里跑。AI 在这里解决的，主要是“从文稿到画面的对齐成本”和“从文本到声音的生成效率”这两件事。古文读音仍然需要创作者做专业判断，AI 只是把判断结果稳定地执行下去。
只要读音前置、画面锚点清晰、分镜规划到位，历史文献和史料转成视频，就不再是“手工熬素材”的活，而是一套可以复制、可以加速的生产流程。