Language:Chinese VersionEnglish Version

OpenAI 推出了 GPT-5.4,其宣传周期既过度推销了模型的推理能力,又低估了其上下文窗口的扩展。在三周的生产环境中,我尝试了各种开发任务——代码生成、多文件重构、图表解释、API 集成——发现的情况既不同于基准测试的结果,也怀疑论者的观点。这份 GPT-5.4 开发者实用评估并非要讨论模型是否令人印象深刻。它显然是的。更有用的问题是它是否应该改变你当前构建软件的方式,以及为谁而改变。

简而言之:GPT-5.4 在两个特定领域代表了有意义的代际进步——大上下文连贯性和多模态输入质量——而在大多数纯代码生成任务上,它与 Claude 4.6 和 Gemini 2.5 Pro 大致相当。定价结构调整使其在中等 API 调用量下更易用,但在大规模使用时更昂贵。而且,”使用哪个模型”的问题对大多数开发者来说,其重要性远低于他们的预期。

从 GPT-4o 到 GPT-5.4 的实际变化

诚实的比较点不是某种理想化的 AI 未来——而是 GPT-4o,它在 2025 年底之前一直是大多数基于 OpenAI 的开发者工具的生产标准。有三项变化对实际使用具有重要意义。

上下文窗口:标准版支持 256K tokens

GPT-4o 的 128K 上下文窗口很有用,但在大型代码库上遇到了实际限制。GPT-5.4 将标准版的上下文窗口翻倍至 256K,企业版则提供 1M token 的上下文。这里重要的不是上限数字,而是有效利用率。GPT-5.4 在保持大上下文连贯性方面明显优于 GPT-4o。实际上,你可以在单个会话中加载一个包含 30 到 40 个文件的 Node.js 后端、完整的 OpenAPI 架构以及几个相关测试套件,而模型不会在响应过程中丢失类型关系或架构约束。

这不是魔法。当接近限制时,上下文质量会下降,模型仍然在将最相关的上下文放在提示符顶部时表现最佳。但改进是真实且可衡量的:一个需要用 GPT-4o 进行仔细手动分块的 40 个文件的重构,现在可以用 GPT-5.4 一次性完成。对于从事中等规模项目(大约是独立 SaaS 或小型团队创业公司范围)的开发者来说,这是此次发布中最立即可用的功能升级。

深度指令遵循

GPT-4o 倾向于在约束被埋藏在长系统提示中或当多个约束相互冲突时,默默地放弃这些约束。GPT-5.4 在跟踪长交互过程中的复杂多部分指令方面有了显著改进。指定 TypeScript 严格模式、特定错误处理约定、不使用 any 类型以及一致使用特定工具库的系统提示,在 20 轮对话中会比在 GPT-4o 上更一致地被遵守。

这比听起来更重要。现实世界中 AI 辅助编程的生产力损失通常不是来自单个糟糕的输出,而是来自漂移——模型逐渐放弃您在会话开始时建立的约束。GPT-5.4 减少了但不消除了这种漂移。长会话仍然需要定期重新锚定核心约束,但频率显著降低。

标准任务延迟降低

在标准编码任务上,GPT-5.4 的中位响应延迟相比 GPT-4o 在类似负载条件下降低了大约 25% 到 30%。对于交互式使用,这是可感知且受欢迎的。对于批量 API 工作负载——自动化测试生成、大规模文档提取、代码审查流程——这转化为有意义的吞吐量改进。延迟减少并不均匀分布;复杂的多步推理任务比直接的生成任务改进较小。

多模态改进:开发者现在实际能做什么

GPT-5.4 中的多模态故事是营销与现实差距最大的地方——但现实仍然不错,只是与演示所暗示的不同。

UI 截图解释

截图到代码的工作流程在所有前沿模型中都在不断改进,GPT-5.4 显著提高了质量标准。提供 Figma 导出的截图并请求 React 组件,现在生成的代码能比 GPT-4o 更准确地捕获布局意图、间距关系和交互状态模式。对于前端开发者来说,这是一个真正的工作流程加速器——不是取代设计交接,而是大幅减少视觉规范与实现之间的机械翻译工作。

失败模式是可以预测的:复杂的 CSS 行为(过渡效果、滚动相关效果、响应式断点逻辑)仍然经常被误解,模型经常产生组件库版本的幻觉。始终在提示中明确指定你的组件库和版本,并将生成的代码视为经过大量修改的起点,而非可直接投入生产的产品。

图表转代码:架构和数据流图

这是实践中让开发者最感到惊讶的多模态用例。一张绘制良好的架构图——类似于 C4 模型的上下文图或容器图,或带有清晰标记节点和边的数据流图——现在可以输入给 GPT-5.4,用于生成能反映该架构结构的脚手架代码。给它一个服务交互图,请求具有正确接口定义的 Go 服务存根,输出结果出奇地连贯。

需要注意的是,这种能力会随着图表质量下降而急剧减弱。手绘的白板照片、标签密集重叠的图表或非正式草图会产生较差的结果。模型在处理来自 draw.io、Lucidchart 等工具的干净导出图表,或 Mermaid 渲染的图像时表现最佳。如果你的团队维护着适当的架构文档,那么图表到脚手架的工作流程确实值得添加到你的过程中。

截图调试

粘贴带有错误状态的损坏 UI 截图并要求 GPT-5.4诊断问题,比使用 GPT-4o 有明显改善。模型现在可以高精度地从截图中读取浏览器 DevTools 控制台输出,并将其与视觉元素相关联。这个工作流程——截取损坏状态、截取相关 DevTools 面板、同时使用两者作为提示——已成为 UI 调试会议中可靠的第一步,通常在使用更正式的调试工具之前就能提出正确的假设。

代码生成质量:真实的进步和持续的失败

GPT-5.4 真正改进的地方

多文件重构是最明显的进步。要求 GPT-5.4 在一个 TypeScript 项目中重命名核心抽象——将 UserRecord 类型更改为 UserProfile,更新所有导入,调整所有派生类型,并修改所有函数签名——它将比其前身完成得更少错误和偏差。对于没有自动化重构工具的项目(在多语言商店或没有成熟 IDE 的新语言中很常见),这确实是一项真正的能力解锁。

测试生成质量已显著提升,特别是在集成测试方面。给定一个服务类及其依赖项,GPT-5.4 生成的测试套件能够覆盖更多边界情况,更正确地模拟依赖项,并更好地符合常见测试约定(TypeScript 使用 Jest,Python 使用 pytest,Go 使用 testing 包)。测试并非总是正确——特别是当服务具有复杂副作用或外部 API 交互时——但初始质量足够高,使得测试生成成为工作流程的净增益,而非清理负担。

从代码生成文档的能力也得到提升。GPT-5.4 可以吸收一个模块,从上下文中理解其意图(不仅仅是函数签名),并生成准确描述行为(包括边界情况)的 API 文档。对于文档质量不佳的团队,这提供了一条可行的追溯覆盖路径,而在相同质量水平下,此前并不存在这样的路径。

仍存在不足的领域

领域特定逻辑仍然是持续的弱点。让 GPT-5.4 实现金融计算逻辑——时间价值调整、符合法规的利息计算、精算公式——它会生成看似正确但在任何领域专家都能立即发现的边界情况下失败的代码。这并非 GPT-5.4 特有的问题;这是在训练数据中很少出现的领域约束下,基于通用代码分布训练的模型的基本局限性。

架构决策同样不可靠。模型会根据提示的表面特征而非系统的实际操作约束,自信地推荐数据库模式、微服务分解和缓存策略。这是经验最丰富的开发者报告出现看似合理但实际上错误输出的比例最高的用例。GPT-5.4 不能替代架构师。它是一个相当好的”橡皮鸭”——它可以提出你未曾考虑的问题,并生成具体选项供评估,但评估本身仍需要人类判断。

安全敏感代码是模型的自信超过可靠性的第三类领域。GPT-5.4 生成的加密实现、认证流程和授权逻辑应被视为不可信,直到理解攻击面的人员进行审查。模型了解模式但会遗漏创建漏洞的微妙实现细节——那些通过代码审查但未能通过安全审计的错误。

API 定价变更与生产预算现实

GPT-5.4 的定价结构已被广泛讨论且经常被误解。对开发者做出生产决策的关键数字:

  • 输入 tokens: 标准层级为每百万 tokens 2.50 美元,相比 GPT-4o 发布时的每百万 tokens 5.00 美元有所下降
  • 输出 tokens: 每百万 tokens 10.00 美元,与 GPT-4o 基本持平
  • 缓存的输入 tokens: 每百万 tokens 0.63 美元—对于有稳定系统提示的应用来说,这是一个显著的折扣
  • 批量 API: 对于有 24 小时交付窗口的异步工作负载,输入和输出均有 50% 的折扣

输入价格的降低听起来很显著。对于输入密集型应用—检索增强生成、文档分析、代码审查流程—这实质上降低了每次请求的成本。对于输出占主导地位的应用(包括大多数代码生成用例),其成本结构与 GPT-4o 类似。

缓存 token 定价对于生产部署来说是最重要的结构性转变。拥有稳定大型系统提示的应用—例如总是加载编码标准文档的编程助手,总是加载产品文档的客户导向产品—通过有效利用提示缓存,可以在每次请求的系统提示部分实现 70% 到 75% 的节省。这需要对提示构建方式进行架构调整,但对于高容量应用来说,投资回报率是巨大的。

对于目前大量使用 API 运行 GPT-4o 的团队,实际建议是在假设成本降低之前,针对您的工作负载对 GPT-5.4 进行基准测试。该模型并非在所有方面都更便宜。在需要精心设计才能捕捉的特定配置中,它才更便宜。

GPT-5.4 vs. Claude 4.6 vs. Gemini 2.5 Pro:各模型真正擅长的领域

当前前沿模型领域已经足够趋同,以至于基准测试对比对于实际决策来说几乎变得毫无意义。所有三个模型在标准编码任务上都表现出色。有意义的差异在于边缘情况。

GPT-5.4

GPT-5.4 在多模态输入处理方面领先—特别是上述的截图和图表解释用例。它在结构化输出生成方面也表现最佳:JSON 模式遵循、一致的 API 响应格式化,以及需要严格格式遵循的复杂提示模板。OpenAI 历史上一直大力投资于指令遵循和格式可靠性,这种投资在需要可预测输出结构的生产应用中得到了体现。大的上下文窗口和改进的连贯性使其成为中等规模全代码库推理任务的最强选择。

Claude 4.6

Anthropic 的 Claude 4.6(截至本文撰写时的生产模型)在需要保持长推理链中逻辑一致性的长篇推理任务上继续领先。对于复杂的调试会话——那种需要同时处理15个观察结果、系统性地排除假设并找出根本原因的情况——Claude 4.6 在推理质量和事实声明上的较低幻觉率使其成为更佳选择。它还能产生更具防御性的架构建议:听起来不那么自信,更可能标记出真正的不确定性,作为真实架构对话的输入更有用。

Claude 4.6 在需要细腻文笔的任务上也具有显著优势——技术写作、有特定声音要求的文档、开发者博客内容。如果你的应用生成面向用户的解释性文本,Claude 4.6 的输出需要较少的人工编辑即可达到可发布质量。

Gemini 2.5 Pro

Google 的 Gemini 2.5 Pro 拥有三者中最大的上下文窗口,达200万个token,在整个代码库分析任务方面仍然无人能及。对于使用 monorepo 或超大型代码库的团队——那种规模下即使是 GPT-5.4 的100万企业级上下文也会填满——Gemini 2.5 Pro 的上下文容量是一个真正的差异化优势。它还显示出与 Google Cloud 工具的最佳集成,并且在受益于 Workspace 集成的数据密集型任务上表现出色。

权衡之处在于,对于复杂的多约束提示,Gemini 2.5 Pro 的指令遵循可靠性不如 GPT-5.4,且其输出格式一致性明显落后。对于需要严格输出结构的应用,这会增加额外的提示工程开销,削弱了部分能力优势。

适用于大多数用例的实际决策规则:对于结构化输出和多模态任务,默认选择 GPT-5.4;对于扩展推理和文本质量,优先选择 Claude 4.6;当需要推理超过一百万token的上下文时,选择 Gemini 2.5 Pro。

“模型不重要”的论点——以及为什么它80%正确

过去一年,开发者社区中流传着一种观点:工作流集成比模型选择更重要,这个观点值得认真对待而非简单否定。它在很大程度上是正确的,但有一个重要的限定条件。

在AI辅助开发生产力中,最重要的变量不是你使用哪个模型——而是模型在开发者需要帮助的那一刻被集成的程度。一个在调试会话的恰当时机、通过不破坏流程状态的UI、预先加载了正确上下文的劣质模型,其表现将优于需要切换应用程序、重新建立上下文、并在一个并非为此任务设计的UI中浪费90秒的优质模型。

这就是为什么尽管Cursor本质上只是对其他地方也可用模型的简单封装,但其采用率仍在增长。IDE原生集成不是一种变通方法——它才是真正的价值主张。同样,Claude Code的终端原生设计创建了一种工作流集成,它比基于浏览器的聊天界面更适合某些开发者画像,无论底层模型质量如何。

但需要明确的是,当任务确实需要一个模型能做到而另一个模型做不到的事情时,工作流集成无法完全弥补能力差距。如果你的模型上限为128K token,那么通过更好的工作流设计也无法实现具有1M token上下文的完整代码库推理。GPT-5.4与较弱的多模态模型之间的图表转代码能力差异是真实存在的,无论多少提示工程都无法缩小这一差距。在能力前沿——那些勉强可行的任务——模型选择非常重要。对于中间80%的任务,工作流集成是主导变量。

实用建议:委托什么,保留手动操作

经过持续使用,大多数开发工作流程中合理的分配如下。

委托给GPT-5.4

  • 具有明确定义范围的多文件重构任务——重命名抽象、迁移到新的库版本、在整个代码库中强制执行一致的模式
  • 为现有模块生成测试套件,特别是集成和单元测试脚手架
  • 根据OpenAPI或GraphQL模式生成API客户端代码
  • 将设计规范中的截图转换为UI实现组件
  • 为API文档不足的模块生成代码文档
  • 结构化输出生成任务,其中格式合规性至关重要
  • 架构图解释以生成脚手架代码
  • 减少具有清晰结构的重复代码模式中的样板代码

保留手动操作或仅作为输入使用

  • 涉及运营约束权衡的架构决策——延迟、成本、运营复杂性、团队技能——这些在代码中不可见
  • 受监管或专业领域的特定领域逻辑:金融计算、医疗数据处理、法律文档逻辑
  • 安全敏感代码:身份验证流程、加密实现、授权规则——由AI生成,由了解攻击面的相关人员审查
  • 性能关键实现,其瓶颈是算法性的而非语法性的
  • 具有高成本失败模式的决策,其中看似正确但错误的输出模式所创造的风险超过了生产力提升所能带来的价值

基本原则很简单:当成功可以客观验证时(测试通过、类型检查、格式符合模式),AI生成的代码最可靠;而当成功需要提示中未体现的领域知识或判断时,则最不可靠。围绕这一原则设计你的委托决策,而不是试图寻找在所有模型都不擅长的任务上表现最好的模型,这才是真正的生产力杠杆所在。


关键要点

  • GPT-5.4最有意义的升级是其256K标准上下文窗口和改进的连贯性,以及对UI截图和架构图的多模态输入质量
  • 定价结构调整有利于输入密集型和缓存提示工作负载;输出密集型代码生成应用在无需架构变更的情况下看到适度的成本改善
  • Claude 4.6在扩展推理和文本质量方面仍然更强;Gemini 2.5 Pro在大型代码库的上下文容量方面领先;GPT-5.4在结构化输出和多模态任务方面领先
  • 特定领域逻辑、安全敏感代码和架构决策对于任何当前前沿模型来说,仍然保持在委托边界之外
  • 工作流集成继续成为能力谱系中间80%任务的主要生产力变量;模型选择主要在能力边界边缘起作用
  • 你能对AI辅助开发生产力做出的最持久的改进是定义你将委托和不委托的任务——而不是为委托是错误方法的任务寻找更好的模型

By Michael Sun

Founder and Editor-in-Chief of NovVista. Software engineer with hands-on experience in cloud infrastructure, full-stack development, and DevOps. Writes about AI tools, developer workflows, server architecture, and the practical side of technology. Based in China.

Leave a Reply

Your email address will not be published. Required fields are marked *

You missed