Akshay Nathan¶
- 背景: OpenAI 核心产品工程负责人，带 productivity 团队（ChatGPT Work / Codex）。2023 年加入 OpenAI（当时公司约 500 人），此前做消费金融科技、创业做 AI 自动化测试（在 LLM 与视觉 LLM 之前）、在 Airtable 做 no-code。做过 ChatGPT Enterprise（视频页 [00:01:01]–[00:04:02]）。
- 本库定位: 第一份来自 OpenAI 产品侧（而非研究侧）的系统表达。价值集中在两处：harness 合并的产品论证，以及AI 时代生产力为什么变得无法测量。
核心观点¶
harness：Codex 的壳吃掉了 ChatGPT 的壳¶
- ChatGPT Work 与 Codex 共用同一个 harness，差别只在 UX 取舍与沙箱默认值（[00:11:04]）。产品原则："不希望用户被困在某个 tab 或某种体验里而拿不到产品的全部能力"（[00:10:04]）。
- 他给 harness 演化的模型是"发散、收敛、发散、收敛"（[00:16:10]）：chat 侧长期优化延迟与人格；Codex 侧学到的是"给 agent 一个无限灵活的环境——一台计算机——它能做到非常强大的事"，面向知识工作时把它带进计算机环境更自然，再把细节抽象掉。
- ⚠️ 不认为这是终局："我们希望能力在所有地方都在……以后肯定还有工作要让各场景能力等同。"（[00:17:11]）经典 ChatGPT harness 仍在，由模型做路由决策（[00:15:09]）。
为什么合并：职能边界正在模糊¶
（[00:13:07]–[00:14:07]）"我们所有人的工作都在因为 AI 剧烈变化，几乎每几个月一变。"因此按"你是谁"划硬边界会失效——只写代码的、写战略文档的、做市场的、办活动的之间界线会被模糊。结论：让用户自己选，但不要把用户框死；工程上保持原语统一（plugins 跨 ChatGPT / Work / 云端统一）。
Codex 品牌会长期保留并继续针对软件开发优化；合并反而提升其效用（[00:44:27]–[00:45:28]）。
默认值与模型选择¶
- "我们希望对默认值有主见……默认就该对绝大多数用例是最好的。"高级用户有旋钮，"可以说现在旋钮可能太多了，我们正在简化"（[00:18:11]–[00:19:11]）。
- 使用准则：ultra / 多 agent 适合极复杂开放探索或高度可并行的任务；goal 模式适合"能随时间取得可验证的一致进展"的任务；但大多数任务两者都不属于（[00:20:11]）。
- ⚠️ Ultra 发布后被回退了默认值：发布时"我们对 Ultra 是给谁用的没有足够主见"，之后改为需手动开启并移入高级设置（[00:55:32]）。本库中罕见的、来自前沿实验室的明确产品回退承认。
Sites 是被低估的那一个¶
（[00:26:12]–[00:27:12]）外界主要把 Sites 当原型工具，但另一面是 site 作为知识工作的 artifact——公司财务团队的月度报告已从幻灯片和表格搬到 site 上。理由是带宽更高：PowerPoint 和 Excel 无限灵活，但总会撞到"人不会用某功能"或"产品不支持"的边界，而 site 里你想要什么就能要到什么。
对 agentic Excel，他的框定值得记：不是"你不再需要 Excel 授权"，而是"这是第一阶段"——重点是迭代，高保真呈现同事将看到的样子才让人敢信任这个迭代（[00:23:12]）。
术语现实：artifacts 是内部叫法，外部没人这么说——"如果 ChatGPT Work 擅长做幻灯片，他们就说它擅长做幻灯片，而这正是我们想要的"（[00:45:28]）。
与 OpenClaw 的关系¶
- 他有自己的 OpenClaw 时刻（和配偶用它管家务、接日历），承认 ChatGPT Work 的持久计算机环境受其启发；团队有成员已把过去用 OpenClaw 做的事完全转过来，因为原语一样：定时任务、文件系统、跨时间引用（[00:46:28]–[00:47:28]）。
- ⚠️ 他明确不认为会取代 OpenClaw："我不这么认为……那个团队做出来的这种了不起的开源技术永远有其需求。"（[00:47:28]）
记忆¶
- "和朋友、家人聊他们喜欢 ChatGPT 什么，'它了解我'、'我的 ChatGPT 是我的' 大概排第一。"（[00:56:33]）
- ChatGPT Work / 云端默认继承 ChatGPT 记忆并可写回，同属 memory V3（[00:56:33]）。
- 他反驳"work 场景记忆与 chat 根本不同"这一前提：chat 里大量一次性对话"长期累积起来相当耐久，是对我这个人相当好的表征"（[00:58:35]）。
- Chronicle（从你如何使用计算机中学习）目前实验性、默认关闭；他的价值定位很克制——它未必捕捉你全部意图，"但它多半会发现一些你自己都不知道的东西"（[00:59:36]–[01:00:37]）。
⚠️ 组织与生产力度量（他最有转述价值的一段）¶
- T 型："AI 会让每个人都成为通才"，同时保留一条向下深挖的专长竖线（[01:03:39]）。EM / PM / 工程师 / 设计师的界线在模糊（[01:02:38]）。
- 瓶颈变成想法与品味："因为现在人人都能造……你永远会被你在任一时刻拥有的想法数量卡住。"（[01:04:39]）
- 但想法不能被模型自动化——它们不在真空里产生，来自和用户对话、来自你看到的摩擦与反馈，"所以那种能闭环、能把想法扎根在反馈里的通才，永远有价值"（[01:05:39]）。
- 团队不会变小："个人或小团队能完成过去需要更多人的事，但同时要做的事也更多了，所以团队变得更有野心。"（[01:02:38]）
- 生产力度量：他明说没解决（[01:06:39]–[01:07:40]）——"我们还没想明白"；点赞点踩没用（分不清踩的是内容、语气还是目标达成）；旧代理指标正在失效（代码行数、story point、PR 数、token 用量已不再强相关于目标达成），"而且整个行业都得想明白这件事"。
- 给管理者的建议：看 at-bats——不只数量还要质量，能否高效走完"想法 → 造 → 反馈 → 反应 → 证实/证伪 → 下一个"的整环，并包含团队文化（谦逊、反复走这个过程还保持动力）（[01:08:41]）。
- 最锋利的一句（[01:09:42]）：
"陷阱大概是混淆 motion 与 progress。因为有了这些工具，motion 比以往任何时候都容易；但 progress 要求你对自己到底想达成什么非常明确、非常刻意。"
企业落地¶
- "企业里没有一刀切的方案"；问"具体想解决哪个用例"时答案方差爆炸（[00:04:02]）。
- 对这个 box 的诊断："你有一个盒子，可以对它说任何话，这是魔力；但反过来也意味着你不知道该拿它做什么。"（[00:05:02]）
- 早期采用者"真的懂"，但还有大 10–100 倍的市场尚未理解（[00:06:02]）。
- 方法论是 show, don't tell——"我们还没完全破解如何展示而不是教"（[00:34:20]）。
- 采用序列：开发者 → 通用知识工作 → 所有人（[00:35:22]–[00:37:23]）。
- ⚠️ 他给高级用户的建议里划了一条清楚的线：用 AI 收集上下文做绩效评估是可以的（模型能拉到代码、评审、Slack 的全部上下文），"但我绝不会只用 AI 写出一份东西然后当作对某人的评估交上去"（[00:39:23]–[00:40:24]）。swyx 归纳为 agentic search，他接受。
呼应与分歧¶
- 与 swyx 反对模型路由的立场：swyx 反对跨厂商路由；OpenAI 的做法是由模型自己在同厂商内做模式路由，与 swyx 那句"人们不想选用哪版 AGI"一致——不是同一层的路由，但都把"用哪个能力"的决定权交给模型。
- LLM OS 的产品化实证：持久计算机环境 + 文件系统 + 定时任务 + plugin，几乎逐项对上 Karpathy 的 LLM OS 清单；但他自己的参照系是 OpenClaw 而非操作系统。
- "瓶颈是想法与品味" 与本库 AI 与就业 的 T 型/通才叙事同族，但他补的限定是关键约束：想法不在真空里产生。
- "混淆 motion 与 progress" 是本库对"企业买了 AI 却没变化"最简洁的诊断，与 Sinofsky 的例外处理、Mark Cuban 谈企业落地难 属同族不同切面。
- "旧代理指标正在失效" 给 评估与 Benchmark 补了组织侧：不是模型怎么被评测，而是用模型的人怎么被评测，且新度量尚不存在。
- 记忆：与 Dan Biderman 谈长上下文为何不够 对读——那边讲机制，这边讲产品两难（知道你的事 vs. 有 EQ 在对的时机提起）。
已收录¶
| 日期 | 视频 | 场合 |
|---|---|---|
| 2026-07-28 | OpenAI 把 ChatGPT 做成"万物应用" | Latent Space，swyx + Vibhu 主持 |