ChatGPT Work 与 Codex 产品负责人 Tara Seshan：当智能体成为持久在线的同事，我们该如何与它协作？
聊天解决一轮问题，智能体完成一次任务，下一阶段的 AI 会跨时间保持上下文、持续执行并进入多人协作。OpenAI 产品负责人 Tara Seshan 解释了这套工作关系需要什么，以及人的责任会怎样上移。
- 聊天解决一轮问题，智能体完成一次任务，持久在线同事跨时间保持上下文、持续执行并接受多人干预。
- 持久工作依赖运行环境、数据、权限、可靠性和协作界面，模型能力只占其中一层。
- 执行成本下降后，人的职责上移到方向、品味、表达、问责、关系和提高团队目标。
- 知识工作必须检查背景、输入、引用、过程和最终结论；思考型写作仍应由人开始并收尾。
Lenny Rachitsky 主持的产品播客 Lenny’s Podcast 邀请 OpenAI ChatGPT Work 与 Codex 产品负责人 Tara Seshan，解释 AI 智能体怎样从一次性工具变成长时间协作的工作伙伴。
嘉宾背景： Tara Seshan 在 OpenAI 同时负责 Codex 和 ChatGPT Work 的产品工作；加入 OpenAI 前，她在 Stripe 工作六年，是公司最早五位产品经理之一，后来负责气候软件公司 Watershed 的产品，也曾创业、入选 Thiel Fellowship，并在 Sutter Hill Ventures 担任驻场创业者。
这期节目围绕一个问题展开：当 AI 不再只回答问题或完成一次任务，而能在后台持续工作、带着项目上下文回来交付，并允许人随时纠偏，它会怎样改变产品设计、组织分工和个人能力？Tara 把模型、运行环境、权限、协作界面和人的责任放进同一个框架，解释一位 AI 同事怎样从“能做”走到“能长期共同负责”。
这期节目给出的四个答案：
- 产品形态：AI 正从一轮聊天、一次任务，走向跨时间保持上下文、持续执行并接受多人干预的工作伙伴。
- 产品方法：前沿团队不能只适配今天的模型；OpenAI 用两三个月作为产品与研究能力交汇的工作窗口，并用可运行原型快速验证判断。
- 人的工作：执行被智能体接手后，人的职责上移到方向、品味、表达、问责、关系和提高团队目标。
- 验收边界：知识工作不能像代码一样主要依靠测试；可靠的 AI 同事必须让人检查输入、来源、过程、中间产物和最终结论。
持久在线 AI 同事，与聊天和一次性智能体有什么不同
Tara 用三个阶段区分不同的工作关系：一轮问答、一次任务和一个持续项目。它们可以同时存在，差别在于 AI 能否跨时间保留上下文、继续执行、接受人的检查与纠偏，并进入多人共同工作的空间。下面的交互图把三种关系放在同一组维度中；点击阶段即可比较时间单位、上下文、人的介入方式和协作范围。
从一次回答，走向一段持续协作
点击阶段，聚焦 AI 行为与人的职责
“持久”因此至少包含五个条件：
- 可持续的运行环境。 任务能在本地或云端继续，不因一次聊天结束而停止。
- 可用的项目上下文。 它能读取文件、历史决定、数据和必要的业务背景。
- 受控的权限。 邮件、文档、代码库、财务系统各自有明确的访问边界。
- 足够的可靠性。 长任务失败后可以恢复，关键动作可检查，结果能够追溯。
- 协作界面。 人能看到进度、在中途介入，并把另一位同事带进同一项工作。
Tara 特别强调这些“朴素”的基础设施。只提高模型智能，仍会得到一个聪明却没有电脑、没有资料、不能稳定交付的临时帮手。OpenAI 对 ChatGPT Work 的产品定位也包括跨应用与文件工作、数小时持续执行和从目标走到成品，并说明其中采用了 Codex 的技术基础。OpenAI 产品发布
ChatGPT Work 与 Codex：同一套执行能力，不同的工作入口
访谈录制时，用户会看到多个名字：ChatGPT 的 Chat、Work，以及独立的 Codex。Tara 的解释很直接：这些入口首先服务于不同用户的熟悉程度。
| 入口 | 当前更适合的任务 | 界面重点 |
|---|---|---|
| Chat | 对话、搜索、解释和快速问答 | 保持聊天的轻量体验 |
| Work | 财务模型、研究、演示、网站等长时知识工作 | 展示任务进展和成品，隐藏工作树等开发者概念 |
| Codex | 软件开发及需要技术细节的复杂任务 | 暴露代码、终端、文件和更完整的执行过程 |
Work 底层使用 Codex 的执行能力。按照 Tara 的说法，让 Codex 做财务模型并不会天然弱于 Work；差别主要在产品给用户看哪些细节。OpenAI 帮助中心也把 Chat、Work 与 Codex 作为不同工作方式说明，而长期方向是降低用户选择负担。OpenAI 帮助中心
终点并不是让十亿级用户学会什么是模型、harness 或工作树。用户只需描述目标，系统选择合适的模型、工具和执行环境，并根据任务呈现合适的控制面板。多个入口是过渡期的产品安排，不是理想状态下永久增加的认知负担。
从划船到掌舵：人与 AI 应该怎样分工
Tara 用“从划船到掌舵”描述产品经理的变化。划船是亲自推动每一个执行动作；掌舵是决定去哪、为什么去、怎样判断偏航，以及什么时候应该改变路线。
智能体能写代码、做研究、生成模型、搭页面后，工程、产品和设计的边界会变薄。一个人可以跨过过去的专业分工完成更多环节。边界变薄不等于责任消失。团队仍需要明确的人回答三类问题：这个产品有人需要吗？质量达到要求了吗？最后的结果由谁承担？
角色边界变薄也会抽象掉旧专业技艺的一部分。Tara 没有给出轻松答案：产品经理可能不再亲手打磨某些传统工作，工程师也会怀念手写代码时的心流。新的专业能力会从完成某个具体动作，迁到选择问题、编排工具、判断质量和承担结果；如何在跨职能效率与持续精进本专业之间保持平衡，仍是一个开放问题。
当同一团队的每个人都能调用相近的模型和工具，差异更多来自以下能力：
- 方向。 选择哪个问题值得解决，拒绝哪些看似能做但没有价值的任务。
- 品味。 判断什么样的体验、表达和细节构成完整作品。Tara 把软件类比为电影：更大的预算不会自动产生更好的影片。
- 表达。 把模糊感受变成清晰主张，让别人能理解、质疑并共同修改。
- 问责。 对结果的正确性、影响和后续行动负责，不把失败归给模型。
- 关系。 让团队成员彼此信任、共同学习，并愿意把目标提高。
最后一项是 Tara 反复谈到的 ambition。许多团队把 AI 用在自动化旧任务：更快写周报、更快做一份原来就会做的分析。她观察到的高水平用户会重新估计项目规模：一个人能否完成过去需要一个小团队的产品？团队能否把几个月的探索压到几周，并把省下来的执行力投入更大的问题？
这不是要求所有工作无限加速。它指出一个新的约束：当执行成本下降，组织的上限会越来越受“我们认为自己能做什么”影响。PM 的一部分工作，也从催进度转向提高团队对可实现目标的判断。
面对快速进化的模型，OpenAI 如何提前设计产品
传统软件把底层能力视为相对稳定的约束。团队知道数据库、浏览器和设备大致能做什么，然后在这些边界内优化功能。前沿 AI 产品面对的是一块持续移动的地面：今天不可靠的动作，几周后可能变得可用；今天围绕局限设计的补丁，产品上线时可能已经成为累赘。
Tara 给出的内部工作窗口是两到三个月。
- 只围绕当前模型设计，团队往往在它“刚好能做”的位置投入大量工程。等产品上线，更强模型已经把这部分难题吃掉。
- 为一年后的能力设计，假设太远，无法用真实模型和用户行为验证，容易把愿景当成事实。
- 两三个月允许产品团队参考研究路线图，提前准备新的交互和执行框架，同时仍能快速拿到可观察的反馈。
过短会过时，过长无法验证
选择时间窗，查看风险、证据与决策
今天 只围绕当前模型设计，容易为即将消失的局限投入过多。
两三个月 OpenAI 用这个窗口连接研究路线、内部模型和可观察的产品试验。
一年以后 可以探索方向，但很难及时用真实模型和用户行为校正。
这套时间窗不能机械套用到所有公司。OpenAI 能直接接触模型研究路线图，也能高频使用内部版本；外部团队没有同等信息。可迁移的方法，是把产品判断写成可被推翻的假设，然后尽快制造证据。
Tara 借用 Coda 联合创始人 Shishir Mehrotra 的“eigenquestion”概念：先找到能让大量后续问题同时变清楚的那个问题。接着制作原型、让人实际使用、观察行为，再修改假设。产品经理过去可能花几周写一份完整方案；现在更有效的沟通物往往是一个能试的 mock、一个能跑的 prototype，或者一组已经得到的实验结果。
这也解释了 OpenAI 的速度。访谈里没有“秘密战略文档”统领一切。团队成员被要求像创始人一样发现问题，持续使用自己做的产品，把内部体验和公开市场反馈接成短循环。这种速度来自更快地把不确定判断变成可检查的现实，同时保留质量控制。
这种速度带着明确的取舍。Tara 说，过去的软件团队往往会等每个交互都充分抛光后再发布；在模型和用户习惯同时快速变化时，如果团队已经确信产品带来质变，先让用户用上、再根据真实反馈修整，常比等待完美更有价值。这不等于放弃可用性，而是把“产品是否带来足够大的变化”放在“每个角落是否已经磨光”之前。
验收 AI 同事的工作，不能只看最终结果
把编码智能体移植到知识工作，最容易忽略验收差异。
代码有较强的结果检验：能否编译、测试是否通过、界面能否运行、性能是否达标。测试并不保证产品一定正确，但它能迅速淘汰大量错误结果。
一份财务模型、一份市场研究或一套管理层方案没有同样清晰的通过按钮。表格里的数字可以排版漂亮却引用错误；演示文稿可以逻辑流畅却遗漏决定结论的反例；报告末页写着“90% 成功率”，读者不能仅凭这个数字判断它是否可信。
成品看起来正确，还不等于工作可靠
切换视图，聚焦两类任务的验收路径
较短的结果检验链
- 输入：需求与代码上下文
- 执行：修改、构建、运行
- 检查：测试、界面、性能
更长的过程证据链
- 背景：已有决策是否齐全
- 输入：数据和原始来源是否可靠
- 过程：方向是否可中途干预
- 中间产物：假设、引用和计算能否审查
- 结论：重要判断能否回溯到证据与负责人
知识工作的验收需要一条更长的证据链：
- 背景是否完整。 智能体看到了哪些邮件、文档、数据和已有决策？
- 输入是否可靠。 使用的是原始资料、二手摘要，还是未经核对的网页片段？
- 过程是否可干预。 人能否在方向错误时中止、补充约束或缩小范围？
- 中间产物是否可审。 关键假设、引用、计算和被排除的方案是否看得见？
- 最终结果是否能回溯。 每个重要数字和判断能否找到来源与负责人？
这并不要求产品暴露模型的私有思维链。需要暴露的是工作证据：引用了什么、执行了什么、产物如何变化、哪里需要人确认。持久在线同事越能独立执行，越要让人用较低成本保持知情和控制。
从写作开始：哪些工作交给 AI，哪些判断必须留给人
Tara 对 AI 写作的分界比“用或不用”更具体。
“写作用于汇报”包括周报、状态总结、会议材料整理、格式转换和已知内容的重组。目的在于准确传递已有信息，适合让模型承担大量机械工作。
“写作用于思考”发生在观点还没有成形时。列提纲、写出第一版、删掉站不住的句子、发现论证缺口，这些动作本身构成思考。若一开始就让模型生成完整文稿，人可能得到一份流畅文本，却跳过了形成判断的过程。
她给自己的规则是：思考型写作由自己开始，也由自己结束。AI 可以在中间找资料、拉数据、提出反例、攻击假设；最终结构和文字仍由她重新判断。她还沿用一个协作方法：文档做到约 70% 时就拿给需要参与的人，让对方有空间质疑和共同塑形。完全抛光的成品反而容易让新想法弹开。
她还用一条很重的个人问责规则约束文档和会议：如果要求几个人读她的文档，她至少要按相同次数亲自读过；如果召集一场会议，她会在会前投入相当于所有参会者总时长的准备。重点不在机械计算时间，而在于不能用 AI 生成材料后，把理解和审阅成本转嫁给别人。
同一个分界也适用于其他任务：
| 可以大量自动化 | 应保留人的主动工作 |
|---|---|
| 已知材料的摘要、转格式、状态汇总 | 定义问题、形成判断、决定取舍 |
| 找资料、取数、制作候选方案 | 选择可信来源、检查缺口与反例 |
| 生成可运行的第一版工具或页面 | 决定什么值得交付、为结果负责 |
Tara 用 Sites 做团队游戏、旅行路线和内部仪表板，用 Visualize 把数据组织成故事。这些案例说明，知识工作的默认产物不必永远是文档和幻灯片。一个临时需求可以直接变成可运行、可共享、带数据库的小工具。AI 同事扩大了表达形式，人仍负责决定表达什么。
她在 Sutter Hill 还学到一种更靠前的验证：先测试“产品营销匹配”。团队在投入完整产品之前，先向大量潜在用户讲清它解决什么问题、为什么会改变现状，观察哪种定位能让对方理解并愿意继续。叙事在这里不是产品完成后的包装，而是一项低成本的产品发现工具。模型让原型变便宜后，定位、原型和真实反馈可以更早进入同一个验证循环。
与持久在线 AI 同事合作的六条协议
个人或团队不必等到“第三阶段”完全成熟才调整工作。可以先把一次复杂任务改造成六项明确约定：
- 写目标，不只写动作。 除了“做一份报告”，说明报告要支持哪个决定、读者是谁、什么算完成。
- 提供必要上下文。 把原始资料、历史决策和限制放在同一项目里，避免智能体靠猜测补齐。
- 设置中途检查点。 长任务先确认研究范围、结构或样例，再继续大规模执行。
- 要求工作证据。 保存来源、计算、修改记录和无法确认的事项，让最终产物可以回溯。
- 固定一位结果负责人。 智能体可以执行，批准发布、付款、对外沟通或高风险决定的人不能缺席。
- 每轮都提高目标。 记录省下的时间，也检查是否只把旧任务做快；把一部分新增能力用于过去不敢启动的项目。
访谈结尾，Tara 用一个很具体的移动场景描述“持久”：在手机上交代一项工作，进入没有网络的地铁，出来时任务已经在云端完成，人再继续检查和对话。它听起来只是后台运行，却把工作关系彻底改写了——人不再需要守着每一步执行，但必须更清楚地给方向、设边界、看证据并承担结果。
AI 同事越能独立工作，人的工作就越集中到那些无法靠“生成更多内容”解决的问题：我们要去哪里，什么足够好，哪些证据可信，以及谁愿意为最后的选择签字。