乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > Codex 详解:从 AI 编码工具到多代理工作台

Codex 详解:从 AI 编码工具到多代理工作台

当前时间： 2026-04-27 09:24:13 更新时间： 2026-04-27 分类：软件教程 评论(0)

Codex 详解:从 AI 编码工具到多代理工作台

本文是一篇面向普通用户的 Codex 介绍。你不需要预先了解任何背景材料，只要想知道 Codex 能做什么、如何组织工作流、适合哪些场景，以及使用时需要注意什么，就可以从这里开始。

一、Codex 到底是什么？

Codex 是 OpenAI 面向真实软件工程和生产工作流推出的 AI 编码代理。它不只是一个“会写代码的聊天框”，而是一个可以读取项目、编辑文件、运行命令、执行测试、生成文档、管理多个任务，并在一定权限范围内操作本地或云端环境的 AI agent。

按照 OpenAI 官方说法，Codex 的核心定位是：帮助用户更快地写代码、审查代码和交付软件。它可以在终端、IDE、Codex 桌面应用、Web 和云端任务中使用。用户既可以像结对编程一样和它实时互动，也可以把任务委托给后台运行的 Codex agent，让它在隔离环境里完成较长时间的工作。

很多人会把 Codex 理解成一种“AI super-app”。这个说法不是官方术语，但它抓住了一个关键变化：Codex 正在从单纯的 AI 编程助手，变成一个统一管理 AI agent、文件、插件、技能、自动化和多项目协作的工作台。

换句话说，Codex 的价值不只在于“帮你写一段函数”，而在于它把很多原本分散的能力放进了同一个界面：

  • 写代码、改代码、跑测试
  • 生成和编辑文档、表格、幻灯片
  • 做网页搜索和资料研究
  • 创建项目文件夹并管理输出文件
  • 调用插件和外部服务
  • 创建可复用技能
  • 创建定时自动化任务
  • 同时运行多个 agent 处理不同任务
  • 在桌面应用里查看文件、预览网页、打开局部窗口继续跟进

这也是理解 Codex 时最重要的观点：未来使用 AI agent 的关键能力，不只是“会写提示词”，而是会把多个 agent 当作一组可以并行工作的协作者来调度。

二、Codex 的入口：CLI、IDE、App 和云端

Codex 不是只有一种形态。根据 OpenAI 官方资料，Codex 主要有几类入口。

第一类是 Codex CLI。它运行在终端里，适合开发者在本地项目中直接让 Codex 阅读代码、修改文件、运行命令和执行测试。对于习惯命令行的人来说，CLI 是最直接、最轻量的入口。

第二类是 IDE 扩展。Codex 可以在 VS Code、Cursor、Windsurf 等开发环境里使用。它适合日常开发：一边看代码，一边让 Codex 修改、解释、测试和重构。

第三类是 Codex 桌面应用。桌面 App 像一个“代理控制中心”，可以管理多个项目和多个 agent，并支持更丰富的文件预览、插件、技能、自动化、多任务调度等能力。OpenAI 官方也把 Codex app 描述为一个可以管理多个 agent 并行工作的 command center。

第四类是云端 Codex。云端任务适合较长时间的后台工作，例如修复 bug、实现功能、跑测试、生成 PR。每个任务通常在隔离的 sandbox 环境中运行，用户可以查看结果、审查 diff，再决定是否合并。

这几种入口不是互相排斥的。在复杂项目中，Codex app 可以成为“主控台”：你既可以让 Codex 直接推进任务，也可以在项目终端里运行其他 CLI 工具或 agent，把它们作为某些专项任务的补充。

三、Codex App 的基本界面：项目、聊天和文件

先从 Codex app 的基础界面理解。新打开 Codex app 时，它看起来有点像 ChatGPT：左边是侧边栏，中间是对话区域，你可以输入任务并等待 AI 回复。但真正的差异在于，Codex 的对话通常绑定到本地项目文件夹。

Codex app 里的一个核心概念是 Project。Project 本质上对应你电脑上的一个文件夹。你可以创建一个总文件夹，比如 Codex Projects，再在里面创建不同项目，例如：

  • Codex Desktop Research
  • My New Business
  • Chorus App
  • Website Redesign
  • Investor Deck

每个项目可以有多个 chat/thread。你可以在同一个项目里同时开启多个任务：一个 chat 做资料研究，一个 chat 生成表格，一个 chat 修改网页，一个 chat 创建幻灯片。所有 agent 创建出来的文件，会保存在项目文件夹下，通常还会有 outputs 之类的输出目录。

这个设计很重要。普通聊天工具里的 AI 输出往往停留在对话记录里，而 Codex 的输出会落到真实文件系统中。也就是说，你不是在“复制粘贴 AI 的回答”，而是在让 AI 直接创建和维护项目资产。

一个简单流程可以是：

  1. 创建一个项目文件夹。
  2. 让 Codex 搜索并总结 Codex desktop app 的新功能。
  3. 继续要求 Codex 把结果整理成 Excel 表格。
  4. Codex 生成 .xlsx文件并放到项目目录中。
  5. 用户直接在 Codex app 的预览面板里打开表格。
  6. 用户继续要求删除某一列，Codex 修改表格文件。

这个流程展示了 Codex app 的一个关键能力：对话、文件和预览是连在一起的。你可以在聊天中发出指令，也可以在右侧直接查看文件，必要时再继续让 agent 修改。

四、Codex 的预览能力：不只是代码，也能看文档、表格和网页

Codex app 的预览面板让用户可以直接查看 agent 生成的内容，例如：

  • Excel 表格
  • Word 文档
  • PowerPoint 幻灯片
  • 本地网页
  • React 应用
  • Remotion 视频时间线
  • 设计稿或图片文件

这让 Codex 不只是一个代码生成器，而更像一个可视化工作台。你可以让它生成一个网页，然后在侧边预览中打开；发现布局不好，再直接截图或描述问题，让它继续修改。你也可以打开一个表格或幻灯片，在视觉上检查结果，然后用自然语言要求它做进一步调整。

这种“看见结果再继续指导”的循环，是在实际使用中非常重要的工作方式。它比一次性写一个完美 prompt 更现实。真实工作中，你通常会经历这样的过程：

  1. 先让 agent 生成第一版。
  2. 打开预览。
  3. 发现问题。
  4. 用截图、文件引用或文字描述告诉 agent。
  5. 让它继续修。
  6. 重复，直到结果可用。

这也是为什么 Codex app 比单纯 CLI 更适合多模态、多资产的项目：它把结果检查这一步变得更直观。

五、权限、模型和 effort：让 agent 工作前先设边界

Codex agent 可以读写文件、运行命令，甚至在某些场景中使用 computer use 控制电脑。因此，权限管理非常重要。

Codex 的权限设置决定 agent 能做什么、哪些操作需要用户批准。从稳妥的工程实践看，权限应该根据任务风险来设置：

  • 只做解释和研究时，可以限制写权限。
  • 修改本地项目时，可以允许写入项目目录。
  • 运行安装、网络访问、部署等命令时，最好保留确认步骤。
  • 涉及 API key、生产数据库、真实账号、发布上线时，应格外谨慎。

OpenAI 官方也强调 Codex 的 sandbox 和权限设计：默认情况下，agent 会被限制在所在文件夹或分支内工作，并对需要更高权限的命令请求用户批准。这个设计是必要的，因为一个能操作文件和命令行的 AI agent，本质上已经是一个具有执行能力的软件实体。

模型和 effort 则影响 agent 的能力和成本。复杂任务通常适合使用更强模型和更高 effort；简单任务则可以用较低 effort 换取速度和成本优势。一般来说：

  • 简单任务可以用较低 effort，速度更快。
  • 复杂重构、设计规划、长文档、跨文件任务适合更高 effort。
  • 多 agent 并行时，要注意使用额度和等待时间。

六、搜索和项目组织：多项目时代的记忆入口

当你开始频繁使用 Codex 后，项目和聊天会迅速变多，因此搜索和组织会变得非常重要。

Codex app 支持搜索历史聊天，例如通过快捷键 Cmd+G 搜索某个关键词，找到之前的项目或会话。项目从侧边栏移除，并不意味着本地文件被删除；它只是从界面中隐藏。只要文件夹还在，你仍然可以通过搜索或重新添加项目找回。

这意味着 Codex 的组织方式更接近“本地文件系统 + agent 历史记录”的组合：

  • 文件夹是项目资产的真实位置。
  • chat 是 agent 工作过程的记录。
  • 搜索是找回上下文的入口。
  • 文件引用让不同 chat 可以共享项目内的产物。

你可以在新 chat 中 @mention之前生成的文件，让 agent 基于那个表格、文档或设计稿继续研究和补充。这种文件引用能力非常重要，因为它让 Codex 不必每次从零开始，而可以围绕已有资产迭代。

七、Skills 与 Plugins：Codex 能力扩展的两条路

不同产品对 skills 和 plugins 的命名不完全一致，但可以简单理解为：

Skill 是一种可复用工作流。它像一份“任务配方”，告诉 agent 遇到某类任务时应该怎样做、使用什么工具、输出什么格式、遵守什么标准。

Plugin 是一种可安装的能力扩展。它通常连接外部服务或提供新的工具能力，例如 Google Calendar、Gmail、Figma、Remotion、Vercel、Typefully 等。

几个直观例子：

  • 安装 Google Calendar 插件后，Codex 可以读取本周日程。
  • 配合 Gmail 插件，Codex 可以把周报发到用户邮箱。
  • 用户可以让 Codex 把这个流程变成每周五下午 4 点自动运行的 automation。
  • 安装 Figma 插件后，Codex 可以查看或操作 Figma 文件。
  • 使用 Remotion 插件后，Codex 可以生成 motion graphics launch video。

Skills 更偏向“教会 agent 怎么做事”，plugins 更偏向“给 agent 新工具”。两者经常一起使用。例如用户创建了一个 YouTube Researcher skill，这个 skill 内部使用第三方 API 拉取 YouTube 视频字幕，再配合文档生成能力输出分析报告。

一个成熟的 Codex 工作流，通常不是只靠一个 prompt，而是由“项目 + 文件 + skill + plugin + automation”组合出来的。

八、自定义 Skill：把重复工作变成可复用能力

一个很有代表性的自定义能力，是创建 YouTube Researcher skill。

这个能力要解决的痛点是：经常需要拉取 YouTube 内容 transcript，分析频道最近内容表现、标题、开头 hook、观看数据和内容趋势。手工做这件事很繁琐，于是可以让 Codex：

  1. 搜索可用的 YouTube transcript API。
  2. 比较几个服务。
  3. 选择一个 API。
  4. 使用 API key。
  5. 创建一个可复用 skill。
  6. 让以后任何 chat 都可以调用这个 skill。

创建完成后，你就可以在新会话里使用这个 skill，让 Codex 分析某个频道最近 10 条内容，拉取 transcript，生成包含 thumbnail、观看表现、hook 分析、内容建议的文档。更进一步，还可以把这个流程做成 automation：每个月最后一天自动分析当月内容，并生成报告。

这个案例说明了 Codex 的一个核心使用哲学：当你发现自己反复做同一件事，不要只让 AI 临时帮你做一次，而是让它把这件事封装成 skill 或 automation。这样就可以把 AI 从“临时助手”变成“长期工作系统”。

九、Automations：让 Codex 从被动聊天变成主动执行

Automations 是 Codex 从“聊天工具”走向“工作系统”的关键能力。用户可以直接用自然语言要求 Codex 创建自动化任务，例如：

  • 每周五下午生成日程回顾并发邮件。
  • 每月最后一天分析 Bilibili 视频表现。
  • 每天早上生成 3 条 Weibo 草稿。
  • 定期检查某个项目状态。
  • 监控某些数据或提醒用户处理事项。

automation 不是抽象概念，而是真实把插件、skill 和时间规则串起来：

Google Calendar + Gmail 可以组成周报自动化。YouTube Researcher + Word Doc 可以组成月度内容分析自动化。Typefully API skill 可以组成社交媒体草稿自动化。这类自动化的价值在于，它把 AI agent 从“你问一句它答一句”的模式，推进到“在固定时间主动完成一项工作”的模式。

不过 automation 也要谨慎使用。凡是涉及发邮件、发社交媒体、修改数据库、部署生产环境的自动化，都应该设置好审核步骤，至少在初期保留人工确认。

十、MCP：把外部工具接入 agent 的通用方式

MCP 全称 Model Context Protocol，是一种让 AI agent 连接外部工具、数据源和服务的协议。

以设计工具为例，某些工具会提供 MCP，让 agent 更方便地读取画布、创建元素和修改设计。和传统只面向人类鼠标操作的界面相比，为 agent 暴露 MCP 或 API 的工具，在自动化设计、批量生成和跨工具协作中会更自然。

关键建议是：如果某个外部工具提供 MCP，你可以让 Codex 或其他 agent 帮你创建一个 skill，把这个 MCP 包装成易用能力。之后你就不必每次记住复杂的 MCP 调用方式，只需要在 Codex 里用自然语言或 slash skill 调用。

这代表一个很重要的趋势：未来很多软件不仅会提供给人类使用的 UI，也会提供给 agent 使用的 MCP 或 API。谁能更好地被 agent 操作，谁就更容易进入 AI 工作流。

十一、Steering vs Queueing：在 agent 工作时继续指导

这里有一个很实用的交互细节：steering。

很多 AI 工具在 agent 工作时，如果用户继续输入指令，新消息会排队，等当前任务结束后才执行。这叫 queueing。

Codex app 支持 steering，也就是在 agent 正在执行时插入新的指导信息。比如当 agent 正在设计落地页时，你发现按钮和文字有重叠，可以直接截图并说明“这里有重叠，需要修正”。选择 steer 后，Codex 会在当前任务流程中接收这条反馈，并尽快调整。

这个能力很适合长任务。因为真实工作中，你经常在 agent 执行过程中发现方向问题。如果必须等它跑完再纠正，会浪费很多时间。Steering 让用户像导演一样持续微调 agent 的工作方向。

十二、多任务工作流：Codex 最值得学习的使用方式

一个典型的进阶场景是围绕一个 iOS app 项目，同时创建六类资产：

  • iOS app design
  • Swift iOS app
  • Web landing page
  • Investor deck
  • Launch video
  • X/Twitter post automation

这个部分最重要的不是某个具体工具，而是多任务方法论。

推荐做法是：

  1. 先创建一个项目文件夹。
  2. 让 Codex 生成一个 markdown plan，把所有任务列出来。
  3. 给不同任务开不同 chat。
  4. 每个 chat 专注一个产物，例如 mobile app、web app、deck、video。
  5. 当一个 agent 开始长时间执行时，切换到另一个 chat 继续推进。
  6. 不断回到 plan 中标记进度。
  7. 必要时 fork chat，让新任务继承上下文。

这是一种“串行发起，并行等待”的工作方式。你每次只专注写一个高质量 prompt，然后让 agent 去执行。它执行时，你转到下一个任务。几十分钟后，多个任务都推进了一大截。

这正是使用 Codex 时需要建立的新能力：AI agent 的执行时间越来越长，单个任务可能跑 5 分钟、20 分钟甚至 1 小时。高效用户不会坐等一个 agent 结束，而会学会调度多个 agent。

十三、案例一：用 Codex 创建 iOS App

以创建 Swift iOS app 为例，流程大致是：

  1. 先让 Codex 创建一个最小 Swift 项目。
  2. 用 Xcode 打开项目。
  3. 在 iOS Simulator 或真实 iPhone 上运行。
  4. 让另一个 chat 生成移动端界面设计。
  5. 把设计整合进 Swift app。
  6. 继续要求调整滚动、顶部栏、底部导航、模糊效果、保存功能等。
  7. 接入 Supabase 数据库。
  8. 添加平台、课程、skills 等内容。
  9. 添加登录认证。
  10. 准备 TestFlight。

这个案例说明 Codex 可以覆盖从项目初始化到真实设备测试的完整链路。它不仅写 Swift 文件，还能指导用户安装 Xcode、选择 simulator、解释数据库方案、生成图标、处理认证流程。

这类流程也会暴露现实限制：复杂 app 仍然需要人类判断。比如数据库选型、认证方式、UI 细节、App Store 配置，都需要用户不断审查和决策。Codex 能加速，但不等于完全替代产品经理、工程师和设计师。

十四、案例二：创建 Landing Page 并部署到 Vercel

为了给 iOS app 收集候补用户，可以让 Codex 创建一个 web landing page，并嵌入 Tally 表单。

流程包括：

  1. 在 Tally 创建报名表。
  2. 复制 embed code。
  3. 让 Codex 创建 React app。
  4. 把 Tally 表单嵌入页面。
  5. 让页面视觉风格匹配 iOS app。
  6. 使用 Vercel 插件部署。
  7. 打开公网链接测试提交。
  8. 回到 Tally 确认数据收到。

这个流程非常典型：Codex 不是只负责写网页，而是贯穿“表单工具、前端代码、部署平台、真实测试”的完整业务闭环。

这类流程也会暴露一个现实问题：不同模型和工具有不同强项。Codex 的优势是工作台、代理调度和 OpenAI 生态；但在某些设计审美任务上，用户可以把其他工具作为补充，例如在 Codex app 的项目终端里运行其他 CLI agent 来优化页面或素材。

十五、案例三：用 Remotion 创建 Launch Video

对于发布视频，可以使用 Remotion 插件创建 motion graphics launch video。

一种常见流程是先让 Codex 规划视频，再让 Remotion 生成一个本地可预览的视频时间线。打开 localhost 预览后，你可以看到每一段动画，并基于时间点和画面问题继续修改。例如：

  • 给手机 mockup 加黑色边框。
  • 在某个时间点放大某个界面。
  • 加一个鼠标点击开关的动画。
  • 添加 skills 卡片旋转。
  • 展示把 skill 复制到 Codex 或 Claude Code 的过程。
  • 加入背景音乐并控制音量。

这个案例展示了 Codex 处理“代码驱动的视频制作”的能力。Remotion 本身是用代码生成视频的框架，因此特别适合 agent 参与。用户不必手动拖动时间线，而是可以用自然语言描述动画，再在预览里检查。

不过需要承认：第一版视频并不会完美，很多细节需要反复调。比如鼠标位置偏了、过渡太丑、动画太快、文字不够高级。这些都需要用户通过截图、坐标、时间点等方式继续指导。

十六、案例四：生成 Investor Deck 并导出到 Canva

Codex 也可以用于创建 investor deck。流程大致是：

  1. fork 现有 mobile app chat，让新 chat 继承上下文。
  2. 要求 Codex 分析 app 特点和已有资产。
  3. 让 Codex 搜索投资人当前关心什么。
  4. 使用 PowerPoint skill 生成 deck。
  5. 在 Codex 里预览。
  6. 导出或打开到 Canva。
  7. 在 Canva 做最后的人工微调。

这个案例说明 Codex 可以把“产品上下文”转化为商业资产。它不只知道 app 的代码，还能读取项目中的图标、页面、文案、计划文档，并把这些材料组织成融资叙事。

但这里同样有边界：自动生成的 deck 通常还需要精修，文本可能太多，视觉表达不够成熟。因此更合理的定位是：Codex 可以快速生成 60% 到 80% 的初稿，让人类做最后 20% 的判断和润色。

十七、案例五：创建 Typefully Skill 和社交媒体自动化

最后，还可以创建一个 Typefully skill，用于控制 X/Twitter 草稿。

拿到 Typefully API key 后，可以让 Codex 搜索 API 文档，创建可复用 skill，并测试能否为指定账号生成草稿。测试成功后，再进一步创建 automation：每天早上研究并生成三条推文草稿。

这个案例代表 Codex 的商业自动化潜力。很多知识工作并不是“写代码”，而是反复在多个 SaaS 工具之间搬运信息、生成内容、整理数据、发给某个渠道。Codex 的插件、skills 和 automations 可以把这些流程变成系统。

但涉及对外发布的自动化，建议先从“生成草稿”开始，而不是直接自动发布。让 AI 写初稿，人类审核后再发，是更稳妥的落地方式。

十八、Codex 的真正优势：统一界面和多代理调度

综合来看，Codex 最突出的优势不是单点能力，而是统一性。

在一个项目中，你可以同时拥有：

  • plan chat
  • mobile design chat
  • Swift app chat
  • web app chat
  • launch video chat
  • investor deck chat
  • automation chat

每个 chat 都是一个 agent 的工作线程。它们共享项目文件夹，可以引用彼此产物。你可以打开某个文件预览，也可以把某个 chat fork 出来做新方向。你还可以把完成的流程封装成 skill 或 automation，下次复用。

这种体验让 Codex 更像一个 AI 操作系统里的工作台，而不是一个单独的模型窗口。

如果说传统 AI 聊天的基本单位是“问题”，那么 Codex 的基本单位更像是“项目”。在项目里，问题、文件、agent、工具和自动化共同组成一个可持续推进的工作空间。

十九、Codex 与 Claude Code 的关系：竞争，也可以互补

有人会把 Codex 和 Claude Code 放在一起比较，但更真实的情况是：它们既竞争，也可以互补。Codex 可以作为项目主控台，其他 CLI agent 可以作为局部任务的辅助工具，尤其是在设计、文案、特定框架代码生成等细分场景中。

因此，Codex 和 Claude Code 并不一定只能二选一。

Codex 的强项是：

  • 多 agent 工作台
  • 项目和文件组织
  • OpenAI 生态集成
  • skills、plugins、automations
  • 与 ChatGPT 账号和 Codex 云端能力结合

Claude Code 的常见强项包括：

  • 某些设计任务的审美更好
  • 在终端里处理特定代码任务很顺手
  • 可以作为 Codex app 中的辅助 CLI agent

更成熟的用法是：把 Codex app 当作主控台，把 Claude Code、Gemini CLI、其他 MCP 工具或脚本作为某些任务的补充工具。未来的高效工作流很可能不是“一个 AI 工具统治一切”，而是“一个工作台调度多个专长不同的 agent”。

二十、Codex 适合哪些人？

Codex 首先适合开发者。它可以帮助开发者修 bug、实现功能、重构代码、写测试、生成 PR、解释代码库、跑本地命令。

Codex 也适合创业者和独立开发者。一个人可以同时推进 app、官网、融资 deck、launch video、社交媒体自动化。以前这可能需要产品、设计、前端、移动端、增长、运营多个人协作，现在至少可以用 Codex 快速做出初稿和可运行版本。

Codex 还适合内容创作者和知识工作者。通过自定义 skill 和 automation，用户可以让 Codex 定期分析视频、生成报告、整理邮件、总结日程、准备文档。

对于团队来说，Codex 的价值在于把代码之外的工程流程也纳入 agent 工作流，例如：

  • issue triage
  • CI/CD 失败排查
  • PR review
  • 文档更新
  • 发布说明
  • 数据迁移计划
  • 内部工具脚本

二十一、使用 Codex 的推荐方法

如果你刚开始使用 Codex，可以按以下方式上手。

第一步，建立清晰的项目文件夹。不要把所有任务都混在一个地方。为每个项目创建独立目录，并让 Codex app 的 project 指向这个目录。

第二步，先让 Codex 创建 plan。不要一上来就让它直接实现复杂系统。先让它生成 markdown 计划、任务清单、文件结构和风险点。

第三步，一个 chat 做一类任务。比如 app、web、deck、video、automation 分开跑。这样上下文更清晰，也更容易并行。

第四步，用文件引用串联工作。让 landing page chat 引用 mobile app 设计，让 deck chat 引用产品 plan，让 video chat 引用 app 截图。

第五步，频繁预览和测试。不要只看 agent 的文字总结。打开网页、运行 app、查看表格、检查幻灯片、测试表单提交。

第六步，把重复流程变成 skill。如果你第三次让 Codex 做同一件事，就该考虑让它封装成 skill。

第七步，把稳定流程变成 automation。但 automation 初期最好只生成草稿或报告，不要直接执行高风险动作。

二十二、Codex 的局限与风险

Codex 很强，但不是魔法。使用它时需要理解几个限制。

首先，设计质量不稳定。Codex 可以生成 UI 和 deck，但审美未必总是好。复杂设计仍然需要人类判断，或者结合更擅长设计的模型和工具。

其次，复杂任务需要反复纠偏。无论是 Remotion 视频、iOS app 还是数据库接入，都不是一次 prompt 就完美。用户必须会看结果、指出问题、给出更具体反馈。

第三，API key 和账号权限要小心。创建 skill 或接入第三方服务时，现实中应该避免把密钥写入普通文档或公开仓库，最好使用环境变量、密钥管理或专门的凭据配置。

第四，自动化要有边界。能自动发邮件、发推文、部署网站、改数据库的 agent，也可能自动制造错误。越靠近生产环境，越需要审计、确认和回滚机制。

第五，长任务会消耗时间和额度。多 agent 并行很爽，但也更容易消耗模型使用量。真正高效的用户会把高 effort 用在关键任务上，把简单任务交给轻量模型或低 effort。

二十三、Codex 代表的是一种新的工作方式

Codex 的意义不只是“OpenAI 又做了一个编程工具”。它代表的是一种新的工作方式：人类不再只是向 AI 提问，而是在一个项目空间里调度多个 AI agent，持续推进真实产物。

在一个完整项目中，用户可以用 Codex 同时创建 iOS app、网页、数据库、发布视频、幻灯片、社交媒体自动化和多个自定义 skill。虽然每个产物都还需要人工打磨，但它展示了一个非常清晰的趋势：未来一个人可以用 AI agent 管理更多并行项目，把想法更快变成可运行、可展示、可发布的东西。

Codex 最值得学习的地方，不是某个按钮怎么点，而是它背后的 agent 工作流：

  • 用项目组织上下文
  • 用 chat 拆分任务
  • 用文件沉淀产物
  • 用 preview 快速检查结果
  • 用 skills 复用经验
  • 用 plugins 接入外部工具
  • 用 automations 固化周期性工作
  • 用多 agent 并行扩大个人产能

如果说过去的软件开发是“人写代码，工具辅助”，那么 Codex 代表的方向是“人设计目标和判断质量，agent 执行大量中间步骤”。这并不会让人的判断变得不重要，恰恰相反，它让人的判断更重要：你要知道要做什么、怎么拆任务、哪里需要检查、什么时候该停、什么结果可以发布。所以，Codex 最适合的用户，不一定是最会写代码的人，而是最会定义任务、组织项目、审查结果、沉淀流程的人。

二十四、参考资料

  • OpenAI Help Center：Using Codex with your ChatGPT plan

    https://help.openai.com/en/articles/11369540-codex-in-chatgpt

  • OpenAI：Introducing the Codex app

    https://openai.com/index/introducing-the-codex-app/

  • OpenAI Academy：How to get started with Codex

    https://openai.com/academy/codex-how-to-start

  • OpenAI：Codex

    https://openai.com/codex