OpenAI 产品经理是如何工作的？丨Aakash Gupta

OpenAI 产品经理是如何工作的？丨Aakash Gupta OpenAI 产品经理是如何工作的？丨Aakash Gupta Modified May 30 原创 Capihom Capihom 晚点再听LaterCast2026年5月29日 20:30 北京 标题已修改 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3500 字，如果你现在没有时间，试试转成播客稍后再听 "代码已经从昂贵资产，变成需要被管理的负债。" "如果一天不用十亿 token，你可能没有认真用这批新同事。" "团队要学会雇五个叫 Codex 的实习生。" Aakash Gupta 这期请来 OpenAI frontier 团队的 Ryan Leopo，这期聊的重点，放在 OpenAI 内部如何让 PM、设计师、工程师一起进入代码生产现场。Ryan 的判断很尖锐：过去组织围绕“代码很贵”来设计流程，现在代码生成变便宜，团队真正要管理的是质量、边界、并行度和验证。 代码从稀缺品变成待管理对象 Ryan 开场抛出一句很反常识的话：code is a liability。过去软件组织把代码当最贵的产出，因为工程师键盘上的时间有限，验证和部署也很重。所有流程、评审、权限和排期，都围绕“保护这份昂贵产出”来设计。 "代码曾经是最贵的东西，现在生成代码本身已经变得很便宜。" 当 Codex 这样的模型能并行写出大量代码后，团队要换一个角度看问题。代码不再天然代表进度，更多代码也不一定代表更强产品。每一段生成物都需要上下文、测试、业务边界和可观察结果来承接。 AI 让代码产能上升，也把质量管理的压力前移到了团队结构里。 PM 和设计师开始接触可执行物 Ryan 认为，新工具正在抹平角色之间的生产距离。设计师从 Figma 到 HTML、SVG、CSS，中间一直有损耗；PM 从用户访谈到 PRD，再到代码上线，中间也有损耗。AI 编码工具让每个角色更接近最终可执行产物。 "每个软件交付团队成员，都可能站到同一条生产线上。" 这并不等于角色消失。PM 仍然负责要解决什么问题，设计师仍然负责体验和审美，工程师仍然负责系统质量。但每个人都能更早看到自己的判断如何落进产品。过去要靠会议翻译的想法，现在可以先变成可运行版本，再让团队围绕结果讨论。 OpenAI 从空代码库做内部 agent Ryan 回忆了一个内部实验。去年 6 月，编码模型刚开始可用，他们从一个空代码库出发，让 Codex 做完整的软件工程工作，原型是给非编码知识工作者使用的内部 agent。这个实验的目标很清楚：检验 coding agent 能否搭出面向普通业务场景的工具。 "我们从零开始，让 Codex 完成完整的软件工程工作。" 这段经历解释了 OpenAI 为什么看起来像提前两年进入未来工作方式。PM 和设计师没有突然都成了资深工程师。团队给模型足够清晰的任务、上下文和验证方式，机器就能承担大量生产动作。人把注意力放回问题、品味、排程和验收。 一份 PRD 可以直接长成 demo 对话里有一个很具体的场景：团队周初一起看 PRD，工程师没有和 PM 逐条沟通，周末 demo 时功能已经跑起来，并在下一周面向客户发布。Ryan 说，这能安全发生，是因为他们的代码被拆成模块，业务逻辑有清晰边界，每个领域都能导出高保真 fake 供测试使用。 "那些由 PM vibing 出来的测试，真的跑到了依赖服务和业务逻辑上。" 这段话背后的门槛很高。很多团队也想让 PM 直接用 agent 写功能，但代码库像一团泥，任何改动都有远处副作用。OpenAI 的做法先给业务逻辑分层，强制包边界，让 agent 可以在受控空间里行动。 让非工程角色靠近代码，前提是工程系统先有清楚边界。 不要盯着 agent 工作 Ryan 还讲了一个管理细节：他曾故意让团队使用 CLI、多标签页等略有摩擦的方式启动 Codex，因为他不希望人盯着 agent 每一步。人如果一直看着屏幕等 agent 输出，就会把新工具用回旧流程。 "我们不希望他们盯着电脑看自己的 agent。" 这和很多团队的直觉相反。AI 工作流的价值在于并行和异步，人应该去安排更多任务、做更高层判断、检查结果，而不是把 agent 当一个慢吞吞的结对程序员盯着。Ryan 后来也承认，如果今天重做，他会把团队的设计品味、共享知识和插件打包到 Codex app 里，让使用更顺滑。 模块化决定并行上限 在代码结构部分，Ryan 反复强调 package boundary。高速增长的代码库最容易变成一团泥，业务逻辑散在各处，改一处牵动一片。这样的系统不适合大规模 agent 并行，因为每个任务都可能踩到别人的脚。 "你不能先允许一团泥出现，再期待 agent 安全地并行工作。" OpenAI 的解法是用代码强制边界：业务域之间硬隔离，依赖通过 fake 和测试承接。这样 PM 或 agent 生成的测试，不会停留在空壳层，而是能触达真实业务逻辑。团队能跑更多 Codex，靠的是系统结构允许机器犯小错，并让测试把错误拦住。 五个 Codex 实习生带来的管理题 Ryan 提到一个内部实验：让团队假设自己被分配了五个叫 Codex 的实习生，成功标准之一是看团队如何吸收这些资源。这个比喻很准确。模型更像一批需要任务、上下文、反馈和验收的产能。 "我们让团队假设自己被迫雇了五个叫 Codex 的实习生。" 如果团队只给一个模糊需求，这五个“实习生”会产出一堆难验收的东西；如果团队把任务拆清楚，给出测试、数据和业务边界，它们就能并行推进。AI 管理能力会成为技术负责人和 PM 的新基本功。 十亿 token 不是炫技指标 主持人提到 Ryan 的另一句狠话：如果你一天不用十亿 token，几乎算不认真。Ryan 想提醒团队，别再把模型当成稀缺计算器来省着用。更多 token 代表更多尝试、更多推理、更多候选方案和更深验证。 "让 GPU 闲着，在某种意义上就像没有人在键盘上工作。" 这会改变团队对成本的感觉。过去最贵的是工程师时间，今天很多场景里更贵的是没有把模型产能转化成实验速度。用得少，常常说明组织还没有准备好接住并行产能。 周末可以先闭合一条回路 最后，Ryan 给技术负责人一个周末建议：让 Codex 能看见你的 app，并能驱动业务逻辑。没有这条闭环，团队很容易“vibe”出一些看似能跑的东西，却无法证明它解决了原本的问题。 "要让 Codex 能看到你的应用，并驱动业务逻辑。" 这条提醒也适合 PM。不要从宏大改造开始，先让 agent 能跑一个真实流程、改一个小功能、通过一个测试、看见一个结果。工作方式的变化，不靠口号推进，靠一条条可验证闭环累积。 Ryan 对“代码是负债”的解释，还可以从团队心理上理解。过去工程师写下的每一行代码，都带着维护成本、线上风险和协作成本。模型生成速度上来后，团队更容易在短时间内得到很多实现方案；如果没有测试和边界，这些方案会把未来维护压力迅速堆高。 这就是为什么他一边赞成 PM 和设计师靠近代码，一边反复讲模块化。没有边界的代码库，会把 AI 产能变成混乱制造机；有边界的代码库，才能把 agent 放进具体业务域里，让它在安全范围内试错。AI 工作流的前提，往往是老派工程纪律。 OpenAI 的例子也说明，PRD 的形态会变化。以前 PRD 是沟通文档，写完后交给工程拆任务；现在 PRD 可以变成 agent 的输入，直接生成测试、原型和可运行 demo。PM 写得越清楚，机器越容易把需求变成可检查结果。 设计师的角色同样会变。Ryan 提到可以把团队共同的设计品味打包成插件，让 Codex app 在生成界面时直接吸收这些约束。设计规范不再只是 Figma 里的说明页，也会成为 agent 工作时能调用的上下文。 “不要盯着 agent”背后还有一个管理含义：团队要学会安排异步工作。人盯着屏幕等待输出时，仍然把 AI 当成单线程助手；人把多个任务排出去，再回来检查证据、测试和体验时，才开始利用机器的并行能力。 十亿 token 的说法听起来激进，但它其实在问团队有没有准备好接住更多探索。更多 token 可以跑更多备选方案、更多测试、更多重构尝试。低使用量有时代表节省成本，有时代表团队没有把任务拆到模型能承担的粒度。 对普通公司来说，不必照搬 OpenAI 的规模。更现实的起点是挑一个边界清晰的内部工具，让 PM 写出需求和验收样例，让 Codex 生成实现和测试，再由工程师检查结构。这个小实验能暴露很多问题：上下文够不够、测试真不真、业务逻辑有没有被隔离。 这期最大的价值，是把“AI 让 PM 写代码”从猎奇话题拉回组织设计。谁拥有问题、谁拥有体验、谁拥有系统质量，这些分工还在；改变的是每个人都能更早接触可执行结果，团队围绕结果调整，而不是围绕文档猜测。 Ryan 的表达里还有一层现实感：AI 带来的不只是速度，也会放大组织已有的弱点。代码库边界混乱，agent 会更快制造混乱；测试只覆盖表层，agent 会更快绕过真实业务；需求写得含糊，agent 会更快把含糊变成一堆看似完成的实现。 所以 OpenAI 的工作方式并不适合被简化成“让 PM 直接写代码”。更准确的说法是，让每个角色都能围绕可执行结果工作。PM 提供问题和验收样例，设计师提供体验标准和组件约束，工程师提供架构边界和质量护栏，Codex 在这些约束里并行产出。 对多数团队，第一步可以很小：选一个内部后台页面，让 PM 写清楚用户故事和验收场景；让设计师把组件规则整理成上下文；让工程师准备 fake 服务和测试入口；最后让 Codex 生成实现。一次跑完，团队就会知道自己缺的是上下文、测试，还是系统边界。 Ryan 讲的未来并不轻松。AI 把更多人带到代码旁边，也要求更多人理解质量从哪里来。PM 写需求时要想到测试，设计师给稿时要想到组件约束，工程师搭架构时要想到 agent 会怎样调用这些边界。 这也是 Ryan 反复讲“harness engineering”的原因。团队要给模型装上缰绳：任务拆分、上下文、测试、权限、回滚和观察入口都要准备好。没有这些护栏，更多 token 只会制造更多待清理的代码。 先跑一个小闭环，再谈大规模改造。 这一步最能暴露团队当前的短板。 写在最后 这期对话提醒所有产品团队：AI 编码远比替换工程师复杂。代码变便宜后，组织要重建边界、测试、角色协作和任务分发。PM 和设计师会更靠近可执行物，工程师会更像系统设计者和产能调度者。下一次写 PRD 时，可以先想一件事：这份需求能不能直接长成一个可验收的 demo？ 内容来源："I got an inside look at how OpenAI PMs ship code"丨Aakash Gupta 原视频：https://www.youtube.com/watch?v=8suwvrF0Lv0 No access 26e626eea8c04813804b4b9504c6ce5a 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ 原创 Capihom Capihom 晚点再听LaterCast2026年5月29日 20:30 北京 标题已修改 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3500 字，如果你现在没有时间，试试转成播客稍后再听 "代码已经从昂贵资产，变成需要被管理的负债。" "如果一天不用十亿 token，你可能没有认真用这批新同事。" "团队要学会雇五个叫 Codex 的实习生。" Aakash Gupta 这期请来 OpenAI frontier 团队的 Ryan Leopo，这期聊的重点，放在 OpenAI 内部如何让 PM、设计师、工程师一起进入代码生产现场。Ryan 的判断很尖锐：过去组织围绕“代码很贵”来设计流程，现在代码生成变便宜，团队真正要管理的是质量、边界、并行度和验证。 代码从稀缺品变成待管理对象 Ryan 开场抛出一句很反常识的话：code is a liability。过去软件组织把代码当最贵的产出，因为工程师键盘上的时间有限，验证和部署也很重。所有流程、评审、权限和排期，都围绕“保护这份昂贵产出”来设计。 "代码曾经是最贵的东西，现在生成代码本身已经变得很便宜。" 当 Codex 这样的模型能并行写出大量代码后，团队要换一个角度看问题。代码不再天然代表进度，更多代码也不一定代表更强产品。每一段生成物都需要上下文、测试、业务边界和可观察结果来承接。 AI 让代码产能上升，也把质量管理的压力前移到了团队结构里。 PM 和设计师开始接触可执行物 Ryan 认为，新工具正在抹平角色之间的生产距离。设计师从 Figma 到 HTML、SVG、CSS，中间一直有损耗；PM 从用户访谈到 PRD，再到代码上线，中间也有损耗。AI 编码工具让每个角色更接近最终可执行产物。 "每个软件交付团队成员，都可能站到同一条生产线上。" 这并不等于角色消失。PM 仍然负责要解决什么问题，设计师仍然负责体验和审美，工程师仍然负责系统质量。但每个人都能更早看到自己的判断如何落进产品。过去要靠会议翻译的想法，现在可以先变成可运行版本，再让团队围绕结果讨论。 OpenAI 从空代码库做内部 agent Ryan 回忆了一个内部实验。去年 6 月，编码模型刚开始可用，他们从一个空代码库出发，让 Codex 做完整的软件工程工作，原型是给非编码知识工作者使用的内部 agent。这个实验的目标很清楚：检验 coding agent 能否搭出面向普通业务场景的工具。 "我们从零开始，让 Codex 完成完整的软件工程工作。" 这段经历解释了 OpenAI 为什么看起来像提前两年进入未来工作方式。PM 和设计师没有突然都成了资深工程师。团队给模型足够清晰的任务、上下文和验证方式，机器就能承担大量生产动作。人把注意力放回问题、品味、排程和验收。 一份 PRD 可以直接长成 demo 对话里有一个很具体的场景：团队周初一起看 PRD，工程师没有和 PM 逐条沟通，周末 demo 时功能已经跑起来，并在下一周面向客户发布。Ryan 说，这能安全发生，是因为他们的代码被拆成模块，业务逻辑有清晰边界，每个领域都能导出高保真 fake 供测试使用。 "那些由 PM vibing 出来的测试，真的跑到了依赖服务和业务逻辑上。" 这段话背后的门槛很高。很多团队也想让 PM 直接用 agent 写功能，但代码库像一团泥，任何改动都有远处副作用。OpenAI 的做法先给业务逻辑分层，强制包边界，让 agent 可以在受控空间里行动。 让非工程角色靠近代码，前提是工程系统先有清楚边界。 不要盯着 agent 工作 Ryan 还讲了一个管理细节：他曾故意让团队使用 CLI、多标签页等略有摩擦的方式启动 Codex，因为他不希望人盯着 agent 每一步。人如果一直看着屏幕等 agent 输出，就会把新工具用回旧流程。 "我们不希望他们盯着电脑看自己的 agent。" 这和很多团队的直觉相反。AI 工作流的价值在于并行和异步，人应该去安排更多任务、做更高层判断、检查结果，而不是把 agent 当一个慢吞吞的结对程序员盯着。Ryan 后来也承认，如果今天重做，他会把团队的设计品味、共享知识和插件打包到 Codex app 里，让使用更顺滑。 模块化决定并行上限 在代码结构部分，Ryan 反复强调 package boundary。高速增长的代码库最容易变成一团泥，业务逻辑散在各处，改一处牵动一片。这样的系统不适合大规模 agent 并行，因为每个任务都可能踩到别人的脚。 "你不能先允许一团泥出现，再期待 agent 安全地并行工作。" OpenAI 的解法是用代码强制边界：业务域之间硬隔离，依赖通过 fake 和测试承接。这样 PM 或 agent 生成的测试，不会停留在空壳层，而是能触达真实业务逻辑。团队能跑更多 Codex，靠的是系统结构允许机器犯小错，并让测试把错误拦住。 五个 Codex 实习生带来的管理题 Ryan 提到一个内部实验：让团队假设自己被分配了五个叫 Codex 的实习生，成功标准之一是看团队如何吸收这些资源。这个比喻很准确。模型更像一批需要任务、上下文、反馈和验收的产能。 "我们让团队假设自己被迫雇了五个叫 Codex 的实习生。" 如果团队只给一个模糊需求，这五个“实习生”会产出一堆难验收的东西；如果团队把任务拆清楚，给出测试、数据和业务边界，它们就能并行推进。AI 管理能力会成为技术负责人和 PM 的新基本功。 十亿 token 不是炫技指标 主持人提到 Ryan 的另一句狠话：如果你一天不用十亿 token，几乎算不认真。Ryan 想提醒团队，别再把模型当成稀缺计算器来省着用。更多 token 代表更多尝试、更多推理、更多候选方案和更深验证。 "让 GPU 闲着，在某种意义上就像没有人在键盘上工作。" 这会改变团队对成本的感觉。过去最贵的是工程师时间，今天很多场景里更贵的是没有把模型产能转化成实验速度。用得少，常常说明组织还没有准备好接住并行产能。 周末可以先闭合一条回路 最后，Ryan 给技术负责人一个周末建议：让 Codex 能看见你的 app，并能驱动业务逻辑。没有这条闭环，团队很容易“vibe”出一些看似能跑的东西，却无法证明它解决了原本的问题。 "要让 Codex 能看到你的应用，并驱动业务逻辑。" 这条提醒也适合 PM。不要从宏大改造开始，先让 agent 能跑一个真实流程、改一个小功能、通过一个测试、看见一个结果。工作方式的变化，不靠口号推进，靠一条条可验证闭环累积。 Ryan 对“代码是负债”的解释，还可以从团队心理上理解。过去工程师写下的每一行代码，都带着维护成本、线上风险和协作成本。模型生成速度上来后，团队更容易在短时间内得到很多实现方案；如果没有测试和边界，这些方案会把未来维护压力迅速堆高。 这就是为什么他一边赞成 PM 和设计师靠近代码，一边反复讲模块化。没有边界的代码库，会把 AI 产能变成混乱制造机；有边界的代码库，才能把 agent 放进具体业务域里，让它在安全范围内试错。AI 工作流的前提，往往是老派工程纪律。 OpenAI 的例子也说明，PRD 的形态会变化。以前 PRD 是沟通文档，写完后交给工程拆任务；现在 PRD 可以变成 agent 的输入，直接生成测试、原型和可运行 demo。PM 写得越清楚，机器越容易把需求变成可检查结果。 设计师的角色同样会变。Ryan 提到可以把团队共同的设计品味打包成插件，让 Codex app 在生成界面时直接吸收这些约束。设计规范不再只是 Figma 里的说明页，也会成为 agent 工作时能调用的上下文。 “不要盯着 agent”背后还有一个管理含义：团队要学会安排异步工作。人盯着屏幕等待输出时，仍然把 AI 当成单线程助手；人把多个任务排出去，再回来检查证据、测试和体验时，才开始利用机器的并行能力。 十亿 token 的说法听起来激进，但它其实在问团队有没有准备好接住更多探索。更多 token 可以跑更多备选方案、更多测试、更多重构尝试。低使用量有时代表节省成本，有时代表团队没有把任务拆到模型能承担的粒度。 对普通公司来说，不必照搬 OpenAI 的规模。更现实的起点是挑一个边界清晰的内部工具，让 PM 写出需求和验收样例，让 Codex 生成实现和测试，再由工程师检查结构。这个小实验能暴露很多问题：上下文够不够、测试真不真、业务逻辑有没有被隔离。 这期最大的价值，是把“AI 让 PM 写代码”从猎奇话题拉回组织设计。谁拥有问题、谁拥有体验、谁拥有系统质量，这些分工还在；改变的是每个人都能更早接触可执行结果，团队围绕结果调整，而不是围绕文档猜测。 Ryan 的表达里还有一层现实感：AI 带来的不只是速度，也会放大组织已有的弱点。代码库边界混乱，agent 会更快制造混乱；测试只覆盖表层，agent 会更快绕过真实业务；需求写得含糊，agent 会更快把含糊变成一堆看似完成的实现。 所以 OpenAI 的工作方式并不适合被简化成“让 PM 直接写代码”。更准确的说法是，让每个角色都能围绕可执行结果工作。PM 提供问题和验收样例，设计师提供体验标准和组件约束，工程师提供架构边界和质量护栏，Codex 在这些约束里并行产出。 对多数团队，第一步可以很小：选一个内部后台页面，让 PM 写清楚用户故事和验收场景；让设计师把组件规则整理成上下文；让工程师准备 fake 服务和测试入口；最后让 Codex 生成实现。一次跑完，团队就会知道自己缺的是上下文、测试，还是系统边界。 Ryan 讲的未来并不轻松。AI 把更多人带到代码旁边，也要求更多人理解质量从哪里来。PM 写需求时要想到测试，设计师给稿时要想到组件约束，工程师搭架构时要想到 agent 会怎样调用这些边界。 这也是 Ryan 反复讲“harness engineering”的原因。团队要给模型装上缰绳：任务拆分、上下文、测试、权限、回滚和观察入口都要准备好。没有这些护栏，更多 token 只会制造更多待清理的代码。 先跑一个小闭环，再谈大规模改造。 这一步最能暴露团队当前的短板。 写在最后 这期对话提醒所有产品团队：AI 编码远比替换工程师复杂。代码变便宜后，组织要重建边界、测试、角色协作和任务分发。PM 和设计师会更靠近可执行物，工程师会更像系统设计者和产能调度者。下一次写 PRD 时，可以先想一件事：这份需求能不能直接长成一个可验收的 demo？ 内容来源："I got an inside look at how OpenAI PMs ship code"丨Aakash Gupta 原视频：https://www.youtube.com/watch?v=8suwvrF0Lv0 No access 26e626eea8c04813804b4b9504c6ce5a 00:00 No access 26e626eea8c04813804b4b9504c6ce5a 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ 🔗 原文链接： https://mp.weixin.qq.com/s/SdD7QH88... https://mp.weixin.qq.com/s/SdD7QH88...