滴滴开放 AI 打车之后，我最想问的不是技术，而是这产品到底成不成立

滴滴把 didi-ride-skill 放出来之后，很多人的第一反应大概都是：AI 终于也能打车了。

但说实话，如果讨论只停在这里，我觉得有点浅。

因为这件事真正有意思的地方，不是“又多了一个能调用的工具”，而是它第一次把 AI 助手往一个特别现实、也特别容易翻车的产品场景里推了一步。

打车不是写诗，不是陪聊，也不是查资料。

它是一个目标非常明确、结果非常具体、用户容错率也非常低的场景。

你叫错车、叫错时间、叫错地点，用户不会觉得“模型偶尔犯错也正常”，只会转头把 App 打开，自己下单。

所以我更想从产品经理的角度拆这件事，而不是把它当成一条技术新闻看。

这篇主要讲三件事：

1. 这个 Skill 解决的到底是不是一个真实需求
2. 它的产品关键路径在哪里
3. 为什么“一句话叫车”听起来简单，落地却不轻松

先看需求：它解决的是不是一个真问题

先说结论：我认为这是一个很成立的方向，而且是少数一眼就能看出价值的 AI 入口。

原因也不复杂。

打车本来就是一个高频、低决策成本、强时效的任务。

大多数时候，用户不是想“使用滴滴”，而是想尽快完成一件事：

• 去公司
• 去机场
• 去约定地点
• 查一下司机到哪了
• 预约明天的行程

这类任务最大的特点就是，目标明确，路径越短越好。

这也是为什么“对话式入口”在打车场景里有天然吸引力。

用户未必在乎背后是不是 AI，他在乎的是能不能少点几步，少切一个 App，少输一遍地址。

从这个角度看，滴滴开放 Skill，切的不是“地图问答”那种泛信息需求，而是“我现在就要出发”这种强执行需求。

它开放的其实不是一个接口，而是一条服务链路

按照目前公开的信息，滴滴这次开放出来的不是单点能力，而是一整套围绕打车流程组织过的服务能力。

站在产品侧看，这意味着它开放的不是一个按钮，而是一条完整链路。

这里真正值得看的是，它把一条原本在 App 内完成的服务链路，搬到了 AI 对话里。

如果只是开放一个“创建订单”的接口，其实产品价值没那么大。

因为用户在真正下单前，往往还要先完成几个动作：说清楚去哪、什么时候走、选什么车型、价格大概多少、现在要不要下单。

这些动作没接住，所谓“AI 打车”就只是把表单换了个入口。

从产品路径看，核心不是下单，而是缩短任务完成链路

如果用产品经理最熟悉的视角来看，这个 Skill 的核心目标其实只有一句话：

把“从产生出行意图到完成下单”的路径缩到最短。

传统 App 的路径通常是这样的：

1. 打开 App
2. 等待定位
3. 输入目的地
4. 选择车型
5. 查看价格
6. 确认下单

如果换成 AI 入口，理想状态是：

1. 理解需求
2. 补全参数
3. 给出预估
4. 请求确认
5. 发起下单
6. 持续跟踪
7. 处理变化

产品上真正有意义的，不是把原来的 6 步机械替换成 7 段对话。

而是看它能不能在用户几乎不费脑的前提下，把必要参数补齐，再把确认成本压低。

这决定了它到底是一个“新入口”，还是一个“新负担”。

真正决定这件事能不能成的，是三个产品环节

如果我是这个能力的产品经理，我会重点盯下面三个环节。

1. 意图识别是不是够快

用户说“帮我叫个车去机场”，系统到底能不能立刻识别这是一个打车意图，而不是路线咨询、旅游推荐，或者日程提醒的前置问题。

对话入口的第一个门槛，从来不是功能有没有，而是识别是否足够准。如果第一步就判断错，后面路径越长，损耗越大。

2. 补参过程会不会把用户聊烦

打车不是填写调研问卷。用户要的是效率，不是沉浸式聊天。

所以补充信息这一步很考验产品设计。该问的一定要问，不该问的就不要问。能从历史地址拿到的，不要再让用户重复输入。能通过上下文推断的，也别一轮一轮确认。

3. 确认节点要不要收得更克制

涉及真实下单的场景，确认一定要有，但确认太多也会把体验打碎。

最理想的状态不是“每一步都问你一遍”，而是把确认压缩到临门一脚。比如在价格、时间、车型都明确后，给用户一个清晰的确认摘要，然后一次性完成操作。

如果这件事做好了，体验应该是什么样

如果这套 Skill 最终真的要形成稳定体验，我觉得对话应该接近下面这种状态：

我：明天早上 6 点半帮我叫车去虹桥机场
助手：从哪个地址出发？你常用地址里有“家”和“公司”
我：从家走
助手：明天 6:30 从家到虹桥机场，快车预估 78 到 95 元，预计 42 分钟。要帮你预约吗？
我：要
助手：已经预约成功，后续有司机接单我再提醒你

这段体验的价值不在于“像人聊天”，而在于它把用户最关心的几个节点都接住了：

• 只在必要的时候追问
• 快速给到可判断的信息
• 先预估，再确认
• 下单后还能继续服务，不是做完就结束

难点也很清楚：这个场景太容易翻车了

如果从产品落地看，这件事最难的地方不是“把接口接出来”，而是处理那些最容易让体验崩掉的边界场景。

比如这些情况都不算少见：

• 用户说“去国贸”，但一个城市里可能不止一个“国贸”
• 用户说“现在叫车”，但定位权限、出发点、支付方式还没准备好
• 用户在下单后改口，说“算了，换成专车”
• 用户同时提到多件事，比如“先看看附近咖啡店，再叫车过去”
• 用户把打车和其他安排串在一起，比如“我 8 点有会，帮我算一下几点该出门”

这些问题看着像模型理解问题，实际上很多都是产品定义问题。

该不该自动推进，推进到哪一步该停，什么场景必须确认，什么场景允许默认，这些都需要明确规则。

换句话说，这不是一个“模型越聪明越好”的问题，而是一个“产品边界划得准不准”的问题。

如果我是 PM，我会先盯这几个指标

如果我是产品经理，我不会先盯“用户觉得酷不酷”，我会先看几个更硬的指标：

• 意图识别成功率
• 从用户首次表达，到完成下单的平均轮次
• 因地址歧义、时间歧义导致的中断率
• 下单前确认后的取消率
• 下单成功后的查单、跟踪使用率

这些指标合起来，基本就能看出这条链路到底顺不顺。

尤其是“平均轮次”这个指标，我会特别在意。

因为很多对话产品的问题不是不能完成任务，而是完成得太磨叽。

用户能接受 AI 帮他多想一步，但不太能接受它陪自己聊八轮天才把车叫上。

怎么使用

如果你想自己试，可以按现在公开的方式接入：

1
2
3
4

1. 在支持 MCP / Skill 的 AI 助手里添加 didi-ride-skill
2. 也可以去 ClawHub 搜索 didi-ride-skill 安装
3. 按提示申请并配置 MCP Key
4. 完成授权后，就可以在对话里直接发起打车、预约和查单

相关链接

还有一个容易被忽略的点：Skill 本身也是产品设计

从这个角度再回头看，Skill 这件事本身就不只是技术封装，它也是产品封装。

它其实在定义一件事：AI 助手在出行场景里应该管到哪，停在哪，什么时候代办，什么时候只辅助。

这比单纯开放几个 API 更重要。因为真正决定体验的，不是能力列表，而是产品怎么把这些能力编排进用户旅程。

最后说我的判断

如果从产品经理视角总结，我会觉得滴滴这次开放打车 Skill 值得看，不是因为它证明了 AI 多先进，而是因为它选了一个特别适合检验产品能力的场景。

这个场景用户需求明确，路径短，价值感知强，错误成本也真实存在。

做得好，用户会很快形成习惯。

做不好，用户也会毫不犹豫退回原来的 App 路径。

所以它的价值不在“一句话叫车”这句宣传语本身。

真正值得看的，是它有没有机会把“出行意图到下单完成”这条路径，真的重新设计一遍。

本文基于滴滴出行公开发布信息整理与延伸分析。