深度｜OpenAI产品经理谈Codex爆发式增长背后的AI协作：实现AGI级生产力的真正瓶颈是人类的打字速度！

深度｜OpenAI产品经理谈Codex爆发式增长背后的AI协作：实现AGI级生产力的真正瓶颈是人类的打字速度！深度｜OpenAI产品经理谈Codex爆发式增长背后的AI协作：实现AGI级生产力的真正瓶颈是人类的打字速度！ Modified January 19 所以，如果你现在创业，并且对特定用户群体的痛点有着深刻的理解，那你就已经成功了一半；但如果你只是擅长搭建网站这类技术开发工作，却没有明确的目标用户，那创业之路可能会走得非常艰难。 Lenny：听你这么说，你是看好垂直领域AI创业公司的发展前景。没错，我完全同意这个观点。市场上确实存在两类产品：一类是能解决多种问题的通用型工具，另一类则是深耕某一细分领域的垂直产品——比如专注于优化演示文稿制作，比任何人都更懂演示文稿相关的痛点，并且能无缝融入用户的工作流程，针对性地解决这类特定需求。这个方向真的很有前景。说到Codex的研发进展，我猜想你们内部应该有很多评估指标（ZP注：Evals，指对模型性能进行的评估测试），同时也会参考各类公开基准测试（ZP注：Benchmarks，指用于对比模型性能的标准测试集）。你们是通过哪些指标来判断产品是否取得了显著进展的？我知道肯定不会只看单一指标，所以想了解一下你们重点关注的方向，以及正在努力推进的KPI有哪些？ Lenny：当你考虑Codex的进展时，我猜你们应该有很多评估和公共基准。你会关注哪些方面来告诉自己，“好，我们正在取得非常好的进展”？我想这不可能是一个单一的因素，但你们最关注的是什么？你们在推动什么？有什么关键绩效指标（KPI）？ Alexander Embiricos：我时常提醒自己，Codex这类工具，用户很容易发展成重度用户。这就意味着，我们很容易不自觉地把大量精力投入到开发那些深度功能上——也就是那些只有用户深度使用产品后才会用到的功能，最终可能会在这方面过度投入资源。因此，我认为关注7日留存率（ZP注：D7 retention，产品运营术语，指用户注册7天后仍会使用产品的比例）这类指标至关重要。我们还会以全新用户的身份重新体验产品，从注册开始一步步操作。为了能以最真实的方式进行内部试用，我用自己的谷歌邮箱注册了好几个ChatGPT Pro账号，这些账号每个月要花掉我差不多200美元，我得走报销流程才行。但在我看来，亲身体验普通用户的使用感受，同时密切关注早期留存数据，对我们来说依然是重中之重。毕竟，尽管这个赛道现在发展得如火如荼，但整体而言，Agent工具的用户普及度仍处于非常早期的阶段。另外，我们团队可能是这个领域里最热衷于收集用户反馈、关注社交媒体舆情的团队之一。我们有几位同事会时刻关注Reddit和Twitter上的相关讨论，平台上既有对产品的赞扬，也充斥着大量的吐槽和抱怨。而我们会高度重视这些负面反馈，认真研究和分析。因为Coding Agent的应用场景非常广泛，往往会在某些特定功能上暴露出问题。所以我们会经常监测社交媒体上的用户舆论倾向。特别是 Twitter的氛围会更偏向炒作，而Reddit上的评价虽然更尖锐，但也更真实客观。因此，我现在越来越关注Reddit上用户对Codex实际使用体验的讨论。 Lenny：这对大家来说非常重要，能告诉我你们常关注哪些subreddits吗？是不是有像r/Codex这样的板块？ Alexander Embiricos：嗯，算法其实很擅长推荐相关内容，但r/codex确实存在。 Lenny：这点对很多人来说都很有参考价值。你们最常关注哪些SubReddit？有没有专门讨论Codex的r/Codex版块？ Alexander Embiricos：平台的算法其实很智能，会主动推送相关内容。不过确实是有r/Codex这个子版块的。没错。Twitter的互动模式更偏向一对一交流，哪怕是公开推文也是如此；而Reddit有一套完善的投票机制，而且上面的用户大概率还是真人——虽然也不能完全确定没有机器人账号。所以从Reddit上，我们能更清晰地捕捉到哪些内容是用户真正关心的，以及大家对产品的真实看法。 Lenny：那我想简单聊聊Atlas浏览器。你们推出这款产品的时候，我还发过一条推文，说我试用了Atlas，但不太喜欢它那种纯AI驱动的搜索体验。有时候我就是想直接用谷歌搜索，而不是等着AI生成答案。而且当时的版本还没有切换搜索模式的选项，所以我就发推文说 “我还是换回原来的浏览器吧，这款体验不太好”。我感觉这条推文可能让OpenAI的一些产品经理有点难过。不过后来我看到有人发推文说，Atlas已经新增了相关功能。我猜想这个功能其实早就规划好了，这或许就是你们的产品迭代策略——先把产品推向市场，观察用户的实际使用情况，然后再针对性地优化调整。所以我想问两个问题：第一，这件事背后有没有什么值得分享的细节？第二，我很好奇，你们为什么要研发一款网页浏览器呢？ Alexander Embiricos：我之前参与过一段时间的Atlas项目，但现在已经不负责相关工作了。不过我可以从个人角度聊聊这个项目的初衷。我之前创办过一家做屏幕共享和结对编程（ZP注：Pair Programming，指两名程序员共用一台电脑协作开发的模式）的创业公司，后来我们团队加入了OpenAI。当时我们的核心想法是打造一款情境感知桌面助手（ZP注：Contextual Desktop Assistant，指能感知用户当前操作场景并提供针对性帮助的智能工具）。我之所以认为这个方向很重要，是因为我发现，用户要先向智能助手提供大量上下文信息，才能让它提供有效的帮助，这个过程其实非常繁琐。但如果智能助手能主动理解用户当下的操作意图，就能最大限度地提升用户的工作效率。其实在我看来，Codex本质上也算是一种情境感知助手，只不过它是从代码开发这个垂直领域切入的。至少就我个人的想法而言，很多工作都是在网页端完成的，如果我们能打造一款浏览器，就能以一种更原生、更优质的方式实现情境感知功能。我们不用再去适配其他桌面软件——这些软件对辅助功能树（ZP注：Accessibility Tree，指用于辅助技术解析网页内容的树形结构）的支持程度参差不齐；也不用依赖截图技术，毕竟截图不仅速度慢，而且可靠性不高。相反，我们可以直接深入浏览器的渲染引擎（ZP注：Rendering Engine，浏览器核心组件，负责解析和显示网页内容），提取我们需要的各类信息来为用户提供帮助。我还喜欢用电子游戏来打比方，不知道你有没有玩过《光环》（Halo）这类游戏？当你走到某个物体旁边时——很多游戏其实都是这样的，我都有点不好意思说，毕竟已经过去很久了——按下X键，游戏角色就会做出相应的正确操作。我以前买每一款电子游戏，都会认真阅读说明书。我还记得第一次在说明书上看到 “情境交互”（ZP注：Contextual Action，指根据玩家所处场景触发的对应操作）这个概念时，就觉得这是个非常酷的设计。而情境交互的核心在于，首先要理解用户当下的操作意图，掌握一定的上下文信息，然后才能提供恰到好处的帮助。我认为这一点至关重要，因为我们可以设想这样一个未来场景：Agent每天要为用户提供数千次帮助，如果它只能通过推送通知的方式告知用户 “我帮你完成了这件事，你觉得怎么样”，那用户每天就要收到上千条推送，这显然会让人不胜其烦。但换个角度想，回到软件工程的工作场景：假设我正在查看数据仪表盘，发现某个核心指标出现了下滑，这时AI可以主动介入分析，然后在我查看仪表盘的当下，直接给出它对指标下滑原因的判断，甚至提供对应的解决方案。这种方式不仅能让我保持工作的沉浸感，还能让Agent处理更多事务。所以在我看来，我们研发浏览器的部分原因就在于，通过浏览器，我们能更精准地捕捉用户的上下文信息，从而明确应该在哪些场景下提供帮助。同时，用户也能更好地掌控哪些内容愿意让我们的工具访问——比如，如果你希望Agent处理某项任务，就可以在这款AI浏览器中打开相关内容；如果不想，那就用其他浏览器。这样一来，用户的控制权和使用边界就非常清晰了。此外，我们还能在浏览器中设计人机混合主动交互（ZP注：Mixed Initiative，指人类和Agent共同主导交互流程的模式）的用户体验，让Agent在合适的时机主动提供情境化操作建议，而不是随意推送通知打扰用户。 Lenny：听你这么说，Codex的愿景是成为一款超级助手，它的作用不只是帮人写代码，而是像一个超能搭档一样，在工作中为你提供各种各样的帮助，让你在工作中表现得更加出色。我现在完全明白了。说到这里，Codex有没有什么非工程领域的常见应用场景呢？我们之前聊过设计师用它来制作原型和开发功能。除此之外，有没有什么非工程师群体使用Codex的有趣或者出人意料的方式呢？ Alexander Embiricos：其实这类用法有很多，都挺出人意料的。不过目前来看，真正能让用户产生高粘性的场景，大多还是和编程相关，或者是偏技术导向的领域——这些领域往往已经形成了成熟的生态系统，比如数据分析这类工作。我个人预计，未来这类跨领域的应用场景会越来越多，但就现阶段而言，我们团队的精力还是高度集中在编程相关的功能上，毕竟这个方向还有大量的工作要做。 Lenny：对于那些想尝试使用Codex的人来说，它是否适用于所有类型的代码库？它支持哪些编程语言？比如如果是做SAP相关的开发，能不能接入Codex来开展工作？它的优势应用场景是什么？又有哪些场景目前的表现还不够理想？ Alexander Embiricos：你问的这个问题其实非常关键。尝试使用Codex的最佳方式，就是把你最棘手的任务交给它，这一点和其他一些Coding Agent不太一样。有些工具可能会建议你从简单的任务入手，或者随意写点代码来判断自己是否喜欢这款工具。但我们打造Codex的定位，是让它成为一款专业级工具，你可以放心地把最难解决的问题交给它，让它在庞大的代码库中生成高质量的代码。当然，它现在的表现还谈不上尽善尽美。所以，如果你打算尝试Codex，最好用一个真实的工作任务来测试它，不必特意把任务简化成无关紧要的小事。比如，你遇到了一个很难排查的bug，不知道问题出在哪里，就可以让Codex帮忙分析原因，或者直接编写修复代码。 Lenny：这个回答我太喜欢了，直接把最难的问题交给它就行。 Alexander Embiricos：不过我得补充一句，如果你说 “我现在最难的问题是要打造一个能估值超10亿美元的独角兽企业”，那显然Codex目前还做不到，至少现在还不行。所以我的建议是，交给它的任务得是那种最难，但本质上还是一个独立的问题或单一任务的工作。刚开始试用的时候可以这样操作，之后再慢慢摸索，学着用它来处理更大型的项目。 Lenny：好的。那它支持哪些编程语言呢？ Alexander Embiricos：我们训练Codex的方式，决定了它支持的编程语言分布，和这些语言在现实世界中的使用频率是基本一致的。所以除非你用的是那种非常冷门的编程语言，或者是某些企业内部的私有编程语言，否则Codex在你使用的语言上应该都能有不错的表现。 Lenny：如果是新手刚开始使用Codex，你有没有什么小技巧可以分享，帮助他们更好地使用这款工具？比如，要是你能悄悄给第一次配置Codex的用户一个建议，让他们获得良好的使用体验，你会说些什么？ Alexander Embiricos：我可能会建议他们并行尝试几件事。比如，既可以把一个难题交给它，也可以让它帮忙理解某个代码库的结构，还可以和它一起围绕某个想法制定开发计划，然后循序渐进地深入使用。这里面的核心思路是，你其实是在和一个新的团队伙伴建立信任。你不会刚认识一个同事，就毫无铺垫地丢给他一个任务。你应该先让他熟悉代码库，然后和他对齐工作思路，再让他一步步推进工作。如果你用这种方式来使用Codex，就会自然而然地摸索出和它交互的不同Prompt技巧。因为它确实是一款功能极其强大的Agent和模型，但给Codex写Prompt的方式，和给其他模型写Prompt还是有点不一样的。 Lenny：我还有几个问题想问。第一个问题，随着AI在代码编写方面的参与度越来越高，一个老生常谈的问题也随之而来：我们还应该学习编程吗？为什么要花时间做这件事？对于那些正在规划职业方向的人，尤其是有志于从事软件工程、计算机科学领域工作的人，你觉得计算机科学领域有哪些知识板块会变得越来越重要？又有哪些内容其实已经没必要再花太多精力去关注了？在AI日益融入工作场景的趋势下，大家应该着重培养哪些技能？ Alexander Embiricos：这个问题可以从几个角度来分析。首先，最容易想到的一点是，要做一个实干派。随着Coding Agent的能力不断提升，即便是大学生或者刚毕业的新人，能完成的工作也远比以前多得多。所以我认为，大家应该充分利用这个优势。说实话，在招聘职场新人的时候，我很看重的一点就是，他们能不能熟练运用最新的工具来提高工作效率。他们本该如此，而且从这个角度来看，新人相比资深从业者的劣势其实变小了 ——因为这些强大的Coding Agent，正在缩小不同资历人员之间的能力差距。所以这方面的建议就是：你可以学习任何自己感兴趣的内容，但一定要花时间去实践，而不只是完成课后作业。不过从另一个角度来看，理解一个优秀的软件系统是如何构建的，这一点依然至关重要。我认为，像扎实的系统工程能力，以及高效的团队沟通协作能力这类技能，在未来很长一段时间内都会很重要。我并不认为，AI Coding Agent很快就能在没有人类协助的情况下，独立构建出完美的系统。这个过程会是循序渐进的。就拿我们之前聊到的Atlas项目来说，有一位工程师就为Codex搭建了一套能让它自我验证工作成果的机制。考虑到Atlas项目的特性，这件事其实并不简单。他的做法是，不断给Codex发送Prompt：“你为什么无法验证自己的工作成果？赶紧修复这个问题。” 通过这种循环优化的方式，最终实现了这个功能。由此可见，在Agent工作的不同阶段，依然需要人类参与其中，帮助配置Agent，使其更高效地工作。所以，人类依然需要具备对系统进行逻辑推理的能力。这么说吧，或许快速敲代码的能力，或者精准掌握如何编写某个循环语句、如何实现某个特定算法这类技能，已经没那么重要了。但你必须能够理解不同的系统架构，知道怎样才能打造一个高效的软件工程团队。我认为这才是另一个非常重要的能力。最后，还有一个可以切入的角度：如果你能深耕某个领域的前沿知识，我觉得这也是一件非常有意义的事。一方面是因为，Agent在这类前沿领域的表现还不够好；另一方面是因为，当你试图推进某个领域的技术边界时，会自然而然地倒逼自己去充分利用Coding Agent，借助它们来加速自己的工作流程。 Lenny：你说的深耕前沿领域，能不能举个例子？ Alexander Embiricos：比如，Codex会编写大量代码，用于辅助管理自身的训练过程和核心基础设施。我们的工作节奏很快，Codex的代码审查功能帮我们发现了很多错误，其中还包括一些非常有意思的配置错误。而且我们已经看到了一些未来的雏形：我们开始让Codex参与到自身训练的应急值守（ZP注：on call，IT运维术语，指负责处理突发故障的值班工作）中，这个应用场景其实非常有意思，里面大有文章可做。 Lenny：等等，让Codex参与自身训练的应急值守是什么意思？是不是说，当它在进行训练的过程中出现故障，需要人工介入的时候，它会主动发出警报，还是会直接自行修复问题，然后重启训练？ Alexander Embiricos：这其实是我们正在探索的一个早期想法。它的基本思路是这样的：在模型训练过程中，会产生大量的数据图表，目前这些图表都是由人工来监控的，这项工作非常关键，我们把这个过程叫做 “人工盯控”（babysitting）。 Lenny：我猜这是因为模型训练的成本非常高昂，而且快速推进项目进度也很重要。 Alexander Embiricos：没错。模型训练的背后涉及大量的系统，任何一个系统都有可能出现故障，或者在某个环节引入错误。这时候我们可能需要修复问题、暂停训练，或者采取其他应对措施。所以我们的想法是，让Codex持续运行一个监控循环，评估这些数据图表的实时变化趋势。通过这种方式，我们就能大幅提升模型训练的效率。 Lenny ：这个想法太赞了，这绝对是Agent未来的发展方向。Codex的作用不只是编写代码，它能做的事情还有很多很多。好了，最后一个问题。既然你在 OpenAI工作，我必须得问问你对通用AI实现时间线的看法，你觉得我们离实现通用AI还有多远？我知道这不是你负责的领域，但现在关于这个话题有很多不同的观点和时间预测。在你看来，我们距离实现具备人类智能水平的AI——无论你如何定义这种智能——还有多久？ Alexander Em biricos：在我看来，这件事的关键在于，我们什么时候能看到技术发展的增长曲线出现指数级跃升，也就是我们常说的 “曲棍球杆式增长”（Hockey Stick）。目前制约技术发展的因素有很多，但我认为有一个因素没有得到足够的重视，那就是人类的打字速度，或者说人类编写Prompt时的多任务处理速度。就像我们之前聊到的，Agent可以实时监控你的所有工作，但如果它无法自主验证工作成果，那么人类就依然会是效率瓶颈。所以我的观点是，我们需要打破这种由人类手动编写Prompt、手动验证所有工作成果所造成的效率限制。如果我们能够重构系统，让Agent默认就能主动提供有效的帮助，那么技术发展的指数级增长就会随之而来。不过，我认为这个过程不会是一蹴而就的，它会高度依赖具体的应用场景。比如，我可以预见，到明年，如果一家创业公司要开发一款新的应用程序，它完全可以搭建一套技术架构，让Agent在其中发挥高度自主的作用。但反过来，如果是像SAP这样的企业，它们拥有大量复杂的系统，显然不可能在一夜之间就让Agent完全自主地处理这些系统的相关工作。它们必须循序渐进，或许要逐步替换或升级现有系统，才能让Agent端到端地处理更多工作。所以，回到你的问题，我的详细回答——可能听起来有点枯燥——是：从明年开始，我们会看到一些早期采用者的工作效率出现指数级提升。在接下来的几年里，越来越多的大公司也会迎来效率的爆发式增长。而在这个过程中的某个模糊的时间点上，这种效率的提升会反过来推动AI实验室的技术突破，届时我们基本上就可以认为通用AI的时代到来了。 AI时代别死磕写代码！这3项能力才是未来硬通货 Lenny：这个回答太务实了，这个话题也是我的播客经常会聊到的——审核AI生成的所有内容，这件事实在是太麻烦了，而且已经成为了一个巨大的效率瓶颈。你们正在攻克这个难题，我觉得非常棒。让编程变得更高效是一回事，而解决最后那个关键问题——验证AI生成的内容是否真的可靠——则是另一回事。你认为人类的打字速度是制约技术发展的关键因素，这个观点真的很独特，我以前从来没有听过这种说法。这其实也印证了你之前提到的一个观点：即便AI的技术水平不再提升，只要我们能学会更高效地使用现有的工具，依然可以释放出巨大的潜力。Alexander，我们今天聊了很多内容。有没有什么我们没谈到，但你想补充或者强调的事情？在进入激动人心的快问快答环节之前，你还有什么想说的吗？ Alexander Embiricos：我想提一件事，Codex团队目前正在扩招。正如我刚才所说，我们现在的工作效率，在一定程度上还是受到人类思考速度和打字速度的限制，我们正在努力解决这个问题。所以，如果你是工程师、销售人员，或者是想从事产品相关工作的产品人，都欢迎联系我们。我不太确定提供联系方式的最佳方式，不过大家可以去查看我们的招聘页面，或者通过你进行联系？你的听众有什么方式可以联系到你吗？ Lenny：如果他们想通过我联系你，说 “我想申请加入Codex团队”，我的个人网站上有一个联系表单。不过我有点担心，到时候会有太多优秀的人才来找我。不过没关系，大家可以试试这个方式，看看效果如何。 Alexander Embiricos：好的。或者——当然这段内容之后可以剪辑掉，取决于你的安排——大家也可以直接给我发私信。比如，我在Twitter上的账号是 Embiricos ，如果你有兴趣加入我们的团队，欢迎随时私信我。 Lenny：这绝对是很多人梦寐以求的工作机会。你有没有什么筛选应聘者的小妙招，避免自己的收件箱被求职信淹没？ Alexander Embiricos：具体来说，如果有人想加入Codex团队，那么他首先得是一名技术从业者，并且正在使用这类AI工具。我建议每个人都先问自己一个问题：“假设我加入 OpenAI，在未来六个月里全身心投入Codex的相关工作，并且做出了出色的成绩。那么到那个时候，软件工程师的工作状态会变成什么样？” 在我看来，如果你能对这个问题有自己的见解，就可以提交申请了；如果你对此没有想法，需要先花时间思考一下，那么这个思考的过程，其实就是一种筛选机制。现在有很多人都在关注这个领域的发展，我们非常希望能吸引到那些已经深入思考过Agent未来发展形态的人才。当然，我们不一定非要在未来的发展方向上达成共识，但我们希望找到那些对这个领域抱有极大热情的人。关于Embiricos本人的五个问题 Lenny：能参与一款影响力如此巨大、且处于技术前沿的产品研发，这样的机会非常难得。对于合适的人来说，这绝对是一份超棒的工作。你们现在有岗位空缺，而我的听众群体恰好可能非常契合这个岗位的需求，这真是太好了。希望我们能帮你们找到一位极其优秀的人才。好了，接下来我们进入激动人心的快问快答环节。Alexander，我准备了五个问题，你准备好了吗？ Alexander Embiricos：虽然不知道会问什么，但我已经迫不及待了，开始吧。 Lenny：这些问题除了最后一个，其他的我都会问每位嘉宾。所以可能没什么惊喜，或许我以后该多准备些不一样的问题。好的，第一个问题：你最想推荐给大家的两三本书是什么？ Alexander Embiricos：我最近读了很多科幻小说。我知道这本书应该已经被推荐过很多次了，就是《文明》系列，作者应该是伊恩・班克斯。我喜欢这套书的原因是，它描绘了一个AI共存的未来世界，而且是一个充满希望的未来。要知道，很多科幻作品的基调都比较反乌托邦。我觉得用这个虚构的文明世界作为参照，去思考我们能开创怎样的未来，以及当下应该做出哪些决策来推动这样的未来到来，是一件很有意思的事。 Lenny：哇，我好像从没听过有人推荐这本书。我记得你在录制开始前提过，你最近在看《指环王》。如果你还想读一些和AI相关的科幻小说，有没有读过《深渊上的火》？ Alexander Embiricos：没有，我没读过。 Lenny：这本书非常精彩，算是一部太空歌剧式的宏大科幻史诗，里面还涉及到了超级智能的设定。 Alexander Embiricos：听起来不错。 Lenny：这本书的基调不算完全乐观，但也带有一定的希望色彩。好的，下一个问题：最近有没有什么特别喜欢的电影或者电视剧？ Alexander Embiricos：有一部叫《咒术回战》的动漫，我特别喜欢。这部作品的题材有点暗黑，和咒灵有关，但我喜欢它的点在于，主角是个非常善良的人。我发现现在动漫和动画领域出现了一种新趋势，主角不再是过去那种形象，而是变得非常友善，心怀天下。你看以前那些开创了这类题材的经典动漫，比如《新世纪福音战士》或者《阿基拉》，里面的主角都有着明显的性格缺陷，活得很痛苦。当然，这些作品算不上是题材开创者，但曾经有很长一段时间，动漫界都在调侃一个设定：让一个十几岁的少年背负起拯救世界的重任。所以当时出现了一批作品，通过刻画主角在剧情中遭遇严重的精神危机，来批判这种不合理的设定。我并不是说现在的新趋势就一定更好，但看到这些充满正能量的主角，一心一意想帮助身边的人，真的会觉得很有意思。所以，如果你现在创业，并且对特定用户群体的痛点有着深刻的理解，那你就已经成功了一半；但如果你只是擅长搭建网站这类技术开发工作，却没有明确的目标用户，那创业之路可能会走得非常艰难。 Lenny：听你这么说，你是看好垂直领域AI创业公司的发展前景。没错，我完全同意这个观点。市场上确实存在两类产品：一类是能解决多种问题的通用型工具，另一类则是深耕某一细分领域的垂直产品——比如专注于优化演示文稿制作，比任何人都更懂演示文稿相关的痛点，并且能无缝融入用户的工作流程，针对性地解决这类特定需求。这个方向真的很有前景。说到Codex的研发进展，我猜想你们内部应该有很多评估指标（ZP注：Evals，指对模型性能进行的评估测试），同时也会参考各类公开基准测试（ZP注：Benchmarks，指用于对比模型性能的标准测试集）。你们是通过哪些指标来判断产品是否取得了显著进展的？我知道肯定不会只看单一指标，所以想了解一下你们重点关注的方向，以及正在努力推进的KPI有哪些？ Lenny：当你考虑Codex的进展时，我猜你们应该有很多评估和公共基准。你会关注哪些方面来告诉自己，“好，我们正在取得非常好的进展”？我想这不可能是一个单一的因素，但你们最关注的是什么？你们在推动什么？有什么关键绩效指标（KPI）？ Alexander Embiricos：我时常提醒自己，Codex这类工具，用户很容易发展成重度用户。这就意味着，我们很容易不自觉地把大量精力投入到开发那些深度功能上——也就是那些只有用户深度使用产品后才会用到的功能，最终可能会在这方面过度投入资源。因此，我认为关注7日留存率（ZP注：D7 retention，产品运营术语，指用户注册7天后仍会使用产品的比例）这类指标至关重要。我们还会以全新用户的身份重新体验产品，从注册开始一步步操作。为了能以最真实的方式进行内部试用，我用自己的谷歌邮箱注册了好几个ChatGPT Pro账号，这些账号每个月要花掉我差不多200美元，我得走报销流程才行。但在我看来，亲身体验普通用户的使用感受，同时密切关注早期留存数据，对我们来说依然是重中之重。毕竟，尽管这个赛道现在发展得如火如荼，但整体而言，Agent工具的用户普及度仍处于非常早期的阶段。另外，我们团队可能是这个领域里最热衷于收集用户反馈、关注社交媒体舆情的团队之一。我们有几位同事会时刻关注Reddit和Twitter上的相关讨论，平台上既有对产品的赞扬，也充斥着大量的吐槽和抱怨。而我们会高度重视这些负面反馈，认真研究和分析。因为Coding Agent的应用场景非常广泛，往往会在某些特定功能上暴露出问题。所以我们会经常监测社交媒体上的用户舆论倾向。特别是 Twitter的氛围会更偏向炒作，而Reddit上的评价虽然更尖锐，但也更真实客观。因此，我现在越来越关注Reddit上用户对Codex实际使用体验的讨论。 Lenny：这对大家来说非常重要，能告诉我你们常关注哪些subreddits吗？是不是有像r/Codex这样的板块？ Alexander Embiricos：嗯，算法其实很擅长推荐相关内容，但r/codex确实存在。 Lenny：这点对很多人来说都很有参考价值。你们最常关注哪些SubReddit？有没有专门讨论Codex的r/Codex版块？ Alexander Embiricos：平台的算法其实很智能，会主动推送相关内容。不过确实是有r/Codex这个子版块的。没错。Twitter的互动模式更偏向一对一交流，哪怕是公开推文也是如此；而Reddit有一套完善的投票机制，而且上面的用户大概率还是真人——虽然也不能完全确定没有机器人账号。所以从Reddit上，我们能更清晰地捕捉到哪些内容是用户真正关心的，以及大家对产品的真实看法。 Lenny：那我想简单聊聊Atlas浏览器。你们推出这款产品的时候，我还发过一条推文，说我试用了Atlas，但不太喜欢它那种纯AI驱动的搜索体验。有时候我就是想直接用谷歌搜索，而不是等着AI生成答案。而且当时的版本还没有切换搜索模式的选项，所以我就发推文说 “我还是换回原来的浏览器吧，这款体验不太好”。我感觉这条推文可能让OpenAI的一些产品经理有点难过。不过后来我看到有人发推文说，Atlas已经新增了相关功能。我猜想这个功能其实早就规划好了，这或许就是你们的产品迭代策略——先把产品推向市场，观察用户的实际使用情况，然后再针对性地优化调整。所以我想问两个问题：第一，这件事背后有没有什么值得分享的细节？第二，我很好奇，你们为什么要研发一款网页浏览器呢？ Alexander Embiricos：我之前参与过一段时间的Atlas项目，但现在已经不负责相关工作了。不过我可以从个人角度聊聊这个项目的初衷。我之前创办过一家做屏幕共享和结对编程（ZP注：Pair Programming，指两名程序员共用一台电脑协作开发的模式）的创业公司，后来我们团队加入了OpenAI。当时我们的核心想法是打造一款情境感知桌面助手（ZP注：Contextual Desktop Assistant，指能感知用户当前操作场景并提供针对性帮助的智能工具）。我之所以认为这个方向很重要，是因为我发现，用户要先向智能助手提供大量上下文信息，才能让它提供有效的帮助，这个过程其实非常繁琐。但如果智能助手能主动理解用户当下的操作意图，就能最大限度地提升用户的工作效率。其实在我看来，Codex本质上也算是一种情境感知助手，只不过它是从代码开发这个垂直领域切入的。至少就我个人的想法而言，很多工作都是在网页端完成的，如果我们能打造一款浏览器，就能以一种更原生、更优质的方式实现情境感知功能。我们不用再去适配其他桌面软件——这些软件对辅助功能树（ZP注：Accessibility Tree，指用于辅助技术解析网页内容的树形结构）的支持程度参差不齐；也不用依赖截图技术，毕竟截图不仅速度慢，而且可靠性不高。相反，我们可以直接深入浏览器的渲染引擎（ZP注：Rendering Engine，浏览器核心组件，负责解析和显示网页内容），提取我们需要的各类信息来为用户提供帮助。我还喜欢用电子游戏来打比方，不知道你有没有玩过《光环》（Halo）这类游戏？当你走到某个物体旁边时——很多游戏其实都是这样的，我都有点不好意思说，毕竟已经过去很久了——按下X键，游戏角色就会做出相应的正确操作。我以前买每一款电子游戏，都会认真阅读说明书。我还记得第一次在说明书上看到 “情境交互”（ZP注：Contextual Action，指根据玩家所处场景触发的对应操作）这个概念时，就觉得这是个非常酷的设计。而情境交互的核心在于，首先要理解用户当下的操作意图，掌握一定的上下文信息，然后才能提供恰到好处的帮助。我认为这一点至关重要，因为我们可以设想这样一个未来场景：Agent每天要为用户提供数千次帮助，如果它只能通过推送通知的方式告知用户 “我帮你完成了这件事，你觉得怎么样”，那用户每天就要收到上千条推送，这显然会让人不胜其烦。但换个角度想，回到软件工程的工作场景：假设我正在查看数据仪表盘，发现某个核心指标出现了下滑，这时AI可以主动介入分析，然后在我查看仪表盘的当下，直接给出它对指标下滑原因的判断，甚至提供对应的解决方案。这种方式不仅能让我保持工作的沉浸感，还能让Agent处理更多事务。所以在我看来，我们研发浏览器的部分原因就在于，通过浏览器，我们能更精准地捕捉用户的上下文信息，从而明确应该在哪些场景下提供帮助。同时，用户也能更好地掌控哪些内容愿意让我们的工具访问——比如，如果你希望Agent处理某项任务，就可以在这款AI浏览器中打开相关内容；如果不想，那就用其他浏览器。这样一来，用户的控制权和使用边界就非常清晰了。此外，我们还能在浏览器中设计人机混合主动交互（ZP注：Mixed Initiative，指人类和Agent共同主导交互流程的模式）的用户体验，让Agent在合适的时机主动提供情境化操作建议，而不是随意推送通知打扰用户。 Lenny：听你这么说，Codex的愿景是成为一款超级助手，它的作用不只是帮人写代码，而是像一个超能搭档一样，在工作中为你提供各种各样的帮助，让你在工作中表现得更加出色。我现在完全明白了。说到这里，Codex有没有什么非工程领域的常见应用场景呢？我们之前聊过设计师用它来制作原型和开发功能。除此之外，有没有什么非工程师群体使用Codex的有趣或者出人意料的方式呢？ Alexander Embiricos：其实这类用法有很多，都挺出人意料的。不过目前来看，真正能让用户产生高粘性的场景，大多还是和编程相关，或者是偏技术导向的领域——这些领域往往已经形成了成熟的生态系统，比如数据分析这类工作。我个人预计，未来这类跨领域的应用场景会越来越多，但就现阶段而言，我们团队的精力还是高度集中在编程相关的功能上，毕竟这个方向还有大量的工作要做。 Lenny：对于那些想尝试使用Codex的人来说，它是否适用于所有类型的代码库？它支持哪些编程语言？比如如果是做SAP相关的开发，能不能接入Codex来开展工作？它的优势应用场景是什么？又有哪些场景目前的表现还不够理想？ Alexander Embiricos：你问的这个问题其实非常关键。尝试使用Codex的最佳方式，就是把你最棘手的任务交给它，这一点和其他一些Coding Agent不太一样。有些工具可能会建议你从简单的任务入手，或者随意写点代码来判断自己是否喜欢这款工具。但我们打造Codex的定位，是让它成为一款专业级工具，你可以放心地把最难解决的问题交给它，让它在庞大的代码库中生成高质量的代码。当然，它现在的表现还谈不上尽善尽美。所以，如果你打算尝试Codex，最好用一个真实的工作任务来测试它，不必特意把任务简化成无关紧要的小事。比如，你遇到了一个很难排查的bug，不知道问题出在哪里，就可以让Codex帮忙分析原因，或者直接编写修复代码。 Lenny：这个回答我太喜欢了，直接把最难的问题交给它就行。 Alexander Embiricos：不过我得补充一句，如果你说 “我现在最难的问题是要打造一个能估值超10亿美元的独角兽企业”，那显然Codex目前还做不到，至少现在还不行。所以我的建议是，交给它的任务得是那种最难，但本质上还是一个独立的问题或单一任务的工作。刚开始试用的时候可以这样操作，之后再慢慢摸索，学着用它来处理更大型的项目。 Lenny：好的。那它支持哪些编程语言呢？ Alexander Embiricos：我们训练Codex的方式，决定了它支持的编程语言分布，和这些语言在现实世界中的使用频率是基本一致的。所以除非你用的是那种非常冷门的编程语言，或者是某些企业内部的私有编程语言，否则Codex在你使用的语言上应该都能有不错的表现。 Lenny：如果是新手刚开始使用Codex，你有没有什么小技巧可以分享，帮助他们更好地使用这款工具？比如，要是你能悄悄给第一次配置Codex的用户一个建议，让他们获得良好的使用体验，你会说些什么？ Alexander Embiricos：我可能会建议他们并行尝试几件事。比如，既可以把一个难题交给它，也可以让它帮忙理解某个代码库的结构，还可以和它一起围绕某个想法制定开发计划，然后循序渐进地深入使用。这里面的核心思路是，你其实是在和一个新的团队伙伴建立信任。你不会刚认识一个同事，就毫无铺垫地丢给他一个任务。你应该先让他熟悉代码库，然后和他对齐工作思路，再让他一步步推进工作。如果你用这种方式来使用Codex，就会自然而然地摸索出和它交互的不同Prompt技巧。因为它确实是一款功能极其强大的Agent和模型，但给Codex写Prompt的方式，和给其他模型写Prompt还是有点不一样的。 Lenny：我还有几个问题想问。第一个问题，随着AI在代码编写方面的参与度越来越高，一个老生常谈的问题也随之而来：我们还应该学习编程吗？为什么要花时间做这件事？对于那些正在规划职业方向的人，尤其是有志于从事软件