在遇到漂亮的风景、不安全的驾驶行为等情况时，我习惯于将行车记录仪的视频拷贝下来，保存在nas上；但是大部分行车记录仪的视频都是分段存储的，通常是每1或5分钟一个文件。为了方便查看，我需要将这些视频拼接成一个完整的视频。
文件metadata中的创建/修改时间戳并不完全可靠。因此，主要方向是通过视频文件名中包含的时间戳来进行拼接。
以往的做法，需要分析视频文件名，从中找到时间戳的特征，然后提取出时间戳，根据时间戳的范围来分组视频，进而拼接成一个完整的视频，我车上原装的记录仪和后装的都有相似的格式，可以共用提取逻辑；这种方案我使用了一年，没什么大问题。但是最近换了一款记录仪，文件名的结构变化较大，不再适用此前的提取逻辑。为了适应新的文件名格式，我需要重新设计视频拼接的逻辑。
修改的唯一目的是，这个提取逻辑可以适配不同行车记录仪的文件名格式。我想到让大模型来做这件事。
设计思路
prompt设计如下：
| |
prompt中要求模型返回文件的序号，而不是文件路径，这是为了减少模型返回的内容长度。否则，在文件数量较多时，模型返回的内容会很长，可能导致超时或者超出token限制。
我们还需要检查模型的输出，一方面检查输出格式是否符合json要求，另一方面检查输出内容，确保没有遗漏文件，也没有新增文件。
如果检查不通过，则可以告诉模型哪些地方不对，然后拼接历史消息，然后再送给模型，让模型再次输出。
当生成正确时，就可以将分组好的文件路径传给ffmpeg进行拼接了。ffmpeg拼接方法本文不再赘述。
当然，在调试过程中我也发现了一些错误分类的情况，比如某10个文件实际可以拼接成一个连续的视频，它们可以划分在同一组，但是模型输出的结果把他们划分为了两个组。针对这种情况，一方面可以思考是否也算符合自己的需求，另一方面则是通过修改prompt来优化模型输出。比如针对本文的视频拼接需求，偶尔把一个长视频划分成两个短视频也并不糟糕；因此我只修改了若干次prompt，没再发现这种划分多组的问题就算它通过了，并没有再经过复杂的验证。
脚本源码相继于本文的思路来说不算重要，我就不贴了（偷懒，不想整理）。
总结
通过这次实践，可以发现，对模型输出的检查是非常重要的。因为模型的输出不能保证总是正确的。检查方法需要根据具体的需求来设计。比如在本例中，我们使用计算机代码来检查模型的输出是否正确，而不是使用另一个模型来检查。本例中，如果检查失败，我们会将错误信息反馈给模型，要求它重新输出正确的结果。
对于本文讨论的这种非创造性的需求，一般会设置模型的temperature为0，确保模型的输出是确定的。而对于之前讨论的“文章摘要”话题，可以适当给模型一些创造的空间。
另外，结合最近两次实践的prompt来看，有一些表述显得啰嗦，是因为目前发现重复（啰嗦）的一些表述，可以提高模型的输出质量，使其返回内容更满足需求。