Peter Yang 的 Behind the Craft 节目，嘉宾是 OpenAI Codex 产品负责人 Alexander Embiricos（Alex）和开发者体验负责人 Romain Huet。Alex 此前有五年结对编程产品创业经验，Romain 曾在 Stripe 担任开发者平台产品负责人。
节目开场，Romain 做了一个实时演示：GPT-5.4 和 Codex Spark 并排运行，Spark 平均每秒 1200 token，当场创建 2D 游戏，几秒内响应”加点树木装饰”的需求。两种模型各有用法——GPT-5.4 扛百万行代码的分析或迁移，Spark 则在灵感涌现时快速迭代。他还演示了 plan mode（规划模式）：给 Codex 一个正在开发的 iOS 项目，不给具体指令，只说”下一步该做什么”，Codex 自动分析代码库现状，列出几个方向供选择。
Spec 只有 10 个要点
Codex 团队几乎不写产品规格文档。只有问题复杂到一个人脑子装不下、需要多人协调时才写，而且即使写了也短得惊人——往往只有 10 个要点，就这样了。
背后的逻辑是：既然大部分编码工作已经可以委派给 AI Agent，单个人能覆盖的范围就大了很多。核心原则是”让真正在干活的人做尽可能多的决策”。
PM 用 Codex 的三种模式
简单改动：直接提 PR。一个测试过的 PR 提出来，比找到对应工程师、让他们在一万件事里排优先级快得多。
中等复杂度：先让 Codex 做实现计划，再决定要不要自己接着做。
探索性思维：有模糊想法但没有具体功能时，直接在 Codex 里和模型对话，让它去代码库里探索、提问、生成方案。Alex 说他经常不会真的使用这些方案，因为改动太复杂，他不想自己维护。但走完这个过程之后，他对问题的理解深了，然后把这份理解——不是计划本身——分享给工程师。“我不是在写代码，我是在建立心智模型。”
Codex 团队的设计师现在写的代码量超过了六个月前一个工程师写的量，绝大多数代码由 AI Agent 生成。Alex 说现在已经不在乎这个了——问题不再是”能不能生成代码”，而是”选择做的事对不对”和”怎么保证质量”。
只做近期和远期规划，永远不做中期
OpenAI 内部研究员 Andre 给了 Alex 一个建议：要么做近期规划，要么做远期规划，但永远不要做中期规划。
近期是 8 周以内的具体目标，团队围绕它集中发力。远期是一种方向感——未来会有无限多个模型同时独立工作，自己验证结果、自己部署和监控，用户可能根本不需要主动输入提示词。中间那段？ 基本不存在。三个月后模型能做什么还不确定，中期路线图只是猜测。
从 18 个终端窗口到 Codex App
Codex 有两次明显的转折。2025 年 8 月推出 Codex Cloud 和 GPT-5，团队把精力集中在 CLI 和 IDE 扩展上，几个月增长了 20-30 倍。2025 年 12 月 GPT-5.2 Codex 发布，模型跨过了一个门槛——可以可靠地独立工作数小时甚至数天。用户开始用 tmux 并行运行大量会话，Peter Steinberger 在三块显示器上同时开了 18 个终端窗口的照片广为流传。
Alex 意识到只有顶尖 1% 的工程师会这样工作。团队内部有过争论——IDE 扩展已经很受欢迎，真的需要独立 app 吗？推动项目启动的不是 spec，而是一份说明”为什么做 app 是好主意”的文档，具体形态在构建中成形。技术上，App、IDE 扩展和 CLI 共用同一套开源 Rust 核心（Codex harness）。Codex App 于 2026 年 2 月发布，截至 3 月周活跃用户超过 200 万，Peter Steinberger 和 Greg Brockman 也把它作为主力工具。
开源产品哲学与团队运作
Codex 核心开源带来了一个独特效果：团队还没把某个功能上线到生产环境，推特上就有人在抱怨它不好用了——用户直接 fork 源码启用了未发布的功能。产品设计因此分三层：核心交互极简，让模型的能力自然显现；为 power user 做充分的可配置性；再从实际使用中提炼应该为所有人简化的功能。
Skills（技能插件）是这个分层最直接的体现。Figma Skill 可以直接拉取设计变量来写代码，部署到 Vercel 或 Cloudflare 只需一句话。Alex 讲了一个故事：一个朋友用 Linear Skill 让 Codex 把产品想法写成任务，睡觉前说”去把这些任务全部实现”，第二天醒来全部完成了。
团队刻意保持”海盗船”式运作——50-100 人长期只有一个 PM，跨职能协调极少，大部分功能来自工程师自下而上的提案。Romain 看到了更大的格局：他的团队把 Codex 定位为 OpenAI 整个开发者平台的入口，不只是编码工具。不管要接 Imagen、Sora 还是语音对话，都可以通过 Codex 加 Skill 完成。OpenAI 内部非技术团队也开始用 Codex App 做非编码工作，产品正从”开发者工具”向通用方向扩展。多个城市已经建立了 Codex 大使网络，由本地开发者自发组织活动和教学。
Peter Steinberger：从”永远不用”到主力工具
2025 年 10 月，Alex 和 Peter Steinberger（OpenClaw 创建者，2026 年 2 月加入 OpenAI）在旧金山 Fort Mason 散步，Alex 试探性地聊”某种让委派变得自然的新界面”。Peter 的反应是：他永远不会用这种东西。几个月后，Peter 在推特上说 Codex App “还不错”。
Romain 补充了更深层的观察。Peter 在 2025 年构建了超过 40 个开源项目，表面上零散——日历的 CLI、推特的 CLI、Gmail 的 CLI——但每一个都指向同一个方向：为日常数字工具构建命令行接口，让编码 Agent 不只写代码，而是能操控一切工具。这些项目共同奠定了 Codex Skills 生态和个人 Agent 概念的基础。Peter 在 OpenAI 具体做什么没透露太多，Alex 只说他在帮助构建”下一代个人 Agent，整合到 ChatGPT 中”。
PM 是填空岗位，不是领导岗位
Peter Yang 直接问：我们还需要 PM 吗？
Alex 说 PM 不是领导岗位，是填补空缺的岗位。AI 工具让每个人都能做一部分别人的工作；工程师以前没时间做项目管理，是因为要集中精力写代码；现在写代码可以委派给 Agent，工程师有了更多时间。Scott Belsky（Adobe 首席战略官）提出的”人才栈压缩”（collapsing the talent stack）正在发生。“做任何事情所需的人越少，那件事就做得越好。每个决策都更纯粹。”
本来就更想做工程师、只是因为管理能力不错才做了 PM 的人，现在可以直接转。如果真正感兴趣的是花大量时间和用户在一起、理解市场走向，那 PM 可能还有空间。每个问题都需要一个负责的人，但不一定得叫 PM。
Stripe 做到了 250 名员工零 PM——他们全是工程师，在构建自己一直想要的 API，每个人都知道优雅的 API 长什么样。PM 需求的多少和你离用户的距离有关。如果你就是自己产品的用户，PM 的价值自然会低。Codex 团队就在这个位置上。
招聘：给我看你做了什么
Alex 的招聘标准就一个词：能动性（agency）。入职没有递增难度的任务列表，就是一句”欢迎”，然后自己找事做。他要的是那种会主动发现问题、不介意推翻现有决策、愿意接手任何未知领域的人。
看求职信息时，优先看链接和想法，简历大概率不读完。他说完全不知道团队成员是什么学校毕业的。“管它什么学校，给我看你做了什么。”
Codex 团队这套极简方式——几乎不写 spec、50 人团队一个 PM、海盗船式运作——建立在一个特殊条件上：他们是自己产品的用户，他们的用户也是开发者，同时有一个极度活跃的开源社区持续反馈。当 Codex 的野心扩展到”把编码 Agent 带给 ChatGPT 的 9 亿用户”时，这套方法在面对不熟悉的用户群体时能否继续有效，值得持续观察。