和四家机构同时押注的AI Lab聊聊：AI应用公司，为啥要做后训练？

去年夏天，22岁的杨博麟刚进剑桥没多久，就把学退了。

杨博麟生于2003年，16 岁开始创业，做过出海和营销，好几个项目都从零做到过数千万营收，还完成过一次退出。

这次来剑桥，他本来计划完成硕士课程。但2025年多模态和 Agent 迅速迭代，大量创业者涌现。已经习惯创业的杨博麟，又坐不住了。

于是，他卖掉上一家公司的股权，又找到毕业于帝国理工、在亚马逊研究 AI 的 Derek，成立了一家名为 SigmaZ 的公司，做下一代交互界面。

故事讲到这里，是上个版本 AI 应用创业者的典型路线。

没错，和很多2024-2025年的AI创业公司一样，成立几个月后，SigmaZ 的第一个产品 Cuflow 就上线了。

这是一款 AI 教育产品。用户上传 PPT、PDF 或其他资料，它能用代码生成一段教学视频。据称，这款产品上线一两个月后，获得了超过 2000 万次海外曝光。

但与此同时，SigmaZ 迎来了转折点。

杨博麟和 Derek 看到，Cuflow 的用户会拿它做营销、游戏讲解、博客内容，却不怎么学习。他们还发现，那时的 Cuflow 没有实时对话生成内容的能力，用户却不自觉地开始在产品内尝试和 AI 对话、提问。

这让他们意识到，下一代交互页面应该不止有多模态，还需要实时互动。

这个洞察，让 SigmaZ 决定做后训练，准备训一个能够用代码生成实时互动内容的模型。

一家 AI 应用公司开始走向后训练，“进化”成为前沿实验室的故事，去年还不多见，今年已经成为一种趋势。

这种现象的支持者认为，当应用跑出了场景，产生降低成本的需求，创业公司希望独立训练更懂场景的模型，非常合理。质疑者也很犀利，认为这只是 AI 应用公司活不下去，新换的一套融资说辞。

SigmaZ 的后训练路线，是基于Google、字节等公司的 DLM （扩散语言预训练模型），再加上自进化系统，训出能用代码生产实时互动内容的模型。

DLM、自进化、实时互动、后训练...当这些词在一家公司的战略方向里一起出现，我问杨博麟和 Derek：为什么不能直接用已经成熟的 LLM 直接用代码生成内容？为什么不能用视频生成模型直接做互动视频 —— 正如很多公司正在尝试的那样？

总之，为什么一定要放弃市场上已有的模型，自己做后训练？

他们告诉我，大语言模型可以用代码生成内容，但做不到实时。视频生成模型可以做出精致画面，但难以保证生成的内容准确、符合用户需求。搭建自进化系统，也是为了及时提升实时互动的效果。

说到底，DLM+自进化，是他们认为做实时互动内容最靠谱的方式。而且 SigmaZ 看到了需求，有用户，有技术 Sense，也有一些资金 —— 之前完成了蓝驰、云启、德迅、小小基金等机构的融资，没有自己不做这件事的理由。

这件事目前已经初见成果。

我了解到，SigmaZ 的模型已经搭建好数据和效果评测的管线，正在和内测客户共创中。预计明年Q1，依托这套模型打造的 C 端产品 Tap8 会正式对外开放。

*Tap8 Demo，实时指导用户健身

更多关于 SigmaZ 技术和业务的信息，在以下我和杨博麟（William）、Derek 的对话中。

用代码，生成下一代界面

Q：我们从创业开始聊起。做下一代交互页面，这个创业方向是怎么决定的？

William：我过去的工作和创业经历，主要集中在出海互联网产品和营销上。

我一直觉得，产品和营销的本质都像翻译。做产品，是把复杂的技术、流程和能力压缩成一个足够简单、自然的界面；做营销，则是把产品卖点翻译成消费者能听懂的话。

所以我一直很着迷于一个问题：信息应该怎样被组织和表达，才能让人与人之间的沟通效率最高？

后来，我找到认识很久的 Derek 聊了很长时间，我们达成了一个结论：今天做 Agent 的公司已经非常多了，但真正擅长表达的 Agent 并不多。它能干活，却不太会表达，就像一个人很聪明，但情商不高，只能用文字交流，表达能力不强。

Derek 多年来一直聚焦模型训练和人机交互。所以在我们还没有确定做哪一个特别具体的场景之前，就有一件很确定的事：如果要做，就要做“会表达的 AI”。再具体一点，就是探索一种新的人与 AI 的交互形式。

Q：“会表达的 AI”具体指的是？是更主动、表达更精确，还是代表某种其他趋势？聚焦视觉交互 Interface这个定位的过程可以讲讲吗？

William：现在我们理解的“会表达的 AI”，就是能够实时进行多模态交互的 AI。

今天的 AI 主要通过文字跟人交流。我们认为，AI 能帮你干活只是基础，还应该探索新的交互方式。所以我们从来没有想把产品做成传统 Chatbot，而是一直在探索交互。

我们给自己的定位是一个“视觉交互智能实验室”，研究新的 interface。

Derek：聚焦视觉交互的过程我可以从技术视角讲讲。

从大学毕业到现在我经历了四代人机界面的迭代。

从文字开始，然后第二代界面是语音。十年前，我刚毕业进入 Amazon Alexa 的剑桥实验室，做 Conversational AI，那项功能最早的几百行代码是我写的。当时团队定下的目标是，不管用户问什么，Alexa 都要能接得住并继续对话。后来，我们把 Alexa 从大约百万用户做到了 6 亿用户。

有了大模型以后，我开始做生成式 UI，带着团队把 Generative UI 做进了 Amazon Nova 模型，让大模型可以直接输出可视化 HTML。现在大模型都能做这件事，编写 HTML，直接做可视化表达。

现在，我们想做的就是第四代人机交互界面：实时交互视频。

你能看出来，界面在一代一代往前走。这是因为每一代界面最终都会成为人与 AI 之间的新瓶颈，需要下一代界面。

这个瓶颈到底有多大？其实是可以量化的，一个成年人的阅读速度大约是每分钟 240 个英文词，拆成 Token 后，约等于每秒 5 个 Token。现在的前沿模型已经能做到每秒输出 300 个 Token，一些专用推理芯片甚至能达到每秒几千个 Token。

也就是说，即便只有一个模型对着一个非常专注的人输出，中间也有约 60 倍的信息差，前沿模型每秒钟输出的内容，一个人需要一分钟才能读完。假如这个人还同时和多个 Agent 组成的团队一起工作，信息差就会达到百倍甚至千倍。

换句话说，今天大部分 Agent 的输出根本没有人能读完。算力不再是 AI 的天花板，人与 AI 之间的带宽才是卡点。

Andrej Karpathy 2025 年 5 月也发文，说与大语言模型聊天像在使用古老的 terminal。聊天框只是一个命令行，属于 AI 的 GUI，也就是真正的图形界面还没有被做出来。当时我已经在 Amazon Nova 完成了第一代生成式 HTML。

今年 5 月，他又说HTML 是当下模型最理想的模态，但终点是交互式视频。那时候，我们的第一代视频生成引擎已经上线几个月了。

这让我们更确信方向是对的，最聪明的一批人正在往同一个地方走。

Q：下一代界面一定会是“实时交互视频”吗？这件事不同的人可能持不同看法。

William：我们最早做的是一款名为 Cuflow 的 AI 教育产品，核心功能是把用户的 PPT、PDF 或其他知识资料，变成一个可以观看、可以互动的课堂。当时称它为“全模态 AI 教室”，学生可以在里面上课。

这款产品的数据很好，发布不久就获得 2000 多万次全网曝光，活跃度、使用时长等核心指标也高于同赛道的其他 AI 教育产品。对比下来，当时只有我们会把课件变成教学视频，其他产品更多是生成思维导图之类的内容。

这个产品里有一个功能很重要，就是我们上线了“资料转视频”功能，用大模型生成“视频”，速度很快、准确度较高，价格也便宜。那时很多像素视频模型只能生成 15 秒的视频，还要等 30 分钟。但我们用大模型，用户上传一份课件后，可以用代码很快生成一段 3 分钟的“视频”。

后来，用户拿它生成各种内容：市场营销、游戏讲解、教程、博客，什么都传，偏偏不只拿来学习。于是我们决定把“用代码生成交互视频”从一个功能变成核心产品，并把它做得更加通用。

当时，我们的产品还不能和视频 "对话"—— 用户能做的，只是拖拽视频里的部分 3D 组件。但我们发现用户在对话框里会很自然地想直接跟“视频”交流，比如问它， "这道题能不能再讲一遍？"" 这句话是什么意思？"

也就是说，虽然当时的技术做不到真正的实时交互，但 80% 以上的用户都会尝试用 Chatbot 与视频交流。

这个线索给了我们启发。接着，我们一个月内访谈了 100 多位用户。

我记得有一位 00 后用户说，自从开始用视频看生活中的各种内容之后，他已经懒得再读文字了。这些反馈再加上之前用户通过对话框和视频对话的现象，我们意识到，消费者的心智正在发生范式变化。模态转化或视频不只是一种内容形态，它可能就是下一代人与 AI 交互的界面，因为它能更高效地组织和传递信息。

我们从这些真实、具体的用户行为里看到了范式变化，再结合对技术的理解，就开始做实时交互视频了。

Q：在 Cuflow 里，你们也选择用代码生成视频，而不是直接用视频模型生成视频。这样做的原因是？

William：没错，我们的第一款产品已经在用模型的代码生成视觉内容。

如果做个对比，像素生成的视频，画面精细程度更好，代码生成的内容更准确、更可编辑，能够清晰、准确地表达结构和因果。它要能在浏览器这样的通用平台上直接执行，还必须能够检查和修改。同时满足这些要求的，只有用代码生成视频。

所以不是我们选择了代码生成视频，而是“解决下一代界面问题”这件事本身选择了代码。

Derek：我们认为，凡是以代码作为中间格式来生成视觉内容的 AI 系统，都属于代码生成的视觉 AI。

a16z 的文章《The Next Frontier of Visual AI Is Code》给出了类似架构。Pixel-native 系统直接生成最终画面；code-native 系统生成的不是像素或最终画面，而是一个程序，再由程序渲染画面。SVG、HTML、Lottie、Blender 脚本，或游戏引擎里的场景，都属于 code-native 系统。

a16z 按内容的表示形式来划定边界，这个边界清晰准确，我认同。不过仅用“输出是否为代码”还不够，更深一层的分界是：代码导出的是一份成品、成片，还是一个能够继续运行的世界。

我觉得代码真正解锁的不只是格式，而是一整个闭环：生成代码之后，我们可以渲染、检查、精修，再渲染、再检查、再修改。像素模型每次重试，基本上都是重新“抽卡”；代码则能在每次迭代里持续修改源码。

而且这种修改是 specific 的。如果 spacing 不对，就改 CSS；图形不对，就改 path；节奏不对，就改 timing。每个部件都可以编辑，也可以归因。只有这样，系统才有可能形成 RSI，也就是自我迭代、自我改进。

选DLM路线，是为了提升内容生成速度

Q：a16z 的文章没有很确切的技术选择，但你们现在要自己做后训练，并且选了 DLM 模型路线。这样做的原因是？

William：当时我们已经可以用代码生成质量不错的视频，准确性较强、速度较快，成本也比较低。但从生成视频，到生成交互视频，再到实时交互视频，中间最大的 gap 是速度：怎样让它生成得更快？

用户希望输入文字后，视频能在一秒左右出现。这个最纯粹的用户需求，让我们开始思考比传统自回归模型更快的生成方式。

传统自回归大语言模型的速度上限，取决于每秒能吐出多少 Token。它又受硬件和显存带宽限制，所以要提高生成速度，大致有两种办法。

第一种是换硬件，例如 Cerebras、英伟达都在做专门为大模型适配的硬件，但这不是一家 Startup 最适合做的事。

第二种是放弃传统自回归大语言模型，也放弃传统的像素扩散模型，寻找第三条路，才能做到非常快的实时生成。后来我们选择了扩散语言模型，也就是 DLM。

Derek 在这个方向上研究了两年多。DLM 通过迭代式扩散的方式生成 Token，速度可以比传统自回归模型快一个量级。

我们的第一款产品从一开始就是代码生成。在几乎没有人做代码生成时，我们已经在做了，因为 Derek 一直在视觉编码方向工作。如今，这件事正在逐渐形成共识。

Derek：DLM 是行业已经存在的技术路线和基础架构，这两年也被产业界推进。我们基于这条路，自研训练框架，并针对视觉代码任务做优化。

DLM 与传统自回归模型最直观的差别是：自回归模型从左到右，一个 Token 一个 Token 地写；DLM 更像洗照片，先铺开一张画布，再让整张画布上所有位置逐步变清晰，直到每个字都清楚。

技术上，它带来三个好处。

第一，注意力是双向的。

第二，一次传播可以覆盖许多位置，解码过程从 memory-bound 变成 compute-bound，恰好更适合现代 GPU。现在 GPU 有非常强的计算能力，而大语言模型生成的瓶颈往往在 memory bandwidth。

所以在同样的硬件上，DLM 的吞吐量可以高出一个量级。一些开源模型已经展示了这种能力，例如字节的 Seed Diffusion 可以达到每秒约 2000 个 Token，Google Gemini Diffusion 接近每秒 1500 个 Token，而常见自回归模型通常在每秒 100 个 Token 上下。

第三，DLM 生成代码时可以自我修正。它不是从左到右写完就不能回头，而是同时处理一整段代码。写的过程中发现问题，下一步还可以修改前面的 Token。

对我们来说，DLM 首先解决的是“快”。我们要做实时视频生成，内容生成速度必须提上来，刚刚说的那几个技术特点，都能提升内容生成的速度。

当然了，DLM 目前也有弱点，主要是 reasoning。比如在 GPQA 这类推理测试上，它可能比前沿自回归模型低 15 个百分点左右。但我们判断，这对视觉代码生成的影响没有那么大。

具体到我们的实践里，SigmaZ 的 interaction model 架构中，所有复杂 reasoning 都会由另一个前沿模型负责。DLM 只负责把已有素材翻译、打磨成视觉代码，再渲染给人看。它是表达层，不是逻辑推理层。

它把文字表达转成视觉代码表达，本质上更像翻译，这个任务恰好落在 DLM 又强又快的能力区间。

如果用自回归模型，跑一遍可能就要几分钟，迭代两三轮的成本和延迟都很高。用 DLM，一轮只需几秒。如果在实际场景里，同样几十秒的用户可容忍时间里，我们可以做几十轮在线精修，把速度收益直接兑换成质量提升。

Q：DLM 解决了实时互动视频的实时问题，另外还有互动，也就是来自用户的视频需求随时可编辑、改动，这一半是怎么解决的？

Derek：通过代码做视觉，我们可以形成自循环的 RSI 自我改进系统。因为代码不只是中间格式，它还描述了交互视频世界的状态。

这个系统的核心逻辑是：我们在内部把交互视频写成一个状态方程：下一个画面，是当前画面加上用户动作以及此前动作的上下文，再由模型计算得到的。

因此，代码承载了这个世界的结构、对象和演化规则，浏览器负责渲染与执行。用户每做一个动作，这个世界就往前走一步，进入下一个画面。

如果在“以代码为中间格式生成视觉”的定义上再加一层，我们会问：这个系统能不能跑循环？能跑多少次？

有些系统导出一份 HTML 就停止了，相当于循环一次也没有真正运行。我们的系统则在每次交互时都运行一次，世界会随着交互持续迭代和更新。所以，即便大家都在做代码原生视觉，最终产物也可能完全不同。

这个循环的 RSI 架构，是这台机器的引擎。DLM 则像给这台引擎增加了一层高效燃料。

把 DLM 与 RSI 自动优化循环合起来，会产生最大的变量。RSI 引擎不断经历“代码生成—渲染—精修”的循环，上限取决于：在人能接受的延迟里，它能精修多少遍。

所以我们常说，RSI 精修循环是发动机，DLM 的速度是火箭燃料。发动机已经造好了。过去我们烧不起这种燃料，现在有了 DLM，它就可以变成火箭发动机。

和其他“互动”模型的区别

Q：像素视频模型也能根据用户输入继续生成画面。你们的核心差异是什么？

Derek：两类系统都在根据当前状态预测下一状态，但表达状态的方式不同。我们用代码记录世界的结构、规则和状态；像素模型主要根据此前画面和用户的新输入预测后续画面。

代码路线更适合需要准确、可控和持续编辑的工作或生活场景；像素路线则更擅长写实质感、氛围、光影和人物情绪。两者没有绝对优劣，取决于最终要服务什么产品。 采取像素路线的产品，优先追求吸引眼球、好玩、好看的游戏或娱乐世界。我们更偏向 for work、for lifestyle，两边各有重点。

William：如果实时交互视频真的是下一代人机界面，它就必须具有实用性，承担一定的信息组织和传递功能。

今天的手机界面不只用来打游戏，还要订酒店、记录工作、跟人通话。它不能只有娱乐性。同样，如果实时交互视频要成为下一代界面，我们的解法是“好用又好玩”。

现在很多产品更强调好玩，因为资本喜欢寻找下一个 TikTok。但如果真正专注于“下一代人机界面”这个命题，它既要有娱乐性，也必须能准确地组织和传递信息。

对我们来说，实时交互视频首先要成为一个有用的界面，因此准确、可用的优先级高于单纯好看。

Derek：大家在 next-state prediction 上的工程理念可能相近，但我们选择用代码表达整个世界，它们选择用像素表达整个世界。

最大的差别是，代码的准确性不完全依赖后期优化，它是代码结构天然带来的。代码特别适合表达一切有结构、承载事实的内容，比如图表、数据可视化、公式、标注、机械拆解、软件 UI 展示、物理动画和 3D 结构。因为在 representation 层级上，代码的抽象程度比像素高得多。

比如要表达一个弹跳的球，用代码只需几句话：球往哪个方向飞，落地后怎样反弹。我们还可以 import 一个现成的物理库，设置初始速度、重力和碰撞参数，反弹过程就由多年迭代的渲染引擎准确完成，并且符合物理规律。

用像素表达同一件事，则要每秒 30 帧，一帧一帧地把地面、球和背景全部重新计算。算了这么多，也不能保证球碰到地面后的反弹角度一定正确。

这种差别可以在 benchmark 中直接看到。在信息密集的场景下，我们的代码渲染系统在事实覆盖率上达到 84%；像素系统大约是 54% 到 68%。这不是谁把准确率调得更好的问题，而是技术路线自带的差别。

反过来，代码目前不擅长的，恰好是像素模型擅长的：写实质感、氛围、光影和人物情绪。这些 high-entropy 的开放世界内容，是 pixel diffusion 的主场。在我们发布的 benchmark 里，审美 preference 这一项，我们也坦诚地承认，在七个系统中并不是最高。

Q：代码生成内容目前“不够美、不够好看”的问题，可以怎么解决？

Derek：我认为“不够美”要分成两种情况。它不一定意味着代码路线做不到，也可能只是还没有被训练到那个程度。

有些代码艺术家能用很短的代码渲染出整个艺术展示的世界，说明代码本身具备很高的 expressiveness，表现力上限并不低。只不过，它需要足够有创意的艺术家把代码当作表达媒介，而现有大语言模型还没有真正针对“高表现力视觉代码”做过充分训练，这个方向才刚刚开始。

实时渲染中的 DLM 速度也能帮上忙。我们的 improvement loop 是“写代码—渲染—精修”。如果用实时生成的 DLM，可以把精修轮次从两三轮增加到几十轮，把速度收益转化为美感的逐步提升。

William：这也就是现在很受关注的 test-time scaling。

Training scaling 当然重要，要在训练过程中让模型原生具备生成好看内容的能力；但在推理过程中扩大计算，让它更充分地推理、精修，同样重要。两者是相辅相成的。

让模型和模型的“评委”一起进化

Q：关于提升代码生成内容的审美。看到你们的底层系统里还提到有一个“评委”，它是在训练时提升模型品位，还是在推理时实时优化输出？

Derek：两种都有，是两个循环。

在用户实际使用的推理阶段，我们会让 VLM Judge，也就是评委，检查内容是否成功渲染、是否符合预期，并做精修和调整。

另一个循环发生在训练阶段。这也来自我今年在巴西 ICLR 发表的论文。论文讲的是两个循环：一个是线上实时循环；另一个是把循环中得到的最佳结果、最好看的画面，通过训练内化进模型，把 online 阶段的改进带回模型训练。

在真实使用中，系统会反复迭代，得到最好的版本。模型训练时，我们还会加入更多合成数据，也让模型自己迭代，选出最好的版本用于训练。

Q：训练时的循环，具体是怎么工作的？

Derek：自动评估优化有一个内环：先生成视觉代码，再渲染；用 VLM，也就是视觉模型，检查实际效果，对美术和排版给出反馈；Coding Agent 再拿着这些反馈反复修改。

这些修改轨迹会被蒸馏成训练数据，用于调优下一代模型。下一代模型再被用于 Coding Agent，生成代码的 baseline 会更好，然后继续迭代。每一轮循环中，作为设计师的 Coding Agent 和评委都会同时变强。

Q：这套系统能够持续运行的核心原因是？

Derek：主要靠三个机制。

第一个是归因，也就是 credit assignment。

判断一个版本整体是否好看并不难，难的是把这种整体判断归因到具体哪些代码、哪些 Token。

我们开发了一套 credit assignment 方法，可以识别哪些代码写得好、哪些写得不好。这样，代码训练就能得到干净的训练信号。只有可归因，才可训练，系统才可以自我改进。

第二个是评委本身也要进化。写代码与数学、科研不同，后者的对错相对稳定，但人类的视觉品位，特别是视频品位，每天都在变化。

比如去年年初，大模型刚能写网页时，经常生成紫色渐变的“AI 风”，当时大家觉得很酷。今天，这种风格几乎已经被全网拉黑。

品位变化最快的方向，往往恰好也是奖励模型最用力、最容易过度奖励的方向。今天很酷的东西，被模型训练放大之后就会被过度使用，最后从潮流变成 AI slop。

静态评委会持续奖励这种 AI slop，把模型卡在昨天的品位里。因此，在论文所说的循环之上，我们又增加了一层 meta 循环，也就是“评委的评委”。

它会观察评委与人类标注之间的差异，自动做实验并重新调整评分标准，让评委持续与人类品位对齐，跟上视觉审美的变化。

William：可以把内层评委理解为老师，Meta 层则像教学质量监督部门。它检查老师采用的最新标准是否符合整体要求。

这是一个双循环过程：模型会吸收生产环境中真实用户的反馈，也会吸收“质检员”对老师的反馈。老师一直在进化，并持续根据这些反馈调整。

Q：一方面使用蒸馏数据，另一方面也需要 Agent 持续为评委纠偏。在整个过程里，会不会也需要真人来判断审美？

Derek：是的。我们有专家参与打分和标注，但使用专家数据的方式很高效。专家数据主要用于让 AI 评委与人类对齐。假如人类专家打 100 条，自动测评模型就可以按照这套标准去评后面的 10 万条。

William：可以把视频生成模型想象成一个短视频博主。过去，这个博主不会学习，只会一直做同一种视频。我们在做的 continual learning，则让它可以根据人类反馈持续学习：有些视频没人点赞，它就知道这种做法不好，以后少这么做。

传统做法要让这个博主越做越好，需要很多真实观众持续观看、点赞和反馈。我们的做法相当于训练一个模型，去模拟许多真人，告诉生成模型：你做得好不好，最新的视频是否符合人类喜欢的方向。

这样就像“左脚踩右脚”，模型可以自己不断提高，不再需要大量真人参与每一步反馈，标注成本也会降低。

另外，如果要让双循环真正转起来，也需要数据。

我们有来自生产环境的几十万条“用代码生成交互视频”的数据，这是模型飞轮的燃料。所以，既要知道飞轮怎么搭，也要有最初把它转起来的数据。数据同样是重要壁垒。

Q：这些数据里，第一款产品会做多少贡献？

William：数据主要有三种来源。

第一，来自我们最早的产品。

第二，来自目前与 B 端客户开展的早期试点。现在有 21 家签署合作意向的机构，我们会在试点中了解它们的真实场景。

第三，来自数据合成。

数据合成会基于已有的真实用户反馈。比如，一个视频生成后，如果用户选择导出，通常说明用户认为它质量不错，我们就会把它加入高质量数据集。然后，再把这条数据翻译成多种语言，或者对视频做 remix，进一步扩充数据量。

21家B端客户意向，和C端产品的定位

Q：实时互动方向还有不少生成小游戏的产品。它们底层也使用代码。与你们相比，差别在哪里？

Derek：核心有两个差别。

第一，那类实时生成小游戏通常是单次生成。小游戏生成之后，用户只是在玩它；游戏世界不会再根据用户新的输入发生变化。它可以被下载、导出到其他地方运行，因为它本质上是一份一次性产物。

我们做的是持续、实时、交互式生成。世界会根据你的互动和上下文重新生成，进入下一个画面。

第二，双方的优化目标不同。我们优化视觉代码时，关注准确性和表达能力，关心信息是否被准确传递、用户是否真正吸收；小游戏产品更关注娱乐性、好不好看、好不好玩，以及有没有传播性。

William：它们也是代码生成，但我们还会再往前一步，做混合模态：既有代码，也有像素。下一步，我们会对模型做联合训练，让同一个模型同时输出代码和像素。

此外，我们生成的是实时可交互的世界，而它们更像生成一份静态产物。它们偏纯娱乐，我们更关注“好用又好玩”的实时交互视频。

如果把视角放宽，整体对比其他所有互动产品，我们的特点主要有三个。

第一是 Watch and Play，也就是“一边看，一边玩”。视频里只要是可交互的内容，例如 3D 对象或图表，用户都可以点击、拖拽和操作。

第二是 Create and Remix。用户只需一句简单指令，就能生成一段可交互视频。也可以上传课件，或者把文字内容转成视频。

比如我和你们的公众号合作，可以建立一个完全由视频或互动视频组成的频道，把文字内容生成视频。你们还可以定义一种独特 style，例如像素风。别人看到后觉得有意思，也可以很快 remix 出自己的版本。

第三是 Real-time Interaction。过去的视频是静态的，未来的视频应该支持实时双向交互。用户看到不懂的地方，可以随时暂停，直接问“这是什么意思”“能不能再深入讲讲”，视频里的 AI 会很快给出回应。

正式发布前，我们会邀请合作媒体提前试用，提供 API 和账号。我们希望它像 Manus 发布时一样，给人带来强烈的科技奇观感，让大家意识到，原来今天的科技已经发展到了这个程度。

Q：现在 SigmaZ 已经有两款产品，它们未来的规划是？

William：我们当前最聚焦的是模型后训练，以及基于视觉反馈的自进化框架。

Cuflow 是我们最早做的第一款产品，也是很多技术判断的起点。从一开始，我们就把它定位成 research preview 或 prototype，用来验证用户对“用代码生成可交互视频”是否存在真实需求。

虽然 Cuflow 的数据很好，但它的实验性定位没有改变。它帮助我们收集了初步数据，也让我们更加确信：未来的交互形式会发生巨大变化，我们需要基于这些数据训练一个模型，专门解决这个问题。

Q：目前模型方面的具体进展是？未来的业务会更偏To B 还是 To C？

William：我们只在小范围内做尝试。现在还不能大规模 serve 客户，因为模型尚未完成，需要一些时间。

目前主要是少量 B 端客户，可以理解为内测，但更重要的目的，是和他们一起理解真实场景。

现有 21 家合作意向方中，主要以出海的硬件和软件公司为主

我们未来的业务占比，我觉得大约 80% 在 To B，20% 在 To C。C 端产品首先是流量入口和数据来源，也能建立品牌声量与市场认知。真正驱动收入的，可能是 B 端。

就像今天的 Kimi 和 DeepSeek，它们的 C 端产品未必直接赚钱，但可以建立很好的口碑，让大家知道谁在这个领域做得最好，最终再把能力自下而上地卖给 B 端。

B 端客户可能需要高可控的视频生成。

比如市场营销客户需要用交互方式展示产品，企业培训客户也可能用这套能力，替代原本年薪十几万美元的培训师。

所以代码生成内容的路线娱乐性可能没那么强，但 PMF 或许会来得更快。整个市场都希望看到交互内容找到 PMF。

未来，我们会更聚焦模型层能力，但提供的不只是一个裸模型，还会在其上搭载基于视觉反馈、自我进化的 Harness。我们会与 B 端客户合作，帮助他们定义，在自己的具体场景中，什么才是“更好”的信号。模型也会随着 B 端场景持续进化。

我认为，专门做模型后训练的公司未来会在生态中拥有自己的位置。企业并不是把模型建起来就结束了，还需要让模型在真实业务场景中自我进化。后训练的价值，就是把模型从“可用”推进到“在这个场景里真正好用”。