OpenAI称英国旅游平台 loveholidays 正让“每个人都成为构建者”：Codex 从编程工具走向企业协作界面

OpenAI 发布的客户案例显示，英国旅行平台 loveholidays 将 Codex 从工程编程代理扩展为面向产品经理、设计师和业务团队的自助协作界面，显著提升 AI 辅助代码变更与部署频率，同时工程团队规模保持稳定。文章指出这些数据来自公司自报，强调关注部署质量、成本与治理而非单纯增加代码量。

OpenAI 8月26日发布的一篇企业案例显示，英国在线旅行社 loveholidays 正把 Codex 从工程师使用的编程代理，扩展为产品经理、设计师和商业团队共同使用的工作工具。该公司称，过去一年其代码变更中由人工智能辅助完成的比例从约7%升至79%，部署数量增加73%，而工程团队规模基本保持不变。

这篇名为《How loveholidays is making everyone a builder with Codex》的文章是一篇由 OpenAI 发布的客户案例，相关数据和效果主要来自 loveholidays 及 OpenAI 的陈述，并非独立审计结果。它所呈现的重点，也不只是代码生成速度，而是企业试图重新安排“谁可以提出、验证并交付软件想法”。

从工程排队到业务团队直接试验

loveholidays 是一家在线旅行代理商，在欧洲八个市场运营。OpenAI称，公司每天需要处理约60万亿种旅游套餐组合，帮助数百万用户搜索和预订假期。支撑这些业务的是一套已经运行多年的技术平台。

在传统流程中，产品经理或商业团队提出新的客户体验后，通常需要先说服工程团队排期，再等待原型开发。每一个试验项目都意味着占用工程师本可以用于其他工作的时间。loveholidays希望把这种依赖降下来，于是让工程师使用其设计系统、前端技术和 Codex 创建了一个名为 Search Playground 的环境。

Search Playground 的目标，是让公司各部门把想法转化为可工作的客户体验，先收集反馈，再判断是否值得继续投入。按照 OpenAI 的说法，已有超过10种新的搜索体验通过该环境完成，其中大多数由非工程人员构建，至少有三个已经运行在 loveholidays 网站上。

另一个例子来自营销活动“Crisps from Abroad”。团队希望制作一个互动微型网站，用于收集竞赛报名并分享旅行灵感。过去，这类项目可能需要交给外部代理商完成；这一次，营销团队结合 Codex 和 Search Playground，在数小时内完成了体验，同时沿用了 loveholidays 的设计系统。

loveholidays 工程主管 Dmitri Lerko 表示，公司的目标是“让试验新想法的能力与实际工程时间脱钩”。这并不意味着每个原型都会成为产品，而是让更多想法有机会先经过低成本验证。

把工程经验编码进工作流

Codex 在 loveholidays 的作用还延伸到了数据平台和基础设施。公司称，这些系统最初主要面向技术人员，修改数据管道或基础设施往往需要熟悉专门工具、代码仓库、版本控制和内部流程。遇到问题时，业务人员通常仍需要工程师介入。

现在，工程团队把最佳实践、操作说明和验证规则编码进工作流。员工可以先用自然语言说明希望完成的事情，Codex 再协助提出变更、运行检查，并引导其进入发布流程。对于业务人员来说，这相当于把数据和基础设施团队的一部分专业经验变成了可以随时调用的服务。

loveholidays称，过去一年数据平台中成功完成的人工智能辅助变更比例从58%升至93%；在每一次支持请求对应的时间里，数据平台变更数量增加到原来的四倍。在更广泛的自助基础设施工作流中，成功率也从63%升至90%。

这些指标需要结合公司的口径理解。文章没有披露成功变更的具体定义、样本规模、任务难度或统计方法，因此它们更适合作为企业部署案例中的运营指标，而不是可以直接推广到所有公司的生产率结论。

但对组织分工而言，变化相对清晰：业务团队可以在较少依赖专家支持的情况下处理部分需求，工程师则把更多时间用于改进平台、设计系统和解决更高层次的问题。loveholidays 首席技术官 Mike Jones 说，随着更多工作可以交给人工智能，工程师的工作不再只是拿到解决方案并实现它，而是需要更多参与业务问题本身。

代码更多了，但目标不是单纯增加代码

OpenAI称，loveholidays 的部署数量在一年内增加73%，工程人员数量大致保持稳定。与此同时，AI辅助代码变更比例从7%升至79%。这些数字描绘出一种常见的企业采用路径：先让代理进入工程流程，再逐步把它交给邻近工程但不以写代码为主要职责的团队。

不过，loveholidays强调，公司并没有把“使用了多少人工智能”作为唯一目标。Jones表示，技术只是实现业务目标的手段，关键在于它带来的影响。

公司举出的影响包括成本优化。由于团队有更多能力处理过去因机会成本过高而被推迟的工作，数据工程团队每年减少约3.6万英镑云存储成本，并通过降低数据处理浪费，每年再节省约10万英镑。

这些节省同样来自公司案例中的自报数字，尚未说明是否包含工具成本、迁移成本和维护成本。对其他企业而言，真正重要的可能不是复制某个百分比，而是建立一套能够把代理使用与部署质量、基础设施成本和业务结果联系起来的衡量方法。

Codex 正从编程代理变成“控制平面”

Lerko把 Codex 描述为工程师、数据科学家和业务团队共享的“单一控制平面”。这个说法揭示了产品定位的变化：Codex 不再只负责生成或修改代码，也在成为连接组织知识、内部流程和发布机制的接口。

这种方向与 OpenAI 对 Codex 的产品描述一致。其 Codex 产品页将 Codex 定位为能够完成拉取请求、重构、迁移和测试等端到端工程工作的代理，并强调工作树、云环境、技能和后台任务等多代理工作流能力。

OpenAI在另一篇关于 Codex 的文章中也表示，非开发者已经占其整体用户的一部分，并将 Codex 延伸到分析、营销、运营、设计、研究和投资等工作。企业版产品开始提供按角色适配的插件、可共享的网站和应用，以及对文档、表格和幻灯片进行局部修改的注释功能。这些功能显示，公司的目标正在从“帮助工程师写代码”扩大到“让更多岗位直接产出可交付成果”。

在 AIFlux 已发布的关于 OpenAI Admin 插件的报道中，Codex 和 ChatGPT Work 已经被放入工作区成员、权限和用量管理的对话式流程中。两条产品线合在一起看，Codex 的竞争重点正在从单次代码生成转向企业内部的持续执行、协作与治理。

“每个人都能构建”仍有边界

loveholidays 的案例并不意味着工程专业知识已经失去价值。相反，Codex 能够被更多人使用，部分原因正是工程团队预先把设计系统、验证规则和发布要求写进了工作流。非工程人员获得的是在边界内试验和交付的能力，而不是无限制地绕过技术治理。

这也带来几个尚未解决的问题。第一，AI辅助变更的成功率提高，是否同时意味着长期维护成本、技术债务和安全风险下降，文章没有提供证据。第二，更多人参与代码和基础设施修改后，组织如何划分最终责任，仍需要通过权限、审批、审计和回滚机制来回答。第三，部署数量增加73%是否转化为更多订单、更高转化率或更好的客户体验，OpenAI也没有披露相应的业务结果。

OpenAI近期发布的工作场所人工智能研究提供了更宽的背景：其对超过80万条美国用户工作相关消息的分析显示，16.8%的工作相关消息涉及的任务，以及43.5%的职业特定消息，分别与用户传统职业边界之外的工作有关。研究将这种现象称为“任务跨界”，认为人工智能正在让员工在正式职位名称改变之前，先承担其他岗位的一部分任务。

loveholidays 的做法可以被看作这一变化在企业软件开发中的具体版本。产品经理、设计师和商业人员没有变成传统意义上的软件工程师，但他们获得了把一部分业务需求直接转化为软件实验的能力。工程师的角色也没有消失，而是更多地转向设计平台、设定约束、检查结果以及解决更复杂的问题。

对企业来说，真正的考验将不只是能否让更多员工“开始构建”，而是能否在扩大参与范围的同时保持软件质量、权限边界和责任追踪。loveholidays 的案例显示，Codex 已经开始改变谁能够动手做软件；它能否稳定地把这种能力转化为可持续的组织生产力，还需要更多跨企业、可复核的长期数据。

来源： OpenAI：How loveholidays is making everyone a builder with Codex；OpenAI Codex 产品页；OpenAI：How AI is expanding what people do at work。