Omio 接入 OpenAI：旅行 AI 的真考题，是能不能接住真实订单

Omio 这次有意思的地方，不是“又接了一个大模型”。

它把 OpenAI 模型接进自己的实时交通库存和预订系统。这个网络覆盖 47 个国家、3000 多家交通服务商，包含火车、巴士、轮渡和航班。

问题也在这里：旅行 AI 如果只会回答“罗马到佛罗伦萨怎么玩”，价值有限。真正难的是，它能不能把用户的问题，接到真实库存、实时价格和可预订旅程上。

我更在意的是这个变化：AI 正从旅行搜索的辅助层，往交易入口和企业运营底层挪。但现在还不能把 Omio 案例写成胜利报告。OpenAI 官网案例没有披露订单量、转化率、用户增长，也没有证明 ChatGPT 已经能包办所有交通预订流程。

对话式旅行的关键，不是会聊天，是接得上库存

Omio 早在 2023 年就在 ChatGPT 中推出过早期对话式旅行体验，并连接实时库存和价格数据。

用户可以问“罗马到佛罗伦萨最快怎么走”，也可以问“巴黎到巴塞罗那坐火车还是飞机”。差别不在问法更自然，而在答案背后有没有可售交通网络支撑。

过去的旅行产品，大多围绕搜索框和筛选器设计。用户填出发地、目的地、日期，再比较价格、时间、换乘和承运商。对话式界面想改掉这一步：用户先说需求，系统再补路线组合。

但这不是把搜索框换成聊天框那么简单。

这对旅行平台的产品团队影响很直接。

以前主要优化排序、筛选、详情页和支付转化。现在还要设计对话意图、库存召回、价格校验、异常提示。一个过期票价，用户不会觉得“模型还在进步”，只会觉得平台不靠谱。

对旅游出行行业从业者来说，短期动作不是立刻把所有入口迁到聊天界面。更现实的做法，是先挑低风险场景试：路线比较、跨交通方式推荐、行程解释、售前问答。等库存校验和售后边界稳定，再把更靠近支付的环节放进去。

Codex 进研发链路，AI 开始影响产品速度

Omio 的另一个动作发生在内部。

公司先向员工开放 ChatGPT，再把 Codex 嵌入工程流程。按照 CTO Tomas Vocetka 的说法，工程师在研究、规划、编码、测试、代码审查、监控和维护中都会使用 Codex。

Omio 还给了一个很具体的说法：部分产品现在能用原来约 20% 的时间完成。过去需要几名开发者做一个季度的项目，现在可能由一名开发者在约一个月内完成。

这个数字不能外推成行业平均水平。它来自 OpenAI 官网案例和合作方叙述，不是独立第三方评测。

但它至少说明一件事：AI 对企业的影响，正在从“前台多一个功能”，变成“后台试错成本下降”。

旅行平台的竞争，长期不只看界面。还要看谁能更快接入供给、处理价格变化、上线本地化功能、修补异常流程。开发周期被压短后，团队可以更快试一个路线推荐策略、一个新筛选项，或者一个内部运营工具。

这对企业数字化和产品研发负责人更具体。

不要只问“买哪个模型”。更该问三件事：哪些研发环节可以先迁到 AI 辅助，哪些代码必须人工复核，哪些数据不能直接喂给外部工具。采购可以快，权限和审计不能省。

如果团队已经在用 ChatGPT 或 Codex，下一步不是鼓励大家随便用，而是把使用场景写清楚：需求拆解、测试用例、代码解释、监控排查可以开放到什么程度；涉及支付、用户隐私、合作方数据时，谁审批、谁留痕、谁负责。

边界比话术重要，责任不能交给模型

OpenAI 的案例材料没有回答几个关键问题。

对话查询带来了多少新增预订？价格错误率怎么控制？用户在 ChatGPT 里发现行程后，有多少能顺利走到支付？复杂换乘、退款、改签和取消政策由谁兜底？

这些问题现在都不能替 Omio 补答案。

Vocetka 的一句判断反而更重要：AI 可以加速开发、分析和决策，但责任和问责仍由人承担。

这句话放在旅行交易里很实在。票价、车次、座位、取消政策都不是软信息。攻略写错了，用户最多绕路；票务信息错了，用户可能误车、误机、退改受损。

所以 Omio 案例最值得看的是三条线。

我不太买账的是，把这类案例直接讲成“AI 颠覆旅行预订”。证据还不够。

更稳的判断是：Omio 给出了一条可看的路径。前台用对话承接需求，后台用模型加速研发，中间用实时库存和价格系统连接交易。但这条路能不能走通，不取决于回答多顺，而取决于每一次车次、票价和责任落款能不能对上。