人们很喜欢 Codeex 的细致与勤勉。它不是市面上最快的工具，但在处理困难复杂的任务时，它最为细致，也最为出色。
Claire Vo：如果你是一名软件工程师，或者甚至是刚接触这些 AI 工具的新手，你会从哪里开始使用 Codeex？
Alex：我们正在把它打造成一个全能的软件工程队友。Codex 非常擅长的一件事就是回答问题。如果你在对话中让 Codex 生成方案，然后想要修改某些内容，最好的做法是在同一个对话里直接要求修改方案，这样当它准备开始执行时，脑子里已经有了所有这些上下文。这是一个很好的入门流程，展示了这个平台有多灵活，以及它如何能满足不同水平用户的各种任务需求。
Claire Vo：OpenAI 是如何把它用于更大型的功能和产品的？
Alex：我们用 Codex 在 28 天内为 Android 开发了一款 sore app（音乐），它一上线就成了应用商店的第一名。（音乐）
Claire Vo：欢迎回到 How I AI。我是 Claire Vo，一名产品负责人，也是痴迷于 AI 的人，致力于帮助你利用这些新工具更好地构建产品。今天我们有请 Open AI 的 Codeex 产品负责人 Alexander Emiros，他会向我们展示如何最大限度发挥 Codeex 的潜力。无论你是不懂技术的用户，想要修改现有代码库，还是想掌握在终端中使用它的高级技巧和窍门。让我们开始吧。
Claire Vo：本期节目由 Brex 赞助。（音乐）如果你正在听这档节目，你已经知道 AI 正在以非常实际的方式改变我们的工作方式。（音乐）Brex 正将同样的力量带入金融领域。Brex 是（音乐）为创始人打造的智能金融平台。有 autonomous agent 在后台运行，你的 finance stack 基本可以实现自我管理。卡片自动发放，费用自动归档，欺诈行为被实时阻止，无需你费心。
Claire Vo：加上 Brex 的银行解决方案，配上高收益 treasury account，你就拥有了一个能帮你更聪明地花钱、更快地行动、更自信地扩张的系统。美国三分之一的初创企业（音乐）已经在使用 Brex。你也可以，访问 bre.com/howi AI。
Claire Vo：Alex，感谢你参加 How I AI。我对今天的节目很兴奋，因为我们还没有看到过对 codeex 的深入解析，而我们将从专家那里了解如何最大限度利用这个工具。我也很喜欢我们要直接深入，从零到一完成一个 Codeex 的 hello world。那么，如果你是一名软件工程师，或者甚至是刚接触这些 AI 工具的新手，你会建议从哪里开始使用 Codex？
Alex：Codex 是一个 coding agent。我们正在把它打造成一个全能的软件工程队友。不过要说入门，我们先聊聊大多数人使用它的地方，也就是在他们的 IDE 里。呃，我正好用 VS Code。所以我会向你展示在 VS Code 中使用 Codex。你也可以在任何 VS Code 的分支版本中使用这个 Codex 扩展，比如 Cursor 等等。假设我刚从 VS Code 扩展市场安装了 Codex。顺便，需要我演示一下吗？
Claire Vo：好啊，来吧。我们就真正地从零开始。好的，没问题。从零到一。我是说，我不会真的卸载然后重新登录，但我们可以假装我这么做了。好，我喜欢这样。
Alex：就当是我点了安装，然后点了进去。好的，接下来我会在这里看到这个图标，呃，就是 Codex 扩展。我需要点击几个步骤并完成登录。另外，如果你还不知道，Codex 包含在你的 charge PT 套餐里。所以你需要一个付费套餐。如果你有 Plus、Pro、Business、Team 或 EDU 套餐，就可以使用 Codex。嗯，而且额度非常慷慨。好的，假设我已经装好这东西，真正从零开始了。假设我刚听说这是个游戏，但我根本不知道该怎么玩。呃，Codex 非常擅长的一件事就是回答问题。我是 Codex 的产品负责人。所以我其实经常用 Codex 来提问，可能比大多数工程师用得还多，因为我不想用傻问题去烦工程师。所以我可能会问：这个游戏怎么玩？我们今天刚发布了一个新模型。所以我挺好奇它用的是什么模型。5.2。酷。我猜我们待会会聊到。那我就在这里运行 npm rundev，按它说的启动服务器，然后看看这个游戏。好的，我这里是一个简单的 commander type 游戏。我可以移动角色。嗯，我可以招募部队。看起来种植风车这个功能还没实现。而且我听说跳跃功能有点问题。好的，这跳得太高了。我们来动手修复这些问题吧。那我在这里可以直接去问，比如说跳跃幅度太大了。呃，请调低一点。所以呃，对于那些刚接触 coding agent 的人来说，这其实非常基础。我只是用纯自然语言、纯英文写下了我想要的改动。然后我们可以看到 codeex 开始工作，构思一个方案。好的，我得先搞清楚跳跃是怎么实现的。然后我需要降低它，接着还要确保整件事能跑通。那我们就这样做。呃，既然我们都在做了，不如再多改一些东西。要不我们实现一下种植风车？嗯，我就在聊天里同时做这些，这样它们可以并行跑。
Claire Vo：好，我想为那些只听的或者没在看画面的听众强调一些东西。基本上你展示的是从现有代码库入手的过程，假设你是一个半技术背景的用户。你就像这个项目的项目经理，你会觉得，呃，他们交付了东西，但又不是你完全想要的样子。你用 Codex 做的事，一是：我怎么才能在本地运行这东西？我觉得这类基础用例很容易被忘记，因为我知道很多软件工程师听这个播客，但人们忘了，不是每个人都知道怎么在本地跑每一个 repo。所以，你可以做的一件小事就是问：我怎么让这个代码库跑起来，这样我就能测试它？二是，你设置了小的并行任务，我觉得这很好。我挺好奇的，你在任何一个代码库里，一般会同时做多少个这样的小修复？所以我想问的是，在这个例子里这些并行任务都很小。你觉得更好的方法是设置并行任务，让它们各自单独运行，还是按串行方式一个一个做？为什么选择这一种而不是另一种？
Alex：这完全取决于情况。这有点像是个玩具项目，但现实中，如果我是在四处处理事情，我通常的工作方式是这样的。呃，这对产品经理来说可能非常实用。比如我现在看着终端，经常有想知道的问题。其实就在今天早上，我想：好吧，我要做个 demo。我知道我们刚上线了一个让选模型更容易的新功能。我能关掉它吗？于是我就运行了 codeex，它把我带进去了。呃，这只是一些我运行 codeex 的内部自动更新逻辑，然后我问：嘿，呃，我们有个新功能。顺便说一下，我不介意告诉你们，因为是 open source，所以很多新东西都是公开的。我们有个新功能，提供 um balanced reasoning settings。我实际上打算把它用引号括起来，好给模型一个线索，让它知道我想搜索这个字符串。呃，"reasoning settings"。我怎么在 demo 里关掉它？所以，你知道，我可能会非常频繁地做这种事，或者我会问："嘿，我听说有客户报告了这个行为。做了吗？" 或者我会问："嘿，呃，我们上线这个功能了吗？我我搞不清我们到底发没发这个东西。"
这类问题我经常遇到。如果是这种情况，把它们并行运行就很好，完全没必要做别的。但另一方面，如果我在做修改，那我更可能会去想：这个改动和另一个改动发生冲突的概率有多大？通常我要么一次只做一件事，要么会用到一个叫 work tree 的东西，这应该算是一个比较进阶的概念。如果你感兴趣我们可以展开讲讲。我会使用一个 work tree，然后让 Codex 在单独的 work tree 上完成它的工作。不，我们花点时间看看 work tree 吧，因为我觉得这是大多数刚接触这些工具的人用得不太好的功能。我看到你展示的两种路径：一种是开一个大分支，把这些事串行做完再提交进去；另一种是同时启动一堆不同任务，但它们都在同一个冲突空间里运行，导致问题。所以也许我们可以花点时间聊聊 work tree，以及它在 Codex 里是怎么用的，或者你怎么配置和使用它来确保你能并行运行改动，同时它们不会互相冲突，而且可以分开审查。基本上，如果我们要让 Codex 做修改——我可以临时想个例子。比如说，我们想把这个输入的语言改成法语或德语。显然这两者不可能同时为真。这是个非常刻意造出来的例子，对吧？但也许我想两个都试试。也许我在做原型设计。嗯。那我需要的是两份不同的代码库副本。所以我可以干脆把代码库复制两份，对吧？就像在 Finder 里 Command+C、Command+V，或者把仓库 git clone 两次。但 Git 提供了一个非常好用的功能，叫 work tree，它基本上能让一个 Git 实例同时跟踪多份代码库副本。呃，你知道，作为典型的哺乳动物，我很懒，所以我不想记 work tree 的命令，尽管它们很简单。因此我通常的做法是直接让 Codex 来创建 work tree。我可能会这样说：Codex——我也可以像刚才那样启动 Codex 再输入提示词。但 Codex 里有个挺好用的快捷方式，你可以直接把提示词放进去。所以我可能会说：Codex，在这里，基于 main 分支创建两个新的 work tree。如果我真的在操作，可能不会说得这么具体。main 分支，一个叫 French，一个叫 German。然后你可以看到这里发生的是，Codex 直接启动并进入了这个提示词。我经常这么做。事实上，我已经用顺手到有时候都会忘记写 Codex --，我 literally 就会直接像这样：呃，我在终端里，我说，在这里，做这个。对，我刚才在看这个，因为我们现在在一个非常 meta 的仓库里，就是你所在的文件夹叫 codecs，在里面运行着 codecs，和 Codex 对话。就像人们说的，codecs 一路套到底。不过，我觉得有一点需要特别提醒那些没在看 YouTube、可能在听音频的人：当你在 CLI 里新开一个 Codex 实例时，你可以直接输入两个横线，把你的第一条提示词和命令写在一行里。这就是典型的开发者效率思维：总不能让我先按回车，等着，然后再打字吧。没错。嗯，我很喜欢这个做法。好，所以你在这里用 Codex 做了我们所有人都用 Codex 做的事——就是不用去记 Git CLI 命令——然后你基于 main 创建了两个新的 Git work tree。那我推测，当你在 Codex 里工作时，你的意思就像是：在 French 那个 work tree 里做 ABC，在 German 那个里做 XYZ。对。那我们实际展示一下在这些 work tree 里工作吧。你看，我现在有两个文件夹了。一个叫 French，一个叫 German。那我可能会先 cd 进 French，然后运行 Codex。呃，进去之后我就说：把输入框的占位字符串翻译成法语。再说一次，这是个非常刻意的例子。对。那现在我可以新开一个标签页。然后我会 cd 进 German 那个目录，再运行 Codex。我会用我那个好用的快捷方式，直接给它下命令：把输入框占位字符串翻译成德语。所以现在 Codex 可以同时处理这两个改动了。你看 French 那边在跑，它在琢磨该在哪里改；German 这边也在跑。这太棒了。你知道，很多人在社交媒体上会说：我在终端里跑了 15 个 Codex 实例。他们展示一堆标签页，但实际上并没有分享他们是如何在代码层面做到关注点分离的。我很开心我们在展示 AI 工具，但我觉得这些编码工具也让很多人在没有掌握 Git 等基础知识的情况下就进入了软件工程领域。所以，除了学习这些 AI 工具之外，如果我能给任何人提个建议，那就是先学好 Git 的基础，这样当你驾驭这些强大工具的时候，你会处在一个安全的位置，我觉得这真的很重要。好。所以我们已经展示了，启动 Codex 基本上有两种方式，这点我也想强调一下。第一，通过 IDE 里的扩展插件；第二，如果你就想直接进终端操作，那也很好。你可以让它做解释性的任务——我自己写的代码也会经常用它来看 ，比如：我当时在这儿写了什么？给我讲讲这玩意儿是怎么运作的。也可以做一些离散的任务，然后你可以把这些任务并行化，特别是通过使用
work tree。所以我觉得这是一个很好的基础，讲了你该如何使用一些基本功能，但 OpenAI 是怎么把它用在更大的功能和产品上的呢？没错。其实我们刚发了一篇博客讲这个，我觉得大家可能很感兴趣：我们怎么用 Codex 在 28 天内为 Android 构建了 Sora 应用，而且一上线就成了应用商店的第一名。四个工程师，28 天，应用商店第一名，而且这不是个简单的应用。我看着这个团队推进的速度，印象非常深刻。这篇文章里有很多非常实用的建议，告诉你该怎么做到。我觉得，这篇文章其实是写给专业软件工程师的，他们要做大型生产级应用，在复杂的代码库里工作。一个很酷的、可以总结出的核心观点是：有了 coding agents，事情并不会变得更简单，但你的速度会快很多。这里的意思是，我们不是让四个工程师在 28 天里纯靠 vibe code 把应用做出来——他们并没有进去就说：嘿 Codex，给我做个 Sora Android 应用，然后就成了。其实稍微纠正一下，他们确实试过这么做，但没成功 ，不可能一个提示词就把整个 Sora Android 应用搭出来。相反，他们非常认真地思考了应用应该采用什么样的架构。他们用了一种叫 planning 的技术，我觉得这是一个超级实用的方法。让我看看，我要在这里打开 Codex 的代码库，这个代码库稍微大一点。为了做这个，我可能会在这里启动一个任务。哦，对了，抱歉。实际上有件事我想分享一下：当你第一次安装 Codex 扩展时，它会出现在左侧，我强烈建议把它拖到这里。这只是一个更适合它待的位置。好了。实用资讯。是的，在 VS Code 里，这款简单的 IDE 有点像 Cursor。它很难找到。所以我让你自己去探索它在哪里，因为我觉得它甚至会变动。不过我可能会说，嘿，我们想做一个不那么简单的改动。比如，我们有一个 TypeScript SDK，也许想写一个 Python SDK。对吧？所以，我不一定想让 Codex 在这个任务上一次性完成。虽然我可以这么做，也许也能行。嗯，所以我可能会这样说：制定一个计划，基于我们的 TypeScript SDK 构建一个 Python SDK。这是一个合理的提示词。我可以直接发这个。这也行。但实际上，OpenAI 的一些高级用户对于计划的运作方式已经形成了相当明确的偏好，而且我们也确实发布了一篇关于高效规划的博客文章。Aaron 发了一篇关于使用 plans.mmd 的博客文章，这个技巧用起来非常简单。基本上，你要做的就是去这篇博客文章，然后复制这段描述。这有点像元计划。就像说，嘿，当你做规划时，一份好的计划应该是这样的。是的。比如说，一份好的计划是自包含的。好的计划要有里程碑，而且 agent 应该在执行过程中不断更新计划。所以我就这么做了，我把它复制到了一个 markdown 文件 plans.mmd 里。你看，我刚从网站上复制粘贴过来。那么，在这里我实际可能会做的是，我可能会说：使用 plans.mmd 制定一个计划。是的。对。然后我可能会直接发送这个提示词。嗯，这会花一些时间，因为如果你看一下 plans.mmd 的规范，它非常详尽。而这其实是 Codex 非常擅长的事情。人们很喜欢 Codex 有多详尽、多认真。它不是最快的工具，但它是最详尽的，也最擅长处理困难复杂的任务。所以我其实，是的，我可以说，比如说，把它放到 temp.md 里。我让它放进一个随机文件里。嗯，主要是因为我提前做过这个。那么，这就是它生成的计划。你可以看到它大约有 120 行，我们可以一起通读。我们看到它列出的这些待办事项。嗯，我们看到它识别出了 TypeScript 的命名规范。这是一段很棒的 Codex 对话，等等。实际上我们对 SDK 参数的命名非常讲究。所以对我来说，阅读并核实这些内容非常重要，确保它没有搞错。嗯，它在这里做了各种各样的决定，我可能会满意。好的，很好。那么现在我可以做的是，我可以开启聊天并说：如果我满意的话，就按 SDK plan MD 里的计划执行。是的。嗯，然后它就会开始执行，这可能是一个大约 30 分钟到 1 小时的任务，但我对这项任务的结果会相当有信心。嗯，他们构建那个 Android 应用时也是这么做的。一个非常具体的建议是：如果你有一个 Codex 正在生成这些计划的对话，而你想修改某些内容，那么最好就在同一个对话里请求修改计划，这样当模型准备开始执行时，它脑子里已经有了所有这些上下文。首先，我喜欢你用了“脑子里”这个说法。所以，我们是在说模型有它自己的大脑。是的。我是说，我们经常看到这种情况。这种先制定计划的做法。显然，我喜欢规范文档，喜欢纯粹性，喜欢技术设计文档。我很好奇，如果我们以 Sora 应用为例。我猜你们有一个“计划的计划”，本质上就是你看遍整个应用的架构，然后做我们在软件工程中一贯做的事：把你想要做的完整东西写成规范，拆分成可以执行的组件或模块，然后我认为你所说的速度来源在于，任何一位工程师都可以与 Codex 合作完成一份详细的技术规范和计划，然后让 Codex 快速执行该计划的 V1 版本以供评审。所以你并不会绕过架构层面的思考，比如这个应用应该如何搭建、我们希望它具备哪些能力等等。虽然你可以把 AI 当作头脑风暴的伙伴。但一旦你把工作拆成了大小合适的模块——而且它们可以相当有分量。我是说，构建一整个 TypeScript SDK 可不是什么小项目，不像给某个东西添加一个方法。嗯，然后你就可以用这种规划策略，把你要做的事情全部梳理清楚，再让 Codex 去执行。是的，我觉得这大概和我想的差不多。所以，说实话，我现在挺喜欢 vibe coding 和 vibe engineering 这两个词的。我的感觉是，现在作为开发者或产品经理，你在如何分配时间上拥有很大的自主权。我认为，当你要做类似 Sora 这样的事——比如构建一个像 Sora 应用这样的生产级应用，而且你知道它必须能扩展——这一点非常重要：也许你已经有很多像 Codex 这样的高级工程师，但你还是想要一位架构师，对吧？或者让 staff engineer 来思考应用的整体形态。嗯，所以我认为这至关重要。与此同时，你知道，你得花很多心思在应用的整体形态上，而且在代码审查方面要非常谨慎。实际上我们可以聊聊 OpenAI 是如何加速审查流程的，因为现在我们能写这么多代码，瓶颈已经变成了思考该写什么代码，然后确保代码质量过关、审查通过并合入代码库。不过与此同时，Codex 在那些你只是想要学习、并不需要可扩展的生产级应用的场景下也能非常强大。比如，我们大量用 Codex 做原型设计。Codex 团队的设计师们实际上有一个完全——或者说大部分——由 vibe coding 完成的完整原型，涵盖了所有 Codex 的界面，他们可以直接用代码进行设计，然后我们用它来试玩，看看我们是否喜欢这些设计，如果喜欢，我们通常会用 vibe coding 的方式在实际产品中切一个分支来实现。所以很多设计都是在那里由设计师尝试的，然后有时候 vibe coding 的原型几乎完全——或者说非常接近——就是我们想要的样子，于是他们就会在工程师的帮助下，甚至自己动手，直接把它合入代码库。而有时候我们会说，好吧，这个方向不错，或者说我们学到了一些东西，我们对 vibe coding 的原型做了迭代，现在我们知道想要构建什么了，然后我们就可以把那份非常明确的规范交给一位工程师，他可能会重新思考一些基本假设，因此最终不得不使用 Codex 从头重建很多东西。所以我觉得加速分为两种：一种是在学习上的巨大加速，另一种是在执行上的巨大加速。执行。本期节目由 Graphite 赞助呈现，Graphite 是一款 AI 驱动的代码审查平台，帮助工程团队更快交付更高质量的软件。随着开发者采用 AI 工具，代码生成正在加速。但代码审查还没有跟上。PR 变得越来越大、越来越嘈杂，团队花在审查上被阻塞的时间比写代码还多。Graphite 解决了这个问题。Graphite 将代码审查所需的一切整合到一个精简的工作流中。
Stacked diffs、更简洁直观的 PR 页面、AI 驱动的代码审查、 以及自动化的合并队列。所有这些都旨在帮助你更快地完成审查周期。成千上万的开发者依赖 Graphite 来加速审查流程，从而让你 能够专注于构建，而非等待。访问 graphite dev.link/howi aai 开始使用。网址是 graphite dev.link/howi。所以我得问一个问题，然后我们再进入代码审查环节。就是，你知道，有点像那种“你懂的”时刻——但你怎么判断什么事情需要制定方案，什么事情不需要呢？在某种程度上，这更多取决于我，而不是任务本身。显然，任务越难，你越可能想要一份 spec。但我也觉得，这在一定程度上取决于你当时的状态。比如，如果我只是想快速搞定某件事，我可能没时间等一个方案出来，然后再来来回回沟通。所以我可能会直接把 Codex 扔上去做，而且我可能会并行跑四次。这其实是我们在 Codex 上做的一件事。你也可以在云端、在网页上使用 Codex，它会在自己的电脑上运行，里面有个叫 best event 的功能，它会直接把同一个任务做四次。所以你完全可以先让 Codex 去探索，而不是先探索着做个方案，然后再协作。你就让它尝试四种不同的做法，看哪种效果最好。而且你知道吗，我在本地用 work trees 也会这么干。所以我想，对你这个问题更好的回答是：任务越难，你越需要规划；但比较懒的回答是：这也取决于我有没有时间等一个方案。我喜欢这个说法。我发现自己做着一件挺搞笑的事：随着这些运行时间更长的编程模型问世——52 就是其中之一——我等待的时间变多了。我不得不，就是，想办法填满我的时间。我以前做过那种光鲜的高管工作，日程完全是管理者式的；过去两年我过的是 builder 的生活；而现在我感觉，该死，我又回到管理者日程了。我把任务发出去，然后某个“别人”会把它做完，接着我就得找点别的事来打发时间，而且我拒绝再往日程表里加更多会议。所以，我同意你的看法。我有时间和耐心等一个方案吗？我的意思是，Codex 团队里有很多工程师基本上会并行推进两件正在做的事，不会超过两件，通常就是两件。对。嗯，所以他们会一边思考该做什么，另一边……顺便说一句，这可能只是打开了两个不同的 work tree 和两个不同的 IDE 实例。可能就是类似这样的情况。而且，他们可能一边在一个项目里思考和 Codex 协作，同时让 Codex 在另一个项目里干活。同时兼顾两件事对普通人来说似乎还能应付。但兼顾超过两件对普通人来说就挺难了。不过从产品方向的角度来看，我认为我们并不真的希望让用户去兼顾多件事。这对很多人来说并不好玩。当然，有些人喜欢在代码里玩 Starcraft，但我们正在训练……
插一句，我爱 Starcraft，所以我觉得我现在很擅长做这些事 。是的，是的，是的。嗯，我觉得这其实是个挺恰当的比喻，但这不是我想出来的，我忘了是谁说的。嗯，但总之，我们想做的就是让 Codex 越来越快。对。而且我们也在努力构建这样的体验：你不必干等着。随着模型越来越智能，它们能处理越来越难的任务。比如今天早上，Every 的 Naveen 分享了一个 demo，有一个 bug 之前的模型都修不了，然后昨天 5.2 2 发布了，他就用 5.2 2 去跑，模型思考了 37 分钟，然后说“这就是 bug”，而事实也确实如此，bug 被修好了。所以随着模型越来越智能，会有更多时候你需要等待。但我认为，作为围绕模型做产品的人，我们的职责就是让即使模型在思考的时候，你也不用干等着它思考。对，或者至少让你知道自己在等待，并且对此感到安心。我觉得这是我在使用某些模型时遇到的挑战之一——当思考时间很长时，我发现自己……天啊，就像以前和人类软件工程师合作时那样——我会忍不住问：“怎么样了？还在做吗？还顺利吗？”所以我认为这是一个非常有趣的产品问题，因为这些模型确实存在有用的延迟，但作为产品和设计师，如何把这段延迟、推理过程和进度展示出来，让人们不会感到焦虑，这对你和你们团队，以及所有做这类工具的人来说，仍然是一个挑战。你知道，这对理解 Codex 的基础非常有帮助。我很想听听，有哪些与其他系统或工具的集成，能够真正放大你从 Codex 中获得的价值。我觉得目前为止最大的集成肯定是 GitHub 和 code review。嗯，也还有其他一些。既然说到这儿，这是关于 5.2 模型的一张很酷的图表。嗯，我们稍微岔开一下话题，我给你们看看，因为我觉得这太酷了。基本上，这张图展示的是：当你让 5.2 想多久就想多久时，它在 Sweetbench Pro——这是一个软件工程任务的 eval——上表现得极其智能。但 x 轴很有意思。它展示的是模型完成这些任务所消耗的 output tokens 数量。所以这有点像模型到底需要思考多久？当我们说“嘿，你可以大致上想多久就想多久”时，它真的非常聪明。但另一个很酷的点是，我们可以告诉它：“嘿，其实我们不需要你想得那么用力，或者我们想让你回答得快一点。”于是它的表现甚至更好，结果比这边这个之前的模型——51 thinking——更高，但用时明显更少。所以这其实就是我们想要构建的东西，回到我们刚才说的等待问题，对吧？我们想让你更快地得到同样的结果，然后在给模型更多时间的情况下，得到更智能的结果。对。在合适的时间内得到正确的结果。对吧。是的。没错。所以，Codex 可以做的一件事是让它做 code review。这其实非常容易，甚至不需要集成 GitHub。我们就可以直接在这里操作。假设它写了一些代码。嗯，那边发生了什么我先不管。我就假装我想审查这段代码。那么我可以输入 /review u，基本上就是让它开始审查这段代码。这是人们非常喜欢的一个功能。你知道吗，现在的感觉就像是，当你把模型放到一种特定的心智模式里，比如“嘿，你现在是一个审查者”，并且给它一个与写代码的模型不同的对话上下文时，你得到的批评意见甚至比人类工程师的还要好。部分原因在于，这个模型有大把时间去通读所有代码，甚至可能执行代码来验证这些改动。这确实是非常实用的一点，我推荐大家这么做：Codeex 上的许多工程师会让 Codex 完成工作，然后多次要求它审查代码、评判代码，或者只是让代码更优雅，这会极大地加速开发。假设你觉得这不错，而且你的团队有做代码审查的习惯，那么你实际上可以去 GitHub 里开启自动代码审查。当这个 PR 被推送时，Codex 会自动地——不需要任何人去提示它，也不需要任何人开着电脑运行，它就在云端——去查看代码并发现了一个问题。这类发现的命中率非常高。我们构建这个功能时，特意让它只指出那些它非常有把握的问题，因为这里的原则就是：人的注意力太稀缺了，我们很想保护它。但当它发现一个真的很重要的问题时，它会发布在这里，而这时候你就会稍微感受到一点 AGI 的意味。它发现了这个问题，然后 Ham 基本回复说：“嘿 Codex，你能修一下吗？”然后 Codex 就去修复了，对吧？于是我们就可以进入这样的循环。所以这是我首推的集成方案。第二个可能是 Slack 和 Linear。嗯，我很喜欢这个流程，而且我觉得再次强调优化——我现在其实正在跑一个 52 个分支的审查。我不是在 codeex 里跑的，但我会对比这两种体验。不过我做的很像是在和 base 做比较。告诉我我们做了什么，我们在这里做了什么。如果有什么我需要留意的，我确实喜欢在 GitHub 代码审查里做这些。我确实觉得，在减少噪音这方面，我找到了最高质量的产出。所以你们把重点放在置信度上、放在哪些 bug 真正重要上，再加上这种“你能修一下吗”的循环，这真的很棒。那么，你们基本上在所有仓库上都跑了这个吗？这已经成为代码审查的常规方式了吗？是的，我的意思是，Codex 在 OpenAI 内部已经无处不在了，看到这种情况真的很酷。你知道，每当我听到某个工具被到处使用的说法时，我总是有点怀疑。这些人有偏见。所以我可以告诉观众的是，今年夏天早些时候，codeex 大约被公司里一半的人使用，这……我不知道，一半这个数字挺低的，对吧。嗯，我们现在已经到了基本上所有技术人员、几乎所有技术人员都在持续使用 codecs 的阶段。这很有趣，因为既然每个人都在用 Codex，我们甚至没有一个对照点。很难去比较用 Codex 的人和不用的人。但曾经有一段时间，我们看到使用 codeex 的人如果看 PR 数量的话，生产力大约提高了 70%。显然 PR 数量不是最好的衡量指标，但这是一个可以观察的指标。嗯，现在这个指标已经没有意义了，因为所有人都用 codeex。Codex 代码审查本身在公司几乎每个仓库上都启用了，而且几乎审查所有 PR。嗯，你知道，这是我们发布时有点紧张的功能之一，担心大家的感受，但它一推出就大受欢迎，人们真的很喜欢它。呃，你知道，也许这有点跑题，但作为产品人之间的对话，我们一直在想的是：如果我们的使命是把 AGI 的好处带给全人类，我认为最大的限制因素之一就是人们到底想不想输入 prompt？ 你知道，我不喜欢打字。所以，呃，我太懒了，不愿意做这些。因此，我们一直在思考：好吧，有哪些事情我们可以为团队做，而且不需要任何人做任何工作就能有用？所以我们试了几样东西。Code Rio，就像我刚才给你展示的，是我们尝试的其中之一。大受欢迎。嗯，我们还试了一些其他很有趣的东西，比如我们构建了一个功能，当你收到来自他人的代码审查反馈时，它会自动尝试修改 PR。呃，你知道，也许我有兴趣再试一次。但有趣的是，那个功能并不是特别受欢迎。命中率经常是……PR 反馈嘛，有时候是些小毛病，但经常是比较深入的内容。你需要很多人类上下文才能理解那些 PR 反馈。所以 Codex 没能很好地完成。而且命中率也不够高，不值得你每次 GitHub 上有事件发生时都收到一封邮件。而代码审查呢，你知道，我们对它的触发频率非常谨慎，而且我们确保了，比如这次 codeex 没发现任何问题，它甚至不会通知你。它只是发一个点赞表情，你知道，就这样完成了。是的。我的意思是，我也有过这种经历，这挺有意思的。我也用过自动代码审查，也尝试过那种完全闭环的流程，而且我也不太满意，不只是对 bug 修复不满意。有时候修得还行，有时候不行。但我经常觉得，让一个人类在回路中说一句“我很确定这没问题，原因是 XYZ”，或者“别忘了我们这么做是因为 ABC”，有时候还是会丢失一点上下文。但从产品角度看，我觉得另一个有意思的地方是，在这些主动式与被动式的 agentic 体验之间，如果你有一个完整的 agent 闭环，人类对质量的门槛会变得极高。因此不满意度与挫败感会很快冒出来。如果你的代码审查机器人说这里坏了，你去修好，然后再审一遍，它挑你小毛病，你会觉得“好吧，我没完全按你想要的做”。但如果你的体验是，代码审查机器人提出问题，自己修复，然后又挑自己的毛病，那就真的很烦人了。完全同意。所以这也是一个小小的 agentic 产品设计挑战，我认为我们现在即将面临，大家需要注意：那就是如何为延迟做设计？如何在有人类参与和没有人类参与的情况下，为感知质量和标准做设计？然后我想对你说的最后一点是，我的意思是，如果我们人类的手指不再有价值、不再被使用，那我们要扮演什么角色呢——保护打字员吗？ 不过，呃，我明白你的意思，就是现在在我的产品开发和软件开发流程中，几乎所有的摩擦点其实都在于写下第一个 prompt，坐下来，然后直接开始说“咱们现在就来做吧”，这和过去的做法相比真是一个有趣的转变。是的。我的意思是，这确实值得思考，对吧，你知道，显然我们的使命就是大幅加速每一位开发者，而且广义上说，加速任何在做那些可以由使用电脑的 agent 提供帮助的事情的人。所以没错，我们的角色是什么这个问题很有意思。我喜欢开玩笑说，限制因素是打字速度。我觉得这有一半是真的。比如像“请审查这段代码”这类事情，限制因素就是打字速度。agent 可以在很多微小的环节帮到你。嗯，但我觉得另一半其实是思考，对吧？就像现在，我们可以随处获得代码，而且基本上可以轻而易举地做出原型。我认为困难的部分变成了决定什么才真正应该被纳入产品、思考一个产品应该做什么、真正了解客户，然后你知道，如果你在构建一个复杂系统，就要非常深思熟虑地考虑那个系统的架构，并且要去精心编排 agent 的工作。所以，是的，我和那些因为看到人们使用自己构建的东西而获得动力的开发者聊过，我觉得这些开发者越来越兴奋，对吧？然后我也和一些只是喜欢写代码这种感觉的开发者聊过。我不知道。我自己从这两者中都能获得快乐。我认为这正是我们不断思考的地方：好吧，我们怎么让这一切尽可能有趣？对吧？比如配置依赖有点烦人，但你的 agent 又必须这么做。那我们怎么让它变得简单？审查也有点烦人。那我们怎么让它变得简单？太棒了。那么，先回顾一下，因为到目前为止我们已经讲了很多内容，在进入快问快答之前。我们演示了将 Codex 作为扩展安装、设置任务、设置工作树、使用 plan，特别是参考 OpenAI 博客上那篇关于如何规划（how to plan）的文章来生成更复杂实现的计划，尤其是当你需要长时间运行的任务时。还有围绕代码审查和 bug 修复的自动化。我们没有特别提到、但我认为非常重要的一点是，你基本上可以在任何地方使用 Codex。所以我们在 VS Code: 里演示过，在终端里演示过，你可以在网页上使用，可以在 Slack 里使用，可以在 Linear 里使用，也可以在 GitHub 里触发。我很喜欢这种"随时随地用 Codex"的理念，这真的很棒。所以再说一次，如果你被 VS Code: 吓到了，或者不懂 VS Code:，没关系，从网页端开始。如果你喜欢命令行工具，那也很好。我们来用几个刚才演示的快捷键。所以我认为这是一个很好的入门流程，展示了这个平台有多灵活，以及它如何能满足各种不同任务层次的人的需求。实际上，我就从这儿开始我们的快问快答环节：你们刚发布了 52，你展示了 Bench。显然，你知道，每周都有模型大战。但我真的很好奇 harness 大战。为什么像 Codex 这样的模型接口如此重要？你知道，我们看到了你们构建到平台里的一些功能，比如 PR 审查或代码审查，一些小的 UX 修复让它更易用，但就你使用这些编程工具的经验来看，你认为 harness 的差异化体现在哪里？我认为有两个方面。一个是模型工作的质量，另一个是用户体验。对吧？说到模型工作的质量，我猜想很多听这个播客的人自己会捣鼓模型，或者有朋友在做模型，有些人就是所谓的"模型耳语者"，他们知道怎么用一个模型，有些人是某个特定模型的耳语者，但换另一个模型可能就不是了。而我认为非常真实的一点是，这些模型一直在变化，对吧？我已经数不清了，我想我们最近在 OpenAI 大概每两周就会发布一个新模型，对吧？而且我们发布的每一个模型都比上一个更好。这非常令人兴奋。但它们也在进化，对吧？它们有新的能力，除非你整天泡在 Twitter/X 上，否则很难跟上。所以我认为这里有两件事。首先，你需要知道如何充分发挥模型的潜力。你需要知道，比如说，对于 open models，我们训练模型的方式非常——怎么说呢——非常敏捷。我们基本上就是给它们 shell 的访问权限，然后告诉它们，去吧，你觉得该做什么就做什么。于是我们会看到一些非常有趣的新涌现行为，比如有时候模型会决定写一个 Python 脚本来对代码进行大量修改，然后我们就会争论，这到底好不好？我们是更喜欢模型一步步地处理这些编辑，还是让它运行脚本？但不管怎样，这是你应该知道的事。所以 Codex 很酷的一点是，我们在开源的基础上构建 harness。因此你可以看到，每当我们发布一个新模型，我们为了充分发挥它的潜力所做的更新。我可以说，每次我们发布模型，Codex 团队的工程师都会去测试它、思考它、和研究团队交流。我的意思是，他们合作非常紧密，一起研究如何充分发挥模型的潜力。有时候我们会推出一个新能力，比如模型在并行工具调用方面变得更好了。我们就看看这怎么运作。或者最近我们发布了一个叫 compaction 的功能，模型基本上可以——我们可以让模型用一个全新的上下文开始和自己进行一场新的对话，而它要做的只是给自己恰好足够且恰当的信息，这样对用户来说，感觉就像是一场连续的对话，而不是两场对话。所以当我们同时构建 harness 和模型，并做出这样的功能时，我们可以对如何处理模型有更强的主见，然后就能让实际结果对用户来说好得多。Codex CLI 开源的部分原因就在于此：任何想要充分发挥 Codex 模型——实际上也包括一般的开放模型——潜力的人，都可以去观察我们的实现方式。他们想用的话可以用 Codex SDK，完全不用碰 harness，把这部分交给我们。或者如果你想构建自己的 harness，你可以直接复制粘贴部分代码。我们一直在这么做。比如我和很多客户在 Slack 私信里交流，我们就会直接发代码片段给他们，说，哦对，我们是这么做的，你直接复制这段代码就行。所以这就是关于获得更高质量的模型输出，同时还要跟上研究团队创新速度的原因。这就是我认为 Codex harness 在这方面很棒的原因。另一方面是，嗯，是产品层面的负担。比如，今年年初，大多数人们使用的真正强大的 agentic 流程，比如 Codex 还有其他的，都是在 CLI 里，对吧？这是非常基础的东西，但我跟很多人聊过，他们其实并不喜欢整天泡在终端里。我喜欢用终端，但我跟很多人聊过，他们不喜欢。我还跟很多人聊过，他们真的很喜欢同时看到正在被编辑的代码。我就是。我是个——我喜欢读代码。我喜欢读自己的代码，对吧？所以，你知道，这是非常非常基础的东西，但正是在这个地方，构建正确的产品体验为我们带来了巨大的增长。所以，从经验来看，我可以说，比起看到人们只是单纯地在终端里运行，我们看到更多更多的人喜欢一边看着 agent 写代码，一边实时查看。所以，你知道，这是一个非常基础的例子，然后我们刚才还提到了延迟的问题，作为一个更高级的例子——我认为如果我们能正确地 harness 模型，我们就能让你部署模型来每天帮你处理成千上万件事，而且不需要你打字，同时也不会让你觉得过滤这些输出很烦，也不需要你等待，因为每当它主动帮你做某事时，它基本上是在自己的电脑上运行的，只有在有了很棒的结果时才会通知你。所以我的观点其实是，即使所有这些模型都在进步——假如说它们停下来了，虽然这不会发生——要真正把 harness 做好、做到对人有用，也还有很多年的产品工作要做。太好了。我想确保大家没有错过这个建议：如果你想弄清楚如何充分发挥这些新模型的潜力，不妨去深入研究一下 Codex 的开源代码，看看当新模型发布时，你需要做出哪些调整。尤其是如果你是一位开发者，也许你现在做的不是编程工具，而是一款 SaaS 产品，并在新产品发布时使用这些模型。能够观察到模型的创造者如何最大化地发挥模型的独特优势，我认为这是非常有价值的一点，而且人们往往低估了这一点。好，我的第二个问题。我留心观察到了一个东西：Atlas。跟我说说你最喜欢的、但觉得大家没充分重视起来的 Atlas 使用场景吧。第一个可能有点无聊，但确实是真的：我已经开始什么都问 ChatGPT 了。我什么都问它，因为我得到的答案非常贴合我的需求，因为我什么都跟它聊。你知道，我这个人有点怪，如果我问了一个问题，然后基于它做了一个决定，我会告诉它我做了什么决定，因为这样它就能记住。然后我得到的下一个回答就会更好。所以简单来说，对于任何非代码类的工作，我的工作流就是打开 Atlas，按 Command+T 打开一个新标签页，然后输入我想问的任何问题，得到答案。而且我经常追问——对我来说，这就是使用 LLM 的魔力所在。能够直接提问、追问，然后跳转到相关链接，这听起来超级无聊，但我真的很喜欢。另一个我很喜欢的功能是 side chat。基本上，你打开的任何页面……我应该展示一下吗？我可以演示这个。我觉得你应该展示。好啊。那在你操作的时候，我要指出一点：你解决了我今天在 X 上看到的一场争论，就是当 AI 做完某件事之后，无论对错，你应不应该告诉它？比如它修了一个 bug。我就是那种会说“太棒了，看起来真不错，谢谢，修好了”的人。（笑）但我确实在心里说服了自己：这种闭环反馈能创造一些上下文，比如“是的，我做的这件事对了或错了，用户已经接受了”，而且在未来的某个时刻，这会让我的生活变得更好。是的。我觉得这么做有两个原因。第一个就是记忆。对。没错。如果你开启了记忆功能——大多数人都会开——那么你就能得到更好的回答。一个很具体的例子是，我之前在度假，计划有变，所以我们在决定去哪里吃晚餐。我们就问了 ChatGPT 晚餐推荐。说清楚一点，我们本身也很爱美食，所以我们也自己搜了。但问 ChatGPT 很有意思，因为它知道我们住在哪里，也知道我们前一天吃了什么之类的。所以它就给出了一个非常量身定制的推荐，这很酷。我另一个比较大胆的看法是，我认为对 AI 保持礼貌很重要。我知道——
要先说清楚，这不是公司的官方立场——但我更高层面的理由是，我觉得对每个人都保持礼貌很重要。而且我认为，如果你开始对 ChatGPT 不礼貌，这种习惯可能会影响到你，然后你就会开始对你生活中的其他人也不礼貌。我们是大人了，想想孩子吧，对吧？他们听到我们以某种方式跟 AI 说话，他们可能也会去用某种不礼貌的方式对待别人，他们还是孩子，不懂事。所以这是我的一点看法。完全同意，完全同意。你知道，我就是那种会说“请、谢谢、干得不错”的人。说实话，这不是因为 AI 有人性。这是为了保护我自己的人性——如果我习惯了对任何像人的东西粗鲁，那不可能不渗透到我对真人的看法和说话方式中去。呃，把这段剪下来，钉到 YouTube 频道的置顶，为了你自己也要保持礼貌——
这点我非常共鸣。我们的人性取决于我们如何对待他人，而不是他人如何对待我们。对吧。没错。好，说回 side chat。基本上，呃，我可以在这里，点击这个按钮，然后针对这个页面提问。对吧？比如我可以问：“GPT 5.2 有什么了不起的？”呃，你可能会开玩笑地说：“你怎么还让 AI 给你总结这篇文章啊？”但很多时候我在工作时，别人会发给我一个东西，说：“你怎么看？”而我就是没时间。想法？（笑）就是“这什么啊？”对吧？然后你知道，我还可以跟它继续对话，比如“哦，挺有意思的”之类的。嗯。
“嘿 ChatGPT，我对这个怎么看？”（笑）
我是说，这个问题往往会基于我之前跟它聊过的内容来回答，比如“既然你是一个喜欢……的人，你可能会对这个细节感兴趣”。所以，呃，这可能不是最好的例子，因为我是在要求总结，但很多时候如果我在看一些数字、数学——
或者我需要深入了解某个概念，我就会用这个功能。你也可以用这个来改写内容。比如如果我在——
你知道，在 Google 文档里，我可以选中一些文字，然后说：“嘿，你觉得这段话还能怎么改？”所以我认为——
对我来说，side chat 是一个非常酷的功能。嗯，不过——
说实话，我觉得我可能有点被它 nerd sniped 了，因为这就是我加入 OpenAI 想要参与构建的东西。所以我对它非常感兴趣。对我来说，一个不需要我去迁就它、而是能理解我的 agent，这个概念非常强大。
side chat 就是这样，Codex 也是，对吧？你在代码库里启动它，它就在你的环境里，不需要你专门去找它。嗯，我认为这就是未来，我非常期待我们能把 Atlas 和 Codex 的所有最佳理念结合起来，打造成一个基本上就是 AGI 的超级助手。
AGI 超级助手。也许明年我们就能看到它了。听起来像是那种你会很喜欢的产品名字。（笑）超级助手 5.1。
5.2 thinking high。是的。嗯，好，最后一个问题。我们可能已经聊过这个了，但既然我们已经确定你对 AI 很有礼貌，那么当它不回复、不按你说的做、或者记不住的时候，你的提示词技巧是什么，把它拉回正轨？是的。首先，我的工作有点特殊，因为如果我注意到 AI 没有回复，我可能得去提个 bug，或者启动一个 SEV。SEV 就是指严重事故。所以，你知道，是的，我得去做这些事。但我觉得上下文就是一切。所以如果我发现 agent 没有按我的想法做，我有一个非常实用的技巧：我通常不会在不提供上下文的情况下要求 agent 做事。所以我会说：“嘿，我想让你把这个 UI 从这样改成那样，这样用户就会如何操作”，或者“因为我们不希望大家对 XYZ 感到困惑”。而且很有意思的是，我认为——又一个大胆的看法——产品经理（PM）是最会写提示词的人，因为我们已经习惯了不是自己所做领域的专家，也习惯了不是房间里最聪明的人。所以我们通常只能给点建议，甚至不知道对不对。所以我跟 Codex 协作也是这种方式。我会说：“嘿，你能不能把这段代码写得更优雅一点？”但我不会说具体想要什么，因为它看了代码之后，其实比我更清楚。嗯，第一个建议是提供大量背景信息，并且要非常擅长描述你的请求存在多大程度的模糊性。就是说，如果你其实并不在意结果具体怎样，就不要在提示词里制造虚假的精确度。第二点则是，如果这样不行，你再次解释原因后还是不行，那我就直接新开一个对话。嗯，你还可以这么做——我觉得这是非常高阶的用户才会做的事，而且我不认为收听节目的各位会真的去用——但 Codex 是一款非常开放的产品。它会将对话日志存储在你的主目录下的一个 codex 文件夹中，里面有个叫 sessions 的子文件夹。所以就像 Codex 的 sessions。因此你可以直接对它说：“嘿，我新开了一个对话，因为你刚才搞混了。我之所以想让你做这件事，原因是这个。你去读一下我们之前的对话，搞清楚状况。”然后，嗯，你知道的，就从那里继续。太棒了。这期节目要收尾了，却冒出来一个隐藏的热门口诀——我们刚才在 Codex 演示里都没聊到——那就是你所有的对话都保存在本地，所以直接让它去读这些记录就行了。今天真的很开心。Alex，我们在哪里可以找到你？除了提交 bug 之外，我们还能帮上什么忙？我正在招产品经理（PM）。如果你有兴趣，请到招聘页面申请，也可以在社交媒体上联系我。呃，我们整体来说在 Codex 上招很多人。我们确实很喜欢 bug 报告，也很欢迎反馈，实际上它已经是开源的了，所以我不介意聊这个。我们其实还会发布一系列新的 Codex 配置功能，比如允许使用命令或技能（skills）的能力。所以如果你想帮忙构建 Codex 的 skills，或者告诉我们你想要什么配置，那都会非常有帮助。最后，去试试吧。Codex 真的很棒。呃，你可以在 Twitter 上找到我。我在 subreddit 上也很活跃。我们一直都在那里，也很喜欢跟大家聊天。太棒了。嗯，感谢你参加 How I AI。好的，谢谢邀请。非常感谢 你的观看。如果你喜欢这档节目，请在 YouTube 上点赞和订阅，或者更好的是，留下评论告诉我们你的想法。你也可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上找到我们。 请考虑给我们打分和写评价，这会帮助更多人发现这档节目。你可以前往 howiaipod.com 查看所有节目并了解更多信息。下期再见。