OpenAI’s Plan to Make ChatGPT the Everything App — Akshay Nathan, OpenAI

OpenAI 的 Akshay 透露：ChatGPT Work 和 Codex 其实共用一套底层引擎，区别只在界面和细节体验，普通人和开发者都能无缝切换用 AI 干活。

人人能造之后，稀缺的是品味

Akshay Nathan 是 OpenAI 核心产品工程负责人，领导生产力团队，2023 年加入 OpenAI。此前，他在 Airtable 工作，也创办过一家探索 AI 自动化测试的公司。他一路在做同一件事：把原本只有会写代码的人才能调用的能力，交给更多人。本期访谈谈的不是某个新功能，而是一个更棘手的问题：当“做出来”越来越便宜，团队究竟该如何找问题、做判断、衡量进展？

这期回答了 7 个问题：

1. 当代码不再稀缺，为什么好想法和品味会成为新瓶颈？
2. 为什么真正卡住智能体普及的，不是模型能力，而是用户不知道能让它做什么？
3. 同一套智能体能力，为什么不该被切成“开发者版”和“办公版”？
4. 网页为什么可能替代 PPT、Excel，成为团队协作的正式产物？
5. AI 会让产品经理、工程师和设计师消失，还是让每个人变成 T 型通才？
6. 管理者可以让 AI 参与绩效评估到什么程度，哪些判断绝不能外包？
7. 当代码提交、工单和 token 都不再代表产出，团队该如何判断真正的进展？

被问到 AI 让每个人都能构建之后，团队还会受什么限制时，Akshay 没有把答案放在模型速度、算力或招聘数量上。他说，人人都能把一个点子做成原型，不等于人人都有足够多值得推进的点子；更不等于能在多个可行方案里，判断哪个方向该继续投资源。"I think the bottleneck becomes like sort of like ideas and taste, I guess."（我觉得瓶颈会变成想法和品味之类的东西。）

他特别强调，产品想法不是漂在空中的灵感。它们通常来自用户访谈，来自人们在某一步卡住时暴露出的摩擦，来自反馈，也来自已有产品和已有假设的延伸。AI 可以很快给出十个界面方案、三种技术路径，甚至把其中一个直接做出来；但它不知道用户究竟在哪个环节失去耐心，也不知道某个看起来很小的抱怨，背后是否藏着一个高频、昂贵的问题。

这意味着，竞争从“谁能做出来”转向“谁能持续发现真实问题，并判断什么值得做”。品味在这里不是审美标签，而是一种筛选能力：知道什么该删，什么不该因为“能做”就做。边界也很清楚：模型擅长组合、展开和改写，但“给我新想法”不能脱离具体用户、具体摩擦和具体情境独立发生。没有一线反馈，生成再多方案，也可能只是更快地堆出一批无关紧要的东西。

被问到 ChatGPT Work 的产品合并决策从何而来时，Akshay 讲了一个内部 UX 研究中的发现。OpenAI 去和战略财务、市场等非开发岗位聊天，发现他们已经在使用 Codex。Codex 原本更接近开发者工具，却被这些人拿来做自己的工作任务。真正让他印象深刻的，不是“非开发者也会用”，而是这些人对自己属于早期使用者感到骄傲。

他们不是把它当作另一个聊天机器人，而是感觉自己突然能完成以前不会做、或要找别人做的事情。"they felt like they had a superpower right"（他们感觉自己拥有了一种超能力。） 这种感受来自任务的闭环：给智能体足够上下文，接上对应工具，再对过程进行监督，它就能执行多步工作。这里的智能体，指的是不只回答一句话，而是能调用工具、拆解步骤、持续执行的 AI。

Akshay 的判断是，真正懂得这种工作方式的早期采用者之外，还有大约大 10 倍或 100 倍的人群没有看见它的可能性。数以亿计的人会用 ChatGPT 提问，不代表他们知道可以让它查本地文件、连接工作工具、做一份可继续迭代的产物。这意味着，下一阶段不只是往功能列表上再加几项，而是让用户在自己的工作现场亲眼看到：“原来这件事也可以委派。”但门槛仍在：上下文该给什么、工具该怎么连、什么时候该人工接管，对更大人群都不直观。产品若只摆出能力，却不帮助人发现用法，超能力仍会停在少数人手里。

被追问 Codex 与 ChatGPT Work 是不同产品，还是只是界面不同的时候，Akshay 给出了一个很明确的答案：两者共享同一套 harness。harness 可以理解为智能体背后的“执行底盘”，负责把模型、工具、文件、插件、计算机操作和安全限制组织到一起。"the harness is the same the harness is shared."（这套底层运行框架是一样的，是共享的。）

这意味着，无论用户进入 Codex 还是 Work，都能拿到面向知识工作的插件、computer use，也就是让 AI 操作电脑环境的能力，以及 artifacts，也就是可保存、可继续修改的表格、网页、文档等产物。差别不在“谁配不配拥有能力”，而在界面如何呈现。例如让 AI 生成退休计算器表格时，Codex 模式会突出文件编辑记录和 spreadsheet 的 diff，即文件前后改动的对比；Work 模式则不会把这些细节直接摊给普通用户。

这背后是一种产品架构判断：能力层应该通用，界面层可以按任务的信息密度来调整，而不是按“开发者”与“非开发者”划死入口。因为一个做市场的人，可能今天要写活动方案，明天要改一个网页；一个工程师，也可能要做调研、写策略材料。边界在于，统一能力不等于统一界面。Git repo 状态、代码 diff、沙箱设置对开发者是验证工具，对普通用户可能只是噪音；但如果把过程藏得过深，用户又无法确认 AI 是否做对了。真正困难的不是分产品，而是决定哪些细节该露出来，哪些应留在底层。

被问到除了 Excel、PowerPoint 和 Docs 外，未来工作还会采用哪些格式时，Akshay 把重点放到了 Sites。这里的 Site 不是单纯的宣传页，而是一个由 HTML 构成、可以承载互动逻辑的网页式产物。OpenAI 的模型选择 slider，几乎完全是在一个 Site 里由设计、工程和产品协作开发出来的：团队可以直接在同一处调整交互、观察效果，而不是在设计稿、说明文档和代码之间来回转述。

他还提到，公司财务团队过去每月协作的报告，原本放在幻灯片和电子表格中，现在已经直接放到 Sites 里。"historically those things were in in slide decks and in spreadsheets and now they're just in sites."（过去这些东西放在幻灯片和电子表格里，现在它们直接就是网站。） 这个变化的要点不只是“网页更漂亮”。PPT 擅长线性讲述，Excel 擅长表格计算，但当一个报告既要显示重点、又要展开数据、还要让不同角色各取所需时，静态文件的层级很快不够用。

这意味着，协作的终点会从“发一个文件给别人”变成“维护一个可交互、可迭代、能直接运行逻辑的共享界面”。HTML 的灵活性让团队可以把最重要的信息放到首屏，把细节折叠到后面，把筛选、计算和解释放在同一处。不过 Akshay 也泼了盆冷水：Sites 仍需要解决多人协作体验，以及产物太长、太冗杂、难以拆分的问题。网页能装下更多东西，也更容易把所有东西都装进去，最后变成一条没人愿意滚到底的长页面。

被问到 AI 前后理想团队的角色分工发生了什么变化时，Akshay 观察到，工程经理、产品经理、工程师和设计师之间的传统边界正在变模糊。他拿自己举例：以前他做不了设计，现在可以借助 AI 快速生成方案、不断迭代、比较不同选择。但他没有因此宣称自己变成了设计师，反而明确承认，自己未必有真正的视觉品味。

他的判断是，未来每个人都会更像 T 型人才。T 型的横线是广度：借助 AI，工程师可以理解产品和设计，产品经理可以做出原型，设计师可以尝试数据和交互逻辑；竖线则是深度：每个人仍要在真正感兴趣、长期投入的领域里形成专业判断。"everyone will be like T-shaped in a way"（每个人都会在某种意义上变成 T 型人才。）

这意味着，组织不会简单变成“一个全能员工替代一个团队”。AI 的作用更像给每个人多了一套可调用的手脚，让人能更完整地走完从想法到验证的闭环。招聘和协作也会更看重跨职能完成任务的能力：你能否把问题说清、做出可测试的东西、拿到反馈并据此调整。但专业深度仍是质量的上限。AI 可以帮人生成四套界面，却不能自动告诉人哪一套符合品牌、用户习惯和信息优先级；它能写代码，也不能替代对系统风险的判断。“会做”与“做得好”之间，仍隔着领域知识和长期训练。

被追问能否用 AI 撰写员工绩效评估、以及这会不会显得不在乎员工时，Akshay 先讲了一个时间差很短、结果却很明显的经历。在 OpenAI 的绩效评估周期中，他尝试让模型汇集一个人做过的工作，包括代码、评审和 Slack 信息，寻找管理者可能遗漏的贡献。六个月前的上一次周期，他已经试过类似做法，当时的结果是“not at all helpful”；这一次，他觉得“incredibly helpful”。

变化不只是模型写得更顺，而是它能从大量分散记录中找回人脑容易漏掉的证据：某次代码评审避免了什么问题，某条讨论推动了什么决定，某个不显眼的贡献如何影响了团队节奏。但 Akshay 给出的底线没有模糊空间。"I would never write something via like only via AI and like present it as like a review for someone."（我绝不会只靠 AI 写一份东西，然后把它当作对某个人的正式评估交出去。）

这意味着，AI 可以把管理者从“靠记忆翻贡献”中解放出来，却不能替他承担评价责任。绩效评估不只是信息检索，它还包含对贡献的理解、对成长的反馈，以及管理者愿意署名负责的判断。模型可能找不到某段关键合作，也可能误判一件事的重要性；更重要的是，员工需要的不是一份检索报告，而是有人认真理解其工作。合理的分工是：让 AI 扩大证据覆盖面，让人完成解释、取舍和沟通。

被问到生产力团队如何定义和衡量 leverage，也就是 AI 到底是否让人获得了更多实际能力时，Akshay 的回答很坦白。真正该衡量的，是用户有没有达成自己的目标；但每个人的目标都不同，而且系统通常不知道用户一开始到底想完成什么。"I think we haven't figured this out yet."（我觉得我们还没有把这件事弄明白。）

这不是 OpenAI 独有的难题。以 ChatGPT 的点赞和点踩为例，一个点踩究竟代表什么？可能是答案内容错了，可能是语气不对，也可能答案本身不错，但没有帮助用户完成真正的任务。一个按钮把这些不同情况压成同一个信号，产品团队很难据此判断“生产力提升了没有”。同样的问题也会出现在企业内部：某人用了更多 token，做了更多 AI 生成内容，或打开产品次数更多，都不等于他离目标更近。

这意味着，AI 产品和管理系统会越来越难依赖统一使用量指标。过去，使用时长、功能点击、满意度反馈还能勉强作代理；现在，AI 既能让人十分钟完成一件高价值工作，也能让人花三小时反复生成并不需要的内容。真正的评价方式必须更接近“意图—行动—结果”的链条：用户想实现什么，AI 帮他完成了哪一步，最后结果是否真的改善。难点也正因此变大：目标往往没有明确写出来，且每个人的目标、约束和成功标准都不同。

被要求给管理者一条可以立刻尝试的建议，并追问团队衡量生产力最常见的陷阱时，Akshay 把矛头指向了“代理指标”。过去，团队会看代码提交数、代码行数、工单完成数；进入 AI 时代后，人们又开始看 token 用量、pull request 数量。这些数字都容易获得，也都能画成上升的仪表盘，但它们与真正达成目标的相关性正在下降。

他的原话很直接。"I think maybe the trap is like conflating motion and progress."（我觉得陷阱可能在于，把行动量和进展混为一谈。） AI 让“行动量”变得异常便宜：代码可以批量生成，设计稿可以一小时出几十版，研究笔记可以自动汇总，任务看上去比以往推进得快得多。但如果团队没有事先说清要验证什么假设、服务什么用户目标、以什么结果判断成败，所有高频产出都可能只是在原地打转。

Akshay 给出的替代指标是 at-bats，可以理解成高质量的“完整回合”。不是只看团队提出了多少想法，或写了多少代码，而是看能否反复走完一整轮：提出想法，做出东西，获得反馈，验证或证伪假设，再进入下一轮。这要求工程、设计和规格产出更快，也要求团队有足够的谦逊，愿意承认假设错了后重来。边界在于，AI 不会自动带来这种闭环文化。它只会让团队更容易制造动作；没有明确的进展定义，动作越多，错觉可能越大。

“代码不再是瓶颈，真正稀缺的是想法与品味”和“AI 时代最危险的管理错觉，是把忙碌当成进展”，说的其实是同一件事：构建成本下降后，组织最容易误把产出能力当成判断能力。以前做一个原型要排期、找工程资源、等设计交付，资源稀缺迫使团队做筛选；现在，原型、页面、报告、代码都能快速生成，筛选反而更难了。

这也是为什么“知识工作的正式产物，正从文档变成可运行的网站”不只是格式变化。产物越容易做成、越容易分享，就越需要它服务于真正的协作和验证，而不是成为更精美的汇报材料。为什么“AI 可以帮管理者找全证据，却不能替管理者对人下判断”也同样重要：检索和生成可以外包，承担解释与责任不行。

对读者来说，最现实的问题不是“我要不要用 AI”，而是每次让它替你生成内容、写代码、做分析之后，是否更接近一个可验证的结果。你是否接触到了真实用户？是否明确了成功标准？是否愿意让反馈推翻原来的判断？当人人都能造，拉开差距的不是谁的界面里多了几个按钮，而是谁能把更快的构建速度，接到更真实的问题和更短的验证闭环上。