最近我在继续完善一个 视频解析插件。
它要解决的问题其实很直接：很多时候，我们把一个视频链接丢给 Bot，希望它“看看这个视频怎么样”，但大多数 Bot 实际上只是在看标题、简介，或者机械地总结一下网页文本。这样得到的结果，往往并不是真正基于视频内容本身的判断。
所以，这个插件想做的事，不是“假装理解视频”，而是尽量让 Bot 真的基于视频内容来回答问题。
为什么要做这个
最典型的场景是这样的：
- 用户发一个视频链接
- Bot 先去解析这个视频
- 用户继续追问：
- “你觉得这个怎么样？”
- “这个视频说得对吗？”
- “适合买吗？”
- “它和上一个比哪个好？”
问题就在这里。
如果 Bot 只做了一次首轮总结，而没有把视频内容真正放进后续上下文，那么它在第二轮、第三轮追问时，很容易答偏，甚至变成只是在续聊自己上一轮生成的总结，而不是继续围绕视频本身回答。
所以这个插件的核心目标，不只是“总结视频”，而是：
- 提取视频内容
- 保存最近一次视频上下文
- 在后续追问时自动承接
- 让 Bot 能围绕“刚才那个视频”继续聊下去
插件现在在做什么
目前插件主要围绕这几个方向工作。
1. 自动识别视频链接
用户发出视频链接后，插件会自动识别并进入处理流程，而不需要每次都手动下特定命令。
2. 提取视频基础信息
包括：
- 标题
- 时长
- 链接来源
- 元信息
3. 根据模式做内容解析
在支持视觉能力的情况下，插件会结合关键帧做分析；在普通模式下，也会尽量生成一份更客观的内容底稿，避免只输出一段风格化总结。
4. 缓存最近视频上下文
这是这次优化里最关键的一部分。
插件不再把视频解析结果当成“一次性回复”就结束，而是会缓存最近一次视频的上下文，包括：
- 客观底稿
- 最终总结
- 基础信息
- 对应会话范围
这样当用户后面继续问：
- “这个怎么样？”
- “那它值不值得买？”
- “你觉得他说得靠谱吗？”
Bot 就能优先基于刚才解析过的视频内容继续回答，而不是脱离上下文重新瞎猜。
为什么要分“客观底稿”和“最终总结”
这是我这次比较看重的一点。
如果只保存最终总结，后续追问时很容易变成：Bot 继续围绕自己上一轮写出来的那段话打转。
但视频本身的信息，其实应该有两个层次。
客观底稿
尽量保留视频中可提取的事实、观点、结构、重点内容。这部分更适合做后续追问时的“真实上下文”。
最终总结
这是给用户第一眼阅读的结果，允许更自然、更口语化一些。它更适合展示，但不一定适合作为后续连续对话的唯一依据。
所以现在的设计思路是：
- 追问优先注入客观底稿
- 最终总结只作为辅助参考
这样 Bot 的后续回答会更稳，也更接近“确实看过视频”的感觉。
我不想做成死板分类器
一开始也想过，要不要把视频强行分类成：
- 教程类
- 测评类
- 做饭类
- 资讯类
然后每种类型走不同 prompt。
但后来还是觉得，这样太死了。
真实对话里，用户不会先告诉 Bot：“这是一个测评视频，请按测评规则回答。”
用户更常见的表达是：
- “你看看这个”
- “这个咋样”
- “他说得对不对”
- “这个能买吗”
所以现在更偏向一种通用会话记忆的做法：
- 先解析视频
- 缓存最近视频上下文
- 识别后续是否是指代追问
- 自动把视频内容接进后续回答
这样更符合真实聊天习惯，也更自然。
这个插件真正想要的效果
我真正想做的，不是一个“会总结视频”的工具插件，而是一个能让 Bot 在群聊和私聊里都更像真正看完内容后再说话的能力层。
用户发一个视频链接，不应该只得到一段孤立的总结；更理想的状态应该是：
- 第一次，Bot 看视频并给出总结
- 第二次，Bot 能知道“你问的是刚才那个视频”
- 第三次，Bot 还能继续围绕那个视频延伸讨论
只有这样，视频解析才不是一次性的，而是真的融入对话上下文。
目前还在继续完善
现在这套逻辑已经在现有插件里持续增量优化中，方向也基本确定了：
- 不改 AstrBot 核心
- 不另起一套系统
- 继续在现有插件内把上下文承接做好
- 让“发视频 → 解析 → 追问 → 连续回答”这一整套体验更稳定
接下来还会继续处理一些细节问题，比如：
- 追问识别过宽或过窄
- 不同模型返回格式不一致时的兼容
- 普通模式下底稿提炼的稳定性
- 群聊场景下最近视频上下文的作用范围
最后
这个插件现在还在收尾和打磨阶段，等整理好文档和说明，我会尽快把它发到 GitHub。
马上做好，发 GitHub。
部分信息可能已经过时