DoorDash 放出一段 dd-cli 演示视频:点三份沙拉,先要读一条 Slack 消息,调出记忆里的偏好,解析菜单 JSON,再跑一段 Python 算总价。屏幕上还蹦出一个编造出来的词——“Flibbertigibbeting”。
这画面像极了程序员圈那张经典漫画:一句话能干的事,非要写成一段代码才觉得体面。dd-cli 确实冲着这个梗去,但它真正要测试的,是能不能让 AI Agent 直接替人下单买东西。
dd-cli 能干什么,谁能用
现在能用到它的人很少。
| 维度 | 现状 |
|---|---|
| 地区 | 美国、加拿大 |
| 系统 | 仅 macOS |
| 开放方式 | 候补名单,非公开注册即用 |
| 核心能力 | 搜索商店、查优惠、建购物车、结账下单 |
| 调用方 | 开发者手动调用 + AI Agent 调用 |
候补名单目前只覆盖 macOS,Windows 和 Linux 开发者暂时用不了。官方注册表单还专门问“你想拿它做什么”,更像是在收集用例,不是急着推给普通用户。
拿到测试资格的开发者,现实点的用法是先在自己的脚本或 Agent 项目里把下单流程跑通,别急着接生产环境和真实信用卡——支付授权、误下单之后怎么处理,DoorDash 都还没公开说明。
终端是幌子,接口才是生意
命令行本身不新鲜,程序员用它点外卖也谈不上多提效。真正该盯的是,DoorDash 把下单这件事做成了一个 AI Agent 能直接调用的接口。
这已经不是 DoorDash 第一次试探代理式商业了。
| 渠道 | 交互形式 | 面向对象 |
|---|---|---|
| iMessage 试点 | 短信对话里下单 | 普通消费者 |
| Ask DoorDash | 聊天机器人问答下单 | 普通消费者 |
| 接入 ChatGPT / Claude | 第三方 Agent 调用 DoorDash | 用 ChatGPT、Claude 的用户 |
| dd-cli | 命令行 / 脚本调用 | 开发者、AI Agent |
从这条链路看,方向很清楚:从消费者对话入口(iMessage、Ask DoorDash),一路下沉到开发者可编程接口(dd-cli)。谁先把交易能力封装成一个干净的接口,谁就更容易被别的 Agent、别的产品调用,而不是被绕过去。
入口让出去,谁该盯紧什么
这轮测试还没说清三件事:支付授权怎么给、下错单谁能改、退款算谁的责任。这些目前是悬而未决的问题,不是已经发生的事故。
| 对象 | 该盯的风险 | 现实动作 |
|---|---|---|
| 拿到测试资格的开发者 | 支付授权、误下单、退款责任还没公开 | 先在测试环境走通流程,别急着接生产订单和真实信用卡 |
| 商家 | Agent 下单会不会绕开优惠位、评价曝光,规则未知 | 先观望,等 DoorDash 公开商家端细节再决定要不要适配 |
| 普通消费者 | 目前用不到,基本不受影响 | 不需要现在做任何决定 |
外卖平台的护城河从来不是配送本身,是它卡在用户和商家中间收的那点信息差和抽成。入口挪到 Agent 手里以后,DoorDash 要面对的问题是:如果订单能被 ChatGPT、Claude,甚至一段 Python 脚本代下,这道“必须经过我”的墙还能立多久——现在还看不清。
回到那段沙拉演示。过度工程化的段子背后,DoorDash 是认真的:它想在“App 之后是什么”这道题上,抢先占一个答案。终端只是它扔出来试水的第一个壳,拿到候补资格的人,大概率不会用它点今晚的外卖,而是拿它给自己的 Agent 项目接一条能下单的路。