OpenAI的Jason Liu写了一篇文章，教普通用户用“今日工作概览”这个例子来使用Codex。分六步，在一步步优化中教会Codex的基本用法。
原文在：jxnl.co/writing/2026/05/18/six-levels-of-complexity-of-an-ai-powered-morning-brief-with-codex/
翻译下：
Codex 今日工作概览的六个复杂度层级
====================================
这是我所知道的、教别人使用 AI 最容易的方式。
不是从 models、agents，或者某种抽象的技术能力分类开始。要从一个大家本来就理解的工作开始，然后让这项工作在不知不觉中变得更强。
今日工作概览之所以有效，是因为几乎每个人本来就有自己的工作概览。他们只是整理得很糟。
我认为今日工作概览是普通人真正能理解的第一个 Codex workflow。
你醒来，打开 Slack，查看日历，点进邮箱，忘了自己为什么要打开邮箱，又回到 Slack，然后意识到七分钟后有个会议，而你完全不知道昨天发生了什么。
它的吸引力很直接：帮我记住现在到底发生了什么。
当我们讨论 Codex onboarding 的时候，这是第一个既足够普通、适合教学，又足够有用、值得重视的 workflow。它一开始只是一个很朴素的导向 prompt。持续推进之后，它会变成一个相当好的模型，用来说明人们实际上是怎样逐渐认真使用 Codex 的。
从初学者能理解的事情开始。然后每次增加一项真实能力，直到整个系统的形状变得清晰。
我认为这里有六个真正的层级。
----------------------------------------------------------------------
Level 1：问你真实的一天正在发生什么
----------------------------------------------------------------------
第一个版本小到几乎有点不好意思。
连接 Slack、Gmail 和 Calendar，然后问：
使用 Slack、Gmail 和 Calendar，告诉我今天有什么事。
先看看 Codex 能不能跨过你工作通常散落的三个地方，告诉你一些你确实关心的事情。
也许它会注意到 Slack 里有人在等你回复的 thread。也许它会找到你忘记准备的会议。也许它会发现一封邮件，而那封邮件会改变那场会议本身的主题。
如果它让你一天开始的前十分钟更清爽，那它就有用了。
----------------------------------------------------------------------
Level 2：添加一个 agents file
----------------------------------------------------------------------
第二层是加入一点持久化指令。
你已经有足够多的原始信息让 Codex 发挥作用了。现在你需要让它不要每天早上都只是泛泛地帮忙。
这就是 agents file 有用的地方。它不是某种基础设施术语，而是一个用来说明你希望这项工作默认如何呈现的地方。
对于今日工作概览，可以像这样写：
给我一份今日工作概览。
重点关注：
- 正在等我回复的人
- 需要准备的会议
- 我昨天承诺过但还没有完成的事项
- 夜间发生、会影响今天优先级的变化
使用清晰的标题和 bullet points。
将概览组织为：
- To-dos
- Needs replies
- Project-level updates
对于 “Needs replies” 中的任何事项：
- 包含直接的 Slack 链接
- 说明对方在等什么
- 提供刚好足够的上下文，让我决定是否现在回复
保持简短、有结构、易于浏览。
你不需要担心这个文件放在哪里。只要告诉 Codex：
我希望你把这些保存到你的 agents file 中，
这样你每次准备我的今日工作概览时都会使用它。
然后粘贴上面的指令。重点是只定义一次你的偏好，让以后的每份概览都从这里开始。
你不是为了显得高级。你只是想让明天早上比今天早上少一点烦躁。
对于其他工作，指令会不同。Recruiter 可能希望按候选人分组。Engineer 可能希望 blockers 和 code review 分开。Comms 人员可能希望把外部扫描和内部请求分开。但动作是一样的：先给 Codex 真实上下文，再给它你的默认偏好。
----------------------------------------------------------------------
Level 3：让它持续关注这件事
----------------------------------------------------------------------
第三层是加入 recurrence，但我不认为应该把它教成“创建一个 automation”。
我会说：
每个工作日早上持续关注这件事。
这是人们真的记得住的指令。
在底层，是的，你是在把今日工作概览变成一个 recurring automation。但在实际使用中，你只是说：这件事足够有用，我希望它自己回来。
价值单位不再是“我记得去问”。而是“概览已经在那里等我”。
而且因为它存在于同一个 thread 中，你可以不断调整它，而不必从头重写 prompt。如果它过度重视日历事件，就告诉它。如果它总是漏掉 Slack 里的未完成事项，也告诉它。如果它应该区分 needs reply、needs prep 和 worth knowing，那就教它一次，让这个 thread 继续带着这个偏好往后走。
这就是为什么我更喜欢 thread 版本，而不是通用的定时报告。你指出的问题越多，概览就越好。
Recurring prompt 可以保持很短：
每个工作日早上持续关注这件事。
检查 Slack、Gmail 和 Calendar。
告诉我：
- 什么需要我的注意
- 我应该为什么做准备
- 有哪些变化是我可能错过的
- 什么事情看起来卡在我这里
保持简短。
如果没有重要变化，就直接说没有。
到这里，今日工作概览开始产生实际价值。你醒来时，已经有东西帮你完成了对信息泥潭的第一轮整理。
----------------------------------------------------------------------
Level 4：把它分成多个项目级概览
----------------------------------------------------------------------
最终，一份概览会变得含混。
这在对话中直接出现过。我其实不想永远只有一个通用的 daily assistant。我通常会有多个项目 thread，每个 thread 都给我自己的今日工作概览。
- 一个 thread 用于一次 launch。
- 一个用于某个项目。
- 一个用于 open source。
- 一个用于类似 chief-of-staff 的个人事项处理。
每个 thread 对“重要”的定义都不同。
项目 thread 关心 blockers、PRs、决策，以及某个承诺过的 draft 到底有没有完成。
Recruiting thread 可能关心今天要来的候选人的 interview brief，以及夜间是否有任何背景变化。
个人 thread 关心消息、排期、旅行，以及那些一直低强度存在、但没有消失的责任。
这时，pinned threads 的意义就很明显了。Recurring 今日工作概览不只是一份报告。它是一种让每个项目以自己的方式保持活跃的办法。
prompt 变得更好的原因是，thread 已经知道你说的那个 “launch thing” 指的是什么。
----------------------------------------------------------------------
Level 5：让概览起草后续工作
----------------------------------------------------------------------
到了这一层，今日工作概览不应该只是告诉我发生了什么。它还应该起草那些由概览自然产生的工作。
- 起草 Slack 回复，但不要发送。
- 整理候选人 brief。
- 写会议准备笔记。
- 总结我回复前应该阅读的那个 thread。
- 告诉我哪个决策看起来卡在我这里。
一份好的 Level 5 概览结尾可能像这样：
这里是我会优先回复的三条消息。
我已经为每条起草了回复。
这里是两个值得准备的会议。
这里是一个看起来卡在你这里的决策。
我希望概览把几件显然要做的工作先完成一部分，而不是只给我另一份要读的 summary。
这也是我开始更多使用手机的地方。如果上下文收集已经在我打开电脑前完成，我可以在走动时看一眼概览，批准一件小事，或者只是决定等我坐下来以后，什么才真正值得关注。
----------------------------------------------------------------------
Level 6：把重要内容保存到 memory vault 中
----------------------------------------------------------------------
第六层是今日工作概览不再只是一个早晨仪式，而是开始给一个记忆系统提供信息。
如果今日工作概览不断发现同样的人、同样的项目、同样的未完成事项和同样的决策，那么其中一些内容应该离开 thread，变成可长期保存的东西。
- 把重要内容写下来。
- 更新项目笔记。
- 记录未完成事项。
- 添加不应该被忘记的决策。
- 保留那些会让下周概览变得更好的上下文。
这时我会开始使用 vault。简短地说，我喜欢把 memory 做成文件，因为这些文件我可以检查、比较差异，并在不同 thread 之间复用。
最小的可用版本可能像这样：
vault/
|-- TODO.md
|-- people/
|-- projects/
|-- daily/
|-- notes/
`-- AGENTS.md
这个结构很直观：
TODO.md
让未完成事项不至于消失在聊天记录里。
people/
存放关于常见协作者的长期上下文。
projects/
存放重要 workstreams 的状态。
daily/
给每一天一个地方，用来留下当天重要的事实。
notes/
用来存放更松散的研究内容或一次性 memo。
AGENTS.md
告诉 Codex 如何使用这个 vault，而不是每次都重新发明结构。
你也应该更新 agents file，让概览在输出前先读取 vault。比如：
在写我的今日工作概览之前：
- 查看 TODO.md 中的未完成事项
- 查看 people/ 中相关协作者的上下文
- 查看 projects/ 中活跃 workstream 的状态
- 查看 notes/ 中近期可能改变今天优先级的背景信息
使用这些 vault 上下文，让概览更具体，也更少遗忘。
当概览有了足够的结构后，你还可以让 Codex 使用 subagents 并行搜索。一个可以查看未完成的 to-dos，一个可以扫描项目笔记，另一个可以查看近期人员上下文，然后主 thread 汇总真正的概览，并在有实质性变化时更新底层文档。第一天不需要这样做，但当概览的组成部分多到让一次串行处理显得慢、浅或过时时，它就会变得有用。
你也可以让 Codex 回顾你已经在做的工作，并向你提问，帮助把 vault 组织得更好。它可能会注意到同一个人出现在三个项目里，某个项目还没有清晰的笔记，或者你的 TODO.md 把个人杂事和 launch blockers 混在了一起。这种来回很有用。当 Codex 被允许说“我觉得这个内容应该有个更合适的位置，它应该放在哪里？”时，vault 会变得更好。
当今日工作概览能在运行前读取 vault，并在有实质性变化后更新 vault，它就会变得更好。明天的项目概览可以记住上周那个未完成的决策、仍然需要回复的人，或者那条不应该因为 thread 变长就消失的状态备注。
----------------------------------------------------------------------
为什么我喜欢这条阶梯
----------------------------------------------------------------------
每一层都教会用户一种更认真使用 Codex 的方式，而不要求用户一上来就跳进某种宏大的 agent 架构。
Level 1
教 connectors。
Level 2
通过 agents file 教 defaults。
Level 3
通过让 Codex “keep an eye on this” 教 recurrence。
Level 4
教 durable threads 中的项目级概览。
Level 5
教我真正关心的信任边界：起草工作，但不要冒充我。
Level 6
教会最会复利增长的部分：把长期上下文保存到 vault 中，
让明天的概览从比今天更聪明的地方开始。
这就是为什么我会用今日工作概览来教 Codex。它一开始只是一个简单 summary，最后会变成你工作的一个微型 operating system。
#AI创造营#