GPT-5.5 的早期体验：能力、成本与引导难题

我原本以为自己会对 GPT-5.5 很兴奋，某些方面确实如此。它能力很强，生成的代码令人印象深刻，但我早期的使用体验也有不少挫折：我希望它进一步落实任务意图时，它经常只完成较狭义的要求。

录制视频时，我提到的标价是每百万输入 token 5 美元、每百万输出 token 30 美元，在我的比较中是上一代模型的两倍。每 token 价格只是总成本的一部分：在某些工作负载下，消耗更少 token 的模型完成一次任务可能更便宜。这些是发布时的信息，不是当前价格指南。

OpenAI 的发布材料介绍了安全测试、早期用户反馈，以及为高效提供更大模型而开展的基础设施工作。我讨论的是发布时的说法和自己的早期测试；这些说法不能独立证明模型对每个用户或任务的表现。

我说录制时自己尚无法使用标准 API，不过获得了部分早期访问权限。可用性会变化，因此这只是我测试时的快照，不代表现在的服务状态。

视频展示的 OpenAI 成绩中，GPT-5.5 在 Terminal-Bench 2.0 得分 82.7%，GPT-5.4 为 75.1%；内部 Expert-SWE 评测分别为 73.1% 和 68.5%。这些是服务商在特定测试中报告的结果；解读时需要考虑工具框架、任务选择和设置。

在 GDPval 上，展示的数字把胜出和平局合并计算。我指出，即使明确胜出和平局的分布变化不那么明显，合计指标仍可能上升。比较基准成绩时应阅读底层定义，不要假定每个百分比衡量的都是同一件事。

表格还包括计算机操作、浏览和数学基准。我认为其中一些结果令人印象深刻，但推测工具使用和长任务连贯性的差异可能影响浏览成绩。这些解释只是猜测；单个基准分数不能证明模型表现背后的原因。

Artificial Analysis 的智能指数展示了不同推理设置。在我讨论的图表中，GPT-5.5 的 medium 设置似乎接近 GPT-5.4 的较高设置，同时消耗更少输出 token。这是该基准内部的比较，不能保证所有应用中的质量或成本相同。

展示的输出 token 总量随推理强度明显变化：我提到该评测中 extra-high 约用 7,500 万、high 约用 4,500 万、medium 约用 2,200 万。这些是运行整套基准的总量，不是一次普通请求的用量。

Token 效率可以让模型感觉更快，也可能部分抵消更高的单价。但它本身不能证明端到端成本更低：输入、输出、重试、延迟和任务成功率都重要。我会先用代表性工作测试较低推理强度，在确有帮助时再提高。

前端演示在某些方面令人印象深刻，尤其是涉及空间或游戏式输出时。我反复遇到的审美问题是过多不必要的卡片。我想看看模型在我熟悉的项目上会怎样表现，而不是只根据精心展示的演示判断。

我重新拿出一个受水族馆游戏启发的旧原型 Fish Slap。它的代码需要清理，所以我让不同模型对其现代化，建立更可靠的起点。这只是针对特定提示词和运行结果的非正式比较，并非受控基准。

Opus 版本生成了素材，改善了部分移动效果，但更改了控制方式，喂食行为也有问题。GPT-5.4 版本同样能运行，但我发现屏幕不断缩放，鱼也死得过快。两个例子都说明，演示能运行仍然需要亲自测试。

在我看来，GPT-5.5 的版本一开始玩起来和看起来都更好。它复用了部分原有素材，也添加了新的视觉细节，不过我不喜欢大量卡片式界面。经过后续提示，它去掉了一些杂乱元素，我认为结果可以作为后续开发的起点。

随后我要求制作更具三维感的游戏。第一个结果使用了 3D 素材和渲染器，但大体保留了原来的二维玩法。构建渲染器并非易事；让我失望的是，结果没有达到我设想的游戏体验。

多次尝试纠正后，我新开了一个线程，用更严格的指令得到了更好的结果。我的主观感受是，模型有时会满足字面要求，却没有追求更广泛的目标。清晰的验收标准可以帮助区分真正的三维交互和仅仅显示 3D 对象。

我还让它重新设计赞助商页面。生成的页面乍看可以接受，但我发现了一些不必要的控件，以及导航时未按预期改变的高亮类别。单看截图发现不了这种交互问题，必须实际操作页面。

我认为更清楚的视觉方向或参考图可能改善结果。其他一些测试者告诉我，他们先用图像模型制作草图，再让编码模型实现。这把视觉探索与实现分开，但得到的界面仍然需要审查。

其他早期用户的体验更积极。我引用了一些公司对更强的持续性、工具使用和复杂编码任务表现的评价。他们的报告与我的体验是在不同条件下得到的观察；没有独立、可复现的测试，任何一方都不应当作普遍排名。

我的主要不满是模型有时过早停止并宣布任务完成。我把这种体验称为“懒”，并不是在断言模型有什么动机。它可能需要更明确的指示，说明完成结果应该是什么样，以及如何验证。

我还遇到过一些线程，早期走错方向后似乎很难纠正。Ben 举的例子是，请求提交一次变更后，模型在后续工作中继续做了不希望出现的提交。这是一次报告的工作流故障，不能证明后续指令永远无法覆盖先前上下文，也不能说明每个会话都会如此。

对我自己的工作来说，反复跑偏或上下文压缩效果不好后，新开线程很有用。新线程是重置上下文的一种方法，但如果不带上相关事实、约束和未完成工作，也会丢失有价值的历史。

我简要展示了一个“骑自行车的鹈鹕”SVG 测试。在我看来，较高推理强度的结果比 medium 好，但这只是一个视觉编码提示词。它说明该例子中设置之间的差异，而不能衡量模型的整体质量。

对于耗时较长的困难谜题，我使用 GPT-5.5 Pro 的体验更积极。我说它解决了几个安全社区的旧谜题，但无法公开其中所有案例和结果。因此这属于个人叙述，而非可独立复现的评测。

我还测试了一个公开谜题：模型取得了一些进展，但没有完全解决。我觉得部分工作有帮助，同时也承认自己不知道所需信息是否全部公开。看似合理的部分答案仍需要对照真实谜题核查。

对于我自己设计的一个谜题，一次 ChatGPT 运行用了约 163 分钟并得到答案。另一次本地运行快得多，但我提供的链接可能构成了额外提示。起始上下文不同，因此两次时间不能构成干净的速度比较。

我介绍了谜题的几个阶段：简单编码的线索、Git 提交引用、自定义的 23 进制编码以及加密载荷。重点不是模型独自破解了现代加密，而是它沿着人为设计的挑战中的线索逐步推进。

我仍然对模型的编码能力以及 Pro 愿意花时间处理难题的表现印象深刻。同时，我必须更努力地说明目标、提供正确资料，并检查代理是否沿着预期方向工作。能力和易于引导是不同的品质。

根据这次早期体验，我的实际建议是：直接说明要求，定义成功标准，提供相关参考资料，并让结果能够验证。如果一个线程反复遵循错误假设，可以考虑带着简洁的交接信息重新开始。仍要检查输出，因为幻觉和普通错误依然可能发生。

我推测未来模型可能改善这些问题，但我并没有关于训练或发布计划的内部消息。目前，我会重新审视旧提示词和工作流程，而不是假定新模型一定会产生相同行为。