别再让AI看视频"看个寂寞"！从抽帧到Embedding，从时间戳对齐到多模态RAG，手把手教你打造能"看懂"视频、能"说人话"的生成式AI应用。这篇文章，就是你在视频RAG深水区里最结实的那块垫脚石。

本文目录速览：

• 要点一：视频解析与关键帧提取——别让AI对着黑屏发呆
• 要点二：多模态嵌入与向量索引——你的视频片段真的能被找到吗？
• 要点三：时间戳对齐与上下文召回——为什么AI总答非所问？
• 要点四：跨模态融合与重排序——视觉、听觉、文本的三位一体
• 要点五：大模型生成与答案溯源——拒绝一本正经地胡说八道
• 要点六：工程化部署与性能调优——从Demo到生产的最后一公里

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》97.[第10章 视频RAG应用] 视频问答实现：理解视频内容并回答问题

“看了，但又好像没看。”

这句话是不是特别扎心？就像你明明花了两个小时刷完一套技术教程，结果同事问你"视频里第三步配置的那个参数叫啥"，你瞬间大脑空白，只记得开头那句"哈喽大家好"和结尾的"我们下期再见"。更气人的是，连进度条都不知道拖到哪去找。

更扎心的是，咱们很多新手朋友做出来的视频问答系统，状态跟你差不多——视频确实传进去了，向量也存了，检索也跑了，但用户一问细节，AI就开始"已读乱回"。不是胡编乱造，就是答非所问，偶尔还会给你编一个视频里根本不存在的时间点，讲得比真的还真。

为啥会这样？因为视频RAG这玩意儿，真的不是简单地把"文本RAG"那套代码复制粘贴，再把txt文件换成mp4文件就完事了的。视频里有画面、有声音、有字幕、有PPT翻页，信息维度比纯文本复杂得多。你少做一步，系统就"瞎"一分；你错配一个环节，用户就得忍受AI的胡说八道。

今天，大仙我就把这整套视频问答实现的链路拆成六个关键要点，带着你一步一步把坑填平。从怎么科学地"拆"视频，到怎么让图文音在同一个语义空间里"碰头"，再到怎么在工程上扛住高并发——系好安全带，咱们发车！

---

要点一：视频解析与关键帧提取——别让AI对着黑屏发呆

点题：

做视频RAG，第一步永远是"拆"。你得把视频这个黑盒子拆开，让AI能看到里面的"零件"。这些零件包括：音频里的说话声（ASR）、画面里的关键帧（Keyframe）、屏幕上的文字（OCR），甚至还有镜头切换的节点和画面变化的幅度。只有拆得细、拆得准，后面的检索和生成才有米下锅。这一步要是糊弄，后面全白费。

痛点分析：

我见过太多新手在这一步就直接崩盘。最常见的骚操作是啥？打开Python，调个OpenCV，然后cv2.VideoCapture配合一个while循环，每隔固定秒数抽一张图，完事儿。你还别笑，真有人这么干，而且觉得自己挺聪明——“均匀采样，多公平啊！”

问题大了去了。你想啊，一个10分钟的1080p视频，如果是30fps，总共18000帧。你每30帧抽一张，也有600张图。600张图往多模态Embedding模型里一塞，光推理时间就够你泡三杯咖啡。更离谱的是，很多连续帧的内容几乎一模一样，比如讲师对着一个PPT讲了五分钟，你抽出来的图全是一个画面，纯粹是浪费算力和存储空间，检索的时候还会因为重复内容导致"堵车"。

还有一种极端反例：有人为了省算力，只抽视频的第一帧、中间帧和最后一帧，三帧定乾坤。结果用户问"视频结尾的总结"，你倒是能答，用户问"第三分钟的那个代码截图报错信息"，你中间帧刚好落在讲师低头喝水的画面上，AI直接懵圈，给用户回一句"视频中没有找到相关内容"。

音频这块也是重灾区。很多人直接把整个视频的音频当成一大段纯文本，不做时间戳对齐，也不分段。最后检索出来一段文字，根本不知道它对应视频的哪个位置，用户体验极差。更有甚者，视频里明明有背景噪音和BGM，他也不做语音增强，ASR转出来一堆错别字，“线程池"识别成"现场吃”，后面检索根本对不上。

解决方案：

抽帧这件事，核心思路不是"均匀采样"，而是"变化检测"。你要让机器像人一样看视频——镜头没动、画面没变的时候，看一眼就够了；一旦PPT翻页了、讲师切到IDE写代码了、画面从人头像变成动画了，这时候才需要记录。这叫"关键帧提取"，而不是"傻瓜式抽帧"。

具体怎么搞？上工具。PySceneDetect就是一个专门做镜头边界检测的库，它通过分析相邻帧的差异度（直方图对比或内容检测算法），自动找到镜头切换点。你只需要在这些边界处提取关键帧，再配合一个"最大间隔兜底"策略（比如最长不超过5秒必须抽一帧，防止长镜头漏信息），这样既能保证信息不丢，又能把帧数压缩到原来的十分之一甚至更少。

音频部分，强烈推荐用Whisper或者类似模型做ASR，而且一定要选带时间戳的输出模式（segment-level或者word-level）。这样转出来的每一段文本都带开始和结束时间，后面做时间对齐的时候才能精准定位。如果视频音质一般，可以先过一遍ffmpeg的音频滤波（比如高通滤波去底噪），ASR准确率能提升不少。

如果视频里还有PPT、代码截图或者界面演示，别忘了上OCR，比如PaddleOCR或者EasyOCR。有时候讲师嘴里说的和PPT上写的不完全一致，甚至口误了，OCR出来的文字反而是准的。这两者互为备份，信息才完整。

小结：

视频解析不是简单的"格式转换"，而是"信息密度的重新分配"。抽帧抽得好，后面的RAG就赢在了起跑线；抽不好，AI就只能对着黑屏和重复画面发呆。

---

要点二：多模态嵌入与向量索引——你的视频片段真的能被找到吗？

点题：

拆完视频，你手里会攥着一大堆"碎片"：关键帧图片、ASR转录文本、OCR屏幕文字，还有它们各自对应的时间戳。接下来的灵魂问题是，怎么让用户的一句自然语言提问，能精准地从这堆碎片里捞出最相关的那些？这就要靠多模态Embedding和精心设计的向量索引了。

痛点分析：

这个环节的坑，我愿称之为"强行拉郎配"。

很多小伙伴从文本RAG转过来，手里最熟的就是text-embedding-ada-002或者BGE这类纯文本模型。于是他们一拍脑袋：图片？我用CLIP编码。文本？我用BGE编码。然后把这俩向量往同一个向量库里一扔，就开始做相似度检索。

结果呢？维度不一样，根本写不进去一个集合（Collection）。好，你强行把CLIP的512维投影到1536维，或者反过来做PCA降维。可问题是，CLIP的语义空间和BGE的语义空间压根不是一回事，就像把北京地铁线路图和上海公交路线图叠在一起看，能对上号才怪。检索出来的结果简直是"跨服聊天"。你问"视频里那个红色的错误提示是什么"，文本Embedding去匹配ASR里的"error"和"red"，图像Embedding去匹配那张红色报错图，两边各找各的，最后Top-K里可能全是噪音，真正相关的片段被埋在了第50页。

还有一种错误，是把所有视频、所有关键帧的向量不做区分，全部压到一个平面索引里，二十个视频的课程混在一起。用户明明问的是"第一节课的内容"，检索结果里却混进了第三节课的画面，就因为它们的视觉背景碰巧都是深色IDE界面。这种"跨视频污染"会让答案完全失控。

解决方案：

首先，必须统一语义空间。现在有很多开源的多模态Embedding模型可以直接用，比如jina-clip-v1、BGE-VL，或者国内的Piccolo2-zh。这些模型的核心能力就是能把中文文本和图像编码到同一个向量空间里，共享相同的维度。你的查询文本和关键帧图像，用的是同一个模型、同一个空间，这样才能 apples to apples 地比相似度。如果你非要分开建模，那就必须加一个投影层（Projection Layer）做对齐，否则检索质量就是开盲盒。

其次，索引结构要分层，不要只建一个"大杂烩"索引。建议按"视频ID -> 时间片段 -> 具体模态"的层级来组织。向量数据库里，每个向量都要带上video_id、start_time、end_time、modality_type（是image还是text）这些元数据。检索时先用video_id做过滤（或者按课程/视频分组检索），再在单个视频内部做语义搜索，精度能提升一大截。你想想，在一个限定好的"小池塘"里捞鱼，总比在"大海"里盲目撒网强吧？

向量数据库选型上，如果是轻量级项目，Qdrant或Milvus社区版都够用，上手快。如果要上生产环境，考虑Milvus分布式版或Weaviate。索引类型推荐HNSW，在召回率和查询速度之间比较平衡。另外，千万别忘了做混合检索——向量相似度兜底语义相关性，BM25或全文检索兜底精确匹配（比如代码里的特定函数名、报错信息里的专有名词）。两条腿走路，才能又快又稳。

小结：

向量索引是视频RAG的"地基"。地基歪了，检索必垮；语义空间对齐了、索引结构分层了，才能指哪打哪。

---

要点三：时间戳对齐与上下文召回——为什么AI总答非所问？

点题：

用户问"第三分钟左右，讲师提到了哪个设计模式"，你召回的片段却是第五分钟的闲聊。这种"时间错乱"，是视频问答系统最让人抓狂的体验之一。时间戳对齐和上下文召回，解决的就是"什么时候发生了什么事"的问题。没有时间维度的精准控制，RAG就是个聋子的耳朵——摆设。

痛点分析：

新手在这里最容易犯的错，我总结为"碎片化孤岛"。什么意思？就是把视频切得太碎，每一帧、每一句ASR文本都当成独立的文档去建索引，彼此之间在时间轴上完全割裂。检索的时候，确实能召回最相似的那一条，但它前后发生了什么，系统完全不知道。

举个例子。用户问"讲师总结了几点建议"。你的系统从向量库里召回了三条ASR文本：

1. “首先我们要注意内存泄漏的问题”（00:01:20）
2. “第三点，尽量使用连接池”（00:05:40）
3. “好的我们来看第二个问题”（00:03:15）

看到没？这三条虽然都包含序号词，但在时间轴上是跳来跳去的，而且缺了"第二点"和具体的上下文。你把这三条丢给大模型，模型要么只回答一半，要么自己脑补一个"第二点"，幻觉就这么来了。用户拿到答案也一脸懵：这到底是几点？

还有一种情况，是召回结果在时间轴上高度重叠。比如连续三帧关键帧都被召回了，内容其实差不多，但Prompt里重复了三次，白白浪费token，还可能让模型误以为"这段内容很重要，我要多说几句"，导致答案失衡。

解决方案：

召回的核心原则叫"以点带面"。当你通过向量检索命中某一个时间点（比如00:02:48），不要只把这一帧或这一句话塞给模型，而是以它为中心，向前后各扩展一个时间窗口，比如前后10到15秒。为什么？因为人类说话是有上下文的，讲师不可能在某一秒突然蹦出一个无头无尾的概念，前面一定有铺垫，后面可能有总结。

具体实现上，你的向量元数据里要有精确的start_time和end_time。检索命中后，根据这个时间戳去"捞"同一段时间内其他模态的信息。比如命中了一个关键帧，就把同一时间段内的ASR文本也捞出来；命中了一段文本，也看看附近有没有相关的关键帧可以补充。这种"时间窗口聚合"能极大提升上下文的完整性。

捞上来之后，还要做"时序合并"。如果召回的多个结果在时间轴上重叠（比如00:02:00-00:02:10和00:02:05-00:02:15），就把它们合并成一个连续片段，去掉冗余内容后再按时间顺序送入Prompt。这样能保证信息的时序连贯性，也节省了宝贵的token预算。

另外，如果用户的问题里包含了时间线索词，比如"后面"、“接下来”、“之前提到的”，一定要在查询改写（Query Rewriting）阶段把它解析出来。结合对话历史，把"后面"映射到当前话题时间戳之后的一个范围，再做检索。不然模型怎么知道你说的是哪个"后面"？

小结：

没有时间戳对齐的RAG，就像没有页码的词典。查得到词，却翻不到页，答案自然对不上号，用户只能干着急。

---

要点四：跨模态融合与重排序——视觉、听觉、文本的三位一体

点题：

召回了一堆素材，有图、有文、有音频转录，接下来怎么让它们协同工作，而不是互相拆台？跨模态融合和重排序，就是把这堆"各说各话"的原材料，整理成一份逻辑清晰、信息互补的"briefing"交给大模型。这一步做不好，Prompt就是一锅粥，模型看了直呼"这题超纲"。

痛点分析：

我见过最直接粗暴的做法，就是把检索到的Top-K结果，不管三七二十一，按"图-文-图-文"的顺序往Prompt里一贴，然后跟模型说"请根据以上内容回答"。这相当于把一本打乱页码、缺章少页的教科书扔给学生，让他临场考试，能考好才怪。

更隐蔽的坑是信息冗余。同一段内容，可能在画面里以文字形式出现（OCR识别了），又被讲师念了一遍（ASR转录了），还被你抽了关键帧（图像描述模型生成了一句"图上写着准确率99%“）。三句话语义重复，全塞进Prompt，不仅浪费token，还可能让模型困惑：这三个来源说的到底是不是一回事？如果OCR把"99%“识别成了"9q%”，ASR是准确的"99%”，模型该信谁？没有融合机制，它只能抓瞎。

还有一种情况是模态错位。用户问的是"代码里那行红色报错是什么意思"，你召回的结果里有一段ASR讲的是"我们接下来看一下这个架构图"，虽然语义上都是"看"，但根本不是一回事。如果没有重排序机制，这种噪音很容易混进上下文，因为召回阶段的双塔模型（Bi-Encoder）只能粗筛，精度不够。

解决方案：

第一步，先做"模态内去重"。对于OCR和ASR这种都是文本的，可以用简单的编辑距离或者语义相似度做去重。如果两段文本相似度超过0.9，保留时间戳更完整、识别置信度更高的那一段。图像描述如果和OCR内容高度重合，优先保留OCR（因为更精确），图像描述作为补充。

第二步，引入Cross-Encoder做重排序。召回阶段用的双塔模型追求的是速度，但精度有限，容易引入 false positive。把召回回来的候选结果（比如Top-50）和用户查询一起送进一个多模态的Cross-Encoder（比如专门微调的图文匹配模型，或者jina-colbert），让它们两两打分，重新排序。这样能把那些"看起来相关实则跑题"的片段筛出去，只把最精华的Top-5或Top-10送进生成环节。

第三步，构建结构化的Prompt模板。不要简单拼接！要给每个片段加上清晰的来源标签和时间戳，比如：

[视频画面 00:03:20] 屏幕上显示了一段Python代码，包含try-except语句。
[语音转录 00:03:22] 讲师说："这里我们一定要捕获这个KeyError，否则程序会崩溃。"
[屏幕文字 00:03:20] 代码行：except KeyError as e:

LLM一看就知道信息从哪来，互相印证还是互相矛盾，一目了然。这种结构比一团乱麻的纯文本强十倍。

最后，做动态截断。模型上下文窗口是有限的，比如8K或32K。根据重排序后的相关性分数，从高往低排，设定一个token预算上限（比如保留60%给上下文，40%留给系统提示和生成），超出的部分果断砍掉，不要心疼。把宝贵的窗口留给真正相关的片段。

小结：

跨模态融合不是简单的1+1，而是要把不同来源的"方言"，翻译成大模型能听懂的、没有冗余的"普通话"。

---

要点五：大模型生成与答案溯源——拒绝一本正经地胡说八道

点题：

视频问答系统上线后，用户最怕的不是"我不知道"，而是AI一本正经地胡说八道。明明视频里没讲的内容，它给你编得头头是道；视频里讲的是方案A，它非说成方案B，还煞有介事地给你解释原因。这一章，咱们就来给生成环节加上"紧箍咒"和"溯源链"。

痛点分析：

RAG确实能大幅降低幻觉，但它不是"零幻觉"保险。尤其是在视频场景下，上下文信息可能比文本更模糊、更碎片。新手常犯的错误，是Prompt写得太"松"，给了模型太大的发挥空间。

比如，Prompt里只写：“请根据以下内容回答问题。” 这就完了？完了。模型看到上下文里有一段关于"多线程"的讨论，用户问的是"怎么保证线程安全"，模型可能把自己预训练数据里的"volatile和synchronized"知识全抖落出来了，而视频里其实只讲了"用线程池隔离"。用户一看，这答案好详细啊，但其实一半是视频外的知识，跟讲师讲的对不上。

还有一种情况，是模型"过度推断"。视频里讲师说：“我们不推荐使用全局变量。” 用户问"视频里推荐用什么？" 模型回答：“推荐使用局部变量和依赖注入。” 后一半"依赖注入"是模型自己加的戏，视频里根本没提。这种"脑补"在视频RAG里特别常见，因为视频内容本身信息量就大，模型容易"发散思维"。

解决方案：

第一步，Prompt里必须加"紧箍咒"，而且要写得非常明确。我是这么写的：

你是一名严格的视频内容分析师。请仅基于以下标记了时间戳的视频片段回答问题。
如果视频片段中没有足够的信息来回答问题，请明确回答"根据视频内容，无法找到相关信息"。
严禁使用你自己的先验知识补充视频外的内容。

这几句话看着简单，但能把模型的"表现欲"按住一大半。你要让它明白，这不是自由发挥的创作题，而是严格基于材料的阅读理解题。

第二步，强制溯源。要求模型在生成答案时，必须引用所依据的视频片段时间戳。比如：“根据视频00:05:30处的讲解…”。这不仅提升了用户体验（用户可以点击跳转到对应位置验证），更重要的是，它让模型的生成过程"有迹可循"，不敢乱编。实现上可以在Prompt里给示例（Few-shot），告诉模型你想要的输出格式。例如：

问：视频里提到了哪些优化手段？
答：视频里提到了两种优化手段。第一，使用缓存（见00:03:15）；第二，减少数据库查询次数（见00:04:20）。

第三步，后校验（Post-hoc Verification）。生成答案后，再用一个轻量级的NLI（自然语言推断）模型，判断生成的句子是否被原始上下文所"蕴含"（entailment）。如果NLI输出的是"矛盾"或"无关"，就触发拒答或者重新检索。也可以用一个更小的LLM（比如7B的蒸馏模型）来做这个校验，成本和延迟都在可控范围内。

第四步，设置拒答兜底。哪怕检索出了上下文，但如果相似度分数普遍偏低（比如最高也就0.6），说明用户的问题可能真的不在视频范围内。这时候与其让模型硬答，不如优雅地告诉用户：“这个问题似乎没有在视频里详细讲到哦，建议你可以看看视频的第X部分，或者换个问法试试。” 真诚的"不知道"，比自信的"胡说"要专业得多。

小结：

RAG是防幻觉的盾牌，但只有加上严格的Prompt约束、溯源要求和后校验机制，这块盾牌才能真正挡住"胡说八道"的暗箭。

---

要点六：工程化部署与性能调优——从Demo到生产的最后一公里

点题：

前面五步都是在单机上跑通逻辑，但真正的考验在上线之后。用户并发提问、上传高清视频、要求秒级响应，这些才是区分"玩具"和"产品"的试金石。很多Demo在笔记本上跑得飞快，一上生产环境就趴窝，问题往往就出在这一环。

痛点分析：

新手最容易在工程化上栽的跟头，我总结为"一锅炖"。整个流程从视频上传、解析、向量化、检索到生成，全部塞在一个同步接口里。用户前端点一下"上传"，后端开始吭哧吭哧跑FFmpeg、跑Whisper、跑Embedding。一个500MB的视频，处理时间可能要十分钟，前端HTTP请求早就504超时了。用户刷新一下页面，又得重新上传，体验灾难。

还有一个性能误区，是"重复造轮子"。每次用户问一个问题，都重新去向量数据库里做全量搜索，不做缓存。如果同一个视频被一百个用户同时问"这节课讲了什么"，检索服务压力山大，向量库CPU直接飙红。

更隐蔽的是成本问题。直接调用云端的多模态大模型API做图像描述，或者每次问答都调最强的GPT-4，Demo阶段账单看着还行，一旦用户量上来，月底看到账单能让你怀疑人生。有小伙伴跟我吐槽，说上线第一周API账单就烧了五千块，全是图像描述和GPT-4的调用费。

解决方案：

首先，流水线必须异步化。视频上传后，立刻返回一个任务ID，告诉用户"正在处理中，稍后可以提问"。后端把视频解析任务扔进消息队列（Celery、RQ、或者云端的SQS/RabbitMQ），由Worker集群异步消费。解析完成后，更新数据库状态，通过WebSocket或轮询接口通知用户"视频已就绪，可以开始提问了"。这样前端永远不会超时，用户体验也流畅。

其次，预计算与缓存。热门视频或者课程类内容，在上传后就应该触发预计算，把Embedding提前生成好存进向量库。问答环节只做检索和生成，不再碰原始视频。对于高频问题，可以在向量检索层前加一层Redis缓存，缓存"查询文本 -> 召回结果"的映射。毕竟同一个班的学生问的问题都差不多，缓存命中率能高得惊人。

第三，推理加速。Embedding模型建议转成ONNX或TensorRT格式，在GPU上跑，比PyTorch原生快几倍。LLM推理端，一定要用vLLM或TGI这类推理框架，配合PagedAttention和Continuous Batching，吞吐量能提升一个数量级。如果预算有限，可以对7B或13B的模型做AWQ/GPTQ量化，显存占用减半，速度还能更快，对于视频问答这种对实时性要求不是极致的场景，完全够用。

第四，服务解耦。视频解析服务、向量检索服务、LLM生成服务，三者独立部署，独立扩缩容。解析吃CPU和GPU显存，检索吃内存和磁盘IO，LLM吃GPU算力，混在一起互相拖累。用Docker Compose或者K8s做容器化编排，哪座山唱哪首歌。

第五，成本控制。对于非核心场景，可以用小参数模型做意图识别和简单问答，只有复杂问题才路由到大模型。图像描述也可以用轻量级的VLM（比如MiniCPM-V、LLaVA-Phi3）代替超大模型，效果差不了太多，成本却能降一个数量级。

小结：

工程化不是锦上添花，而是决定你的视频RAG能不能从"玩具"变成"产品"的分水岭。Demo能跑是起点，高并发下还能稳、还能省，才是真正的技术实力。

---

写在最后

聊到这里，六个关键要点已经过了一遍。你会发现，视频RAG和传统的文本RAG相比，最大的区别就在于"多模态"和"时序"这两个词。视频不是平面的文档，它是流动的、多维的信息流。你要做的，就是帮AI把这股信息流梳理清楚，让它看得懂画面、听得懂声音、对得上时间，最后再组织成用户能听懂的人话。

这一路坑确实不少。从抽帧抽到内存爆炸，到向量维度对不上，再到时间戳对不齐导致答非所问，最后到上线就被高并发打崩——几乎每个环节我都摔过跤，也见过太多朋友在这些坑里挣扎。但好在，这些坑都是可以被填平的。你只要按照今天说的这六步走，每一步都把细节夯实，做出来的视频问答系统，绝对能从"人工智障"进化成"人工智能"。

编程这条路，从来就没有一劳永逸的银弹。新技术出来，我们都是从一脸懵逼到慢慢上手，再到最后融会贯通。视频RAG现在正是热闹的时候，多模态大模型也在快速迭代，机会很多，坑也很多。保持好奇，保持动手，别怕报错，报错才是你真正在学习的证明。

代码不会辜负每一个认真对待它的人。今天这六步你先消化着，找个视频动手试一试，咱们下回见！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》