Codex Team — Product Methodology
来源：Alexander Embiricos & Romain Huet (OpenAI)，访谈，2026-04-06
惊人的数字
- 产品规格文档只有 10 个要点 — 整个产品的 spec，不是单个功能
- 设计师写的代码量超过六个月前工程师写的
- 50-100 人的团队，长期只有一个 PM（直到最近才有第二个）
10 个要点就够了
Codex 团队几乎不写产品规格文档。只有问题复杂到一个人脑子装不下、需要多人协调时才写。
而且即使写了，也就十来个要点。
逻辑：既然大部分编码工作可以委派给 AI Agent，一个人能处理的范围就大了很多。过去需要三个人协调的事情，现在一个人用 Codex 就能探索清楚。
"让离金属最近的人做尽可能多的决策"
PM 用 AI 做"思维探索"
Alex 描述了自己作为 PM 使用 Codex 的三种模式：
- 简单改动直接上手 — 用 Codex 生成代码、测试、提交 PR
- 中等复杂度的改动 — 让 Codex 先做一个实现计划
- 模糊想法探索 — 连具体功能都没想好，直接在 Codex 里和模型对话，让它去代码库里探索、提问、生成方案
"我不是在写代码，我是在建立心智模型。"
然后把这份理解（而非计划本身）分享给工程师。
只做近期和远期规划，永远不做中期
近期：8 周以内，具体目标，团队能够围绕它集中发力。
远期：一种"感觉"。比如：一年后会有更聪明的模型，用户可能根本不需要主动输入提示词。
中期路线图？基本不存在。
"在 OpenAI，你要么做近期规划，要么做远期规划，但永远不要做中期规划。"
前提：模型能力在快速变化。当你不确定三个月后模型能做什么，中期路线图就变成了猜测。
规划哲学的前提追问
如果模型进展放缓了呢？
关联
- product-trends/overview — Product Trends 总览
- product-trends/saas-vs-agent-native — Linear 的类似实践
- claude-code/overview — Codex 作为工具