一开始，我把这件事想得很像一个普通的视频自动化任务：找到几个热门开源项目，分别写几段介绍，再把截图、配音和字幕拼起来。单个项目这样做似乎没有问题，项目合集也只是多循环几次而已。
但真正开始处理时，我很快发现这两个任务并不是同一个任务的大小版本。单项目视频是在有限时间里把一个项目讲明白；多项目合集是在更短时间里帮助观众比较、筛选和记住一组项目。前者的核心是解释，后者的核心是组织判断。项目数量一增加，脚本就不再只是“多写几段”，而会变成一套编辑系统。
先判断是在深讲一个，还是横向选多个
当时的需求同时包含两种内容：一种是有人分享一个 GitHub 项目，或者分享一条相关帖子，然后自动做成竖屏视频，里面有项目页面、截图或录屏、配音和项目说明；另一种是围绕某个垂直方向，一次介绍多个开源项目。两种内容都要自动化，也都需要寻找候选项目和相关内容，但观众进入视频时的期待完全不同。
单项目视频的第一个问题通常是“它到底做什么”。所以素材可以围绕一个主线展开：项目解决什么问题，页面上能看到什么，普通人如何理解它，最后为什么值得关注。镜头可以有变化，但所有变化都服务于同一个解释对象。
合集视频的第一个问题却是“为什么是这几个，以及它们之间怎么比较”。如果只是把多个单项目视频首尾相接，观众会得到一串名称，却得不到选择依据。项目之间可能重复，介绍深浅不一，前几个项目占满时间，后几个项目只剩一句口号。这里最容易误判的是，把“同一批素材”理解成“同一套内容结构”。
所以我先把题型拆开，而不是先写脚本。这个判断看似只是分类，实际上决定了后面要收集什么证据、怎样排序项目、每个项目分配多少时长，以及最终验收什么。先分题型，是为了让后面的自动化知道自己正在优化什么，而不是让同一套脚本盲目重复。
合集的主题必须先于项目名单
用户希望寻找热门 GitHub 项目和相关帖子，也希望检查已有的话题发现能力。这个要求表面上是在找素材，实际是在问：这一期合集的边界是什么？如果没有边界，热门项目会不断涌进来，最后只能按“搜到什么讲什么”剪成清单。
我会先给合集写一句选题标准，例如它服务哪类人、解决哪类问题、项目必须具备什么公开证据。这里的标准不一定复杂，但要能在候选之间做取舍。一个项目很热门，不代表它适合这一期；一个项目很新，也不代表它能在几十秒里讲清楚。主题的作用，就是把“看起来不错”变成“符合这次任务”。
然后再做候选收集。候选来源可以包括项目主页、说明文档、公开讨论和已有发现结果，但发现和确认要分开。搜索结果适合告诉我“可能有这个项目”，不能直接承担“这个项目能做什么”的全部结论。项目名称、简介、许可证、最近活动或用户能看到的功能，都应该回到项目本身去核对。
如果不处理这一步，会导致合集主题在剪辑过程中不断漂移：开头说的是一类工具，中间混进另一类项目，结尾只能用“今天就介绍这些”来收尾。观众不是看不懂某个项目，而是不知道这组项目为什么被放在一起。一个有主题的合集，项目名单应该是主题筛选后的结果，而不是主题由名单反推出来。
排序不是装饰，而是合集的叙事骨架
候选项目确定后，排序就成了第二个关键决策。排名可以参考热度、成熟度、功能差异、上手门槛和对普通观众的价值，但不能只把一个数字当作全部依据。热门项目适合建立注意力，容易理解的项目适合让观众迅速进入状态，差异明显的项目适合拉开中段节奏，最值得讨论的项目则可能放在最后形成记忆点。
这次最终采用了按项目排名组织介绍片段的方式。它不是为了制造一种“第 1 名一定最好”的错觉，而是给观众一条可以跟随的路线。每个项目进入时，观众知道它在这一期中的位置；项目切换时，也能意识到比较关系还在继续，而不是重新打开了一个无关的视频。
我选择先定排序，再写每段文案，是因为排序会改变每个项目需要承担的任务。第一个项目要尽快解释主题，不能一上来就堆细节；中间项目要提供差异，避免同一种介绍方式连续重复；最后项目要完成总结或留下判断。合集的节奏不是剪辑阶段才产生的，它首先由项目排序和每项的叙事职责决定。
这里还有一个重要边界：排序理由必须能被说明。如果只是凭感觉把项目排成一列，后续配音再流畅，也只是把主观印象包装得更像结论。排序可以是编辑判断，但不能伪装成没有依据的客观排名。必要时，我会把“推荐顺序”“热度顺序”和“适合入门顺序”区分开，避免观众把不同标准混为一谈。
给每个项目固定最小事实集
单项目视频可以在某个细节上深入，但合集必须先保证每个项目都有基本完整的事实。否则，最容易出现的错误捷径就是复制单项目脚本，只替换项目名称。这样做短期很快，长期一定失控：有的项目讲了用途，有的项目只讲了口号；有的项目有页面证据，有的项目只有搜索摘要；有的片段需要十几秒，有的片段不到 3 秒。
我会先为每个项目固定最小事实集：项目是什么、解决什么问题、观众能看到或使用的核心能力是什么、有什么适合展示的页面或操作、它在本期中为什么值得出现。若某项事实无法核对，就不为了填满槽位而猜测。合集的统一，不是让每个项目说完全一样的话，而是让它们接受同一套最低检查。
固定事实集之后，才决定每个项目的展示时长和镜头。截图、项目页面、简介和配音要互相对应。画面展示功能时，配音应解释这个功能对观众意味着什么；画面只是项目首页时，就不要用它证明首页没有展示的复杂能力。素材越多，越需要让每个镜头承担明确任务。
这次制作过程中，字幕分段、画面尺寸、音频和视频时长也在成片前被检查。它们看起来不像选题问题，却直接关系到事实是否能被顺利接收。字幕挤成多行，观众可能读不完；画面尺寸不统一，项目之间的比较会变得疲惫；音频比视频长，结尾就会留下无法解释的空白。可信的合集不只要事实正确，还要让事实以稳定、可读、可核验的形式到达观众。
用统一模板保持差异，用门禁阻止失控
统一模板并不意味着每个项目都要做成同一张卡片。真正应该统一的是镜头顺序和验收规则，而不是把所有项目的画面强行做成一样。比如每个片段都可以按“项目名—一句话用途—核心功能—页面或操作证据—过渡判断”展开，但具体的截图、录屏和强调方式可以随项目特征调整。
这样做的好处是，批量生产时不需要每次从零决定结构；观众也能快速适应节奏，把注意力留给项目差异。模板还会暴露事实缺口：某个项目始终找不到可展示的核心功能，说明它可能不适合进入这一期，而不是继续用装饰性动效掩盖内容不足。
我会把验收分成几道小门。第一道检查项目是否仍然符合主题和排序标准；第二道复核每个事实是否有对应的项目页面、说明或可见操作；第三道检查每个项目是否拥有同样的最小事实集；最后才检查字幕是否单行可读、画面比例是否合适、音视频是否对齐、收尾是否完整。顺序不能倒过来，因为画面做得漂亮，并不能补回选题和证据的缺口。
失败或不确定的项目也要有处理规则。页面打不开时，不把旧印象当成当前事实；说明不清时，降低表述强度；无法证明的能力，不写成确定结论；素材不足时，宁可减少项目数量，也不拿重复截图凑时长。如果不设置这些边界，自动化会把错误稳定地复制到所有片段，批量生产反而放大风险。
这件事让我重新意识到，自动化真正擅长的是重复执行已经做好的判断，而不是替我们发明判断。流水线的价值不在于一次生成很多项目，而在于它能让每个项目经过同样的证据复核和交付检查。
下次我会怎么做
下次遇到类似需求，我会先问自己：这是要把一个项目讲深，还是要帮助观众在一组项目中做选择？如果是单项目，我会围绕一个主问题组织解释，优先保证主线清楚；如果是项目合集，我会先写选题标准，再做候选收集、证据复核和排序，不会先复制脚本。
具体流程可以压缩成 6 步：先分题型；再定义合集主题和入选标准；然后收集候选并回到项目本身核实；接着确定排序和每个项目的最小事实集；再用统一镜头模板批量制作；最后执行事实、字幕、画面、音频和时长的交付门禁。流程的每一步都应该能回答一个问题，而不是为了让表格看起来完整。
我还会给项目数量设一个上限。数量不是越多越有价值，超过观众能比较的范围之后，每个项目分到的注意力会迅速下降。少讲几个、把差异讲清楚，通常比塞进一长串名称更可信。主题明确、排序有据、证据能对上、镜头能看懂，这 4 件事比“介绍了多少个项目”更值得作为合集的完成标准。
一个流程成熟的标志，不是它能顺利跑通一次，而是下一次面对新项目时，不必重新争论什么算完整、什么算证据、什么算交付。单项目和项目合集看起来都在介绍开源项目，真正不同的却是它们对观众承诺的东西：前者承诺把一个对象讲清楚，后者承诺帮观众看懂一组对象之间的关系。把这个差别保留下来，流水线才不会只剩下自动化的外壳。