先别急着写旁白
这次的起点很像一个简单的视频需求：从 GitHub 项目，或者一条 X 帖子，自动做出竖屏介绍视频。画面里要有项目截图或录屏，配音和字幕也尽量自动完成。与此同时，还想做另一种视频：一次介绍多个同类项目。
我一开始也容易把它理解成“找几个项目，写一段介绍，再拼成视频”。但真正动手以后，最先需要解决的不是剪辑，而是判断。单项目视频和多项目合集不是同一种内容，前者要讲清一个项目为什么值得看，后者要在多个项目之间建立可比较的标准。如果一开始就把它们混在一起，后面的文案、镜头长度和素材选择都会失去依据。
一个项目能不能被讲成短视频，首先取决于事实能不能被核对，而不是旁白能不能写得顺。
这件事让我重新意识到，自动化最容易被误解成“让机器替我完成所有动作”。其实更重要的是，把判断顺序固定下来。机器可以抓取、截图、录屏、配音和合成，但它不能替我们承担没有证据的断言。
两种视频，先分开建问题
第1轮需求同时包含两种形态。第1种是围绕单个项目或一条帖子展开，画面可以跟着项目页面、演示视频和帖子内容走；第2种是面向某个垂直主题，连续介绍多个 GitHub 项目。它们都要求说明自动化方式、开源项目和教程来源，但内容组织不同。
单项目视频的核心问题是：“这个东西到底做了什么，观众为什么现在要看？”多项目视频的核心问题则是：“我用什么标准，把这些项目放在同一张地图上？”前者需要一条完整的事实链，后者需要一套稳定的筛选和比较规则。
如果不先区分，最直接的后果是把合集写成项目名清单，把单项目写成资料堆。前者没有重点，后者没有故事。视频虽然可能按时生成，观众却无法判断哪个事实来自仓库，哪个只是文案猜测。
所以我先把候选分成两张表：一张记录“项目—原始仓库—对应帖子—可用画面”，另一张记录“主题—候选项目—共同字段—差异点”。表格不是为了增加手续，而是为了让后面每一句话都知道自己站在哪里。
候选不是证据，仓库和原始页面才是
调研至少分成了3轮。第1轮的任务是发现线索，从 GitHub、X 和已有的开源视频方向里找可能的项目；第2轮不是继续扩大搜索，而是追问第1轮出现的新线索，同时回到仓库核对；第3轮继续处理仍然含糊的地方，并确认哪些内容真的适合进入视频。
这中间有一个很容易误判的地方：搜索摘要、项目名称和别人转述的功能，看起来都足够像“事实”，其实只适合发现候选。比如第1轮出现了多个视频生产、项目介绍和趋势发现方向，后续核对时才发现，有的项目数据和最初回答并不一致。某个项目的 star 数，甚至出现了回答值和实际核对值不同的情况。
搜索结果负责把门打开，原始仓库和原始页面负责决定这句话能不能进成片。
单项目案例最后选了一个同时有公开仓库和对应社交帖子的项目。这个选择不是因为名字最响，而是因为它能把“帖子发现—仓库核对—画面取材”连成一条线。帖子里还有演示视频，可以作为真实录屏素材；仓库里的动图则不是一张完整海报，而是包含多个过程画面的拼图，需要拆成单帧后才能拿来做前后对比。
我选择这种候选，是因为它同时满足内容和画面两个条件：既能说明项目做什么，也能让观众看到它如何工作。只有项目介绍，没有可见过程，视频会像念 README；只有演示画面，没有仓库依据，视频又容易变成没有出处的展示。
证据要绑定到镜头和句子
核对完候选之后，我没有直接开始写整篇旁白，而是把事实拆成几个可拍的单位。一个事实对应一个来源，一个来源对应一种画面，再决定这句话是否需要配音和字幕。比如，项目的用途可以绑定仓库说明；工作过程可以绑定演示视频或动图；帖子传播情况只能按帖子页面看到的内容来讲，不能把它扩大成项目质量的证明。
这个顺序看似慢，实际是在减少返工。网页截图、页面滚动、帖子卡片、项目动图、录屏，都需要不同的画面处理。如果先写了一段很完整的旁白，后面才发现某句话没有合适素材，就只能删句、补素材，甚至重新安排整段节奏。
当时的合成管线包含网页截图和滚动、字幕绘制、配音、视频合成几个环节。首版视频大约76秒，抽帧检查后发现两个具体问题：GitHub 页面上的字太小，字幕切分也会把中文词拆开，甚至出现一帧空白。这个结果很重要，因为它说明“成功生成文件”不等于“视频可看”。
我后来把字幕切分从简单按长度分割，改成更接近词语边界的断句；同时把帖子卡片和演示视频作为独立画面加入，而不是只放一张项目主页。这样做不是为了增加花样，而是让画面承担它应该承担的证据：观众看到的是页面、过程和结果，而不是一串抽象形容词。
最容易走偏的捷径
最容易误判的捷径，是只看项目名称或搜索摘要，就直接生成旁白。这样做的速度确实很快，但它把“可能存在”写成了“已经确认”。安装方法、功能范围、数据规模和维护状态，任何一项写错，都会让视频在发布后变成难以修正的错误说明。
另一个捷径是只追求画面完整。截图、滚屏、配音、字幕和背景都齐了，看起来像成片，就以为任务完成。但如果关键句子没有来源，画面越精致，误导就越像真的；如果字幕把词拆开、页面文字小到看不清，自动化只是把问题更快地复制了一遍。
还有一个很实际的失败：运行目录使用了同名名称，导致下一次任务直接拒跑。配音本身没有问题，问题出在产物和运行状态没有被区分。后来改成每次使用带时间信息的独立名称，才让重复运行变得可控。
自动化流程的验收标准不是“文件生成了”，而是“证据、镜头、配音和字幕仍然互相对得上”。
这也是我没有把第1版直接交付的原因。抽帧能发现空白帧和小字，重新听配音能发现节奏问题，检查字幕能发现断词。每一种检查都在验证不同的风险，不能用“视频播放器能打开”替代。
一条可以复用的证据链流程
这次之后，我把流程收敛成5步。第1步，先判断视频是单项目还是多项目，明确观众要得到的是一个项目的理解，还是一组项目的比较。第2步，建立候选证据表，至少留下项目、原始仓库、原始帖子或页面、可用素材和待核对问题。
第3步，分轮核对。第1轮只负责发现，后续轮次负责复核和修正；任何只在摘要里出现、在原始页面找不到的事实，都先降级为待确认。第4步，把确认后的事实拆成“证据—镜头—配音—字幕”的对应关系，先决定能拍什么，再决定怎么说。
第5步，按成片验收。检查画面是否能读，录屏是否真的展示了功能，配音是否和画面同步，字幕是否按完整词语切分，是否有空白帧或重复运行造成的产物冲突。多项目视频还要额外检查每个项目是否使用同一套比较字段，不能因为某个项目资料多就让它占据全部篇幅。
方法的价值不在于保证每次都一次成功，而在于失败时知道回到哪一步。事实错了，回到原始来源；画面不清，回到素材选择；字幕断词，回到分句规则；重复运行失败，回到产物命名和状态隔离。这样，修改不会变成整条流水线的盲目重做。
下次我会怎么做
下次再遇到“把一个项目自动讲成视频”的需求，我会先问的不是用哪种配音，而是这条视频要证明什么。若是单项目，我会优先找能把帖子、仓库和演示画面串起来的候选；若是项目合集，我会先确定共同比较字段，再去扩展数量。
我也会把证据表提前变成脚本的骨架。每写一句重要判断，就标明它来自哪个原始页面；每选一个镜头，就说明它要证明什么。这样做会让前期看起来慢一点，却能避免后面拿漂亮画面掩盖事实缺口。
这件事让我重新意识到，短视频的自动化不是把判断藏起来，而是把判断留下来。一个成熟的流程，不是它能把素材快速拼成视频，而是下一次仍然能沿着证据链复核每一句话。 当证据先于镜头，文案、配音和字幕才真正有了可以共同依附的东西。