开场：Codex 的野心与新的瓶颈
OpenAI 有 90% 的人都在用 Codex——不是 90% 的工程师，而是整个公司的 90%。
你最近发帖说，想把 Codex 做成有史以来最好的桌面应用。为什么把标准定得这么高？
质量门槛必须高到：当你要做下一件事时，不会犹豫要不要打开它。它应该像打开浏览器标签页一样自然。
使用量纪录一直在刷新。你怎么看这种增长？
还得继续看。很多人似乎喜欢这个应用，但真正的检验是，他们会不会为了真实工作不断回来使用。
为什么最前沿的模型仍然不太擅长设计？
设计更难评分。人的品味本身就是反馈机制的一部分，而这一部分对当前技术来说仍然有些遥远。
和几年前相比，现在的产品团队是什么样子？
OpenAI 的人主动性都很强，也都有很多想法，所以每个人都在构建各种东西。整个流程已经被翻转了。
实现已经不再是最昂贵的部分。昂贵的是选择、塑形，以及运用品味做判断。
这是否意味着每个人都会变成“全能型”，专业角色会消失？
我担心有些公司说要取消产品职能，让所有人都只是 builder。拆掉协作墙有价值，但抹掉专业学科和长期积累的最佳实践并没有价值。
Andrew Ambrosino 负责 OpenAI Codex 应用的产品与工程。Codex 越来越不只用于构建软件，也被用于整理文件、起草文档、分析数据、读取邮件和自动化其他工作。
自今年 1 月以来，Codex 的使用量增长了六倍，周活跃用户超过 500 万。OpenAI 内部几乎所有人每周都会使用它，而不只是工程师。
欢迎你。这是一期少见的线下面对面访谈。准备时你说，最想让大家理解的是 AI 如何改变产品工作的形态。
AI 如何倒转产品开发流程
谢谢邀请。这确实是我最想展开讨论的主题。
你所在的团队可能是最 AI-forward 的软件团队之一。它现在是什么样子？一两年后，其他团队可能会走到哪里？
领导者面临的最大挑战，是旧流程被倒转了。从零开始时，你可以让一个强模型搭出几乎任何功能，这会改变瓶颈所在的位置。
当 token 充足时，主动性强的人会探索一切。过去“研究、构思、规格、设计、实现”的线性顺序，隐含了实现资源稀缺这个前提。
现在我们可以先做出许多版本，再从具体产物中学习。工作重点从“什么能实现”转向“什么值得留下”。
所以产品判断不是变得更不重要，而是更重要？
没错。低成本实现会让好点子和坏点子都更快产出。仍然需要有人筛选、识别真正目标，并叫停不该继续的工作。
团队会不会把产出数量误认为进展？
会。当 90 个人都能做出看起来很精致的探索时，信噪比问题反而更严重。只有主动性、没有品味，会制造大量很有说服力的噪声。
什么时候写文档，什么时候做原型
这是否意味着 PRD 已经死了？团队什么时候应该写文档，什么时候应该做原型？
文档没有死。应该选择最能承载你要表达内容的媒介。复杂决策、共享上下文或需要长期保留的判断依据，可能就适合放在文档里。
交互、工作流或某种使用感受，往往更适合在可运行的产物里验证。AI 降低了这类产物的成本，所以团队应该更早让模糊想法接受现实检验。
一个想法最初呈现的形态，会在后续发展中留下“原初印记”。所以起始媒介很重要：文档和精致原型会以不同方式锚定人们的判断。
精致原型可能会让管理者以为产品已经接近上线。你怎么避免这种误解？
要把所处阶段说清楚。视觉完成度已经不能可靠代表产品成熟度，因为非常早期的探索现在也能看起来像成品。团队需要共同语言，说明哪些已知、哪些未知、哪些仍在验证。
所以文档适合固定上下文，而原型适合暴露感受和假设？
这是一个有用的区分。不要崇拜任何一种媒介，而要用它来降低眼前那类具体不确定性。
Taste 不只是审美，而是综合判断力
大家一直说 taste 是 AI 时代的关键能力。你所说的 taste 到底是什么？
Taste 不只是视觉审美。它还包括系统思考、理解上下文、识别交互背后的语义结构，以及判断什么目标值得追求。
模型可以产出许多选项。Taste 是说清楚为什么一个方案不对、另一个为什么连贯，以及为什么某个看似聪明的功能也许根本不该存在。
为什么模型仍然不擅长设计
随着执行摩擦下降，判断会越来越接近工作的中心。能够形成并修正高质量判断的人，会从 AI 中获得更大的杠杆。
为什么编码能力的进步看起来比设计更快？
编码更容易通过测试和客观反馈来评分。设计涉及人的感知、信任、新颖性、文化和上下文一致性，这些很难转化成干净的奖励信号。
实验室也优先投入编码，因为代码本身会帮助研究。更强的编码模型能改进训练和评估下一代模型的工具链。
模型可以复制熟悉的视觉模式——大家会开玩笑说所有东西都长得像 Linear——但复制风格不等于理解一种体验为什么有效。
设计和代码之间还存在一个抽象层问题，对吗？
对。两个控件看起来可能不同，却表达同一种语义关系。一个稳健的系统应该知道它们属于同一交互家族，并在品牌重塑时保持一致变化。
浅层做法是逐个更新几百个组件；更深层的做法是理解它们背后的共同抽象。当前模型在这种层级的设计推理上仍然吃力。
Codex 应用本身是一种新交互范式，既不是终端，也不是传统 IDE。这是否说明人的创造力仍然重要？
传统设计流程为何失效
至少目前是这样。创造新范式比重组既有模式更难。我们可以暂时给人类大脑一点掌声。
Jenny Wen 认为设计流程已经死了，因为团队应该直接构建、边做边引导。你同意吗？
即使在 AI 之前，我也不喜欢僵化、学院派的设计流程。“案例工厂”常常奖励按步骤走完流程，而不是奖励真正结果。
那套流程假设实现昂贵、只能构建一次，因此在实现之前必须把研究和发散几乎做尽。
交互原型早已把类似实现阶段的反馈提前带入设计。AI 现在让团队能把更多真实实现直接拉进探索阶段。
危险在于，早期探索也可能看起来已经可以发布。如果没人明确指出所处阶段，人们看到精致外观就会问为什么明天不能上线。
我们会使用一个大幅简化的“baby Codex”代码库，快速尝试激进的交互想法。它近似真实产品，但改动成本低得多。
流程的工具会死，阶段意识不会
所以，绑定具体工具的日常流程可能已经死了，但那层概念框架——知道自己处于发现、验证还是交付阶段——比以往更重要。
你的经历横跨工程、设计、产品和创业。Codex 团队的设计工作是怎么组织的？
Codex 团队怎样做设计与 dogfood
汇报关系每周都可能不一样，但我们作为嵌入式团队紧密协作、坐在一起。重要的不是组织图，而是围绕产品形成共同反馈循环。
设计师理解工程，产品人会写代码，工程师也参与交互决策。一个角色越来越像你所做活动的平均值，而不是禁止你跨界的门禁。
我们会刻意 dogfood。有时我们宁愿继续忍受不完美的内部流程，也不为自己做一条私有捷径，因为亲自感受摩擦会迫使公开产品变得更好。
当每个人都能构建时，产品职能是不是正在消失？
角色不会消失，但边界会变软
一些低杠杆的协调工作会缩减。一个只搬运需求、安排会议和转述状态的产品经理，越来越难躲在流程后面。
但产品判断不会消失。仍然需要有人决定做什么、理解用户问题、平衡短期和长期结果，并守住产品方向。
健康的变化，是产品人离构建更近。他们可以验证想法、检查结果并更新判断，而不必等待漫长的交接链。
我也见过另一种错误：取消专业分工，连同帮助团队避免重蹈覆辙的积累一起丢掉。流动性有价值，失忆没有。
所以角色会变成责任区域，而不是墙？
对。可以把它想成区域防守。每个人保留自己的强项和责任，同时在工作跨过旧边界时互相补位。
小而高密度的团队与区域防守
实际团队结构是什么样的？
取决于统计口径，这项工作的规模可以从大约两位数工程师的核心团队，延伸到公司内部更大的协作网络。核心团队还有约为工程师一半数量的设计师，以及少量产品人员。
我们重视主动性、品味，以及有过创业经历的人。目标不是把“小团队”当口号，而是形成高密度团队，让一个想法能从洞察一路被推进到完成。
产品经理像在公司里做区域防守。他们补位、连接工作并维持一致性，而不是只拥有一条狭窄的工单队列。
团队也需要有产品意识的工程师。当实现成本下降时，在实现过程中识别重要产品决策的能力会变得更有价值。
IC、管理者与无限产出的信噪比
AI 会怎样改变个人贡献者和管理者之间的界线？
强大的 IC 可以管理多个 agent，完成过去需要更多协调才能完成的工作。管理者在不同粒度上做着类似的事：设定方向、审查产出，并决定注意力投向哪里。
无限产出不会让管理消失。它会让信号选择、质量标准、反馈机制和说“不”的能力变得更重要。
路线图、未来模型与“假精确”
当模型和工作流变化这么快时，你怎么规划路线图？
短期可以做得很细；九个月后的精确性通常是假的。我们会保持清晰方向和约束，但把远期计划视为假设，而不是施工图。
我们会为可能早了一两年的想法做原型，把它放在那里，并在新模型到来时重新测试。这个产物会成为探测未来能力的探针。
Codex 应用就是很好的例子。如果同样的产品在 11 月发布，很可能会失败；到了 2 月，模型进步改变了结果，哪怕产品形态大体相似。
所以路线图不仅要安排功能顺序，还要考虑模型能力到来的时机。
没错。你必须区分“坏点子”和“所需能力尚未到来的好点子”。
先做出现在还不能发布的功能
你们会不会刻意构建现在还不能正常工作的功能？
会，但必须正确标记它所处的阶段。写出了代码，不等于它就该上线；它可能只是让我们拥有了一个用于测试未来模型的产物。
应用内浏览器沿着 Operator、Atlas、Codex 和 ChatGPT 这条线发展。底层想法相似，但不同的智能水平和产品上下文，会改变它是否有效。
某个版本失败，不应自动判定整个功能方向错误。有时正确做法是保留学习结果、等待能力成熟，再用更强智能重新发布相同形态。
但团队也有一种肌肉记忆：既然代码写了，就应该发布。
这种肌肉记忆很危险。产品团队需要为探索性产物、内部测试和发布候选明确区分状态。
太 AGI-pilled 的产品陷阱
当团队太 AGI-pilled，目标超出了今天用户或模型能支持的范围，会发生什么？
最初的 Codex Web 会接收一个完整任务，然后稍后回来交付。这个形态很有野心，但当时的模型还无法足够可靠地完成任务。
更本地化、更互动、会提问并陪在用户身边的编码产品反而表现更好，因为它匹配了模型的真实能力。我们当时确实对 AGI 押注得太超前了。
从 AI 写代码到监督式与非监督式开发
同一种产品形态可能需要发布六次才真正奏效。模型时机、用户理解和产品沟通都会改变结果。
你怎么在保持雄心的同时，不忽略今天的可靠性和细节问题？
你需要一组人维护、改进现有产品，也需要一种自下而上的探索文化，允许新方向颠覆现有产品。同一种流程通常很难同时把两者都优化好。
用户指出细节问题是对的。雄心不能成为当前体验糟糕的借口，但打磨眼前产品也不能成为唯一活动。
AI-native 产品开发的最新前沿是什么？是 loops 吗？
Loops 都已经是上周的话题了。过去那个“有多少代码由 AI 编写”的问题，在几乎所有代码都能由 AI 生成之后已经失去意义。
更有用的区分是监督式和非监督式工作：人需要多频繁地引导、检查和恢复流程。不断移动这条门槛，本身就是产品进步的标志。
自主开发的边界与个人工作转型
团队正在探索自主软件开发、harness engineering，以及夜间自动维护，例如为代码库做垃圾清理。
当前模型往往会增加复杂性。我很希望研究团队让模型更擅长删除代码，而不只是生成更多代码。
完全自动驾驶还需要产品品味：哪些功能请求应该忽略，哪些应该合并重构，以及哪些抽象能长期保持健康。
我们是否已经到了这样一个阶段：自主循环可以监听 Twitter、Slack 和邮件，并持续改进应用？
还不能可靠做到。我不会说永远不可能，但今天的循环仍然缺少足够的品味、上下文和克制。
随着你的职责扩大，你现在个人怎么使用 Codex？
Andrew 的发布追踪与深度研究
一开始，我亲自编写或监督了早期应用的大量代码。随着团队扩大，我的工作转向产品发现、招聘、引导，以及构建帮助自己理解工作的系统。
我会用 Codex 处理表格、内部深度研究，并跨文档和对话收集信息。它降低了启动任务和恢复上下文的成本。
在一次 5 月发布中，我们并行协调应用内浏览器、电脑操作和 artifact 工作。我们开玩笑说这是一次“氛围协调式发布”，因为许多移动部件都通过 Codex 连接起来。
我做了一个追踪器，读取 Notion 文档、拉取请求和 Slack 更新，再汇总发布状态。这比人工追逐每条线程更有用。
每日简报、邮件和电脑操作
另一个工作流会读取数千个 Slack 频道，并围绕少数几个问题生成每日简报。真正的产品挑战，是让这类设置可以通过对话完成，而不是要求每个人都为自己搭一套系统。
我还会用它筛选类似垃圾邮件的内容、整理重复信息，并通过自然语言配置和指导定时任务。
电脑操作和浏览器自动化带来了什么新能力？
有一次，Codex 直接通过电脑控制配置 Google Cloud Pub/Sub，因为那是最实际的路径。关键不在于它使用连接器、浏览器、扩展还是直接写代码，而在于哪条路径能安全完成任务。
记忆、浏览器与 SaaS 的连接方式
个人工作流会暴露产品真正需要的基础能力。但答案不能是要求每个用户都搭建复杂的私人记忆系统或 Obsidian“心智宫殿”。记忆必须成为产品能力。
你预计未来所有 SaaS 应用都会在 Codex 里运行吗？
存在两个方向。Codex 可以通过连接器、电脑操作或扩展使用专业工具；网页应用也可以在 Codex 内打开，让 agent 在它们周围增加能力。
转向浏览器技术栈会带来能力，也带来权衡。仅供 agent 使用的浏览器、用户浏览器和人机共享浏览器，在安全、状态和交互需求上都不同。
高级用户已经有快捷键和肌肉记忆；新手需要清晰可理解和信心。产品必须同时服务两者，又不能变成一堆模式的拼盘。
Codex 应用最终会走向哪里？
第一版被刻意控制在合适尺寸：聊天加代码可见性，但不假装自己是完整可编辑 IDE。到一二月份，这种形态在工程师和研究人员中找到了产品市场匹配。
从开发者工具走向知识工作
随后，市场、沟通、财务和法务人员也开始使用它，尽管这个偏代码的界面对他们并不友好。这种真实行为比我们对 persona 的假设更有力。
我们曾尝试把这些用户迁移到看起来更适合的界面，例如 ChatGPT 或 Atlas，但很多人不愿离开 Codex。这让我们明白，“开发者工具还是知识工作工具”的二分法过于简单。
自适应界面与工作主基地
界面可以从简单开始，再根据工作逐步显露复杂度。做 Excel 工作的人不需要 Git 仓库信息，但系统可以从上下文推断出应该呈现哪些基础能力。
我们会深入与财务、科学和法务团队合作。如果扩展基础和通用模型设计正确，同一个工作主基地就能支持非常不同的垂直工作流。
有人把它叫作超级应用。它的概念就是在一个地方做所有事情吗？
我希望大家没说“超级应用”这个词，因为现在我每天都听到它。我觉得“工作主基地”更准确。
它是一个让你开始工作、结束工作并跨界面自动化工作的地方。有些任务在应用内完成，另一些会打开合适的外部应用，完成后再返回。
Excel、Premiere Pro 与专业工具
例如，内置表格编辑器未必足以支持用于数十亿美元融资的财务建模。Codex 可以与桌面 Excel 的加载项通信，使用专业工具，完成后再关闭它。
讲讲视频制作人员和 Premiere Pro 的故事吧。
我们的内部 DX 摄像师 Brent 要剪辑在这个房间拍摄的发布视频。出于好奇，他试着问 Codex 能不能完成剪辑。
Codex 理解他使用 Premiere Pro。它可以修改部分底层文件，但无法执行界面中的所有操作。
于是 Codex 给自己构建了一个 Premiere Pro 扩展，安装后通过扩展修改应用里的标记。看到这一幕非常震撼。
两个工具模型、失败角与快问快答
这说明了两个互为镜像的模式：AI 可以操作现有专业工具；现有网页应用也可以被带进 AI 工作主基地，让 agent 增加额外执行能力。
我们进入“失败角”。大家看到 Codex 高速增长，却看不到那些事情不顺利的年份。哪次失败塑造了你？
我曾作为创业者苦撑多年，最后一家公司基本以拆分资产的方式出售。我也做过受监管的 AI 创业项目，反复撞上限制和失败。
现在是我第一次没有持续感觉自己在失败。在此之前，我失败了十到十五年。一个成功快照会掩盖很长的一串死胡同。
即使现在，ChatGPT 和 Codex 每天也充满微小失败。内部 Slack 线程可能有两千条消息，大家会非常直接地说某个想法愚蠢或已经坏掉。
这种严厉的 dogfood 很有价值。如果产品能经受诚实的内部批评，外部用户拿到的东西就会更强。
快问快答：你推荐什么书？
儿童读物里，《咕噜牛》非常棒。我也很喜欢《大橙色斑点》，它通过 Mr. Plumbean 的故事讲个人能动性，以及抵抗社区要求所有房子都一样的压力。
快问快答：书、产品与跨学科能力
我们也喜欢由 Kate McKinnon 参与的新版《神奇校车》。我没太多时间看电影，但偶尔会一口气看完一集一小时的节目。
产品偏好、跨学科能力与幕后建议
你欣赏哪些产品？
当然是 Codex，还有 Linear。Linear 的产品非常连贯，对细节也有很高标准。
工程、设计和产品管理，哪一种最难？
取决于具体的人。更有趣的变化，是人们可以更流畅地在这些学科之间移动，但学科本身仍然保留着重要知识。
找到值得做的工作，然后学习这项工作需要的一切。不要让继承来的职位名称阻止你获得下一项技能。
录制结束后，我们又聊到 Codex 如何协助内容剪辑，包括寻找剪切点和删除停顿。
对于非工程岗位的人，最好的起点是什么？
从好奇心和一个明确结果开始。代价通常只是一些 token。先问工具能否帮助完成一个真实任务，而不是一上来就设计宏大的自动化系统。
不要和某个精确流程结婚，而要忠于只有你最适合交付的结果。像整理 Figma 自动布局这类流程会越来越多地被自动化。
在 AI 时代取得成效，需要自我觉察和重新学习的意愿。重新学习很累，但我个人喜欢不断改变做事方式，而不是每天重复同一套流程。
这也许就是我为自己这份工作找到的产品市场匹配：工作每天都在变化，而 Codex 让我可以持续随之调整。