20260622-09 | Codex要是抄一下Kimi Code这个功能就好了!
來源:Youtube | 建立:2026-06-22T15:24:41 | HTML:2026-06-22T15:26:35
開啟原始影片 note.md transcript.txt transcript.vtt

影片筆記:Codex要是抄一下Kimi Code这个功能就好了!

YouTube 影片框會固定在左上方;點擊右側逐字稿時間戳可跳到對應時間。

一句話總結

影片探討了 Kimi Code 在多模態視頻理解上的技術優勢,指出其通過將視頻作為「時空塊」編碼而非僅抽幀,能更好地保留時間維度信息(如節奏、因果關係),從而優於僅支持圖片層級的 Codex 和 Claude Code。作者建議開發者關注模型廠推出的工具鏈(Harness)與新服務,以搶先獲取技術紅利。

核心重點

視頻理解機制差異

實測對比結果

潛在商業機會

行業洞察與建議

詳細大綱

一、 核心發現:Kimi Code 的視頻理解機制

二、 實測對比:Kimi Code vs. Codex

三、 潛在商業機會:AI 輔助視頻製作工作流

Agent 在知識庫中檢索類似案例經驗。

結合腳本,核查提取敘事與動畫方案。

通過 HyperFrame 等框架快速實現動畫。

四、 Kimi Code 的其他技術特性與擴展

五、 行業洞察與建議

工具 / 模型 / 名詞整理

操作流程整理

視頻理解與復刻

精修迭代

自動化視頻製作工作流

值得注意的限制或風險

逐字稿辨識疑點

可延伸追問

Kimi Code 的「時空塊」編碼具體技術實現細節為何?與傳統抽幀方法在計算資源消耗上有何差異?

如何確保在構建「剪輯與敘事經驗知識庫」時,嚴格遵守版權與道德約束?

Kimi K2.7 Code 的高速版(6倍速度,3倍價格)具體適用於哪些場景?其性價比如何評估?

Agent Swarm 在 Kimi Code 中的具體應用場景有哪些?除了視頻製作,是否適用於其他多模態任務?

本地部署的 Qwen3.6 27B 實現視頻駐留上下文的功能,對硬件配置有何要求?

逐字稿時間軸

右側可一路往下捲;左側影片框會固定。點擊時間戳會讓左側影片跳到對應秒數。

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: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:33.783 → 00:00:35.033
但内容很好理解
00:00:37.150 → 00:00:38.266
事情是这样子的
00:00:38.700 → 00:00:41.583
不是Kimi推出了Kimi Code这个工具吗
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: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:13.033 → 00:01:14.750
它居然就做出来了
00:01:14.783 → 00:01:15.983
不能说完全一样
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: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: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: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: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:45.483 → 00:02:48.466
它不是简单的把视频拆成多张图的
00:02:48.583 → 00:02:49.866
它是把连续的几帧
00:02:49.866 → 00:02:51.900
当做一个时空块来编码
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:26.950 → 00:03:29.066
那时间这个信息就这么重要吗
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:59.066 → 00:04:01.633
我只是为了测试Harness的能力边界
00:04:01.633 → 00:04:03.183
所以才用了这段做测试
00:04:03.633 → 00:04:05.866
我也完全不赞同用多模态模型
00:04:05.866 → 00:04:08.100
蒸馏其他视频博主的剪辑
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:22.066 → 00:04:23.950
我还开了最高档的思考
00:04:24.266 → 00:04:25.633
可他完成的效果很差
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: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: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:58.100 → 00:06:00.583
不但完整的复刻了动画的视觉效果
00:06:00.783 → 00:06:01.866
连动画的节奏
00:06:01.866 → 00:06:03.833
转场的时机都复刻出来了
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: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: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: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: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: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.900 → 00:07:41.433
比如就拿我们刚才这个场景举例
00:07:41.433 → 00:07:43.466
我给Kimi Code两个视频让它分析
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.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: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:40.750 → 00:08:42.983
把TOKEN转化成成果这件事
00:08:43.066 → 00:08:44.266
有了一种刚需
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.750 → 00:08:54.233
第三方工具都在忙着兼容各家的API
00:08:54.233 → 00:08:55.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:06.266 → 00:09:07.666
才是那个让模型能力
00:09:07.666 → 00:09:09.266
真正被看到的窗口
00:09:09.550 → 00:09:11.383
而那个所谓的商机咱
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
好了以上就是本期的全部内容了