小学生也能看懂 ChatGPT Work 与 Codex 的关系

很多人把 ChatGPT Work 和 Codex 当成两个产品，结果越看越懵。

我折腾了一圈后发现，理解它们只需要记住一件事：一个更适合云端，一个更适合本地。

搞懂这层关系后，很多过去要靠 OpenClaw、脚本和自动化平台才能做的事，现在用 Work + Codex 就能串起来。

我最近拿它们做了一件事：把滴答清单从“存待办的地方”，改造成一个会提前推进任务的系统。我负责把脑子里的想法丢进去，Work 负责整理和判断，Codex 负责研究和回写。等我准备处理某件事时，背景资料、方案比较、技术路线、风险点，可能已经躺在原来的 Todo 下面。

这套东西有意思的地方，不是 AI 帮我记了一条待办。语音记事、自动分类、自然语言建任务，这些能力早就不稀奇。变化发生在后半段：一条待办进入系统以后，不必躺在 Inbox 里等我某天想起来，它可以进入下一条处理链路，让 Agent 提前完成未来执行需要的信息准备。

不过在讲工作流之前，有件事必须讲清楚：ChatGPT Work 和 Codex 到底是什么关系。这个问题第一次碰到时，我也花了一些时间梳理，因为两个产品的能力边界容易混在一起。

Work 和 Codex

理解这两个东西，可以从“任务在哪里运行”开始。Codex 的优势来自本地环境。权限配置完成后，它可以接触电脑里的代码、文件、项目和本地工具，也能使用保存在设备里的 Codex 会话。对于开发、文件处理、批量操作、本地环境调用，这种模式有天然优势。代价也很明确：电脑是执行环境，离开设备之后，访问方式会受到限制，需要 Remote 一类能力把入口延伸出去。

ChatGPT Work 多了一层云端执行能力。在网页端和手机端使用时，任务运行在云端，因此它适合跨设备使用，手机发起，网页继续，会话也可以同步。云端环境与个人电脑之间存在边界，所以它不会天然拥有电脑里的本地文件。到了桌面端，Work 又可以选择本地运行，让 Agent 进入设备环境。

所以我现在不会用“谁取代谁”的方式理解它们。我更习惯用执行位置区分：需要跨设备、手机随手发起、云端持续处理的任务交给 Work；需要本地文件、项目、历史环境和设备上下文的任务交给 Codex。

这也是我这套 Todo 工作流成立的基础。输入发生在任何地方，手机最方便；深度处理依赖电脑环境，本地 Agent 更合适。两个入口负责两类不同工作。

问题不是记录

我平时用滴答清单管理待办，里面有大量标准任务，比如开会、买东西、缴费、打电话，也有另一类东西：模糊的想法。比如“研究这个产品能不能做”“看看某个开源项目能不能接入现有流程”“比较两种方案的成本”“找一下某个行业最近出现了什么变化”。

后一类任务的问题在于，它们不是动作，而是一个待展开的问题。写进 Todo 的那一刻，我往往只有一个念头，没有标题结构，没有背景信息，没有执行步骤，也没有明确结论。

Inbox 一多，这些东西会变成一堆半成品。表面上它们被记录下来了，实际上任务并没有向前移动。每次准备处理一条，我需要打开滴答清单，找到原记录，把它复制给 Agent，补充背景，解释目的，做调研，比较方案，确认可行性，最后才进入执行。

这意味着 Todo 只是保存了“未来需要重新启动思考”的入口。记录动作完成了，思考成本没有消失。

我想解决的，就是这部分成本。

输入端只负责收

第一步，我在 ChatGPT 手机上固定了一个 Work 对话，并接入滴答清单 MCP。我给这个对话设定了一个清楚的职责：这个窗口不是普通聊天窗口，而是 Todo Inbox。

只要内容进入这个对话，Work 会按待办信息处理。它需要识别用户意图，整理任务标题，判断所属项目，提取日期和提醒，并把任务写入滴答清单。如果我说的是一句模糊的话，例如“这周看看能不能把那个内容监控流程接到飞书”，它不能原样抄进去，而要把口语转成一个未来可执行的任务。

手机端的体验在这里非常关键。Android 版可以把指定对话放到桌面，我把这个 Todo 对话做成了一个单独入口。脑子里冒出什么内容时，我点开图标，用语音输入说完，然后关掉。

输入过程里，我不需要想“这条属于哪个项目”“标题怎么写”“哪天提醒”“是否需要补描述”。这些结构化工作交给 Work。

这样做以后，手机承担的是捕获，滴答清单承担的是存储。输入端的任务只有一个：把念头送进系统。

第二层：判断

但做到这里，价值有限。AI 帮忙建 Todo，省的是几十秒到一两分钟。真正占时间的是任务进入滴答清单后的处理。

所以我给 Work 加了一层判断：每次创建任务时，需要判断这条 Todo 是否值得 AI 做预处理。

比如这些任务，通常有研究价值：产品研究、竞品比较、技术调研、实现方案调查、资料整理、可行性分析、决策辅助、背景信息收集。

而“周三 11 点开会”“买洗衣液”“交水费”“给某人回电话”没有研究价值。Agent 不应该看到任何 Todo 都启动搜索，否则系统会制造大量没有意义的内容，还会浪费模型调用和注意力。

这里的关键不是“让 AI 多做事”，而是让 AI 学会判断什么事值得提前做。

我的规则是：只有 AI 预处理能够降低未来执行成本，才进入研究队列。

如果某条任务满足条件，Work 会给它加一个标签：

#AI待处理

这个标签不代表任务完成，也不代表 AI 一定要给出长报告。它只代表一件事：这条 Todo 值得进入下一阶段。

从这一刻开始，滴答清单里出现了两类任务。一类是普通 Todo，等人执行；另一类是带 #AI待处理 的 Todo，等待 Agent 做前置准备。

标签就是接口

这套系统里，我没有设计复杂数据库，也没有给 Work 和 Codex 做专门通信层。两个 Agent 之间的接口，就是滴答清单里的标签。

Work 只做输入和判断。它不负责后续调研，也不用知道 Codex 什么时间运行。

Codex 只扫描符合条件的任务。它不关心任务来自语音、文字、手机还是网页，也不关心是谁创建的。

中间靠四个标签维持状态：

• #AI待处理：任务进入研究队列。
• #AI调研中：Codex 正在处理。
• #AI已调研：研究结果已经成功写回。
• #AI调研失败：本轮执行失败，需要后续重试。

这几个标签看起来朴素，但它们解决了自动化系统里一个重要问题：状态管理。

如果没有状态标记，Agent 很容易重复处理同一条任务，也无法知道某个任务是否卡在中间，更难处理搜索完成但写回失败的情况。有了标签以后，每条 Todo 都有一个明确阶段。

这相当于用滴答清单搭了一个轻量任务队列。

Codex 开始接管

下一步，我在 Codex 里设置 Automation，让它按固定周期检查滴答清单。

执行逻辑不复杂：找出所有带 #AI待处理、没有 #AI已调研、状态仍为未完成的任务，然后逐条处理。

假设任务是：“研究一下某个 AI 视频产品适不适合做商单内容。”

Codex 不应该把这句话扩写成一篇泛泛的行业报告。它要判断未来执行这条 Todo 需要什么信息，比如产品定位、核心功能、目标用户、近期更新、竞品差异、商业合作角度、可演示场景、潜在风险。

如果任务是：“比较 A 和 B 两套自动化方案。”

输出重点应该变成成本、稳定性、接入难度、运行环境、维护成本和适用条件。

如果任务是：“看看某个开源项目能不能接到现有工作流。”

Codex 则需要检查仓库、文档、依赖、接口、安装条件和兼容性。

也就是说，Automation 的职责不是“看到 Todo 就搜索”，而是判断这条 Todo 在未来执行时缺什么，然后提前把缺口补上。

报告不是目标

我对这套系统有一个限制：调研结果必须服务于 Todo，而不是服务于“写一份看起来很完整的报告”。

这是两个完全不同的目标。

很多 Agent 接到“帮我研究一下”后，会生成一堆背景介绍、概念解释、行业历史、常识性内容。文字不少，但真正开始做事时，用户还得从里面找答案。

我的要求是优先回答三个问题：核心结论是什么，哪些发现会影响决策，下一步应该做什么。

只有任务需要时，才补实现步骤、竞品、风险、注意事项和参考资料。

调研结果不创建新文档，也不丢进另一套知识库，而是追加到原 Todo 描述下面。

原因很简单：任务和准备资料应该放在一起。

如果研究结果散落在 ChatGPT 会话、网页标签、Notion 页面和本地 Markdown 里，等真正开始执行时，寻找资料又会变成一项新任务。

所以 Codex 完成处理以后，会把结果追加到原任务末尾：

AI 预处理

下面放日期、结论、关键发现、建议动作和必要来源。

我打开 Todo 时，任务本身和前置研究处在同一个页面。

失败也要设计

自动化工作流容易被忽略的一件事，是失败状态。

比如 Codex 成功搜索了资料，但滴答清单 MCP 回写失败。如果系统把任务标记成完成，这条任务会失去研究结果，也不会进入下一轮处理。

所以我的规则是：只有 MCP 确认原 Todo 更新成功，任务才算完成。

成功后，系统移除 #AI待处理、#AI调研中、#AI调研失败，添加 #AI已调研。

如果研究失败，或者回写失败，系统移除 #AI调研中，添加 #AI调研失败，同时保留 #AI待处理。

这样下一次 Automation 扫描时，这条任务仍然可以进入队列。

这一点看起来像工程细节，但只要自动化开始长期运行，它会决定这套系统到底是工具，还是一个需要人天天擦屁股的半成品。

为什么放本地

我把研究端放到 Codex，还有一个原因：上下文。

很多 Todo 单独看都缺信息。

“研究这个工具。”

哪个工具？研究什么？为了购买、写内容、接入流程，还是做竞品分析？

“比较一下这两个方案。”

比较标准是什么？成本、速度、稳定性、安全、部署难度，还是商业价值？

如果每次都从零解释，Agent 的价值会被沟通成本吃掉。

本地 Codex 可以接触设备里的项目、文件、本地会话和工作环境。对于很多持续项目，它更容易理解当前工作脉络。

假设我过去几周一直在研究某类产品，电脑里已经有相关文档、代码、历史对话和资料，那么新 Todo 出现时，它可能拥有比一条孤立提示词更多的背景。

这意味着 Todo 预处理可以从“通用搜索”变成“结合现有工作上下文的准备工作”。

这个差别会影响输出质量。

完整链路

我现在这套 Todo Agent，可以压缩成 10 步：

1. 我产生一个想法。
2. 手机打开固定 Work 对话，用语音或文字输入。
3. Work 把口语整理成结构化 Todo。
4. Work 判断项目、日期、提醒和任务类型。
5. 如果任务需要资料、比较、分析或研究，添加 #AI待处理。
6. Todo 写入滴答清单，输入流程结束。
7. Codex Automation 扫描所有 #AI待处理 任务。
8. Codex 根据任务类型完成研究、比较或可行性分析。
9. 结果追加到原 Todo，标签改为 #AI已调研。
10. 我准备执行任务时，Todo 下面已经有一份可用的前置资料。

整条链路有一个原则：输入、判断、处理、执行相互分离。

我记录想法时，不考虑调研。

Work 整理任务时，不负责执行研究。

Codex 做研究时，不关心任务从哪里产生。

我开始执行时，也不需要重新寻找前置资料。

每个环节只处理自己的职责。

它改变了什么

传统 Todo 系统的逻辑是：人产生任务，人记录任务，人未来回来处理任务。

加入 Agent 之后，Todo 可以拥有一个中间状态：人还没开始执行，但机器已经开始准备。

这个变化适合很多过去会被拖延的任务。

比如“研究一个新工具”。传统 Todo 只保存一句话，几天后打开时还是一句话。Agent 版本可以提前补上价格、功能、竞品、限制、近期更新和适用场景。

比如“看看这个 GitHub 项目能不能用”。传统 Todo 等你有时间后打开仓库。Agent 版本可以提前检查 README、Issues、依赖、安装方式和近期维护情况。

比如“比较三家供应商”。传统 Todo 只是提醒。Agent 版本可以提前整理公开资料、产品差异、价格结构和关键问题。

比如“准备一次选题”。传统 Todo 提醒你研究。Agent 版本可以提前收集信号、案例、来源和反对意见。

任务还是那条任务，但开始执行时的起点变了。

还有一个边界

这套东西不是为了让 AI 接管所有 Todo。

不少任务没有必要加 Agent。生活提醒、明确动作、简单购买、固定日程，本身执行成本低，引入 AI 只会增加系统复杂度。

我现在判断一条任务值不值得进入 AI 队列，只看一个标准：

AI 做完预处理后，我未来开始这件事时，是否会少做一段明显的信息工作。

如果答案是否定的，这条任务保持普通 Todo。

如果答案是肯定的，它才进入 #AI待处理。

这个标准可以防止系统膨胀。

最后一个坑

滴答清单国内版和 TickTick 国际版的数据相互隔离，配置 MCP 时需要确认接入的是哪一个版本。

另外，这套链路不绑定某个产品。WorkBuddy、其他支持 MCP、Automation 或本地 Agent 的工具，也可以照着这个结构搭。

工具不是重点。

核心只有四个东西：

一个低摩擦输入入口，一个任务存储层，一套状态标签，一个能消费任务的 Agent。

把这四块接起来以后，Todo 才开始从“提醒我未来做什么”，变成“在我准备动手之前，机器已经把一部分工作往前推了”。

我现在更关注的下一步，也不是让 Agent 写更多研究报告。

而是把 Todo 分成两类：需要人判断的，交给人；可以由 Agent 完成一部分的，提前处理。

当这条链路继续往下走，待办清单可能不只是“记事本”。

它更像一个给人和 Agent 共用的任务队列。

关于作者

三个三｜AI 工具实测博主｜AI 小白教程｜2 个月靠 AI 赚了5位数 ｜全平台粉丝近 10 万粉 ｜@3three_AI