OpenAI员工实战分享：用Codex打造AI工作操作系统

当AI从"写代码工具"进化为"工作操作系统"，人类的角色究竟发生了怎样的改变？OpenAI Codex 团队的 Jason Liu 在一次深度访谈中，完整展示了他如何将 ChatGPT 工作台与 Codex 融入日常工作与生活的每一个环节。他的核心观点令人深思："唯一剩下的工作，就是搞清楚你对某件事哪里不满意，把它转化成语言，然后告诉 AI。"

ChatGPT 工作台与 Codex 的本质区别

很多人容易混淆 ChatGPT 工作台（ChatGPT Work）与 Codex 的区别。Jason 给出了清晰的解释：二者本质上是同一 Codex 体验的不同 UI 视图。

Codex 是 OpenAI 推出的自主编程 agent，它在云端沙箱环境中运行，能够读写文件、执行代码、访问互联网，并通过 Git 工作流输出结果。ChatGPT 工作台则是面向企业和高级用户的界面层，将 Codex 的底层能力封装为更易用的任务执行环境。二者共享同一套推理引擎和工具调用能力，区别仅在于前端呈现方式——Codex 展示完整的技术过程（如终端输出、文件差异），而工作台将这些抽象为"任务完成"的结果视图。

一个反直觉的洞察是：如果你想打造一款优秀的工作生产力工具，最好的起点竟然是一个强大的编程 agent。Codex 会向你展示 Git 历史、Pull Request、代码变更等技术细节；而工作台则把这些隐藏在幕后。"如果我在做幻灯片，我其实不需要看到自己写了 20 行 Python 来完成某件事。"

Jason 坦言，现在他大部分工作都在"工作台"里完成，因为他"根本不需要审查代码"。这也印证了当下的一个趋势——越来越多的人已经不再逐行 review AI 生成的代码。

关于模型选择，他的建议非常务实：日常事务（读 Slack、排日程、管理日历）默认使用 Sol medium 即可，这些任务不需要最高智能；只有在构建复杂原型应用时，才会切换到 extra high 或 ultra 级别，设定好宏大目标后让 Codex 连续工作数小时。这种分级策略不仅节省计算资源，也反映了一个实用原则：匹配任务复杂度与模型能力等级，避免"杀鸡用牛刀"的浪费。

长驻线程：用 Obsidian 笔记库统管全部上下文

Jason 的线程组织方式颠覆了大多数人的习惯。他并没有在后台运行成百上千个线程，而是把每个置顶线程当作一个独立工作区。

得益于 Codex 出色的"压缩"（compaction）能力，这些长驻线程不会丢失历史上下文。在长对话场景中，上下文窗口有限是大语言模型面临的核心挑战。压缩是一种将冗长对话历史精炼为关键信息摘要的技术，确保 agent 在数百轮交互后仍能记住核心目标、已完成步骤和关键决策。这类似于人类的工作记忆——不需要逐字记住所有对话，只需保留结构化的要点。得益于此机制，Jason 的长驻线程可以持续运行数周甚至数月而不丢失关键上下文。

他有专门读 Reddit、Twitter、LinkedIn 收集用户反馈的自动化线程，有告诉他每日/每周重点的"幕僚长"线程，还有筹备 Dev Day、制作愿景视频、个人学鼓项目等各类线程。

更关键的是他的知识管理哲学：所有上下文都沉淀在一个 Obsidian Vault 里，而它本质上只是一堆 Markdown 文件。Obsidian 是一款基于本地 Markdown 文件的知识管理工具，其核心优势在于所有数据以纯文本形式存储，无需依赖任何专有格式或云服务。这一特性使其天然适合作为 AI agent 的知识源——Markdown 文件既对人类可读可编辑，也极易被语言模型解析和引用。"我很少真正打开 Obsidian，它主要是给我的 agent 提供上下文。"这个 Vault 里分门别类存放着项目、人物、笔记、日常记录和个人偏好。由于它托管在 GitHub 上，无论切换到云端还是其他环境，都能随时拉取重建——任何具有仓库访问权限的 agent 实例都能通过 git clone 获取完整知识库，实现了"便携式大脑"的效果。

值得一提的是，遇到需要执行的任务时，Jason 不会让主线程直接处理，而是让它"派生一个子 agent"（subagent）。子 agent 是一种将复杂任务分解执行的架构模式：主线程（类似"管理者"）负责理解目标、拆分任务和汇总结果，而子 agent（类似"执行者"）则在独立的沙箱环境中处理具体子任务。这种设计避免了主线程上下文被大量执行细节污染，允许多个子任务并行执行，并且在子 agent 失败时不影响主线程状态。这一做法在 ultra 模式下可以自动完成，但 Jason 倾向于更谨慎地手动控制。

幕僚长系统：让 AI 主动为你梳理优先级

Jason 系统中最实用的部分，是他称之为"幕僚长"（Chief of Staff）的定时任务。

每天 9 点、13 点、17 点，这个自动化会读取他所有的 Slack、用 computer use 读取 Twitter DM、检查未回复的邮件和 Linear 看板，然后给出一份清晰的"当前需要关注什么"的概览。如果 Linear 上有状态需要更新，Codex 会直接帮他处理。这种心跳任务（heartbeat）的设计借鉴了分布式系统中的概念——在软件工程中，heartbeat 是指系统组件之间定期发送的状态信号，用于确认彼此存活和同步状态。Jason 将此概念移植到个人生产力系统中，让 Codex 按预设间隔自动检查各个信息源并主动汇报，将人从"拉取信息"的认知负担中解放出来。

更妙的是那些日积月累打磨出来的小功能：因为经常出差，一旦 Codex 发现有订票信息和参考号，就会自动帮他值机，并把登机牌短信发到他的个人手机上。当他人在纽约时，会突然收到 Codex 发来的登机牌。

对于普通用户如何搭建这套系统，Jason 给出了极其朴素的起步提示词：

"把这个线程变成一个 heartbeat（心跳任务）。我要你在合适的时间——比如 9 点、13 点、17 点——检查我的邮件、Slack、Linear，然后告诉我该优先处理什么。"

随后就是持续迭代：一开始它不带链接，你就说"给每条都加上链接"；后来它能预先起草 Slack 回复和邮件，你只需修改润色即可发送。"这就跟招人一样，第一天你得给他大量信息、不断反馈，他会随时间成长。"

Skill 与 Plugin：打造个人 AI 语气库和能力包

Jason 最喜欢的一类能力是各种"写作 skill"。他有 write me、tweet me、email me 等技能，还有把语音转录变成博客、把视频变成视频随笔的技能。

创建方式同样简单："我要你用 Slack connector 读过去一周的消息，然后写一个 skill 来搞清楚怎么模仿我说话。"随着使用深入，他还会教它区分场景——对外部用户、团队成员、高管、同事要用不同的语气。

关于概念辨析，Jason 讲得很清楚：skill 是 plugin 的一个组成部分。一个 plugin 可能包含若干 MCP server、多个 skill 以及一些资源和脚本。MCP（Model Context Protocol）是一种标准化大语言模型与外部工具和数据源交互的开放协议，一个 MCP server 本质上是一个轻量级服务端点，向 AI agent 暴露特定能力（如读取数据库、调用 API、操作文件系统）。在 Codex 的 plugin 体系中，这种分层架构让能力的复用和分享变得模块化。如果想把写作能力分享给团队，他会打包成一个名为 "Better Writing" 的 plugin。目前任何人都可以向 Codex plugin 目录提交自己的插件——纯 skill 会快速审核通过，含 MCP 的则需额外的安全审计。

为了对抗技能膨胀，他还有一招"自我改进"的元技能（self-improve）：让 Codex 回顾过去 400 个 session，找出从未使用的 skill、可以合并的重复 skill，然后自动清理。"这跟管理一个团队没什么两样。"

浏览器与 Computer Use：合上笔记本也能继续工作

Jason 认为浏览器与 computer use 是 Codex 最令人惊叹的能力。Computer Use（计算机使用）是指 AI agent 通过截屏识别和模拟鼠标/键盘操作来控制图形界面的能力。其技术路径通常是：agent 获取当前屏幕截图→通过视觉理解模型识别界面元素→规划下一步操作→执行点击、输入等动作→再次截屏验证结果。这项能力的突破意义在于，它让 AI 能够操作任何没有 API 的软件——视频编辑器、网页表单、桌面应用——从而极大扩展了自动化的边界。

他分享了一个经典案例：骑行途中收到同事请求重新导出视频，他用手机远程控制 MacBook，让 Codex 用 computer use 找到视频、识别导出工具、编辑后发回 Slack。之后设定每 30 分钟检查一次反馈，自动产出 V2、V3、V4。等他到家时，视频已被审批通过，成为一支正式发布视频。

使用浏览器的关键技巧有两点：一是理解 Codex 内置浏览器支持登录态（带 cookie 认证），从而能访问更多信息；二是它能控制多个标签页。他举了个购物的例子——不是让 AI 给出一份 Markdown 推荐清单，而是让它把每个候选商品分别打开在独立标签页，等他喝完咖啡回来，直接对比四个标签页后自行点击下单。

从零构建应用：目标、计划与工作日志方法论

访谈中最精彩的部分，是 Jason 展示他如何为自己"学打鼓"构建了一款定制学习 app。

他的方法论围绕三个文件展开，且这三个文件都由 Codex 自己生成：

Goal.md：定义可验证的成功标准

例如"能粘贴 YouTube 链接并提取出鼓组的不同声部"。关键在于目标必须可验证——他甚至在目标里写明了测试歌曲、视频 ID，要求 Codex 用 computer use 打开 app、上传视频、拿回数据来验证核心功能。"如果你想设定好目标，别自己写目标，告诉 Codex 你想要什么和成功标准，然后让它自己设定目标去完成。"这种做法体现了软件工程中"验收测试驱动开发"（ATDD）的理念——先定义什么算"完成"，再反向推导实现路径。

Plan.md：明确技术实现路径

实现细节：用 React 编写、两个标签页、使用 Tailwind 和 shadcn 等技术栈，不会用就去读文档。React 是 Meta 开发的前端 UI 框架，Tailwind 是实用优先的 CSS 框架，shadcn 则是一套可复制的 UI 组件库——这些技术栈的选择反映了当前 AI 生成应用的主流模式：选用文档丰富、社区活跃的工具，确保 AI 能从训练数据中获取充足的参考知识。

Work Log：追踪执行过程的日志

由于压缩机制，他不会逐条读消息，但工作日志能帮他快速了解卡在了哪里——作为 DX（Developer Experience，开发者体验）团队成员，这正是他理解工具局限的窗口。工作日志还有另一个重要作用：当 Codex 的压缩摘要遗漏了某些细节时，日志文件作为持久化存储提供了完整的审计轨迹。

将目标独立成文件的好处是：即便任务还在运行，他也能随时编辑 Goal.md 来扩展或收缩范围。

核心哲学：学会"不满意"才是真正的竞争力

Jason 反复强调的一句话，是整场访谈的灵魂：

"如果你想要品味（taste），你就必须去品尝（eat）。我们现在的工作，就是想出那套语言，更深入地了解自己到底想要什么。"

面对"编程已被解决后人该学什么"的问题，他的答案是：学会对现状的不满，并学会用词汇精确表达这种不满。四年前的问题是"我怎么写这段代码"，现在的问题变成了"为什么切换面板会闪烁"——你问 Codex，它会告诉你是因为没有预加载，然后你说"修掉它"。这种转变意味着，技术素养从"知道怎么实现"转向"知道什么是好的"——审美判断力和问题诊断能力取代了编码技能，成为核心竞争力。

他明确拒绝"管理者"的自我定位。在 OpenAI，人人都很努力，让你脱颖而出的是你有多在乎一件事做得够不够好，多在乎它能否带来真正的成果。对他而言，学鼓 app 成功的标准不是代码好不好看，而是他是否真的学会了打鼓、这个工具能否被分享给他人。

谈及未来，Jason 表示 Codex 正从桌面端大量迁移到 ChatGPT 工作台的云端体验中。他最期待的方向是——"工作不应该因为你合上笔记本电脑而停止。"这一愿景的技术支撑在于：当 agent 完全运行在云端，它不再依赖用户本地设备的在线状态，可以 7×24 小时持续执行任务并在完成后通知用户。此外，语音交互（比如打电话给你的 Codex 下达指令）也将是重点发力的方向。

对于每一个想借助 AI 提升生产力的人来说，Jason 的系统给出了一条清晰路径：不要期待 AI 一次解决你的问题，而要把它当成一位需要持续培养、会随时间成长的伙伴。而你真正需要修炼的，是那种"知道自己想要什么、并能把它说清楚"的能力。