OpenAI on KnightLi的博客

OpenAI Plugins 仓库还值得看吗？从插件时代理解工具调用演进

Sat, 06 Jun 2026 22:26:00 +0800

openai/plugins 是 OpenAI 早期 Plugins 相关的示例仓库。虽然今天的 OpenAI 工具体系已经演进到 function calling、tools、Agents SDK、MCP 等方向，但这个仓库仍然有参考价值：它能帮助理解“让模型调用外部工具”这件事最早是怎么产品化的。

对现在的开发者来说，它更像历史资料和设计样本，而不是新项目的首选模板。

为什么还值得看

AI 工具调用的核心问题一直没变：

模型如何知道有哪些工具；
工具能力如何描述；
参数如何声明；
结果如何返回；
权限和用户确认怎么处理；
第三方服务如何被模型安全调用。

Plugins 时代用 manifest、OpenAPI schema、服务端 API 等方式解决这些问题。后来的 function calling、tool calling、MCP，本质上仍然在围绕这些问题演进。

适合谁看

这个仓库适合：

想了解 OpenAI Plugins 历史设计的人；
做 AI 工具生态或 Agent 平台的人；
需要理解 manifest / OpenAPI 工具描述的人；
想比较 Plugins、function calling、MCP 差异的人；
维护旧插件或迁移旧方案的人。

如果你是新项目，不建议直接照搬旧 Plugins 模式。应该优先看当前官方 API、tools、Apps SDK 或 MCP 相关文档。

从中能学到什么

最值得学的不是某段代码，而是工具接口设计思路：

工具描述要让模型读得懂；
API schema 要足够明确；
返回结果要适合模型继续推理；
用户授权不能藏在黑盒里；
外部工具失败时要有可理解的错误信息。

这些原则今天依然有效。

小结

openai/plugins 更像 AI 工具调用早期阶段的切片。它不一定适合新项目直接使用，但很适合拿来理解“插件、工具、Agent 能力扩展”这条线如何发展。

如果你现在做 AI Agent 工具集成，读它可以帮你看清很多设计问题的源头。

参考来源

openai/plugins - GitHub

OpenAI Whisper 怎么用？开源语音识别模型的定位和边界

Sat, 06 Jun 2026 22:26:00 +0800

openai/whisper 是 OpenAI 开源的语音识别项目，论文方向是 Robust Speech Recognition via Large-Scale Weak Supervision。它让很多人第一次低门槛获得了可本地运行的多语言语音转写能力。

今天虽然有 faster-whisper、whisper.cpp、各种云端 ASR 和新一代语音模型，但原版 Whisper 仍然是理解开源 ASR 生态的起点。

它适合做什么

Whisper 常见用途包括：

音频转文字；
视频字幕生成；
播客转写；
会议记录；
多语言语音识别；
语音翻译到英文；
字幕草稿和内容检索。

它的优势是鲁棒、多语言、开源、生态成熟。很多后续工具都是围绕 Whisper 模型或接口做优化。

使用边界

Whisper 不是万能听写员：

噪音、口音、多人重叠会影响结果；
专业术语和人名需要后处理；
长音频要分段；
时间戳不一定总是完美；
原版推理速度和资源占用不一定适合生产；
隐私音频要注意本地处理和存储。

如果你需要高吞吐生产服务，可能要看 faster-whisper、whisper.cpp、批处理、量化和 GPU 部署。

适合谁用

适合：

做字幕和转写工具；
处理播客、课程、会议录音；
研究 ASR 模型；
搭建本地语音转文字服务；
做多语言内容整理。

如果只是偶尔转写一段音频，托管服务可能更省事；如果你在意隐私和成本，本地部署更有吸引力。

小结

Whisper 是开源语音识别生态里的标志性项目。它不一定是今天速度最快的实现，但仍然是 ASR 工具链的重要基石。

如果你做音频转写、字幕或语音数据处理，值得从 Whisper 开始理解，再按性能需求选择优化版实现。

参考来源

openai/whisper - GitHub

ChatGPT 记忆功能升级：Dreaming 是什么，用户能怎么控制？

Sat, 06 Jun 2026 10:19:46 +0800

OpenAI 在 2026 年 6 月 4 日发布了 ChatGPT 记忆系统的新升级，标题是 Dreaming: Better memory for a more helpful ChatGPT。这次更新的重点不是让 ChatGPT “多记几条笔记”，而是把记忆从手动保存的条目，升级成更能持续整理上下文的系统。

一句话概括：新的 Dreaming 记忆系统想解决三个老问题：记忆会过期、记忆可能不够准、记忆规模变大后很难维护。

这项更新从美国的 Plus 和 Pro 用户开始推出，之后会在接下来几周扩展到更多国家，以及 Free 和 Go 用户。

ChatGPT 的记忆是怎么演进的

OpenAI 最早在 2024 年 4 月推出 ChatGPT 的 memory 功能，也就是后来常说的 saved memories。当时的逻辑比较像一本小笔记本：你明确告诉 ChatGPT “记住这件事”，它就把这条信息保存下来，并在以后的对话里使用。

这个版本有一个优点：用户很容易理解，也方便管理。但它的问题也明显：

需要比较强的提示，模型才知道该保存什么；
很多自然对话里的重要背景不会被记下来；
随着时间过去，某些记忆会过期；
用户需要自己维护、删除或更新旧信息。

2025 年 4 月，OpenAI 引入了第一版 Dreaming。它让 ChatGPT 可以参考已往聊天上下文，在后台自动整理更有用的记忆，而不是只依赖用户明确说“请记住”。

到了 2026 年这次更新，OpenAI 把 Dreaming 变成了更强、更省算力的记忆架构，目标是支撑更大规模用户和更长时间跨度的个性化体验。

Dreaming 和 saved memories 有什么区别

saved memories 更像用户手动写下的备忘录。比如你说：

`1`	`记住，我是素食者。`

ChatGPT 就可以在以后推荐食谱时避开肉类。

Dreaming 更像后台整理系统。它会从多次对话里综合信息，判断哪些背景对未来回答有帮助，并把它们整理成更可用的记忆状态。

这两者的区别可以这样理解：

saved memories 偏显式：用户说了要记，系统才更容易保存；
Dreaming 偏综合：系统从长期聊天历史里总结出对未来有用的上下文；
saved memories 容易变旧：比如旅行结束后，旧计划可能仍然留在那里；
Dreaming 更强调更新：它会尝试根据时间和后续对话修正记忆。

所以这次升级的重点不是“ChatGPT 偷偷记住更多东西”，而是让记忆更像一个会自动整理和更新的上下文层。

为什么“过期记忆”是大问题

记忆功能听起来简单，但真正长期使用时，最麻烦的是时间。

比如你曾经告诉 ChatGPT：你 7 月要去新加坡出差。出差前，这条记忆很有用。它可以帮你规划行程、提醒天气、推荐适合你的酒店和餐厅。

但等你已经回家，如果 ChatGPT 仍然以为你人在新加坡，再给你推荐当地外卖或附近活动，这条记忆就变成了错误上下文。

OpenAI 在文章里重点强调，新的 Dreaming 系统要解决这种“时间不会停在聊天结束那一刻”的问题。记忆不能只是保存过去的事实，还要理解这些事实是否已经过期、是否需要更新，或者是否只适合在特定时间段内使用。

这也是个性化 AI 很难的一点：记住用户不是越多越好，而是要记住对当前任务真正有帮助、并且仍然准确的信息。

这次更新重点优化了什么

OpenAI 把好的 ChatGPT 记忆拆成三个目标。

第一是延续有用上下文。你不需要每次开新聊天都重新介绍自己、项目、设备、偏好或约束。比如你之前讲过自己的相机和水下摄影装备，下次问兼容配件时，ChatGPT 应该能基于这些上下文给更具体的建议。

第二是遵守偏好和限制。如果你长期说过自己是素食者、喜欢安静晚餐、需要酒店空调足够强，这些偏好应该影响之后的推荐，而不是每次都从通用答案开始。

第三是随时间保持更新。旅行结束、项目阶段变化、工作地点改变、计划过期，这些都应该被记忆系统反映出来。

简单说，新的 Dreaming 不是只追求“记得住”，还要追求“记得对、用得上、不过期”。

用户能看到和管理什么

这次更新里一个重要变化是 memory summary，也就是记忆摘要页面。

用户可以在这个页面看到 ChatGPT 对自己的记忆概览，快速了解它认为哪些信息有助于个性化回答。这个摘要不是所有记忆的完整列表，而是一个高层视图，方便用户检查、纠正和管理。

根据 OpenAI 的 Memory FAQ，用户可以：

在设置里的 Memory 页面开启或关闭记忆；
查看 memory summary；
在 memory summary 里输入修改要求；
高亮某些内容并纠正；
对某些内容选择类似 “Don’t mention this again” 的处理；
使用 Temporary Chat，避免当前对话被用于后续个性化；
删除相关聊天、文件或连接应用，进一步清理来源。

这里有一个细节很重要：让 ChatGPT “以后不要再提”并不等于完全删除所有相关信息。要彻底删除某些可能影响个性化的内容，可能需要同时删除保存记忆、相关聊天、文件或连接应用里的来源。

隐私和控制仍然是核心

记忆越强，个性化越好，但隐私和控制也越重要。

OpenAI 在 FAQ 里说明，如果你不希望某段聊天内容用于个性化，可以关闭 Memory，或者使用 Temporary Chat。Temporary Chat 不会使用已有记忆，也不会创建新的记忆。

另外，用户仍然可以询问 ChatGPT 记住了什么，也可以要求它忘记某些内容。对于企业和教育场景，工作区管理员也有对应的记忆开关。

对普通用户来说，比较稳妥的使用方式是：

想让 ChatGPT 长期记住的偏好，可以明确告诉它；
不希望进入长期上下文的信息，用 Temporary Chat；
定期检查 memory summary；
发现过期或错误信息，及时修改或删除；
对敏感信息保持克制，不要默认把所有个人细节都交给记忆系统。

对用户体验有什么实际影响

如果这套系统表现稳定，ChatGPT 的体验会更像一个持续协作的助手，而不是每次都从空白聊天开始。

几个典型变化包括：

写作时更知道你的表达偏好；
做计划时更知道你的预算、地点和约束；
做技术项目时更容易延续前面的背景；
推荐内容时更少给通用答案；
长期项目里不需要反复补充同一批上下文。

但它也不会让 ChatGPT 变成真正意义上的“完整人生数据库”。OpenAI 明确提到，memory summary 不一定包含 ChatGPT 基于聊天综合出的全部上下文；同时，记忆也需要在准确性、相关性、隐私和可控性之间取平衡。

对 AI 产品的意义

这次更新说明，AI 助手的竞争已经不只是单轮回答质量。

真正有用的长期助手，需要处理几个更复杂的问题：

用户是谁；
用户正在做什么；
哪些背景仍然有效；
哪些偏好只适合某些场景；
什么时候应该记住，什么时候应该忘记；
怎么让用户看得见、改得动、关得掉。

Dreaming 的方向是把 ChatGPT 从“会聊天的模型”推进到“能持续维护上下文的产品”。这对个人助手、工作流工具、教育产品和企业知识协作都很关键。

不过，这也意味着记忆系统会成为 AI 产品里越来越敏感的一层。它既能提升效率，也可能因为记错、过度引用、隐私边界不清而造成困扰。未来好不好用，不只看模型能力，还要看控制界面、解释能力和删除机制是否足够清楚。

小结

OpenAI 这次发布的 Dreaming 记忆升级，核心不是让 ChatGPT 机械地保存更多信息，而是让它更好地综合长期上下文，并在新鲜度、连续性和相关性之间做平衡。

对用户来说，最直接的变化是：ChatGPT 可能更懂你的项目、偏好和长期目标，也更少需要你反复交代背景。

但记忆功能越强，越需要主动管理。建议用户定期查看 memory summary，敏感内容使用 Temporary Chat，发现错误或过期信息及时纠正。好的记忆不是无限记住，而是该记的记住，该更新的更新，该忘的忘掉。

参考来源

GPT-5.6 爆料：150 万 token 上下文窗口意味着什么

Wed, 27 May 2026 13:55:06 +0800

2026 年 5 月 26 日，有爆料称多名开发者在 OpenAI Codex 后端日志中发现了尚未官宣的 GPT-5.6 相关痕迹，其中一个内部代号为 iris-alpha，传闻支持 150 万 token 上下文窗口，并可能在 2026 年 6 月发布。

这类信息目前仍属于爆料，不等于 OpenAI 官方发布。更稳妥的看法是：它展示了下一代大模型可能继续沿着“更长上下文、更强代码能力、更好前端生成”几个方向推进。

爆料里提到哪些模型代号

报道提到，开发者在相关日志中看到的不只 iris-alpha，还包括 ember-alpha 和 beacon-alpha 等版本。

这些名字现阶段更像内部测试代号。它们是否都属于 GPT-5.6 系列、最终会不会对应公开 API 模型、发布时间是否会改变，都还没有官方确认。

所以不要急着把这些代号当成最终产品名。真正值得关注的是它们暴露出来的能力方向。

150 万 token 上下文为什么重要

报道里最醒目的数字是 150 万 token 上下文窗口。

爆料中给出的对比是：

当前 GPT-5.5 API 为 105 万 token
Codex OAuth 渠道约为 40 万 token
GPT-5.6 传闻提升到 150 万 token

上下文窗口决定模型单次能接收和利用多少信息。它包括用户输入、历史对话、系统提示、文件内容、日志、代码 diff、测试输出等。

如果这个数字属实，GPT-5.6 对几类任务会更有意义：

阅读大型代码仓库
分析长篇合同或技术文档
连续跟踪复杂项目
保留更长的 agent 工作历史
在一次任务里处理更多文件和更多测试反馈

但上下文窗口变大，不代表模型一定“更聪明”。它只是让模型能看到更多材料。模型是否能从长上下文里准确检索、归纳、保持目标一致，还要看训练、推理策略和工具调用能力。

真实世界测试的信号

报道还提到，有开发者在辅助工具 OpenCode 中做了较极端的真实世界测试：当输入达到约 90 万 token 时，模型仍能流畅响应，甚至处理超过 105 万 token 的请求。

如果这个反馈准确，它说明 OpenAI 可能不仅在扩展理论窗口，也在处理长输入下的响应稳定性。

对 AI 编程来说，这点比“窗口数字”本身更重要。开发任务里的上下文往往不是干净的长文本，而是代码、日志、错误栈、依赖文件、配置文件和用户指令混在一起。模型不仅要装得下，还要找得准。

前端界面生成能力也被提到

这次爆料还提到了 GPT-5.6 的前端生成能力。

据报道，爆料截图中模型在几乎没有详细提示词的情况下，生成了一个名为 Lumen Notes 的极简记事应用界面。报道强调的表现包括：

栅格布局更成熟
配色更克制
字体层级更清晰
导航结构更完整

如果这类能力稳定，AI 编程模型的价值会继续从“能写代码”转向“能生成更接近可用产品的界面”。这也是 Codex、Claude Code、Cursor、Gemini CLI 等工具最近都在推进的方向：不只是补函数，而是从需求到界面、测试、修复形成闭环。

还提到了哪些竞争模型

同一批爆料还提到，Anthropic 的 Claude Sonnet 4.8、Google 的 Gemini 3.5 Pro，以及 xAI 的 Grok 5，都可能瞄准 2026 年 6 月发布。

这部分同样要按传闻看待。即便多个模型确实都在 6 月前后更新，最终能力也要等官方文档、API 实测和真实开发任务验证。

不过大方向很清楚：模型厂商的竞争已经不只是聊天能力，而是更长上下文、更强工具调用、更稳的代码编辑、更好的 UI 生成，以及更适合 agent 长任务的可靠性。

我的判断

如果 GPT-5.6 的 150 万 token 上下文窗口最终成真，它对 Codex 这类编程 agent 的意义会比普通聊天更大。

因为 agent 编程天然会消耗大量上下文：读仓库、跑测试、看日志、比较 diff、保留用户偏好、连续修复问题。上下文越长，agent 越有机会在一次任务里保留完整线索。

但我更关心三个实际问题：

长上下文下的定位能力是否稳定。
大量日志和代码混合输入时，模型是否会被噪音带偏。
API、Codex、ChatGPT、OAuth 等不同入口是否会给出一致的上下文上限。

所以这条爆料可以关注，但不适合过早下结论。等 OpenAI 官方发布模型卡、API 文档和真实价格之后，再判断 GPT-5.6 是否真的适合大型代码仓库和长任务 agent 工作流，会更稳。

OpenAI Symphony 是什么？Codex 编排、Issue 驱动与 AI Agent 开发工作流

Mon, 25 May 2026 00:17:32 +0800

OpenAI 最近开源了一个很有意思的 Codex 编排规范：Symphony。

它不是另一个聊天式编程助手，也不是一个完整的新 IDE。更准确地说，Symphony 是一套面向 Codex 的“工作编排方式”：把类似 Linear 的 issue tracker 变成编程智能体的控制平面，让每一个未关闭的任务都能对应一个持续运行的 Agent。

官方文章里有一句话很能概括它的方向：过去工程师要同时盯着多个 Codex 会话，不断分配任务、审查输出、纠偏和重启；Symphony 想解决的，正是这个上下文切换瓶颈。

Symphony 解决的不是写代码，而是管理 Agent

单个 Codex 会话适合交互式开发：你给它一个任务，它修改代码，你 review，再继续追问。但当团队开始同时使用多个 Agent 时，问题会从“代码能不能写出来”变成“谁在做哪件事、做到哪一步、失败后谁来接手”。

OpenAI 的做法是把工作重心从“会话”切到“任务”：

issue 是真正的工作单元；
每个未关闭 issue 都可以映射到一个独立 Agent 工作空间；
Symphony 负责持续轮询任务看板，决定哪些任务需要启动、重试、停止或回收；
Codex 在工作空间里执行实现、测试、提交、创建 PR、更新状态等动作；
人类不再微操每个会话，而是审查结果、调整目标和维护边界。

这背后的变化很关键：Agent 不再只是一个被人类临时唤起的工具，而是开发流程里持续运行的一类执行者。

为什么是 issue tracker？

因为团队已经用 issue tracker 管理真实工作。

需求、bug、重构、迁移、调研、优先级、阻塞关系、负责人、里程碑，这些信息本来就沉淀在 Linear、GitHub Issues 或类似系统里。Symphony 没有重新发明一个庞大的控制台，而是把这些现有系统当作 Agent 的任务入口。

这样做有几个好处：

工作不必从 issue 复制到聊天窗口里。
人类可以继续按熟悉的方式创建、拆分、排期和关闭任务。
Agent 的状态变化能回写到同一个工作系统里，方便团队异步协作。
任务依赖可以自然形成 DAG，让未阻塞的任务并行推进。

如果把传统 CI 看成“代码提交后的自动化”，Symphony 更像是“issue 创建后的自动化”。

它的核心工作流

一个典型的 Symphony 流程可以理解为：

创建 issue
  -> Symphony 轮询到可执行任务
  -> 为该 issue 创建独立 workspace
  -> 启动 Codex agent session
  -> Agent 阅读任务、修改代码、运行测试
  -> 创建或更新 PR
  -> 写回任务状态、评论、证据和交付物
  -> 人类 review、合并或要求修改

官方规范里还强调了几个工程化点：

每个 issue 使用独立工作空间，降低相互污染；
编排器维护重试、并发和恢复状态；
工作流策略放在仓库内的 WORKFLOW.md，让团队把 Agent 应该如何处理任务写成可版本化的规则；
实现需要保留可观测性，至少要有结构化日志；
成功状态不一定是 Done，也可以是交给人类 review 的中间状态。

这说明 Symphony 不是简单地“让 AI 自动写代码”，而是在定义一套可运行、可恢复、可审计的 Agent 工作系统。

目标驱动，而不是死板状态机

OpenAI 在文章里提到一个重要转变：早期他们尝试把很多动作写死在外层 harness 里，例如提交代码、跑测试、处理 GitHub 流程。但随着 Codex 能力增强，这种方式反而限制了 Agent。

后来的方向是给 Agent 设定目标，而不是把每一步都写成固定状态转换。

比如，一个任务的目标可以是“完成 Vite 迁移并确保 CI 通过”。Agent 可以自己判断是否需要改配置、修测试、读 CI 日志、处理 review feedback，甚至拆出新的后续 issue。Symphony 负责提供边界、上下文和运行框架，而不是替 Agent 规定每一个动作。

这也是它和传统自动化脚本的区别：脚本擅长重复确定流程；Symphony 面向的是带有不确定性的工程任务。

和普通 Codex 使用方式有什么不同？

普通 Codex 会话更像“人带着 AI 写代码”：

人类打开会话；
人类描述任务；
人类观察输出；
人类随时纠偏；
任务结束后再开下一个会话。

Symphony 更像“团队把任务池交给一组 Agent 执行”：

人类写清楚 issue；
系统持续发现可执行任务；
Agent 在独立环境里推进；
结果以 PR、评论、测试状态、视频或分析报告的形式返回；
人类在关键节点做 review。

这不是替代工程师，而是把工程师从“同时照看多个会话”的负担里解放出来。OpenAI 在官方文章中提到，在部分团队中，合并到主分支的 PR 数量有明显提升；但更值得注意的是工作方式的变化：试验一个想法、发起一次重构、验证一个假设的启动成本变低了。

适合哪些场景？

Symphony 更适合这些任务：

常规功能实现；
已有代码库里的小型重构；
基础设施迁移；
依赖升级；
测试补齐；
CI 修复；
调研后生成实现计划；
根据 review feedback 继续修改 PR。

它不一定适合高度模糊、需要强业务判断或架构拍板的任务。对这类问题，交互式 Codex 会话仍然更自然，因为人类需要在过程中持续参与。

风险和边界

Symphony 的吸引力很强，但真正落地时不能只看“自动化”这一面。

几个边界要提前想清楚：

issue 必须写清楚，否则 Agent 会把模糊需求放大成错误实现；
Agent 的权限要收敛，尤其是仓库、密钥、生产环境和第三方服务访问；
每个工作空间要隔离，避免多个任务相互污染；
CI、测试、lint 和 review 仍然是必须的质量门；
任务状态、PR 链接、日志和失败原因要可追踪；
人类 review 不能省，尤其是涉及安全、计费、数据迁移和权限逻辑的改动。

官方仓库也把 Symphony 定位为 trusted environment 里的工程预览和参考实现，而不是一个拿来就能无脑替代研发流程的成品平台。

我对 Symphony 的理解

Symphony 最有价值的地方，不在于它用了 Linear，也不在于参考实现选择了 Elixir，而在于它重新定义了编程 Agent 的入口。

过去我们习惯从聊天窗口启动 AI 编程：这很灵活，但规模一大，人类注意力就成了瓶颈。Symphony 把入口放回 issue tracker，让 Agent 围绕真实任务持续工作。这样一来，AI 编程从“个人效率工具”开始向“团队工作流基础设施”靠近。

如果你已经在使用 Codex、Claude Code、Cursor Agent 或类似工具，Symphony 值得关注的不是某个具体实现，而是它背后的模式：

不要只管理 Agent 会话，要管理需要完成的工作。

这可能会成为下一阶段 AI 编程工具的关键分水岭。

参考链接

AI 数学里程碑：OpenAI 推翻 Erdős 单位距离猜想意味着什么

Fri, 22 May 2026 22:21:46 +0800

OpenAI 在 2026 年 5 月 20 日公布了一项很不寻常的研究结果：内部一款通用推理模型在平面单位距离问题上找到新的构造，推翻了数学界长期相信的一个上界猜想。

这不是一个普通聊天机器人随口给出的答案，而是 OpenAI 内部通用推理模型在一组 Erdős 问题评估中产生的证明。证明已经由外部数学家检查，OpenAI 也公开了证明文本、配套说明和模型推理思路的删节版。

问题是什么

平面单位距离问题由 Paul Erdős 在 1946 年提出。问题本身很好理解：在平面上放置 n 个点，最多能有多少对点之间的距离刚好等于 1？

数学上通常把这个最大数量记为 u(n)。如果把点排成一条直线，可以得到大约 n - 1 对单位距离。若把点排成方形网格，每个点和上下左右相邻点形成单位距离，数量大约可以达到 2n。Erdős 还给出过更精细的缩放方形网格构造，使单位距离点对数量达到 n^(1+C/log log n) 的量级。

长期以来，数学界普遍认为这类网格构造接近最优。对应的猜想可以粗略写成：u(n) 不会超过 n^(1+o(1))。这里的 o(1) 会随着 n 增大趋近于 0，意思是单位距离点对数可以比线性增长略快，但不应该出现一个固定指数优势。

OpenAI 模型给出的结果打破了这个直觉。它构造出一族无限多的例子：对于无穷多个 n，可以得到至少 n^(1+δ) 个单位距离点对，其中 δ 是固定正数。OpenAI 官方文章提到，原始 AI 证明没有给出明确的 δ 数值，但 Will Sawin 后续改进显示可以取 δ = 0.014。

证明过程为什么特别

这次突破最有意思的地方，不只是结论本身，而是证明路线。

Erdős 早期构造可以通过高斯整数理解。高斯整数形如 a+bi，它把普通整数扩展到复平面中，并保留了类似唯一分解的性质。借助这种数论结构，可以解释为什么某些缩放后的网格会产生很多单位距离。

OpenAI 模型没有继续沿着普通几何直觉推进，而是把问题带到更复杂的代数数论中。官方解释称，新证明使用更一般的代数数域，利用其中更丰富的对称结构制造大量单位长度差，从而在平面中形成更多距离刚好为 1 的点对。

更技术一点说，证明涉及无限类域塔和 Golod-Shafarevich 理论。这些工具对代数数论研究者并不陌生，但它们突然出现在一个欧氏平面里的组合几何问题中，才是外部专家认为这项结果很有启发性的原因。

这个过程大致可以拆成四步：

从单位距离问题的传统网格构造出发，把“点之间差值长度为 1”转化为代数结构中的范数和差值问题。
用更复杂的代数数域替代高斯整数，让可用的单位长度差数量变多。
借助无限类域塔和 Golod-Shafarevich 理论证明所需数域确实存在。
把代数构造重新落回平面点集，得到在无穷多个 n 上超过 n^(1+o(1)) 的单位距离点对数量。

也就是说，AI 不是简单搜索已有证明，而是把组合几何和代数数论连接起来，提出了一条人类主流直觉之外的构造路线。

专家反应

OpenAI 官方文章列出了多位数学家的评价，整体态度相当积极，但重点并不完全相同。

组合数学家 Noga Alon 认为，这个问题是 Erdős 最喜欢的问题之一，几乎所有组合几何研究者都思考过它。让他意外的是，正确答案并不符合长期相信的 n^(1+o(1)) 图景，而新构造还优雅地使用了高级代数数论工具。

菲尔兹奖得主 Tim Gowers 把这件事称为 AI 数学的里程碑。他的判断很重：如果这篇论文由人类写成并投稿到顶级数学期刊，他会毫不犹豫建议接收。这个评价真正强调的是证明质量，而不是 AI 话题本身。

数论学者 Arul Shankar 的关注点在模型能力。他认为这篇论文说明当前 AI 模型已经不只是数学家的助手，还能够提出原创且巧妙的想法，并把它们推进到完整证明。

Thomas Bloom 在配套说明里提出了一个更审慎的标准：评价 AI 生成证明，关键要看它有没有让人类更理解问题。在他看来，这个结果给出的答案是谨慎的肯定。它说明数论构造对离散几何的影响可能比过去想象得更深。

这些反应共同指向一点：数学界并不是因为“AI 做出来了”就接受结果，而是因为证明可以被检查，路线能解释问题，结论也确实改变了原有理解。

这是否意味着 AI 替代数学家

还不能这样理解。

这次案例里，AI 提出了关键构造和证明路线，但结果成为严肃数学成果，仍然依赖外部数学家的检查、解释和补充。配套论文的作用也很重要：它把 AI 给出的证明放回数学语境中，解释为什么这个构造重要、它与已有研究有什么关系、未来可能影响哪些问题。

更合理的判断是：AI 开始进入数学研究上游，但没有把人类专家挤出研究过程。

过去几年，AI 在数学里的角色主要是解竞赛题、生成证明草稿、辅助形式化证明、检索资料或改写论证。这些任务通常仍由人类指定方向。单位距离问题这次的不同之处在于，模型面对长期开放问题，提出了新构造，并把论证推进到可审查状态。

这会改变数学研究中的劳动分配。模型可能更擅长批量尝试长链条路线、连接远距离知识、探索研究者不一定优先尝试的方向。人类数学家的价值则会集中到几个更高层的问题上：

选择哪些问题值得研究。
判断 AI 给出的结果是否可信。
解释结果在学科中的位置。
决定哪些路线值得继续投入。

对未来科研的影响

这件事对 AI 行业的意义，可能比对单个数学猜想的意义更大。

数学是检验推理能力的理想场景。问题定义清楚，证明能被逐步检查，一条长论证只要中间断裂就无法成立。如果模型能在数学中保持复杂论证的连贯性，并连接不同学科工具，那么类似能力也可能迁移到其他科研领域。

OpenAI 官方文章也把影响延伸到生物、物理、材料科学、工程和医学。这里不能简单理解为“AI 很快会自动做科学发现”。更现实的变化是，AI 可能先成为科研中的路线生成器和假设放大器：它提出大量可能路径，人类专家筛选、验证、解释，再把少数有价值的路径推进下去。

这会带来三类变化。

第一，研究速度可能被拉高。很多开放问题不是没人能理解，而是可尝试路线太多、跨领域成本太高。AI 如果能持续提出可审查构造，会扩大研究者的搜索半径。

第二，跨学科连接会变得更常见。单位距离问题原本属于组合几何，新证明却借助代数数论。未来类似“远距离知识迁移”可能成为 AI 科研工具的重要价值。

第三，专家审核会更重要。AI 生成的路线越多，越需要可靠的验证机制。数学可以用证明审查来过滤错误，其他实验科学还需要实验、数据、复现和安全评估。AI 越像研究者，人类判断越不能省略。

这和 IMO 解题有什么不同

过去几年，AI 数学能力常常通过竞赛题来展示，比如 IMO 难度题目、大学数学题或者形式化证明任务。这些测试很重要，但它们和这次单位距离问题突破不是一类事情。

竞赛题通常有明确题面、确定答案和相对固定的解题范围。模型要做的是在有限时间内找到一条可验证的解法。即使题目很难，它仍然属于“已被设计出来的问题”，背后通常存在人类出题者预期的解题路径。

开放数学问题则不同。它没有标准答案，也不保证现有方法能解决。研究者需要判断哪些方向值得尝试，哪些工具可能跨领域迁移，哪些构造虽然反直觉但有机会成立。OpenAI 这次结果的意义正在这里：模型不是只解一道已知题，而是在一个长期开放问题中提出新构造，并改变了原有猜想。

所以，这次突破更接近数学研究，而不是数学考试。

为什么数学适合检验 AI 推理

数学是检验 AI 推理能力的高压场景，因为它很难靠流畅表达蒙混过关。

一条数学证明必须层层成立。定义是否准确、引理是否可用、推导是否跳步、结论是否真的覆盖目标命题，都可以被专家逐段检查。只要中间某一步断裂，整条证明就站不住。

这让数学比很多开放式写作任务更适合作为推理能力的测试场。模型不仅要给出看起来合理的答案，还要让答案经得起复核。单位距离问题这次尤其有代表性：结论重要，证明路线也能被外部数学家审查和解释。

当然，数学也不是唯一标准。现实科研还涉及实验误差、数据质量、设备条件和工程约束。但数学提供了一个清晰窗口：如果模型能在这里产出新证明，至少说明它在长链条推理和跨领域连接上已经出现了值得认真对待的能力。

AI 证明为什么仍然需要人类数学家

AI 给出证明，并不等于人类数学家可以退出。

第一，证明需要验证。AI 生成的论证可能有漏洞、隐藏假设或符号误用，必须由专家检查。第二，证明需要解释。一个结果为什么重要、它和已有理论有什么关系、它打开了哪些新问题，这些都不是形式上“证完了”就自动完成的。

第三，证明还需要改进。OpenAI 原始证明没有给出明确的 δ，后续由 Will Sawin 改进到可以取 δ = 0.014。这说明人类专家仍然在压缩、澄清和增强结果。

更重要的是，数学研究不是只追求“有一个证明”。研究者还要判断哪条路线更有价值，哪些问题值得继续推进，哪些构造可能迁移到其他领域。AI 可以扩大搜索空间，但学术判断仍然需要人。

这对 OpenAI 模型路线意味着什么

从产品视角看，这件事说明 OpenAI 的模型路线正在从“回答问题的聊天助手”，转向“能参与复杂任务的推理系统”。

聊天助手强调对话、总结、写作和工具调用。科研推理系统则要能长期保持目标，组合多个领域的知识，生成可验证的中间步骤，并把探索结果整理成专家能审查的形式。单位距离问题这次展示的，正是后者的一部分。

这也解释了为什么 OpenAI 会公开证明、配套说明和模型推理摘要。对科研任务来说，最终答案本身不够，过程也必须能被检查。未来面向科研、工程和专业知识工作的模型，很可能会越来越强调可追踪推理、可复核输出和专家协作接口。

换句话说，模型不只是更会聊天，而是更像一个可以分担研究探索的系统。

普通读者该怎么看

这件事不宜神化，也不该轻描淡写。

不宜神化，是因为 AI 还没有变成独立科学家。这个结果仍然需要人类数学家检查、解释和改进，也需要放回数学共同体中接受长期审视。一次突破不能直接推出“所有科学问题都快被 AI 自动解决”。

不该低估，是因为它确实越过了一个重要门槛。模型不只是复述知识，也不只是解训练过的相似题，而是在开放问题中给出新构造，并让专家认为它有数学价值。

更稳妥的理解是：AI 正在成为研究者的强力协作者。它可能先改变的是探索速度、跨领域连接和证明草稿生成，而不是一夜之间替代学术共同体。对普通读者来说，最值得关注的不是“AI 是否取代数学家”，而是“人类如何利用 AI 扩大能研究的问题范围”。

结论

OpenAI 这次结果的重要性，不只是推翻了一个近 80 年的猜想，而是展示了通用推理模型参与前沿研究的一种形态：提出构造、连接跨领域工具、产出可由专家审查的证明。

它还不是“AI 独立科学家”的终点，但已经不是简单的解题助手。未来几年，数学可能会继续成为观察 AI 科研能力的窗口：哪些问题能被模型推进，哪些证明需要人类补全，哪些跨领域连接会被重新发现，都值得持续关注。

参考资料：

OpenAI：《An OpenAI model has disproved a central conjecture in discrete geometry》：https://openai.com/index/model-disproves-discrete-geometry-conjecture/
OpenAI proof PDF：https://cdn.openai.com/pdf/74c24085-19b0-4534-9c90-465b8e29ad73/unit-distance-proof.pdf
OpenAI companion remarks：https://cdn.openai.com/pdf/74c24085-19b0-4534-9c90-465b8e29ad73/unit-distance-remarks.pdf
OpenAI model reasoning summary：https://cdn.openai.com/pdf/1625eff6-5ac1-40d8-b1db-5d5cf925de8b/unit-distance-cot.pdf

Cerebras IPO 大涨背后：晶圆级 AI 芯片能挑战英伟达吗

Mon, 18 May 2026 00:19:51 +0800

Cerebras Systems 终于登上了公开市场。

这家以“晶圆级 AI 芯片”闻名的公司，于 2026 年 5 月 14 日在纳斯达克挂牌交易，股票代码为 CBRS。根据 Cerebras 官方公告，其 IPO 发行价为每股 185 美元，公开发行 3450 万股 Class A 普通股，其中包括承销商全额行使的 450 万股超额配售权。

上市首日，Cerebras 股价大幅高开，一度接近 386 美元。按发行价计算，公司融资规模超过 55 亿美元，是 2026 年以来美国市场最受关注的 AI 硬件 IPO 之一。

这也是为什么它会被很多媒体称为“英伟达挑战者”。不过，把 Cerebras 简单理解成“下一个英伟达”并不准确。它真正特殊的地方，是选择了一条和传统 GPU 完全不同的技术路线。

Cerebras 做的不是普通 GPU

Cerebras 的核心产品是 WSE，完整名称是 Wafer-Scale Engine，中文通常可以理解为“晶圆级引擎”。

传统芯片制造会把一整片晶圆切割成许多小芯片，再进行封装、测试和出货。Cerebras 反过来做：它尽可能把整片晶圆直接做成一颗超大芯片。

这条路线的好处很直观：

芯片面积更大。
片上计算单元更多。
片上 SRAM 更接近计算核心。
数据在芯片内部移动距离更短。
更适合特定 AI 推理和训练负载。

在 AI 计算里，数据搬运往往比单纯计算更难优化。Cerebras 的思路是尽量把计算和存储留在同一片硅上，减少数据频繁离开芯片带来的延迟和能耗。

这也是 WSE 路线最吸引人的地方：它不是沿着 GPU 的老路继续堆规模，而是试图用更大的单颗芯片，换取更高的片上带宽和更低的数据移动成本。

为什么市场会兴奋

AI 芯片市场目前高度依赖英伟达。无论是训练大模型、部署推理服务，还是建设 AI 数据中心，英伟达 GPU 都是最主流的选择。

这让市场天然会关注两类公司：

能否降低对英伟达供应链依赖。
能否在某些 AI 工作负载上提供更高性能或更低成本。

Cerebras 正好踩中了这两个叙事。

它不是做通用 CPU，也不是做普通加速卡，而是直接围绕 AI 训练和推理设计系统。公司也一直强调，其晶圆级芯片和云端推理平台在某些模型推理场景中可以提供极高吞吐。

这类故事在 2026 年非常容易被市场放大。AI 基础设施仍在扩张，企业、云厂商和模型公司都在寻找更多算力来源。只要一家芯片公司能证明自己在某些场景里不是“又一个小 GPU”，市场就会愿意给它很高关注度。

OpenAI 合作让想象空间变大

Cerebras 被关注的另一个原因，是它和 OpenAI 的关系。

据媒体报道，Cerebras 与 OpenAI 签订了金额超过 200 亿美元的合作协议。搜狐原文提到，截至 2025 年底，这一协议带来的剩余履约义务达到 246 亿美元。

对一家刚上市的 AI 硬件公司来说，这类长期协议非常重要。它意味着公司不只是有技术故事，还有大客户需求作为支撑。

不过，长期订单和最终收入之间并不能直接画等号。AI 数据中心建设还受制于制造产能、封装、供电、交付节奏、客户预算和模型路线变化。尤其是芯片公司，拿到订单只是第一步，能否按期交付、能否稳定扩产、能否把毛利率做出来，才是更难的部分。

客户集中仍然是最大风险之一

Cerebras 的风险也很明显：客户集中度高。

搜狐原文提到，G42 曾在 2024 年贡献 Cerebras 85% 的收入，2025 年降至 24%；阿联酋穆罕默德·本·扎耶德人工智能大学则在 2025 年贡献了 62% 的收入。这意味着，即便 G42 占比下降，公司收入仍然高度依赖少数大客户。

对 AI 基础设施公司来说，客户集中有两面性。

好处是：大客户能带来快速增长、长期合同和订单可见性。

风险是：如果客户削减预算、改变技术路线、延后数据中心建设，或者监管环境发生变化，公司收入波动会非常大。

这也是市场看 Cerebras 时不能只看 IPO 涨幅的原因。上市首日股价反映的是热度和预期，长期估值最终还是要看收入结构、交付能力、利润率和客户多元化。

技术路线的短板：内存容量

WSE 的优势很突出，但短板也同样清楚。

搜狐原文提到，WSE-3 芯片配备 44GB SRAM，而英伟达 B200 配备 192GB 内存。Cerebras 的设计把大量计算和 SRAM 放在同一片晶圆上，这能减少数据移动，但也限制了可用内存容量。

对大模型来说，内存容量直接影响上下文长度、批处理规模和模型部署方式。上下文窗口越来越长，旗舰模型已经普遍朝百万级 token 上下文发展。在这种趋势下，片上 SRAM 的容量限制会成为现实约束。

传统 GPU 可以通过 HBM 堆叠、封装扩展和多卡互联继续增加内存容量。Cerebras 的晶圆级路线则更难简单扩内存，因为整片晶圆面积已经被计算单元和 SRAM 占用。想增加 SRAM，就可能牺牲计算面积。

这不代表 Cerebras 技术路线失败，而是说明它更像一种面向特定工作负载的架构选择。它可能在某些推理场景非常强，但未必能覆盖所有 AI 训练和推理需求。

它会取代英伟达吗

短期内，Cerebras 不太可能取代英伟达。

英伟达的优势不只是 GPU 性能，还包括 CUDA 生态、开发者工具、系统集成、网络互联、整机方案、云厂商支持和客户迁移成本。AI 公司选择英伟达，很多时候不是因为单颗芯片某个指标最好，而是因为整套生态最稳。

Cerebras 更现实的机会，是在特定 AI 负载上成为补充方案：

高吞吐推理。
特定大模型服务。
对延迟和片上带宽敏感的任务。
想降低单一 GPU 供应链依赖的客户。
愿意为性能试用新架构的大模型公司。

也就是说，它不是“英伟达杀手”，更像是 AI 算力市场里一条激进的替代路线。

小结

Cerebras IPO 大涨，说明资本市场仍然愿意为 AI 基础设施故事付出高溢价。

它的晶圆级芯片路线确实有独特性，也让它和普通 AI 加速卡公司区分开来。再加上 OpenAI 等大客户合作，Cerebras 有了足够强的市场想象空间。

但风险同样不能忽视：客户集中、交付压力、内存容量限制、生态壁垒，以及和英伟达竞争时的系统级差距，都会决定它能走多远。

对普通读者来说，Cerebras 最值得关注的不是股价涨了多少，而是它证明了一件事：AI 算力竞争不会只有 GPU 一条路。未来的大模型基础设施，可能会同时容纳 GPU、晶圆级芯片、自研加速器和云端专用推理平台。

参考资料

Codex 支持 ChatGPT 移动端远程访问，Enterprise 工作区可用 Access Tokens

Sun, 17 May 2026 09:12:07 +0800

OpenAI 在 2026 年 5 月 14 日更新了 ChatGPT Enterprise & Edu Release Notes，重点只有两件事：Codex 支持通过 ChatGPT 移动端远程访问，Enterprise 工作区可以使用 Codex access tokens 做受控自动化。

这不是一次模型能力发布，而是 Codex 产品形态的变化。Codex 正在从“本地或网页里的编程助手”，变成可以长时间运行、可以远程接管、可以接入企业自动化流程的 coding agent。

这次更新是什么

根据 OpenAI Help Center 的说明，Codex 现在支持从 ChatGPT mobile app 远程访问。用户可以在手机上连接正在运行的 Codex 环境，持续跟进长时间任务，并在需要时介入。

同时，ChatGPT Enterprise 工作区新增 Codex access tokens。它们面向可信的非交互式本地工作流，让自动化流程可以使用 ChatGPT workspace identity 和企业控制，而不需要每次通过浏览器登录。

可以把这次更新理解成两个入口：

移动端远程访问：解决“Codex 跑长任务时，人不在电脑前怎么办”。
Access Tokens：解决“企业自动化脚本如何以受控身份调用 Codex 工作流”。

移动端远程访问解决什么问题

Codex 的典型任务并不总是几秒钟完成。真实开发里，它可能要阅读代码库、修改多个文件、运行测试、等待命令输出、根据错误继续修复，甚至需要用户中途批准某些操作。

过去这类任务往往要求用户守在本地 Mac、桌面端、CLI 或 IDE 旁边。现在，ChatGPT 移动端可以变成一个远程控制台，让用户离开电脑后仍能跟进 Codex。

OpenAI 提到，移动端可以展示底层环境的实时状态，包括：

项目上下文。
approvals。
screenshots。
terminal output。
diffs。
test results。

用户也可以在手机上回答 Codex 的问题、重定向执行、批准操作、查看输出，并在不同 connected hosts 之间切换。底层任务仍然运行在 Mac host 或连接的远程环境中，手机端负责查看和控制。

这对开发者有什么价值

这项能力最适合长时间、需要中途确认的开发任务。

例如：

Codex 正在跑一组耗时测试，你出门后仍想看结果。
Codex 修改了多个文件，需要你在手机上看 diff 后批准下一步。
Codex 执行到某个危险操作前等待确认，你可以远程处理。
本地 Mac 上有多个 connected hosts，需要在手机上切换查看状态。

它的价值不是让你在手机上写代码，而是让你不用一直守着电脑。Codex 继续在原环境里工作，你只在关键节点介入。

这也说明 Codex 的使用方式正在接近“后台 Agent”：任务可以持续运行，用户不必全程在线，但仍要保留审批和控制权。

Access Tokens 解决什么问题

Codex access tokens 面向 ChatGPT Enterprise 工作区。它们的重点不是普通个人用户登录，而是企业内部可信自动化。

企业里经常有一些本地或内部流程需要非交互式运行，例如：

定时执行代码检查。
在受控机器上触发 Codex 工作流。
将 Codex 接入内部开发工具链。
在不打开浏览器的情况下使用工作区身份。

Access tokens 让这些流程可以带着 ChatGPT workspace identity 运行，同时继续受企业策略约束。相比临时人工登录，它更适合自动化；相比随便共享个人凭据，它也更容易纳入治理。

它不是普通 API key

这点很重要。Codex access tokens 不应该被理解成一个简单的“万能 API key”。

OpenAI 的说明里提到，access tokens 可用于 ChatGPT Enterprise 工作区，管理员可以管理工作区级可用性，拥有允许角色的成员可以创建自己的 tokens。治理界面在可用情况下也会反映 access token 活动。

也就是说，access tokens 被放在企业权限、角色和审计框架里：

管理员可以决定工作区是否开放。
不是所有成员都天然可以创建。
token 活动可以进入治理视图。
它继承 ChatGPT workspace identity 和企业控制。

这和个人随手生成一个长期密钥不是一回事。

安全默认值：Remote Control 默认关闭

Codex mobile remote access 涉及代码环境、终端输出、diff、测试结果和操作审批。如果默认开放，会带来明显企业安全风险。

因此 OpenAI 的默认策略是：remote control 默认关闭，管理员或 owner 需要在 Workspace settings 中启用。

启用移动端远程访问时，还可能涉及：

workspace-enabled Remote Control access。
SSO。
多因素认证。
passkey。

这说明它是一个需要企业 IT 和安全团队参与配置的能力，而不是“更新 App 后所有人自动可用”。

使用前需要更新什么

OpenAI 提到，要使用移动端远程访问，需要更新两端：

ChatGPT mobile app。
macOS 上的 Codex app。

如果工作区启用了相关要求，移动端设置过程还可能触发 SSO、多因素认证或 passkey 流程。

实际落地时，企业管理员还需要先确认 Workspace settings 里的 remote control 设置，以及哪些成员或角色可以使用相关能力。

对企业 Codex 使用方式的影响

这次更新把 Codex 往两个方向推进。

第一，Codex 更适合长任务。以前长任务最大的问题是用户要一直盯着，现在手机可以查看状态和批准操作，Codex 可以更自然地跑在后台。

第二，Codex 更适合企业自动化。Access tokens 让非交互式工作流有了更正式的身份方式，后续更容易接入内部 CI、代码审查、脚本和开发平台。

这两个方向结合起来，意味着 Codex 不再只是“开发者手边的 AI 助手”，而是在变成企业开发流程里的一个可管理 agent。

仍然需要注意的边界

这次更新很有用，但并不意味着 Codex 可以完全无人看管。

企业使用时仍然要注意：

哪些项目允许远程控制。
哪些命令需要审批。
token 如何创建、轮换和撤销。
mobile remote access 是否符合公司设备管理策略。
终端输出、截图和 diff 是否可能包含敏感信息。
审计日志和治理界面是否能满足内部合规要求。

尤其是 access tokens，一旦进入自动化流程，就要像其他企业凭据一样管理：最小权限、定期轮换、避免硬编码、及时撤销不用的 token。

总结

OpenAI 这次 Codex 更新的重点很集中：ChatGPT 移动端可以远程访问 Codex 长任务，Enterprise 工作区可以用 Codex access tokens 支持受控自动化。

前者让开发者不必一直守在电脑前，后者让企业可以把 Codex 更正式地接入内部工作流。两者合在一起，说明 Codex 正在从交互式编程助手，进一步走向可远程管理、可审计、可自动化接入的企业 coding agent。

参考链接：

OpenAI Help Center：ChatGPT Enterprise & Edu - Release Notes

Codex 额度为什么突然重置？Usage Limits 历史与消息来源整理

Sun, 17 May 2026 08:36:15 +0800

Codex 用户偶尔会遇到一种情况：明明还没到自己的常规 reset 时间，usage limits 却突然恢复了。这种“无预兆重置”不是第一次出现，也不一定代表额度规则永久变宽。它可能来自故障补偿、产品活动、增长里程碑，也可能只是某个窗口或部分账号状态被后台重置。

这张截图来自 OpenAI Codex 团队负责人 Tibo Sottiaux（@thsottiaux）在 X 上发布的公告。对额度用户来说，最关键的一句不是模型细节，而是：他表示会在当晚 reset usage limits。截图里的上下文说明，这次重置是一次补偿性操作，而不是普通周期刷新。

先说结论

Codex 额度突然重置，大致可以分成几类：

故障补偿：模型或 Codex 服务异常导致用户浪费额度，官方通过重置弥补。
发布或推广活动：新模型、新客户端、新功能上线时，临时提高或重置额度。
增长里程碑：用户规模达到某个节点后，官方用重置或提额鼓励继续使用。
后台策略调整：部分额度窗口、部分账号状态被重置，但 UI 不一定解释清楚。

普通用户最容易误解的是：看到“重置”就以为所有窗口都恢复了。实际上，Codex 可能同时有短窗口、weekly limit、不同模型和不同套餐限制。一次特殊重置可能只影响其中一部分。

这次截图说明了什么

截图显示，Tibo 在 2026 年 5 月 15 日发布更新，表示团队会继续监控，并在当晚重置 usage limits。它引用了前一条“正在调查部分用户反馈”的消息，因此这次重置更像一次服务波动后的补偿。

对用户来说，可以提炼出三点：

这不是用户自己的常规周期到了，而是官方主动重置。
这次重置有明确事件背景，不是永久提额公告。
“usage limits” 的具体覆盖范围仍要看实际账号显示，截图本身没有解释 5 小时窗口、weekly limit 是否全部包含。

所以，如果你看到额度恢复，正确做法不是马上推断“以后都变宽了”，而是先把它当成一次特殊 reset event。

为什么 Codex 会无预兆重置

Codex 的额度体系不是一个简单的“每天几点刷新”。用户界面通常只显示剩余额度或百分比，但后台可能同时跟踪：

短时间窗口，例如几小时内的使用量。
周额度或更长周期额度。
不同模型的消耗权重。
本地 Codex、Cloud Task、IDE/CLI 等不同入口。
Plus、Pro、Business、Team 等不同套餐。
账号是否满足某次特殊重置的后台条件。

当 OpenAI 做一次特殊重置时，用户未必能看到“这是普通周期恢复，还是特殊补偿”。如果只重置短窗口，用户可能误以为 weekly 也应该恢复；如果 weekly 没变，就会怀疑重置失败。

OpenAI 的 Codex GitHub issue 里也有人专门反馈过这个透明度问题：公开说 reset Codex rate limits，但产品 UI 没有说明到底重置了哪些窗口、是否包含 weekly limit、是否所有付费计划都一致生效。这也是“无预兆重置”让人困惑的核心原因。

历史上的几类重置

1. 2026 年 2 月：发布期与临时加量

Codex 桌面应用和 GPT-5.3-Codex 推广期间，社区用户讨论过 usage limit reset 和临时 2x rate limits。Reddit 上有用户提到 Codex app 刚发布时提供过限时 2x rate limits，并伴随 usage limit reset。

这类重置更像发布期运营动作：让更多用户试用新客户端、新模型或新工作流。

2. 2026 年 3 月：随机重置与异常消耗讨论

3 月前后，社区里多次出现“random usage reset”“weekly limit reset daily”之类帖子。有用户反馈自己的 weekly limit 被提前恢复，也有人认为这和 Codex 新模型、新安全拦截、异常消耗或 bug 修复有关。

这些讨论不等同于官方公告，但它们说明一件事：用户侧已经多次观察到额度并非只按固定周期恢复。某些情况下，后台会因为问题修复或补偿而触发额外 reset。

3. 2026 年 4 月：增长里程碑与付费计划重置

4 月下旬，有公开报道提到 Codex 达到 300 万周活用户后，OpenAI 重置了 rate limits，并计划在后续用户增长里程碑继续给用户更多额度空间。

GitHub issue 中也引用过 Tibo 4 月 28 日的 X 公告：他提到曾为“good week”重置付费计划的 Codex rate limits，让用户可以更多使用 GPT-5.5。不过同一个 issue 也指出，实际产品 UI 没有清楚说明到底哪些额度窗口被重置，weekly limit 是否全部包含。

这说明增长或活动型重置，往往也会带来解释成本：用户听到“all paid plans”，但账号里看到的结果未必完全一致。

4. 2026 年 5 月：故障补偿型重置

这次截图属于更典型的故障补偿型重置。Tibo 明确说团队找到了问题并会在当晚 reset usage limits。OpenAI Status 也记录过 2026 年 5 月 13 日 Codex 相关高错误率和延迟退化事件。

对普通用户而言，这次重点不是某个模型是否变差，而是：当服务端问题让用户额度被异常消耗时，OpenAI 可能会通过特殊重置来补偿。

用户该怎么判断一次重置来自哪里

遇到 Codex 额度突然恢复，可以按这个顺序判断：

先看自己的常规 reset 时间，排除普通周期恢复。
看 OpenAI Status 是否有 Codex、模型错误率、延迟或降级记录。
看 Tibo、OpenAI 官方账号、Codex GitHub issue 是否有说明。
看社区反馈是否集中出现“突然 reset”“额度燃烧异常”“weekly 没恢复”等讨论。
区分短窗口和 weekly limit，不要默认所有窗口都会一起恢复。

如果是官方事故补偿，通常会伴随状态页记录、负责人公告或大量用户集中反馈。如果只是后台部分窗口刷新，可能不会有明确公告。

消息来源怎么分辨可靠性

这类消息最好分层看：

官方状态页：最适合确认是否有服务故障、错误率、延迟、恢复时间。
Tibo / OpenAI 官方账号：适合确认是否有特殊 reset、补偿或活动口径。
OpenAI Codex GitHub issue：适合看用户对 UI、额度窗口、实际行为的反馈。
社区 Reddit / X 讨论：适合观察用户是否普遍遇到类似现象，但不能直接当成官方结论。
第三方新闻或博客：适合补充时间线，但仍要回到官方和原始链接核对。

写文章或做判断时，最好把这些来源分开写。比如“OpenAI Status 记录了服务问题”是官方状态；“Reddit 用户反馈随机重置”是社区观察；“GitHub issue 反映 UI 不透明”是用户提交的问题描述。

总结

Codex 额度突然重置，通常不是一个单纯的“系统送额度”。它可能来自故障补偿、发布期推广、增长活动或后台策略调整。真正容易造成误解的地方在于：Codex 同时存在多个额度窗口，而特殊 reset 不一定覆盖所有窗口，UI 也不一定清楚展示 reset scope。

所以，遇到无预兆重置时，最稳的判断方式是：先看客户端实际额度，再查 OpenAI Status、Tibo 公告、Codex GitHub issue 和社区反馈。不要只凭一次 reset 推断长期额度规则，也不要默认 weekly limit、短窗口和所有套餐都会同步恢复。

参考链接：

Codex 手机远程访问来了：用 ChatGPT App 跟进 Mac 上的编程任务

Sat, 16 May 2026 17:42:40 +0800

OpenAI 在 2026 年 5 月中旬把 Codex remote access 带进了 ChatGPT 手机 App。这个功能的重点不是“在手机上写代码”，而是让你用手机远程跟进 Mac 上正在运行的 Codex。

它更像一个移动审批和监控入口：Codex 继续在电脑上读项目、跑命令、改文件、看测试结果；手机端负责查看进度、回答问题、补充指令和批准操作。

对经常让 Codex 跑长任务的人来说，这个变化很实用。你不必一直坐在电脑前等它卡在哪里，出门或离开工位后，也能从 ChatGPT App 里接上现场。

它能做什么

根据 OpenAI Codex remote connections 文档，手机端远程访问可以做这些事：

在 Mac 主机上的项目里开启新线程，或继续已有线程；
发送后续指令，回答 Codex 提出的问题，调整任务方向；
批准命令和其他操作；
查看输出、diff、测试结果、终端输出和截图；
在 Codex 完成任务或需要你注意时收到通知；
在多个已连接主机和线程之间切换。

也就是说，手机端不是一个简化版聊天窗口，而是接入了 Codex 当前工作现场。你看到的不只是模型回复，还有它在主机上产生的工程上下文。

使用前需要什么

当前手机远程访问有几个前提。

第一，你需要有可用的 Codex 权限，并且手机和 Mac 使用同一个 ChatGPT 账号与 workspace。

第二，手机上要安装最新版 ChatGPT App，iOS 或 Android 都可以。如果 App 里看不到 Codex，先更新 ChatGPT。

第三，主机目前要求是 Mac，并且需要保持在线、唤醒、正在运行 Codex App。OpenAI 文档明确写到，移动端设置和设备控制当前需要主机上运行 Codex App for macOS，不能从 Codex CLI 或 IDE Extension 里完成设置。

第四，如果账号或 workspace 要求 MFA、SSO 或 passkey，需要先完成对应认证。团队 workspace 还可能需要管理员开启 Remote Control access。

这些限制说明它目前更像是 Codex App for macOS 的移动控制能力，而不是通用远程桌面，也不是所有 Codex 入口都能用。

Codex 手机远程访问的限制

这个功能虽然很方便，但限制也要提前看清楚。

第一，当前需要 macOS host。手机端连接的是 Mac 上运行的 Codex App，不是直接连接 Codex CLI、IDE Extension，也不是任意 Linux / Windows 开发机。

第二，主机必须在线。Mac 需要保持唤醒、联网，并持续运行 Codex App。如果电脑睡眠、断网或 Codex 关闭，手机端远程会话就可能断开。

第三，连接依赖扫码流程。你需要先在 Mac 端打开 Set up Codex mobile，再用手机扫描二维码进入 ChatGPT 完成绑定。它不是输入一个地址就能直接连，也不是纯账号登录后自动发现所有设备。

第四，远程操作仍然要经过审批流程。手机端可以批准命令和其他操作，但这也意味着你需要看清 Codex 请求做什么，再决定是否继续。尤其是涉及终端命令、文件修改、测试运行和外部访问时，不应该把手机审批当成无脑点确认。

所以它适合“人离开电脑后继续跟进任务”，不适合替代完整开发环境，也不适合把主机长期无人值守地开放给远程操作。

怎么连接

设置流程从 Mac 上的 Codex App 开始。

在 Mac 上打开 Codex。
在侧边栏选择 Set up Codex mobile。
Codex 会为这台主机开启远程访问，并显示一个二维码。
用手机扫描二维码，进入 ChatGPT 里的 Codex mobile setup 流程。
确认同一个 ChatGPT 账号和 workspace。
完成必要的 MFA、SSO 或 passkey 验证。
设置成功后，这台 Mac 会出现在手机端 Codex 里。

连接完成后，可以在 Mac 端 Codex 的 Settings > Connections 管理已连接设备。这里也可以设置是否让电脑保持唤醒、是否启用 Computer Use、是否安装 Chrome extension。

手机端适合干什么

手机端最适合三类操作。

第一类是审批。Codex 需要运行命令、访问文件、继续某个动作时，你可以在手机上看清请求，再决定是否批准。

第二类是纠偏。比如 Codex 走偏了、误解了需求、测试失败后需要你选方向，你可以直接补一句说明，让它继续处理。

第三类是查看结果。你可以看 diff、测试输出、终端日志和截图，不必回到电脑前才知道任务跑成什么样。

这和“手机写代码”不是一回事。真正有价值的是把手机变成工程任务的随身控制台，让 Codex 在主机上干重活，人只在关键节点介入。

常见问题

如果手机上看不到主机，先确认 Mac 上 Codex App 仍在运行，并且开启了 Allow other devices to connect。手机和主机也必须使用同一个 ChatGPT 账号与 workspace。

如果审批请求没有出现，可以打开 ChatGPT 手机 App，进入 Codex，再重新扫码或从主机重新开始设置。团队账号还要确认管理员是否已经允许 Remote Control access。

如果远程会话断开，通常要检查三件事：Mac 是否睡眠、网络是否断开、Codex App 是否关闭。远程访问依赖主机保持唤醒和联网。

如果认证卡住，就先完成账号或 workspace 的 MFA、SSO、passkey 流程。企业环境里，权限问题往往要管理员介入。

适合哪些场景

这个功能适合这些人：

经常让 Codex 跑较长的代码修改任务；
需要在通勤、会议间隙、离开工位时继续跟进任务；
希望及时审批命令，而不是让 Codex 停在等待状态；
同时管理多个项目或多个 Codex 线程；
使用 Mac 作为主力开发机，并已经习惯 Codex App。

不太适合这些场景：

主要使用 Windows 或 Linux 主机；
只用 Codex CLI 或 IDE Extension；
希望手机端独立完成完整开发环境；
网络不稳定，或 Mac 经常休眠；
团队 workspace 没有开启远程控制权限。

我的判断

Codex 手机远程访问的意义，不是把开发工作搬到手机屏幕上，而是把“等待 Codex 跑完”的时间变得更可控。

以前 Codex 长任务经常卡在审批、追问、测试失败或方向确认上。现在这些节点可以通过 ChatGPT 手机 App 处理，Mac 继续做真正的工程执行，手机负责轻量决策。

这会让 Codex 更像后台工程代理：它可以在电脑上持续工作，人不用一直盯着终端，只需要在需要判断的时候回来。限制也很清楚，目前它强依赖 macOS 上的 Codex App、同一账号 workspace、主机在线和组织权限。

如果你已经在 Mac 上重度使用 Codex，这个功能值得开启。如果你还只是偶尔问几句代码问题，它的价值可能没有那么明显。

参考资料

ChatGPT File Library 是什么：文件保存、容量限制和隐私边界

Sat, 16 May 2026 17:40:14 +0800

ChatGPT File Library 可以理解成 ChatGPT 里的文件库。

以前你在某个对话里上传文件，更多像是一次性给这轮聊天使用。File Library 出现后，上传到 ChatGPT 或由 ChatGPT 创建的文件会保存到账号里，之后可以在 Library 中重新找到、下载、删除，或者在新对话里再次引用。

这让 ChatGPT 更像一个长期资料工作区，而不只是临时聊天窗口。

它会保存哪些文件

ChatGPT 会自动保存你上传或创建的文件，包括：

文档；
表格；
演示文稿；
PDF；
图片；
ChatGPT 生成的文件。

生成图片仍会继续出现在 Images 标签页。File Library 更像是统一管理上传文件和生成文件的地方。

如果你经常让 ChatGPT 分析 PDF、整理表格、生成文档、处理演示稿，这个功能会减少重复上传。同一份资料不必每次重新找一遍，也方便在不同对话里继续使用。

怎么把文件加入新对话

在支持的客户端里，可以从输入框附近的附件或添加菜单进入文件选择。

常见流程是：

打开 composer 菜单，也就是附件或添加按钮。
选择 Add from library。
选择要引用的文件。

Release Notes 还提到，Library 和 composer 里的 Recent files 支持 Web、iOS 和 Android。也就是说，移动端至少可以从最近文件入口继续使用保存过的文件。

怎么查找和管理

在网页端，可以从左侧边栏进入 Library，集中查看上传和生成的文件。

文件可以按类型和来源筛选。官方帮助页提到的筛选维度包括：

上传文件或生成文件；
图片；
文档；
表格；
演示文稿；
PDF。

Storage 入口可以查看总使用量、剩余容量，以及是否超过限制。Release Notes 还说明，存储管理可从 Settings > Storage 进入，文件也可以直接在 Library 中删除。

各计划容量

OpenAI 在 2026 年 5 月 14 日的 Release Notes 中给出的容量如下：

计划	File Library 容量
Free	500 MB
Go	4 GB
Plus	20 GB
Business	20 GB
Pro	100 GB

这个容量包括上传的文件，也包括 ChatGPT 创建的文件，例如文档、表格、演示文稿和图片。

对普通用户来说，500 MB 足够放一些 PDF、截图和轻量文档，但不适合长期堆大量图片、表格和演示稿。对重度用户来说，20 GB 或 100 GB 会更像真正的资料库。

单文件限制

OpenAI 帮助页列出的文件限制包括：

上传到 GPT 或 ChatGPT 对话的单个文件最大 512 MB；
文本和文档类文件最多 200 万 token；
CSV 或电子表格通常约 50 MB，具体取决于每行大小；
图片单张最大 20 MB。

这些限制和账号总容量是两回事。即使你的账号还有很多剩余空间，单个文件也不能超过对应上限。

删除和下载

文件会保存在账号中，直到你手动删除。

删除方式一般是在 Library 中选中文件，然后点击删除或垃圾桶图标。OpenAI 帮助页说明，删除后文件会立即从账号中移除，并计划在 30 天内从 OpenAI 系统中永久删除，除非已经去标识化并与账号脱离关联，或出于安全、法律义务需要保留更久。

文件也可以从 Library 中下载。对于经常让 ChatGPT 生成文档、表格或演示稿的人，下载和清理会成为日常维护的一部分。

Temporary Chat 不会保存文件

如果你在 Temporary Chat 中上传文件，文件不会保存到账号或 Library。

这一点很重要。File Library 的默认逻辑是方便长期复用，而 Temporary Chat 更适合临时、敏感、不想留下长期上下文的任务。

如果只是让 ChatGPT 临时看一份不想保留的文件，可以优先考虑 Temporary Chat。反过来，如果这份资料后面还会反复用，放进 Library 更省事。

数据和训练设置

OpenAI 帮助页说明，文件和聊天会按照你的设置与数据控制项使用。

如果开启了 Memory，文件和聊天可能会帮助 ChatGPT 在对话之间记住对你有用的信息。对个人服务用户来说，如果开启了 Improve the model for everyone，OpenAI 也可能使用提交到 ChatGPT 的内容，包括上传文件，来改进模型表现。这个设置可以在 Settings > Data Controls 中关闭。

这意味着 File Library 不是一个单纯的本地文件夹。它是云端账号功能，使用前要想清楚哪些资料适合上传，哪些资料不应该交给第三方服务处理。

适合怎么用

File Library 适合这些场景：

长期分析同一组 PDF 或报告；
反复处理课程资料、会议材料、产品文档；
让 ChatGPT 继续修改之前生成的文档或表格；
在多个对话里复用同一份素材；
把 ChatGPT 变成轻量资料整理工作台。

不太适合这些场景：

上传高度敏感的身份证明、合同、病历、财务流水；
把它当成正式云盘备份；
不清理旧文件，长期堆积无用资料；
在不了解数据控制设置时上传公司内部文件。

我的判断

ChatGPT File Library 的价值不只是“多了一个文件列表”。它改变的是 ChatGPT 的使用方式：过去是一轮一轮聊天，现在开始变成带资料沉淀的工作空间。

但这个变化也带来新习惯。用户需要定期清理文件，关注容量，区分普通聊天和 Temporary Chat，也要检查数据控制设置。

如果你经常用 ChatGPT 看文档、改表格、整理资料，File Library 会明显省时间。如果你只是偶尔上传一份敏感文件问几句，反而要更谨慎，别让“方便复用”变成“忘了自己存了什么”。

参考资料

GPT-5.5 Prompt 迁移指南：旧提示词为什么要先删再改

Fri, 15 May 2026 01:17:35 +0800

OpenAI 在 API 文档里更新了 GPT-5.5 prompting guide。这份文档最有价值的地方，不是又给了一套更长的提示词模板，而是提醒开发者：迁移到 GPT-5.5 时，很多旧 prompt 反而应该变短。

官方文档地址：https://developers.openai.com/api/docs/guides/prompt-guidance

如果只看一句话，GPT-5.5 的提示词方向是：少写过程，多写结果；少堆规则，多定义验收；少用“永远必须”，多写清楚什么时候停止、什么时候验证、什么时候补证据。

旧 prompt 为什么需要重写

很多生产系统里的 prompt 是一层层堆出来的。模型不稳定时，加一条规则；工具调用出错时，再加一条禁止；输出啰嗦时，再加一段格式要求。时间久了，系统 prompt 会变成一份厚重的操作手册。

这种写法在旧模型上有时有用，因为模型需要更多步骤约束才能不跑偏。但到了 GPT-5.5，OpenAI 的建议很明确：不要把旧 prompt stack 原样搬过来。

原因很简单。过度指定过程会带来几类副作用：

噪声变多，模型要在大量旧规则里找真正重要的约束。
搜索空间变窄，模型不敢选择更高效的解法。
输出变机械，看起来像在执行脚本，而不是解决问题。
旧规则之间可能互相冲突，导致工具调用和最终回答都变笨。

GPT-5.5 更适合让 prompt 描述目标状态、约束、可用证据和最终输出，而不是把每一步都写死。

outcome-first：先定义什么叫完成

官方文档反复强调一个方向：GPT-5.5 最适合 outcome-first prompt。

也就是说，提示词里应该优先写：

目标结果是什么。
什么条件算成功。
哪些约束不能突破。
当前可用上下文是什么。
最终答案需要包含哪些字段或部分。
证据不足时怎么处理。

不太推荐的写法是：

`1`	`先检查 A，再检查 B，然后比较所有字段，再思考全部异常情况，再决定调用哪个工具，再调用工具，最后解释完整过程。`

更适合 GPT-5.5 的写法是：

解决用户的问题。成功标准：
- 基于可用政策和账户数据完成判断
- 如果允许执行操作，先完成操作再回复
- 最终输出包含 completed_actions、customer_message、blockers
- 如果缺少关键证据，只询问最小必要字段

这不是让 prompt 变得含糊，而是把控制点从“过程顺序”移到“结果和边界”。模型可以自己选择搜索、推理和工具调用路径，但必须对成功标准负责。

少用绝对规则，多写决策规则

旧 prompt 里常见大量 ALWAYS、NEVER、must、only。这些词不是不能用，但应该只留给真正不可违反的约束，比如安全规则、必填字段、禁止执行的动作。

对于“什么时候搜索”“什么时候问用户”“什么时候继续迭代”“什么时候停止”这类判断，GPT-5.5 更适合使用决策规则。

例如，不要只写：

`1`	`永远先搜索三次。`

可以改成：

先做一次覆盖核心问题的检索。如果前几个结果已经能支持关键事实，就停止检索并作答。只有当证据冲突、缺失或不足以支撑结论时，才继续搜索。

这种写法给了模型判断空间，也给了它停止条件。对需要联网、检索、文件搜索或数据库查询的产品来说，这一点很关键，因为每多一轮工具调用都会带来延迟和成本。

给检索设置 retrieval budget

GPT-5.5 prompt 里值得单独加的一类规则是 retrieval budget。

它不是预算金额，而是检索停止规则。它告诉模型：什么时候证据已经足够，什么时候应该继续找，什么时候该承认缺证据。

一个实用写法是：

普通问答先做一次宽检索，关键词要短且有区分度。如果前几个结果已经能支持核心请求，就基于这些结果回答，不再继续搜索。只有当结果冲突、缺失关键事实或不能支持结论时，才追加检索。

这类规则能减少两种常见问题：

搜索不够，答案没有证据。
搜索过头，模型在工具循环里浪费时间。

更重要的是，文档还提醒：没有搜到证据，不应该自动变成事实上的“否”。有时正确行为是说明证据不足，或者换一个更小的问题继续查。

reasoning effort 不要一上来拉高

GPT-5.5 的推理效率更高，所以 OpenAI 建议重新评估 low 和 medium，不要一遇到质量问题就直接把 reasoning effort 往上加。

更稳的顺序是：

先确认 prompt 是否写清楚了目标、输出格式和停止条件。
加上验证循环，比如测试、引用、复核或渲染检查。
为工具调用补上持久性规则和完成标准。
仍然不够时，再提高 reasoning effort。

换句话说，reasoning.effort 更像最后的调参旋钮，不应该替代清晰的 prompt 设计。

如果任务是短分类、字段抽取、支持工单分流、格式转换，可以先从低推理成本开始。如果是长文档综合、多源冲突判断、策略写作、复杂研究，再考虑 medium 或更高。

text.verbosity 控制输出，不等于控制思考

GPT-5.5 对输出格式很可控。官方文档建议使用 text.verbosity 配合 prompt 里的输出要求。

默认 text.verbosity 是 medium。如果产品需要更短、更干净的回复，可以使用 low。但这不意味着所有内容都要变短。

一个典型做法是：

面向用户的状态更新和最终总结保持简短。
代码、配置、结构化结果需要清楚时，仍然要求可读性。
不要为了“简短”牺牲字段完整性、引用和必要 caveat。

这对代码类产品尤其有用。可以让聊天回复短一点，但要求生成的代码保持可读变量名、清楚结构和必要注释。

preamble 和 phase：让长任务更可感知

GPT-5.5 在复杂任务中可能先做推理、计划或准备工具调用，然后才输出可见文字。对流式产品来说，用户会明显感知首 token 等待时间。

官方建议是：对多步骤、工具密集或长时间运行的任务，让模型先发一个短 preamble。它不需要解释完整计划，只要告诉用户“我会先做什么”。

例如：

`1`	`我会先检查相关文件和现有配置，然后再给出修改方案。`

在 Responses API 的长任务或工具密集工作流里，还要注意 assistant item 的 phase。如果应用使用 previous_response_id，API 会自动保留前序 assistant 状态；如果应用手动回放 assistant 输出，就要保留原来的 phase 值。

常见约定是：

phase: "commentary"：中间状态更新。
phase: "final_answer"：最终答案。
不要给 user message 添加 phase。

这部分看起来像底层实现细节，但对有工具调用、状态更新和最终回答的产品很重要。手动回放时弄丢 phase，容易让模型分不清中间进度和最终结论。

提示模型检查自己的工作

GPT-5.5 guide 里还有一条非常实用：在可以验证的任务里，给模型验证工具和验证规则。

对代码 Agent，可以明确要求：

修改后运行相关单元测试。
必要时运行 type check 或 lint。
影响包较大时跑 build。
全量验证太贵时，至少做最小 smoke test。
如果验证无法运行，要解释原因和下一个最好检查方式。

对视觉或页面产物，可以要求先渲染再检查布局、裁切、间距、缺失内容和视觉一致性。

对工程方案，可以要求计划里包含需求对应关系、涉及文件/API/系统、状态流转、验证命令、失败行为、隐私和安全考虑，以及真正影响实现的开放问题。

这类规则比“请认真一点”有效得多。它把“认真”落到了可执行检查上。

一个更适合 GPT-5.5 的 prompt 骨架

OpenAI 文档给出的结构可以简化成这样：

Role:
你是什么角色，要在什么上下文里工作。

# Personality
语气、协作方式、是否需要温度或观点。

# Goal
用户可见的目标结果。

# Success criteria
最终回答前必须满足的条件。

# Constraints
安全、业务、证据、权限、成本和副作用边界。

# Output
输出结构、长度、语气、字段要求。

# Stop rules
什么时候继续、什么时候重试、什么时候降级、什么时候询问、什么时候停止。

这个骨架的重点不是“每个 prompt 都要写这么多标题”。它真正想表达的是：复杂任务的 prompt 应该让模型知道目的地、边界和交付物，而不是把每一步都硬编码进去。

迁移旧 prompt 的实际顺序

如果你现在有一套 GPT-4.1、GPT-4o、GPT-5.2 或 GPT-5.4 的旧 prompt，不建议一次性大改。

更稳的迁移顺序是：

先切模型，固定当前 reasoning effort 和输出参数。
跑已有 eval 或真实样例，找出行为变化。
删除明显过时、重复、互相冲突的过程规则。
把“步骤要求”改成“成功标准”和“停止条件”。
补上检索预算、引用规则和缺证据行为。
为工具任务加验证循环。
最后再调 reasoning.effort 和 text.verbosity。

如果没有 eval，至少准备一组典型任务：简单问答、复杂检索、工具调用、格式化输出、拒答/降级、长任务完成。不要只用一个 demo case 判断 prompt 好坏。

一张旧 prompt 迁移清单

真正迁移旧 prompt 时，可以先按这张清单过一遍。它的目标不是把 prompt 改得更短，而是把无效约束删掉，把关键约束改成更可验证的形式。

检查项	常见问题	建议处理
重复规则	同一件事在不同段落反复出现，甚至措辞不一致	合并成一条清晰规则，只保留最终版本
绝对词	到处都是 `ALWAYS`、`NEVER`、`must`、`only`	只给安全、合规、权限、必填字段保留绝对约束
无停止条件	要求模型持续搜索、持续分析、持续修复，但没写什么时候停	增加 stop rules，例如证据足够、验证通过、达到轮次或成本上限
无验证命令	只写“确保正确”，没有测试、lint、引用或检查方式	改成具体检查：运行测试、类型检查、构建、引用来源或 smoke test
过程太细	把每一步都写死，模型只能照流程走	改成目标、成功标准、边界和输出要求
旧模型补丁	为旧模型弱点写的限制仍然保留	先删除，再用 eval 判断是否真的还需要
工具规则模糊	只写“必要时使用工具”	写清楚何时调用、何时停止、失败时怎么降级
输出格式漂移	有格式要求，但没有字段完整性要求	明确必填字段、可选字段、缺证据时的占位或说明

如果你只能做一件事，优先检查“无停止条件”和“无验证命令”。这两项最容易让 GPT-5.5 在长任务里变成无限工具循环，或者在没有证据时给出看似完整但不可验证的答案。

GPT-5.5 prompt 示例对比

下面这几组不是完整系统 prompt，而是迁移时常见的局部改写方式。

例子 1：检索问答

旧写法：

`1`	`回答前必须搜索至少 3 次。必须阅读所有相关结果。必须给出完整解释。`

新写法：

先做一次覆盖核心问题的检索。若前几个结果已经能支持关键事实，停止检索并回答。若结果冲突或缺少关键事实，再追加检索。最终回答说明依据；证据不足时明确说证据不足。

区别在于，新写法把“搜索次数”改成了“证据是否足够”。它给模型继续查的理由，也给模型停下来的理由。

例子 2：代码修改

旧写法：

`1`	`仔细修改代码。不要破坏现有逻辑。完成后告诉我改了什么。`

新写法：

完成用户要求的最小必要代码修改。成功标准：
- 只修改与任务相关的文件
- 保持现有公开接口兼容，除非用户明确要求变更
- 修改后运行相关单元测试；如果无法运行，说明原因和下一个最好验证方式
- 最终总结改动、验证结果和剩余风险

区别在于，新写法没有泛泛要求“仔细”，而是把谨慎落到文件范围、接口兼容、测试命令和风险说明上。

例子 3：结构化输出

旧写法：

`1`	`请输出 JSON。不要输出多余内容。字段要完整。`

新写法：

输出严格 JSON，不要添加 Markdown。必须包含：
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
如果证据不足，status 使用 "needs_more_info"，不要编造 evidence。

区别在于，新写法不仅要求 JSON，还定义了缺证据时的合法输出路径。这样模型不用在“必须完整”和“证据不足”之间硬编。

参数怎么配

reasoning.effort 和 text.verbosity 不应该孤立看。前者影响模型投入多少推理，后者影响输出有多详细。一个常见误区是：质量不够就先把 reasoning.effort 拉高，输出太长就把 prompt 写得更凶。更稳的做法是按任务类型配。

场景	reasoning.effort	text.verbosity	说明
字段抽取、分类、短格式转换	`none` 或 `low`	`low`	追求低延迟，重点是输出 schema 清楚
客服分流、简单工具路由	`low`	`low` 或 `medium`	规则明确时不需要高推理，保留必要解释即可
普通问答、轻量检索总结	`low` 或 `medium`	`medium`	需要一点判断，但不必默认高推理
多文档综合、冲突判断	`medium`	`medium`	先保证证据规则和引用，再考虑提高 effort
复杂代码修改、长任务 Agent	`medium` 或 `high`	用户回复 `low`，代码输出要求清晰	聊天更新可以短，代码和 diff 要可读
策略、方案、风险分析	`medium` 或 `high`	`medium` 或 `high`	需要解释取舍、风险和假设

对大多数应用来说，可以先从 low 或 medium 开始。只有当 prompt 已经写清楚成功标准、停止条件和验证规则，模型仍然遗漏关键约束时，再提高 reasoning.effort。

text.verbosity 也不是越低越好。低 verbosity 适合状态更新、客服短答、操作结果摘要；但对于代码、配置、迁移方案、审计说明，过低的输出会让结果难以审查。

哪些规则适合保留

迁移到 GPT-5.5 不是把旧 prompt 全部删掉。下面这些规则通常应该保留，而且要写得更明确。

安全规则：不能执行的动作、不能生成的内容、需要拒绝或降级的场景。
合规规则：行业政策、地区限制、年龄限制、审计要求、审批要求。
隐私规则：个人信息处理、敏感数据脱敏、日志记录限制、数据不得外传。
输出字段：API 响应、JSON schema、表格字段、前端组件需要的固定结构。
业务边界：退款规则、账号权限、服务等级、合同范围、人工客服升级条件。
工具权限边界：哪些工具能调用、哪些工具必须先确认、哪些工具禁止调用。
引用和证据规则：什么时候必须引用来源，证据冲突时怎么处理。

这些规则不是旧包袱，而是产品契约。区别只在于，迁移时要把它们从长篇口号改成可执行约束。

例如：

`1`	`不要泄露用户隐私。`

可以改成：

`1`	`不要在最终回答中输出完整手机号、身份证号、访问 token、API key 或内部用户 ID。需要引用时只显示脱敏版本，例如手机号保留后 4 位。`

哪些内容不要误删

删 prompt 时最危险的不是删掉废话，而是把真正的系统边界一起删掉。下面这些内容即使看起来“很老”，也不应该轻易删除。

隐私与数据处理要求：尤其是日志、导出、跨系统传输、第三方工具调用相关规则。
安全和权限限制：删除数据、转账、发邮件、改权限、执行 shell 命令等高风险动作的确认规则。
引用格式：如果产品依赖 citation、脚注、来源列表或审计链路，不要只因为它占空间就删掉。
工具调用边界：哪些工具只读、哪些工具可写、哪些工具必须用户确认。
失败行为：API 超时、数据缺失、检索失败、权限不足时应该怎么降级。
业务硬规则：价格、退款、封禁、风控、合规审核这类不能由模型自由发挥的规则。

一个简单判断方法是：如果删掉某条规则只会让输出风格变一点，可以考虑删；如果删掉后可能导致越权、泄露、误操作、错误承诺或审计断链，就应该保留，并改写得更精确。

总结

GPT-5.5 prompting guide 的核心不是“写更高级的提示词”，而是把旧 prompt 里过度指定过程的部分删掉。

更适合 GPT-5.5 的提示词应该做到：

目标优先，而不是步骤优先。
成功标准明确，而不是泛泛要求“做好”。
有停止条件，而不是无限搜索或无限工具循环。
有证据预算，而不是查不到就乱答或一直查。
有验证规则，而不是只靠模型自觉。
参数调优靠后，而不是一上来拉高 reasoning effort。

如果你的旧系统 prompt 已经很长，迁移到 GPT-5.5 的第一步可能不是加内容，而是删内容。把真正不可违反的规则留下，把过程细节改成结果、边界和检查项，通常比继续堆提示词更有效。

参考资料

OpenAI Prompt guidance：https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5：https://developers.openai.com/api/docs/guides/latest-model

OpenAI 新一代 Realtime 语音模型：GPT-Realtime-2、实时翻译与流式转写

Sat, 09 May 2026 10:58:47 +0800

OpenAI 在 2026 年 5 月 7 日发布了新一代 Realtime API 语音模型，重点不只是“说得更像人”，而是让语音代理可以在实时对话中理解、推理、调用工具、翻译和转写。

这次更新包括三个模型：

GPT-Realtime-2：面向实时语音 Agent 的主模型，支持更强推理、工具调用和长上下文。
GPT-Realtime-Translate：实时语音翻译模型，支持 70 多种输入语言到 13 种输出语言。
GPT-Realtime-Whisper：低延迟流式语音转文字模型，用于字幕、会议记录和实时工作流。

如果说早期语音助手更像“问一句、答一句”，这次更新的方向更接近“边听边做事”的语音界面。

GPT-Realtime-2：语音 Agent 的主力模型

GPT-Realtime-2 面向实时语音交互场景。它不仅要回答问题，还要在用户说话、改口、插话、补充约束时保持上下文，并在必要时调用工具完成任务。

官方重点提到的能力包括：

可以在回答前输出简短提示，例如“我查一下”，让用户知道系统正在处理。
支持并行工具调用，适合日程、搜索、订单、客服系统等多工具场景。
失败恢复更自然，避免语音会话突然中断或沉默。
上下文窗口从 32K 提升到 128K，适合更长的对话和复杂任务流。
对专业术语、专有名词、医疗词汇等场景有更好的保持能力。
语气和表达方式更可控，可以根据场景调整为冷静、同理、确认或更有活力的语气。
reasoning effort 可调，支持 minimal、low、medium、high、xhigh，默认是 low。

这意味着开发者可以把语音 Agent 用在更复杂的业务里，而不是只做简单问答。例如客服可以边听用户描述边查订单；旅行应用可以根据航班变化主动给出下一步建议；房产应用可以根据用户口头条件筛选房源并安排看房。

实时翻译：面向跨语言语音产品

GPT-Realtime-Translate 的定位是实时语音翻译。用户可以用自己的语言说话，对方听到翻译后的语音，同时还能看到实时转写。

它适合的场景比较明确：

多语言客服。
跨境销售和售前沟通。
在线教育和直播活动。
国际会议与活动主持。
视频平台和创作者内容本地化。

实时翻译的难点不只是“翻译准”，还包括低延迟、自然停顿、语气保留、口音适应和专业词汇处理。OpenAI 这次强调的是让跨语言对话更接近自然交流，而不是等一整段说完后再翻译。

流式转写：让语音内容马上进入工作流

GPT-Realtime-Whisper 是新的流式语音转文字模型。它的价值在于把语音在发生时就变成可处理文本，而不是等录音结束再统一转写。

常见应用包括：

会议实时字幕。
课堂和直播字幕。
实时会议纪要。
语音 Agent 的连续听写输入。
客服、医疗、招聘、销售等高频语音场景的后续流程。

对产品来说，流式转写可以明显缩短“说话到可操作文本”的时间。字幕更快出现，会议记录可以边说边生成，后续摘要、任务提取、CRM 写入等流程也能更早启动。

价格与可用性

这三个模型都已经在 Realtime API 中可用。官方给出的价格是：

模型	价格
`GPT-Realtime-2`	音频输入 $32 / 1M tokens，缓存输入 $0.40 / 1M tokens，音频输出 $64 / 1M tokens
`GPT-Realtime-Translate`	$0.034 / 分钟
`GPT-Realtime-Whisper`	$0.017 / 分钟

OpenAI 还提到，Realtime API 支持 EU Data Residency，并受到企业隐私承诺覆盖。对于欧洲企业或有数据驻留要求的语音产品，这是一个需要单独评估的点。

对开发者意味着什么

这次发布的重点，是语音能力开始从“输入输出层”变成“产品交互层”。

过去很多语音功能只是把语音转成文字，再把文字回复转成语音。真正难的是中间那层：理解用户意图、处理打断、补全上下文、调用工具、告诉用户系统正在做什么、在失败时自然恢复。

GPT-Realtime-2 试图把这部分能力直接放进实时语音模型里。对开发者来说，最值得关注的不是单次回答质量，而是它能否支撑持续会话和多步骤任务。

比较适合优先尝试的产品包括：

客服语音 Agent。
车载和移动端语音助手。
旅游、订票、房产、金融等需要边问边查的服务。
多语言会议和跨境沟通工具。
实时字幕、会议纪要和通话质检系统。

也要注意安全和告知

OpenAI 在发布页中强调，Realtime API 会包含多层安全措施，例如对会话进行主动分类，必要时中止违反政策的内容。开发者也可以通过 Agents SDK 增加自己的安全护栏。

还有一个容易被忽略的要求：当终端用户正在与 AI 交互时，开发者需要清楚告知，除非场景本身已经足够明显。

这对客服、销售、教育、医疗等场景都很重要。语音越自然，越需要在产品设计上明确边界：用户知道自己在和 AI 沟通，也知道哪些操作会被记录、转写或触发工具调用。

总结

OpenAI 这次 Realtime API 更新，把实时语音从“能听能说”推进到“能边听边处理任务”。

GPT-Realtime-2 负责更复杂的语音 Agent，GPT-Realtime-Translate 负责跨语言实时交流，GPT-Realtime-Whisper 负责低延迟转写。三者合在一起，覆盖了语音产品里最常见的三个基础能力：对话、翻译和转写。

如果你正在做客服、车载、会议、教育、跨境沟通或移动端语音助手，这次更新值得重点测试。真正需要验证的，不只是模型听起来是否自然，而是它在长对话、打断、工具调用、失败恢复和成本控制上的表现。

参考链接：

OpenAI：Advancing voice intelligence with new models in the API

马斯克诉 OpenAI 庭审焦点：非营利使命、控制权与 AI 竞赛

Fri, 08 May 2026 23:37:37 +0800

马斯克与 OpenAI、Sam Altman 之间的诉讼，表面上是一次旧合伙人之间的反目，深层则是 AI 行业最重要的结构性问题之一：当训练先进模型需要巨额资本时，最初以公益、开放、安全为旗帜成立的组织，能否以及如何转向更商业化的形态？

这场争议之所以被持续放大，不只是因为双方都是硅谷最有影响力的人物，也因为它把 OpenAI 的三个矛盾同时摆到了台前：非营利使命与商业融资、AI 安全叙事与市场竞争、创始人贡献与后续控制权。

庭审真正争什么

从公开报道看，马斯克一方的核心主张是：OpenAI 创立时具有明确的公益使命，马斯克早期捐赠和参与是为了支持一个不为个人谋利、服务人类整体利益的 AI 组织；而 OpenAI 后来建立营利性实体、接受巨额投资并发展为高估值公司，已经背离了最初承诺。

OpenAI 一方的核心回应则是：马斯克的捐赠并没有附带他所主张的永久性限制；OpenAI 之所以建立营利性结构，是为了获得算力、人才和资本，继续实现开发安全先进 AI 的使命；同时，OpenAI 认为马斯克当年并非反对营利化本身，而是希望获得控制权。

因此，这不是简单的“非营利 vs 营利”二选一，而是一个更具体的问题：OpenAI 的原始使命到底具有怎样的法律约束力？马斯克的 3800 万美元捐赠是普通捐赠，还是带有可执行条件的慈善信托？OpenAI 后续结构变化是否仍在非营利控制之下？

马斯克一方的叙事

马斯克在庭审中强调，他当初参与 OpenAI，是为了建立一个防止 AI 被少数商业巨头控制的公益机构。他将 OpenAI 的结构变化描述为对慈善机构的掠夺，并警告如果允许这种情况发生，会破坏美国慈善捐赠的基础。

这一叙事的力量在于，它抓住了 OpenAI 早期形象与后来商业成功之间的反差。OpenAI 最初给外界的印象，是一个以安全、开放、公共利益为核心的非营利研究实验室；而今天的 OpenAI 已经成为全球 AI 竞赛中的关键商业实体，与微软等巨头深度绑定。

但马斯克一方也面临一个问题：他是否曾经接受过某种营利性安排？如果他当年也讨论过建立营利性实体，只是要求保持非营利控制或获得更大控制权，那么案件就不再是“有没有营利结构”，而是“谁控制这个结构”。

OpenAI 一方的叙事

OpenAI 的公开页面和庭审辩护都把重点放在另一条线上：OpenAI 始终由非营利机构治理，建立营利性实体是为了筹集实现 AGI 使命所需的资源；马斯克后来发起诉讼，是因为他未能取得控制权，又创办了竞争对手 xAI。

OpenAI 还强调，马斯克曾向 OpenAI 非营利机构捐赠 3800 万美元，这笔钱已经用于公司使命；而马斯克现在试图把它重新解释成投资，并据此主张对 OpenAI 的权益。OpenAI 的说法是，马斯克当年希望获得绝对控制权，甚至曾提出将 OpenAI 并入特斯拉，遭拒后离开。

这套叙事的重点，是把案件从“OpenAI 背叛公益使命”转向“马斯克没有得到想要的控制权”。如果陪审团和法官接受这个框架，马斯克的道德指控就会被削弱，案件会更像一场迟来的创始人权力争夺。

为什么非营利结构是关键

OpenAI 最复杂的地方，不是它有没有商业收入，而是它的治理结构。它不是传统意义上的纯商业公司，也不是完全不参与市场竞争的研究机构。它试图用非营利实体控制营利性子公司，通过资本市场获取算力和人才，同时保留“造福全人类”的使命叙事。

这种结构本身有现实理由。训练前沿模型需要数据中心、芯片、研究人员、安全评估和全球产品基础设施。仅靠捐赠，很难长期支撑这种规模的投入。

但结构越复杂，信任成本也越高。外界会自然追问：非营利控制是否真的有效？商业合作是否改变了研发方向？安全承诺和产品增长发生冲突时，谁有最终决定权？这正是马斯克诉 OpenAI 案能引发广泛关注的原因。

庭审不等于 AI 安全公投

这场庭审里会反复出现 AI 安全、AGI 风险、开源承诺和公共利益等概念，但它本质上仍是一个法律案件。法院要处理的是捐赠性质、慈善信托、组织治理、控制权和不当得利等问题，而不是替全行业制定 AI 安全政策。

换句话说，即使马斯克赢了，也不等于法院会直接给出一套 AI 安全治理方案；即使 OpenAI 赢了，也不等于所有关于商业化和使命漂移的质疑都会消失。

真正值得关注的是判决可能产生的治理信号：法院会如何看待 AI 机构早期公开承诺的约束力？创始人捐赠和后续商业化之间的边界在哪里？非营利控制营利性 AI 公司这种结构，是否需要更强的外部监督？

对 AI 行业的影响

这场诉讼给整个 AI 行业提供了一个提醒：宏大的公益叙事一旦和巨额资本绑定，就必须有足够清晰的治理机制来支撑。否则，当公司成功后，早期使命、捐赠者期待、员工激励、投资人回报和社会风险就会全部挤到同一个法律和舆论战场上。

对其他 AI 公司来说，这意味着几件事：

早期章程、使命声明和捐赠协议必须写得更清楚。
非营利与营利实体之间的权责边界不能含糊。
安全承诺不能只停留在宣传层面，需要可审计的治理机制。
创始人、投资人和公共利益之间的冲突，要在融资前就有制度安排。

OpenAI 的规模和影响力让这些问题被放大，但它们并不只属于 OpenAI。随着 AI 公司继续吸收资本、进入医疗、教育、国防、办公和消费产品，这类治理冲突还会反复出现。

总结

马斯克诉 OpenAI 的核心，不只是“谁背叛了谁”，而是前沿 AI 组织在从研究实验室走向超级平台时，如何证明自己仍然受使命约束。

马斯克一方试图证明 OpenAI 背离了最初的慈善使命；OpenAI 一方则试图证明商业化是实现使命的必要路径，并把马斯克的诉讼解释为控制权失败后的反击。最终法院如何判断，还要看证据、捐赠文件、组织章程和双方当年的沟通记录。

无论结果如何，这场庭审都已经说明一件事：AI 公司不能只靠“为了全人类”的口号维持信任。越是接近通用人工智能、越是掌握巨大商业价值，治理结构就越需要透明、可验证、能经得起法庭和公众同时审视。

参考链接：

GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking 和 GPT-5.5 Pro 有什么区别

Thu, 07 May 2026 21:59:33 +0800

OpenAI 现在把 GPT-5.5 拆成了几个更明确的使用层级：Instant、Thinking 和 Pro。

很多人看到 GPT-5.5、GPT-5.5 Instant、GPT-5.5 Thinking、GPT-5.5 Pro 会混在一起。简单说：GPT-5.5 是这一代模型能力的总称，Instant 是日常快速模型，Thinking 是深度推理模式，Pro 是更高强度的研究级模式。

快速对比

名称	本质	适合场景	速度/成本	可用性
GPT-5.5	GPT-5.5 主模型/家族名；在 ChatGPT 里通常对应 GPT-5.5 Thinking 的能力定位	复杂工作、代码、研究、分析、工具调用	比 Instant 更重，但能力更强	Plus、Pro、Business、Enterprise
GPT-5.5 Instant	快速默认模型，替代 GPT-5.3 Instant	日常问答、写作、总结、轻量代码、快速查询	最快、最省额度	面向所有 ChatGPT 用户逐步推出
GPT-5.5 Thinking	深度推理模式	难题、长上下文分析、复杂代码、研究、文档密集任务	较慢，但推理更稳	付费用户可手动选择
GPT-5.5 Pro	更高强度的研究级模式	高风险/高精度任务：法律、商业、教育、数据科学、科研分析	最慢、最重，追求质量	Pro、Business、Enterprise、Edu

如果只想记一个选择规则：

日常快速任务：用 GPT-5.5 Instant。
复杂推理和代码分析：用 GPT-5.5 Thinking。
特别难、特别重要、需要更全面严谨：用 GPT-5.5 Pro。

GPT-5.5 是什么

单独说 GPT-5.5 时，通常是在说 GPT-5.5 这一代主模型能力，而不是某一个固定按钮。

OpenAI 对 GPT-5.5 的定位是“面向真实工作的更强模型”。它重点提升的是：

agentic coding；
复杂代码调试；
研究和资料综合；
文档、表格、演示文稿生成；
计算机使用和跨工具工作；
长任务中的持续推理和自我检查。

在 ChatGPT 里，用户看到的不是一个笼统的 GPT-5.5 按钮，而是更具体的 Instant、Thinking、Pro。所以如果有人说“我在用 GPT-5.5”，最好再问一句：是 Instant、Thinking，还是 Pro？

GPT-5.5 Instant：默认、快速、日常使用

GPT-5.5 Instant 是新的快速默认模型。OpenAI 官方说明里，它开始替代 GPT-5.3 Instant，成为 ChatGPT 的默认模型，并在 API 中作为 chat-latest 提供。

它适合这些任务：

日常聊天；
快速问答；
普通写作；
总结文章；
改写邮件；
轻量代码解释；
简单表格和清单；
不需要长时间推理的任务。

Instant 的核心优势是速度和默认可用性。你不需要每次都手动选择推理模式，也不需要为普通问题付出更高延迟。

它还有一个变化：OpenAI 强调 GPT-5.5 Instant 的回答更清晰、更简洁，并且个性化能力更强。对普通用户来说，这意味着它更适合“每天一直开着用”。

需要注意的是，Instant 不是“最强模式”。遇到复杂数学、长代码、架构设计、多文件分析、严肃研究时，它可能会自动切换到 Thinking，也可能需要你手动选择 Thinking。

GPT-5.5 Thinking：复杂任务的主力

GPT-5.5 Thinking 是更适合复杂任务的推理模式。

它适合这些场景：

代码调试；
架构设计；
多步骤推理；
长文档分析；
学术资料整理；
商业方案推演；
数据分析解释；
需要比较、权衡、验证的任务。

Thinking 的特点是会花更多时间推理。OpenAI Help Center 提到，当 GPT-5.5 Thinking 或 GPT-5.5 Pro 开始推理时，可能会先显示一个简短 preamble，说明它打算怎么做。用户也可以在模型还在 thinking 时追加指令，提前调整方向。

在 ChatGPT 里，手动选择 Thinking 时，还可以调整 thinking time。官方说明中，Plus 和 Business 用户可以使用 Standard 和 Extended；Pro 用户还会有 Light 和 Heavy 等更多选项。

我的理解是：Thinking 是“认真干活”的默认选择。只要任务涉及多步骤、长上下文或高准确性要求，就比 Instant 更合适。

GPT-5.5 Pro：研究级、更重、更严谨

GPT-5.5 Pro 是面向更难问题和更高精度工作的模式。

它适合这些场景：

法律材料分析；
商业研究；
教育和课程设计；
数据科学；
科研资料综合；
高风险决策前的深度审阅；
多文档、多约束、多轮验证任务。

OpenAI 在 GPT-5.5 发布说明中提到，早期测试者认为 GPT-5.5 Pro 相比 GPT-5.4 Pro，在完整性、结构性、准确性、相关性和实用性上都有明显提升，尤其在商业、法律、教育和数据科学领域表现更强。

Pro 的缺点也很明显：它更慢、更重，不适合每个小问题都用。它更像“专家审阅/研究伙伴”，而不是日常聊天入口。

另外，Pro 在工具支持上有特殊限制。OpenAI Help Center 写明，Apps、Memory、Canvas 和图像生成不适用于 Pro。如果你的任务需要这些 ChatGPT 功能，可能要用 Instant 或 Thinking。

工具支持有什么不同

根据 OpenAI Help Center，GPT-5.5 Instant 和 GPT-5.5 Thinking 支持 ChatGPT 的常用工具，包括：

Web search；
Data analysis；
Image analysis；
File analysis；
Canvas；
Image generation；
Memory；
Custom Instructions。

GPT-5.5 Pro 更偏研究级推理，但不是所有 ChatGPT 工具都可用。尤其要注意：

Apps 不可用；
Memory 不可用；
Canvas 不可用；
图像生成不可用。

所以选择模型时，不只看“哪个更聪明”，还要看你要用哪些工具。

上下文窗口有什么区别

官方 Help Center 给出的 ChatGPT 上下文窗口说明大致是：

模式	上下文窗口
GPT-5.5 Instant	Free：16K；Plus/Business：32K；Pro/Enterprise：128K
GPT-5.5 Thinking	付费档手动选择时通常为 256K；Pro 档可到 400K

这意味着：

普通聊天和短文档，Instant 足够；
多文件、多轮研究、长代码库分析，Thinking 更合适；
特别长、特别复杂的高精度任务，Pro 用户可以利用更大的上下文和更重推理。

怎么选

日常问答

用 GPT-5.5 Instant。

它速度快，足够聪明，适合随手问、快速写、快速改。

写文章、总结、改邮件

优先用 GPT-5.5 Instant。

如果文章很长、需要结构重写、需要多轮校对，再切到 GPT-5.5 Thinking。

写代码和调试

简单代码解释用 Instant。

多文件调试、架构设计、复杂报错分析，用 Thinking。如果是非常棘手的长期工程问题，可以考虑 Pro。

研究和资料分析

普通资料整理用 Thinking。

如果是法律、商业、科研、数据科学这类高精度任务，用 Pro 更合适。

需要图像生成、Canvas、Memory

优先用 Instant 或 Thinking。

不要默认选 Pro，因为 Pro 不支持部分 ChatGPT 工具。

简短结论

GPT-5.5 Instant 是日常默认模型，快、清晰、省额度，适合多数普通任务。

GPT-5.5 Thinking 是复杂任务主力，适合代码、研究、长文档、分析和多步骤推理。

GPT-5.5 Pro 是高精度研究模式，适合更难、更重要、更需要严谨性的任务，但工具支持和速度都更受限制。

GPT-5.5 本身更像这一代模型的总称。真正选择时，要看你在 ChatGPT 里选的是 Instant、Thinking 还是 Pro。

从 ChatGPT Release Notes 看 OpenAI 的产品节奏

Thu, 07 May 2026 14:31:22 +0800

OpenAI 的 ChatGPT Release Notes 是观察 ChatGPT 产品节奏的一个直接入口。这个页面会持续记录 ChatGPT 的模型、功能、账户安全、应用集成和客户端体验变化。

截至 2026 年 5 月 7 日查看，页面顶部显示最近更新为“yesterday”，最新条目集中在 2026 年 5 月 5 日。它们看起来是几条普通更新，但放在一起，其实能看出 ChatGPT 正在往哪里走：默认模型更可靠，记忆更可控，办公场景更深入，账户安全也在补强。

最新重点一：记忆来源变得可见

5 月 5 日的第一项更新，是 ChatGPT 的记忆改进。

OpenAI 表示，Plus 和 Pro 用户会逐步获得更个性化、更连续的回答。ChatGPT 可以更好地使用过去聊天、保存记忆、可用文件，以及已连接 Gmail 中的上下文，来提供更贴合用户的建议、推荐和下一步行动。

这类能力的价值在长期使用中才明显。用户如果正在做一个项目、写一系列文章、跟进一组邮件或反复处理同类工作，最烦的就是每次都要重讲背景。更强的记忆能力，就是为了减少这种重复。

但记忆越强，用户越需要知道模型到底用了什么上下文。因此 OpenAI 推出了 memory sources。用户可以在回答下方查看相关保存记忆、过去聊天、自定义指令，以及在特定情况下被引用的文件和 Gmail 邮件。

如果其中的信息已经过期、不准确或不再相关，用户可以更正、删除，或标记为不相关。

个性化不只是“更懂你”

很多人谈 AI 个性化时，只关注“模型更懂我”。但真正能长期使用的个性化，还必须解决三个问题：

用户能不能看见模型参考了什么。
用户能不能修改或删除这些信息。
用户能不能在不需要记忆时关闭它。

Release Notes 里明确提到，memory sources 只在用户自己的账户体验中显示，分享聊天时不会把这些来源暴露给其他人。用户也可以删除聊天、使用临时聊天、关闭记忆、断开应用连接，并管理内容是否用于改进模型。

这说明 OpenAI 不是只在堆个性化能力，也在给个性化补控制界面。对长期助手来说，这一步很关键。

最新重点二：GPT-5.5 Instant 成为默认模型

同一天，OpenAI 还把 GPT-5.5 Instant 作为 ChatGPT 新默认模型推出，替代所有用户原来的 GPT-5.3 Instant。

Release Notes 对这次模型更新的描述很务实：更准确、更清晰、更简洁，图片理解、STEM 问题，以及何时使用网页搜索的判断也更好。

这类默认模型更新对用户影响很大。大多数用户不会每天切换模型，他们感受到的 ChatGPT 质量，就是默认模型的质量。默认模型少一点幻觉、少一点废话、少一点无意义追问，实际体验就会明显改善。

OpenAI 还提到，GPT-5.5 Instant 会减少过度格式化和不必要的装饰性内容。这一点虽然小，但很贴近日常使用。很多时候，用户并不需要一篇结构完整的小论文，只需要一个准确、直接、能执行的回答。

付费用户还可以继续使用 GPT-5.3 Instant 三个月，之后该模型会退役。

最新重点三：ChatGPT 进入 Excel 和 Google Sheets

5 月 5 日的第三项更新，是 ChatGPT for Excel 和 Google Sheets 全球上线。

这项功能把 ChatGPT 放进 Microsoft Excel 和 Google Sheets 侧边栏，让用户可以在表格里直接构建、更新和理解数据。官方提到的场景包括追踪表、预算、公式、多工作表文件、情景分析和表格清理。

这说明 ChatGPT 不只是停留在“聊天窗口里回答问题”。它正在进入用户已经工作的地方。

对办公用户来说，表格是非常高频的真实工作现场。很多公司、团队和个人的业务数据，并不在复杂的数据平台里，而是在一堆 Excel 和 Google Sheets 文件里。如果 ChatGPT 能在表格旁边直接理解数据、写公式、整理多表和解释结果，它的使用门槛会比复制粘贴到聊天窗口低很多。

OpenAI 也提醒，依赖公式或分析前仍然要检查输出。这一点很现实：AI 可以加速表格工作，但不能替用户承担财务、运营或业务判断的全部责任。

4 月底的铺垫：安全和模型选择

再往前看，4 月 30 日的 Advanced Account Security 也值得注意。

这是一个面向个人 ChatGPT 账户的可选安全设置。开启后，账户会使用更强的登录方式，例如 passkeys 或兼容安全密钥，并关闭密码登录、邮件或短信登录码、邮件账户恢复等较弱路径。它还包括恢复密钥、更短活跃会话、登录通知和会话管理控制。

这类功能说明 ChatGPT 账户的重要性在上升。随着文件、记忆、应用连接、邮件、表格和工作项目逐渐进入 ChatGPT，账户安全就不再是普通登录问题，而关系到用户的长期工作上下文。

4 月 28 日，OpenAI 还把模型选择入口移到输入框附近，并把 Thinking 和 Pro 模型的 thinking effort 控制放进模型选择器。这是一个典型的产品细节改动：模型越来越多以后，用户需要更容易在发送消息前选对工具。

4 月下旬的另一个方向：更快的普通回答

4 月 22 日，ChatGPT 推出 Fast answers。

这个功能用于常见的信息查询。当问题不需要个性化，且 ChatGPT 有高置信答案时，它可以更快返回结果。Fast answers 不引用过去聊天或记忆，用户也可以在个性化设置里关闭。

这和记忆增强看起来相反，其实是同一个产品逻辑：不同问题需要不同处理方式。

有的问题需要结合用户长期背景，比如“帮我继续规划上周那个项目”。有的问题只需要快速准确，比如“世界七大奇迹有哪些”。前者需要记忆和上下文，后者需要速度和清晰。ChatGPT 正在把这些路径拆开。

产品节奏的变化

从这些 release notes 可以看到，ChatGPT 的更新已经不只是模型发布。

现在的更新同时覆盖：

默认模型质量。
记忆和个性化。
应用连接和办公插件。
账户安全。
模型选择和交互入口。
快速回答和移动端体验。

这意味着 ChatGPT 正在从单点 AI 聊天产品，变成一个更完整的工作平台。模型能力仍然重要，但产品体验、上下文管理、工具入口、账户安全和第三方应用集成都同样重要。

简短判断

这份 ChatGPT Release Notes 最值得看的，不是某一条具体更新，而是它们组合出的方向。

OpenAI 正在让 ChatGPT 同时变得更快、更懂上下文、更能进入办公场景，也更可控、更安全。GPT-5.5 Instant 负责提升默认回答质量，memory sources 负责解释个性化来源，Excel 和 Google Sheets 负责进入真实工作文件，Advanced Account Security 则为更重的账户使用补上保护。

接下来，ChatGPT 的竞争力不会只取决于模型参数，也会取决于它能否把这些更新组织成稳定、清晰、用户愿意长期托付上下文的产品体验。

ChatGPT Release Notes 更新：记忆来源、GPT-5.5 Instant 和表格插件

Thu, 07 May 2026 14:30:15 +0800

OpenAI 的 ChatGPT Release Notes 页面在 2026 年 5 月初更新，最新一批重点包括三件事：ChatGPT 的记忆来源和个性化能力增强，GPT-5.5 Instant 成为新的默认模型，以及 ChatGPT for Excel 和 Google Sheets 全球上线。

这几项更新放在一起看，方向很清楚：ChatGPT 正在从一个聊天入口，继续变成更持续、更个性化、也更贴近办公场景的工作助手。

Memory sources：个性化要更透明

最新更新里，最值得关注的是 memory sources。

OpenAI 表示，ChatGPT Plus 和 Pro 用户会开始获得更强的记忆改进。ChatGPT 可以更好地从过去聊天、保存的记忆、可用文件，以及已连接的 Gmail 应用中提取相关上下文，用来给出更贴合用户的想法、建议和下一步行动。

这意味着用户不必在每次新对话里反复解释自己的项目背景、偏好、工作习惯或已有材料。对于长期写作、项目规划、资料整理、学习和团队协作来说，连续性会更强。

但个性化越强，透明度就越重要。OpenAI 因此推出 memory sources，让用户看到哪些信息帮助 ChatGPT 个性化了某个回答。用户可以点击回答下方的 Sources 图标，查看相关保存记忆、过去聊天和自定义指令。Plus 和 Pro 用户还可能看到资料库中的文件，以及已连接 Gmail 中被引用的邮件。

如果某些信息过期、不相关或错误，用户可以更正、删除，或标记为不相关。

记忆控制仍然是关键

OpenAI 也说明，memory sources 不一定展示影响回答的全部因素，后续还会继续改进这个视图。

这个提醒很重要。它说明 memory sources 不是完整的“模型思考日志”，而是让用户理解个性化上下文的一种产品界面。它能提高可见性，但不能把所有影响因素都完全展开。

隐私和控制方面，OpenAI 表示 memory sources 只会显示在用户自己的账户体验里。如果用户分享聊天，相关 sources 不会出现在共享聊天中。用户也可以删除聊天，使用不会使用或更新记忆、也不会出现在历史记录中的临时聊天，关闭记忆，随时断开应用连接，并管理自己的内容是否用于改进模型。

这说明 ChatGPT 的个性化正在走一条更明确的路线：既要更懂用户，也要让用户知道它为什么这么回答，并保留管理入口。

GPT-5.5 Instant 成为默认模型

Release Notes 还确认，GPT-5.5 Instant 正在作为 ChatGPT 的新默认模型推出，并替代面向所有用户的 GPT-5.3 Instant。

这次默认模型更新主要改善几个方面：

准确性。
清晰度和简洁度。
图片理解。
STEM 问题回答。
判断何时需要联网搜索。

OpenAI 强调，GPT-5.5 Instant 在事实可靠性上更好，尤其是在准确性更重要的提示词中表现更稳。它也会给出更紧凑、更直接的回答，减少不必要的追问，降低过度格式化和无意义装饰带来的干扰。

对用户来说，这类变化可能不会像新功能按钮那样显眼，但会影响每天打开 ChatGPT 时的体感：回答更少绕路，更少啰嗦，也更少在简单问题上堆格式。

个性化和默认模型结合起来

GPT-5.5 Instant 对 Plus 和 Pro 网页端用户还会更有效地使用过去聊天、文件和已连接 Gmail 的上下文。

这和 memory sources 是同一条产品线。模型不只是“更聪明”，还要在合适的时候知道你之前做过什么、关心什么、已经提供过哪些材料。比如继续一个项目、写一份计划、整理邮件里的信息，或根据过去偏好给出建议时，ChatGPT 可以减少重复询问。

付费用户仍可在三个月内通过模型配置继续使用 GPT-5.3 Instant，之后该模型会退役。

ChatGPT for Excel 和 Google Sheets

另一个重要更新，是 ChatGPT for Excel 和 Google Sheets 全球上线。

它把 ChatGPT 放进 Microsoft Excel 和 Google Sheets 的侧边栏中，让用户可以在表格里直接构建、更新和理解数据。OpenAI 提到的场景包括：

追踪表。
预算。
公式。
多工作表文件。
情景分析。
表格清理。

在可用地区和条件下，它还支持 Skills 和 apps。

这类功能的意义很直接：很多办公数据并不在专门的 BI 系统里，而是在 Excel 和 Google Sheets 里。把 ChatGPT 放进表格侧边栏，比让用户复制粘贴到聊天窗口更自然，也更容易进入真实工作流。

使用限制和安装方式

Release Notes 提到，Free 和 Go 计划包含有限使用量；Plus 和 Pro 使用与 Codex 相同的 agentic 使用限制。如果用户超出计划限制，可以购买额外 credits。

安装方式也比较直接：Excel 版本从 Microsoft Marketplace 安装，Google Sheets 版本从 Google Workspace Marketplace 安装，然后使用符合条件的 ChatGPT 账户登录。

OpenAI 也提醒，用户在依赖公式或分析前需要检查输出。这点不能忽略。AI 可以加速表格工作，但公式、预算、财务和业务分析仍然需要人工复核。

近期更新脉络

如果把 4 月底到 5 月初的 release notes 放在一起看，ChatGPT 的方向更清楚。

4 月 30 日，OpenAI 推出 Advanced Account Security，给个人 ChatGPT 账户提供更强的登录要求和账户保护，包括 passkeys、安全密钥、恢复密钥、更短会话和登录通知。

4 月 28 日，模型选择入口移到输入框附近，让用户在发送消息前更容易选择模型；Thinking 和 Pro 模型的 thinking effort 控制也被放进模型选择器。

4 月 22 日，ChatGPT 推出 Fast answers，用于一些不需要个性化、且模型有高置信答案的常见信息查询。Fast answers 不引用过去聊天或记忆，用户也可以在个性化设置里关闭。

这些更新都围绕同一个目标：让 ChatGPT 更适合日常高频使用。该快的时候快，该个性化的时候个性化，该需要安全保护和可见控制的时候给出入口。

简短判断

这次 ChatGPT Release Notes 的重点，不是单个功能，而是产品形态继续收束。

GPT-5.5 Instant 提升默认回答质量，memory sources 让个性化更可见，Excel 和 Google Sheets 插件把 ChatGPT 放进办公表格，Advanced Account Security 和模型选择改动则补上账户安全和操作体验。

ChatGPT 正在变成更长期的工作层：它会记住更多上下文，进入更多工具，也承担更多日常任务。接下来真正需要观察的是，个性化透明度是否足够清楚，办公插件在真实复杂表格里是否稳定，以及用户能否在便利和控制之间保持平衡。

GPT-5.5 Instant 发布：ChatGPT 默认模型变得更准、更短、更懂你

Thu, 07 May 2026 14:28:40 +0800

OpenAI 在 2026 年 5 月 5 日发布 GPT-5.5 Instant，并开始把它作为 ChatGPT 面向所有用户的默认模型。

这次更新的关键词不是“更大”或“更炫”，而是更贴近日常使用：回答更准确、更简洁，语气更自然，也更会利用用户已经分享过的上下文。对 ChatGPT 来说，默认模型的变化尤其重要，因为它影响的是最多用户每天实际打开就会用到的体验。

默认模型为什么重要

Instant 是 ChatGPT 的日常主力模型。很多用户不会手动切换模型，也不会研究不同模型之间的差异。他们感受到的 ChatGPT，就是默认模型的质量。

所以 GPT-5.5 Instant 的意义不只是新增一个模型名，而是把基础体验整体往前推了一步。OpenAI 在公告中提到，这次更新让日常互动更有用、更顺手：不同主题下的回答更紧凑，聊天语气更自然，也能在合适的时候更好地使用已有上下文。

这种改进看起来不如一次大型多模态发布显眼，但对几亿级用户来说，默认模型少犯错、少啰嗦、少问多余问题，本身就是很大的产品变化。

更少幻觉，更可靠的回答

OpenAI 把准确性放在了第一位。

官方表示，在内部评测中，面对医学、法律、金融等高风险提示词，GPT-5.5 Instant 相比 GPT-5.3 Instant 产生的幻觉声明减少了 52.5%。在用户曾经标记过事实错误、难度更高的对话中，不准确声明减少了 37.3%。

这两个数字值得注意。它们说明 OpenAI 不只是追求模型“会说”，而是继续压低错误事实的发生率。尤其是在医疗、法律、金融这类领域，模型不能只给出流畅答案，还要更谨慎、更少编造。

当然，这不等于用户可以把 ChatGPT 当成专业意见的替代品。更准确的模型仍然需要在高风险场景里保留核查、引用来源和人工判断。但从产品体验看，默认模型的事实可靠性提升，会减少很多日常使用中的误导。

日常任务能力增强

GPT-5.5 Instant 不只是在事实性上改进，也提升了多种日常任务能力。

OpenAI 提到，它在分析照片和图片上传、回答 STEM 问题，以及判断何时使用网页搜索方面都有提升。这里的重点是“判断何时搜索”。很多用户并不关心模型内部是否调用工具，只关心答案是否新、是否准、是否能解释清楚。

如果模型能更好判断哪些问题需要联网，哪些问题可以直接回答，用户就不必反复提醒“你去查一下”。这会让 ChatGPT 更像一个主动可靠的助手，而不是只会等待明确指令的聊天框。

公告中的数学示例也体现了这个方向。GPT-5.5 Instant 在一开始认可错误解法后，能继续检查并发现代数错误，再回到正确方程求解。真正重要的不是它从不出错，而是它更有机会在推理链条中发现问题并修正。

回答更短，但不是变少

OpenAI 还强调，GPT-5.5 Instant 的回答更紧、更直接，同时保留必要内容和 ChatGPT 的友好语气。

这点对默认模型很关键。很多用户对 AI 回答的疲劳感，不来自信息不够，而来自结构太重、铺垫太多、格式太满。一个简单问题被拆成五个小标题、十几条注意事项，反而会让人觉得不自然。

GPT-5.5 Instant 的目标，是减少无谓的冗长和过度格式化，少问不必要的追问，也避免让回答显得杂乱的装饰性内容。对日常办公、写作建议、生活咨询和快速解释来说，这类改进往往比单项基准分更影响体感。

更短不等于更浅。好的默认模型应该能判断用户需要的是一句可执行建议、一段解释，还是完整方案。GPT-5.5 Instant 的方向，就是把这种分寸感做得更稳。

个性化能力继续增强

这次更新的另一条主线，是个性化。

OpenAI 表示，Instant 现在更擅长使用过去聊天、文件以及已连接 Gmail 中的上下文，让回答更贴合用户。它会判断什么时候额外个性化能改善答案，并更快搜索过去对话中的相关内容，减少用户反复交代背景。

这对长期使用 ChatGPT 的人很有价值。比如做计划、写文章、选工具、整理项目、延续一段工作流时，用户往往已经在过去对话里提供过偏好、约束和上下文。如果模型能自然接上，就会减少很多重复说明。

但个性化也必须配合透明度和控制。否则用户会不知道模型为什么突然提到某个偏好，也不知道哪些记忆正在影响回答。

Memory sources：让个性化更可见

OpenAI 同时推出 memory sources，覆盖所有 ChatGPT 模型。

它的作用是让用户看到哪些上下文被用于个性化回答，例如保存的记忆或过去聊天。如果某些内容过期、不准确或不想再被使用，用户可以删除或更正。

OpenAI 还说明，如果用户分享一段聊天，memory sources 不会展示给其他人。用户仍然可以删除不希望被引用的聊天，在设置中修改保存记忆，或使用不会使用和更新记忆的临时聊天。

这一步很重要。AI 助手越个性化，就越需要解释“我是根据什么在回答你”。Memory sources 不一定展示所有影响因素，但至少让个性化从黑箱里走出来一部分。

可用性安排

GPT-5.5 Instant 从公告当天开始向所有 ChatGPT 用户推出，并替代 GPT-5.3 Instant 成为默认模型。在 API 中，对应 chat-latest。

对付费用户来说，GPT-5.3 Instant 还会保留三个月，可通过模型配置设置访问，之后会被退役。

增强个性化功能会先在网页端向 Plus 和 Pro 用户推出，移动端随后上线，并计划在接下来几周扩展到 Free、Go、Business 和 Enterprise。Memory sources 会在网页端向 ChatGPT 消费者计划推出，移动端也会随后跟进。不同地区可用的个性化来源可能会不同。

简短判断

GPT-5.5 Instant 是一次面向默认体验的升级。

它不只是模型能力变强，而是在回答准确性、表达密度、语气、上下文使用和个性化透明度上一起调整。对普通用户来说，最直接的变化应该是：少一点废话，少一点事实错误，更容易接上你的背景。

对 OpenAI 来说，这也是默认助手形态的继续演进。ChatGPT 不再只是“每次从零开始回答问题”的工具，而是在逐步变成能记住偏好、理解上下文、知道何时搜索，并且让用户管理这些记忆来源的长期助手。

Codex App 保姆级上手：安装、沙盒、并行任务、Skills 与 MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App 可以理解成一个面向 AI 编程的任务工作台。它不是传统 IDE，也不是单纯聊天窗口，而是把多任务、项目管理、沙盒权限、Git、云端运行、插件、Skills、MCP 和自动化集中到一个界面里。

如果你已经在用 Codex CLI、Claude Code、Cursor 或其他 coding agent，Codex App 最值得关注的地方，是它把“多个 agent 并行干活”做成了一个更清晰的桌面工作流。

Codex App 适合做什么

Codex App 的核心价值不是让 AI 回答问题，而是让 AI 在项目目录里持续执行任务：

修改代码、运行命令、启动开发服务。
管理多个项目和多个任务。
在本地或云端执行长任务。
调用插件、Skills 和 MCP 扩展能力。
通过 Git、worktree 和 PR 管理改动。

OpenAI 官方也把 Codex App 定位成一个用于管理多个 coding agent 的界面。它适合需要同时推进多个代码任务的人，尤其适合前端页面、脚本工具、小型应用、文档整理和自动化工作流。

安装前准备

使用 Codex App 前，建议先准备好三个基础工具：

Git
Node.js
VS Code 或你常用的 IDE

Codex App 支持 macOS 和 Windows。安装后使用 ChatGPT 账号登录，首次进入时可以选择主要使用场景，例如编程或日常工作。Codex 会根据选择预装一部分插件和 Skills，后续也可以在设置和插件市场里调整。

Windows 和 macOS 的主要功能大体一致，但部分电脑自动化能力可能依赖具体平台和插件支持，实际以你当前版本显示为准。

界面结构：项目、任务和对话

Codex App 是典型的三栏布局：

左侧：项目、任务、历史对话、插件和自动化入口。
中间：当前对话窗口。
右侧：文件、浏览器、终端、运行结果等多功能区域。

一个项目通常对应一个本地文件夹。你可以在同一个项目里开多个对话，也可以同时打开多个项目，让不同 agent 并行执行任务。

任务列表会显示不同状态：

正在运行：agent 仍在执行。
等待批准：需要你确认权限、联网、安装依赖或执行高风险操作。
已完成：任务已经结束，可以查看结果或继续追问。

这比在多个终端窗口里来回切换更直观，也更适合同时管理多个 AI 任务。

沙盒与权限控制

Codex App 的权限体系围绕沙盒展开。默认情况下，当前项目文件夹会成为 agent 的主要工作范围。

常见权限边界包括：

可以读取和修改项目目录内的文件。
默认不能随意修改项目外文件。
默认会限制联网或高风险命令。
需要越权时，会向用户申请批准。

比较实用的模式是“自动审查”：低风险操作由系统自动放行，高风险操作再交给用户确认。这样既能减少频繁弹窗，又能避免 agent 在不知情的情况下执行危险操作。

“完全访问”要谨慎开启。它适合你明确知道 agent 要做什么，并且项目已经有 Git 备份、重要文件也有额外备份的场景。日常使用不建议长期保持完全访问。

上下文、模型和额度

Codex App 会显示当前对话的上下文使用情况。对话越长，历史内容越多，模型需要处理的上下文也越大。

实用建议是：

一个任务完成后，优先开新对话。
长对话可以手动压缩，但不要把压缩当成万能记忆。
复杂任务先写清楚目标、边界和验收标准。
不要把大量无关日志、报错和文件一次性塞进对话。

模型选择上，可以根据任务复杂度调整思考强度。简单修改、文案整理、重复任务不一定需要最高规格模型；架构迁移、疑难 bug、跨文件重构则更适合使用更强模型。

如果界面里有快速模式，也要注意它通常会带来更高的额度消耗。赶时间时可以开，日常不必默认开启。

图片生成与多模态输入

Codex App 可以接收图片和文件作为上下文，也可以在合适场景中调用图像生成能力。

这对前端和内容类项目很有用。例如你可以让 Codex：

根据截图修正页面样式。
替换网页中的不合适配图。
生成产品图、轮播图或页面素材。
根据 UI 截图指出需要修改的位置。

更高效的用法是：不要只说“改好看一点”，而是结合截图指出具体问题，例如“这个卡片间距太大”“这里的图和服务场景不匹配”“把地图区域做得更清楚”。

Steer：任务执行中及时纠偏

Steer 可以理解成“执行中接管方向”。当 agent 已经开始执行，但你发现它理解错了方向，不应该等它全部跑完再改。

这时可以使用引导功能，把新的指令插入当前执行流程，让 Codex 及时修正路线。

适合使用 Steer 的场景包括：

agent 误解了需求。
生成的页面风格明显不对。
正在执行的方案成本太高。
你临时补充了关键约束。

一般建议保留默认排队行为，只在确实需要干预时手动使用 Steer。这样既不会打乱正常任务，也能在关键时刻把方向拉回来。

计划模式和内置浏览器

复杂任务建议先开计划模式。计划模式下，Codex 不会马上改代码，而是先输出方案，必要时还会用卡片形式追问关键选择。

适合开计划模式的任务：

框架迁移，例如从普通 React 项目迁到 Next.js。
大范围重构。
涉及数据库、认证、部署的功能。
你还没想清楚技术路线的需求。

Codex App 的右侧区域可以打开内置浏览器，用来预览本地开发服务。你可以在页面上做批注，让 Codex 按具体 UI 位置修改问题。这种“看页面、点位置、让 AI 改”的流程，比纯文字描述更适合前端调试。

Git、IDE 和代码回滚

Codex App 不是完整 IDE。它可以查看代码、批注代码，但真正的手写编辑仍然更适合交给 VS Code、Cursor、Windsurf 等 IDE。

建议每个 Codex 项目都尽早初始化 Git：

让 Codex 创建或检查 .gitignore。
在完成一个可用状态后提交一次。
每次大改前确保有干净提交点。
不满意时用 Git 回滚代码。

如果只回滚对话历史，代码不会自动跟着回滚。比较稳的做法是：对话层面回到合适节点，代码层面用 Git commit hash 回到对应状态。

Worktree：并行开发多个方向

git worktree 是 Codex App 里非常适合并行 agent 的能力。

它的本质是：基于同一个仓库创建多个独立工作目录，每个目录对应不同分支。这样你可以让不同 agent 在不同文件夹里同时开发，不互相覆盖。

典型用法：

一个 worktree 优化客户评价组件。
一个 worktree 调整门店信息和地图布局。
两个任务完成后分别合并回主干。
合并完成后删除临时 worktree。

这比在同一个目录里让多个 agent 同时改代码稳得多。遇到冲突时，也可以按正常 Git 流程 review 和合并。

云端运行环境

Codex 不只能在本机工作，也可以把任务委托到云端环境执行。

云端运行适合这些场景：

出门在外，手边只有手机。
希望 agent 在后台跑长任务。
代码已经同步到 GitHub，需要让 Codex 基于远端仓库修改。
希望通过 PR 形式审查和合并改动。

典型流程是：先把本地代码推到 GitHub，再让 Codex 在云端环境中拉取仓库、执行任务、生成改动，最后以 PR 或 diff 的方式交给你审核。

本地继续开发时，要记得把远端最新改动同步回来。

记忆系统：写好 AGENTS.md

新对话默认没有完整历史记忆。项目一复杂，如果每次都重新解释背景，会很浪费。

最通用的做法，是在项目根目录维护 AGENTS.md。这个文件可以记录：

项目目标和主要技术栈。
常用命令。
目录结构说明。
代码风格和命名约定。
禁止事项，例如不要批量删除文件。
测试、构建和部署规则。

你也可以让 Codex 先通读项目，再生成一版 AGENTS.md，然后人工审一遍。复杂项目里，这个文件非常值得维护。

全局规则也要谨慎。适合写入所有项目都通用的安全约束，例如“不要递归删除目录”“执行破坏性操作前必须确认”。不要把某个项目的细节写进全局规则，否则会污染其他项目。

插件和自动化

插件用于把外部服务接入 Codex，例如 GitHub、Gmail、Google Drive、数据库、部署平台等。

插件的价值在于减少复制粘贴。比如你可以让 Codex：

查看某个 GitHub 仓库的 star 趋势。
整理邮件内容并发给自己。
定期执行某个检查任务。
把结果写成摘要。

自动化则适合重复任务。例如每周五下午检查一次仓库数据，并发送邮件报告。简单自动化任务通常不需要最高规格模型，选择较轻量的模型即可。

Skills：把工作流变成可复用能力

Skills 是 Codex 的“专业说明书”。它不是单次提示词，而是把某类任务的流程、规范、脚本和注意事项沉淀下来，让 Codex 后续稳定复用。

常见来源有三类：

官方 Skills。
第三方 Skills。
自己编写的 Skills。

适合做成 Skill 的工作：

把字幕整理成图文笔记。
按公司规范写周报。
批量处理图片或文档。
固定格式的代码审查。
特定框架的项目初始化。

如果某个提示词你已经复制粘贴了很多次，就值得考虑把它做成 Skill。

MCP：接入外部工具和数据库

MCP 可以理解成给大模型使用的标准化工具协议。通过 MCP，Codex 可以调用外部服务完成更具体的任务。

例如接入 Supabase 后，可以让 Codex：

创建数据表。
读取数据库结构。
修改后端接口。
把前端表单提交到数据库。
根据数据库状态调试问题。

这类能力很强，但也要注意权限边界。数据库、生产环境、部署平台、邮件账号都属于高风险资源。第一次接入时，最好使用测试项目和低权限账号。

部署插件

部署平台插件可以让 Codex 直接完成构建和发布，例如把前端项目部署到 Netlify 一类平台。

这类插件适合小型网站、原型页面、内部工具和展示项目。实际使用时建议注意：

部署前先跑本地构建。
环境变量不要直接写进代码。
发布后检查页面是否能正常访问。
生产项目要保留人工 review。

AI 可以帮你打通发布流程，但发布权限仍然要谨慎管理。

电脑自动化

在支持的平台和插件环境里，Codex 还可以操作浏览器或桌面应用，完成更接近 RPA 的任务。

例如：

打开聊天软件并准备一条消息。
浏览项目看板，汇总任务状态。
生成英文简报。
在你确认后发送给指定对象。
把这套流程做成定时自动化。

这类功能很有想象力，但也最需要安全边界。凡是涉及发消息、发邮件、提交表单、付款、删除数据的操作，都应该保留人工确认。

使用建议

Codex App 的正确打开方式，不是让它一次性全自动接管一切，而是把任务拆清楚，让它在受控环境里高效执行。

推荐习惯：

每个项目先初始化 Git。
复杂任务先开计划模式。
并行任务优先用 worktree。
项目规则写进 AGENTS.md。
高风险操作保留人工确认。
重复流程沉淀成 Skill 或自动化。
插件和 MCP 先在测试环境验证。

参考资料

小结

Codex App 的重点不是“多一个 AI 聊天窗口”，而是把 AI 编程变成一个可管理的工作台：本地项目、云端任务、Git、worktree、插件、Skills、MCP 和自动化都能串起来。

真正用好它的关键，是在“放权”和“控制”之间找到平衡。小任务可以大胆交给 Codex，复杂任务先让它计划，高风险动作必须确认。这样它才会从一个会写代码的助手，变成可以长期协作的工程工具。

ChatGPT 提示「此聊天已被标记为可能存在网络安全风险」的原因与处理

Wed, 06 May 2026 00:17:00 +0800

使用 ChatGPT 或类似大模型时，偶尔会遇到提示：「此聊天已被标记为可能存在网络安全风险」（This chat was flagged for possible cybersecurity risk）。这意味着平台的自动安全系统检测到对话内容可能违反了使用政策。

下面分析这个提示的触发原因、实际影响和处理方式。

为什么会被标记

输入内容敏感

对话中包含了可能被解读为有害的内容，例如：

要求生成恶意代码或脚本。
分析或利用网络漏洞。
询问非法活动相关内容。
寻求绕过安全限制的指令。

误报（False Positive）

即使意图是合法的代码分析或技术研究，系统仍可能把网络安全相关的术语误判为潜在攻击企图。AI 审核模型对关键词的敏感度较高，技术讨论和攻击行为之间的分界线有时不够精确。

平台审核机制

系统会自动扫描对话内容进行风险评估。在较新版本（如 2026 年 4 月更新）中，触发这类提示的情况更常见，说明平台可能引入了更严格的外部审核流程。

提示出现后的影响

当前聊天被终止：平台可能限制或停止当前会话的生成。
风险记录：多次触发风控会被记录，累积到一定程度可能影响账号状态。
高敏感度趋势：审核机制在持续收紧，技术讨论时更容易碰到边界。

如何处理

新建聊天

最直接的方式是放弃当前对话，点击「New Chat」开始一次全新会话。此前的上下文不再延续，通常就不会再次触发同一审核。

调整提示词

检查之前输入的内容，去掉可能被判定为敏感的词汇，换一种更中性的方式提问。例如把「如何绕过某限制」改成「某限制的原理是什么」，把「怎么写一个攻击脚本」改成「这类脚本通常利用什么机制」。

不要尝试绕过

避免通过提示注入等方式强迫 AI 回答被拒绝的问题。这类行为会增加封号风险，且往往适得其反。

确认操作本身

如果并未进行高风险操作（如分析钓鱼链接或编写病毒），大概率是 AI 对技术概念的误读。这种情况可以考虑向平台反馈，但短期内效果有限。

注意隐私

不要将包含敏感个人信息或商业秘密的内容用于 AI 分析。即使不触发风控，也存在数据泄露风险。

预防建议

技术讨论时尽量使用中性的术语描述问题。
避免在一个会话中集中讨论大量敏感主题。
定期清理不必要的历史会话。
重要账号避免频繁触碰审核边界。

小结

「此聊天已被标记为可能存在网络安全风险」通常由自动审核触发，不一定是账号违规。处理优先级很清晰：新建聊天 > 调整措辞 > 不要硬碰。日常使用中注意措辞的边界，可以避免大部分触发。

ChatGPT 和 Codex 登录要求验证手机号，可能是什么原因

Tue, 05 May 2026 23:57:50 +0800

最近有些用户会遇到一个情况：ChatGPT 账号已经注册成功，但登录 ChatGPT 或 Codex 时，系统又要求验证手机号。尤其是在使用 Codex 时，这个提示更容易让人困惑：账号明明能注册，为什么登录工具时还要补手机号？

这类问题通常和账号风控、免费额度滥用、网络环境以及账号安全策略有关。下面把常见原因和处理思路整理一下。

为什么会要求验证手机号

最直接的原因是风控升级。

Codex 面向用户开放后，免费额度会吸引大量真实用户试用，也会吸引批量注册、批量领取额度的行为。如果有人用注册机批量创建账号，再用这些账号消耗免费额度，平台就会更容易收紧验证策略。

从用户侧看到的结果就是：原本只需要邮箱或第三方登录的账号，在登录 ChatGPT 或 Codex 时，突然被要求补充手机号验证。

这不一定代表你的账号一定有问题，也可能是触发了更高风险的登录环境。例如：

使用了被大量用户共享的网络出口。
当前 IP 段被频繁用于注册或异常登录。
账号刚注册不久，却马上访问高消耗工具。
登录设备、地区、网络频繁变化。
免费账号使用行为和批量账号相似。

如果近期出现账号异常、登录受限或误封，也可能和网络环境被连带标记有关。尤其是多人共享的节点，风险会明显更高。

Codex 为什么更容易触发

Codex 和普通聊天不同，它更接近开发工具，可能涉及更高的资源消耗，也更容易被批量账号拿来消耗免费额度。

所以同一个账号在普通 ChatGPT 页面里看起来正常，到了 Codex 登录流程里却触发手机号验证，并不奇怪。可以把它理解为：不同产品入口会有不同的风险判断。

对正常用户来说，这类验证通常不是为了为难单个用户，而是为了限制批量注册和免费额度滥用。但如果你的网络环境不干净，也会被误伤。

处理方法一：升级 Plus

如果你是长期使用 ChatGPT 或 Codex，最简单的处理方式是升级 ChatGPT Plus。

从实际使用体验看，付费账号通常比免费账号更不容易触发这类额度滥用风控。Plus 账号本身也更适合稳定使用 Codex、ChatGPT 高级模型和其他高频功能。

不过要注意：升级 Plus 并不等于永远不会再触发验证。如果升级后仍然要求手机号，常见原因还是网络环境问题。

这时可以优先检查：

是否使用了大量用户共享的网络。
当前出口 IP 是否频繁变化。
是否长期使用低质量代理或公共节点。
是否同一网络下有大量 OpenAI 账号登录。

如果条件允许，换一个更稳定、更干净的网络环境再登录，通常比反复重试更有效。

处理方法二：检查网络环境

很多登录验证问题，看起来像账号问题，本质上是网络问题。

如果某个出口 IP 被大量用户共用，或者曾经被用于批量注册、异常登录、自动化请求，就更容易被标记。此时即使你是正常用户，也可能在登录 ChatGPT 或 Codex 时被要求额外验证。

可以从这几个角度排查：

换一个更稳定的网络环境。
避免使用公开、廉价、多人共享的节点。
尽量减少短时间内频繁切换地区。
不要在同一浏览器里频繁切换多个账号。
如果使用代理，优先选择质量更稳定、滥用更少的线路。

也可以借助第三方网络质量检测工具查看当前 IP 的风险情况，但检测结果只能作为参考，不能完全代表 OpenAI 的内部判断。

处理方法三：按要求完成手机号验证

如果系统明确要求手机号验证，最稳妥的方式仍然是按要求完成验证。

建议优先使用自己可长期接收验证码的号码。这样以后如果账号出现安全验证、恢复登录、异常提醒，也能继续处理。

不建议把重要账号绑定到来路不明、多人共用或无法长期使用的号码上。短期看可能能通过验证，长期看会带来账号找回、安全审计和二次验证风险。

如果你使用的是工作账号、团队账号或长期依赖的开发账号，更应该避免使用不可控的临时号码。账号安全比临时省事更重要。

升级 Plus 时要注意什么

如果你准备升级 Plus，可以先确认几件事：

账号本身可以正常登录。
当前网络环境稳定，不频繁跳地区。
支付方式可靠，不要使用来源不明的代付。
升级后保留好付款记录和账号邮箱。
不要把账号借给多人共用。

很多账号问题并不是出在 Plus 本身，而是出在升级前后的网络、支付和共享使用习惯上。一个账号如果长期多人共用、频繁异地登录、经常切换环境，即使付费也可能触发安全验证。

如果只是偶尔试用，免费账号也可以继续用。但如果你已经把 Codex 当成日常开发工具，Plus 会更适合长期使用。

不建议继续薅免费额度

Codex 这类工具的免费额度本来是为了让正常用户体验和试用。如果大量批量账号持续消耗免费额度，平台最终只能继续提高风控强度。

结果就是正常用户也会受到影响：登录更麻烦，验证更多，封禁误伤更多，账号使用成本更高。

对真正把 Codex 用在写代码、改项目、跑工程任务的人来说，与其把时间花在规避风控上，不如把账号和网络环境整理干净。长期看，这比反复注册新账号、切换节点、处理验证问题更省事。

小结

ChatGPT 或 Codex 登录时要求验证手机号，通常和账号风控、免费额度滥用、网络环境风险有关。它不一定代表账号本身违规，但说明当前登录环境或账号状态触发了更高等级的验证。

处理顺序可以很简单：

先检查网络环境，避开多人共享和高风险出口。
长期使用就考虑升级 Plus。
如果系统要求手机号验证，优先使用自己可长期控制的号码完成。
避免批量注册、共享账号和频繁切换登录环境。

稳定使用 AI 工具的核心不是一直绕过验证，而是让账号、网络和使用方式都尽量正常。这样才能减少登录麻烦，也能降低后续被误伤的概率。

谁把哥布林放进了 GPT-5.5？

Sat, 02 May 2026 10:51:36 +0800

OpenAI 最近复盘了一个很有意思的小问题：为什么 GPT-5.5 在 Codex 里会频繁使用 goblin、gremlin 这类表达？

这不是普通的口头禅问题。它暴露的是模型训练中的一个常见现象：模型可能不是直接记住某个词，而是在强化学习阶段学到一种“更容易被奖励”的表达风格。

现象是什么

GPT-5.5 训练后期，Codex 用户开始发现模型在解释代码问题、测试失败或异常行为时，会偏爱一组带有拟人化色彩的表达。

OpenAI 内部也观察到类似现象：GPT-5.5 相比早期版本，更常在响应里使用 goblin、gremlin 等词。研究团队把这个现象称为一种“怪异人格特征”，并尝试追踪它从哪里来。

不是简单的数据复读

最直观的猜测是：训练数据里这类表达变多了，模型只是学到了高频词。

OpenAI 检查后发现，事情没有这么简单。它们在预训练语料中确实能找到相关词，但数量不足以解释模型后期行为变化。更关键的是，模型在强化学习前后表现差异明显：后期训练把这类风格放大了。

这说明问题不只是“数据里有什么”，还要看训练过程奖励了什么。

强化学习放大了风格偏好

OpenAI 的分析里，关键变化发生在强化学习阶段。GPT-5.5 在训练中学会了更活泼、更有辨识度、更像“有性格”的写法，而某些带有调侃意味的词正好符合这种风格。

简单说，模型可能发现：

更有个性的回答更容易被偏好。
用轻松比喻解释技术问题，反馈可能更好。
某些词在特定语境里能增加“可爱”“机灵”“好玩”的感觉。
这些局部奖励会被训练过程放大。

最终结果就是，模型没有被明确要求频繁使用这些词，却在特定场景里形成了稳定倾向。

源头是 Nerdy 人格

顺着数据回溯，OpenAI 很快定位到一个具体分支：个性化定制里的 Nerdy 人格。

这个模式原本想把 AI 调成“书呆子导师”：热情、机智、推崇知识和批判性思维，同时不要太一本正经。站在人类角度，这个要求很清楚：要有极客精神，也要有幽默感。

但模型不会真正理解“幽默”的边界。它在强化学习反馈里学到了一条捷径：用 goblin 这类比喻，容易显得俏皮、聪明、像个书呆子，于是更容易拿到高分。

数据也能说明问题。从 GPT-5.2 到 GPT-5.4，默认人格下 goblin 出现频率变化只有 -3.2%；但在 Nerdy 人格下，这个数字暴涨了 3881.4%。更夸张的是，Nerdy 模式只占 ChatGPT 总对话量的 2.5%，却贡献了 66.7% 的 goblin 用量。

所以问题不在某个词本身，而在奖励信号把一种“看起来幽默”的表达方式推成了固定风格。

Codex 为什么更明显

Codex 场景放大了这个问题。因为代码任务经常涉及 bug、测试失败、环境差异和边界行为，模型很容易把这些问题拟人化。

当模型想用轻松方式解释“这个错误很奇怪”“这个测试不稳定”“这个行为像在捣乱”时，就会更容易调用这类词。久而久之，用户会感觉模型有固定口癖。

OpenAI 后来在 Codex 的系统提示中加入了抑制指令，明确要求模型避免这类表达。这个做法不是重新训练模型，而是在产品层面先把行为收住。

这件事说明什么

这个案例的重点，不在某个词本身，而在模型行为如何形成。

它至少说明了三点：

模型风格可能来自奖励信号，而不只是语料频率。
小的偏好在训练后期可能被放大成稳定人格特征。
产品里的系统提示可以缓解问题，但不等于从模型内部消除了倾向。

这也是大模型对齐里很麻烦的一类问题：用户喜欢“有趣”的回答，但过度追求有趣，可能让模型在严肃任务里显得轻浮、重复或自带口癖。

对使用者的启发

如果你在使用 AI 编程工具时发现模型有固定话术，不一定是提示词里写错了，也可能来自模型本身的训练偏好。

可以用几种方式缓解：

在系统提示或项目规则里写明语气要求。
要求模型避免拟人化、俚语化、过度调侃。
对技术任务指定“直接、简洁、工程化”的回答风格。
如果某个词反复出现，可以明确列入禁止表达。

这类约束不能改变模型内部权重，但能在实际产品使用中减少干扰。

小结

GPT-5.5 的 goblin 口癖不是一个孤立笑话。它展示了大模型训练中更深的问题：奖励信号会塑造风格，风格会迁移到产品场景，最后变成用户能感知到的人格特征。

对模型厂商来说，这类问题需要在训练、评测和产品提示三层同时处理。对普通用户来说，最实用的做法是把期望风格写清楚，让模型少一点表演，多一点稳定。

参考：

https://openai.com/index/where-the-goblins-came-from/

OpenAI 推出 Advanced Account Security：ChatGPT 和 Codex 账号多了一层高强度保护

Fri, 01 May 2026 06:15:29 +0800

OpenAI 在 2026 年 4 月 30 日推出了 Advanced Account Security，这是面向 ChatGPT 账号的可选高级安全设置。

它主要服务两类用户：一类是记者、民选官员、政治异议人士、研究人员等更容易遭遇定向攻击的人；另一类是希望给 ChatGPT 和 Codex 账号加上更强保护的安全敏感用户。

这项功能开启后，不只保护 ChatGPT，也会保护同一登录账号下访问的 Codex。

为什么 ChatGPT 账号需要更高安全等级

现在很多人会把 ChatGPT 用在越来越私密、越来越高风险的工作里。

一个 ChatGPT 账号里可能包含：

个人问题和长期对话
工作文档与项目上下文
已连接工具和工作流
Codex 里的代码与开发任务
企业、研究或安全相关材料

如果账号被接管，损失不只是聊天记录泄露。攻击者还可能访问连接的工具、查看敏感上下文，甚至干扰用户正在进行的工作。

所以 OpenAI 这次推出的不是一个普通登录选项，而是一组更严格的账号保护措施。

Advanced Account Security 包含哪些保护

OpenAI 把这项能力放在 ChatGPT 网页端账号的 Security 设置里，用户可以主动开启。

开启后，它会从几个方面提高账号安全性。

第一，登录方式更强。

Advanced Account Security 要求使用 passkeys 或实体安全密钥，并禁用基于密码的登录。这样做的目的，是让更抗钓鱼的登录方式成为默认选择。

第二，账号恢复更严格。

传统账号恢复经常依赖邮箱或短信。如果攻击者控制了用户的邮箱或手机号，就可能借此重置账号。为降低这个风险，Advanced Account Security 会禁用邮件和 SMS 恢复，改用更强的恢复方式，例如备用 passkeys、安全密钥和恢复密钥。

这里有一个重要代价：开启后，账号恢复会更依赖用户自己保管这些恢复方式。OpenAI 明确说明，已开启该功能的用户如果丢失恢复手段，OpenAI Support 无法协助恢复账号。

第三，会话时间更短，管理更清晰。

OpenAI 会缩短登录会话，以降低设备或活跃会话被盗用后的暴露窗口。用户也会收到登录提醒，并可以查看和管理当前登录的设备会话。

第四，自动排除训练。

对处理敏感信息的人来说，不让对话用于模型训练是一项重要隐私设置。开启 Advanced Account Security 后，这个偏好会自动生效：这些账号的对话不会用于训练 OpenAI 模型。

与 Yubico 合作推广实体安全密钥

OpenAI 还宣布与 Yubico 合作，给用户提供定制的安全密钥组合。

其中包括：

YubiKey C Nano：适合长期插在笔记本上，日常登录摩擦更小
YubiKey C NFC：适合作为备用，也方便在笔记本和移动设备之间使用

OpenAI 表示，用户也可以使用其他符合 FIDO 标准的实体安全密钥，或者使用软件 passkeys。

这说明 Advanced Account Security 并不绑定某一种硬件，而是围绕抗钓鱼认证方式设计。

Cyber 可信访问用户会被要求开启

OpenAI 还提到，针对 Trusted Access for Cyber 的个人成员，如果他们要访问更强、更宽松的网络安全模型，从 2026 年 6 月 1 日开始将被要求开启 Advanced Account Security。

组织用户可以用另一种方式满足要求：证明自己的单点登录流程已经采用抗钓鱼认证。

这个安排很合理。越强的模型能力越需要更强的账号保护，尤其是面向网络安全研究、漏洞分析和红队等场景时，账号本身就会成为高价值目标。

适合谁开启

这项功能不一定适合所有人。

如果只是普通聊天，且不想承担更严格账号恢复带来的复杂性，可以先观望。

但以下用户值得认真考虑：

经常在 ChatGPT 中处理敏感工作材料的人
使用 Codex 处理私有代码仓库的人
记者、公共事务人员、研究人员、企业高管等高风险用户
网络安全从业者
已经习惯使用 passkeys 或实体安全密钥的人
对账号被钓鱼、短信劫持或邮箱接管特别敏感的人

开启之前，最好先准备好备用 passkey、安全密钥和恢复密钥，并确认它们被妥善保存。否则，安全性提高的同时，账号恢复难度也会明显提高。

这对 AI 产品意味着什么

Advanced Account Security 不是一个模型能力更新，但它反映了 AI 产品正在进入更高风险的使用阶段。

当 ChatGPT 和 Codex 开始承载工作流、代码、文档、企业连接器和长期上下文时，账号就不再只是“登录聊天工具”的入口，而是 AI 工作环境的钥匙。

这类产品越像个人工作台，账号安全、恢复机制、会话管理和训练数据控制就越重要。

OpenAI 这次把 passkeys、实体安全密钥、恢复限制、会话管理和训练排除放到同一个设置里，方向是对的。它让高风险用户可以用一个明确入口，把账号保护提升到更适合敏感工作的级别。

小结

Advanced Account Security 可以理解为 ChatGPT 和 Codex 的高安全模式。

它通过更强登录、更严格恢复、更短会话、登录提醒和自动排除训练，降低账号被接管后的风险。代价是用户需要更认真地管理自己的恢复方式，因为开启后传统邮件和短信恢复不再可用，OpenAI Support 也无法替用户兜底。

如果你已经把 ChatGPT 或 Codex 用在重要工作里，尤其是涉及私有代码、敏感文档或高风险身份，这项功能值得关注。

参考链接：

Introducing Advanced Account Security - OpenAI

OpenAI 发布 GPT-5.5：更强的智能体编码、知识工作与科研能力

Fri, 24 Apr 2026 08:39:56 +0800

OpenAI 在 2026 年 4 月 23 日发布了 Introducing GPT-5.5。从官方页面看，这次更新的重点不是单纯“模型更聪明”，而是更强调模型能不能把复杂任务持续推进下去。

官方给 GPT-5.5 的定位，是一个更适合真实工作的模型。它不仅要回答问题，还要能写代码、调试、查资料、分析数据、生成文档和表格、操作软件，并在多个工具之间来回切换，直到任务完成。

1. GPT-5.5 主要强在哪里

这次发布页里反复出现的几个方向，可以概括为四类：

智能体编码
电脑操作与工具使用
知识工作
早期科研辅助

也就是说，GPT-5.5 的重点不是短问短答，而是更长链路的任务。比如一个工程问题不只是“这段代码怎么改”，而是要理解项目结构、定位失败原因、修改相关文件、补测试、验证结果，并尽量减少用户反复提示。

OpenAI 也特别强调，GPT-5.5 在 Codex 任务中更省 token。这个点很实际，因为编码智能体一旦开始读文件、跑命令、修 bug，token 消耗会非常快。如果模型能用更少的步骤完成同样任务，实际成本和等待时间都会下降。

2. 编码能力是这次最重要的展示方向

官方称 GPT-5.5 是目前最强的 agentic coding 模型。

几个公开指标里，比较值得注意的是：

Terminal-Bench 2.0：GPT-5.5 达到 82.7%
SWE-Bench Pro：GPT-5.5 达到 58.6%
OpenAI 内部的 Expert-SWE：GPT-5.5 也高于 GPT-5.4

这些测试的共同点是，它们更接近真实工程流程，而不是只考单个算法题。特别是 Terminal-Bench 这类任务，会涉及命令行操作、规划、试错、工具协调和多步骤验证。

对日常开发者来说，这里的意义很直接：模型是否能接住更大的任务，取决于它能不能长时间保持上下文、自己检查假设、知道什么时候该跑测试、知道改动会影响哪里。

GPT-5.5 在 Codex 里的价值，也主要体现在这些地方。它更像是可以接手一段工程任务的协作者，而不是只会补全代码片段的工具。

3. 知识工作开始变成重点场景

除了写代码，OpenAI 这次还把 GPT-5.5 放到了更广的办公场景里。

官方提到，GPT-5.5 在 Codex 中可以更好地生成文档、电子表格和演示文稿，也更适合处理运营研究、表格建模、业务材料整理这类任务。结合电脑操作能力之后，它的目标不是只给建议，而是能直接参与“找资料、理解内容、调用工具、检查输出、整理成结果”这一整条流程。

发布页里还提到 OpenAI 内部已经在多部门使用 Codex，包括软件工程、财务、传播、市场、数据科学和产品管理等。这里真正值得关注的不是某个单点案例，而是 OpenAI 正在把 Codex 从开发工具扩展为通用工作工具。

在 ChatGPT 里，GPT-5.5 Thinking 面向 Plus、Pro、Business 和 Enterprise 用户；GPT-5.5 Pro 则面向更难问题和更高准确率需求，提供给 Pro、Business 和 Enterprise 用户。

4. 科研能力不只是“答题更强”

GPT-5.5 的科研展示也很重。

官方提到它在遗传学、定量生物学、生物信息学、数学证明等方向都有改进。这里的重点不是模型能不能背出一个知识点，而是能不能处理更接近真实研究的问题：读数据、发现异常、提出分析方式、解释结果，并根据中间结果继续推进。

发布页里提到的 GeneBench 和 BixBench，都更偏多阶段科学分析任务。OpenAI 还提到，一个内部版本的 GPT-5.5 借助自定义工具链，帮助发现了关于 Ramsey numbers 的新证明，并用 Lean 做了验证。

这类案例还不能简单理解为“AI 已经能独立做科研”，但它说明模型正在从问答工具往研究协作者靠近。尤其是在代码、数据、论文、实验想法混在一起的场景里，GPT-5.5 的长链路推理和工具使用能力会更重要。

5. 推理效率：更强但没有明显变慢

一个容易被忽略的点是，OpenAI 说 GPT-5.5 在真实服务中的 per-token latency 与 GPT-5.4 相当。

通常更大的模型、更强的模型会带来更高延迟。OpenAI 这次强调，它们通过推理系统优化，让 GPT-5.5 在智能提升的同时保持速度。发布页里还提到，Codex 分析生产流量模式并编写负载分配相关启发式算法，使 token 生成速度提升超过 20%。

这个细节很有意思：模型不仅被基础设施服务，也反过来帮助改进服务它的基础设施。

6. 安全策略会更严格，尤其是网络安全方向

GPT-5.5 的网络安全能力更强，所以 OpenAI 同时加强了安全限制。

官方说明中提到，GPT-5.5 在网络安全能力上比 GPT-5.4 有提升，因此会部署更严格的分类器，尤其针对高风险活动、敏感网络安全请求和重复滥用行为。

这意味着一部分用户在使用网络安全相关能力时，可能会遇到更多拒答或限制。OpenAI 也提供了 Trusted Access for Cyber，用于让经过验证的防御性用户获得更少不必要阻碍。

对普通开发者来说，可以简单理解为：合法的安全加固、漏洞修复、代码审计会继续被支持，但高风险攻击链路会被更严格地控制。

7. 可用性与 API 价格

根据 OpenAI 发布页，GPT-5.5 的可用性如下：

ChatGPT：GPT-5.5 Thinking 面向 Plus、Pro、Business、Enterprise 用户
ChatGPT：GPT-5.5 Pro 面向 Pro、Business、Enterprise 用户
Codex：GPT-5.5 面向 Plus、Pro、Business、Enterprise、Edu、Go 计划
Codex：上下文窗口为 400K
Codex Fast mode：生成速度约 1.5x，成本为 2.5x

API 方面，OpenAI 表示 gpt-5.5 和 gpt-5.5-pro 会很快开放。

官方给出的 API 价格是：

gpt-5.5：输入 5 美元 / 1M tokens，输出 30 美元 / 1M tokens
gpt-5.5-pro：输入 30 美元 / 1M tokens，输出 180 美元 / 1M tokens
gpt-5.5 API 上下文窗口为 1M
Batch 和 Flex 为标准 API 价格的一半
Priority processing 为标准价格的 2.5x

这个价格明显高于很多日常模型，所以它更适合高价值任务：复杂工程改造、长文档分析、自动化办公、科研辅助、重要业务流程，而不是普通闲聊。

8. 怎么看这次发布

如果只看一句话，GPT-5.5 的重点是：OpenAI 正在把模型从“回答问题”继续推向“完成工作”。

它最值得关注的地方，不只是 benchmark 分数提升，而是几种能力开始汇合：

更强的长任务保持能力
更稳定的工具使用
更好的工程上下文理解
更适合文档、表格、研究和业务流程
更长上下文和更高 token 效率
更严格的高风险能力控制

对开发者来说，最值得试的是 Codex 里的复杂工程任务。对企业用户来说，更值得关注的是它能不能把一部分跨工具、跨文档、跨流程的工作变成可交付结果。

GPT-5.5 不是一次只面向聊天体验的小更新，而更像是 OpenAI 在继续推进“AI 作为工作执行层”的方向。

GPT Image 2 正式发布：从能生成到能商用的跨越

Wed, 22 Apr 2026 20:08:22 +0800

OpenAI 的下一代图像生成模型 GPT Image 2 已经正式面向 ChatGPT 用户开放。结合社区在泄露测试阶段的反馈，以及公开可见的实际效果，这一代模型的变化不像一次常规迭代，更像是 AI 生图从“能看”走向“能用”的一次明显推进。

如果说上一阶段的图像模型，更多还是用来做灵感图、概念图和试玩性质的生成，那么 GPT Image 2 最突出的地方，是它开始接近生产级工具。无论是可读文字、界面截图、营销海报，还是更逼真的商业摄影风格图片，它都比过去更接近“直接拿去用”的状态。

一、核心升级：五个最值得注意的点

1. 文字渲染终于进入可用区间

AI 生图过去最难啃的一块，就是文字。乱码、拼写错误、长文本崩坏、字体变形，这些几乎是所有模型都会碰到的问题。

GPT Image 2 在这方面的提升非常明显。它不仅能处理更清晰的英文和中文文字，还能应对更复杂的排版、更长的段落，以及一定程度上的多语言混排。这意味着很多原本必须靠后期修字的场景，现在可以直接在生成阶段完成。

比较典型的用法包括：

海报
社交媒体封面
带标题与说明文字的宣传页
PPT 配图
带真实文案和界面元素的 App 截图

对实际工作流来说，这一步很重要。因为只要文字能稳定可读，图像生成就不再只是“出一张背景图”，而开始具备承接营销物料和产品展示图的能力。

2. 照片级真实感明显提升

从社区并排对比来看，GPT Image 2 的整体画质更锐利，材质纹理更细，光线一致性也更强。过去最容易露出 AI 痕迹的人脸、手部、边缘细节，这一代都明显更稳定。

更准确地说，它不是完全没有破绽，而是“AI 味”显著下降。很多图第一次看上去，已经会让人直接把它当作真实照片、商业摄影样片或者游戏截图。

这也是为什么很多人对它的第一反应不再是“画得不错”，而是“这张图已经很像真的了”。

3. 世界知识整合能力更强

这是一个不那么显眼，但非常实用的升级。

GPT Image 2 给人的感觉，不只是会拼图块、凑风格，而是更像“知道自己在画什么”。原文里提到的几个方向很有代表性：

手表表盘时间逻辑更合理
品牌细节和角色特征还原更准确
Minecraft 这类游戏截图或软件界面的逻辑结构更像真的

这意味着它在处理现实物体、数字界面、游戏画面这类需要常识和结构感的内容时，成功率更高。对用户来说，这种提升往往比单纯的“更高清”更有价值。

4. UI 与截图生成能力很强

从泄露期到正式上线，GPT Image 2 最出圈的一个方向，就是生成软件界面、网页截图和 App mockup。

这类任务过去很难做，因为它们同时要求：

文字清楚
布局规整
按钮、卡片、导航条等元素对齐
配色和层级像真实产品

而这次模型在这些方面的表现已经相当成熟。对于产品经理、独立开发者和设计师来说，这意味着可以更快做出高保真原型图，用于提案、演示甚至用户测试。

5. 局部编辑更接近实用工作流

按原文整理的信息，GPT Image 2 支持更精准的局部编辑能力，也就是只修改画面中的特定区域，而不是每次整张图推倒重来。

这类能力对创意工作流非常关键。因为实际设计场景里，很多时候不是“重做一张”，而是：

改一个按钮
换一段文字
调整某个物体的位置
修一块背景
替换局部元素

如果局部编辑足够稳定，AI 生图的价值就不只是第一次出图，而是能真正参与到反复迭代中。

二、怎么使用 GPT Image 2

在 ChatGPT 里使用

目前 GPT Image 2 已经集成在 ChatGPT 里，普通用户可以直接通过图像生成功能调用。

常见操作流程是：

打开 ChatGPT 网页版或 App
在输入框点击 +
选择“创建图片”
输入提示词并提交
系统调用 GPT Image 2 生成结果

原文还提到，不同订阅等级对应的可用额度不同，免费用户和 Plus / Pro 用户在生成次数上会有差别。具体额度规则建议以当时 ChatGPT 产品内显示为准，因为这类限制后续可能调整。

在 API 中使用

如果是开发者场景，也可以通过 OpenAI API 调用图像生成模型。原文里提到的模型名写法是 gpt-image-2，但实际接入时仍建议以官方文档中的最新名称和参数为准。

文中列出的几个常见分辨率如下：

分辨率	适用场景
`1024×1024`	通用方图、头像、社交媒体图片
`1536×1024`	横版封面、幻灯片、宽屏壁纸
`1024×1536`	竖版海报、手机壁纸、故事配图
`2048×2048`	高清印刷、大幅展示、精细插画

三、几个代表性使用场景

原文列了不少案例，这里整理出最有代表性的几类。

1. App 界面截图

这一类提示词非常适合产品原型、设计演示、需求讨论。

示例特点通常是：

指定平台风格，例如 iOS
写清页面结构
列出核心数据卡片
指定底部导航栏
说明配色与字体风格
强调文字必须清晰、元素要对齐

这种写法的重点不是“画面好看”，而是尽量减少模型发挥空间，让结果更像一个真的界面。

2. 电商产品图

像香水、耳机、手表、化妆品这类商品图，很适合 GPT Image 2 发挥。

因为它现在对以下内容的处理已经更稳定：

玻璃、金属、液体等材质质感
柔和阴影和反射
商业摄影常见的布光逻辑
简洁背景下的高端展示感
少量品牌文字

如果生成结果稳定，很多电商详情图、营销页主图、社交媒体产品视觉，都能把试错成本压低很多。

3. 文字海报

海报是最能体现这一代文字能力的场景之一。

原文给出的方向很典型：在一个黄昏城市剪影背景上，明确写出主标题、时间地点、艺人名单，并要求：

文字清晰可读
无拼写错误
中英文混排稳定
风格统一

这类任务过去通常要先生成背景图，再人工补字。现在如果模型能一次完成大部分工作，它的实用价值就会大很多。

4. 游戏概念图和“假截图”

这是 GPT Image 2 在社交媒体上最容易传播的一类内容。

比如第三人称游戏截图、霓虹街道、雨后积水反射、景深、颗粒感、PS5 实机风格，这种提示词组合出来的结果，很容易让人第一眼误判为游戏泄露画面。

从传播角度看，这类图很吸睛；从风险角度看，也说明以假乱真的门槛已经明显下降，用户对图片真实性的判断需要更谨慎。

5. 拟真人像与创意肖像

人像一直是 AI 图像能力最直观的测试题。

原文里的示例聚焦在自然光、咖啡馆、逆光边缘、针织衫、暖色背景虚化这类细节组合。它们背后的重点其实是：

皮肤纹理自然
发丝细节完整
手部结构不崩
光线逻辑合理
整体氛围不带明显 AI 痕迹

如果这几点能稳定做到，人像生成才算真正进入可用阶段。

6. 美食摄影

原文还给了一个非常长的英文提示词，用来生成高端餐厅风格的豚骨拉面照片。这个例子说明了一个很现实的趋势：当模型足够强时，提示词可以写得像摄影脚本。

这种写法会细到：

菜品构成
餐具材质
汤底光泽
叉烧的脂肪层和焦边
溏心蛋状态
背景景深和散景
光源方向
镜头型号与光圈

对于餐饮品牌、菜单设计、外卖平台主图和社交媒体内容，这种生成能力已经非常接近商业摄影替代方案。

7. 教育插图

另一个很有代表性的方向，是带标注的科学教育图。

原文示例是一张植物细胞剖面图，要求模型同时处理：

结构正确
标签位置准确
引导线清晰
字体统一
配色有层次
整体适合教材或课件使用

这说明 GPT Image 2 的价值不只是做“好看”的图，还包括做“信息型”的图。

四、对普通用户最实际的意义

GPT Image 2 真正值得关注的地方，不只是它又把画质往前推了一步，而是它把 AI 生图从娱乐型、试玩型工具，进一步推向了可商用、可交付的生产工具。

具体体现在几个层面：

文字终于开始靠谱
界面和海报更像真实物料
商业摄影风格图更可用
教育类、信息类图片也能做
局部编辑让它更适合迭代

当然，这并不代表它已经完全替代设计师、摄影师或插画师。真正的商业项目仍然需要审美判断、品牌控制、版权意识和人工复核。

但至少从这次更新能看出来，AI 图像生成的竞争点已经不只是“能不能出图”，而是“能不能更稳定地进入真实工作流”。

OpenAI 发布 ChatGPT Images 2.0：图像生成开始走向可直接交付

Wed, 22 Apr 2026 14:19:53 +0800

OpenAI 在 2026 年 4 月 21 日发布了 Introducing ChatGPT Images 2.0。从官方页面来看，这次更新想强调的并不只是“图片更好看了”，而是图像生成正在往“更可控、可排版、可直接交付”的方向走。

如果只看这篇发布页，它更像一组高密度能力展示，而不是传统意义上的技术说明。页面几乎没有展开模型结构、训练细节或基准测试，而是用大量示例图直接回答一个问题：现在的 ChatGPT 图像生成，能不能把过去还要靠设计师反复修图、补字、调版式的活，进一步前移到生成阶段。

01 这次更新最明显的信号

官方页面里最醒目的几个关键词，其实已经把重点说得很清楚：

Greater precision and control
Stronger across languages
Stylistic sophistication and realism

这三点放在一起看，含义很明确。

第一，不再只强调“想象力”，而是强调控制力。页面里出现了大量海报、杂志页、宣传页、信息图、角色设定页、分镜漫画、印刷书签这类示例。它们的共同点不是单张视觉冲击力，而是需要同时处理文字、层级、留白、构图、风格统一和输出比例。这说明 OpenAI 在刻意把产品定位从“生成一张图”往“生成一份可以拿去用的视觉成品”推进。

第二，多语言文字能力被单独拎出来做展示。页面里不仅有多语种海报、书籍封面、韩文旅宿宣传页、日文漫画，还有专门强调 typography 的示例。这很关键，因为过去图像模型最容易翻车的地方之一，就是一旦涉及长文本、复杂版式或非英语文字，稳定性会明显下降。现在 OpenAI 把它放到发布页核心位置，本身就是在传递一个信号：文字渲染和跨语言排版，已经成为它们认为值得正面展示的能力。

第三，风格覆盖面被拉得很宽。官方示例同时覆盖了写实摄影、复古拼贴、Bauhaus 海报、时尚大片、黑白纪实、儿童绘本、日漫、青年漫画、教育信息图、产品网格图、角色设定页等多种形式。这里想表达的不是“模型能模仿很多画风”这么简单，而是它正在尝试从单一美术风格输出，走向更完整的视觉任务适配。

02 为什么说它在走向“可直接交付”

从这页内容来看，ChatGPT Images 2.0 更像一个“图像制作工作台”能力升级，而不只是更强的文生图模型。

过去很多模型虽然也能生成漂亮图片，但一旦用户需求变成下面这些任务，体验就会迅速下降：

做一张带完整标题、副标题和说明文字的海报
做一页信息密度较高的杂志或宣传页
做带连续角色和连续叙事的漫画页
做需要固定比例、特定版式和明确品牌感的营销物料
做包含多语言文字的正式视觉内容

而 OpenAI 这次展示的例子，几乎都在正面回应这些老问题。

例如页面里有教育信息图、设计趋势海报、书签印刷稿、咖啡店开业海报、旅游宣传页、产品周边展示图、论文海报重制图。这类内容有一个共同特征：它们不是“给人看一眼觉得不错”就结束，而是更接近真实工作流里的半成品甚至成品。

换句话说，这次更新真正重要的地方，可能不是单张图质量又提升了多少，而是模型开始更像一套可用于内容生产、品牌物料、教育传播和轻量设计工作的生成系统。

03 这对 ChatGPT 产品定位意味着什么

从发布页组织方式也能看出一些产品层面的变化。

OpenAI 没有把 ChatGPT Images 2.0 包装成一个只服务创意圈的图像模型，而是不断用“研究、推理、资料转化、版面整理、知识表达、营销输出”这些场景去展示它。页面里甚至还有把数学证明、设计趋势、历史笔记、学术论文可视化的例子。

这意味着图像生成在 ChatGPT 里的角色，已经不只是“给聊天配图”或“生成一张插画”，而是在向更通用的表达层靠拢。它想做的是：当用户已经在 ChatGPT 里思考、查资料、整理内容、写文案之后，最后一步连视觉产出也一起完成。

如果这个方向继续推进，图像功能的竞争点就不再只是审美和写实程度，而会越来越依赖下面这些能力：

是否能稳定处理复杂文字
是否能维持跨页面或多面板的一致性
是否能生成更接近真实工作物料的版式
是否能在研究、写作、营销、教学这些任务里自然接上前面的上下文

04 这篇发布页没有说什么

当然，发布页的写法也决定了它更适合“看方向”，不太适合“看细节”。

截至官方页面 2026 年 4 月 21 日的内容，它主要展示的是结果，而不是方法。页面没有详细展开：

模型与上一代相比的量化提升
文字准确率或多语言渲染的明确指标
复杂版式任务的失败边界
API、价格、调用方式或企业侧接入细节
安全策略和生成限制的具体更新

所以更准确地说，这篇文章传递的是产品信号，而不是完整技术规格。

05 简单结论

如果只用一句话概括 ChatGPT Images 2.0，这次更新最值得注意的不是“更会画”，而是“更会做成品”。

OpenAI 显然希望把图像生成从灵感型工具，往可执行、可排版、可沟通、可交付的生产工具推进。文字控制、多语言、版式、风格跨度、长页面内容组织，这些原本最容易暴露短板的地方，现在反而成了它主动展示的卖点。

这不代表图像生成已经完全解决了设计工作里的所有问题，但至少从这次发布页可以看出，竞争重心正在变化。未来谁更强，可能不只是看谁能出一张更惊艳的图，而是看谁能更稳定地做出一份真的能拿去用的视觉内容。

Codex 额度怎么算：5 小时限额、周限额和 Credit 消耗

Wed, 15 Apr 2026 22:50:00 +0800

很多人第一次看 Codex 额度时，会以为 5 小时限额 是一个短期余额池，只有它用完之后才开始扣 周限额。

实际不是这样。Codex 更像是同时检查多个额度窗口：短窗口防止短时间爆量，周窗口限制一周总量。一次 Codex 使用通常会同时计入这两个窗口。

所以你看到：

1
2

5 小时额度还剩很多
但 weekly 额度已经下降

通常是正常现象。

01 先记住结论

Codex 额度可以先按下面三句话理解：

5 小时限额 和 周限额 是同时生效，不是先后扣除。
周限额用完后，即使 5 小时额度还有，通常也不能继续用同一个订阅额度池。
Codex 不是简单按消息条数计费，而是和模型、tokens、任务复杂度、上下文、执行位置有关。

用伪代码表示就是：

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && 没有触发其它产品策略限制

5 小时窗口重置，只恢复 5 小时额度；不会恢复 weekly 额度。weekly 额度要等自己的 reset，或者在支持的计划里购买额外 credits。

02 为什么会同时扣两个窗口

可以把 Codex 的额度想成两个闸门：

窗口	作用
5 小时窗口	防止短时间高频使用
周窗口	控制一周总使用量

每次 Codex 任务都会产生一次实际消耗。这个消耗会反映到当前相关的 rate limit 窗口里。

因此不是：

1
2
3

先扣 5 小时额度
5 小时额度用完后
再扣周额度

而更像是：

1
2
3

一次 Codex 请求
=> 计入 5 小时窗口
=> 同时计入周窗口

这就是“5 小时额度没用完，但 weekly 也在下降”的核心原因。

03 当前更应该看 token-based credits

OpenAI 没有公开一个用户可以完全复算的 Codex 扣费公式。官方公开的是 rate card、影响因素和不同模型的 credit 单价。

截至 2026-04-15，Codex rate card 的主口径已经是 token-based credits。也就是根据输入 tokens、缓存输入 tokens、输出 tokens 折算 credits。

官方给出的示例价格如下：

模型	输入 / 1M tokens	缓存输入 / 1M tokens	输出 / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

所以一个粗略估算公式是：

本次消耗
≈ 输入 tokens / 1,000,000 × 模型输入单价
+ 缓存输入 tokens / 1,000,000 × 模型缓存输入单价
+ 输出 tokens / 1,000,000 × 模型输出单价

这不是精确账单公式，但足够解释趋势：输出很贵，长上下文很贵，高能力模型更贵。官方还说明 Fast mode 会消耗 2 倍 credits，Code review 使用 GPT-5.3-Codex 的价格。

04 不要再只看“消息条数”

同样发 10 次 Codex，消耗可能完全不同。

轻量任务通常更省：

改一个小函数
解释一段短代码
写一小段文案
在明确文件里做局部修改

重任务会更贵：

扫描大型代码库
长时间运行 agent
多轮读取、编辑、测试、修复
生成大量代码或长报告
使用 cloud task
开启 fast mode

因此，消息数量 只能作为很粗的感觉，不能用来判断真实消耗。

05 local task 和 cloud task 的差别

Codex 里很容易拉开消耗差距的是执行位置。

local task 更像是在你的本地工作区里读文件、改代码、跑命令。cloud task 则把任务交给云端环境托管执行，适合更长、更自动化的流程。

从额度角度看，cloud task 往往更贵。原因也很直接：

需要云端执行环境
任务通常更长
工具调用更多
上下文更大
自动化链路更完整

如果只是普通代码编辑、文章整理、局部修复，优先 local task 会更省。cloud task 更适合确实需要云端托管的任务。

06 为什么 weekly 掉得特别快

如果你觉得“5 小时额度没怎么动，但 weekly 掉很多”，常见原因有这些：

使用了 cloud task。
使用了更贵的模型。
开启了 fast mode。
上下文很大，Codex 读了很多文件或保留了很长对话。
输出很长，比如大量代码、长报告、长日志分析。
任务链很长，比如搜索、编辑、测试、修复、再测试。
自己的额度脚本把窗口标签解析错了。

如果你是用脚本读 /backend-api/wham/usage 之类的字段，不要只看加工后的 five_hour%、weekly%。最好先看 raw JSON 里的：

limit_window_seconds
percent_left
reset_at
bucket / feature 名称

常见窗口长度可以这样判断：

limit_window_seconds = 18000
=> 约 5 小时窗口

limit_window_seconds = 604800
=> 约 7 天窗口

如果脚本把两个窗口标反，就会误判额度变化。

07 更省额度的使用方式

想让 weekly 撑得久一点，可以这样用：

把大任务拆成小任务。先处理一个文件、一个 bug、一个功能点。
能 local 就 local，谨慎使用 cloud task。
明确告诉 Codex 相关路径，减少无关扫描。
避免一次塞入巨大日志、长文件、无关上下文。
轻量任务可以用更便宜的 mini 模型。
长任务前先让 Codex 出计划，再进入执行。
不需要长报告时，明确要求“简短回答”。

最实用的记忆方式是：

是否能继续用
= 短窗口还有额度
&& 周窗口还有额度

消耗快不快
= 模型价格
× tokens
× 输出长度
× 任务复杂度
× 执行位置

这个模型不能精确对账，但足够解释大多数 Codex 额度现象。

如何在 VS Code 中使用 Codex（从安装到高效实战）

Fri, 20 Mar 2026 00:00:00 +0000

Codex 可以直接在 VS Code 侧边栏中协助你写代码、改 Bug、解释项目和执行命令。

1. 准备工作

开始前请确认：

VS Code 已更新到较新的稳定版本。
你可以正常访问OpenAi网站
项目代码已在本地打开（建议使用 Git 仓库）。

2. 安装扩展

打开 VS Code 的扩展市场（Extensions）。
搜索并安装：Codex - Codex - OpenAI's coding agent。
安装完成后，按提示完成登录授权。

3. 打开 Codex 侧边栏

你可以通过任一方式打开：

在编辑器右上角点击 Open Codex Sidebar。
使用命令面板（Ctrl + Shift + P）搜索 Codex 并打开。

打开后，Codex 会读取当前工作区上下文，进入可对话状态。

4. 常见使用方式

4.1 让它解释代码

示例提示词：

`1`	`请解释这个文件的核心逻辑，并指出最可能出错的 3 个地方。`

适合你刚接手旧项目时快速建立全局理解。

4.2 让它实现功能

示例提示词：

1
2

在现有 API 里新增一个 /healthz 健康检查接口，
要求返回版本号和数据库连接状态，并补上基础测试。

建议把“输入约束”和“验收标准”一起写清楚，生成结果会稳定很多。

4.3 让它修复问题

示例提示词：

1
2

这个接口在并发下偶发 500，请先定位根因，再给出最小改动修复方案，
最后列出回归测试点。

先“定位”再“修复”，能减少误改和过度重构。

5. 高质量提示词模板

你可以直接复用下面这个结构：

背景：这是一个 <技术栈> 项目，当前目标是 <目标>
约束：不改动 <模块/接口>，兼容 <版本/平台>
输出：
1) 修改文件列表
2) 关键代码说明
3) 验证步骤
4) 风险与回滚方案

这个模板对“多人协作 + 大项目”非常有帮助。

6. 常见问题

6.1 关于免费额度

在对话框输入 ‘' 然后选择状态会出现额度重置时间等相关信息

6.2 改动不符合预期

修改完成后查看审核按钮，查看修改细节，不满意选择撤销按钮，可撤销修改。在后面的步骤中可以把需求拆小，分成多个步骤分别执行。使用git等代码管理工具，保持小步提交（small commits），方便回滚。