Inside Zipline's Autonomous System: 140M Miles, Zero Incidents
Sequoia Training Data · 2026-07-08

Zipline 联合创始人:无人机只占系统复杂度的 15%,我们花了 8 年才进入美国,现在目标是比 Waymo 安全 2 倍,即将每天完成 100 万次配送。
从血库到外卖:Zipline 的起源与核心洞察
- Zipline 2011 年成立,2014 年转型,2016 年在 卢旺达 启动商业服务,最初只配送 血液 给医院。当时在美国飞行是 非法的,所以选择在监管更灵活、需求更迫切的国家起步。
- 早期最大的教训:无人机只占系统复杂度的 15%。团队原以为造出酷炫的飞机就行,结果前 9 个月只服务了 1 家医院(合同签了 21 家)。他们被迫自建库存管理、与民航局集成、与医疗系统对接等 85% 的辅助系统。
- 关键客户反馈:医生和实验室技师说“人们 24/7 都会生病,为什么你们只营业 12 小时?” 这促使 Zipline 在第一年内就实现了 24/7 全天候运营,并成为公司“客户痴迷”文化的基石。
- 当前规模:已覆盖 8 个国家、服务 5000 家医院,累计飞行 1.4 亿英里(相当于在美国每条路上开 30 多遍),完成 250 万次配送,零安全事故。宾夕法尼亚大学研究显示,Zipline 使 孕产妇死亡率降低 51%,每年拯救 1 万到 1.2 万 条生命。
硬件自研与安全:从“15%”到“100%”的垂直整合
- 700 个自研组件:飞机上有 700 个独特部件、43 个主要子系统,全部由 Zipline 从头设计,包括飞行计算机、电机、电池管理系统、配送舱(自带 NVIDIA GPU 的 AI 自主系统)等。因为市面上买不到所需 推重比 的电机。
- 双飞行计算机 + 仲裁器:飞机有两台飞行计算机,都认为自己“在飞”,同时接收传感器数据并发送指令。一个 仲裁器 监控两者健康,决定谁“说了算”。若仲裁器失效,主计算机继续飞行。几周前刚发生过一次主计算机故障,自动切换后飞机安全返航。
- 安全目标:比 Waymo 安全 2 倍:Zipline 原目标是比汽车安全 10 倍,但董事会成员 Alfred 认为“汽车是过时技术”,要求对标 Waymo(约比汽车安全 10 倍)。Zipline 今年底的目标是 比 Waymo 安全 2 倍。目前 1.4 亿英里零事故,而同等里程汽车驾驶预计会导致 600 起事故、100 人受伤、2-6 人死亡。
- 极端环境测试:飞机在 49°C(凤凰城夏季)到 -25°C(美国北部)下运营。测试不只是“通过”,而是 故意把部件搞坏,看它如何失效,从而改进设计。单个飞机已累计飞行 超过 100 万英里。
从“1 对 1”到“1 对 100”:运营系统的进化
- 配送精度:飞机在 100 米 高空悬停,利用 实时差分 GNSS(厘米级精度)和配送舱上的 NVIDIA GPU 自主感知系统,识别最佳落点(如避开桌上的饮料),然后降下配送舱,触地开门,留下包裹后收回。配送舱还能在 X/Y 轴 上自主调整位置。
- 从“飞行员”到“舰队指挥官”:受《安德的游戏》启发,Zipline 将监控人员改称 “舰队指挥官”。从最初 1 人看 1 架飞机,到如今 1 人管理 100 架,并计划继续扩大比例。人类角色从“操作者”升级为“战略管理者”。
- 规模化的新挑战:Zipline 花了近 10 年 才完成第一个 100 万次 配送,但很快将实现 每天 100 万次 配送。这意味着百万分之一概率的事件将 每天发生,维护、软件系统、流程都必须彻底重构。Zipline 正在投资“制造机器的机器”。
- 空中交通管制变革:Zipline 未来每天飞行量将超过 美国所有航空公司总和(目前最大航司每天约 5000 架次)。他们正在与 FAA 合作,推动飞机间 直接通信、自动冲突检测(“你上我下”),并参与制定行业标准。美国 50% 的空中交通管制员超过 45 岁,20% 即将退休,劳动力危机倒逼改革。
带走一句话
“我们做这件事,不是因为容易,而是因为我们以为它会很容易。”——Keller Rinaudo(Zipline 联合创始人)
- 做 AI 硬件的,别只盯着模型:Zipline 的“15% 无人机”教训对所有 AI 机器人公司都适用。真正的壁垒在 85% 的辅助系统(集成、运维、合规、供应链)。如果你只做“核心算法”,最终会被这些“脏活累活”拖垮。
- 安全不是“够用”,而是“知道怎么坏”:Zipline 的测试哲学值得借鉴——不是验证“没问题”,而是 主动寻找失效模式。做自动驾驶或任何 AI 系统,应该把“如何安全地失败”作为设计输入,而不是事后补救。
- 规模化会暴露所有“百万分之一”的问题:当你的系统从百万次增长到每天百万次,所有罕见故障都会变成日常。这要求从一开始就设计 冗余和容错机制(如双飞行计算机),而不是等到出事后才补。
