前天OpenAI发布了 GPT 5.6，Codex大变样了。

今天我重新看了 2026 年 6 月 22 日，OpenAI 发布白皮书《Codex-maxxing for long-running work》。

这份文档表面在介绍 Codex 的功能与使用方式，实际提出了一套长线工作组织方法。

过去我们使用 AI，基本是一次性问答：给一个问题，拿一个结果，对话结束。下次再做相关工作，还要重新补背景、找资料、解释之前为什么这么决定。

这并没有解决真实工作里最麻烦的问题。

真实工作不是由一个个独立问题组成的。一个项目可能持续几个月，中间会有需求变更、会议结论、人员调整、开发进度、用户反馈和待确认事项。真正消耗时间的，往往不是执行某个具体动作，而是每次回来都要重新恢复上下文。

所以，相比一次生成多少内容，白皮书更关注另一个问题：能不能让一项工作保留上下文，并在后续继续推进。

一、长线工作的核心，是给工作一个固定位置

如果一项工作需要反复推进，就不应该每次新开对话。

白皮书建议为这类工作建立持久线程。线程仍然包含聊天记录，但它承担的角色不只是保存对话，也可以成为一项工作的长期入口。例如项目背景、个人偏好、已经做出的决定和还没解决的问题，可以在这里持续积累。

这样做解决了一个很实际的问题：不用每次从零开始。

比如，一个项目经理助手可以长期跟踪会议、消息和开放事项；一个开发线程可以记住仓库结构、命令和代码约定；一个用户反馈线程可以持续收集问题、识别重复信号并形成结论。

但不是所有事情都要做成长线线程。

一次查询、一次改稿、一个很快就能结束的小任务，开新线程反而更轻。只有满足下面任一条件，才值得长期保留：

后续还会回来继续做；过去的决定会影响下一步；需要持续等待外部状态变化；同一套流程会重复发生。

从工作方法上看，持久线程的目的不是单纯保存更多内容，而是减少恢复工作状态的成本。

二、聊天记录不等于记忆

长线程会保留历史，但只靠历史消息还是不够。

原因很简单：重要信息散落在几十轮对话里，人很难检查，Codex 也可能把临时判断当成长期事实。时间一长，线程里积累的不是记忆，而是噪声。

真正能长期使用的记忆，必须可以打开、修改、对比和复用。

白皮书展示了一种可选做法：建立类似 vault 的记忆库，用文件管理工作上下文。示例按待办、人物、项目、代理和日常记录分类。项目状态变化后更新项目页；出现值得长期保留的人物偏好时更新人物记录；问题解决后将循环标记为关闭；做出重要决定时记录结论和原因。

这里要把两个东西分清楚：

代码仓库保存系统本身；记忆库保存围绕系统发生的事情。

代码能告诉我们现在实现成什么样，但不一定能告诉我们为什么这么做、在等谁确认、哪个方案已经否决、下一步卡在哪里。这些才是长线工作最容易丢失的内容。

如果记忆库使用 Git 管理，还可以直接通过 diff 审查。Codex 新记住了什么、修改了什么判断，人都能看见。

对于会影响后续行动的重要记忆，不应只依赖模型从历史对话中形成的印象，而应转化为人可以审查的工作记录。

三、不要等想清楚了才把信息交给 Codex

语音输入这一节看起来很小，但很重要。

我们通常认为，给 AI 的指令应该尽量完整、准确。但现实里，很多工作刚开始时就是模糊的。

比如：“我记得 飞书中有个人提过这件事，名字可能叫小张，具体说了什么不记得了，你去找一下。”

这不是一条标准指令，但它是很真实的工作输入。人脑里经常只有半个名字、大概方向和不确定判断。如果一定要先整理成正式文字，很多线索反而会被删掉。

按照白皮书的用法，语音的价值不只是输入更快，也在于保留这些尚未整理的想法。会议转录、电话记录、临时讨论和粗略笔记，都可以作为输入材料，再由 Codex 协助整理成计划、草稿、待办或下一步动作。

这里的用法不是“让 AI 猜我想做什么”，而是先把原始信息完整交进去，再通过后续审查逐步收敛。

四、提示词不需要一次写完

过去使用 AI，常见做法是先写一段尽可能完整的提示词，然后等结果。

这个模式适合短任务，不适合长任务。

因为很多问题只有看到中间结果才会暴露。页面做出来以后，才发现字号太大、文案不对、两个模块的间距不合理；代码跑起来以后，才知道原来的方案不成立。

白皮书将这种交互称为“引导”：在 Codex 执行过程中继续追加要求，包括纠正方向、补充背景、批准下一步，或者安排当前动作完成后的后续步骤。

这更接近真实的协作方式：

先给目标和边界；Codex 开始执行；人根据中间结果持续校准；到关键节点再做判断。

所以，长线任务不应该追求一开始就写出完美提示词。更重要的是目标清楚、边界清楚，并且中途可以调整。

五、工具越多，越要先划清边界

当用户为 Codex 配置相应工具、连接器和权限后，它可以接触浏览器、邮件、日历、Slack、GitHub 或桌面应用中的工作内容。具体可用能力取决于产品版本、运行环境、已安装连接器和用户授权，并非所有环境默认具备。

这时候首先考虑的不是“还能接什么工具”，而是“这项任务最少需要什么权限”。

本地页面调试，用浏览器预览就够了；依赖登录状态时，才使用已经认证的浏览器会话；只有必须操作桌面软件时，才使用电脑控制。能只读就不要写入，能准备草稿就不要直接发送。

一个重复流程跑通后，可以把说明、参考资料和脚本整理成技能。这样下次不需要重新教，个人经验也能变成稳定的工作方法。

但技能化的前提是流程已经验证有效。不要把一个还没跑通的临时做法过早固化，否则只是把错误重复得更稳定。

六、自动化的价值，是在该回来时回来

很多任务不是做不下去，而是做着做着没人继续关注。

例如：等待 PR 更新、等待部署完成、等待客户回复、等待某份文档变化。这些任务单次检查并不难，麻烦的是要记得反复回来查看。

根据白皮书描述，线程自动化可以让 Codex 按计划重新唤醒当前线程，在保留已有上下文的基础上检查外部状态，并在满足条件时准备或推进下一步。实际能否执行某项检查，仍取决于相应工具是否可用以及权限是否已授予。

例如：

每 30 分钟检查 Slack 和 Gmail，找出可能需要我关注的未回复消息。研究上下文并起草回复，但未经批准不要发送。

这段要求里真正重要的不是“每 30 分钟”，而是三个边界：

Codex 负责检查和整理；Codex 可以准备回复；最终发送必须由人批准。

一个可靠的自动化循环，应该包含四步：观察变化、补充上下文、准备下一步、等待人的判断。

在这些案例中，自动化的目标不是让 Codex 无限制地自行完成任务，而是让它把工作推进到需要人决策的位置。

七、人和 Codex 的分工必须明确

白皮书列了三个例子。

第一个是首席助手。Codex 检查 Slack 和 Gmail，找出需要关注的消息，搜索背景并起草回复；人决定是否发送、用什么语气、什么时间发送。

第二个是反馈监控。Codex 收集动画项目的反馈，更新项目并重新渲染；人负责创意判断、最终批准和发布。

第三个是申请退款。Codex 监控客服会话、准备证据和下一条回复；人负责同意方案以及任何不可逆操作。

三个例子体现了相近的分工原则：

Codex 负责发现、搜索、整理、生成和建议；人负责判断、授权和不可逆操作。

对于涉及对外沟通、发布或资产变更的工作，这条边界不应模糊。

特别是发送消息、发布内容、付款、删除数据、合并代码这类动作，不能因为前面的工作都由 Codex 完成，就顺手让它自动执行最后一步。越接近真实结果，越需要明确的人工检查点。

远程控制也是同一个逻辑。人离开电脑后，可以通过手机查看进度、回答问题或批准下一步，但这不代表可以跳过审查。远程控制只是让决策不受设备限制，不是取消决策。

八、不要只给计划，要给验收标准

大多数习惯这样给任务：“按照这份 Markdown 计划实现”。其实这不是一个合格的长线目标。

它只说明了怎么做，没有说明做到什么程度才算完成。Codex 可能完整执行所有步骤，但结果仍然不可用。

更好的目标应该包含：

预期结果是什么；哪些约束不能破坏；用什么方式验证；什么状态才算完成。

白皮书举的例子是把一个库移植到 Rust。弱目标只是“完成移植”；强目标则要求保持公共 API 兼容，使用原有单元测试作为验收标准，并记录实现差异。只有相同测试通过，工作才进入审查。

从项目管理角度看就是：计划是执行路径，验收标准才是目标。

计划可以调整，完成定义不能模糊。如果 Codex 无法自己判断当前结果是否达标，长线运行只会把不确定性拖得更久。

九、最终产物必须留在工作循环里

如果 Codex 生成文档后，需要人下载、打开、批注，再把修改意见复制回聊天框，整个流程依然是断的。

按照白皮书展示的产品形态，侧边面板可以让人和 Codex 围绕同一个产物工作。Markdown、电子表格、CSV、PDF、幻灯片和小型网页可以在支持的环境中预览或审查；人的评论可以成为后续指令，修改后的产物也可以继续作为上下文。不同文件类型的具体支持情况可能随产品版本变化。

这样，生成、审查、修改和再次确认才形成闭环。

这也是白皮书希望表达的产品方向：Codex 不只提供对话式建议，也逐渐承载产物生成、审查和修改过程。

最后：先从一个反复重启的任务开始

这份白皮书介绍了很多能力，但不应该一次全部用上。

最直接的落地方法，是先找一项经常中断、每次都要重新恢复状态的工作。比如项目周报、需求跟踪、用户反馈整理、PR 检查或重要消息处理。

然后只做五件事：

为它建立一个持久线程；规定哪些信息需要进入记忆；明确 Codex 能使用哪些工具；写清楚验收标准和人工审批点；对确实需要等待的环节设置自动检查。

等这个循环稳定运行，再把它整理成可复用技能。

总结一下：Codex 长线工作的重点，不是单纯延长 AI 的运行时间，也不是扩大权限，而是重新设计工作如何被保存、继续、检查和完成。

过去，我们每次使用 AI 都是在重新开始。更好的状态是：工作已经在那里，Codex 知道之前发生了什么，也知道下一步做到什么程度需要停下来等人判断。

真正节省下来的，不只是执行时间，而是反复找背景、补上下文和恢复状态的时间。

如果这些环节能够稳定形成闭环，Codex 才可能从一次性工具逐渐变成工作系统的一部分。

本文根据 OpenAI 于 2026 年 6 月 22 日发布的白皮书《Codex-maxxing for long-running work》整理。官方页面作者标注为 OpenAI，文中实践案例主要来自 Jason Liu。