6月22日消息,字节跳动旗下 AI 聊天应用豆包(Doubao)在北京、杭州上线打车功能灰度测试,由曹操出行作为独家出行服务提供商。用户可在豆包对话框中用自然语言发起打车请求("帮我叫辆车去首都机场"),大模型自动识别上下车点、人数和偏好,完成路线规划、费用预估和车型推荐,确认后一键下单,全程不跳转第三方 App。司机端接入豆包专属订单通道,每单额外获得2元平台激励。这是字节跳动继抖音电商、团购之后在本地生活领域的又一次扩展,但时间节点值得注意——阿里千问+高德打车的同类功能已于3月23日上线并覆盖20+城市,滴滴 AI 助手"小滴"更早在3月17日发布 v1.0。 产品机制:对话式叫车 + 独家运力绑定
豆包打车的产品逻辑是"AI 聊天入口 + 单一运力提供商"。用户在对话界面口述需求,大模型做意图解析和参数提取,调用曹操出行的运力接口完成派单。曹操出行是唯一供给侧合作方,这意味着用户在豆包内看不到多平台比价,也无法选择其他网约车服务商。
这一设计与千问打车的架构有本质区别。千问接入的是高德打车聚合平台,后端连接多家出行服务商(包括首汽约车、T3出行、享道出行等),用户可获得多运力池的供给覆盖。代价是聚合模式引入了更多中间层:用户→千问→高德→具体服务商→司机,链条每多一层,权责归属就模糊一层。千问上线后黑猫投诉平台上已出现"AI自作主张选商务车""预估价与实际扣费差距大"等反馈。
豆包选择独家绑定曹操出行,短期内简化了服务链条和纠纷归属(只有豆包和曹操两个主体),但也意味着运力天花板被锁定在曹操一家的供给能力上。曹操出行目前在全国62座城市运营,累计服务用户超1.4亿,但市场份额远低于滴滴。在北京这种高峰期运力紧张的城市,单一供给商能否保证响应速度和覆盖密度,是灰度测试需要验证的核心问题。
竞品时间线:字节是第三个入场的
2026年上半年,"AI 聊天应用 + 打车"已经成为中国互联网的标准动作,三大玩家的入场节奏如下。
滴滴最先动手。2025年9月 AI 出行助手开始公测,2026年3月17日"小滴" v1.0 正式上线,支持90多个服务标签(空气清新、驾驶平稳、后排宽敞等),覆盖搜附近、预约叫车、组合出行、订单查询等高频功能。滴滴的优势在于自营运力池+十几年运营数据沉淀,AI 匹配直接作用于调度引擎。据滴滴公布的运营数据,个性化叫车需求中"又快又便宜"占57%、"空气清新"占12.5%、"最近的车"占9.9%。
阿里千问3月23日上线打车功能,通过高德打车聚合平台接入运力,已覆盖北上广深等20+城市,支持一句话选车型、添加途经点、预约时间。用支付宝 AI 付完成支付。千问的差异化在于将打车嵌入阿里本地生活生态——飞猪管出行、淘宝管购物、饿了么管外卖、大麦管演出,理论上可以在一个对话框里串联"订票→打车→吃饭"的完整链路。
豆包6月22日入场,比千问晚整整3个月。字节跳动没有自己的地图/导航产品(对比阿里有高德),也没有现成的出行运力(对比滴滴的自营车队),选择与曹操出行做独家绑定是补足供给侧短板的最直接路径。但这也意味着豆包在出行场景的生态深度目前不如千问+高德和滴滴+小滴。
海外的类似动作也在同步推进:OpenAI 已完成 ChatGPT 与 Uber、DoorDash、Spotify 的集成;Google 为 Gemini 推出自动化功能,支持在 Pixel 10 和 Samsung Galaxy S26 上执行叫 Uber 等多步骤任务。 曹操出行的战略账:AI 转型 + Robotaxi 铺垫
从曹操出行的视角看,接入豆包不仅是获取一个新的流量入口。6月9日,曹操出行宣布成立独立 AI 事业部,启动全面 AI 转型。上周在2026国际汽车及供应链博览会(香港)上发布 RoboX 战略,提出"双十万计划"——到2030年累计部署10万辆 Robotaxi 和10万辆 Robovan。公司近期被纳入港交所科技100指数。
与豆包的合作可以理解为 RoboX 战略的前置验证:先通过人类司机运营的网约车接入 AI 聊天入口,跑通"对话式叫车→自动派单→履约→支付"的全链路,再逐步替换为 Robotaxi 运力。如果这条路径成立,豆包未来可能成为曹操 Robotaxi 服务的 C 端入口之一。
但这也是一个"赌注对赌注"的结构——曹操赌豆包能带来有效增量流量,字节赌曹操能提供稳定的运力和服务质量。双方目前的绑定是独家的,但灰度测试阶段的独家与全量开放阶段的独家有本质区别。如果灰度数据不达预期(响应时间、覆盖率、用户留存),双方都有动力调整合作模式。
三个结构性限制
第一,字节缺少地图基建。阿里有高德,腾讯有腾讯地图,百度有百度地图,字节跳动在地图/导航领域没有自有产品。打车功能的核心依赖——定位精度、路线规划、ETA 预估——需要依赖第三方地图服务。这不只是技术接口的问题,更是数据闭环的问题:字节无法像阿里(千问+高德)那样在地图数据、POI 数据和出行数据之间建立内部反馈循环来持续优化匹配准确率。当用户说"打车去五道口",地址解析的准确性取决于底层地图引擎,而这个引擎不在字节的控制范围内。
第二,独家绑定限制了供给弹性。曹操出行62城运营的覆盖面不算小,但与滴滴的规模差距明显。特别是在高峰时段和低线城市,单一运力源的响应能力是硬约束。千问接入高德聚合平台虽然引入了权责模糊的问题,但在供给侧提供了多运力池的冗余。豆包如果未来想扩展到更多城市或增加运力合作方,独家绑定的模式需要重新谈判。灰度阶段的"独家"更像是双方试水的低成本承诺,不太可能成为长期架构。
第三,AI 打车的核心竞争力可能不在"AI"本身。千问上线3个月后的实际反馈显示,对话式叫车的核心痛点不是"能不能用自然语言叫车"(这一步所有大模型都能做到),而是意图理解到调度执行之间的精度gap——AI 听懂了"经济型+空气清新",但派来的是商务别克。这不是 NLU 的问题,是 AI 输出到运力系统的参数映射和调度优先级的问题。豆包作为后来者,能否从千问的落地教训中学到什么并在产品层面做出差异化改进,比"谁先上线"更重要。滴滴"小滴"在这个维度上有天然优势——AI 直接嵌入自有调度引擎,不存在跨平台参数映射的损耗。