点击上方 程序员成长指北，关注公众号
回复1，加入高级AI交流群
Codex 小白入门：从安装到插件、MCP、Skills，一篇把配置讲明白
DeepSeek、Kimi、Qwen、GLM 怎么接入 Codex？这篇一次讲清楚
别再把 Harness 和 Loop 吹玄了：研发工程师真正该补的是这层能力
OpenAI 最近发了一份 Codex 白皮书，标题叫 Codex-maxxing for long-running work。
上面这张是 OpenAI Developers 文档里的 Codex App 官方界面截图。能让读者先看到：这里讨论的不是抽象的聊天机器人，而是一个包含项目、线程、产物审查和执行过程的工作台。
如果只看表面，它像是一份 Codex App 使用技巧清单：置顶对话、语音输入、追加指令、记忆、工具、手机远程、定时任务、Goal、侧边面板。
但我读完以后，觉得真正值得抄的不是某一个技巧，而是它背后的工作方式。过去我们用 AI，默认是“一问一答”：我发一个 prompt，它回一个结果。这个模式适合查资料、改一段代码、写一小段文案，但它很难处理真正的工作。
真实工作不是一次问答。它是跨天的，是有上下文的，是需要等别人回复的，是中途会改方向的，也是要不断检查结果的。你今天说过的背景，明天还要接着用；你早上开的任务，下午可能才有结果；你让 AI 做的东西，最后还得有人来判断能不能用。
所以 Codex-maxxing 这份白皮书真正想讲的，其实是把 AI 从“聊天框”变成“长期工作系统”。下面这 10 个技巧，可以直接照着抄，但更重要的是，你要看到它们是怎么连在一起的。
1. 给每条重要工作线开一个置顶线程
第一个技巧很简单：不要什么事都新开一个对话。
如果你手上有一个会反复推进的项目，比如一个产品功能、一篇长期写的文章、一个客户问题、一个持续维护的代码库，最好给它单独开一个线程，然后置顶。
这件事看起来只是“整理聊天列表”，其实是在改变 AI 的工作单位：以前一个对话对应一个问题，现在一个线程对应一条工作线。
你可以在第一条消息里写清楚背景：这个项目是什么、现在做到哪、哪些决定已经定了、你的偏好是什么、什么事情必须问你、什么事情可以自己推进。之后每次回来，都继续在这条线程里说。
这样 Codex 不用每次从零开始理解“我们在干什么”。它接的是同一条线，也更适合那种“今天做不完，但会一直回来”的长期任务。
2. 用语音把模糊想法直接倒进去
很多人低估了语音输入。语音的价值不只是快，而是它更接近你的真实思考。打字的时候，人会下意识地修饰、删减、组织语言。结果是 prompt 看起来更整齐，但信息反而变少。
你真正想说的可能是：
我记得上周有人在 Slack 里提过这个问题，但我忘了是谁，你帮我找一下，然后看看这次改动会不会影响那个场景。
这句话如果打字，你可能嫌麻烦，最后只写成“帮我看一下影响”。但对 Codex 来说，前面那堆含糊的背景非常有用。
白皮书里提到，语音可以把未整理的想法、会议转录、临时灵感直接送进 Codex。它不是为了写出完美指令，而是为了让 AI 先拿到足够多的上下文。
我的建议是：越早期、越模糊的任务，越适合用语音。不要等自己想清楚再发给 AI，很多时候，让 AI 帮你把“没想清楚”整理成可执行计划，才是最省时间的用法。
3. 在它工作的时候继续追加方向
以前我们习惯等 AI 完整回答完，再指出哪里不对。Codex 的新工作方式更像和同事一起看同一个东西：它在跑，你也可以继续说。
比如它正在改一个页面，你可以中途补一句：
这里不要做成营销页，做成工具界面； 这个按钮文案太夸张，收一点； 等测试跑完以后，顺手把 PR 描述也写了； 如果发现影响范围太大，先停下来给我选项。
这就是白皮书里讲的 steering。它解决的是一个很真实的问题：工作不是线性的。你一开始给的指令，经常不是最终指令。看到中间结果以后，你才会意识到哪里要改。
所以不要把 Codex 当成“发出去就等结果”的黑盒。更好的方式是让它边做边汇报，你边看边校准。这个技巧尤其适合设计、前端、文章、重构这类任务，因为这些任务不是只有“对/错”，中间会有很多品味和判断。
4. 把记忆写成你能检查的文件
长期工作最大的问题是上下文会丢。
聊天记录当然也是上下文，但它有两个问题：一是太长以后不好检查，二是你很难知道 AI 到底记住了什么。所以白皮书里很强调一个动作：把记忆写到文件里。
比如建一个 memory 或 vault 仓库，里面放几类文件：
people.md | |
projects/xxx.md | |
decisions.md | |
todo.md |
然后告诉 Codex：每次任务结束前，把值得记住的内容更新进去。
这一步的关键不是“让 AI 记性更好”，而是让记忆变成可审查的资产。
你可以看 diff。写错了就改，漏了就补，不重要的就删。相比让记忆静悄悄地躺在聊天历史里，文件化记忆更可靠，也更适合团队协作。
这也是我觉得 Codex-maxxing 里最重要的一条：长期工作必须留下结构化痕迹。否则每个新线程都会重新变成“你好，请先理解一下我的项目”。
5. 搞清楚不同工具该用在什么场景
很多人用 AI 工具用得乱，是因为没分清工具边界。Codex 现在不是只有一个聊天框，它可以接很多能力：浏览器、Chrome、Computer Use、GitHub、Gmail、Slack、Calendar、各种 MCP 和插件。但工具越多，越要先判断场景：
这件事听起来像工具说明书，但真正的意义是：让 Codex 能碰到真实工作现场。
以前 AI 的能力边界主要是模型本身。现在更重要的边界是：它能看见什么，能操作什么，能不能把结果带回同一个工作流。
当然，权限越大，责任也越大。凡是会发消息、改权限、提交内容、删除东西的动作，都应该让它先起草、准备、解释，由人来批准。
6. 用手机远程处理“卡住的那一下”
长期任务最容易死在一个小地方。不是模型不会做，而是它中途需要你判断一下：选方案 A 还是方案 B？要不要继续跑这个命令？这个改动范围能不能接受？需要不需要发给别人？如果你不在电脑前，任务就停在那里。
OpenAI 在官方文章里也强调了 Codex 的移动端体验：当 Codex 在你的电脑、开发机或远程环境里继续工作时，你可以用手机查看进展、回复问题、批准下一步。
这改变的不是“手机也能用 Codex”，而是长任务不必因为你离开电脑而中断。一个很实用的写法是，在布置任务时提前说清楚：
遇到依赖安装、测试失败、需要外部账号操作时先停下来问我；其他小的实现细节你自己决定。每完成一个阶段给我摘要和下一步建议。
这样你在路上、吃饭、开会间隙，只需要处理真正需要你判断的节点：AI 负责推进，人负责拍板。
7. 给重复任务设置自动化
白皮书里另一个非常关键的能力是 Heartbeats。OpenAI 开发者文档里对应的是 thread automations：附着在当前线程上的定时唤醒。
它的意思是，让 Codex 定期回到同一个线程里检查事情。比如：
每 30 分钟检查一次 Slack 和 Gmail，找需要我回复的消息，整理背景并起草回复； 每天早上 9 点检查 GitHub 仓库的新 Issue 和 PR，标出今天需要处理的； 每 15 分钟看一次评论区或文档反馈，有新反馈就汇总成修改建议； 每隔几分钟检查一个排队状态、客服状态或部署状态，有变化就准备下一步。
这和普通提醒不一样。普通提醒只是告诉你“该看了”，Thread automation 则是让 Codex 带着上下文回来“继续处理”。它最适合三类循环：
这里的核心原则还是那句话：它准备，你决定。不要一上来就让自动化替你发送、删除、发布。先让它巡查、总结、起草、标出风险。等你确认以后，再进入下一步。
8. 把 Goal 写成可验证的完成标准
很多人写目标，只写愿望。比如：
帮我重构这个模块。
这对 AI 来说太虚了。什么叫重构完成？测试要不要跑？性能有没有要求？改动范围多大算合理？失败时要不要停下来？
更好的写法应该把完成标准一起写进去：
帮我重构这个模块。完成标准是：原有单元测试全部通过；没有新增 lint 错误；对外 API 不变；把关键改动点写在总结里；如果发现需要改接口，先停下来给我方案。
这就是 Goal 的价值：不是把任务说得更宏大，而是给 Codex 一个可以持续逼近的终点。
白皮书里有一个很重要的判断：ambition without verification is just a wish。目标如果没有验证方式，只是愿望。
所以布置长期任务时，一定要补上三件事：
写文章也是同样的逻辑。不要只说“帮我写一篇文章”，可以说：
写一篇公众号文章，完成标准是：标题有点击理由；开头 100 字讲清楚读者痛点；主体有 3 个核心观点和具体例子；结尾给出可执行清单；不要一行一句；写完后检查是否有占位符。
这样 Codex 才有自检的依据，而不是写完一篇看起来完整、但不知道是否达标的稿子。
9. 把侧边面板当成协作现场
很多人把 Codex 的侧边面板当预览窗口，但白皮书里更想表达的是：侧边面板是工作发生的地方。
Markdown、表格、CSV、PDF、幻灯片、网页、Storybook、Remotion、Streamlit，这些都可以变成 Codex 和你共同查看、共同修改的对象。
这和传统聊天有很大区别。聊天里，你只能描述“第三段有问题”；侧边面板里，你可以看着文章、页面、表格说：“这里逻辑不对”“这个表格第二列公式错了”“这个按钮太亮了”“这一页幻灯片内容溢出了”。产物本身变成了下一轮上下文，这对非代码任务尤其重要，因为文章、PPT、表格、页面都不是只靠文字描述就能判断好坏的东西。你需要看它的结构、排版、状态、交互和实际输出。
所以以后让 Codex 做东西，不要只让它在聊天里给结果。能生成文件就生成文件，能预览就预览，能批注就批注。让任务从“讨论一个结果”，变成“共同修改一个对象”。
10. 把这 10 个动作连成一个闭环
单独看，这 10 个技巧都不复杂。它们真正厉害的地方，是连起来以后会变成一套闭环：
这才是 Codex-maxxing 这个词的真正含义。它不是“把 Codex 用到极致”，更不是“写一个神奇提示词”。它是把工作拆成可以被 AI 长期参与的结构：有上下文、有目标、有工具、有记忆、有检查、有人的判断。
普通人今天怎么开始抄？
如果你不想一次配置太多东西，可以从三个最小动作开始。
第一，给一个长期项目开置顶线程。第一条消息写清楚项目背景、当前状态、你的偏好、完成标准和停止条件。
第二，建一个最简单的记忆文件。哪怕只有 project.md 和 decisions.md，也比完全依赖聊天历史强。每次任务结束，让 Codex 更新一次。
第三，给一个重复检查任务设置自动化。比如每天早上检查 GitHub、每 30 分钟看一次等待回复、每周整理一次文章选题。先让它只做摘要和草稿，不要直接执行高风险动作。
这三个动作跑起来以后，你会明显感觉到变化。AI 不再只是“你问一句，它答一句”，它开始像一个会回到现场的协作者：知道你们之前说过什么，知道这件事下一步该看哪里，知道什么情况该停下来问你，也知道怎么把结果留在一个你能检查的地方。这才是这份白皮书最值得抄的地方：不是 10 个孤立技巧，而是一个新习惯，把工作交给 AI 之前，先把工作变成一个可持续推进、可验证、可审查的循环。
参考资料
OpenAI：Codex-maxxing for long-running work OpenAI PDF：Codex-maxxing for long-running work whitepaper Jason Liu：Codex-maxxing OpenAI：Codex OpenAI Developers：Codex OpenAI Developers：Automations - Codex app
Codex 小白入门：从安装到插件、MCP、Skills，一篇把配置讲明白
DeepSeek、Kimi、Qwen、GLM 怎么接入 Codex？这篇一次讲清楚
别再把 Harness 和 Loop 吹玄了：研发工程师真正该补的是这层能力
我组建了一个氛围特别好的 AI 社群，里面有很多 AI Coding小伙伴，如果你对AI 学习感兴趣的话（后续有计划也可以），我们可以一起进AI相关的交流、学习、共建。下方加 考拉 好友回复「AI」即可。
“分享、点赞、在看” 支持一波?
