WEBVTT
Kind: captions
Language: zh

00:00:00.033 --> 00:00:02.833
朋友们我真的没有碰瓷Codex的意思

00:00:03.066 --> 00:00:05.750
但是在视频理解这个多模态场景

00:00:05.900 --> 00:00:07.950
很可能你用的Coding Agent

00:00:07.950 --> 00:00:09.100
一直都是残血

00:00:09.433 --> 00:00:10.750
那谁不是残血

00:00:11.066 --> 00:00:13.783
所有搭配了Kimi Code的多模态模型

00:00:13.783 --> 00:00:14.700
都不是残血

00:00:14.700 --> 00:00:16.150
我说的是所有模型

00:00:16.350 --> 00:00:18.783
我知道Kimi刚发的K2.7很强

00:00:18.983 --> 00:00:21.466
但本期视频不是模型测评

00:00:21.500 --> 00:00:24.150
请跟我把注意力都放在Kimi Code上

00:00:24.350 --> 00:00:26.233
我要分享一个新的发现

00:00:26.383 --> 00:00:27.583
在多模态领域

00:00:27.583 --> 00:00:29.900
它到底是补齐了什么样的能力

00:00:30.066 --> 00:00:32.750
以及它可能带来的一个重大商机

00:00:32.900 --> 00:00:33.783
视频很长

00:00:33.783 --> 00:00:35.033
但内容很好理解

00:00:35.033 --> 00:00:35.833
点个收藏

00:00:35.833 --> 00:00:36.633
我们继续

00:00:37.150 --> 00:00:38.266
事情是这样子的

00:00:38.433 --> 00:00:38.700
最近

00:00:38.700 --> 00:00:41.583
不是Kimi推出了Kimi Code这个工具吗

00:00:41.633 --> 00:00:42.350
它可以看作

00:00:42.350 --> 00:00:45.500
是对原先Kimi CLI的一次重构和升级

00:00:45.750 --> 00:00:47.783
而且官方在浓墨重笔的强调

00:00:47.783 --> 00:00:49.233
它的视频理解能力

00:00:49.300 --> 00:00:51.833
最近不是Anthropic的Fable5也出了

00:00:51.900 --> 00:00:54.700
随即Kimi K2.7 Code的这个模型也发布了

00:00:54.750 --> 00:00:56.266
那我就想着我也试试吧

00:00:56.266 --> 00:00:58.500
拿它来和Fable5比一比

00:00:58.500 --> 00:00:59.500
看看谁厉害

00:00:59.666 --> 00:01:00.950
我看到一位推友发的

00:01:00.950 --> 00:01:04.266
用higgsfield里的Fable5做的游戏的demo

00:01:04.433 --> 00:01:05.950
于是呢我就录了个屏

00:01:06.150 --> 00:01:08.433
把这个视频丢给了Kimi Code

00:01:08.583 --> 00:01:11.500
我的提示词就几个字读取这个demo

00:01:11.500 --> 00:01:12.550
完整复刻它

00:01:13.033 --> 00:01:14.750
它居然就做出来了

00:01:14.783 --> 00:01:15.983
不能说完全一样

00:01:15.983 --> 00:01:16.983
但完全能玩

00:01:17.266 --> 00:01:18.183
我不信邪啊

00:01:18.183 --> 00:01:19.833
我又找了一个Fable5实现的

00:01:19.833 --> 00:01:21.833
中国功夫的粒子动画的Demo

00:01:21.866 --> 00:01:24.500
我的提示词是让它1:1的复刻

00:01:24.950 --> 00:01:26.350
它不仅实现了

00:01:26.350 --> 00:01:28.033
甚至还把我录屏时

00:01:28.033 --> 00:01:30.350
不小心录进去的视频播放控件

00:01:30.350 --> 00:01:31.866
也复刻了

00:01:31.866 --> 00:01:33.750
我后来还测试了很多Demo

00:01:33.750 --> 00:01:35.033
全部都复刻出来了

00:01:35.150 --> 00:01:37.300
可是官方在发布Kimi Code的时候

00:01:37.300 --> 00:01:38.950
他就在强调视频能力的

00:01:38.950 --> 00:01:42.233
但那个时候K2.7还没发布啊

00:01:42.233 --> 00:01:43.550
难道说这个能力

00:01:43.550 --> 00:01:46.066
关键在于Kimi Code这个工具本身

00:01:46.300 --> 00:01:47.466
那么带着这个疑问

00:01:47.466 --> 00:01:49.433
我就开始分析Kimi Code的代码

00:01:49.433 --> 00:01:50.900
以及主流的Coding Agent

00:01:50.900 --> 00:01:52.700
我想看看到底有什么区别

00:01:53.066 --> 00:01:54.750
欸还真让我猜中了

00:01:54.866 --> 00:01:57.300
我调查了所有主流Agent里

00:01:57.383 --> 00:01:58.633
只有Kimi Code

00:01:58.633 --> 00:01:59.900
它的这一套链路

00:01:59.900 --> 00:02:02.583
明确的把视频放进了上下文

00:02:02.583 --> 00:02:04.300
放进了Agent循环中

00:02:04.583 --> 00:02:06.266
所以它在执行任务的过程中

00:02:06.266 --> 00:02:08.033
始终都会有视频的信息

00:02:08.066 --> 00:02:11.233
那我们用ClaudeCode或者是Codex OpenCode

00:02:11.383 --> 00:02:12.700
它们当下的版本

00:02:12.700 --> 00:02:14.900
都只支持到了图片这一层

00:02:15.183 --> 00:02:16.950
一旦这类工具读取了视频

00:02:16.950 --> 00:02:18.866
他们都会用抽帧的方式

00:02:18.866 --> 00:02:19.983
来读许多张图

00:02:19.983 --> 00:02:21.383
来实现视频理解

00:02:21.383 --> 00:02:22.550
在很多时候

00:02:22.550 --> 00:02:23.866
这个确实也够用了

00:02:23.866 --> 00:02:25.700
比如说你复刻一个网页游戏

00:02:25.750 --> 00:02:26.700
通过几张图(关键帧）

00:02:26.700 --> 00:02:28.066
你就能理解出整个游戏

00:02:28.066 --> 00:02:30.066
或者是前端界面的交互逻辑

00:02:30.633 --> 00:02:31.550
但是我要说

00:02:31.550 --> 00:02:33.950
抽帧理解视频其实是残血的

00:02:34.150 --> 00:02:36.033
因为Kimi Code的代码告诉我

00:02:36.033 --> 00:02:38.233
视频它不是多张图

00:02:39.183 --> 00:02:40.500
我恍然大悟啊

00:02:40.500 --> 00:02:41.433
我仔细分析了Kimi在

00:02:41.433 --> 00:02:44.883
《Kimi K2.5: Visual Agentic Intelligence》这篇论文的描述

00:02:44.883 --> 00:02:45.483
我得知了

00:02:45.483 --> 00:02:48.466
它不是简单的把视频拆成多张图的

00:02:48.583 --> 00:02:49.866
它是把连续的几帧

00:02:49.866 --> 00:02:51.900
当做一个时空块来编码

00:02:51.950 --> 00:02:52.383
也就是说

00:02:52.383 --> 00:02:54.300
模型看到的不是孤立的截图

00:02:54.300 --> 00:02:56.500
而是这些截图之间的变化关系

00:02:56.633 --> 00:02:57.666
这个就很关键

00:02:57.666 --> 00:02:59.900
因为视频里的动作转场节奏

00:02:59.900 --> 00:03:01.033
速度因果关系

00:03:01.033 --> 00:03:02.633
它都不在一张图里

00:03:02.766 --> 00:03:04.433
而在图和图之间

00:03:04.583 --> 00:03:05.500
那抽帧的方案

00:03:05.500 --> 00:03:07.300
你看到只是一个状态

00:03:07.383 --> 00:03:07.550
但视频的上下文看到的是整个的过程

00:03:07.550 --> 00:03:10.383
但视频的上下文看到的是整个的过程

00:03:10.783 --> 00:03:11.550
这就是为什么说

00:03:11.550 --> 00:03:13.266
如果你使用的是Claude Code这种

00:03:13.266 --> 00:03:15.783
只是通过抽帧方式的Coding Agent

00:03:15.783 --> 00:03:17.550
用它来使用K2.7

00:03:17.550 --> 00:03:18.583
那这个视频任务里

00:03:18.583 --> 00:03:21.033
就会少掉一部分时间维度的信息

00:03:21.033 --> 00:03:22.750
因为你把视频拆成帧了

00:03:22.950 --> 00:03:25.183
帧和帧之间的变化关系就会失真

00:03:25.183 --> 00:03:26.183
就会丢失

00:03:26.950 --> 00:03:29.066
那时间这个信息就这么重要吗

00:03:29.100 --> 00:03:29.983
通过多张图

00:03:29.983 --> 00:03:32.350
难道不能推理出前后的逻辑吗

00:03:32.433 --> 00:03:33.983
于是我又做了一个实验

00:03:34.300 --> 00:03:36.266
我有一位很喜欢的财经类博主

00:03:36.266 --> 00:03:39.466
他前年发布了一段对SpaceX IPO的解读

00:03:39.500 --> 00:03:41.266
哇那段桥的故事

00:03:41.300 --> 00:03:43.833
无论是叙事逻辑还是动画展示

00:03:43.866 --> 00:03:45.266
都堪称是经典

00:03:45.466 --> 00:03:47.433
那我用这段做了一个小的测试

00:03:47.433 --> 00:03:49.983
我考验了Kimi Code和Codex

00:03:50.066 --> 00:03:51.583
能不能通过理解视频

00:03:51.583 --> 00:03:54.300
再通过HyperFrame这种视频制作工具

00:03:54.300 --> 00:03:56.300
完整的把这个故事讲出来

00:03:56.750 --> 00:03:58.266
但是我要先叠个厚厚的甲

00:03:58.266 --> 00:03:59.066
声明一下

00:03:59.066 --> 00:04:01.633
我只是为了测试Harness的能力边界

00:04:01.633 --> 00:04:03.183
所以才用了这段做测试

00:04:03.266 --> 00:04:03.633
同时

00:04:03.633 --> 00:04:05.866
我也完全不赞同用多模态模型

00:04:05.866 --> 00:04:08.100
蒸馏其他视频博主的剪辑

00:04:08.100 --> 00:04:09.266
和叙事手法

00:04:09.300 --> 00:04:09.700
而且

00:04:09.700 --> 00:04:11.833
我更想通过这个视频提醒各位博主

00:04:12.183 --> 00:04:14.150
视频里的叙事和剪辑技巧

00:04:14.150 --> 00:04:16.266
被AI实现正在成为可能

00:04:16.266 --> 00:04:17.500
实验的结果是这样子

00:04:17.500 --> 00:04:19.433
我给了Codex两次机会

00:04:19.433 --> 00:04:21.100
第一次给它视频片段

00:04:21.100 --> 00:04:22.033
让它去实现

00:04:22.066 --> 00:04:23.950
我还开了最高档的思考

00:04:24.266 --> 00:04:25.633
可他完成的效果很差

00:04:25.633 --> 00:04:25.983
我怀疑

00:04:25.983 --> 00:04:28.866
他是不是还没法从截图中找到逻辑

00:04:28.983 --> 00:04:31.033
第二次我给他提供了完整的

00:04:31.033 --> 00:04:33.750
根据时间戳对齐的字幕文件

00:04:33.750 --> 00:04:35.100
帮他来理解上下文

00:04:35.483 --> 00:04:36.750
可他依然是把一段

00:04:36.750 --> 00:04:38.866
充分利用摄像机运镜的效

00:04:38.866 --> 00:04:41.150
果硬生生是给做成了PPT

00:04:41.500 --> 00:04:44.183
那整个视觉的呈现效果也差了很多

00:04:44.666 --> 00:04:46.550
但是Kimi Code的版本就不一样了

00:04:46.550 --> 00:04:47.900
让人十分的意外

00:04:48.033 --> 00:04:50.783
它不仅更好的对齐了原始的音频

00:04:50.833 --> 00:04:53.266
还模拟出了摄像机运镜的效果

00:04:53.433 --> 00:04:55.633
哇那整个表达是十分有逻辑的

00:04:55.750 --> 00:04:56.183
当然了

00:04:56.183 --> 00:04:58.500
和原视频还是有很大距离的

00:04:58.500 --> 00:05:00.433
我建议大家可以去找一下原视频

00:05:00.783 --> 00:05:03.466
但是如果把原始视频和成品

00:05:03.500 --> 00:05:04.783
都交给Kimi Code

00:05:04.950 --> 00:05:07.150
再让它一次读入两个视频

00:05:07.150 --> 00:05:09.633
并且对不足的方向进行精修

00:05:09.633 --> 00:05:10.700
再迭代个几轮

00:05:10.700 --> 00:05:12.466
我相信结果会越来越好

00:05:12.583 --> 00:05:14.666
而且同时读两个视频的方式

00:05:14.666 --> 00:05:15.833
只有它能支持

00:05:16.183 --> 00:05:17.950
这个实验让我是有些惊讶

00:05:17.950 --> 00:05:19.500
但是也在意料之中

00:05:19.866 --> 00:05:21.750
因为脱离了软件开发场景

00:05:21.750 --> 00:05:24.150
缺少了帧与帧之间的时间关系

00:05:24.383 --> 00:05:26.150
Codex是很难拿出惊艳的

00:05:26.150 --> 00:05:27.550
成果 我知道

00:05:27.550 --> 00:05:29.983
Codex的上下文是在服务端管理的

00:05:30.100 --> 00:05:32.433
所以我们并不清楚他读过的图片

00:05:32.500 --> 00:05:34.500
是不是始终以原始的形态

00:05:34.500 --> 00:05:35.266
留在上下文里

00:05:35.266 --> 00:05:38.150
比如说base64 编码就是一种原始形态

00:05:38.350 --> 00:05:39.383
但我十分确定的是

00:05:39.383 --> 00:05:41.433
视频类的内容是肯定没有的

00:05:41.583 --> 00:05:44.266
所以Codex未来会不会在这个能力上

00:05:44.266 --> 00:05:45.583
对齐Kimi Code呢

00:05:45.666 --> 00:05:47.583
这就是我标题里提出的问题

00:05:47.783 --> 00:05:48.950
我希望他会啊

00:05:48.950 --> 00:05:50.100
我是200刀的订阅

00:05:50.100 --> 00:05:51.950
我特别希望他也能理解视频

00:05:51.983 --> 00:05:53.983
另外在做了这个测试之后

00:05:53.983 --> 00:05:56.500
我又拿了一些AE动画在做测试

00:05:56.750 --> 00:05:57.900
结果和之前一样

00:05:57.900 --> 00:05:58.100
它

00:05:58.100 --> 00:06:00.583
不但完整的复刻了动画的视觉效果

00:06:00.783 --> 00:06:01.866
连动画的节奏

00:06:01.866 --> 00:06:03.833
转场的时机都复刻出来了

00:06:03.983 --> 00:06:04.300
注意

00:06:04.300 --> 00:06:06.866
这不是普通的低频率抽帧的方案

00:06:06.866 --> 00:06:08.983
能稳定做到的只有Kimi Code的这条

00:06:08.983 --> 00:06:10.750
链路上时间这个维度的信息

00:06:10.750 --> 00:06:12.150
才能被保留的更多

00:06:12.233 --> 00:06:15.066
好那我想说的商机到底是什么

00:06:15.666 --> 00:06:16.466
咱们假设

00:06:16.466 --> 00:06:19.266
如果在符合道德和版权的约束下

00:06:19.266 --> 00:06:20.700
我们把一批经过授权

00:06:20.700 --> 00:06:22.233
或者开源的视频作品

00:06:22.300 --> 00:06:23.983
通过视频理解的方式

00:06:24.100 --> 00:06:25.383
来蒸馏成一个

00:06:25.466 --> 00:06:27.983
剪辑和叙事经验的知识库

00:06:28.666 --> 00:06:30.066
如果你接到一个剪辑任务时

00:06:30.066 --> 00:06:31.066
你先用Agent呢

00:06:31.066 --> 00:06:31.900
在这个知识库里

00:06:31.900 --> 00:06:33.666
检索类似的案例的经验

00:06:33.833 --> 00:06:34.750
再结合脚本

00:06:34.750 --> 00:06:37.550
来核查提取出叙事动画的方案

00:06:37.766 --> 00:06:40.033
最后再通过HyperFrame这样的框架

00:06:40.033 --> 00:06:41.550
来快速实现动画

00:06:41.750 --> 00:06:42.550
哇那以后

00:06:42.550 --> 00:06:44.750
博主是不是只需要构思内容本身了

00:06:44.750 --> 00:06:47.100
而所有的表达全部都可以交给Agent

00:06:47.183 --> 00:06:49.350
你们说这个库如果能做成

00:06:49.350 --> 00:06:50.750
会不会成为一个商机呢

00:06:50.933 --> 00:06:52.700
反正我现在已经把Kimi Code

00:06:52.700 --> 00:06:54.866
集成到了我的牛马Agent的体系里了

00:06:54.866 --> 00:06:56.266
我已经开始用这种能力

00:06:56.266 --> 00:06:57.783
去做可行性的验证了

00:06:58.100 --> 00:06:59.550
OK商机说到这里

00:06:59.550 --> 00:07:00.583
咱们回到现实

00:07:00.666 --> 00:07:02.300
我对Kimi Code的代码库

00:07:02.300 --> 00:07:03.833
又做了进一步的研究

00:07:03.833 --> 00:07:06.466
我发现其实还有很多值得说的内容

00:07:06.633 --> 00:07:09.033
比如说它支持其他模型的接入

00:07:09.383 --> 00:07:10.033
甚至是

00:07:10.033 --> 00:07:12.900
如果你稍微对代码做一些修改的话

00:07:13.100 --> 00:07:15.466
本地部署的Qwen3.6 27B

00:07:15.466 --> 00:07:17.433
也能实现视频常驻

00:07:17.433 --> 00:07:18.833
上下文的这种玩法

00:07:18.950 --> 00:07:21.466
那本地多模态模型现在也可以满血

00:07:21.933 --> 00:07:22.750
我还发现啊

00:07:22.750 --> 00:07:25.500
他甚至对音频类型也留了接口

00:07:25.750 --> 00:07:26.700
顺着他的思路

00:07:26.700 --> 00:07:27.900
我稍微对他的代码

00:07:27.900 --> 00:07:29.750
做了一点点的小改动

00:07:29.750 --> 00:07:31.866
我甚至实现了能用本地的模型

00:07:31.866 --> 00:07:33.366
分析带音轨的视频

00:07:33.466 --> 00:07:34.466
另外我还发现

00:07:34.466 --> 00:07:37.033
原本在网页版才能用的Agent Swarm

00:07:37.033 --> 00:07:39.350
现在在Kimi Code里就直接就支持

00:07:39.350 --> 00:07:39.900
了

00:07:39.900 --> 00:07:41.433
比如就拿我们刚才这个场景举例

00:07:41.433 --> 00:07:43.466
我给Kimi Code两个视频让它分析

00:07:43.583 --> 00:07:43.983
这个时候

00:07:43.983 --> 00:07:46.483
可能就用掉了40%的上下文了

00:07:46.483 --> 00:07:47.633
但接下来的任务

00:07:47.633 --> 00:07:49.900
我就可以启动Agent Swarm来实现

00:07:50.033 --> 00:07:50.583
主Agent呢

00:07:50.583 --> 00:07:52.350
再也不用触发Compact

00:07:52.433 --> 00:07:53.350
所以总的来说

00:07:53.350 --> 00:07:55.100
很多更有价值的信息

00:07:55.100 --> 00:07:56.633
其实都在它的代码里

00:07:57.033 --> 00:07:58.750
官方宣传真不到位啊

00:07:59.266 --> 00:08:01.633
一个第一方还是开源的Harness

00:08:01.633 --> 00:08:03.900
其实真的值得我们投入更多注意力

00:08:04.100 --> 00:08:05.583
那在写这篇稿子的时候

00:08:05.583 --> 00:08:06.383
我还有个发现

00:08:06.383 --> 00:08:07.866
让我稍微有点失落

00:08:08.100 --> 00:08:09.633
把视频放入上下文

00:08:09.633 --> 00:08:11.950
其实是在1月的Kimi CLI版本时

00:08:11.950 --> 00:08:12.833
就支持了

00:08:12.983 --> 00:08:14.783
而我这半年却毫无意识

00:08:15.100 --> 00:08:16.666
这就是我正在反省的点

00:08:16.666 --> 00:08:18.583
也是想在结尾和大家共勉的

00:08:18.900 --> 00:08:20.066
模型厂的Harness

00:08:20.066 --> 00:08:21.983
它从来就不只是一个壳

00:08:22.066 --> 00:08:23.900
它是模型能力的放大器

00:08:23.950 --> 00:08:25.950
也是技术路线的风向标

00:08:26.150 --> 00:08:27.100
就拿我刚刚解锁的

00:08:27.100 --> 00:08:29.666
Kimi K2.7 Code 的高速版本来说吧

00:08:30.150 --> 00:08:32.833
它是可以提高6倍速度 3倍价格

00:08:33.183 --> 00:08:34.100
但这不是重点

00:08:34.100 --> 00:08:35.583
它不是提速那么简单

00:08:35.950 --> 00:08:37.100
它很可能意味着

00:08:37.100 --> 00:08:39.666
那些生产流程已经跑通了的用户

00:08:39.750 --> 00:08:40.750
对更高速的

00:08:40.750 --> 00:08:42.983
把TOKEN转化成成果这件事

00:08:43.066 --> 00:08:44.266
有了一种刚需

00:08:44.483 --> 00:08:45.466
而这件事

00:08:45.466 --> 00:08:47.383
模型厂商最先感知到了

00:08:47.383 --> 00:08:49.150
所以他们就推出了这个服务

00:08:49.233 --> 00:08:50.700
那这就是一个风向标

00:08:51.183 --> 00:08:51.750
现在

00:08:51.750 --> 00:08:54.233
第三方工具都在忙着兼容各家的API

00:08:54.233 --> 00:08:55.500
忙着实现各种功能

00:08:55.500 --> 00:08:56.500
跟上需求

00:08:56.633 --> 00:08:58.183
而模型厂自己的Harness

00:08:58.183 --> 00:08:59.066
已经把注意力

00:08:59.066 --> 00:09:01.833
放在了扩大模型能力的边界上了

00:09:02.100 --> 00:09:04.183
我们总是在等模型变强

00:09:04.233 --> 00:09:05.383
却常常忽略

00:09:05.433 --> 00:09:06.266
其实工具

00:09:06.266 --> 00:09:07.666
才是那个让模型能力

00:09:07.666 --> 00:09:09.266
真正被看到的窗口

00:09:09.550 --> 00:09:11.383
而那个所谓的商机咱

00:09:11.383 --> 00:09:12.500
往深了说

00:09:12.583 --> 00:09:14.633
也不只是做几个视频剪辑

00:09:14.633 --> 00:09:15.750
Agent的那么简单

00:09:16.050 --> 00:09:17.183
真正的机会在于

00:09:17.183 --> 00:09:19.700
谁最先理解模型厂的技术路线

00:09:19.750 --> 00:09:22.433
谁最先在新能力上跑通整个工作流

00:09:22.433 --> 00:09:24.633
谁就能在新一轮的模型和工具的迭代里

00:09:24.700 --> 00:09:25.950
最早拿到红利

00:09:26.500 --> 00:09:28.783
希望今天的视频能启发到大家

00:09:28.900 --> 00:09:30.383
咱们必须得动起来了

00:09:30.550 --> 00:09:32.700
好了以上就是本期的全部内容了

00:09:32.700 --> 00:09:33.450
谢谢大家