一个 231MB 的聊天记录，打开要等 27 秒，这谁能忍！
2026 年 8 月 14 日，OpenAI 内部流出一份 Slack 截图和 X 平台的推文，直接引爆了技术圈。Andrew Ambrosino，Codex 桌面应用的负责人，公布了一组内部优化基准测试数据：一个 741 轮对话、体积 231MB 的超大聊天记录，加载时间从 27.62 秒被压缩到了 1.66 秒。网络请求从 894 个砍到 16 个，砍掉了 98.2%。前端加载的对话条目从 15,529 条骤降到 64 条，削减了 99.6%。内存增长降低了 41.2%，渲染引擎的堆内存增长降低了 87.8%。
听起来很燃对不对？
但事情没那么简单！
仔细看数据：一个 741 轮的对话，之前的客户端居然要发 894 个请求才能打开。894 个。打开一个聊天窗口，比打开一个中型网站还费劲。这哪是优化，这分明是擦屁股。更扎心的是——这些屎，是 OpenAI 自己拉的。
一个 741 轮对话，凭什么要发 894 个请求？
先把这个数字放大来看。
894 个请求，打开一个聊天窗口。这是什么概念？一个普通网页的首屏加载，理想状态下请求数在 50 个以内。894 个，相当于打开 18 个普通网页。而这 894 个请求里，大部分是在干同一件事：把对话历史一点一点拖进客户端。
为什么会有这种设计？
因为 ChatGPT 和 Codex 的桌面应用，采用的是“全量加载”策略——打开一个对话，就把整个对话历史全部拉下来。741 轮对话，每轮包含用户输入、模型输出、工具调用记录、文件变更、中间推理步骤，累积到 231MB。客户端拿到这 231MB 数据之后，还要逐条渲染到界面上。15,529 个 transcript 条目，一个一个塞进 DOM 树。
然后呢？
浏览器崩了，或者卡成幻灯片。
这不是猜测。2026 年 7 月，OpenAI 的 Codex 代码仓库里就有用户报告：更新之后，旧对话的历史记录全部无法访问，虽然文件还在本地，虽然服务端还能返回数据，但界面就是显示不出来。另一个 issue 更直接——长会话导致界面冻结、内存暴涨、用户失去对活跃对话的控制。
这些报告的时间是 2026 年 7 月。
优化数据公布的时间是 2026 年 8 月 14 日。
也就是说，这个问题在用户眼皮底下至少存在了一个月，甚至更久。而 OpenAI 的工程师在这段时间里，干的事情是：把 894 个请求砍到 16 个，把 15,529 条加载砍到 64 条。
这就怪了。
如果这个优化这么简单——从“全量加载”改成“按需加载”——为什么不在产品上线第一天就这么做？
“先上线再修”这六个字，值多少钱？
答案就藏在 OpenAI 的发布节奏里。
过去两年，OpenAI 的 shipping 速度是出了名的快。GPT-4 到 GPT-4o 到 GPT-5 系列，模型迭代按月计算。Codex 桌面应用从零到周活跃用户 500 万，只用了几个月。新功能、新模型、新工具，一个接一个往外扔。
代价是什么？
是客户端代码的质量。
Reddit 上有用户在吐槽：“一个万亿美元估值的公司，代码烂成这样。随便一个 vibe coded API wrapper 的渲染都比 ChatGPT 好。”另一位用户说得更直接：“我花了 5 分钟都加载不出 Anthropic 的账单面板。”
这不是个别现象。
第三方开发者甚至专门写了浏览器扩展来解决这个问题。一个叫“Unfreeze-for-ChatGPT”的扩展，专门针对 1000+ 条消息的长对话，声称能让“曾经冻结几分钟的对话在 2 秒内加载”。另一个叫“ChatGPT Performance Optimizer”的扩展，自动卸载旧对话、只保留最近 40 条可见。还有一个叫“GPT Cleaner”的扩展，只保留最后 N 条消息可见。
第三方开发者用浏览器插件解决的问题，OpenAI 花了一年多才在官方客户端里修复。
这不是技术能力的问题。这是优先级的问题。
OpenAI 的优先级一直是：新模型 > 新功能 > 新工具 > 性能优化。性能优化排在最末尾。因为新功能能拉新用户，性能优化不能。新模型能上头条，性能优化不能。
直到长对话的性能问题开始反噬产品本身。
70% 的用户在干“超过一小时”的活，然后产品卡死了
OpenAI 自己发布的数据显示：2026 年 5 月，超过 70% 的 Codex 用户让 agent 执行的任务，需要人类花费超过一个小时才能完成。
这意味着什么？
意味着用户不是拿 ChatGPT 来闲聊的。他们在做正经工作。写代码、改文件、跑工具链、反复调试。一个任务下来，工具调用记录、中间推理步骤、文件变更记录，堆出一座山。741 轮对话、231MB 数据，不是极端案例，是新常态。
然后呢？
然后打开这个对话要等 27 秒。然后界面卡死。然后用户刷新页面、重启应用、去 GitHub 上提 issue。
这不是产品体验问题。
这是产品可用性问题。
一个用来帮人“干一小时以上工作”的工具，自己在打开工作记录的时候先卡半分钟。这就像一辆号称能跑 1000 公里的电动车，每次启动要先热车 27 秒。没人受得了。
所以 OpenAI 终于动手了。
但动手的方式很有意思。
94% 更快，还是 94% 更慢？
先看一个数学问题。
Ambrosino 公布的数据写的是“94% faster”——从 27.62 秒到 1.66 秒。
但 Reddit 上立刻有人指出：这不是 94% 更快，这是“耗时减少了 94%”。真正的速度倍数是 16.6 倍。
一个简单的换算：如果原来的速度是 1，现在的速度是 16.6，那提升幅度是 1560%。但“94% faster”这个说法在普通人的直觉里，会理解成“快了将近一倍”。实际上快了将近 16 倍。
为什么不用“16 倍更快”？
因为“94%”听起来更精确、更技术、更可信。这是营销语言和工程语言的分野。工程师看的是 15,529 → 64，看的是 894 → 16。这些数字才是真正的优化幅度。而“94%”是给媒体写标题用的。
但问题来了。
一个产品的性能优化，数据漂亮到这种程度，恰恰说明之前烂到了什么程度。
从 894 个请求砍到 16 个，砍掉了 98.2%。这意味着之前 98% 的请求是多余的。从 15,529 条加载砍到 64 条，砍掉了 99.6%。这意味着之前 99.6% 的加载内容是用户当前不需要的。
一个产品，上线两年，98% 的网络请求是浪费的，99.6% 的渲染内容是多余的。
这还能叫“产品”吗？
这分明是一个一直在生产环境里跑着的内部测试版。
优化之后，问题就结束了吗？
再看一遍优化方案。
新的客户端不再一次性拉取整个对话，而是只加载 64 条 transcript 条目。用户看到的是最近的一部分对话，滚动的时候再按需加载更早的内容。
听起来合理，对吧？
但有一个细节被刻意忽略了：滚动加载的体验怎么样？滚动位置能不能稳定保持？翻页的时候会不会闪烁？
基准测试没有回答这些问题。因为基准测试只测了“打开对话”这一个动作。打开之后的交互体验，不在测试范围内。
更关键的是：这个优化还没有推送到生产环境。Ambrosino 公布的是内部 benchmark 数据，不是已经上线的产品更新。用户在 Reddit 上问“什么时候能用到”，没人回答。
还有一个更深的坑。
741 轮对话、231MB 数据，优化之后打开只要 1.66 秒。但如果对话增长到 2000 轮、5000 轮呢？按需加载的策略能撑多久？滚动加载会不会在某个临界点重新卡死？
没人知道。因为 OpenAI 没有公布这些数据。
一个矛盾，两种解释
现在回头看整件事，有两个截然不同的解读。
解读一：OpenAI 终于开始重视产品质量了。一个长期被忽视的性能问题，被内部团队用漂亮的数据解决了。16 倍的提速说明他们有能力做好，只是之前没时间。
解读二：OpenAI 的工程文化出了问题。一个核心产品的客户端性能烂到需要第三方浏览器扩展来救，烂到用户在 GitHub 上反复提 issue，烂到内部 benchmark 的“优化后”数据恰恰暴露了“优化前”有多离谱。而这一切，发生在他们号称“ coding is largely solved”之后。
Reddit 上有一条评论说得特别狠：“如果 AI 编程真的那么厉害，为什么 OpenAI 自己的 App 性能能烂成这样？不是说 AI 能让工程师的效率提升 10 倍、100 倍吗？”
这条评论被顶到了很高的位置。
但另一条评论给出了一个完全不同的视角：“没有公司比 OpenAI shipping 更快，同时还能交付生产级工具。两年前 20 美元的订阅，今天还是 20 美元。拿 2024 年的 4o 和现在的 5.6 Sol 比一比，你就知道这 20 美元花得值不值。”
两种声音，说的都是事实。
一个事实是：OpenAI 的产品质量确实配不上它的估值。
另一个事实是：OpenAI 的产品迭代速度也确实没有对手。
还有一个细节，被所有人忽略了
回到那张截图。
Ambrosino 在 X 上发的帖子下面，有一个数据没有被任何媒体报道：57 个点赞，70 个点踩。
一条公布了产品性能提升 16 倍的帖子，点踩比点赞还多。
为什么？
因为用户不在乎你“即将”变快。他们在乎的是“现在”为什么这么慢。他们在乎的是打开一个 741 轮对话要等 27 秒的这个事实，已经存在了多久。他们在乎的是 OpenAI 把“修复自己制造的 bug”包装成“重大性能突破”来宣传。
741 轮对话，231MB 数据，894 个请求，27.62 秒。
这些数字在 2026 年 8 月 14 日被公布出来，作为一个“优化成功”的案例。
但它们同时也是一份“产品失败”的体检报告。
OpenAI 自己写下的代码，把自己卡了整整两年。然后他们用更聪明的代码，把之前那些蠢代码擦掉了。擦完之后，他们拍了一张照片，发到了网上，配文是：“看，我们多厉害。”
问题是：谁该为那两年的卡顿负责？
这个问题，没有出现在任何一份 benchmark 数据里。