Codex 团队的产品 spec 只有 10 个要点。不是每个功能的文档，是整个产品的 spec。设计师写的代码量超过了六个月前一个工程师写的。50-100 人的团队，直到最近才有了第二个产品经理。

这些数字来自 OpenAI Codex 产品负责人 Alexander Embiricos 和开发者体验负责人 Romain Huet，两人接受 Peter Yang 主持的 Behind the Craft 节目采访，讲述了 Codex 团队如何用自己的产品构建产品。

10 个要点的 spec

Codex 团队几乎不写产品规格文档。只有在问题复杂到一个人脑子装不下、需要多人协调的时候才会写。即使写了，也短得惊人。

我们在 Codex 团队写的 spec 非常非常少。就算写，也就十来个要点，就这样了。

背后的逻辑：大部分编码工作已经可以委派给 AI Agent，一个人能处理的范围大了很多。过去需要三个人协调的事情，现在一个人用 Codex 就能探索清楚。"让离金属最近的人做尽可能多的决策"是核心原则。

OpenAI 的规划哲学

Alex 引用了 OpenAI 内部研究员的建议：

在 OpenAI，你要么做近期规划，要么做远期规划，但永远不要做中期规划。

近期 = 8 周以内，具体的目标，团队能围绕它集中发力。远期 = 一种"感觉"，比如一年后模型会更聪明，会有无限多个模型同时独立工作，用户可能根本不需要主动输入提示词。

中间那段呢？产品路线图？基本不存在。

设计师写代码，PM 提交 PR

Codex 团队的设计师现在写的代码量，超过了六个月前一个工程师写的代码量。

团队成员拿 Alex 提交的 PR 数量开玩笑，他没有透露具体数字，只说"确实应该更多"。但他认为这已经不是重点。关键问题不再是"你能不能生成代码"，而是"你选择做的事情对不对"和"你怎么保证质量"。

Alex 描述了自己作为 PM 使用 Codex 的三种模式：

  • 简单改动：直接用 Codex 生成代码、测试、提交 PR
  • 中等复杂度：让 Codex 先做实现计划
  • 模糊想法：直接在 Codex 里和模型对话，让它探索代码库、生成方案，他经常不会真的使用这些方案，但通过这个过程建立对问题的理解

用他自己的话说："我不是在写代码，我是在建立心智模型。"

50-100 人团队只有一个 PM

团队刻意保持低摩擦运作，"有意识地像一支海盗船"，跨职能协调极少。大部分人是工程师，汇报结构极简。

Alex 的 PM 使用模式：

  • 执行模式：产品发布前，大量使用 Codex 了解反馈、让 Codex 总结并发到 Linear、直接用 Codex 提交代码改动。判断标志是他在推特上发了多少东西——发得多 = 在发布节奏里。
  • 协调模式：规划新方向时，花更多时间思考和沟通，用 Codex 更多是做文字工作而非写代码。

PM 是填空岗位，不是领导岗位

最有争议的观点。Alex 的原话：

我其实不认为 PM 是一个好的领导岗位。我觉得它是一个填补空缺的岗位。

他的推理：AI 工具让每个人都能做一部分别人的工作。Scott Belsky 提出的"人才栈压缩"正在发生——一个人覆盖多个角色，比增加协调人员更有效。

做任何事情所需的人越少，那件事就做得越好。每个决策都更纯粹。

但他做了一个细分：如果你一直想做工程师，现在有了编码 Agent，你可以直接把自己从 PM 岗位上删掉，转做工程师。但如果你真正感兴趣的是花大量时间和用户在一起、理解市场走向，那 PM 可能还有存在的空间。

Romain 补充了 Stripe 的例子：在没有任何 AI 工具的情况下，250 名员工做到了零 PM。因为他们全都是工程师，都在构建自己一直想要的那种 API，每个人都知道一个优雅的 API 长什么样。

能动性是最重要的招聘标准

Alex 的标准只有一个词：能动性（agency）。

团队入职没有递增难度的任务列表，就是一句"欢迎"，然后自己找事做。他要的是那种会主动发现问题、不介意推翻现有决策、愿意接手任何未知领域的人。

我很高兴我们生活在一个那些愚蠢的证书不再重要的世界里。管它什么学校呢。给我看你做了什么。