重所周知，gemini是目前唯一个能在视频理解上与其他ai拉开断层式差距的ai ，国产的不用说，不仅有视频时长限制还有文件大小限制，拉完了；claude甚至就不支持上传视频，路边一条；chatgpt就连上传个5分钟时长的视频都要老半天，而且最要命的是它不支持视频理解，只能把视频拆成一帧一帧的图片去看，这就需要花费大量的时间了，这未免太得不偿失了，纯废物；grok虽然有视频理解能力，这明显是ao的，但就它这智商一遇到十几分钟的视频就开始胡说八道了，而且grok的订阅和其他家拉不开差距甚至就它的这个能力来说还偏贵了，想不到什么词说它了，总之垃圾。 而gemini就不一样了，谷歌老早就进军视频理解领域了，从2.5 pro时期就能看出gemini对视频理解不是一般的强，当年的0325一度成为众人的白月光，（让我们缅怀几天前永远离开我们的2.5 pro ），居然视频理解能力都屌上天了，那做字幕包没问题的。 得益于强大的视频理解能力，相当于gemini具备OCR识别+ASR识别能力，这是其他开源字幕生成工具（如：卡卡字幕助手）所做不到的，都清楚大部分字幕生成开源工具都只是依赖whisper模型的ASR识别工具，它们最多只能做到听，这就导致它们无法输出视频里的无声字幕，这是一大重病区，一旦遇上那种正片只有无声字幕的视频，它们就无能为力了，况且api是要钱的，便宜的模型能力不强，强的模型花费又高，而且还没有视频理解能力，llm在字幕生成工具里的用途几乎都是断句+翻译，仅仅只是这样的花我token的话那也太不划算了，还有转录速度这一点，官方whisper在所有 stt模型里转录速度算是快的，但它的转录的字幕并不算优质，有很多会识别错误，所以大部分人我去用一些特调版的whisper了，用过的也知道，并没有和原始whisper拉开很大的差距，一样out。 那么有没有一款质量高、转录速度块、便宜大碗的一条龙式的字幕生成工具呢？有的兄弟，有的，它就是google ai studio，ai studio的老用户都知道谷歌之前确实是大善人，之前的ai studio是完全免费的，自定义程度还算高，还能自由选择web端没有的模型、甚至能加系统提示词和修改temperature、top-p之类的参数，当时2.5 pro一天能调用100多次，日常根本用不完，但自从去年大概11月份左右2.5 pro的次数就越来越少，从100次到50次再到20次、10次，最后甚至开始付费了（不过新模型依旧免费），不过还好ai studio能关联我的web端的pro订阅，能让我继续用上2.5 pro。 说了这么多，你们会发现我一直都在说2.5 pro，毕竟现在都3.1 pro了，我怎么还对着2.5 pro不放呢，因为2.5 pro有个其他gemini模型所没有功能——它支持毫秒级别的视频理解，换句话说它能输出精确到1ms的时间码。你们可能也遇到过让ai生成含时间码的字幕（这里就默认是srt字幕），它们对毫秒位的处理全是清一色的000、100、200、300、……、900这种一眼看上去就知道和音视频绝对不同步的时间码，就算你提醒了它们一定要做到音画/音频同步，它们也还是会生成这种毫秒位，因为它们没那个能力，但2.5 pro无需提醒，它天生就具备这种能力，虽然跟 ElevenLabs这种专业的模型没法比，但好在字幕能准确对上画面，可能也就那么几条字幕对不上画面，但在观看过程中大部分字幕是不会感觉到和画面是有延迟的（2.5 pro yes），这是3.1 pro 怎么都做不到的精确，3.1 pro大部分时候只能一味的输出000、500这两种毫秒位，是的，只有这两种，有时候干脆只会输出000这一种毫秒位，垃圾3.1 pro对毫秒位上的处理堪称残废。 不过好景不差，就在几天前谷歌把2.5 pro从ai studio上下架了（我chovy，谷歌你坏事做尽，不是说好了10月份再下架的吗，2.5 pro没了你我怎么活啊），不过也别太难过，就算其他模型没有2.5 pro那样毫秒级别的视频理解，那也不是什么大问题，只要它能理解视频就赢了一大半了，那毫秒位不精确的问题要怎么处理呢？这时我们就需要用上l站里的一个佬友做的一个工具了—— 【Scribe2SRT】 白嫖 elevenlabs 网页端 stt，音视频一键转录生成 srt 字幕 ，之前也说过ElevenLabs算是第一梯队的stt模型了，再加上ElevenLabs有免费调用次数（只要不频繁使用就不会触发ip调用次数限制，大不了套上个cloudflare 再访问它就没问题了），这无疑是最佳之选，ok，现在我们有了最强级别的转录模型+gemini强大的视频理解能力，又赢了一大半了 那…那么提示词呢？在之前我确实是用了 浮霄默客 大佬的 突破 10 分钟魔咒！哈基米精准时间戳还得靠这组合拳 (提示词 + 脚本) 这个提示词，但是他写的提示词并不直接生成srt格式，还需要用到python脚本，但那是没办法，因为那时直接让2.5 pro生成srt格式容易“截断” （图上并非是2.5 pro而且是srt格式字幕，但我说的“截断”就是这种情况，没办法gemini代码块的通病了），所以只能变相先让它生成默客所写的这种格式，再将其用py脚本转写为srt格式（虽然多了手动调用py脚本一么一步，但习惯之后也蛮好的，因为并不耗时间），经过我这么多次的实验发现现在3.8 flash的截断情况比2.5 pro好很多，所以我们现在可以直接让它生成srt格式的字幕了，那现在只差把ElevenLabs生成的时间戳和gemini生成的字幕联系起来，这个好解决，scribe2srt 这个工具会生成json格式的字幕和srt格式的字幕， 别管srt那个，我们只需把json文件（因为json文件里是精确的词级时间戳，这样gemini可以更好的管理时间码）连同视频本身（如果是youtube的视频直接粘贴url到ai studio上就行了，无需等待上传，能直接开始分析视频，背靠youtube就是好 ）一起发给ai studio，再添加一点提示词就行了 好了，你们开始写提示词吧，算了，我直接发给你们吧，省的你们动手调教提示词，下面我的提示词是根据 Free: AI Studio 實用教學！無限免費影片字幕生成！免費提示詞分享！ 这个提示词为整体框架和主体进行不断的修改最终改出来的完美提示词： 任务：请根据提供的视频，直接生成一份完全符合下述所有SRT 结构和字幕生成规则的简体中文字幕内容。再次强调，SRT 格式的精确性至关重要，特别是确保每个时间码都包含HH: 部分(即使是00:)、每个字幕块的字幕文本部分可单行/换行/多行灵活显示、时间码的逗号、毫秒补零以及字幕块之间的空行。最后输出为代码块。 SRT 结构的关键规则（必须毫无例外地严格遵守）： 序列号：一个从1 开始并严格递增的整数。 时间码： 格式绝对必须为HH:MM:SS,mmm (小时:分钟:秒,毫秒)。这是不可协商的。 小时部分(HH) 即使为零，也必须显示为00。例如，1 分5 秒9 毫秒应表示为00:01:05,009，绝不能省略小时部分而写成01:05,009。此规则适用于档案中的每一个时间码。 分钟(MM) 和秒(SS) 若不足两位数，必须以0 在前面补齐（例如00:01:05,009）。 毫秒(mmm) 必须为三位数，若不足三位数，必须以0 在尾部补齐（例如00:00:01,050 而不是00:00:01,50）。 开始时间和结束时间之间必须使用–> (一个空格，两个减号，一个大于号，一个空格) 分隔。 时间码行本身前后不得有任何多余空格或字符。 字幕文本： 优先在理解音频的基础上保证转录文本的准确性，以及时间码的合理性与精确性。 提取并输出画面里所有的文字（不管有没有声音，但不要输出原文）以及所有的说话的声音（不管有没有文字，包括背景音乐，如果有歌词的话也要输出歌词，歌词要用音符框起来）。 核心原则：在每一个字幕块中，此字幕文本内容既可显示为单行，也可在单个字幕块的字幕文本部分内部产生换行符或显示为多行。当句子过长时，可换行显示，但换行时每一行都要做到自然不突兀。当画面里同时出现多处文字或多个对象同时说话时，可显示为多行。 遵循下述「字幕生成规则」。 空行：每个字幕块(包含序列号、时间码、字幕文本) 之后，必须有一个且只有一个完整的空行将其与下一个字幕块分隔开。这是SRT格式的基础。 换行符：序列号行、时间码行、以及字幕文本行，这三者各自作为独立的行，它们之间必须使用标准换行符分隔。 字幕生成规则（请按优先级顺序执行）： 第一优先：单行显示与长度限制 重申核心原则：每一字幕块的字幕文本部分，可以单行，也可以换行或多行显示。 为确保此单行字幕易于阅读，其文字长度绝对不能超过25 个简体中文字符。 如果原始口语语句的自然长度超过25 个字符，或者其语义停顿点暗示需要分行，则该原始语句必须被切分为数个新的、独立的字幕块。每一个新切分出的字幕块都将拥有全新的序列号和对应的时间码，并且其自身的字幕文本部分可单/换/多行显示和25 字符内的长度限制。 第二优先：语意分段与新字幕块的创建 当因上述「单行显示与长度限制」原则需要切分原始口语语句时，切分点应选择在最自然的语意停顿处（例如，在一个短语或句子结束后）。 每一次有效的切分都意味着结束当前字幕块，并为切分后的下一段文本创建一个全新的字幕块。 这样，原本可能导致在同一字幕块内换行的内容，会被合理分配到连续的多个单行字幕块中。 第三优先：比对并修正时间码的毫秒位 我会提供你一份具有精确的词级时间戳的 .json 文件（忽略里面的文本），请根据 .json 文件里的词级时间戳，比对并修正时间码的毫秒位，毫秒位必须要用 .json 文件里的词级时间戳，这样才能确保字幕与声音同步。 第四优先：内容净化与精简 忽略没有意义的语助词（如：嗯、啊、呃）、口吃或不影响语意的重复词语（如：那个、那个）。 字幕行中不包含任何非语言声音(喘息声、吞咽声、笑声等)。 第五优先：翻译修改与润色 翻译的准确地道，以信达雅为第一翻译原则。要求语言流畅，符合中文语言顺序和用词习惯。通常采用中文网络文学的语言风格翻译，接地气，易懂。在做到信达雅的同时，将汉语中不常见的写法替换为各种网络流行用语、网络吐槽语、网络流行梗、网络流行成句等等（你可以联网搜索，如：萌娘百科）。 【重要】保留除句号以外的所有标点：在此净化步骤中，必须保留所有原始识别出的除句号以外的标点符号（如：，？！等），不得省略，但必须替换为简体中文标点符号，双引号是例外，双引号必须使用「」符号，不要使用“”。 【注意】：当我回答「继续」时，你需要检查上一次输出内容，和原文比对，确认翻译内容是否完整。若不完整，你要接续上一次文本的末尾继续输出，直到完成任务，禁止从头重新开始翻译。若上一次输出内容已经完整，你将会询问我，[对不起，我已经完成上次翻译任务，请问还有新的翻译内容吗？或者你需要我重新翻译之前的内容？]在我回答之后，你将按要求翻译我给予的新内容，或者重新翻译之前的内容。 这是让gemini对一个17分钟的视频（并不是之前那张图片里面的视频）生成字幕的最终效果（别忘了把json文件丢进去） 从开始到结束只花了3m29s，这速度快不快，（刚在页面被我刷新了，现在显示不了生成时间，不过我看到的确实是3m29s） 可以看到一个17分钟左右的视频只要3-4分钟左右的时间就能生成完整srt字幕，而我平常看的10分钟左右的视频甚至只要2分钟完成了，从下载视频（我是用stacher）–> scribe2srt转录字幕 → gemini按照提示词生成最终srt字幕，只花了我不到5分钟的时间就完成了，gemini还是太权威了 你以为到这就结束了吗，记得我标题说的ass字幕吗，别急，现在我就把提示词发出来（这个ass字幕提示词是也是根据srt提示词进行大改的，但并非我独自一人完成的，也叫codex帮了点忙），以下是ass提示词： 任务：请根据提供的视频，直接生成一份完全符合下述所有ASS 结构和字幕生成规则的简体中文字幕内容。再次强调，ASS 格式的精确性至关重要，特别是确保文件完整包含[Script Info]、[V4+ Styles]、[Events] 三个部分、每个时间码都使用H:MM:SS.cc 格式、每个字幕事件严格使用Dialogue: 行、字幕文本部分可单行/换行/多行灵活显示、时间码的句点、百分之一秒补零以及各字段之间的英文逗号。 同时必须仔细分析视频画面中原有字幕、标题、说明文字、人物姓名、UI文字、歌词以及其他需要翻译的可见文字的视觉样式，并在ASS允许的范围内尽可能复刻其原始视觉效果，包括字体风格、字号、文字颜色、透明度、粗体、斜体、描边、阴影、背景框、字间距、缩放比例、对齐方式、边距、位置以及多行排版等。 视频画面中已经存在可参考文字样式时，禁止为了统一字幕风格而擅自将其全部替换成统一的白字黑边底部字幕。 最后输出为一个完整的ASS代码块。 ASS 结构的关键规则（必须毫无例外地严格遵守）： 文件结构：ASS 文件必须严格按照以下三个部分依次组成： [Script Info] [V4+ Styles] [Events] 不得使用SRT 的序列号，也不得使用SRT 的“–>”时间码格式。 [Script Info]： 必须至少包含以下内容： [Script Info] ScriptType: v4.00+ PlayResX: 视频实际宽度 PlayResY: 视频实际高度 ScaledBorderAndShadow: yes WrapStyle: 0 PlayResX 和PlayResY 必须根据提供的视频实际分辨率填写，不得直接输出“视频实际宽度”或“视频实际高度”等占位文字。 PlayResX 和PlayResY 同时也是ASS字幕定位、字号、边距、描边等视觉参数的参考坐标系，因此所有位置和尺寸判断都必须以视频实际分辨率为基准，不得套用其他分辨率的视频参数。 [V4+ Styles]： 必须包含Format 行和至少一个名为Default 的Style。 格式必须为： Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bol

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/22 17:34:01