开发者生态作为技术平台的外延
把无人机变成可编程飞行平台
开发者生态作为技术平台的外延
2014 年 11 月，深圳 DJI 总部的一间会议室里，几位工程师把一段 iOS 代码编译、连接到一台 Phantom 2 的遥控器。遥控器背后的 USB 口连着一台 iPad mini，iPad 上跑的 App 能控制无人机按预设航点自主飞行并记录 GPS 坐标。这段演示后来变成了 DJI Mobile SDK v1.0 的发布版。在那之前，控制一架无人机的飞行路径需要在遥控器上拨动摇杆，或者刷写开源自驾固件。从那之后，任何有 iOS 开发经验的人都可以写一个 App 来接管飞控逻辑。
这个时间点很关键。2014 年的 DJI 正在从航模公司变成消费电子公司。Phantom 2 刚上市，Inspire 1 即将发布，公司年收入从 2013 年的约 1.3 亿美元跃升至约 5 亿美元（市场估计）。但消费级市场再大，DJI 也不可能靠自己的产品部门覆盖电力巡检、农业植保、测绘建模、公共安全这些垂直场景。SDK 不是锦上添花的生态策略，它是 DJI 把自己从"卖无人机"变成"卖飞行平台"的工程手段。
三层 SDK 的扩展逻辑
DJI 在 2014 到 2016 年间陆续发布了三条 SDK 产品线。它们的分工表面上看是"开发者工具"，但更接近技术平台复用的核心判断。
Mobile SDK（2014 年 11 月 v1.0，2016 年 1 月 v3.0 大改版）面向移动端应用开发者。它把飞控底层协议封装成 iOS/Android API，开发者不需要懂飞控算法，也不需要嵌入式开发经验，只需要移动端 App 开发能力。MSDK 提供了航点任务、虚拟摇杆、实时图传、相机参数控制等接口。到 2023 年，基于 MSDK 开发的自定义 App 已经超过 1000 个（DJI Enterprise 官方统计）。
Onboard SDK 面向 Linux/ROS 开发者，2015 年随 Matrice 100 发布。它让开发者把一台机载计算机（如 DJI Manifold）直接连接到飞控上，通过串口或 USB 获取高频率遥测数据、发送低延迟飞行控制指令。典型应用是实时处理。例如在飞行中通过机载 AI 模型识别电力线缺陷，即时调整飞行路径，不依赖地面站。OSDK 的扩展性比 MSDK 更深一层：它允许开发者绕过遥控器链路，直接控制飞行器。
Payload SDK 是 2017 年随 Matrice 200 推出的硬件层 SDK。它定义了一套标准接口和物理规格（SkyPort V2 适配器和 X-Port 云台），让第三方公司可以开发挂载在无人机上的专业负载。气体监测仪、倾斜摄影相机、多光谱传感器、探照灯、喊话器都通过 PSDK 与飞控通信，数据实时显示在 DJI Pilot App 或自定义 App 中。到 2023 年，基于 PSDK 开发和量产的第三方负载已经超过 110 种（同一来源）。
这三层 SDK 加在一起，构成一个"API 深度频谱"。MSDK 最浅（封装最高，开发门槛最低），OSDK 最深（接近飞控裸协议，但要求 Linux/ROS 能力），PSDK 在硬件层（需要嵌入式开发加机械设计能力）。三种不同深度的接口，分别接入无人机平台的不同能力层。核心飞控没有变，变的只是外层的接口封装程度。
这里的 DJI 特征在于接口边界。MSDK 不直接开放飞控算法，而是把航点任务、虚拟摇杆、实时图传、相机参数和电池状态封装成移动端 API；OSDK 则把接口推进到机载计算机和飞控之间，让 Linux/ROS 程序能读取遥测并发送控制指令。这样一来，同一台 Matrice 可以同时服务移动 App、机载 AI 和第三方挂载负载，而不把底层飞控安全边界交给外部开发者。
DJI Mobile SDK 架构，展示移动端 App 如何通过遥控器链路与飞行器通信。SDK 负责封装飞控、图传、电池管理等底层逻辑，开发者只需关注业务功能。来源：DJI Developer 官网。
生态中的关键第三方
SDK 的价值最终由第三方应用来证明。2014 年，DJI 推出了第一届 Developer Challenge，面向全球开发者征集基于 SDK 的创新应用。当年来自华南理工大学的 BetterW 团队开发了一款交通事故现场勘察 App，用无人机代替交警手工测量和拍照，获得了首届冠军。2015 年，德州大学达拉斯分校和宾州州立大学的联合团队开发了电力线巡检 App，精准到可以在飞行中识别绝缘子缺陷。到了 2016 年，挑战赛的主题升级为"从行驶的车辆上起飞并自主降落"的搜救任务，合作方包括福特汽车和联合国开发计划署。这些挑战赛的获奖应用虽然在商业上未必直接规模化，但它们验证了 SDK 在垂直场景中的可行性。
测绘和建模是其中最早被验证的垂直场景。
DroneDeploy 是最早的受益者之一。这家总部旧金山的公司成立于 2013 年，2015 年与 DJI 达成技术合作，利用 MSDK 控制 DJI 无人机自动执行航拍测绘任务。核心功能是让用户在地图上框选一块区域，无人机自动生成航点、飞行、拍摄，然后将数据上传云端生成 2D 正射影像和 3D 模型。2016 年，DroneDeploy 推出实时高程建模功能，在飞行中即时查看施工进度。到 2020 年，DroneDeploy 平台管理的无人机测绘面积超过 1 亿英亩，这些数据基本都来自 DJI 无人机。Pix4D 是另一条生态路径。这家瑞士公司本身是专业的摄影测量软件开发商，2013 年之前主要做地面照片的三维重建。2015 年，Pix4D 与 DJI 合作推出 Pix4Dcapture，一款基于 MSDK 开发的免费 App，用于控制 DJI 无人机自动执行测绘航拍。Pix4D 的路线和后处理建模高度匹配：用户用 Pix4Dcapture 采集航拍图像，用 Pix4Dmapper 做专业级三维重建。这套组合在农业、矿业和地质勘探中广泛使用。
Trimble 在 2017 年加入 DJI 生态，角度更偏硬件。Trimble 是全球测绘和定位的行业巨头，以往它在无人机领域的角色是提供高精度 GNSS 定位模块。2017 年，Trimble 与 DJI 合作推出捆绑方案，将 Trimble 的差分定位能力和 DJI 的飞行平台整合，用于高精度测绘和施工监控。这是 PSDK 硬件层面的集成：Trimble 的定位模块作为挂载负载适配 DJI 的 SkyPort 接口。
三家公司的合作路径恰好对应 MSDK、PSDK 和硬件集成三种模式。DJI 不需要自己去理解测绘的坐标系转换原理、农业的多光谱图层叠逻辑、或者施工监控的 BIM（建筑物信息模型）标准。每一个行业的专业知识由该行业的软件公司通过 SDK 接入。这就是技术平台复用的本质：核心资产固定，外围接口可扩展，新场景的适配成本转移到第三方开发者。
FlightHub 2
2021 年 DJI 推出 FlightHub 2，一个基于云的无人机运营管理平台。它标志着 SDK 生态从"控制一架飞机"升级到"管理一支机队"。
FlightHub 2 的核心功能包括：远程实时操作中心（允许地面操作员在千里之外控制无人机）、智能航线规划（用 AI 为巡检任务自动生成最优路径）、数据管理（飞行记录的自动上传、存储和分析）、以及 OpenAPI 接口（让第三方云平台接入 FlightHub 2 的核心功能）。到 2023 年，自 2022 年 3 月 Cloud API 发布以来，超过 750 个开发者已经基于它构建了云平台（DJI Enterprise SDK Guide）。
FlightHub 2 让 DJI 的开发者生态从"三层的深度频谱"延伸到第四层，云平台层。开发者不再需要在机载计算机上写实时处理代码，也不需要写移动端 App 来控制飞行路径。他们可以在云端用 RESTful API 管理整个机队的飞行任务、数据分析和工作流编排。DJI 的飞控、图传和云台技术从嵌入式系统一路开放到了云端 API。
DJI FlightHub 2 OpenAPI 架构：将核心功能封装为 RESTful API，允许第三方云平台接入航线管理、直播转发、设备同步等功能。来源：DJI Enterprise Blog。
SDK 生态的规模与边界
截至 2023 年，DJI 官方披露的 SDK 生态关键数字包括：超过 10 万名开发者注册加入 DJI 开发者计划，1000 多个基于 MSDK 开发的自定义 App，超过 110 种基于 PSDK 开发并量产的第三方负载，以及 750 多名在 Cloud API 之上构建云平台的开发者。这些数字放在消费电子行业不算突出（相比 iOS 或 Android 的数百万开发者），但考虑到无人机行业是一个极其垂直的品类，10 万开发者的覆盖面已经覆盖了几乎所有可以规模化的行业场景。
从成本结构视角看，SDK 生态改变了 DJI 的研发投入分布。DJI 不需要在自己内部养一支懂测绘、懂农业、懂消防的行业专家团队，而是通过 SDK 接口让每个行业的现有软件公司自行适配。每一条 MSDK 授权应用、每一个 PSDK 挂载负载，都是行业知识进入 DJI 平台的入口，但开发成本由第三方承担。
这个模式也有内在约束。DroneDeploy 和 Pix4D 同时适配多家无人机品牌的飞行器，对它们来说 DJI 只是"可替换的硬件供应商"之一。SDK 接口越开放，开发者的切换成本越低，这是一个微妙的平衡。DJI 的应对方式是把接口封装深度和技术支持质量做成壁垒。MSDK 的 API 稳定性和文档完整度，在无人机行业中长期没有竞品做到同等水平。
DJI 无人机通过 DroneDeploy 平台执行建筑工地测绘的示意场景。第三方软件通过 MSDK 控制无人机，DJI 不需要自己开发测绘软件。来源：DJI 官网新闻。
追问
如果 2014 年 DJI 没有发布 SDK，而是选择自己开发行业应用软件，今天的企业级市场格局会有什么不同？Matrice 系列是否还能占据同样的市场地位？
三层 SDK 的接口深度（MSDK 最浅、OSDK 最深、PSDK 在硬件层）覆盖了几乎所有行业场景，但这种分层设计在 API 演进中也有成本。多平台（iOS/Android/Linux/ROS）的同步更新、版本兼容性维护，DJI 在这个问题上的取舍说明了什么？
10 万开发者对垂直品类是否足够？当无人机行业进入平台期后，开发者生态的规模和活跃度是否会影响 DJI 在行业解决方案中的议价权？
DroneDeploy 和 Pix4D 同时支持 DJI 和 Autel 等其他品牌无人机。DJI 的 SDK 开放策略让这些平台获益，但反过来也让 DJI 变成"可替换的飞行硬件"。当第三方平台同时适配多个无人机品牌时，DJI 靠什么维持平台粘性？