当前时间: 2026-05-22 01:46:34
分类:办公文件
评论(0)
百度AI收入占四成,C端却输得一塌糊涂?编者按: 百度2026年Q1财报出炉:营收320.8亿元,AI新业务收入136亿元,占比超过四成。智能云基础设施收入同比增长79%,GPU云更是暴涨184%。数据看起来很漂亮,但另一边,文心一言在C端市场的表现却难言乐观。豆包、DeepSeek、通义千问后来居上,百度这个"AI元老",怎么就起了个大早,赶了个晚集?技术积累深厚,产品化能力却掉了队——这不是能力问题,是战略选择的问题。财报很漂亮,但C端的故事讲不下去了
320.8亿元营收,超市场预期314.9亿元。核心AI新业务收入136亿元,占总营收的42.4%。智能云基础设施收入88亿元,同比增长79%。GPU云收入同比增长184%——这个数字尤其亮眼,说明百度在算力基础设施上的投入正在变现。这些数据说明什么?说明百度在B端AI市场站稳了脚跟。企业客户愿意为百度的云计算、大模型训练、自动驾驶解决方案买单。百度的技术底蕴,在B端确实能换成真金白银。但财报里也有不那么好看的数据。爱奇艺收入62亿元,环比减少8%。AI应用收入25亿元,同比大致持平。这意味着什么?意味着百度的C端AI产品,并没有随着行业爆发而增长。写到这儿,我突然想到一个对比。字节跳动的豆包,2025年底日活已经突破8000万。DeepSeek虽然没公布具体数据,但凭借开源策略和极致性价比,在开发者社区的影响力如日中天。阿里的通义千问,背靠电商和云计算生态,商业化路径清晰。而文心一言呢?百度从来没公布过日活数据,但业内普遍估计,其用户规模已经掉出第一梯队。这不是技术问题。百度的AI技术积累,在国内绝对是第一梯队。文心大模型的参数规模、训练数据量、多模态能力,都不输给任何竞品。但技术强不等于产品强,模型好不等于用户体验好。百度的问题在于,它太习惯做"平台"了。搜索、地图、网盘,这些产品逻辑是"用户来找我"。但AI助手的产品逻辑是"我去找用户"——需要主动对话、需要理解上下文、需要个性化回复。百度在这方面的产品化能力,明显落后于字节和DeepSeek。文心一言的困境:起了个大早,赶了个晚集
文心一言的发布时间,比豆包、DeepSeek都早。2023年3月,百度就发布了文心一言,是国内最早推出大模型对话产品的公司之一。那时候,ChatGPT刚火起来,国内还没几个人知道什么是大模型。百度的先发优势,不可谓不明显。产品定位模糊。文心一言到底是搜索的升级版,还是独立的AI助手?百度似乎一直没想清楚。早期的文心一言,界面和功能都和百度搜索高度绑定,用户感知上就是一个"能聊天的搜索框"。而豆包从一开始就是独立的APP,定位清晰:年轻人的AI朋友。DeepSeek则聚焦在"极致性价比的专业助手",开发者和大学生的首选。用户体验有差距。我对比过几款产品的对话体验。豆包的回复更活泼、更有网感,符合年轻用户的口味。DeepSeek的推理能力更强,写代码、做数学题明显更靠谱。通义千问在电商场景和办公场景的深度整合更好。文心一言呢?各方面都不差,但也没有特别突出的长板。用产品经理的话说,就是"没有记忆点"。运营策略保守。字节给豆包投入了海量资源:抖音导流、火山引擎支持、剪映联动。DeepSeek靠开源社区自然生长,口碑传播效应极强。阿里把通义千问塞进淘宝、钉钉、支付宝,每一个入口都是流量池。百度呢?文心一言主要靠百度搜索导流,但搜索本身就在被AI助手蚕食,这个逻辑有点自相矛盾。写到这儿,我突然想起一个细节。2024年,百度曾经尝试把文心一言和百度网盘、百度地图做整合,但效果一般。用户用网盘是为了存文件,用地图是为了导航,突然塞进来一个AI助手,感觉很突兀。整合不是简单的功能叠加,需要场景的自然融合。百度在这方面,显然还没找到感觉。百度的AI版图:B端是现金牛,C端是短板
但话说回来,百度在AI领域的布局,远比外界看到的要深。自动驾驶是百度最被低估的资产。Apollo平台在国内自动驾驶领域的技术积累,几乎没有对手。萝卜快跑的Robotaxi服务,已经在武汉、北京等多个城市落地。虽然商业化进度比预期慢,但百度在这个赛道的先发优势是实实在在的。智能云是百度目前最赚钱的业务。88亿元收入,79%的增长,GPU云更是翻倍增长。这说明什么?说明百度在算力基础设施上的投入,正在进入收获期。大模型训练需要海量算力,百度有自研的昆仑芯,有大规模的GPU集群,有成熟的云计算平台——这些能力,是很多AI公司花钱买都买不到的。核心AI新业务收入136亿元,听起来很多,但这里面有多少是"真正的AI收入",有多少是"披着AI外衣的传统业务",外界很难判断。智能云收入里,有多少是GPU租赁,有多少是传统服务器托管?AI应用收入25亿元,具体是哪些应用?文心一言贡献了多少?百度从来没说清楚。更关键的是,C端产品的缺失,可能会反过来影响B端业务。大模型的竞争,最终是数据飞轮的竞争。用户越多,反馈数据越多,模型迭代越快,体验越好,用户越多——这是正向循环。百度在C端用户规模上的落后,意味着它的数据飞轮转得比别人慢。短期看,B端收入还能撑住场面;长期看,如果模型体验和竞品差距拉大,B端客户也可能流失。写到这儿,我突然想到一个可能的转机。百度最近在大力推"智能体"(Agent)概念,试图把文心一言从"对话工具"升级为"任务执行工具"。如果这个方向能跑通,百度或许能绕过C端对话产品的红海,开辟一条新路。但智能体的技术难度更高,用户体验更复杂,百度能不能做好,还是个大问号。未来的路:百度需要一场产品革命
技术底子厚,专利一大堆,工程师能力顶尖。但产品跟不上时代,用户体验被后来者超越。诺基亚当年也不是没做智能手机,Symbian系统一度是行业标杆。但iPhone和Android出来后,诺基亚的产品逻辑就过时了。百度不是诺基亚,AI行业的竞争格局也比手机行业复杂得多。但如果百度不能尽快补上C端产品的短板,它的AI版图就可能出现"B端独大、C端空心"的危险局面。文心一言需要重新定位。不要试图做"全能助手",要找到一个垂直场景打透。比如,百度的搜索和知识图谱是强项,能不能把文心一言做成"最强知识问答助手"?或者,百度的自动驾驶数据是独家资源,能不能做一个"最懂汽车的AI助手"?产品体验要补课。百度的工程师文化太重,产品思维太弱。建议多招一些字节、腾讯出来的产品经理,把用户体验放在第一位。技术再强,用户不爱用也是白搭。运营要更激进。字节给豆包投了多少资源?百度给文心一言投了多少?对比一下就知道了。AI产品的竞争是烧钱的竞争,舍不得孩子套不着狼。当然,这些都是旁观者清。百度内部肯定也在反思和调整。毕竟,136亿元的AI收入不是小数目,百度有底气也有耐心。但市场不会永远等你。豆包、DeepSeek、通义千问都在快速迭代,用户习惯一旦形成,迁移成本会越来越高。百度的时间窗口,可能比想象中更窄。
基本
文件
流程
错误
SQL
调试
- 请求信息 : 2026-05-22 12:59:06 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/655855.html
- 运行时间 : 0.082435s [ 吞吐率:12.13req/s ] 内存消耗:4,547.23kb 文件加载:145
- 缓存信息 : 0 reads,0 writes
- 会话信息 : SESSION_ID=33590e043a4801cdd17f5e963fd330b2
- CONNECT:[ UseTime:0.000508s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
- SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000738s ]
- SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000327s ]
- SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000300s ]
- SHOW FULL COLUMNS FROM `set` [ RunTime:0.000522s ]
- SELECT * FROM `set` [ RunTime:0.000206s ]
- SHOW FULL COLUMNS FROM `article` [ RunTime:0.000641s ]
- SELECT * FROM `article` WHERE `id` = 655855 LIMIT 1 [ RunTime:0.000609s ]
- UPDATE `article` SET `lasttime` = 1779425946 WHERE `id` = 655855 [ RunTime:0.000781s ]
- SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.000199s ]
- SELECT * FROM `article` WHERE `id` < 655855 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000448s ]
- SELECT * FROM `article` WHERE `id` > 655855 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.000312s ]
- SELECT * FROM `article` WHERE `id` < 655855 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.000613s ]
- SELECT * FROM `article` WHERE `id` < 655855 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.000633s ]
- SELECT * FROM `article` WHERE `id` < 655855 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.000738s ]
0.084138s