直飞功能由哪家航司IT团队开发？揭秘背后软件开发方
近期趋势：直飞功能从营销概念转向技术定制
近年来，航空公司官网与App中“直飞”筛选、智能推荐等功能日益普及。所谓“直飞”并非简单显示航线，而是需要整合航班时刻、机型、经停信息、准点率等多个数据层，并在用户搜索时实时运算。行业趋势显示，该功能正从第三方OTA（在线旅游平台）统一提供，转向由航空公司自有IT团队基于自有运力数据开发定制化模块。这一转变源于航司对直销渠道的话语权争夺——当用户通过官网或App直接购票时，航司需要提供与OTA同级的体验，直飞功能便成为基础配置。
行业背景：航司IT团队与外部技术供应商的分工
直飞功能的开发主体通常有三种模式：
- 全自研模式：大型航司（如三大国有航空集团）拥有数百人的IT部门，可基于GDS（全球分销系统）数据或内部运控系统开发直飞筛选逻辑。核心优势在于数据实时性高，可结合机务排班、机组调度等内控信息动态调整直飞标签。
- 联合开发模式：中型航司多采用“自研前端+第三方引擎”的混合方案。前端交互（如筛选器、地图展示）由航司IT团队完成，后端航班匹配算法则由航司合作的技术供应商（如Amadeus、SITA、阿里云航空解决方案等）提供标准化API。
- 外包模式：小型或低成本航司可能直接采购整站系统，直飞功能作为标准化模块集成在预订系统中。这类系统的供应商通常来自航空IT服务商（如Navitaire、Sabre、神马专车等），但功能灵活性较低。
要点总结：
- 直飞功能并非单一软件公司开发，而是由航司IT团队主导，依据技术与预算规模选择不同链路。
- 不存在“某家航司开发了所有直飞功能”的情况，每家航司的实现路径差异明显。
用户关注点：直飞功能的准确性与数据来源可靠性
普通旅客在使用直飞筛选时，常遇到“显示直飞点击后仍有经停”或“某平台直飞航班时间误差大”等问题。这些现象往往源于数据来源差异：
- 航司官网的直飞数据：直接来自自身航班表与OAG（航空运力数据服务商）的实时同步，经停标签通常基于实际飞行计划判定，准确性较高。
- 第三方聚合平台的直飞数据：可能依赖多源拼接，当航司临时更换执飞机型或增加技术经停时，平台更新滞后会导致误判。
- 用户判断建议：若依赖直飞功能挑选航班，优先在航司官方渠道核对具体“飞行时长”与“经停城市”字段；若发现第三方平台与航司官方存在矛盾，应以航司官网信息为准。
可能影响：直飞功能对生态链的牵引作用
直飞功能的定制化开发正在带动航空IT团队角色的转变：
- 自研能力强的航司（如新加坡航空、阿联酋航空自研团队）开始将直飞逻辑与动态定价、常旅客积分系统打通，形成差异化竞争力。
- 技术薄弱的航司依赖外部供应商时，直飞功能可能成为其IT转型的切入点——通过采购直飞模块倒逼内部系统升级，例如增购数据清洗、航班时刻协调等中间件。
- 外部IT供应商正从“卖功能”转向“卖数据服务”：某航空技术供应商近期推出的“直飞置信度评分”产品，通过历史准点率、机场时刻分配概率等参数为每条直飞线路打标签，这类合作模式正在中小航司中扩散。
要点提示： 直飞功能的开发方不局限于一家航司或一家软件公司，而是航空IT外包与自研生态的缩影。未来可能出现第三方直飞标签认证标准，届时用户可通过认证标识判断数据可信度。
后续观察：直飞功能的进化方向与潜在变量
综合近期行业动态，以下趋势值得关注：
- 实时直飞判定：随着ADS-B（广播式自动相关监视）数据的开放，部分航司开始探索基于实时航班轨迹动态修正直飞标签——当航班实际因天气绕飞、备降时，系统可立即撤销直飞标签。这种能力需要航司IT团队具备实时数据流处理能力。
- 跨航司直飞组合：联盟内（如星空联盟、寰宇一家）的代码共享航班若涉及直飞，其数据统一性由联营协议支撑。开发此类功能需联盟IT标准委员会协调多个航司数据接口，目前仅少数技术领先航司能够实现。
- 隐私与数据主权：直飞功能的精准度依赖航班计划数据，部分国家要求航司将敏感航班数据存储在境内。这一限制可能促使更多航司选择本地化开发的直飞模块，而非使用跨国云服务。
总体而言，直飞功能的软件开发方并非单一实体，而是一个由航司IT团队、GDS供应商、云服务商、专业航空IT公司构成的协作网络。用户在关注“哪家开发的”时，更应先明确自己的场景——是查询自身已购航班，还是比价筛选线路，再到对应渠道查看其数据源说明。