Codex是如何炼成资深AI程序猿的？a16z专访OpenAI编程智能体核心成员
6月11日消息，OpenAI编程智能体Codex团队的核心成员Hansen Wang和Alexander Embiricos，近日受邀参加全球顶级风投机构a16z（红杉资本）旗下知名播客《训练数据》，探讨了AI编程领域的创新突破。
Alexander是Codex团队的产品负责人，Hansen则是主导Codex训练的核心研究员，他们共同揭秘了Codex的发展历程——从最初的代码补全功能到如今支持长时间运行的编程智能体范式演进，并分享对开发者与AI协作模式的未来展望。
Codex是OpenAI推出的AI编程工具，致力于帮助开发者将编程任务委托给云端及本地智能体。2021年发布的初代Codex主要为GitHub Copilot提供技术支持，专注于代码行的自动补全，而全新升级的Codex已能实现后台任务的自动化处理。
与OpenAI推理模型o3相比，Codex具有更鲜明的特征：o3更擅长竞赛编程场景，而Codex通过强化学习调优，特别适配企业级日常开发需求。
划重点
Codex可在独立环境中持续工作30分钟，直接根据任务描述生成完整PR，颠覆传统编程模式。
统计显示工程师仅35%时间用于编码，Codex将接管实现与测试环节，让开发者专注创意与设计。
Codex的训练与使用环境100%一致，彻底解决AI “水土不服”的问题，保障生成代码即插即用。
初代Codex仅能补全单行代码，新版则可处理万行级项目重构，代码生成能力呈指数级增长。
以下是此次访谈精华内容：
01技术范式革命：AI智能体成为 “隐形搭档”
问： 你们能分享下Codex的最新功能以及它具体是如何工作的吗？
Hansen：对我来说，Codex这个名字承载着特殊意义。虽然GPT-3已足够惊艳，但正是初代Codex让我确信这项技术将改变世界，这甚至影响了我进入创业领域的决定。随着GPT系列迭代，我们预见到AI智能体将成为未来主流趋势，这正是我加入OpenAI并专注智能体编程研发的原因。
图注：Codex核心研究员Hansen Wang
Alexander：Codex的命名延续了OpenAI的极简主义传统。初代Codex曾是GitHub Copilot的技术核心。当我们开发新产品时，发现Codex（Code+Execution）这个品牌名完美契合产品本质，于是决定重新启用它。
Hansen：Codex代表着一种全新的智能编程范式，它是一个拥有独立容器和终端环境的云端编程智能体系统。开发者只需提交任务需求，系统就能自动生成可直接合并的Pull Request（简称PR，拉取请求，允许开发者将代码修改提交给项目维护者审核并请求合并到主代码库）。
我们一直在开发智能体和编码产品，Codex则是一个思维实验，探索如何通过AI编程，重点是让AI在自己的计算机上独立工作，而不是和人协作编程。
Alexander：与传统的人机协作编程不同，Codex的目标是让AI在独立环境中工作，你可以将任务委托给它，而不是和它一起编码。我们特别优化了计算环境，确保智能体既能写出功能正常的代码，更能产出符合工程规范的、可直接合并的优质代码——理想情况下，开发者甚至无需触碰电脑键盘。
图注：Codex团队的产品负责人Alexander
问：当模型的能力不再局限于仅生成下一行代码时，还需要进行哪些不同的工作？
Hansen：我认为最有趣的进展之一是——回顾我们发布首个推理模型o1时，我们就特别强调它在数学领域的卓越表现，甚至在编程竞赛中也是如此。直到今天，它在编程竞赛中的表现仍然优于我，也超过了OpenAI大多数成员。但我们发现，它在生成可合并代码方面表现欠佳。
而像o3这样的模型生成的代码，往往也不符合专业软件工程师的风格或标准。因此，我们投入大量精力训练新的模型，使其输出与专业软件工程师的品味和偏好保持一致——这需要大量专项训练工作。
Alexander：我有个非常贴切的比喻：像我们的Reync模型虽然在编码方面表现出色，但它更像是一个天赋异禀的优秀大学毕业生，具备竞赛编程能力，却缺乏作为团队中专业软件工程师所需的多年经验。因此，从o3到CodeX-1的演进，就像一个聪明的程序员初入职场前几年在积累工作经验。
问：用户在使用Codex时，最让他们惊喜的是什么？
Hansen：在我们的入职培训中，有个经典练习是“找bug修bug”。这正是Codex最拿手的！它不光能找出代码哪里有问题，还能自己验证问题，甚至给出修复方案。说实话，有时候我们遇到搞不定的bug，直接会把问题描述丢给Codex，它经常能给出管用的解决办法，特别神奇。
Alexander：我讲个真实故事：在产品发布前的凌晨1点，我们被一个动画bug卡住了。试了各种方法都不行，最后工程师把问题描述输进Codex试了四次——前三次没成功，但在第四次，Codex直接给出了我们熬夜几小时都没解决的完美修复方案！最终，产品发布会上的动画效果完美呈现。
02 角色转变：从“人写代码”到“人管理AI写代码”
问：OpenAI内部如何使用Codex？
Alexander：其实Codex最神奇的地方在于它完全颠覆了人们对AI工具的认知。大多数开发者熟悉的AI编程助手，比如GitHub Copilot，都是采用结对编程模式，像是一个实时互动的编程助手。
但Codex完全不同：它更像是一个可以“委托任务”的智能体。我们相信，未来的编程工作将发生根本性变革：不再是程序员独自在电脑前写代码，而是由多个AI智能体在各自的工作台上协作完成。这种任务委托模式需要使用者转变思维方式。
在Codex发布前的内测阶段，我们发现很多测试用户觉得这个工具似乎"没什么用"。直到我们观察OpenAI内部员工的使用方式才恍然大悟——关键在于使用心态的转变。现在我们甚至会特意在新手引导中创造"惊喜时刻"，教用户如何同时并行处理多个任务。当我们看到某个用户能在一天内（甚至一小时内）运行20个任务时，就知道他已经真正掌握这个工具的精髓了。
问：当你需要审核这些代码时，人的角色会发生什么变化？
Hansen：我们特别注重让AI的输出结果更便于人工审核，为此开发了独特的引用功能——模型能够自主引用其工作成果，这是其他工具所不具备的。具体表现为：它不仅会清晰展示修改了哪些文件，还会完整记录终端输出内容。
比如当测试用例失败时，系统会明确给出执行的命令及其完整输出，这种透明化的设计让审核工作变得更加高效。我认为这标志着软件开发模式的重要转变，未来开发者将把更多原本用于编码的时间转移到代码审核上。
问：将来代码审核是否还需要人工参与？
Hansen：至少在可预见的未来，人工审核仍然是必要的。这很大程度上取决于与早期用户建立信任关系的过程。开发者需要明确感知到哪些部分的代码运行良好，哪些部分可能需要额外验证。实际上，总会存在一些超出初始上下文的外部因素，这些因素往往决定着代码的正确与否。
Alexander：让我们从开发者工作流程的角度来看这个问题。典型的开发过程可以分为几个关键阶段：首先是创意阶段，需要与团队讨论并确定要开发的功能和方向；其次是设计阶段，明确具体的实现方案和架构；然后是计划阶段，制定详细的实施步骤和方法；接着进入实现阶段，实际编写代码；最后是验证阶段，进行充分的测试和调试。
这个循环不是单向的，每个阶段的产出都可能促使重新审视和调整前期的决策，从而形成一个持续优化的闭环。目前Codex最擅长的是实现和测试这两个技术性较强环节，而创意、设计和计划等更具创造性的工作仍需要人类主导。
有意思的是，统计显示工程师仅有35%的时间用于实际编码，编程并非他们工作的核心内容。我们构想的未来是：无论是软件开发还是其他专业领域，所有可自动化的重复性工作都可以委托给工具处理，而人类则可以专注于那些更具挑战性、需要创造力的工作。
我们的发展路径是渐进式的。现阶段，我们通过工具加速开发流程：开发者提出需求，评估生成的代码质量，然后提交团队审核。随着技术发展，我们将逐步扩展能力范围，帮助用户完成更多规划设计工作，甚至协助进行决策思考。最终目标是让整个代码审核过程变得更加高效智能，而不是完全取代人工审核。
Hansen：我确实预见未来会出现多智能体协作的开发模式。比如CodeX智能体负责编写代码，测试智能体负责质量验证，还可能存在部署智能体、运维智能体等，这些专业化的智能体协同工作将极大提升开发效率，这种技术演进确实令人期待。
03 低门槛工具+更多定制需求：软件开发者数量将不降反增
问：你认为随着技术发展，专业软件开发者的数量会如何变化？
Alexander：我个人认为，专业软件开发者的数量将持续增长。这个判断基于两个核心逻辑：
首先，软件开发门槛的降低必然带来软件需求的爆发式增长。就像智能手机应用生态的发展轨迹一样，当前大部分应用都是由大型团队为海量用户开发的通用型产品，而真正满足个人化需求的定制化软件占比很低。
其次，当开发工具变得更易用时，不仅会释放现有开发者的生产力，更重要的是会催生大量新的应用场景和细分需求，这些都需要更多专业开发者来实现和维护。因此，随着编写定制软件变得越来越实用，需求会逐步增加。
问：在技术层面，CodeX与o3模型的差异体现在哪些方面？
Hansen：实际上它与o3模型架构相同，只是进行了额外的强化学习微调。不过我认为核心区别在于，这个模型更注重软件工程师的定性能力培养，而不仅仅是编程技巧。比如代码风格规范、注释撰写标准等细节——这些正是其他模型常被诟病的短板。
此外，我们面临的最大挑战是构建高质量的学习环境。现实中的软件仓库极其复杂，开发环境往往混乱无序，因此我们通过渐进式生成更贴近现实的环境来训练智能体。
我们能让这个端到端产品稳定运行的关键在于：训练环境与使用环境完全一致，都采用容器化基础设施。用户使用CodeX时，实际上运行在与训练完全相同的环境中，彻底避免了“水土不服”的问题。
04 “实时协作”+“任务委托”：CodeX演进成智能队友
问：据我所知，CodeX某些任务需要运行长达30分钟，这甚至超过了OpenAI深度研究项目的最长任务耗时。在支持这种超长时推理任务方面，你们遇到过哪些意料之外的挑战？
Alexander：我想从产品角度谈谈。虽然建模方面存在诸多技术挑战，但从产品维度看，最核心的问题始终是用户意图识别。
以IDE（编程环境及集成开发环境）自动补全为例，预测用户即时意图相对简单，但当任务耗时达30分钟时，帮助用户厘清需求本身就变得极具挑战——因为他们可能自己都不确定要做什么。
因此我们持续探讨的核心议题是：如何确定任务的最佳粒度？如何让CodeX既能处理单行代码修改，又能胜任大规模重构（当需求明确时），甚至协助规划模糊的需求。比如是否应该先让CodeX生成实施方案，再由用户选择执行路径？这个问题至今仍在讨论中。
Hansen：这里有个实用技巧：如果需要CodeX工作一小时，用户往往需要花费10-20分钟进行详细规划。更高效的做法是启用“询问模式”：先让模型生成高层方案框架，通过交互式调整完善细节，最后再执行完整任务——这就像指导实习生工作，先讨论整体方向，逐步细化，最终让它完成工作。
问：在模型表现方面，是否出现过一些令你们惊讶的行为特征，特别是在执行长时间任务时？
Hansen：在长时间推理过程中，模型展现出了更强的任务专注力。不过必须承认，虽然模型具备超乎寻常的耐心，但这种耐心也存在极限。有时运行30分钟后，它会突然“宕机”，就像人类遇到瓶颈时的反应。这种类人特性正是我们重点优化的方向，就像指导实习生时遇到的典型场景。
问：我很好奇你们如何看待人机交互模式的演进？随着产品矩阵的发展（比如CodeX和CodeX CLI），在工程和产品设计层面还有哪些创新空间？
Alexander：最初发布的CodeX更像是一个研究预览版，本质上是个思想实验——虽然具备实用价值，但显然处于非常早期的阶段。我们最引以为傲的是三大核心：CodeX模型本身、计算环境基础设施，以及经过反复打磨的UI界面。不过目前的形态远非终点。
当前CodeX UI采用类似ChatGPT的对话界面：用户提交任务后，系统会生成待办列表式的可操作项。这个设计强调“异步代理”理念——用户更像是下达任务的委托方。但我们的终极愿景是：消除委托与协作的界限，让用户感觉是在与无处不在的智能队友共事。
无论使用何种开发工具，都能随时召唤它：可能在你开始工作前，CodeX就已预检代码并提出建议；你可以随时询问，它会根据任务复杂度自主决定响应时间，最终协助完成修改。本质上，我们要实现“实时协作”与“任务委托”的无缝融合。
我们构想的未来不是让用户在不同场景下切换各种专用智能体（编程助手/购物助手/营销助手等）。相反，ChatGPT将作为统一入口的个人智能中枢。对于专业开发者这样的深度用户，可以在IDE等专业工具中获得定制化界面——包含优化的工作流按钮和功能列表，从而极致提升工作效率。
05 未来编程将被AI全面接管？
问：你们如何看待当前市场的演变趋势？OpenAI内部有诸多战略方向，当谈及异步任务和ChatGPT时，我们也看到其他专业化工具和模型的爆发式增长。
Alexander：这确实是开发者最好的时代，也是最具挑战的时代——工具生态呈现爆炸式增长，但市场迭代速度太快了。未来两年内，编程方式将发生根本性变革。目前，大多数人觉得最有价值的工具是那些与你的开发环境紧密结合的工具，它们就像“编程搭档”。而未来趋势将是：大部分代码将由智能体自动生成。
这些智能体不会局限在单任务环境，它们将拥有专属工作空间，不仅能响应具体指令，更能主动连接开发工具完成工作。虽然智能体转型方向明确，但如何管理其生成的代码仍是个问题。
问：像Claude Code、Jules这类智能编程工具，你们如何看待它们的定位？未来市场会趋向统一标准吗？OpenAI的核心优势体现在哪些方面？
Alexander：市场将会分化。部分工具在本地运行，部分在云端执行——正如我所说，未来主要工作将在智能体计算环境中完成，但本地开发体验仍至关重要。理想状态是兼顾两端，但主战场无疑在智能体环境。
Hansen：软件工程最困难之处在于将业务需求转化为技术方案。正如我们常说的，编码本身并非最耗时的环节。ChatGPT的优势在于：具备记忆能力、工具调用能力，以及我们通过Operator深度研究获得的各种专业能力。当这些要素有机结合时，CodeX这类工具就能真正大放异彩——它不仅能理解需求，更能高效执行编码任务。
Alexander：想象雇佣一个只会提交PR的工程师，或者只能完成预设功能的开发者，这种局限性会令人沮丧。而我们正在构建的智能体必须具备通用性，就像人类同事那样灵活。
因此我们的策略是：选择重点领域突破，比如通过CodeX为开发者群体优化GPT-4.1，建立专属评估体系。但长远来看，这些专业能力终将沉淀为普适性功能，变成人人都能使用的简单工具。所以最终，ChatGPT这类通用产品和专业编程工具会走向不同的发展路径。
问：你们认为开发者未来会通过哪些主要方式与CodeX交互？是通过ChatGPT、命令行界面、IDE，还是这些工具的综合体？
Hansen：我们认为应该是多模态融合的交互方式。关键在于实时响应开发者的场景化需求——不仅限于编辑器或终端，而是覆盖整个开发生命周期的触点。
Alexander：我构想了一个未来化的交互场景：假设你是一家初创公司创始人，团队只有几位核心成员，但配备了多个智能体助手。
工作流程可能会像TikTok的交互模式：你的信息流中会垂直展示智能体生成的方案视频，比如“客户提出这个需求，建议这样实现”。你可以像刷短视频一样：右滑表示“立即执行”，左滑表示“需要讨论”，长按则能输入详细反馈，比如“方案可行，但请使用斜体字体”。
本质上，这些智能体会实时订阅公司数据流，主动提出想法并执行任务，而你只需要像产品经理一样审核工作流即可。这种模式下，人类开发者既能保持核心决策权，又能获得智能体的全方位支持。（文/腾讯科技特约编译 金鹿）
