我的 GPT-5.3-Codex 评测：完全自主已经到来

摘要

一句话总结

GPT-5.3-Codex 凭借其在模糊条件下的出色判断力、长周期任务的稳定性和基于测试用例的自我迭代能力，首次实现了真正意义上的全自动编程，彻底改变了开发工作流。

关键要点

实现完全自主性： 只要提供明确的预期结果和验证测试（Pass/Fail），模型就能在无人干预的情况下持续运行数小时（部分任务超过 8 小时）并高质量完成复杂任务。
卓越的模糊判断力： 在指令存在解释空间时，模型能像优秀的人类工程师一样补充上下文，做出合理的架构和代码决策，而非仅追求“表面完成”。
多智能体协作（Multi-Agent）成熟： 在 AgentRelay 框架下测试表明，多个 GPT-5.3-Codex 实例能够进行实质性的高效分工与协作，显著提升产出质量。
跨仓库与全生命周期部署： 能够跨本地多个代码库查找 API 并修改代码；可自主使用 Railway CLI 完成代码推送、部署、查看生产日志及修复的完整闭环。
代码质量与主动性提升： 产出的代码架构更佳，Hack 补丁和死代码更少；在等待任务执行的空闲时间，会主动收集上下文或完善文档；能自主判断并调用合适的本地工具/技能。
工具选择决策树： GPT-5.3-Codex 适用于长周期、高复杂度、零容错的核心任务；Opus 4.5 仍是快速迭代和短任务的首选；UI 和样式设计则更推荐 Opus 或 Gemini 3 Pro。
配置建议： 针对无人值守的自动化任务，建议将推理模式（Reasoning mode）设置为“Extra High”（而非 OpenAI 官方推荐的 Medium）。

风险与不足

执行速度极慢： 运行耗时极长（通常需要数小时），牺牲了速度以换取极高的稳定性。
UI 与样式能力较弱： 在前端 UI 和样式处理上不及 Opus 4.5 和 Gemini 3 Pro。
提示词与 Agent 设计存在短板： 不擅长设计提示词架构，有时会做出糟糕的决策并破坏现有的 Agent 工作流（该场景下 Opus 表现更好）。
状态反馈与总结体验不佳： 运行中途的状态播报（Status Narration）和 UI 任务复选框有时会中断或延迟更新；运行结束后的总结报告往往充斥大量晦涩的技术术语，不够通俗易懂。
Mac 客户端仍有瑕疵： 尽管支持本地/云端运行和分支管理，但客户端仍存在部分 UI 缺陷（特别是运行中途的更新显示问题）。

正文

每一次重大的模型飞跃都会改变我使用这些 AI 系统的方式。虽然 Opus 4.5 让我们非常接近完全自主，但 GPT-5.3-Codex 是第一个给我这种感觉的模型：我指定结果，设置验证（明确的通过/失败测试），然后点击运行……并且非常有信心，当我在一两个小时（有时甚至更长）后回来时，我的任务（无论多么复杂）都会近乎完美地完成。

每一次飞跃都会改变我的工作流，而这是一次巨大的飞跃

回想起来这仅仅是一年半前的事，感觉有点疯狂，但当时的 Sonnet 3.5 或多或少只是一个英语转代码的翻译器。它很棒，但你仍然需要亲自把控每一步。它会（几乎）完全按照你说的去做，这很有用，但它并不能真正自主推进工作。你（在某种程度上）依然需要懂得如何进行开发，才能高效地驾驭它。

接下来的几次模型发布变得更加强大。它们开始让人觉得更像是初级工程师。你可以交给它们稍微大一点的任务，它们也能持续运行更长时间。但你几乎在每一个步骤中都依然需要手把手地引导它们，而且迭代过程简直是一场持久战。为了正确实现一个功能，可能需要 10 到 20 个提示词，如果极其复杂的话甚至需要更多。

GPT-5 是下一次重大的阶段性转变。我不再保姆式地给它喂步骤，而是开始直接设定更宏大的目标结果。它能在一定程度上自主完成很多工作，但大型代码库（repos）依然会让它栽跟头，而且它还是会相对频繁地犯错，尤其是随着时间推移，当我真正开始不断挑战其能力极限时更是如此。最重要的是，我在某种程度上依然需要发挥主导作用，给它提供极其详细的提示词，描述我希望如何完成这些任务。

众所周知，相比 GPT-5（以及此后发布的其他模型），Opus 4.5 是一次巨大的飞跃。Opus 4.5 速度快得惊人，通常能完美搞定我交给它的绝大多数任务，但它仍然需要非常严格的护栏。如果我没有极其明确地说明约束条件、非目标（non-goals）以及我们将如何进行验证，它通常会选择一条看似合理的最快成功路径。它可能会绕过根本原因打补丁，写一些不该写的存根（stub），或者为了“看起来做完了”而妥协，而不是做到“代码扎实，且完全按照用户期望的方式完成”。

即使我给出了明确的说明，它偶尔也会以一种我根本不会发布（ship）的方式来完成提示词的要求。在那些漫长、混乱且高风险的任务中，这最后 5% 到 10% 的判断力缺失依然会暴露出来，而正是这部分会在之后耗费你数小时的时间去弥补。

但现在，我们迎来了下一次阶段性转变，我现在就可以断言：这就是完全自主。

我们终于迎来了这一刻。

最大的区别：它能在模糊不清的情况下做出与我一致的决策

最重要的升级不是速度。甚至不是纯粹的智力。而是判断力。

“但是 Matt！”你可能会说，“判断力是人类独有的！”很抱歉，并非如此。

事实越来越清晰：只要存在关于某件事的数据，基于这些数据训练的模型就能做到这件事。互联网上的海量数据中蕴含着人类的判断力。各大模型公司也正在斥巨资购买数据，这些数据同样能帮助模型提升判断力和品味（taste）。这是第一个让我感觉在特定领域内，已经将这种判断力进行了深度内化的模型。

当提示词留有解释空间时，GPT-5.3-Codex 往往会做出与我相同的选择。它填补缺失上下文的方式，让我感觉与我实际思考该问题的方式高度契合。

在模棱两可环境下的假设质量，比人们意识到的更为重要，而 GPT-5.3-Codex 在这方面比我之前使用过的任何模型都要出色得多。

多智能体协作终于成为现实

我还在我用 AgentRelay 构建的多智能体框架中测试了 GPT-5.3-Codex（利益相关：我最近投资了该项目）。我让多个 GPT-5.3-Codex 实例通过对话共同解决问题，结果绝对令人惊叹。我很快会分享更多相关信息。

这是我见过的首批能够真正与其他模型进行协作的模型之一，而且绝非流于表面。在同一个框架中使用 Opus 时，常常感觉它们只是“为了对话而对话”，多模型协作是否真的带来了更好的效果并不明显。而使用 GPT-5.3-Codex 时，沟通非常高效，智能体会自发地分工并投入到专注的工作流中，这种协作确实产出了更好的成果。整体进展快得多，每个智能体也都保持着高度的专业分工。这真是太他妈不可思议了。我认为这种模式很快就会变得非常、非常普遍。

关键突破：验证机制让它成为真正的智能体

如果你想要实现完全的自主性，有一种方法胜过其他所有手段：预先为模型提供强大的验证机制和测试用例。

有了明确的验证目标，GPT-5.3-Codex 能够持续迭代数小时而不会迷失方向。它不会偏离目标，也不会在中途陷入混乱。它会不断推进，直到满足所有约束条件且测试全部通过（飘绿）。

没有测试时，它已经非常优秀；而有了测试，它就升华成了另一个维度的工具。

注意：这对于任何现代编程智能体来说都是成立的。只不过在有效利用验证和测试来朝着目标不断迭代方面，GPT-5.3-Codex 独一档。

它甚至会在未经提示的情况下主动使用技能

这是一个最终影响巨大的小细节：它能够在合适的时机主动使用本地技能和工具，而无需我明确下达指令。

即使是 Opus 4.5 也经常需要诸如“检查一下是否有相关的技能可用”这样的提醒。它不会自发地去扫描可用资源。但 GPT-5.3-Codex 会这么做，而且它往往是在技能真正派上用场时才去使用，而不是仅仅因为有这个技能就去滥用。

第一个让我放心撒手不管的模型

对于长周期、复杂的工程任务，这是第一个让我可以在启动任务后就去做其他事情的模型，我完全不觉得需要频繁检查以确保它没有跑偏。它只会不断推进。它的表现不会慢慢退化，也不会半途而废。它通常都能把活儿干好。

是的，它比 Opus 4.5 慢。运行一次任务通常需要好几个小时（我有几次任务甚至跑了超过 8 个小时）。这种代价是切切实实存在的。但它的稳定性实在高出太多，以至于对于任何我绝对不想出错的任务，我最终都会更信任它。

代码质量也更胜一筹

这一点很容易被忽略，因为你往往要在几周后才能体会到：它的代码质量和架构通常比我用 Opus 4.5 生成的要好得多。

随着代码库的演进，我发现临时拼凑的补丁变少了，遗留的废弃代码变少了，不断累积的隐蔽 bug 也变少了。它不仅仅是完成任务而已。它通常能让代码库保持在更好的状态，这令人极其印象深刻，因为它往往运行的时间更长，做出的改动也更大。

它像优秀的工程师一样分配时间

另一个被低估的表现是：它能很好地利用空闲时间。如果某个程序正在运行，而在那一刻它又没有其他有用的事情可做，它通常会主动去收集上下文、完善文档或自行修复问题。

其他模型只会干等着，除非我明确告诉它们下一步该做什么。而 GPT-5.3-Codex 往往会去做那些显而易见有用的事情，同时又不会画蛇添足去修改我没要求改动的地方。

跨仓库操作极其惊艳（褒义）

我通常会赋予它超出其原本所属单一代码仓库的访问权限。这解锁了一种截然不同的工作流。

我可以对它说：“在这台机器上找到提供 X 的 API 的代码仓库”，它就会去找到该仓库，学习其中的模式，将其正确应用到当前仓库中，然后继续后续工作。它甚至能在另一个仓库中进行修改并执行推送（push），然后回到主线任务中，丝毫不会迷失方向。

看着它像这样在我的机器上穿梭操作，依然让人觉得不可思议。

它能完成部署的闭环（Railway CLI）

我一直赋予它 Railway CLI 的访问权限，而它已经能够为我完成整个开发生命周期的闭环。我会这样对它说：“准备好后把它部署到 Railway 上，并确保它能完美运行”，然后它就真的做到了。

它会进行代码修改、推送、部署、检查真实的生产环境 URL、追踪日志，并不断迭代，直到程序真正正常运行。我们在其他模型身上也曾看到过类似能力的影子。Opus 在利用日志进行自我纠错方面表现得很扎实，但依然会犯错。Antigravity 环境下的 Gemini 3 Pro 包含了浏览器驱动的迭代功能，而且现在大多数编程工具都针对这个闭环的某些环节提供了插件。但这里的区别在于，它终于让人感觉这是一个真正的闭环……它几乎每一次都能完美搞定。

亲眼目睹这一切发生简直太疯狂了。我可以开启一个新项目，然后离开电脑，一两个小时（有时甚至更久）后回来，就会发现 GitHub 上已经生成了多个全新的代码库，Railway 上完成了新的部署，而且整个系统都在完美地交互运行。

何时使用哪个模型（我的实际选择准则）

目前我总结出的使用模式如下：

Opus 4.5 依然是我处理快捷任务和快速迭代循环的默认首选，尤其是在我更看重速度而非深度的时候。但我现在每天用它的频率越来越低了。最近，我发现自己会把一堆原本习惯用 Opus 处理的小问题，打包成一个给 Codex 的长提示词（prompt），然后让它自己跑上一个小时左右。

GPT-5.3-Codex 则是当任务属于长线任务、非常棘手、充满限制条件，或者是我绝对不想出错时，我会去使用的模型。任何那种我只需点击启动就可以离开电脑不管的任务都会交给它。但话又说回来，我越是用它，就越想把它用在更多的地方。所以我预计这种情况在未来几周还会发生变化，Codex 将会包揽我更多的工作。

UI 和样式设计 依然不是 GPT-5.3-Codex 的强项。Opus 在这方面表现更好，而 Gemini 3 Pro 仍是我用过在样式设计上最出色的模型。

在我的 GPT-5.2 评测中，我曾提到那个模型虽然惊艳，但速度太慢。GPT-5.3-Codex 并没有显著变快。但奇怪的是，这对我来说已经没那么重要了。它在处理长线任务时极其可靠，以至于我完全可以让它自己运行，晚点再回来看结果。速度慢依然是一个减分项，但当一个模型能像它表现得如此出色时，速度就不再是决定性的阻碍了。

关于推理模式：OpenAI 推荐使用 Medium，它已经很强了，但当我打算离开电脑去干点别的时，选择 Extra High 显然更合理。对我来说，Extra High 就是“慢慢来，把事情做好”的绝佳设置。

它更强大了，但没那么有趣了

我还要应付一些小痛点，其中最奇怪的是，它可以运行好几个小时——真的是好几个小时，而在它运行的时候，我常常不知道自己该干点什么。

如果是用 Claude，我会为其他小任务启动并行运行，因为主运行任务通常无法一次性搞定所有事情。而 GPT-5.3-Codex 的能力太强了，一次运行通常就能涵盖我想要的大部分（甚至全部）内容。这很惊人，但也让我有时只能无所事事地干坐着。这是一种很奇怪的适应过程，我还在慢慢习惯。

补充说明

提示词与智能体设计

我构建过很多智能体（agents）。就提示词架构本身而言，GPT-5.3-Codex 并不是我最喜欢的模型。在决定提示词和智能体流程（agent flow）中应该包含什么内容时，它有时会做出考虑不周的决定，而且它还曾破坏过我很看重的智能体流程。我依然会选择 Opus 来优化提示词和构建智能体。

不过，关于这一点还要补充一句：如果我为智能体需要做的事情提供非常明确的验证标准，以及针对输出和行为的具体测试，那么即使它第一次尝试失败了，它也能通过迭代最终得出有效的方案。它会死磕到底，直到测试全绿（grind toward green）。

话虽如此，一旦方向明确，GPT-5.3-Codex 在构建智能体周边系统和执行工作方面表现得异常出色。

状态播报可能不够稳定

所谓状态播报，是指模型在工作时会把正在做的事情说出来：“我看到了这个问题，我准备检查 X，然后运行 Y。”它通常在这方面做得相当不错。

但有时它会突然停止播报一段时间，这使得在运行中途判断发生了什么变得异常困难。用户界面（UI）中的任务复选框帮了大忙。它会列出计划执行的任务，你可以看着它们被逐一勾选。但我注意到，这些复选框有时直到运行结束才会更新。这主要是一个可见性问题。对我来说，它并没有对输出质量产生实质性影响。

运行摘要可能过于技术化

另一个小痛点是：在运行结束时，模型经常会使用充满专业术语的语言来提供更新说明。如果你是一个偏向“氛围流（vibe-codery）”的开发者，没有深厚的技术基础，这将会很折磨人。你经常不得不要求它用通俗易懂的语言重新解释一遍。

即使你是技术人员，这种密集的术语依然会让人心烦。大多数时候，我只想要一个快速、清晰的说明，告诉我改了什么以及是否生效，而不是面对满篇晦涩的技术泥潭。使用这些模型的初衷，本来就是为了避开这些技术泥潭。

为什么我没有在这里评测 Mac 应用程序

有些人问我，既然我拥有早期访问权限，为什么没有评测 Codex Mac 应用程序。原因在于，我完全被 5.3-Codex 惊艳到了，以至于我觉得把时间花在其他几乎任何事情上都不值得。

话虽如此，这款应用程序本身还是很强大的：在一个地方管理多个运行任务确实非常实用，而且对本地/云端运行以及工作树/分支（worktrees/branches）的支持也非常棒。我还是发现了一些 UI 漏洞（尤其是在运行中途的更新方面），界面也有进一步精简的空间，但模型的质量实在遥遥领先，以至于它占据了我所有的注意力。

这个模型改变了我的工作方式

我现在的工作流是这样的：我编写极其详细的提示词，提前定义明确的验证和测试用例，然后就让它自己运行。

GPT-5.3-Codex 是我使用过的第一个让完全自主性在实际操作中开始感觉真实可行的代码模型。

它并不完美。速度仍然是一个巨大的劣势。但由于它在面对模糊情况时的判断力更好，长周期稳定性更佳，并且当你给它设定验证目标时，它会变得极其可靠，因此它现在是我在_大部分_工作中最喜欢的模型。

对于快捷任务，Opus 4.5 依然是我的首选。但对于任何困难、冗长，或者我绝对不想出错的任务，这是第一个让我可以放心点击运行、离开电脑，并期待它真的能……顺利完成的模型。

wsl-docs

探索