把视频"原封不动"塞进上下文,而不是抽帧——小天 fotos 拆穿 Kimi Code 凭什么能 1:1 复刻一段动画
把视频”原封不动”塞进上下文,而不是抽帧——小天 fotos 拆穿 Kimi Code 凭什么能 1:1 复刻一段动画
这条视频的简介只有一句话最扎眼:“把视频的原始内容放入上下文,而不是抽帧。Codex 应该认真考虑改一下这个了。” 作者小天 fotos 不是在做模型测评,而是抓住了一个被几乎所有人忽略的差异——同样一段录屏丢给不同的 coding agent,有的能 1:1 复刻出可玩的游戏和带运镜的动画,有的只能做成一张张 PPT。区别不在模型多强,在于工具(harness)到底是把视频”原封不动”留在了上下文里,还是先抽成几张截图再喂进去。
这是一条 9 分半的硬核评测。下面的拆解来自双轨还原:SenseVoice 逐字稿(口播)+ 豆包视觉逐帧读屏(画面文字 / UI / 对比演示)。涉及的工具名、论文名已按画面校订。
一、先把结论摆桌上:抽帧 vs 视频常驻上下文
作者一上来就把话挑明,而且特意声明”没有碰瓷 Codex”:
在视频理解这个多模态场景,很可能你用的 coding agent 一直都是残血。
“残血”指的不是模型弱,而是工具喂给模型的信息被砍了一刀。一句话区分两条路线:
- 抽帧(frame extraction):工具读到视频,先抽出若干张静态截图,再把这几张图喂给模型。你看到的是一个个孤立的状态。
- 视频常驻上下文(video-in-context):工具把视频的原始内容(base64 chunks)直接塞进 agent 的循环里,执行任务全程都带着视频信息。模型看到的是整个过程。
作者的原话点破了要害:
动作、转场、节奏、速度、因果关系,它们都不在一张图里,而是在图和图之间。抽帧看到的是状态,视频上下文看到的是过程。
这就是为什么标题里他喊话 Codex:他是 200 刀的订阅用户,特别希望 Codex 也能真正”看懂”视频,而不是退化成抽帧。
二、他怎么发现的:四组复刻实验,一组比一组狠
作者不是空谈,他用四组实验把差异逼了出来。
实验一 · 游戏 demo 复刻。 他看到推上有人用 Higgsfield 里的 Fable 5 做的一个游戏 demo,录了屏丢给 Kimi Code,提示词就几个字:“读取这个 demo,完整复刻”。结果它真做出来了——不能说一模一样,但完全能玩。
实验二 · 功夫粒子动画。 不信邪,他又找了一个 Fable 5 实现的中国功夫粒子动画 demo,要求”1 比 1 复刻”。它不仅实现了,甚至把他录屏时不小心录进去的一个视频播放控件也一起复刻了——细节强到离谱。
实验三 · SpaceX IPO 叙事视频(关键对照组)。 这一组是用来”拷问时间维度到底重不重要”的。他拿一段经典的财经解读视频(强运镜、强叙事),分别考 Kimi Code 和 Codex,看谁能通过理解视频、再用 hyperframe 这类视频制作框架把故事重新讲出来:
- Codex 给了两次机会:第一次直接喂视频片段、还开了最高档思考,效果很差;第二次补了按时间戳对齐的字幕文件帮它理解,它依然把一段充分利用摄像机运镜的内容硬做成了 PPT,视觉呈现差一大截。
- Kimi Code 的版本:不仅更好地对齐了原始音频,还模拟出了摄像机运镜的效果,整个表达很有逻辑(当然和原视频仍有距离)。
实验四 · AE 动画复刻。 再拿一批 AE 动画测,结果一致:它不光复刻了视觉效果,连动画的节奏、转场的时机都复刻出来了。作者强调:这不是普通的低频率抽帧能稳定做到的。
四组实验指向同一个结论:涉及”动起来”的东西——交互、运镜、节奏、转场——抽帧会系统性地丢信息,而视频常驻上下文不会。
三、技术根因:视频不是”多张图”,是”时空块”
作者没停在现象,他去扒了 Kimi Code 的代码,又去读了 Moonshot 那篇 MoonViT-3D 的论文,找到了根因:
它不是简单地把视频拆成多张图,而是把连续的几帧当作一个”时空块(spatio-temporal block)“来编码。模型看到的不是孤立的截图,而是这些截图之间的变化关系。
这一句是整条视频的技术核心。把它摊开:
| 抽帧方案 | 视频常驻上下文(MoonViT-3D) | |
|---|---|---|
| 模型看到的 | 若干张孤立截图 | 连续帧压成的时空块 |
| 保留了什么 | 各个时刻的状态 | 状态 + 帧间的变化/过程 |
| 丢了什么 | 动作、运镜、节奏、转场、因果 | 几乎不丢时间维度 |
| 代价 | Token 省 | Token 贵,但信息完整 |
| 够用的场景 | 复刻静态网页/UI 交互逻辑 | 复刻动画/游戏/运镜/叙事 |
作者也客观:抽帧在很多时候确实够用——比如复刻一个网页游戏的前端界面,几张图就能推出交互逻辑。但只要任务里”时间”是主角(动画、运镜、节奏),抽帧就是残血。
而 Kimi Code 之所以能稳定做到,关键不在 K2.7 这个模型本身——作者特意验证过:官方在 K2.7 还没发布时就在强调 Kimi Code 的视频能力。真正的差异是工具这条链路:只有它明确把视频放进了上下文、放进了 agent 的循环。
四、为什么说 Codex / Claude Code 是”残血”
作者调查了所有主流 agent 的链路,结论很直接:
我调查了所有主流 agent,只有 Kimi Code 这一套链路明确把视频放进了上下文、放进了 agent 循环,所以执行任务全程都带着视频信息。而 Cloud Code(Claude Code)、Codex、OpenCode,它们当下的版本都只支持到图片这一层。一旦读取视频,就用抽帧的方式读多张图来”实现”视频理解。
更微妙的一点,他点到了 Codex 的架构软肋:Codex 的上下文是在服务端管理的,外部并不清楚它读过的图片是不是始终以原始形态(比如 base64)留在上下文里;但可以确定的是,视频类内容它肯定没有。 所以”Codex 未来会不会在这个能力上对齐”,就是他标题里抛出的那个问题。
五、被官方”宣传不到位”埋没的几个隐藏能力
作者继续扒代码,挖出几个官方没怎么宣传、但很有价值的点——他原话吐槽”官方宣传真不到位呀”:
- 支持接入其他模型。稍微改点代码,本地部署的 Qwen3 小模型(0.6B / 7B 量级)也能玩”视频常驻上下文”——本地多模态模型也能”满血”。
- 给音频类型留了接口。顺着它的思路小改一下代码,他甚至实现了用本地模型分析带音轨的视频。
- Agent Swarm 直接可用。原本只有网页版才能用的多 agent 协作(agent swarm),现在 Kimi Code 里直接支持。实际意义很大:喂两个视频可能就吃掉 40% 上下文,接下来的任务交给 swarm 子 agent 去做,主 agent 就不用触发 compact(压缩上下文)了。
- 视频入上下文其实 1 月就支持了。作者写稿时才发现,这个能力在 1 月的 Kimi CLI 版本就上线了,而他半年来毫无意识——这也是他反省的点。
一句方法论:一个第一方、还开源的 harness,其实真的值得我们更多注意力。 很多更有价值的信息,都藏在它的代码里,而不是发布会的 PPT 上。
六、他抛出的商机:剪辑叙事经验”蒸馏”成知识库
作者顺着能力推了一个落地构想(并反复强调道德与版权约束):
假设在合规、授权或开源的前提下,把一批视频作品通过视频理解蒸馏成一个”剪辑与叙事经验的知识库”。接到一个剪辑任务时,先用 AI 在这个库里检索类似案例的经验,结合脚本核查、提取出叙事 / 动画方案,最后再用 hyperframe 这样的框架快速实现动画。
这条链路跑通后,博主可能只需要构思内容本身,所有”表达”——剪辑、运镜、节奏——都能交给 agent。 他说自己已经把 Kimi Code 集成进了自己的”牛马 agent”体系,开始做可行性验证了。
值得提醒的是,作者自己也立了红线:完全不赞同用多模态模型去蒸馏其他博主的剪辑和叙事手法,他用经典视频只是为了测能力边界。他更想提醒所有博主:“视频里的叙事和剪辑技巧被 AI 实现,正在成为可能。“
七、最狠的收尾洞察:harness 是放大器,也是风向标
整条视频的”魂”在结尾这段升华:
模型厂的 harness,从来就不只是一个壳。它是模型能力的放大器,也是技术路线的风向标。
他用一个细节佐证:Kimi K2.7 Code 的高速版本可以提速 6 倍、价格 3 倍。重点不是”提速”本身,而是这个信号——那些把生产流程已经跑通的用户,对”更快地把 token 转化成成果”有了刚需,而模型厂最先感知到了,于是推出这个服务。这就是一个风向标。
由此他给出判断:
- 第三方工具还在忙着兼容各家 API、追着需求实现功能;
- 而模型厂自己的 harness,注意力已经放在了扩大能力边界上。
- 我们总在等模型变强,却常常忽略:工具,才是让模型能力真正被看到的那个窗口。
所谓商机,往深了说也不只是做几个剪辑 AI:真正的机会在于,谁最先理解模型厂的技术路线、谁最先在新能力上跑通整个工作流,谁就能在新一轮工具迭代里最早拿到红利。
八、那么,Codex 到底能不能”抄”这个功能?
这是这条视频留给所有 coding agent 用户的问题,也直接回应了它的标题。我的判断,分三层:
1. 这不是纯前端 harness 改改就完事的——它卡在模型侧。 视频常驻上下文要成立,底层模型必须原生吃”视频 token”(时空块编码),而不只是吃图片。Kimi 这条链路能成,是因为 MoonViT-3D 这个视觉编码器在模型侧就支持。Codex / Claude Code 当下只到图片层,首要瓶颈是底层 GPT / Claude 是否原生接受视频输入,不是 CLI 抽不抽帧的问题。所以”抄”的前提,是 OpenAI / Anthropic 先把原生视频能力补齐。
2. 但 harness 的工程范式完全可以学,而且 Kimi Code 开源。 “把原始媒体常驻在 agent 循环里、别预先抽帧降维""用 swarm 子 agent 扛大上下文、避免主 agent compact""给音频/本地模型留接入口”——这些是架构选择,任何 coding agent 都能借鉴,不必等模型升级。
3. 对做内容/做工具的人,真正能立刻抄的是”判断”。 不是去抢着写一个视频 agent,而是记住作者那句风向标:模型厂第一方 harness 的更新,往往比第三方早半年暴露未来的能力方向。 谁盯紧第一方 harness 的代码、谁先在新能力上把工作流跑通,谁就吃到红利。
一句话回答标题:Codex 抄得了”把视频留在上下文”的工程思路,但要真做到 Kimi Code 那种 1:1 复刻动画,得等它的底层模型先长出原生视频的眼睛。
九、一句话沉淀
在多模态时代,决定一个 coding agent 上限的,常常不是模型参数,而是它的 harness 愿不愿意把”原始信息”原封不动地留在上下文里。抽帧省 token,但丢掉了”动起来”的一切;视频常驻上下文贵,却换回了对过程、节奏、运镜的真正理解。盯紧模型厂的第一方 harness,就是盯紧下一轮红利的风向标。
附:原始素材(双轨)
- 作者:小天 fotos
- 时长:约 9 分 33 秒
- 简介原文:
Codex 要是抄一下这个功能就好了！把视频的原始内容放入上下文,而不是抽帧。Codex 应该认真考虑改一下这个了。 #ai新星计划 #VibeCoding大赏 #抖音前沿科技首发计划 #Codex #hyperframe - 逐字稿:SenseVoice 转写(13 段,约 3600 字),工具名以画面校订为准。
- 画面:豆包视觉逐帧读屏——双显示器口播 + 游戏/动画 demo “参考 vs 复刻”分屏 + MoonViT-3D 时空块编码动态图 + 剪辑知识库流程图。
- 涉及关键词:Kimi CLI / Kimi Code、K2.7、MoonViT-3D、抽帧 vs 视频上下文、时空块、Agent Swarm、hyperframe、Fable 5(Higgsfield)、Codex / Claude Code。