五月十号，Twitter 上刷到 jxnl 转出来的一个链接，标题叫 Codex-maxxing。
jxnl 是 Jason Liu，AI 工程圈那种看一眼名字就知道是干净货的研究员，instructor 库作者，《如何让 LLM 听话》这件事上最被人引用的那批人之一。不写鸡汤，不带货，不蹭话题。发文不勤，每篇都被一线 builder 转。
这篇在英文圈被疯传。但中文圈到现在还没什么像样的解读。
所以下面这件事值得做：把骨头拆出来。
工作的最小单位变了
帖子的核心论点只有一句话：
Codex 改变的不是写代码，是给了“工作”一个可以持续呆下去的地方。
听起来像在说上下文长度，但他讲的不是这件事。他在讲一件更大的事。
过去十几年，知识工作的最小单位是“一次会话”。打开邮件写一封，打开飞书发一条，打开 ChatGPT 问一个问题，得到答案，关闭。
每件事都是首尾闭合的。
可你脑子里在跑的工作不是这样的。脑子里随时有十几条若隐若现的线索。一个客户上周问的问题还没回。一份报告想加段数据但还没找到。一个工具想试但还没开账户。一个想法昨晚冒出来今天又忘了。
塞进“一次会话”里，要么塞不下，要么每次都要重新讲一遍背景。
所以它们就停在脑子里，断断续续地耗注意力。
jxnl 的观察是：Codex 这一代工具，第一次给每一条这样的线索准备了一个可以长期住下来的容器。
工作的最小单位变了。
零件一：Pinned Thread
钉住一个长期会话，让它专门盯一件事。
jxnl 自己钉了好几个：一个叫 Chief of Staff，每天扫 Slack 和邮件；一个盯 Twitter 动态；一个盯 OpenAI CLI；一个盯 Codex 开源项目。
这些都不是短聊。每一个都是已经 compact 过好几个月的 megathread。compact 是把长 thread 压缩成下一段还能继续用的状态。
他承认这件事有成本。长线程不在缓存里，每次回访比新开一个 thread 更贵。但对他在乎的工作流，连续性比这点钱重要。
这句话翻译过来是：单次成本贵一点不要紧，工作能积累，才是真正稀缺的东西。
一个跑了三个月的 thread，见过你所有的偏好和取舍，它现在的判断方式跟一个新开 thread 完全不一样。
这种“性格”是无法用 prompt 一次喂出来的。
零件二：用语音把未加工的思考喂进去
如果说 pinned thread 解决了“工作能不能续命”的问题，语音输入解决的是另一个被严重低估的问题：
你愿不愿意把脑子里那些没成形的东西，老老实实交给 agent。
jxnl 在帖子里讲得很直接：语音输入的价值不是快，是 agent 能拿到“未加工版”的思考。
如果让他打字，他大概会写“请帮我搜索 Slack 里关于产品发布的讨论”，一个被整理过的、礼貌的、有结构的指令。
但如果他用语音，他会脱口而出：“我记得 Slack 里有个叫 Ben 的家伙提到过一个事，我也不太记得具体是啥，你去翻一下。”
后一句话太模糊也太懒，正常人不会打字打出来。但说出来毫无心理负担。
这一点至关重要。
输入的颗粒度，决定了输出的天花板。你给 agent 的，永远只是你愿意为它整理的那一部分思考。语音让你愿意整理的部分扩大了，可能不止扩大一倍。
打字时代的工作流，是“想清楚 -> 写下来 -> 让工具执行”。
语音时代的工作流，可以是“边想边说 -> agent 替你梳理 -> 你再判断”。
后者的认知负担小得多，但能进入工作流的素材多得多。
零件三：把记忆从 thread 里搬出来
这一段是整篇帖子的灵魂。
jxnl 的观察：long thread 能让 agent 学到很多东西，但这些东西被困在 thread 里。一旦 thread 崩了、compact 坏了、或者你想换模型重启，几个月攒下来的“性格”就一起没了。
解法是让 agent 把学到的东西，写到一个独立的笔记本里。他用的是 Obsidian vault。
可以把它想成给一个新来的助理准备的活页夹。里面分五栏：待办、人物、项目、助理须知、随手笔记。最前面放一张纸条，写规则。
你每次和我聊完，对某个人有了新的了解、某个项目有了进展、某件事终于解决了，就翻到对应那一栏写一笔。
这一步本身不稀奇。
他的关键操作是再往后一步：让笔记本每被改一次，都留一份昨天版和今天版的对比。
每天扫一眼这个对比，看 agent 替你记下来的内容，是不是你想让它记的内容。记岔了，改掉，补一条更准确的规则上去。
读到这一段会发现一件事：
助理的记忆，是要审稿的。
你不会想让一个工具替你记下来的东西，是它自己揣摩出来、含糊的、永远不暴露在你面前的“印象”。
要的是看得见、能校对、能擦掉重写的记忆。
这一步把 Codex 从一个聪明的工具，慢慢变成一个你可以反复教的同事。
教错了能改。教对了它会延续。不用每次都靠你重新解释。
零件四：Heartbeat
前三个零件解决“工作能不能续命、能不能被充分喂进料、能不能被反复教”的问题。
这一个解决“工作能不能自己往前走”。
jxnl 的描述：让一个 thread 自己定时醒一次，去看世界有没有变化，再决定要不要动手。
帖子里最让人记住的是亚马逊那个例子：他被偷了一个包裹，客服排队要等 25 分钟。他开了一个 thread 告诉它，每五分钟看一次客服窗口，人来了就帮我去争取退款；客服一回话，频率改成每分钟一次。然后他去洗澡了。出来时退款已经办好。
“持续运行的工作”在这里第一次变得非常具体：一段每隔几分钟会执行一次的代码，一个会自己调整频率的循环，一个能跨越“我在不在电脑前”这件事的耐心。
这种耐心人类做不到。连续两小时每五分钟刷一次客服窗口、保持不分心，是反人性的。但 Codex 没有走神这回事。
把这种耐心嵌进工作流，节奏会变。
最直观的变化：你可以走开了。
下楼买杯咖啡、接个孩子、洗个澡，回来时它已经替你往前挪了一点点。
听起来很小。但用过一两次之后，很难再回到“必须守在桌前才算在工作”的旧节奏。
代价是重新学习协作
这套打法不是没有代价。
最大的代价是：你必须重新学一遍怎么跟工具协作。
过去用 ChatGPT，是“我有事问你”的关系。现在用 Codex，是“我们一起在管一摊事”的关系。
前者掌控感很强。后者你必须放掉一部分掌控感。允许它在你不看的时候做决定。接受它偶尔会做错。接受你必须花时间去审稿它的记忆，而不仅仅享受输出。
这个过渡期会让人觉得别扭。前两周经常会忍不住跳进去亲自干，因为亲自干比教它干快。
但跨过这个坎之后，你会得到一种过去没有过的杠杆。
工作产出不再被自己的注意力总量框死。
并不是所有人都需要这个杠杆。如果你的工作本身就是高度即时的，销售现场、客户面谈、紧急响应，把工作交给一个异步循环反而会添乱。
但如果你的工作里有大量“需要持续盯但不需要时时盯”的部分，内容创作、知识管理、客户跟进、信息消化，那就该认真考虑了。
把工作单位从一次会话升级到一个循环。
把 Codex 当成“会写代码的 AI”，是一个严重的低估。
它改的不是单次问问题的质量。
是工作和你之间的关系：过去工作是死的，要你不断启动；现在工作可以是活的，自己往前爬一段。
工作不再死在两次对话之间。
这是 Codex-maxxing 这篇帖子留给中文读者的、最值得带走的那一句话。