从搜索框到对话：Omio 如何把实时交通库存接进 AI 入口

一次订票要跨几个网站，这就是它要解决的矛盾

Omio 是世界领先的多式联运旅行平台之一，连接数百万使用火车、巴士、渡轮和航班的旅客。它背后是 3,000 多家交通服务商，分布在 47 个国家。这个数字听起来是优势，但对旅客来说，它首先是一种复杂度：跨境行程往往要在多个网站之间来回，比较不同交通方式，再把分散在各家服务商的班次拼成一条完整路线。

问题不在于信息不够，而在于信息的组织方式。传统旅行规划把"筛选"的工作全部留给了用户——你得先知道该比什么，才能开始比。而当消费者的预期开始向对话界面转移，Omio 看到了一个重新设计发现流程的机会：旅客只需要描述自己想去哪里，系统返回的是已经个性化、并且可以直接预订的行程。

这里的决策冲突比技术选型更根本。搜索型界面的每一层筛选器，都是平台多年积累的产品资产；换成对话入口，意味着放弃对用户路径的精细控制，把"怎么问"的主动权交回给旅客。作为 OpenAI 的早期客户与合作方，Omio 选择了先做出来再验证的路径，并在 2023 年推出了较早接入 ChatGPT 的旅行体验之一，把 OpenAI 模型直接连接到自己的交通库存和预订系统。

与此同时，公司内部有一个平行的判断：正在重塑客户体验的这套技术，同样可以改变工作本身如何完成。这条内部线索后来变成了案例里数字最扎实的一部分。

让对话能落到"可预订"，靠的是接进实时库存

对话式旅行最容易做成的样子，是一个会聊天但订不了票的助手。Omio 的做法把重点放在了另一头：这套集成让旅客可以用自然语言提问，比如"从罗马到佛罗伦萨最快的路线是什么"，或者"从巴黎到巴塞罗那该坐火车还是飞机"。而回答这些问题时，系统并不依赖静态信息，而是接入了实时的交通库存与定价数据，让用户通过对话发现真实、可预订的行程。

这个区别决定了工程难度的分布。静态信息只需要一次抓取，实时库存和定价则要求模型每次回答都落在当下真实可售的班次上——票价会变，座位会售完，跨境联运的可用组合也随时段变化。把模型接到库存和预订系统，本质上是让自然语言的开放性，去对接交通系统的强约束。

更近期，Omio 在这个方向上做了扩展：推出基于 OpenAI 模型、并连接其全球交通网络的专用 ChatGPT 体验。官方把这条路线描述为一种更广泛的转变，从基于搜索的界面转向 AI 原生的客户体验，AI 成为客户与真实交通系统之间的接口层。

需要说明的是，这一节里所有系统组件都来自官方披露的连接关系。至于模型如何被约束在已核验的库存范围内、检索与调用的具体分层、失败查询的兜底策略，官方材料未披露。下面这张图只表达已公开的输入、连接与输出关系，不补充推测的内部结构。

推广顺序：ChatGPT 是引子，Codex 才是干活的地方

在对外做旅客体验的同时，Omio 也在改内部的工作方式，而这条线的推进顺序很清楚。公司先向全组织员工推广 ChatGPT，让各团队去试、去学、去找出自己工作里可改进的地方；随着采用成熟，再扩展到 Codex，把它深入嵌入工程工作流，并逐步延伸到非技术职能。CTO Tomas Vocetka 对这两步的定位说得直接："我们推出了 ChatGPT，那是个引子。Codex 才是真正干活的地方。"

今天，Omio 的每一位工程师都在软件开发生命周期中使用 Codex，覆盖研究、规划、编码、测试、代码审查、监控和维护。这个覆盖范围值得留意——它不是"用 AI 写代码"，而是把 AI 放进了从需求研究到线上维护的每个环节。在此之上，公司还在构建定制集成和连接器，把内部系统、数据与工作流直接带入 AI 工具，让员工从检索信息推进到执行动作。

推广的目标不是在既有流程上叠一层 AI，而是从底层重新思考工作怎么做。Vocetka 的说法是"所有职能都需要重新思考自己的工作方式"。这种自上而下推动、同时放开全组织试验的组合，也是这个案例在角色分工上最明确的一点。

人机边界同样被写成了原则：责任与问责仍由人承担，AI 用于更快开发、更快分析、更快决策，但由人来负责。官方把这一点描述为把 OpenAI 工具的广泛访问，与治理和人工监督结合起来——AI 加速执行，员工对结果负责。至于具体的审批节点设在哪一步、代码审查中人工与 Codex 的分工如何界定、连接器访问内部系统时采用了哪些权限与审计控制、异常时如何回退，官方材料未披露。

对想复现这条路径的团队，DataHub 建议把三件事列进验证清单：全员试用阶段的留存与真实使用场景，而不只是开通率；Codex 进入代码审查与线上监控环节时，缺陷率和维护成本是否被独立跟踪；连接器接触内部数据时的权限边界与审计留痕。这三项在本案例中都不属于已公开的做法。

那两个交付速度数字，各自是什么口径

更快的开发周期带来了更多试验、更快的决策，以及在投入更大资源之前先检验想法的能力。官方给出了两个量化说法，它们的性质并不相同，混用会得出错误结论。

第一个是 Omio 的自我估计：许多产品现在可以用此前大约 20% 的时间完成。关键词是"估计"和"许多产品"——这是公司自报的整体感受，不是审计过的统计结果。官方未披露基线如何确定、样本包含多少个产品、观察周期多长、按什么方式计算。所以它可以作为方向性证据，但不能当作可复用的效率系数。

第二个来自 CTO 的具体举例：原来需要数名开发者一个季度的项目，现在可由一名开发者在约一个月内完成。这是一个项目对比例子，官方未披露该项目是什么、复杂度如何、是否有重复测量。它说明了变化的量级，但一个例子不构成分布。

还有一个数字容易被跨类别引用：3,000 多家服务商、47 个国家，这是 Omio 交通网络的接入范围，也是 OpenAI 模型所连接的网络规模。它描述的是连接广度，不是 AI 实际处理的查询量、预订量或活跃覆盖率——各服务商的接入深度官方未披露。

同样重要的是这个案例没有给出什么。对话式旅行体验的使用量、预订转化率、回答准确率与用户满意度，官方材料中没有对应指标；Codex 对交付质量、缺陷率和维护成本的影响，也没有独立数据。因此"开发变快"与"产品变好"之间不存在已披露的因果链条，这两件事在现有材料里只是同时发生。

什么条件下这条路径可以搬，什么条件下不行

这个案例可迁移性最高的部分，是推广顺序而非工具选择：先用一个低门槛的通用工具让全组织形成使用直觉，再把资源压到一个能产出可验证成果的核心工作流上。前一步的价值是找出真实场景，后一步才产生交付变化。跳过第一步直接强推深度工具，缺的是员工对"哪些环节该改"的判断；停在第一步不往下走，则只会留下一堆零散的使用记录。

对外那一半的前提要苛刻得多。把对话入口接到可预订的实时库存，成立的条件是企业本身握有结构化、实时、可交易的供给数据。Omio 有 3,000 多家服务商的接入基础在先，模型才有可落地的回答对象。供给数据靠人工维护、库存不实时或不可直接成交的行业，照搬这条路线大概率只能做出一个会聊天但订不了票的界面。

最后一条前提关于责任分配。这个案例把"AI 加速执行、人承担问责"写成了明确原则，但没有公开支撑这条原则的具体机制。想复现的团队需要自己补上审批节点、审计留痕和回退路径——原则可以照抄，控制系统必须自建。