Rakuten 借助 Codex 实现问题修复速度翻倍

Rakuten⁠⁠（在新窗口中打开） 是一家全球创新企业，业务覆盖电商、金融科技和移动通信，以庞大规模服务消费者和商家。该公司在全球拥有 30,000 名员工，其工程团队在庞大而复杂的产品生态中持续交付，速度与可靠性都至关重要。

因此，Rakuten 商务 AI 总经理 Yusuke Kaji 在过去一年里一直推动将智能体工作流更深入地融入团队规划、构建和验证软件环节。Codex⁠⁠ — OpenAI 推出的编程智能体 — 已成为 Rakuten 工程技术栈的核心组成部分，尤其是在公司需要在不牺牲安全性的前提下加快推进工作时。

过去一年里， Rakuten 工程师在运维和软件交付环节广泛使用 Codex，以压缩事件响应时间（包括将平均恢复时间，即 MTTR，缩短约 50%）、通过自动化代码审查和漏洞检查强化 CI/CD，并为复杂项目提供自主性更高的开发支持。

在 Rakuten 的工程团队内部，其 AI 议程清晰明确，并刻意聚焦运营落地。Kaji 将这项工作概括为团队共同围绕的三项优先事项：

• 构建提速（“速度！速度！速度！”）：团队在运维工作流中使用 Codex，包括基于 KQL 的监控与诊断，以加速根因分析和修复，帮助将 MTTR 最多缩短 50%。
• 更安全地构建（“把事情做成”）：在 CI/CD 中调用 Codex 进行代码审查和漏洞检查，自动应用内部标准，让团队能够在有护栏的前提下快速交付。
• 更智能地运营（“AI 化”）：Codex 推动更大、更模糊的项目从需求文档直接生成可用实现，降低对完美定义的依赖，实现更自主的执行，并最终将原本持续一个季度的工作压缩到数周内完成。

作为更广泛工具体系中的可靠智能体，Codex 与每项优先事项都直接对应，在速度、安全和自主性能够产生复利价值的地方发挥作用。

在 Rakuten，“速度”不仅指开发效率，也包括故障恢复速度。

团队使用 KQL（Azure 用于日志和遥测的查询系统）监控 API 并分析信号。Codex 与这些工作流协同工作，帮助识别根因并建议修复方案，缩短从告警到解决的时间。

从站点可靠性工程 (SRE) 的角度看，这缩短了从检测到修复的路径。工程师无需手动拼接查询、日志和补丁，而是可以专注于验证和部署修复。

Rakuten 估计，这种方法在问题发生时可以将 MTTR 降低约 50%。或者更直白地说：当出现故障时， Rakuten 已经使用 Codex 将问题修复速度提升了一倍。

随着交付加速，审查和部署可能成为瓶颈。Rakuten 通过将 Codex 直接集成到其 CI/CD 流水线中来解决这一问题。

在变更进入生产环境之前，Codex 会执行代码审查和漏洞检查。Rakuten 将内部编码原则和标准纳入这些工作流，使审查结果与公司预期保持一致。

“我们会将内部编码原则提供给 Codex，”Kaji 说。“它会依据同样的原则，审查代码是否符合我们的标准。”

结果是：安全检查能够持续且自动地进行，使团队在不降低标准的情况下更快推进。

Rakuten 的第三项优先事项 — AI 化 (AI-nization) — 聚焦于自主性。Codex 不仅用于审查和维护，也用于端到端执行更大、更模糊的项目。Codex 不需要完美定义的规格说明书，它可以根据部分需求推进工作，并生成可用的工件。

“最新的 Codex 模型能理解隐含需求，”Kaji 说。“即使需求没有被完美定义，它也能理解我们想要构建什么。”

其中一个例子是：为现有基于 Web 的 AI 智能体服务构建移动应用版本。Codex 在没有人工逐步指示的情况下实现了全部规格，完成了包含 Python/FastAPI 后端和 Swift/SwiftUI iOS 应用的全栈实现，以及全部后端 API。Codex 将该项目的开发时间从一个季度缩短到数周。

随着 Codex 承担更多代码生成工作，Rakuten 正将工程师的角色转向编写更清晰的规格说明，并依据可衡量的标准验证输出。

“我们的角色不再是检查每一行代码，”Kaji 说。“我们的角色是清楚地定义我们想要什么，并建立验证方法。”

Rakuten 通过面向工程、产品和非技术团队的实操工作坊来支持这一转变。这促使 Codex 成为核心引擎，助力团队加速交付、强化运维安全，并在全公司范围内实现自主开发的规模化。