OpenAI Codex 周活用户已突破 500 万,自 2026 年 2 月以来增长了 6 倍,OpenAI 内部近 100% 员工每周使用 Codex——不限于工程师。Andrew Ambrosino(产品与工程负责人)提出:AI 时代产品开发已「彻底反转」——实现不再昂贵,品味(taste)成为最稀缺的职业能力。
Codex 团队采用「区域联防」产品管理模式:产品负责人分散覆盖业务面而非重叠工作,工程师全员需具备产品思维。同一款 Codex App,2025 年 11 月发布会失败,2026 年 2 月发布成功——唯一变量是底层模型能力在三个月间的飞跃。
未来愿景:Codex 成为跨所有工具的「工作大本营」——不把所有功能塞进一个窗口,而是通过连接器、浏览器与计算机操作能力,协调 ChatGPT、Excel 等专业工具协同工作。
OpenAI内部近100%员工使用Codex,不只是工程师
OpenAI Codex 桌面应用正在经历惊人的增长曲线。产品与工程负责人 Andrew Ambrosino 在 Lenny's Podcast 节目中透露,自 2026 年 2 月正式面向公众发布以来,Codex 周活跃用户已增长 6 倍,达到 500 万以上。更引人注目的是 Codex 在 OpenAI 内部的使用率——近 100% 的员工每周使用 Codex,包括营销、财务、法务等非工程部门。
Andrew 的团队规模在两位数工程师与约一半数量的设计师之间,加上少数产品人员。团队构成上,Andrew 偏好前创始人和「具备极强品味的成员」——成员拥有高度的自主权和判断力,不依赖固定的角色边界。
AI已彻底反转产品开发流程:实现变便宜,品味变昂贵
Andrew 提出的核心论断——产品开发流程已经「彻底反转」——是整场访谈的理论支柱。传统的产品流程(研究→构思→原型→设计→实现→验证)建立在「实现是昂贵的」这一隐含假设之上:因为写代码成本高,你必须在实现之前穷尽一切方式去降低风险(通过文档、研究、原型)。AI 推翻了这一假设。如今任何人都可以在 AI 帮助下快速搭建任意功能——OpenAI 内部经常出现同一个想法同时有 90 多个独立团队并行实现的现象。
这意味着昂贵的环节不再是实现,而是筛选与判断。Andrew 引用 Linear 产品负责人的观点:品味不光是审美(「Paul Graham 品味很好但他穿 cargo shorts」)。品味的真实含义包括:系统思维(一个功能如何在大局中定位)、时机判断(这个功能现在的模型能力够不够)、信息呈现(如何选择合适的媒介来传达观点)。在林林总总的探索中选出正确的方向并整合成型,正在成为最有价值的职业能力。
当所有人都在用AI做原型,文档反而更重要了
Andrew 对「PRD 已死,原型至上」这一流行口号持批判态度。他的逻辑是:既然 AI 让开发者快速交付任意媒介的原型,选择合适的媒介就变得前所未有的重要——不要因为「写文档太传统」就直接跳转原型。当目标是厘清一个模糊领域的产品方向时,文档比原型更合适;当目标是测试具体的交互模式时,原型才是正确选择。
Andrew 用「原始印记」的概念解释了其中的风险:设计师在一幅画上落下的第一个笔触会影响后续所有决策。过度粉饰的原型看起来已经可以上线,但团队可能还处在"90 个并行探索"的早期设计阶段——两者之间存在严重的信号错配。关键不是废除文档,而是让团队清楚地知道当前在流程中的位置——是在探索还是在交付。
为什么AI在「好设计」上仍然很差
Andrew 指出几个深层原因:设计不像代码有编译器或单元测试来客观判定好坏——人类的品味是必需的反馈机制,这让训练循环更困难。前几代的 AI 实验室天然倾向于投资能加速 AI 研究的领域(如编码能力),而非加速设计——编码对研究的飞轮效应远大于设计。
更本质的问题在于:设计要求的创新性与文化相关性,与 AI 擅长复现已知模式的特性存在冲突。当所有新网站都模仿 Linear 风格的时期,如果模型输出 Linear 风格的页面,你无法判断它是「好设计」还是「没有原创性」。此外,设计在代码层面上存在深层的抽象关系——视觉元素与代码组件之间的语义连接、品牌变更对整个组件系统的连锁影响——这些抽象层在当前技术下仍然难以触及。
Codex团队的区域联防:角色消融与保留的边界
Andrew 用「区域联防」来描述 Codex 的产品管理模式:产品负责人之间有意保持间距(「两个产品人贴得太近往往不是好信号」),通过拉开覆盖范围来保证公司各个业务面有人照应。同时,他在回答「角色是否会消失」时展现了清醒的立场——不要因为 AI 让写代码变得容易就认为产品角色应该被取消。
「我看到很多公司说,我们取消产品角色,大家都当 builder——然后发生的是整个产品学科所有积累的最佳实践、失败模式都被直接抛弃了。」Andrew 认为一个平衡点更为合理:角色不是消失,而是重叠度变高了。团队中每个人的角色不再是岗位边界,而是他们时间投入的重心分布——「如果你画一张图,我们设计师做的事中代码和产品工作占了不少,但重心仍然在设计的坐标上。」管理者不会消失,但 IC 与管理的界线也在模糊——IC 不再逐字敲代码,而是在管理代理、管理工作流。
同一款App,三个月延迟决定生死
一个值得产品团队深挖的案例:Codex App 在 2025 年 11 月已经具备了后来 2 月发布的全部产品形态,但 Andrew 自信地判断——如果当时发布,绝对会在市场上失败。唯一变量是底层模型在三个月间的能力跃升。相同的产品设计、相同的交互方式,只是因为模型变聪明了,结果就从失败变成了 500 万周活。
这一观察塑造了 Codex 团队的产品规划方法论:列出未来一两年想做的所有功能 → 全部做成原型 → 模型能力达标的立即上架 → 没达标的放下 → 每次模型跃进后重新尝试。这种模式下,功能的成败不是它本身好不好,而是它和模型能力的时间匹配。Andrew 将此称为「不要做太 AGI-pilled」——在算力还没到的时候,过早推出过于宏大的功能形态会重蹈 Codex 网页版的覆辙(代理式任务提交,听起来很理想但当时的模型做不到)。
Andrew如何用Codex自动化自己的工作流
Andrew 描述的自己的 Codex 使用方式实际上展示了一个正被广泛复制的模式。他的角色已经从一个带着开发者写代码的产品负责人,转变为一个「不断让 Codex 学会做自己新工作」的循环:需要招聘时,就让 Codex 帮忙做产品发现;需要协调多人时,就让 Codex 帮忙做状态追踪;需要管理发布时,就让 Codex 去读 Pull Request 和 Slack 消息,自动更新发布看板。
他每天早上会收到一份从 3000 多个 Slack 频道筛选出的个人简报,包含各项目动态、重点问题和需要他决策的事项。他可以在手机端回复「给我五个需要我决策的问题」,然后逐一回答,Codex 自动将回答分发给对应频道和线程。对于团队成员来说,这种模式意味着「我不用学怎么配置自动化——我只要在用 Codex 做事时跟它说‘下一次这样运行’,它就会自己迭代配置。」
一个具体的案例是 Andrew 用 Codex 搭建的垃圾邮件过滤器:他让 Codex 去 Google Cloud Console 配置 Pub/Sub 和触发接口。当 Codex 没有原生连接器时,它直接接管了 Andrew 的电脑屏幕,用计算机操作能力自己点进 Google Cloud 界面一步步配置完毕。
Codex的产品蓝图:大本营而非超级应用
Andrew 用一段 Premiere Pro 的故事回应了「Codex 是否想成为超级应用」的问题。Codex 团队有一位视频制作人需要用 Premiere Pro 剪辑视频——Codex 本身不是视频编辑器,但它通过操作 Premiere Pro 的底层文件和扩展接口,自己编写了一个 Premiere Pro 插件安装进去,然后通过插件与 Premiere Pro 双向通信。
这个故事定义了 Codex 的长期产品哲学:不是在一个窗口里包办所有功能(超级应用),而是成为协调专业工具的「工作大本营」。Codex 内置了电子表格编辑器,但微软 Excel 的高级用户——做几十亿融资模型的人——不会在上面做。所以 Codex 直接连接到你的桌面版 Excel——在 Codex 里跟它说「帮我做这个表格」,它打开 Excel 操作,完成后你关闭 Excel。同样模式适用于 VS Code、Slack、Chrome、Notion 等专业工具。
这产生了两种互补的交互模型:一种是「Codex 控制你的工具」(通过连接器或计算机操作),另一种是「把工具搬进 Codex 窗口」(通过内置浏览器让 AI 边看边操作)。Andrew 不认为这两者会二选一——它们会共存,取决于具体任务的颗粒度和安全性要求。
本文基于 Lenny's Podcast 对 Andrew Ambrosino 的深度访谈整理而成。