
LibTV收入过半,但陈冕说短期毛利不超30%:深读晚点专访
精读晚点 LatePost 对话 LiblibAI 创始人陈冕,拆出 LibTV 收入占比、订阅加积分的定价逻辑、现金流与毛利边界,并用两篇同期文章核对产品实测和推广口径。
导读
晚点 LatePost 对 LiblibAI 创始人陈冕的专访,给出了目前少见的一套 LibTV 商业账:演语科技 Evoken 的 ARR 超过 3 亿美元,LibTV 贡献超过一半;产品上线时用 3.9 折年费吸引用户,实际把模型成本折算成积分,再根据消耗率和续费率倒推价格;陈冕还说,AI 应用早期的毛利率短期内不应超过 30%。1
这不是一篇单纯的产品发布稿。它试图回答的是:当视频模型的能力和价格都在快速变化时,一个应用平台怎样把模型成本、用户预付款、内容生产流程和竞争速度装进同一套生意里。答案目前仍是陈冕的公司自述,许多关键数字没有财务报表、用户 cohort 或统一测试条件支持,读者需要把「增长已经发生」和「商业模式已经被证明」分开看。
原文信息
- 原文标题:《对话 Liblib 陈冕:关于活下来,以及所有接近死亡的时刻》
- 来源与署名:微信公众号「晚点 LatePost」,文丨董慧,访谈丨小晚、董慧。1
- 发布时间:2026 年 7 月 29 日 17:47:50。1
- 文章类型:创始人专访,内容覆盖 Liblib、Lovart 和 LibTV,但本文最核心的产品对象是 LibTV。
- 读者应先记住的三组数字:Evoken ARR 超过 3 亿美元;LibTV 贡献超过一半收入;陈冕称 LibTV 有几十万付费用户,其中 90% 来自自然增长。1
全文速读
这是一套创始人的生存解释
专访的起点是外界对 Evoken 的两种相反判断:一方面,公司看起来是中国 AI 应用层最成功的样本;另一方面,它也被质疑原创不足、靠低价换增长、可能存在经营风险。陈冕的回应不是证明自己已经稳了,而是解释公司如何在模型快速进化的间隙里争取时间。
他把三条产品线看成同一家公司在不同阶段的应对:Liblib 是图像生成社区,Lovart 是图像设计工具,LibTV 是视频工具。模型能力变化后,原有产品空间会被压缩,团队就必须迅速转向下一种产品形态。这个判断也解释了为什么他把速度、投放和产品跟进放在同一张表里。
LibTV 的收入不是低价 API 生意
陈冕明确否认 LibTV 在出售打折的 Seedance API。3.9 折指的是连续包月年费,而不是把上游 API 以折扣价转卖给用户。按照他的说法,平台先把图片和视频的模型成本折算成积分,设计价格带和积分数量,再根据用户消耗率与续费率估算收入和成本,最后反推出早期价格。1
这套价格成立的前提,是用户不会把权益全部用满。陈冕在采访中举例,用户买了 100 万积分,实际使用 20 万,剩下的 80 万才构成平台利润;如果用户全量使用,平台就会亏损。这个例子解释了定价机制,却不能直接当成 LibTV 的实际平均使用率或毛利率。
他还透露,LibTV 的月客单价是几百元,几十万付费用户里年付订单占比约 20% 至 30%,公司从 2026 年 5 月开始现金流为正。问题是,年付带来的预收款会改善当期现金流,却不能自动证明用户持续使用、续费或完成了高价值交付。1
LibTV 的增长来自产品和注意力同时加速
陈冕称,LibTV 上线后很快从每天 10 万美元收入增长到一个月内峰值日收入 100 万美元;平台上线首月投入 100 万美元做推广。对投放的解释也比较特别:他称公司收入中只有 3% 至 4% 来自效果广告,大部分是无法精确归因的品牌投入,LibTV 早期的 100 万美元更像一次集中争夺注意力的市场费用。1
这也对应他在内部使用的说法:「先 build attention,再 build ability」。他的判断是,找到 PMF 只是开始,如果市场在某个时刻突然放量,产品没有抢到新增用户,已有的 PMF 也不够用。这里的收入和投放数字仍来自创始人访谈,没有第三方流水或渠道归因数据。
低毛利是阶段策略,不是亏损常态
专访把「补贴」和「低定价」区分开了。陈冕承认 Lovart 曾经有过两个月的负毛利补贴,但他说 LibTV 的 3.9 折年费是通过消耗率和续费率计算出来的低价格,不等于把每一笔交易都做成亏损。
他的毛利判断也很直接:应用层在上线一年以内不应追求与存储、芯片和 SOTA 模型相同的高毛利,AI 应用短期毛利率不应超过 30%。这是一种经营立场,不是对 LibTV 当前毛利率的披露。文章没有给出按产品、套餐、模型和时间段拆分的毛利表。1
功能细节拆解
这篇专访不是操作测评,不能替代产品文档。它能确认的是 LibTV 背后的几种产品机制,以及这些机制怎样被放进商业模式。
1. 订阅负责锁定关系,积分负责承接模型成本
传统生产力软件更接近纯订阅,AI 视频平台却面对按模型、时长、分辨率和生成次数变化的 Token 成本。陈冕的描述是,订阅仍然存在,用来维持续费关系;积分则把不同模型和媒体类型的消耗折算到同一套账户体系里。
他还提到过一种尚未切换的「山姆模式」:用户先办理会员卡,再按 Token 用量实充实销,固定费用对应应用层价值。这会让高频用户承担更高的真实成本,但在当前年包竞争中,平台切换过去会更被动。对用户而言,真正要问的不是月费是多少,而是一次完整项目需要多少次生成、多少次返工,以及失败结果是否扣费。
2. LibTV 把自己的价值定义成「对齐」
面对「字节最大的代理商」这个评价,陈冕没有回避上游模型依赖。他把应用层的价值描述成模型和用户之间的对齐:模型像一台单反相机,用户按一下快门就能拍照,但想拍出专业作品,还需要有人听懂需求并操作相机。
这个比喻对应的是工作流编排、参数选择、资产复用和局部修改,而不只是模型本身的画质。它也把 LibTV 的风险说得很清楚:如果上游模型把这些对齐动作直接内置,平台就必须继续寻找更深的任务流程、用户资产或协作关系,单靠一个相似的画布界面很难长期区分。
3. 竞争优势被放在垂直场景,而不是通用 Agent
陈冕说 Manus、Genspark 选择了 general,Evoken 选择垂直;对 LibTV 来说,视频生产场景比通用对话更需要把用户的模糊意图转成镜头、角色、声音和画面控制。文章还提到,LibTV 进入视频赛道后,工程功能的差异可能只能维持一周左右,所以团队把上线速度和注意力获取放在同一优先级。
这条路线的好处是任务边界更清楚,坏处是上游模型一旦把视频工作流做得足够完整,垂直应用就会被迫不断加深流程。专访没有证明哪一项能力已经形成不可替代的壁垒,只证明了公司正在用速度换时间。
目标用户场景
对短剧团队,关键是项目成本而非单次出片
晚点给出的用户画像是有几百元月客单价、用 LibTV 替代部分剧组工作的视频生产者。刺猬公社的另一篇文章也把目标指向连续内容团队:它记录了一个《被裁掉的女孩》团队前 6 集主要由 3 人完成,第 7 集起增加到 4 人,单集制作时间约 2 至 3 天;平台运营负责人称,一集精品 AI 短剧的积分消耗换算成人民币约为「小几万」。这些信息分别来自创作者和平台运营方,不是统一条件下的成本审计。2
对这类用户,LibTV 的价值不在于某一镜头比其它模型好多少,而在于能否稳定复用角色、场景、服装和镜头控制。采购前应该把一个项目完整跑完,记录输入素材、生成次数、失败次数、人工校对时间、返工范围和最终导出,而不是只看一次演示能不能出片。
对独立创作者,低门槛和可控性同时重要
刺猬公社使用 LibTV 做了一个新手测试:先创建 7 岁女孩、65 岁单腿老人和一只狗的人物资产,再用人像质感调节、角色三视图、场景全景、多机位九宫格和 3D 导演台完成制作,最后做出一条 52 秒短片。文章还写到,测试过程中消耗了 8000 积分。2
这次记录支持「功能确实能把新手带入连续生产流程」这一判断,但不能推出每秒成本、成功率或平台排名。8000 积分对应的模型、时长和重试次数没有完全展开,也不能与晚点专访中的几百元月客单价直接相除。
对企业采购者,公开价格和使用边界仍不够
晚点专访中,LibTV 的 B 端收入,包括团队版和 API 相关业务,被陈冕描述为不到 10%。这说明当前叙事仍以 ToC 订阅和个人或小团队使用为主。1
LibTV 官方公开首页目前能看到「创作,只需要一张画布」、TV Show 和「全部」等入口,但没有在可读取页面中展示完整套餐、积分数量、模型规格、失败扣费或退款规则。3 对企业采购来说,这些字段比一句低价宣传更重要。
竞品坐标
专访没有提供同一输入、同一模型、同一预算下的竞品横测,因此下面是产品路线比较,不是能力排名。
| 路线 | 用户买到的东西 | 主要优势 | 需要警惕的地方 |
|---|---|---|---|
| 上游模型或原厂 C 端产品 | 直接使用模型能力 | 距离模型更近,价格和模型更新更直接 | 用户仍要自己组织分镜、资产、返工和交付流程 |
| LibTV 这类垂直视频应用 | 订阅、积分和视频工作流 | 把模型选择、镜头控制、资产和产出组织在一个场景里 | 上游成本、模型能力和额度规则都会影响毛利与体验 |
| 通用 Agent | 跨任务的工具调用和自动化 | 任务范围更广,技术演进速度可能更快 | 视频生产的镜头、角色和连续性要求未必能被通用流程覆盖 |
| 单点模型与多工具拼接 | 按环节自由选择工具 | 可以替换模型,成本和流程更容易拆开记录 | 素材搬运、版本管理和团队协作成本更高 |
这张表最重要的结论是:LibTV 需要证明的不是「能不能调用到某个模型」,而是它把应用层的对齐工作做得是否足够好,足以让用户接受平台的订阅和积分体系。晚点原文提到的早期视频平台 PMF,也没有给出名称和可复现对照数据,不能据此判断谁的模型或产品更强。1
行业影响
AI 视频平台开始出售「一段生产关系」
如果用户买的是单一模型,价格可以按秒、按张或按次比较。LibTV 的商业模式则试图把分镜、角色、场景、镜头、声音和导出放到一个项目里,用户购买的是一段连续生产关系。这样一来,平台的竞争单位就从「某个模型生成得好不好」变成「一个团队完成一个项目要花多少时间和钱」。
这会抬高平台的责任边界。只要用户要回改,平台就需要解释哪些节点会重算、哪些资产可以复用、失败结果是否扣费,以及生成的字幕和画面是否需要人工验收。上一轮刺猬公社的体验说明了功能链条可以跑起来,本轮晚点专访则解释了这条链条为什么必须和订阅、积分、续费率放在一起看。
低毛利可以换增长,但不能替代留存
LibTV 的定价逻辑依赖用户不把额度全部用完,营销逻辑依赖集中投入能换来关注,现金流逻辑又依赖年付预收款。这三件事都可能成立,但它们分别对应使用率、获客效率和留存率,不能用一个数字替代另一个数字。
我的判断是,下一步最值得追踪的不是平台还会不会继续降价,而是用户在第二个月、第三个月是否仍然愿意为完整项目付费。若用户只在新模型发布或促销期集中生成,月费和年费看起来都很漂亮,真实产能却可能没有那么高。
「后发也能赢」的条件比速度更苛刻
陈冕说,LibTV 不是第一个找到视频 PMF 的产品,但第一个发现 PMF 和最终赢得市场之间相差很远。这句话对行业的现实含义是:后发者可以靠更快的工程、定价和传播追上来,却必须在对方犯错、市场放量或用户需求仍未定型时完成切入。
这并不等于复制界面就能得到相同结果。速度只能购买观察窗口,长期留下来的理由还得来自角色资产、项目数据、团队协作、用户网络或更深的内容生产流程。晚点原文把这条路线称作在模型厂商的缝隙里「统一江东」,但陈冕也承认自己还不知道真正的「长江」是什么。
待验证点
- ARR 的计算口径:3 亿美元 ARR 是否按年化订阅收入、预收款、消耗收入或其它口径计算,文章没有给出定义、审计或财务拆分。
- LibTV 的具体收入规模:目前只有「超过一半」这一范围,没有产品级 ARR、月度收入、用户 cohort 和退款数据,不能把它直接当作精确的 1.5 亿美元收入。
- 几十万付费用户与 90% 自然增长:需要统一统计周期、付费定义、自然增长归因窗口和去重方式,也要区分注册、付费、活跃和持续使用。
- 3.9 折年费的真实权益:需要套餐原价、实际售价、有效期、积分数量、支持的模型和规格,以及失败生成、过期和退款规则。官方公开首页目前没有展示完整价目。3
- 积分对应的真实成本:应按图片、视频、音频、时长、分辨率、模型和重试次数逐项记录,不能把「一个项目」或「一条成片」当成统一计费单位。
- 正现金流是否能转成健康留存:年付订单占比约 20% 至 30%,但还需要看使用率、到期续费、退款、未使用额度和用户是否完成了第二个项目。1
- 功能实测能否复现:刺猬公社的 52 秒测试和 8000 积分记录需要补齐输入、模型、生成次数、失败次数和人工时长,才能与其它平台比较。2
- 爆款案例的成本与归因:豫信国创把「4 人、30 天、2.2 亿播放」写成 LibTV 全流程成熟落地的证明,但它是推广型文章;刺猬公社的报道则分别记录了创作者披露的人力成本、平台口径和自身测试,三类材料不能混成一组独立验证的数据。4
- 应用层的长期壁垒:当上游模型把镜头控制、资产复用和视频 Agent 直接内置后,LibTV 能否依靠工作流数据、创作者资产、团队协作或内容网络继续保留应用层价值,专访尚未给出答案。
原文关键句
「本质是对消耗率和续费率假设的平衡:把一张图、一个视频的成本折算成积分,设计不同价格带和对应积分数;假设消耗率和续费率,算出用户在整个周期里付多少钱、消耗多少成本;最后反推出一个没有那么高的早期利润率下成立的价格。」1
这句话把「便宜」还原成一组经营假设。它没有说明假设已经被验证,反而提示读者去追问用户使用率、模型成本和续费率是否与早期预算一致。
「你可以理解为,用户买了 100 万积分,实际只用 20 万,剩下 80 万是我们的利润。」1
这是对订阅加积分机制最直白的解释,也最需要实际账单验证。它是一个访谈中的举例,不是平台公布的平均用户数据。
「短期内不超过 30%。」1
这是陈冕对 AI 应用毛利率的判断,不是 LibTV 当前毛利率。它把问题从「平台是否亏钱」转成了「应用层愿意用多长时间的低毛利来换用户和规模」。
「我们现在就是在模型厂商的缝隙下统一江东。」1
这句话是专访对 LibTV 竞争位置最浓缩的概括:先在巨头暂时不优先投入的垂直市场积累用户和资源,再等待产品形态变化。至于这块「江东」能否守住,仍取决于上游模型、用户留存和应用层壁垒。
Related content
- Sign in to comment.
