鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册

抢占AI入口,阿里无法回避与字节的全面战争

编程导航
编程导航
2025-11-29 12:30
阅读 271
编程导航
2025-11-29 12:30
阅读 271

过去两年,当国内的AI应用疯狂涌现、彼此较量,聚焦在开源模型的阿里在 C 端的存在感明显偏弱。

但是,如今这种局面正在改变。

11月17日,阿里正式宣布推出“千问”项目,面向公众上线其App公测版,19日,千问APP最高升至App Store免费应用总榜第三名,公测一周后,下载量已突破1000万次。阿里并没有把宝全部押在千问身上,而是采用多产品并行的策略,千问APP上线的同时,全模态通用AI助手“灵光”问世,随后,夸克与千问完成了深度融合,全新上线。

千问、灵光及夸克的相继“落子”,意味着阿里开始逐渐铺开其在AI To C战场上的布局,而最终的目标直指用户在 AI 时代的第一入口。

争夺入口,就是争夺流量,争夺用户。尤其AI应用几乎能穿透所有的互联网交易场景,对巨头们实在是太有吸引力了。

可预见的变化是,从传统的用户搜索到AI直接给决策,广告和交易的形式可能都会被颠覆——ChatGPT和电商合作,用户在对话框里就能完成消费;豆包也独家引入了抖音商城的购物链接。

但是,我们可以看到,在这个入口的位置,早已站满了众多抢先一步的劲敌:豆包领衔,还有Kimi、文心、元宝等App虎视眈眈。

阿里有决心,也有钱有技术,但入口之争不会如此轻松写定。而且,它不得不面对一个事实:在与“后辈”的竞争过程中,攻守易位,即将陷入一场旷日持久的全面战争。

卷入应用层,阿里需要先面对字节

千问之前,阿里在C端市场上一直将资源集中在夸克身上,但因为夸克的底层逻辑是浏览器和搜索,即使AI技术能带来升级,可用户对其工具属性的认知也很难改变,这使得夸克在AI应用赛道上的发展并不理想。

“一个好用的浏览器和工具”,显然撑不起超级入口的愿景。

现在,千问上线,作为一个没有历史包袱的独立应用,它比夸克更适合承载阿里在To C市场上的战略期待。

但不可否认,从夸克到千问,阿里似乎错过了关键窗口期,这让其在争夺AI入口上姗姗来迟。

它能否后来者居上,是外界所有人的疑问。显然,刚上线这几日虽然人气高涨,但并不能说明什么。毕竟这是众多国产AI上线时,几乎都会经历的高光时刻和礼遇。

而在失去先发优势的当下,如何持续保持向上增长的曲线,才是阿里需要面对的极其复杂且艰难的挑战。

当然,阿里在底层大模型能力上的积累,为千问赋予了较强的技术底色,这可能是千问挑战AI应用市场最大的底气。

千问APP依托的是Qwen系列模型,并接入了通义实验室最强大的Qwen3-Max。自2023年全面开源以来,阿里旗下Qwen模型的全球下载量已突破6亿次,开源300多款模型,衍生模型突破17万个,超越美国Meta的Llama,成为全球第一的开源模型家族。目前,Qwen模型正成为不少硅谷初创公司的技术基石。

前段时间万亿参数模型Qwen3-Max的发布,更强化了阿里底层模型的技术支撑能力。11月初,Qwen3-Max-Thinking释出预览版本,在AIME 25等数学竞赛测试中刷得满分。

先模型、后产品,阿里在AI时代选择了一条相对稳妥的道路,而这和其本身作为“全栈式”玩家也有关系。阿里和谷歌一样,是全球少数构建了从底层芯片硬件、中间层模型架构到上层应用的互联网大厂,这种全栈技术能力的构建,往往需要长期的技术积累和巨额投入。

根基打稳了,造“入口”才更顺其自然,相对地,底层大模型能力越强,才更有机会在应用层吸引用户。

除了技术,阿里庞大的生态体系显然也为千问提供了丰富的场景,可以帮助其实现从对话到办事的跨越,而“能办事”,很可能将是阿里在C端市场打出的一个差异化特色。

集成了技术、业务和生态的优势,阿里或许能创造出一个成熟的AI产品,但在国内复杂的、激烈的AI应用赛道上,想要超越已经走在前头的对手并不容易。从数据来看,国内AI应用市场上,头部双强已经呈现出断层式领先的格局,尤其是豆包,成功逆袭了Deepseek,如今依然保持强劲的增长。

阿里系的AI产品,面对具备先发优势且势如破竹的豆包,就像一个“新手”,一如抖音刚开始做电商时面对阿里的模样,充满了宿命与轮回的意味。

根据QuestMobile公布的2025年三季度AI应用行业报告,字节跳动旗下豆包以1.72亿月活用户登顶榜首,力压Deepseek的1.44亿月活。腾讯元宝虽排在第三,但月活为3286万,与前两者已经不是一个量级。

至于曾经位居“AI四小强”的Kimi、智谱清言、MiniMax,这个季度集体下滑,Kimi已跌破千万大关。

当下,字节无疑是最有潜力的,它不仅拥有豆包,即梦的用户增长也非常迅速。重要的是,字节在AI时代的野心不仅仅是成为新的流量池,而是形成一个完整闭环,未来不需要再打开其他App或者浏览器,在这个闭环就能实现搜索、购物、消费等服务。

如果放任中国最大的流量池之一,做成新一代的超级入口,让传统电商真的变成“货架”,这恐怕会成为阿里的噩梦。

更何况,抖音电商埋头猛干,今年前十个月的支付GMV已经逼近拼多多,去年的广告收入已经超过阿里。

一边是AI的新入口之争,一边是电商基本盘的厮杀。如此一来,阿里和字节即将进入一场全面战争。但不同的是,这次字节更像那个强势的“守擂者”。

拿着技术找场景与在场景里搞技术

千问的面世,不单单是与其他大厂争夺AI时代的流量入口,它也承担着阿里构建起一个“大一统”的超级入口的期许。

未来作为阿里全栈生态系统的“中枢神经”,其有望打通阿里系内部支付、出行、购物、娱乐等核心场景,破除业务板块之间的壁垒,让阿里的各个生态协同性更强。

这对于用户而言,也是一次体验的变革。比如,你想规划周末亲子游,订门票、酒店、用余额宝支付,系统便可以在淘宝上比价下单,或自动完成跨平台协同,为你选择合适的方案。

乐观来看,阿里一旦掌握了入口,就掌握了流量,也掌握了话语权,再加上AI技术具有很强的穿透力,确实有可能串联起用户消费、生活的多个场景,精准匹配需求与服务,把流量的价值发挥到最大。最终实现单业务线难以达成的增长突破,为阿里带来新的活力。

但问题是,这是典型的“拿着技术找场景”的路子,付出的成本也会比字节更加大。

一方面,同样是AI和电商的结合,豆包+抖音电商VS千问+淘天,看似链路和逻辑一致,前端有入口、后端有供应链和货盘,内部协同好就是非常理想的生态闭环。

但问题在于,字节有中国最大的原生流量池,阿里没有。豆包和抖音电商,都是背靠抖音这个超级国民应用,业务和场景逐渐自然延伸。但阿里要完成这个闭环,先得把“千问”变成流量源,这显然不是有钱有技术有决心就能办到的事。

另一方面,追溯中国互联网产品的创新,“拿着技术找场景”,或者说有技术、缺场景,其实很难跨越用户习惯的鸿沟,把产品真正做起来。这是被无数互联网创业者验证过的共识。

阿里在移动互联网时代曾多次试图构建超级入口,尤其押注在社交上,先后推出了来往、钉钉、支付宝社交等等。可是,除钉钉外,几乎全线溃败。这不能完全归咎于阿里没有社交基因,无论支付宝还是淘宝,都手握巨大的流量池,但场景的缺失,是造成阿里无功而返的一个核心缘由。

在内容电商领域,阿里对内容生态的资源投入也没有换来显著的增长,反而抖音、小红书成功成为用户种草及消费的重要平台,这也同样印证了场景的缺失,无法高效承接起用户的大规模需求,改变用户心智。

在AI时代,一个应用能否成为爆款,往往也不是由技术因素全权决定的,技术、场景以及创新,缺一不可。

从产品策略上看,阿里更像是“三英战豆包”,千问、夸克、灵光各自赛马,或许有可能跑出一个高频的助手类工具应用。

但“通用入口”和“闭环交易”,也会有潜在冲突。越要做公共入口,就要越开放;但越要做交易闭环,就要建壁垒。 甚至可以说,开放的入口和商业的闭环可能是天然互斥的。当然,这对于想要通过消费链条变现的其他AI应用而言,也需要思考。

相较于阿里“拿着AI找场景找流量”,最终反哺电商。字节的逻辑更倾向于“在场景中搞AI”,基于短视频和社交的核心场景,培养和创造出AI应用,并在场景中不断更新与升级。

比如豆包,在抖音里,用户有浏览视频的需求场景,才有了豆包的 AI 总结、AI 弹幕、私信 AI 分身;创作者有了内容创作的需求场景,才有了输入关键词自动生成短视频文案、标题、脚本,和用户上传照片生成艺术风格视频封面等等。

所以,豆包的功能越来越强大,体验也相对丰富。只要它有成为下一个超级App的潜力,抢占用户的时间和注意力,那么它就是优质资产。

AI入口,能一举解决阿里的流量焦虑吗?

找到流量新入口,是阿里这十多年来的未竟之梦。

毕竟,基于电商的所有业务,几乎都在消耗流量,也很难形成新的自然流量。用户“买完即走”,使用时长低,这是先天基因决定。

所以,从“来往PK微信”,到“千问PK豆包”,一脉相承。

而且到了AI时代,入口竞争的烈度会更高。AI应用如果绕过电商平台直接完成消费,那么电商就变成了货盘供应商,平台传统的流量交易和广告收入都会受到影响。

这也能理解阿里对于AI to C入口抱有如此大的决心和期望。在移动互联网时代,它虽掌握着最大的电商交易场景,却始终未能打造出一个能够与微信、抖音抗衡的国民级App,也缺少一个占领用户时间、具备全局影响力的流量一级入口。

而这在当前可能会成为阿里在AI应用赛道上与其他大厂较量的一个不利因素。

近两年,在AI应用市场上,通过大规模投流,加速向C端用户渗透,抢占有利局势,是大多数互联网大厂和初创公司的共同选择。尤其是前者,前者豆包、后有元宝,它们的快速崛起都印证了当前AI应用的竞争还离不开流量争夺。

而随着字节、腾讯这两家国内互联网最大的流量池在电商和AI赛道的纵深推进,流量越来越不够分,因为存量流量池逐渐变成“自留地”,系统内部的生态和转化开始优先。这也意味着当阿里与字节、腾讯在电商和AI赛道的竞争关系不可避免地增强,未来向其他巨头花钱买优质用户和流量,会变得越来越困难。

不过,如果放大到全球市场,基于阿里最领先开源模型的口碑,可能会给其AI应用带来更多的海外流量,这是豆包和元宝所不具备的特殊优势。

AItoC之战,阿里不得不打,也不得不赢,但这可能会演变成一场旷日持久的全面战争,最后变成现金流消耗战。

从账面上看,字节和阿里两家都有非常充足的粮草储备,并且在AI投入上的决心和力度都非常强。

阿里在此前宣布,要在未来3年向AI及相关云计算领域投入3800亿元,未来或许还将进一步加大资金投入力度。

字节在这个领域的投入要更加恐怖。根据券商研报,字节研发投入显著领先同行, 其2024年资本开支达到800亿元,接近百度、阿里、腾讯的总和(约1000亿元)。有分析称,2025年翻倍到达1600亿元。

但变量在于,阿里今年同时在外卖、AI两个领域开战。双线作战,同时重投,即使是阿里这个向来不缺钱的巨头,资金压力也明显上升。

根据阿里最新发布的2026财年第二季度财报,本季度,集团经营利润同比骤降85%至53.65亿元,经调整EBITA(息税及摊销前利润)也同比下降78%至90.73亿元。这不得不归咎于外卖。据海豚投研测算,闪购导致的净亏损约360亿上下,吞掉电商板块近80%的利润。

此外,阿里的现金储备接连下降,到这个季度已经被拼多多超越。根据数据,截至2025年9月30日,拼多多现金、现金等价物及短期投资为人民币4238亿元,而阿里的现金储备下降至3736亿元。 

相比之下,字节要更加游刃有余。超过500亿美元现金储备,资产负债率低于20%,靠自身盈利支撑AI投入和股票回购,不用依赖外部融资。

而且,阿里目前显然并不止字节一个对手。电商基本盘,要不断防守拼多多、抖音、京东;新开辟的外卖,变成了和美团京东打持久消耗战;AI上腾讯、字节、百度强敌环绕。这场争斗的烈度,很有可能前所未见。

新的变量,或许已在酝酿,随时会颠覆现在的所谓格局,谁也无法掉以轻心。尤其对阿里来说,这将是一场前所未有的艰难战役。

原文链接: 抢占AI入口,阿里无法回避与字节的全面战争
站长:程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
朱雀AI检测助手朱雀AI检测助手
🔥 热门文章
1
B 站上 DeepSeek 闹鱼灾了,我发起《大肥鱼清除计划》!
480
2
Vibe Coding 实战:从零构建现代专业级 AI 搜索引擎
430
3
我的第一个出海产品!7 天 2 万
370
4
又一个国产版 Codex 神器,也来卷办公了!
370
5
day3-如何写出一个高质量的 Skill(组内分享) 高质量 Skill 不是“一个调得很顺的巨型 Prompt”,而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”,再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子,但方法是通用的。 --- 一、先想清楚:Skill 到底是什么 一个 Skill 至少包含四部分: 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做,每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办,而不是硬编一个看似合理的结果 高质量 Skill 的共同点:职责单一、接口清晰、规则可定位、输出可验证。 反例:把几十条经验全塞进一个主 Prompt,改一条规则要重调整个 Prompt,评估时也不知道是哪条规则退化。 --- 二、核心方法:先建评估,再写 Skill 不要先写转换器再补测试。正确顺序是: 1. 定义输出契约:什么算合法、什么算合格; 2. 建金标准集:一小批人工认可“可放行”的样本; 3. 先写评估 Skill:让它在金标准集上跑出基线; 4. 再迭代生成 Skill:每次修改跑同一套评估,无退化且目标维度提升才算正向。 这就是评估驱动开发:评估是 Skill 的单元测试,金标准集是回归锚点。 --- 三、评估 Skill:三层门禁,逐层递进 前一层不过,后一层不跑。每层留可追溯证据。 第 1 层:确定性硬门禁 用解析器、Schema、校验器完成,不消耗模型成本。 · 输出可解析; · 必填字段齐全,类型/枚举合法; · 引用目标存在,无悬空引用、无不可达节点; · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层:语义断言 用脚本 + 结构遍历检查“逻辑对不对”,仍然保持确定性。 通用检查项: · 覆盖率:源材料里的关键步骤、分支、条件,输出里是否都有对应? · 完整性:每个判断节点是否都有明确出口?有没有死胡同? · 可达性:每条路径是否都能到达预期终点?有没有无出口循环? · 顺序与依赖:有先后依赖的操作,是否保留了顺序?有没有被拍平成无序列表? 例子:故障诊断转换中,检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层:LLM-as-Judge 只处理解析器表达不了的维度:忠实度、完整性、可执行性。 但 Judge 会漂移,不能单独放行,必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化,换模型必须用金标准集重新校准。 通用 Judge 维度: 维度 问什么 忠实度 输出是否忠实源材料意图?有没有自行发明内容? 完整性 关键步骤、条件、证据是否保留?隐式知识有没有被压成空话? 收敛性 输出是否仍指向原目标,而不是发散? 可执行性 下游不依赖源材料能否直接使用? --- 四、金标准集:回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子,扩到 15~30 份,覆盖失败模式而非随机抽样: · 完整正例:典型流程; · 边界/异常分支:异常路径、循环、前置失败回退; · 已知易错模式:实际踩过的坑; · 留出集:不参与调优,只用于最终验收,防过拟合。 金标准不需要完美,只需要当前标准下认可可放行。 回归指标:关键路径用 pass^k(k 次全过),稳定性用 pass@k。 --- 五、工程约束:让批量产出可重放 · 幂等:同输入 + 同 Skill 版本 + 同规则 → 输出一致,否则无法判断变好是 Skill 改了还是随机波动; · 隔离不阻断:单份失败进隔离队列,记录失败层和原因,不阻塞其余; · 版本绑定:规则、rubric、金标准集进 Git;每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”; · 抽样人工复核:Judge 临界样本 + 易错模式,人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅,写清:输入约定、输出契约、分步流程、硬规则、降级策略; · 经验规则放 references/ 或 rules/,按失败模式分类,不要全塞进主 Prompt; · 不确定时标 needs_review: true,不要硬编看似合理的结果; · 迭代由评估报告驱动:报告告诉你哪层挂了、哪类失败模式,你改对应规则文件,而不是漫无目的调 Prompt。 --- 七、落地顺序(不要反过来) 1. 固化输出契约:Schema + 结构约束; 2. 建金标准集:从已认可的 + 最易出错的样本开始; 3. 先写评估 Skill:跑出基线报告; 4. 再迭代生成 Skill:每次修改对比逐项通过率,无退化且目标提升才算正向; 5. 批量运行 + 隔离回放:失败进队列,结束后人工抽检; 6. 评估 Skill 自身版本化:换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”:每次修改必须附评估报告对比,逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数:前两层挂了,Judge 分数没有意义。 3. 不许把规则堆进主 Prompt:规则按失败模式分文件,评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”,评估 Skill 决定“敢不敢用”。 先让评估体系站稳,再让生成器迭代。这样交付的不是一堆“看起来还行”的产出,而是一套可证明、可回归、可交接的 Skill 质量体系。
340
6
DeepSeek 重磅开源的超级 Agent,到底是个啥?
330
7
最近在落地 AI Native 项目,卡在团队资产协同这块,想请教下社区各位有实际落地经验的同学: 我们现在的资产分为三块:项目文档(PRD/ADR/ 运行手册)、Agent Skill(业务技能、执行 SOP、提示词包)、MCP 工具服务定义。 目标是做到:人和多 Agent 共用一套可信资料源,Skill、MCP 配置、项目文档能够版本化、同步、共享、可评审。 目前我们初步方案是用 Git 做底层版本主线: - 文档:Markdown + ADR,带元信息,支持 RAG 检索 - Skill:单技能包目录化,带版本、评估用例、依赖声明 - MCP:项目级声明文件纳入 Git 但实际协作里遇到不少疑问,想参考大家成熟的实践: 1. 大家团队里,文档、Skill、MCP 三者是怎么组织目录和版本管理的?有没有稳定的仓库结构模板? 2. 多人协作时,Skill 的变更评审、灰度升级、依赖管理怎么做?如何避免本地版本不一致、“本地能跑别人不行”? 3. MCP 是统一中心化网关模式,还是大家各自本地启动 + git 同步配置?权限白名单、调用审计这块有什么好方案? 4. 有没有成熟工具链做自动同步(类似 agentmeld /teamai-cli)、变更校验、eval 回归门禁? 5. 文档和 Agent 的打通:哪些文档放进 Git 作为可信真值,哪些放外部知识库,边界怎么划分? 如果有现成的仓库样例、目录规范、团队协作流程,非常希望能分享参考,感谢!
280
8
PHP 被曝两大致命漏洞,请所有程序员抓紧做这件事!
280
9
人工智能前沿部署工程师(FDE) · 概 览 与 方 法 论
270
10
QuireKit 编辑器的 AI-Native 是如何设计的?谈谈我对真正 AI-Native 的理解
250
11
告别“金鱼记忆”:我开发了一款能当“第二大脑”的浏览器 AI 助手
250
12
ARTS 1101: 最长回文串与子序列匹配、一次 URL 请求的来回之旅与如何验证 AI 的交付
230