OpenAI在2026年6月22日发了一份《Codex-maxxing for long-running work》。主角不是新功能，也不是新版本，而是Jason Liu分享的一套Codex使用策略。

有意思的地方在这里：OpenAI没有把Codex继续放在“帮你多写几行代码”的叙事里，而是把它放进长期复杂工作。也就是一个任务跨过一次提示、一次对话，甚至跨过多天之后，AI还能不能接着干。

我的判断很简单：Codex的重点正在从代码生成器，转向一种持久工作空间。但它不是无人驾驶。人类仍要负责方向、边界和验收。

OpenAI发布的是指南，不是Codex新版本

这次内容来自OpenAI的AI Adoption栏目，形态更接近白皮书/实践指南。原文没有披露用户数量、效率提升比例，也没有给出企业采用规模。

所以不能把它写成“Codex发布重大更新”。目前能确认的是：Jason Liu分享了如何用Codex承接跨越单次提示的长期复杂工作。

白皮书里的关键词很集中：持久工作空间、上下文保留、复杂工作流、可验证步骤、长期项目连续推进。

这些词对应的是开发团队每天都会碰到的麻烦。一个bug不只在一个文件里。一次重构不只改一段函数。框架迁移、测试补齐、遗留系统维护，都需要记住前因后果。

过去很多AI编程工具强在局部：补全一段代码、解释一个函数、生成一个脚本。任务变长以后，真正的问题变成：谁记得项目走到哪一步了，哪些假设还有效，哪些结果已经验证过。

对比项常见AI编程用法这份白皮书强调的用法对团队的实际影响
工作单位单次提示、单段代码长期项目、连续工作流任务要拆得更清楚
AI价值生成代码片段保存上下文并推进步骤更像工作空间，不只是插件
质量控制人看结果能不能用每一步都要可验证测试、评审、记录更重
人类角色提需求、收代码定方向、设边界、验收技术负责人不能退出

这也是它比普通“AI写代码教程”更值得看的一点。它讨论的不是一句prompt怎么写得漂亮，而是AI如何接住一个会变长、会反复、会出错的软件工程任务。

Codex被放进长期工作流，但限制也更明显

Jason Liu分享的实践策略，核心不是让Codex一次性产出更多代码，而是让它围绕长期项目工作：保留上下文，拆解复杂工作流，把任务推进成一组可验证步骤。

这听起来更像“接活”。但接活不等于自治。

长期上下文有价值，因为它减少重复解释。开发者不用每次都把项目背景、约束、目标重新讲一遍。对重构、迁移、测试补齐这类工作，连续性本身就是效率。

但持久上下文也会带来新风险：AI记住的不一定都是对的。

它可能保留过期约束，也可能沿着错误假设继续往下做。上下文越长，错误越不容易被一眼看出来。积羽沉舟，问题往往不是某一行代码，而是一串未经校验的步骤。

所以这份白皮书真正提醒技术团队的，不是“把更多工作交给AI”。更准确地说，是把工作拆到AI能执行、人能验证的粒度。

对普通开发者，动作很具体：不要只问Codex要最终代码。更应该让它列出步骤、标明假设、给出可检查结果。每一步最好能对应测试、diff、日志或评审点。

对技术负责人，动作也很具体：不要急着把长期项目整体迁给AI。先选低风险任务试，比如测试补齐、文档同步、小范围重构。能回滚、能审计、权限边界清楚，再扩大范围。

分水岭不是AI能不能干活，而是谁负责验收

这份白皮书最该影响的，是已经在使用AI编程工具的开发团队。尤其是同时处理重构、迁移、测试和遗留系统维护的团队。

这些团队不缺“生成代码”的工具。缺的是任务不断线：今天拆出的步骤，明天还能接着推进；今天确认过的约束，后面不会被随手覆盖。

但人类监督仍是分水岭。

Codex可以执行任务，可以根据上下文推进步骤。人类要负责判断目标是否正确，边界是否安全，结果是否能进主干。这个边界不能含糊。

接下来最该盯的不是口号，而是三个变量：

  • Codex能否稳定保留项目上下文，并区分新旧约束；
  • 每个执行步骤是否容易审计、测试和回滚；
  • 团队的权限、评审和责任人是否足够清楚。

如果这三件事薄弱，长期工作流反而会放大混乱。AI越能续航，错误也越能续航。

所以我不太买账的是“长期项目交给AI就能省心”的说法。眼下更靠谱的判断是：Codex正在被重新解释为长期项目里的执行空间，而不是完全自治的工程师。

这正好回到开头那个问题。一个任务跨过一次提示之后，AI还能不能接着干？

答案可能是：可以开始接着干。但前提是，人得知道什么时候让它停下来。