o3 模型未能成功复现著名的 GeoGuessr 提示效果The famous o3 "GeoGuessr" prompt did not work

去年4月，凯西·皮珀（Kelsey Piper）发现 OpenAI 的 o3 模型在判断照片拍摄位置方面表现惊人。像人类“地理猜猜乐”（geoguessr）高手一样，o3 有时能准确指出一张看似普通的沙滩照片的具体拍摄地点。以下是凯西举的例子：

多人尝试后也取得了不错的效果：虽然成功率并非100%，但显然远胜于随机猜测的人类。这说明模型能力可能会带来意外惊喜。在凯西发布推文之前，o3 模型已上线两周，却无人注意到它在地理位置识别方面的强大能力。我们是否遗漏了其他不为人知的能力？当前模型还有哪些潜力尚未被发掘？

有人从中得出另一条启示：“提示工程”（prompt engineering）可能解锁全新的能力。这是因为凯西构建了一个经过长期打磨的“魔法提示词”。每当 o3 出错时，她会要求它反思如何避免错误，并将这些改进加入提示中。以下是该提示词的前10%内容，供你参考：

你现在正在参加一场单轮的 GeoGuessr 游戏。任务是从一张静态图像中推断出最可能的真实世界位置。请注意，与 GeoGuessr 游戏中的情况不同，这些图像并不保证拍摄于谷歌街景车可到达之处——它们可能是用户提交的测试图片，用于检验你的图像定位能力。私人土地、某人的后院或越野探险地都是真实可能性（尽管许多图像仍可在街景中找到）。请了解你自己的优势与不足：遵循此协议，通常能准确猜出大洲和国家……

这个提示词让很多人印象深刻，他们试用后报告称能正确识别大量图像。但显然，仅用一句基本的“仔细想想这张照片是在哪里拍的？”提示，o3 也能正确识别大量图像。那么，这个复杂的提示词真的有用吗？光靠 ChatGPT 里试几次很难判断。你需要建立一个包含图像的评估集，并分别用两种提示运行 o3 两次：一次使用高级提示，另一次则不使用。

我就是这么做的。我从 Wikimedia Commons、Geograph Britain and Ireland 和 iNaturalist 三个来源抽取200张图像作为基准测试集。你可以在此阅读 AI 生成的总结，但关键数据如下：

总体而言，基础提示的平均表现更优。它始终能给出更接近实际位置的答案。两种提示都表现不错。尽管高级提示长达基础提示的十倍，o3 的思考时间仅略有增加（平均约多一秒，最长从5分钟增至约10分钟）。我的测试图像多为典型的地理猜猜乐风格户外场景，另有12张室内图用于额外挑战（高级提示在这些图像上的表现也更差）。

这是怎么回事？我觉得这说明了为什么人们很容易高估自己提示词的质量。当模型本身已经对某项任务掌握得相当不错时，即使你给它一个非常复杂的提示词，也不会影响其表现。它依然会表现得很好，但这一次之所以好，是因为你的功劳。如果你正在与模型迭代优化，并针对每个错误反复询问“我该在提示词里加什么”，那么这一点尤为明显。模型会很乐意编造关于自身推理过程的故事，而且当你问它某个提示词改动是否有帮助时，它们几乎总是回答“是的，效果显著！”。但真正要判断这一点，唯一可靠的方法是建立一个基准测试1。

有趣的是，当时竟然没人注意到这一点。我花了大约六小时的分心工作和约15美元就构建并运行了这个基准测试。那为什么在别人写文章吹捧o3的提示词有多神奇的时候，没人想到做这么一件事呢？

一种善意的解释可能是：那个故事的重点其实不在于“魔法提示词”，而在于o3真实的地理定位能力。此外，o3的价格曾经贵出五倍左右（不过就算只跑40张图片而不是200张，也足以让人怀疑那个提示词到底有多少水分）。再者，AI发展得太快了——地理定位只是昙花一现的话题，撑死也就一周；之后大家讨论的都是GPT-4o的阿谀奉承行为。另一个原因是当时的AI工具不够强大。我能轻松运行这个基准测试，很大程度上得益于GPT-5.5承担了大部分繁重工作。在那之前，没有强力的智能体帮你自动化流程，你得自己动手写（虽然简单）的测试框架。我也不能太苛责别人：我当时也没多想就跳过了这一步。

也许我的基准测试设计得不够好？照片看起来还算合理：大多是类似Geoguessr风格的公路和风景照，种类也算丰富。我本可以收集几千张照片，但如果那个“魔法提示词”真的带来了巨大提升，哪怕只有几百张样本也应该能体现出来。如果有人愿意花一百美元做一个更精细的地理定位基准测试，而不是像我这样只花十五美元，我觉得这会是个有趣的项目。

最后，我们用基准测试来回答一个我一直以来的疑问：gpt-5.4 和 gpt-5.5 是否具备 o3 那样的地理定位能力？答案显然是否定的。

让 o3 在这类任务上表现出色的特性，并未延续到更新的模型中。

如果你喜欢这篇文章，欢迎订阅我的邮件更新，或把它分享到 Hacker News。

这里是一篇相关预告，标签与此文部分重合。

提示词也是技术债务 说“所有代码都是技术债务”既常见又正确。为了开发新功能而添加代码是一种必要的恶：你几乎总是不得不这么做，但每行新增代码都会增加系统的复杂性和维护负担。未来任何改动都必须兼容现有代码，或者至少不破坏它。一旦系统积累太多代码，单个开发者就无法完全理解其全貌：你不再能直接读代码就能明白它的作用，而必须依赖猜测、理论和启发式方法。明智的工程师会尽量少写代码。继续阅读全文……