无人配送研究 · 无人运力组织研究 04

卖车、卖软件、卖运力：无人配送到底在卖什么？

同一辆车，四张报价单。真正拉开差距的，是谁负责把最后那件麻烦事做完。

大家好，我是王小珲，这里是【无人配送研究】。

我们沿着一票货，把技术、生意和组织里的问题慢慢讲透。

欢迎关注、点亮⭐️星标；

忙着赶路、不方便看文字的朋友，也可以点标题后面的🎧耳机，听语音一起聊。

图01｜研究示意｜以钥匙、软件模块与货物表现不同交易承诺。

假设一家区域配送公司，准备给仓库和门店之间加一辆无人车。四家供应商坐下来，开口都很亲切：“这个方案，每个月花不了多少钱。”

第一家说，车买回去就是自己的；第二家说，不用买，按月租；第三家说，我只收自动驾驶服务费；第四家一拍胸脯，按完成的运输任务结算。听着像四条路，走到月底，财务却发现：有的账单里没有车，有的没有人，有的有车有人，唯独没有承诺今天这批货一定送完。

这不是文字游戏。一次采购究竟买到什么，决定了谁先掏钱、谁怕车闲着、谁处理夜里的故障，以及合作结束以后，谁把车拉走、谁把账留下。

我想先把判断摆在桌面上：无人配送的商业模式，要沿着合同里的交付物和持续责任来辨认。招牌可以写得很大，账最终还得一笔一笔对。今天就把这几张报价单，放到同一张桌子上。

PART 01

先别问哪种模式先进，先问买到哪一层

卖车，首先交付的是设备及约定功能；租车，首先提供的是一段时间内的车辆使用安排；卖软件，交付的可能是许可、订阅、接口、部署和持续更新；卖运力，才进一步涉及约定运输任务的承接与完成。这里的“首先”很重要：一份合同经常把几层内容打包，不能望文生义。

一辆整车可以连着三年软件服务出售，也可以由运营商买走，再按月出租给网点；运营商还可以拿同一批车，白天跑固定线路，空闲时段承接按次订单。同一辆车，处在几份合同中，不同参与方各自卖不同的东西，毫不稀奇。

反过来，按月收费也不必然就是租赁。客户也许只是购买每月固定班次的运输服务，车辆由服务商自由调换。收费周期回答的是“何时收钱”，交付对象回答的是“凭什么收钱”，两者不是同一道题。

所以我会先写三行：客户拿到什么；供应商持续保证什么；出现偏差时，客户能够要求什么。三行写清，很多令人眼花缭乱的英文缩写，就会安静下来。

看模式，先看承诺；比价格，先对范围。不能拿一个软件账号的月费，去压一份包含车辆、维保和现场保障的报价。这好比只买了一包茶叶，却嫌隔壁茶馆把房租也算进去。

图02｜原创研究图解｜四类交付物可以组合提供。

PART 02

企业可以走几条路，研究别急着替它选边

曹操出行2026年7月15日的官方消息，明确同时列出了车辆销售、租赁和RaaS模式。这条披露足以说明，多种交易方式可以共存。它并没有公开每类合同的完整服务边界，也不能直接证明每种方式都已经盈利。

九识天穹开放平台公开介绍了专用车改制、智驾联合开发、生态合作等安排。其中Zelos Inside指向技术合作，但这也不等于把一个软件安装包发过去、双方就各自下班。平台对相关合作的描述，还包括整车工程与场景配合。具体谁做什么，仍须落到项目文件。

这些原始披露，让我更愿意把行业画成一张交叉的路网。技术企业可以向整车伙伴供能力，整车伙伴向资产公司供车，运营商再向客户供服务。一个公司也可能占据其中几段。

把某家企业永久归为“只卖车”，把另一家永久归为“只卖运力”，容易写得热闹，却可能把变化中的生意写僵。更稳妥的比较单位，是具体产品、具体合同、具体城市和具体阶段。

公开消息能证明企业提出了什么、披露了什么。要判断客户实际买到了什么，还得看订单附件、验收单和服务记录。本文没有取得可公开核验的完整客户合同，下文因此用明确标注的合成案例拆结构，不把演算冒充真实经营样本。

图03｜曹操出行2026年7月15日官方消息配图。

PART 03

买车：钥匙交了，事情未必交完

买车的吸引力很直接：有稳定货源、有管理团队，愿意承担前期投入，长期使用的成本就有机会摊薄。车辆还可成为自己组织运力的基础，不必每次都向外部供应商抢时段。

不过，整车验收必须回答“在什么条件下可用”。适用区域、道路、时段、载荷、天气边界，以及软硬件版本，都是交付条件的一部分。今天在验收线路上跑通，并不自动覆盖明天新增的全部业务。

车主还要关心几个慢问题：软件到期以后还能做什么；关键传感器坏了由谁更换；电池衰减怎样处理；版本升级是否收费；原有服务停供时，车辆是否有可行的迁移方案。购买设备，往往意味着也买进一条持续依赖链。

这并不意味着销售模式一定“甩手”。供应商完全可以把维保、远程支持、替代车辆和响应时间写进长期服务。真正需要警惕的，是客户以为买到了一套完整作业能力，合同却只保证交付一台设备。

残值也不能只凭想象。车况、零部件通用性、软件可转移条件、异地部署成本，都会影响二手接续使用。合同里一句“可回购”，还得往下看：谁回购、什么期限、按什么条件、对方届时有没有履行能力。纸上的退路，也需要能走。

PART 04

租车：把大额付款拆开，不等于把风险全部搬走

租赁能缓解一次性投入，也便于试用新线路。但客户仍可能承担空闲月份的租金、最低租期、超里程费用、退租整备和提前退出成本。有些方案包维保，有些只提供车辆；同样叫月租，服务厚薄可能差得很远。

顺丰同城2026年9月24日的公告提供了一个可核查例子：深圳智联与顺丰泰森订立无人车租赁框架，具体车辆数量、交付地点等由后续订单列明，按月结算；披露的通常月度单位租金为每台1500—5000元，因车型等条件而异。

同份公告给出的年度交易上限为2850万元。这里要踩一下刹车：上限不是已实现收入，更不是已经交付的车数。框架、具体订单、实际履行和结算，应分别观察。

这类信息的价值，在于把交易机制露出来一角。它不能替代一份适用于所有城市、所有车型的“行业价目表”，更不能据此推定装卸、保险、救援全都包含在月租内。公告没有说清的部分，研究也不要替它补齐。

客户真正要问的是：这辆车修三天，租金怎样计；替代车何时到；线路因外部条件暂停，谁承担等待；押金何时退。租金是开场白，停运条款常常才是正文。

PART 05

卖软件：轻的是供应商哪一端，重的是谁的哪一端

软件服务可以带来跨车型、跨场景复制的机会。客户已有车辆、工程能力和运营网络，购买自动驾驶能力，可能比重新搭建全套技术团队更合适。专业分工有它的价值。

但软件费只对应一部分投入。底盘接口、制动与转向控制、传感器布置、算力、通信链路、版本兼容、测试验证，以及上线后的异常处置，都需要有人接住。屏幕上一个“连接成功”，离实际运输可持续运行，还有很长一段工程路。

技术合作的合同，尤其要分清首次适配与持续服务：第一次车型适配由谁投入；以后换硬件版本怎样收费；新增路线是否需要额外工作；故障发生时，谁有权限调取哪些记录，谁牵头定位，谁负责恢复。

若每新增一台车都要重复大量现场开发，所谓软件复制的边际成本，就没有宣传页上那么轻。反过来，一套稳定接口和清楚的支持边界，也可能让技术供给与地方运营配合得更高效。

软件可以被订阅，工程责任不能靠订阅两个字省略。供应商的账面资产轻，不代表整条链条不需要投入。它可能只是把投入交给了制造伙伴、资产伙伴或客户。研究模式时，要顺着这笔钱继续往下找。

图04｜九识天穹开放平台公开的九识与宇通合作暨Z20量产下线仪式照片。

PART 06

卖运力：客户买结果，也得把结果写得出来

按运输任务付费，最容易让客户觉得省心。不想管车辆折旧、不想招一整套保障团队，只想在指定时段，把指定货物送到指定交接点。这是一种清晰的需求，不低级，也不天然高贵。

难点在“完成”两个字。车停到围栏外算到达，货卸进指定区域才算完成，还是收货人核对签收后才结束？三个节点，对客户可能是三种完全不同的价值，对供应商也是三套成本。

还要先定义一项任务的大小：一趟装多少，允许几个停靠点，最长等待多久，拒收后送回哪里。运输任务、车辆行程、包裹票数，不能混着用。一个多点行程可以服务几项任务，一项任务也可能因异常拆成几段行程。

如果按任务收费的服务，仍把装卸、交接、日常协调和每次异常兜底全部留给客户，客户买到的只是运输链的一段。它仍可能划算，只是不能在比较时把余下的人力当成已经消失。

反过来，供应商若承诺更完整的结果，就需要控制相应资源。既要对时效负责，又无法协调取货时间、装载和收货窗口，容易陷入“责任在我，开关在别人手里”的困境。运力服务的产品设计，实际是在给承诺配资源、配权限、配价格。

PART 07

先做责任矩阵，再算便宜了多少钱

我会给每份方案补一张责任矩阵。横着列买车、租车、软件合作、运力服务；竖着列车辆与残值、软件更新、维保、保险、装卸、调度、异常救援、停运安排。每一格都写主责方、配合方与交付证据。

这里的主责，是合同中的工作组织责任，不是替监管、保险或司法机关预判事故责任。发生事故如何处理、对外承担什么责任，还必须结合事实、适用规则和有效条款判断，不能拿一张研究表包办。

尤其不要只写“双方协商”。日常协商当然必要，但夜里一辆车停在路边，最缺的恰恰是重新召开一次商务谈判的时间。应急联系人、先行处置、费用暂记、证据留存和后续复核，应该提前安排。

责任矩阵也能揭穿一类隐形低价：供应商减少了服务，客户增加了工作，报价下降，看起来很美；如果客户增加的这份工作需要持续雇人，或者挤占原有班组时间，项目总成本未必下降。

每一项责任还要配上计量口径。维护是含易损件，还是只含远程诊断？保险是代办投保，还是费用已经计入？异常救援是有人接电话，还是包含拖移与替代运输？这些问题没有统一的标准答案，却必须有可以核对的项目答案。

没有被供应商收费的工作，也可能正在由客户付费。只是付款方式从发票，变成了工资、加班、等待和管理注意力。看账不能只盯着发票那一栏。

图05｜原创合成责任矩阵

PART 08

同一个客户，先把题目固定下来

下面做一组纯教学演算。所有金额均为合成参数，不代表任何企业报价、真实合同或市场均价，也不用于采购估值。我们假设一条已具备运行条件的线路，每月需要300项验收合格的运输任务，每项货量、距离、时效和交接标准相同。

四种方案都要达到同一验收结果。买整车方案先付60000元，假设使用36个月、期末残值6000元；软件合作方案另需12000元一次性适配投入，假设36个月摊分。这里不把适配费描述成行业惯例，只用来展示工程投入不能漏算。

租赁方案假设月租2800元，包含车辆、维护和保险；另交可退押金6000元。运力方案假设每项验收任务18元，包含车辆、软件、能源、维护与保险，但客户仍承担每月1000元交接工作。

买车与软件合作的维护、保险每月分别为600元、400元；软件服务费均为每月1000元，客户协调每月1200元。租赁方案也另需这两项。能源为每完成一项任务1元，由前三种方案客户承担。

为让算式看得清，暂不考虑税费、融资、折现、故障波动和额外场站改造。真实决策必须补回，尤其是不能据此推断安全、许可或者实际车辆能完成多少任务。我们算的是在规定边界下，谁为哪些资源付账。

图06｜原创合成参数表

PART 09

月费很低，可能只是账单还没翻页

买车方案的设备耗用，按这组假设简化为每月1500元，也就是60000减6000后除以36。加上软件1000、维护600、保险400、协调1200和能源300，月度可比成本为5000元。这里的“耗用”是研究分摊口径，不是对任何企业会计折旧政策的认定。

租赁方案2800元租金，加软件1000、协调1200、能源300，合计5300元。可退押金6000元不直接计入月度成本，但它会占用现金，且退款条件与信用风险仍要考察。

软件合作方案在买车方案基础上增加每月约333元适配投入分摊，合计约5333元。单看软件账单确实只有1000元，客户为了让这1000元发挥作用，还组织了车辆、工程和运营。

按任务购买运力，300乘18，再加客户交接1000元，合计6400元。这组参数下它比买车贵1400元，但减少了客户购买车辆的前期投入，也把约定范围内的车辆组织与运营工作交给了供应商。

贵出的1400元是否值得，要看客户省下的投入和承担能力，而不能只看一列高低。对没有运维班组、需求尚不稳定的客户，较高的单项费用可能换来更合适的试错空间。对货量稳定、已有团队的客户，自己组织资源也可能更经济。算盘不替人判断，算盘负责把判断需要的条件亮出来。

PART 10

货少了一半，排名为什么会变

保持同一组教学参数，设每月验收任务数为q，并假定在比较范围内，各方案都具备完成这些任务的能力，人员与固定服务投入暂不调整。买车月度成本是4700加q；租赁是5000加q；软件合作约5033.33加q；运力服务是1000加18q。

任务降到160项，四种成本约为4860元、5160元、5193元和3880元。按任务付费的方案反而较低，因为前三种方案的固定投入没有随着货量同步减少。

任务增到420项，在能力仍满足的前提下，成本约为5120元、5420元、5453元和8560元。这里没有证明一辆车一定能做420项，只是展示需求变化如何影响固定成本与按量支出的关系。实际超出能力边界，必须重算车辆、班组和保障资源。

买车与按任务服务在此模型下的交点约为每月218项。但别把218当成采购口诀。租金、残值、维护、任务定义、最低消费任意一项变化，交点都会移动，现实还会出现扩容台阶和服务能力限制。

更要注意，运力合同若设置最低消费，客户任务减少时未必少付那么多；若低价只适用于非高峰，客户急需的时段可能另算。所谓需求风险转移，必须以服务商实际接受了多少波动为准。按次计价只是线索，不是结论。

例如约定每月最低支付5400元运输费，即使实际完成160项，客户加上1000元交接投入仍要付6400元。我们并不据此指责最低消费，它可能为保留专属运力提供资金。只是同样写着18元一项，有无保底，客户承担的淡季风险完全不同。这个条件必须放进比较表。

图07｜原创合成演算

PART 11

便宜和付得起，是两道题

再看现金。买车方案在投入时先付60000元，运行首月再付3500元经常支出；软件合作先投入72000元，首月同样付3500元；租赁先交6000元押金，首月支出5300元；运力服务若约定月末付款，首月应付6400元。此处假设没有其他预付和保证金。

按36个月、每月300项计算，买车总现金支出扣除假设残值后为18万元；租赁在押金全部退回后为19.08万元；软件合作为19.2万元；运力服务为23.04万元。计算中已经纳入客户保留的协调或交接工作，不能再重复加一次。

这些未折现总额，展示的是同一假设下的资源代价，不是完整投资回报。卖车客户先出钱，运力客户按履约付款，资金时间不同；若融资利息、现金回收和需求稳定性不同，判断也会不同。

还有一个常被忽略的方向：残值不是保证到账的钱。本文为了复算，暂设36个月后确实回收6000元；若最终只能回收零元，买车方案的总净支出就增加6000元，月均增加约167元。一次性适配投入若提前终止也未必能转移，软件合作的退出成本需要另算。

供应商那端同样要算。运力服务商可能先买车、建服务网络，随后逐月收款；租赁平台可能向上游租车再出租，也可能自己持有资产，不能一概视为重资产。软硬件厂商若给客户长账期，卖出了设备也未必立即回笼现金。

我更关心一个朴素的问题：货正常跑着、款还没有回来时，谁在垫这段时间的钱？现金流有点像人的气息，利润表再精神，气接不上，走两步也会喘。

图08｜原创合成现金流对照

PART 12

车卖掉、服务收款、公司赚钱，分别看

现金到账、收入确认和盈利，不是同一个瞬间。IFRS 15的基本原则是识别合同承诺、区分履约义务，并随相应商品或服务控制权转移确认收入。设备与持续服务放在同一合同里，也需要具体分析，不能简单把全部收款都算作当期销售。

租赁还有自身适用的会计要求。IFRS 16以具体资产的使用控制等条件识别租赁，并规定相应承租人处理。仅凭合同封面写“服务”或收费方式按月，就宣布客户不涉及租赁资产和负债，过于轻率。实际应由专业人员结合适用准则和合同判断。

看运营成绩，我会把三个层次分开。第一，单车或者单项任务，扣除了哪些直接成本后还有贡献；第二，一个城市项目，加上站点、保障团队、备车和管理后是否有利润；第三，公司层面，加上研发、总部、融资等开支后怎样。

这三个层次之间没有自动通道。一辆车满负荷时贡献为正，不代表另一批闲车也一样；一个成熟城市盈利，不代表新开城市已经收回启动投入。反过来，公司仍在亏损，也不能抹去个别项目改善的事实。

评价得越细，越不必用一句“行业已经盈利”或“商业模式不成立”包办。它们都很有气势，问题是气势不能替我们付款。真正可比的指标，要带着成本范围、观察周期、任务定义和样本说明一起出现。

PART 13

结果服务最怕的，是有承诺却没有处置权

设想一项合成异常：下午五点，货已装车，门店临时改了收货时间。设备供应商或许只需确认车辆功能正常；软件服务商需要排查是否存在系统问题；运输服务商则要按约定处理重约、等待、返回或替代运输。不同承诺，触发不同工作。

但如果运力服务商既无权联系收货人，也不能决定是否等待，更不能调整任务，却要对所有延误负责，争议几乎可以预见。相反，若服务商可以任意改时间而不用征求客户同意，客户的业务也可能被耽误。

解决办法不是把所有权力集中起来，而是预先安排权限边界：哪些变化系统可以处理，哪些必须征得客户确认；等待到何时升级；谁先启动保底措施；额外费用在什么证据下结算。上一期讨论调度分工，这一期走到它背后的合同授权。

责任划分还应与可观测性对应。客户要提供准确的货物和交接信息，服务商要提供任务状态和异常记录；双方对停运原因有异议，须有复核机制。如果只有一方能够修改影响结算的状态，另一方既看不见也无法提出异议，后面再便捷的自动结算，都可能把小争议迅速放大。

服务等级约定也应具体。写“及时响应”，不如定义接报、确认、到场和恢复四个节点；写“保障运力”，不如说明可预约时段、容量范围与不足时的处理。罚款可以约束行为，却不能在故障现场变出一辆备车。

敢卖结果，要有把异常收回来的能力。谁拥有客户协调、现场资源和恢复流程，谁才更有条件承担相应承诺。漂亮的计费方式，只能给生意起名，不能替生意长出筋骨。

PART 14

标准化与本地服务，要在接口处握手

无人配送要扩张，当然需要标准化。车型和接口尽可能稳定，软件部署和故障定位能够复用，能减少每到一地就重做一次工程。但县城门店的收货习惯、仓库装载安排和本地保障距离，并不会因为接口统一就同时统一。

把所有现场变化都塞进总部研发，软件公司会被项目拖住；把所有适配和异常都推给地方伙伴，客户又可能得不到稳定服务。比较可行的方向，是把标准产品边界、本地工作范围和升级通道一起设计。

例如，通用技术问题由产品团队处理，站点交接变化由当地运营维护；跨越产品边界的新增需求，先评估、再报价、再验证。谁能改什么、改后怎样确认，写进双方都能使用的工作记录，而非靠几位熟人临时救场。

合作伙伴的收益也得与工作匹配。只按卖车台数奖励，本地团队可能缺少持续服务动力；只考核运输单量，又可能忽略等待、恢复和客户保留工作的变化。收益指标与验收口径要互相照见。

这也是我不急着宣布某种模式终将统治市场的原因。不同客户的货量、现金、管理能力和需求弹性不一样，行业很可能长期存在多种组合。真正需要进步的，是每种组合都能把责任说清、把服务做实，而不是把名字换得更时髦。

图09｜原创合同核对框架

PART 15

签约之前，我会把这几句话问到底

第一句，什么证据代表完成？我会要求把任务编号、约定范围、到达、交接和验收串起来，避免供应商报车辆行程、客户算完成任务，月底对账像两个人隔着山喊话。

第二句，报价还缺哪些工作？把客户保留的装卸、场地、协调、异常兜底逐项估算；已有员工承担，也记录占用工时和增量负荷。不是每一分钟都要新增工资，但不能把组织能力当成无穷无尽的免费资源。

第三句，货量降了、系统停了、线路变了，各怎么算？最低消费、可用时段、停运减免、替代服务、迁移成本，应在正常营业时谈妥。风和日丽时修屋顶，总比下雨以后争谁去买瓦从容。

第四句，合作结束以后如何接续？车辆和押金怎样处理，任务与结算记录能否按约导出，软件许可如何终止，未结事项由谁跟进。出口不清楚，入口越便宜，后面越容易犹豫。

最后，把试点验收与规模采购分开。先约定在什么任务范围和观察周期内证明什么，再据记录扩大合作。试点补贴、专人驻场和额外资源若影响成本，就单独列出；否则，把被精心照顾的第一辆车直接乘上一千，通常只能得到一个很自信的错数。

PART 16

生意的分量，藏在最后一项没做完的工作里

回到开头那张桌子。四家供应商都可能提供有价值的方案，客户也不必追求一个听起来最先进的模式。真正要找的，是自己最缺的那部分能力，以及愿意为它承担的代价。

稳定货源、成熟班组和可承受的现金投入，可能支持购买设备；需求需要验证、希望保留调整余地，可以考虑租赁或按量服务；已有整车工程与运营体系的伙伴，可能更看重技术合作。每个选择都附带条件，没有一句话能包治百病。

我想留给读者一个很土、但很好用的办法：拿起合同，顺着一票货走一遍。出库时谁接，路上谁管，到门口谁卸，遇到问题谁来，完成以后谁签，月底谁收钱。走到哪儿停下来，哪儿就值得继续研究。

无人配送卖的可以是车、软件，也可以是运输服务。客户最终在意的，是约定的那段工作，能否持续、可验证、付得起地完成。把承诺写进资源，把结果接上账单，这门生意才有自己的分量。

我是王小珲。下一篇，我们接着翻合同里另一页常被跳过的内容：《无人车怎么买保险：从“能跑”走向“敢长期用”》。车出了门，风险也就上了路；保险究竟接得住什么，得把条款和现场放在一起看。

特别声明

本文为产业研究与合成演算，不构成采购、投资、法律或会计意见。真实照片保留来源及原语境，版权归原权利人；公开转载须核对相应图片使用授权。封面与原创图解均已标明，不将示意作为真实事件证据。