ChatGPT on KnightLi的博客

Google I/O 之后，GPT 和 Gemini 订阅怎么选？普通用户与开发者对比

Thu, 21 May 2026 08:33:14 +0800

Google I/O 2026 之后，很多人的 AI 订阅选择变复杂了。

以前问题比较简单：写作、问答、编程、文件分析，大多数人优先看 ChatGPT；如果深度使用 Google 搜索、Android、Gmail、Docs、YouTube，再考虑 Gemini。现在不一样了。Google 在 I/O 上把 Gemini 3.5 Flash、Gemini Omni、Antigravity 2.0、Gemini API Managed Agents、Google AI Studio 和 AI Ultra 订阅一起推出来，Gemini 生态开始从“可选项”变成“强竞争主线”。

这篇文章不做抽象模型跑分，而是回答一个实际问题：普通用户、开发者、内容创作者和企业用户，到底该订阅 GPT / ChatGPT，还是 Gemini / Google AI？

注意：AI 订阅价格、额度、地区和模型可用性变化很快。本文写作时间是 2026 年 5 月 21 日，正式订阅前应以 OpenAI 与 Google 当前页面为准。

先说结论

如果你只想选一个主力订阅，可以按这个逻辑：

日常写作、问答、文件分析、泛办公、中文英文混合使用：优先 ChatGPT Plus。
高频编程、需要 Codex、复杂推理、项目级代码任务：优先 ChatGPT Plus / Pro，再按额度决定是否升级。
深度使用 Google 生态、Gmail、Docs、Drive、Android、Search：优先 Gemini / Google AI Pro。
重点做视频、AI 影像、Google Flow、YouTube Shorts、Gemini Omni：优先 Google AI Pro / Ultra。
需要 Antigravity、Gemini API Managed Agents、AI Studio 到 Android 的工作流：重点看 Google AI Pro / Ultra。
企业团队：不要只看个人订阅，重点看 Business / Enterprise、Workspace、权限、审计和数据边界。
预算有限：一个主力付费订阅 + 另一个平台免费层或按量 API，通常比同时订两个高阶套餐更划算。

一句话：GPT 更像通用生产力和代码助手主力；Gemini 在 Google I/O 之后更像 Google 生态里的系统级 AI 套件。

Google I/O 之后，Gemini 发生了什么变化

Google I/O 2026 让 Gemini 的价值不再只取决于 Gemini App 本身。

几个关键变化：

Gemini 3.5 Flash：Google 把它定位为从 prompt 到 action 的高速模型，面向真实 Agent 工作流。
Gemini Omni：从任意输入创作内容，当前重点从视频开始，支持多模态创作和自然语言多轮编辑。
Google Antigravity 2.0：Agent-first development platform，面向开发者的多 Agent 编排与编程平台。
Gemini API Managed Agents：通过 API 创建可推理、可用工具、可执行代码的托管 Agent。
Google AI Studio：从 prompt playground 走向移动端、Android 原生应用生成和 Antigravity 项目导出。
Google AI Ultra：I/O 后新增 $100/月档位，并面向开发者、技术负责人、知识工作者和高级创作者。

更重要的是，Google 把 Gemini App 的使用额度从传统每日 prompt 限制，转向 compute-used 模型。复杂视频、代码和长上下文任务会消耗更多额度，简单文本任务消耗更少；额度每 5 小时刷新，直到达到周限制。

这说明 Google 正在把 Gemini 订阅做成“模型 + 应用 + 创作 + 开发工具 + Google 生态”的打包入口。

ChatGPT / GPT 订阅现在适合谁

ChatGPT 的优势依然很强，尤其适合把 AI 当作日常工作主力的人。

根据 OpenAI 当前价格页和帮助文档，ChatGPT Free 可以使用 GPT-5.5 Instant 等基础能力；Plus 提供 GPT-5.5 Thinking、更多消息和上传额度、更强图像生成、deep research、agent mode、项目、任务、自定义 GPT 和扩展 Codex 使用；Pro 则提供更高额度、GPT-5.5 Pro、更高 Codex 使用量、最大 deep research 和 agent mode。

更适合 ChatGPT 的场景：

写作、总结、翻译、改稿。
复杂问答和结构化分析。
文件上传、表格分析、研究报告。
编程问答、代码审查、重构建议。
使用 Codex 做代码库任务。
多语言内容生产。
对模型质量和回答稳定性要求高，但不强依赖 Google 产品。

如果你是普通用户，ChatGPT Plus 仍然是最稳的主力订阅。它覆盖面广，学习成本低，中文和英文任务都比较均衡。

如果你是开发者，ChatGPT 的关键不只是聊天，而是 Codex。OpenAI 帮助文档说明，Codex 可随符合条件的 ChatGPT 计划使用，额度随计划不同而变化。也就是说，如果你大量使用 Codex 做代码修改、PR、重构、测试修复，订阅选择要把 Codex 额度一起算进去。

Gemini / Google AI 订阅现在适合谁

Gemini 的优势在 Google I/O 之后更清晰：它和 Google 生态绑定更深。

Google AI 订阅现在不只是 Gemini App 里的模型额度，还包括 Gemini Omni、Google Flow、Antigravity、AI Studio、部分 YouTube Premium / Lite 权益、Workspace / Android / Search 生态能力等。Google 官方还把 AI Ultra 扩成 $100 与更高阶档位，强调开发者、技术负责人、知识工作者和高级创作者。

更适合 Gemini 的场景：

你深度使用 Gmail、Docs、Drive、Sheets、Slides、Android。
你想把 AI 放进 Google Search、YouTube、Workspace 生态。
你关注 Gemini Omni、Google Flow、视频生成和视频编辑。
你想试 Antigravity、Gemini API Managed Agents、AI Studio mobile。
你需要超长上下文文件理解。
你做 Google 生态应用、Android 原生应用、Workspace 自动化。

Google 官方帮助页显示，Gemini Apps 的上下文窗口会随订阅提高：无 AI plan 为 32K，AI Plus 为 128K，AI Pro 和 AI Ultra 为 1 million。AI Pro / Ultra 也会提供更高使用限制、更多特性和部分早期功能。

如果你的工作环境已经在 Google 生态里，Gemini 的价值会被放大。否则，单独把 Gemini 当作“另一个聊天机器人”来订阅，性价比就不一定比 ChatGPT 更稳。

普通用户怎么选

普通用户最容易踩的坑，是因为新模型发布就同时订多个平台。

更理性的选法是先看主场景。

如果你主要做这些事：

写文章。
查资料。
做总结。
读 PDF。
写邮件。
改简历。
学习语言。
日常问答。

优先选 ChatGPT Plus。它的通用性更好，任务边界更清楚，不需要你深度绑定某个生态。

如果你主要做这些事：

Gmail / Docs / Drive / YouTube / Android 高频使用。
希望 AI 直接进入 Google 生态。
想体验 Gemini App、Daily Brief、Google Search AI、YouTube 内容问答。
需要长上下文读取 Google 文档。

优先选 Google AI Pro。

如果你只是轻量用户，两个平台都先用免费层，等明确遇到限制再付费。不要为了“可能用到”而订阅高阶套餐。

开发者怎么选

开发者要分两类。

第一类是以代码问答、修 bug、写脚本、读代码库为主。优先看 ChatGPT Plus / Pro + Codex。

理由是：

Codex 和 ChatGPT 账号打通。
ChatGPT 对代码解释、重构、测试、错误分析比较稳。
Plus 已经覆盖很多日常开发任务。
Pro 更适合高频、长时间、复杂代码库任务。

第二类是面向 Google 生态、Agent 平台、Android、Workspace 或 Gemini API 开发。优先看 Google AI Pro / Ultra。

理由是：

Gemini 3.5 Flash 是 Google I/O 后 Agent 工作流重点模型。
Antigravity 2.0 是 Google 的 Agent-first 开发平台。
Managed Agents 能通过 API 创建带工具和隔离 Linux 环境的 Agent。
AI Studio 可以和 Android、Workspace、Antigravity 更自然衔接。

如果你是全栈开发者，最务实的组合通常是：

ChatGPT Plus 作为日常代码与文档主力。
Gemini 免费层或 AI Pro 用于 Google 生态、长上下文和视频/Agent 新能力。
API 按量使用，不要把个人订阅误当生产 API 预算。

内容创作者怎么选

内容创作者的选择取决于你做什么内容。

如果你主要做：

文案。
标题。
脚本。
文章。
图文内容。
资料整理。
多语言改写。

ChatGPT Plus 依然很稳。

如果你主要做：

视频生成。
短视频创意。
AI 影像。
YouTube Shorts。
Google Flow 工作流。
多模态素材整合。

Gemini / Google AI Pro 或 Ultra 更值得关注。I/O 之后，Gemini Omni 和 Google Flow 是 Google 在创作场景里的核心牌。

如果预算有限，可以先订一个文本主力，再用另一个平台的免费层或短期订阅测试视频能力。视频模型的额度、排队、时长、分辨率和地区限制变化很快，不建议一开始就按长期生产服务规划。

企业和团队怎么选

企业不要按个人用户思路选。

企业真正要看的不是“哪个模型这周更强”，而是：

数据是否用于训练。
是否有 SSO、MFA、RBAC。
是否有审计日志。
是否支持内部知识连接。
是否能控制插件、连接器和 Agent 权限。
是否符合组织的合规要求。
是否能和现有办公套件打通。

如果企业已经重度使用 Google Workspace，Gemini 企业方案自然更值得评估。如果团队已经围绕 ChatGPT、Codex、OpenAI API 和内部工具链搭建流程，OpenAI Business / Enterprise 更自然。

对工程团队来说，还要单独评估 Codex、Antigravity、Gemini API Managed Agents、MCP、CI/CD、代码权限、仓库访问和审计。

什么时候需要 Pro / Ultra

很多人其实不需要高阶档位。

你需要 ChatGPT Pro 的典型信号：

每天长时间使用 ChatGPT。
Plus 额度经常不够。
高频使用 Codex。
经常跑 deep research、agent mode、复杂推理。
需要 GPT-5.5 Pro 这类更高阶模型。

你需要 Google AI Ultra 的典型信号：

高频使用 Gemini、Flow、Antigravity。
需要更高 Gemini / Antigravity 使用额度。
做视频创作、AI 影像、长上下文研究。
深度依赖 Google 生态和新功能优先体验。
需要 Gemini Spark、Project Genie 或更高级订阅权益。

如果你只是每天问几次问题、偶尔写文章或改代码，Plus / Pro、AI Pro / Ultra 这类高阶档位可能都不是刚需。

最省钱的订阅策略

更推荐这种组合：

先选一个主力付费订阅。
另一个平台先用免费层。
真正需要 API 时再按量付费。
视频、Agent、深度研究类高消耗功能按月开关，不要全年盲订。
每月复盘一次：本月有没有真的用满额度？

几个常见组合：

普通办公：ChatGPT Plus + Gemini 免费层。
Google 生态用户：Google AI Pro + ChatGPT 免费层。
开发者：ChatGPT Plus/Pro + Gemini API/AI Studio 按需。
视频创作者：Google AI Pro/Ultra + ChatGPT 免费层或 Plus。
企业团队：不要用个人套餐拼，直接评估 Business / Enterprise / Workspace 方案。

订阅前检查清单

付费前先确认这些问题：

你的地区是否支持目标套餐？
你要用的模型是否包含在该套餐里？
Codex、Antigravity、Flow、Omni 是否真的可用？
视频功能是否有地区、年龄、排队或分辨率限制？
API 调用是否包含在订阅里，还是单独计费？
文件上传、上下文窗口、agent mode、deep research 是否有额度限制？
数据隐私设置是否符合你的项目要求？
你是否已经有 Google One、Workspace、ChatGPT Business 或学校/公司账号权益？

尤其要注意：个人订阅不等于 API 免费，不等于商用无限额度，也不等于企业合规。

小结

Google I/O 之后，Gemini 的竞争力明显增强，尤其是在视频、多模态、Google 生态、Android、AI Studio 和 Antigravity 方向。但 ChatGPT 仍然是更稳的通用主力，特别是在日常写作、复杂问答、文件分析、代码辅助和 Codex 工作流里。

最简单的判断是：

不知道选哪个：先选 ChatGPT Plus。
深度 Google 用户：选 Google AI Pro。
高频开发者：看 Codex 和 Antigravity 谁更贴近你的工作流。
视频创作者：优先看 Gemini Omni、Flow 和 Google AI Pro / Ultra。
企业用户：按合规、权限、审计和现有办公生态选，而不是按模型热度选。

AI 订阅不是越多越好。真正划算的方式，是明确一个主力工作流，再把其他平台作为补充，而不是为每一个发布会都多开一个长期订阅。

参考来源：

AI Agent 到底怎么进化的？2022-2026 五代演进完整梳理

Sat, 16 May 2026 19:19:52 +0800

AI Agent 的发展不是一夜之间发生的。

2022 年底，ChatGPT 还只是一个会聊天的窗口。到 2026 年，Agent 已经开始具备工具调用、文件操作、电脑控制、长期记忆、远程协作和常驻执行能力。四年时间里，它从“回答问题的模型”逐步变成“能推进任务的数字工作者”。

如果按时间线看，AI Agent 大致经历了五代演进。每一代都解决了上一代的核心缺陷，也制造了新的泡沫和新的安全问题。

总览：五代 Agent 时间线

阶段	时间	关键词	能力变化	核心问题
第零代	2022 年末 - 2023 年初	对话框	会生成文本，但不能行动	模型和现实世界断裂
第一代	2023 年中 - 2023 年末	工具调用	能输出结构化调用，接入 API 和 RAG	开环循环、任务迷路
第二代	2023 年末 - 2024 年	工程化工作流	有规划、状态、反思和多 Agent 协作	工作流易复制，低代码泡沫
第三代	2024 年 - 2025 年	Computer Use	能看屏幕、点鼠标、操作 GUI	权限、安全和误操作风险
第四代	2025 年 - 2026 年	MCP / Skills / 常驻	有工具网络、长期上下文和专业技能	常驻执行扩大风险半径
第五代前瞻	2026 年之后	闭环与世界模型	可能拥有更强记忆、验证和物理行动能力	治理难度继续上升

下面按时间线展开。

2022 年末：第零代，ChatGPT 对话框时代

第零代的起点，是 2022 年 11 月 30 日 ChatGPT 发布。

这一代 AI 还不能算真正的 Agent。它有很强的语言生成能力，但主要被困在对话框里。它可以写一段 Python 代码，却不能在你的电脑上运行；可以规划旅行，却不能打开网站订票；可以告诉你文件应该怎么改，却不能进入文件系统执行修改。

这一代的能力边界很清楚：

能理解自然语言；
能生成文章、问答、代码和方案；
不能主动访问最新数据；
不能稳定读取企业内部资料；
不能执行外部动作；
不能管理长期任务状态。

所以第零代最核心的问题是：模型能力和现实世界之间断裂。它能想、能说，但不能行动。

这一阶段也出现了第一波泡沫：提示词工程师、提示词模板市场、提示词课程和提示词认证。早期模型确实对 prompt 很敏感，但市场把一个临时补丁误解成了长期护城河。

后来 GPT-4 级别模型、系统提示、函数调用和产品默认引导逐渐成熟，大量提示词模板失去稀缺性。这个现象后来反复出现：新能力出现时，中间层爆发；下一代系统把能力内化后，中间层蒸发。

2023 年中：第一代，工具调用觉醒

第一代 Agent 的关键词是工具调用。

2023 年 6 月，OpenAI 发布 function calling。它允许开发者向模型描述函数名、用途、参数类型和 JSON Schema。模型理解用户请求后，可以不再输出普通自然语言，而是输出一个结构化 JSON 调用，再由外部系统执行。

这一步的架构意义很大：模型开始从“只会说话的大脑”，变成可以驱动外部工具的大脑。

第一代的关键能力包括：

根据用户意图选择工具；
输出结构化参数；
调用外部 API；
把 API 结果带回模型继续推理；
通过 RAG 接入外部知识；
通过插件和知识库形成早期 persona。

同一时期，RAG 和向量数据库流行起来。它们解决的是模型不知道最新信息、企业私有资料和内部知识的问题。系统先检索相关文档片段，再把材料放进上下文，让模型基于这些材料回答。

于是第一代 Agent 的基本结构出现了：

你是谁：系统提示和 persona；
你知道什么：知识库、RAG、私有文档；
你能做什么：函数调用、插件、外部 API。

这一代最典型的泡沫是 AutoGPT。它展示了一个很诱人的想法：用户只给一个宏大目标，AI 自己拆解任务、搜索、写文件、评估、循环，直到它认为完成。

但 AutoGPT 很快暴露问题。它缺少状态约束、终止条件和可靠反馈，经常陷入错误方向，反复调用错误参数，或者烧掉大量 API 请求。第一代的教训很直接：工具加死循环，不等于生产级 Agent。

2023 年末到 2024 年：第二代，工程化工作流

AutoGPT 的失败让行业意识到，不能只靠模型自由发挥。复杂任务需要结构化流程。

第二代 Agent 的关键词是工程化工作流。Agent 不再只是一次模型调用，而是一个有状态、有控制流、有评估机制的软件系统。

这一代的关键能力包括：

任务规划：把大目标拆成步骤；
状态管理：记录任务进行到哪里；
反思修正：生成后自评，再修改；
工具编排：在不同工具之间切换；
人机协作：在关键节点让人确认；
多 Agent 协作：让不同角色分工。

典型范式是 ReAct，也就是 Reasoning + Acting。模型先推理，再调用工具，再根据观察结果进入下一轮推理。这样 Agent 不再盲目行动，而是每一步都有可审计的逻辑和反馈。

这一阶段也形成了 agentic workflow 的几种常见模式：

反思：先生成，再评审，再修改；
工具调用：按任务选择搜索、数据库、代码执行、企业 API；
规划：拆解目标，跟踪状态；
多 Agent 协作：产品、开发、测试、评审分工。

第二代的价值，是把模型能力放进可控流程里。一个设计好的 workflow，有时能让较小模型完成比单次大模型调用更稳定的结果。

但这一代也带来低代码 Agent 平台泡沫。很多平台用拖拽方式组合 prompt、RAG、插件和流程，确实降低了搭建门槛。但如果一个流程可以被低成本复制，平台本身就很难形成护城河。

低代码工具能吃到早期红利，但红利不等于壁垒。

2024 到 2025 年：第三代，Computer Use 进入真实界面

第三代 Agent 的关键词是 Computer Use。

此前的工具调用主要依赖 API，能做什么取决于开发者提前接好什么接口。但现实世界里，大量软件没有理想 API，或者 API 不开放、不完整、不统一。

Computer Use 类能力让模型开始看屏幕、点鼠标、操作 GUI。它把通用电脑界面本身变成工具。

第三代的关键能力包括：

识别屏幕内容；
点击按钮、输入文本、切换窗口；
操作网页和桌面软件；
读仓库、改文件、跑测试；
查看终端输出和错误信息；
更接近真实工程助手。

这一步把 Agent 从“调用已接好的工具”，推进到“像人一样操作软件界面”。它也让 coding agent 更接近真实工作流：读项目、改代码、运行测试、根据报错继续修。

但信任边界也扩大了。AI 操作电脑，意味着它可能误点、误删、误提交，也可能被网页、文档或界面文字诱导。提示注入不再只是聊天问题，而可能变成文件操作、权限和系统安全问题。

Vibe coding 的争议也集中在这一阶段。让 AI 快速生成项目很爽，但如果缺少测试、评估、权限控制和部署边界，就容易从快速原型变成快速事故。

第三代的核心教训是：越接近真实操作，越需要沙箱、审批、回滚和最小权限。

2025 到 2026 年：第四代，MCP、Skills 和常驻数字员工

第四代 Agent 的关键词是常驻、连接、记忆和专业化。

这一代的重点不只是单次任务更强，而是 Agent 开始拥有长期上下文、工具网络、专业技能和时间感。它不再只是一次聊天里的助手，而更像一个能持续工作的数字员工。

MCP 解决的是工具连接问题。它让 Agent 用标准方式连接文件系统、数据库、浏览器、设计工具、项目管理工具和企业系统。协议一旦稳定，很多只做“工具连接中间层”的项目就会被压缩。

Skills 解决的是专业方法问题。工具告诉 Agent 能做什么，技能告诉 Agent 应该怎么做。一个好的 skill 不只是 prompt，而是把领域流程、约束、检查方式、常见坑和工具调用顺序封装起来。

第四代的关键能力包括：

长期记忆：保存用户偏好、项目规则和历史任务；
项目上下文：让 Agent 理解代码库、文档和工作规范；
工具网络：通过 MCP、API、浏览器和文件系统连接外部世界；
专业技能：用 Skills 封装任务方法；
常驻执行：可以等待、唤醒、提醒和继续跟进；
远程协作：用户可以从不同设备回来审批和调整。

这一代 Agent 开始有“员工感”：

有身份和职责边界；
有长期上下文；
有专业工作方法；
有时间感；
有工具权限；
能在无人盯着时继续推进任务。

但能力越像员工，风险半径也越像员工。长期运行、读取本地数据、持有密钥、调用工具、处理任务，都让安全问题从边缘变成中心。

尤其要注意一点：文本也是攻击面。如果 Agent 会读取并遵循 Markdown、说明文档、技能包、网页内容，那么恶意文本就可能改变它的行为。提示注入不再只是聊天问题，而是供应链问题、权限问题和执行安全问题。

第四代的核心教训是：常驻 Agent 不只需要能力，还需要治理。

2026 之后：第五代前瞻，闭环、内在记忆和世界模型

第五代还不是确定历史，更像是沿着前面四年的演进逻辑继续外推。

第一个方向是更完整的闭环。

成熟 Agent 至少需要三层闭环：

执行闭环：每一步操作后验证结果，不符合预期就回滚、修正、重试；
时间闭环：跨多个唤醒周期追踪长期目标，而不是做完一次动作就结束；
认知闭环：知道哪些信息确定，哪些只是猜测，哪些已经过期。

第二个方向是内在记忆。

过去的记忆大多在模型外部：RAG、向量库、会话记录、本地文件、memory.md。如果未来模型架构本身支持跨会话持久状态，Agent 的记忆系统会被重构。

第三个方向是世界模型。

今天很多 Agent 仍是反应式的：观察、响应、再观察。真正高风险任务需要模型能预演行动后果。比如改数据库脚本前，要先想到数据丢失、回滚失败、兼容性问题，而不是先造成事故再学习。

第四个方向是具身化。

前几代主要发生在数字空间：API、屏幕、文件、浏览器、企业工具。下一步可能是把 Agent 的行动能力延伸到物理世界，例如机器人、设备控制、工业系统和标准化物理接口。

第五代真正要解决的问题，是如何让 Agent 不只会执行任务，还能理解行动后果、管理长期状态，并在更大风险半径内保持可靠。

这条时间线背后的六条规律

第一，基座模型能力仍然是天花板。Agent 不是大模型之外的魔法，而是大模型能力通过工程系统释放出来的方式。

第二，工程化架构会放大模型能力。规划、验证、反思、修正、评估和权限控制，比单次生成更接近可交付结果。

第三，开放协议会重塑价值分配。MCP、Skills、项目上下文规范一旦稳定，竞争焦点会从“谁先接了工具”转向“谁沉淀了真实领域能力”。

第四，Agent 演化的隐含主线是人机信任边界扩展。从信任文本，到信任 API 调用，到信任复杂工作流，到信任电脑操作，再到信任常驻执行，每一代都把风险半径往外推。

第五，每一代事故都会变成下一代铁律。AutoGPT 的无限循环推动结构化编排，vibe coding 的失控推动评估驱动开发，误删生产环境推动最小权限和沙箱，技能投毒推动供应链安全。

第六，Agent 生态会反复经历爆发和灭绝。能力升级会创造临时中间层，模型或平台内化后又会消灭这些中间层。把时间窗口误判成护城河，是 AI 创业里很危险的错觉。

真正的护城河

AI Agent 领域真正的护城河，不是抢先包装某个新能力。

更可靠的护城河大概有三类。

第一，垂直领域深度。你是否真的理解一个行业的流程、风险、异常和责任边界。通用模型可以学概念，但不一定能替代长期打磨出来的领域执行经验。

第二，数据飞轮。你是否能从真实使用中积累高质量反馈，不断改进流程、评估、微调和产品判断。

第三，用户信任。用户是否愿意把更高价值、更长期、更有风险的任务交给你，而不是只把你当成一次性工具。

当某项能力被平台或基座模型吞噬之后，仍然能沉淀流程、反馈、责任边界和信任的产品，才更可能留下来。除此之外，很多项目只是阶段性泡沫。

最后

从 2022 年到 2026 年，AI Agent 的演进不是“模型越来越会聊天”，而是“人类愿意交给 AI 的事情越来越多”。

真正成熟的 Agent，不是最敢自动执行的系统，而是知道何时执行、何时验证、何时暂停、何时请人确认的系统。

如果要判断一个 Agent 产品是否有长期价值，可以问一个问题：当这个能力被下一代模型或平台内置后，它还剩下什么？

答案如果是领域流程、真实数据、可验证结果和用户信任，那才可能是长期价值。

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 会明显省时间。如果你只是偶尔上传一份敏感文件问几句，反而要更谨慎，别让“方便复用”变成“忘了自己存了什么”。

参考资料

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

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、Claude Code 和 Gemini 的记忆机制有什么不同？

Thu, 07 May 2026 14:47:17 +0800

AI 产品里的“记忆”正在变得越来越重要。它标志着 AI 从“单次对话工具”走向“长期协作伙伴”：不用每次重新介绍背景，不用反复解释偏好，也不用让模型一次次重新理解项目。

但不同产品里的记忆并不是一回事。ChatGPT、Claude Code 和 Gemini 都在解决“AI 如何记得更久”的问题，但它们的设计目标、存储位置、透明度和适用场景差异很大。

截至 2026 年 5 月 7 日，可以把它们粗略理解成三类：

ChatGPT 更像“个人助理记忆”。
Claude Code 更像“工程项目记忆”。
Gemini 更像“Google 生态上下文”。

ChatGPT：围绕人的长期偏好

ChatGPT 的记忆机制主要面向个人协作。它关心的是“你是谁”“你偏好什么”“你长期在做什么”。

OpenAI 目前把 ChatGPT 的记忆分成两类：saved memories 和 chat history。

saved memories 是 ChatGPT 保存下来的重要信息，比如你的名字、偏好、目标、常用技术栈、写作习惯等。你可以直接要求它记住某件事，它也可能在对话中自动保存它认为未来有用的信息。

chat history 则是让 ChatGPT 在回答时参考过去聊天。它不等于把每一段聊天都完整变成记忆，而是在需要时从过往对话里找相关上下文。

所以 ChatGPT 的核心逻辑是：跨会话理解同一个用户。

典型例子包括：

“以后给我代码示例时尽量简洁。”
“我主要使用 Python 和 TypeScript。”
“我正在写一个关于 AI 工具的 Hugo 博客。”
“我喜欢先看结论，再看细节。”

这些记忆不是绑定某个单独项目，而是跟随账号和个人使用习惯。

Memory Sources：让个性化来源更可见

OpenAI 在 2026 年 5 月的更新中强调了 Memory sources。

它的作用不是新增另一种记忆，而是让用户看到 ChatGPT 在个性化回答时参考了哪些来源。根据 OpenAI 帮助文档，Memory Sources 可能显示：

过去聊天。
保存记忆。
自定义指令。
文件库中的文件。
已连接 Gmail 中的邮件。

其中，文件和 Gmail 的可见范围会受到计划、地区和连接状态限制。OpenAI 也明确说明，Memory sources 不一定展示影响回答的所有因素，而是帮助用户理解和管理个性化。

这一步很重要。因为 AI 越会“记住你”，用户越需要知道它到底根据什么在回答。否则个性化很容易变成黑箱：你感觉它好像知道你，但不知道它为什么知道。

ChatGPT 的优势是跨会话、跨主题持续理解个人偏好；风险是记忆容易过期，或者用户忘了某条旧记忆还在影响回答。因此，适合定期清理 saved memories 和旧聊天。

Claude Code：围绕代码库和工程规则

Claude Code 的记忆机制更偏工程协作。它关心的不是“用户平时爱喝什么咖啡”，而是“这个代码库应该怎么改”。

Claude Code 有两类容易混在一起的记忆：

显式项目记忆：CLAUDE.md。
自动项目记忆：Auto Memory。

CLAUDE.md 是最基础、最稳定的项目记忆文件。它可以放在项目根目录，也可以在子目录中存在。Claude Code 会读取这些文件，把它们作为项目说明和操作规则。

适合写进 CLAUDE.md 的内容包括：

常用构建、测试、lint 命令。
代码风格和命名规则。
项目架构说明。
模块边界和危险区域。
团队约定和提交流程。

如果 CLAUDE.md 放在代码库里，它可以提交到 Git，成为团队共享的 agent 说明书。这一点和 ChatGPT 的云端个人记忆完全不同。

Claude Code Auto Memory：自动积累项目经验

Claude Code 现在也有 Auto Memory。它的目标是让 Claude 在多个会话之间自动积累项目经验，而不要求用户每次手写说明。

根据 Claude Code 文档，Auto Memory 会让 Claude 在工作过程中为自己保存笔记，例如构建命令、调试发现、架构说明、代码风格偏好和工作流习惯。它不会每个会话都保存，而是判断哪些信息未来可能有用。

这里有一个容易误解的点：Auto Memory 默认不是把内容写到项目根目录的 .claude/memory.md。官方文档说明，每个项目会在用户目录下拥有自己的 memory 目录，路径类似：

`1`	`~/.claude/projects/<project>/memory/`

其中 MEMORY.md 会在每次对话开始时加载前 200 行或前 25KB，详细内容则可能被拆到其他主题文件里。Auto Memory 文件是本机本地的 Markdown 文件，用户可以通过 /memory 查看、编辑或删除。

这让 Claude Code 的记忆更像“本机上的项目经验库”。它比 ChatGPT 的个人记忆更贴近代码库，也比单纯的 CLAUDE.md 更动态。

但要注意，Auto Memory 是机器本地的，不会天然跟随代码库同步到其他机器或云环境。如果要团队共享稳定规则，仍然应该优先写进项目中的 CLAUDE.md。

Gemini：围绕 Google 生态上下文

Gemini 的记忆逻辑又不同。

Gemini 也有保存信息和参考过去聊天的能力。Google 帮助文档提到，用户可以保存关于生活、工作或偏好的信息，也可以让 Gemini 在回答前参考过去聊天。Gemini 使用这些信息时，可能会在回答底部的来源区域显示 Your saved info 或 Previous chats。

但 Gemini 的差异化不只在“保存几条偏好”，而在 Google 生态集成。

在用户授权和功能可用的前提下，Gemini 可以通过连接的 Google 应用获取上下文，例如 Gmail、Google Drive、Docs、Sheets 等。它的优势不是让用户一条条教它记住什么，而是把已有的 Google 账号资料变成可检索的工作上下文。

典型区别是：

ChatGPT 记得：“我最近在做 LTO 磁带机修复。”
Gemini 可能可以从 Gmail 找到购买确认邮件，或从 Drive 里读取相关维修笔记。

当然，这不代表 Gemini 可以无条件读取你所有 Google 数据。它取决于账号类型、地区、权限、连接应用、Keep Activity 设置和具体产品可用性。对企业或学校账号，还可能受 Google Workspace 管理员控制。

所以更准确地说，Gemini 的记忆不是一个单纯的“备忘录”，而是“保存信息 + 过去聊天 + Google 生态连接”的组合。

三者核心差异

维度	ChatGPT	Claude Code	Gemini
核心对象	人和偏好	项目和代码库	Google 账号与生态资料
典型记忆	偏好、背景、长期目标	架构、命令、规范、调试经验	saved info、过去聊天、Gmail/Drive/Docs 上下文
存储形态	OpenAI 账户内的记忆和聊天上下文	`CLAUDE.md`、`MEMORY.md`、本地 Markdown 文件	Google 账号活动、保存信息、连接应用数据
透明度	Memory sources 可见一部分来源	Markdown 文件可直接查看和编辑	通过来源提示、Gemini Apps Activity 和 Google 设置管理
跨项目能力	强，跟随用户账号	弱，主要跟随项目或本机项目 memory	强，取决于 Google 生态资料和权限
团队共享	不适合直接共享	`CLAUDE.md` 可随 Git 共享	主要依赖 Workspace 和权限体系
最适合	个人偏好和长期助理	长期代码项目和 agent 协作	Google Workspace 资料检索和跨工具工作

该怎么选择和使用

如果你想让 AI 记住“我是谁、我喜欢什么风格、我长期怎么工作”，ChatGPT 的记忆更合适。

它适合保存个人偏好，例如写作风格、常用技术栈、回答格式、职业背景、长期项目方向。它的重点是减少自我介绍成本，让每次新对话更快进入状态。

如果你想让 AI 记住“这个代码库怎么改、哪些命令能跑、哪些坑不能踩”，Claude Code 更合适。

稳定规则写进 CLAUDE.md，团队共享；动态经验交给 Auto Memory 辅助积累；关键决策最好仍然整理进文档或 CLAUDE.md，避免只停留在本机自动记忆里。

如果你的资料大量存在 Gmail、Drive、Docs、Sheets 里，Gemini 的生态上下文更有优势。

它适合查找过去邮件、整理 Google Drive 文档、联动日历和办公资料。使用 Gemini 的关键，不是反复在聊天里提醒它，而是确保相关应用连接、权限和活动设置正确。

一个实用分工

可以把三者这样分工：

ChatGPT 记住“我的通用偏好”。
Claude Code 记住“这个仓库的工程知识”。
Gemini 检索“我在 Google 生态里的资料”。

也就是说，ChatGPT 更像私人秘书，Claude Code 更像项目里的资深工程同事，Gemini 更像 Google 账号里的资料索引员。

这三种记忆没有绝对高低，只是目标不同。

最需要警惕的是把它们混为一谈。个人偏好不一定适合写进项目记忆；项目架构不一定适合存在云端个人记忆；Google 生态检索也不等于模型真正“长期理解”了你。

简短判断

AI 记忆的下一阶段，不是简单地“记得越多越好”，而是记忆要分层、可见、可控。

ChatGPT 的重点是跨会话个人化，Claude Code 的重点是代码项目连续性，Gemini 的重点是 Google 生态上下文。真正好用的长期 AI 协作，不是把所有信息塞进一个黑箱，而是让不同类型的记忆待在合适的位置。

个人偏好放在个人记忆里，工程规则放在代码库里，历史资料放在原本的文档和邮件系统里。AI 要做的，是在需要时准确调用这些上下文，而不是把所有东西混成一团。

从 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 不再只是“每次从零开始回答问题”的工具，而是在逐步变成能记住偏好、理解上下文、知道何时搜索，并且让用户管理这些记忆来源的长期助手。

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 工具的核心不是一直绕过验证，而是让账号、网络和使用方式都尽量正常。这样才能减少登录麻烦，也能降低后续被误伤的概率。

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

ChatGPT、Claude、Gemini 怎么分工：日常对话、编程和特殊能力怎么选

Sat, 25 Apr 2026 10:51:19 +0800

现在很多人不是只用一个模型，而是会在 ChatGPT、Claude 和 Gemini 之间来回切换。问题也随之变得很实际：到底什么任务该交给谁？

这件事之所以容易让人纠结，不是因为三家都不够强，而是因为它们已经强到开始“分工不同”。如果还用“谁更聪明”这种非常笼统的标准去选，反而容易选错。

如果先说一个简化版结论，可以大致这样理解：

日常对话和综合型任务，很多人会先想到 ChatGPT
命令行编程、长上下文协作、持续推进型任务，Claude 往往更顺手
需要依赖 Google 生态、搜索、多模态入口或某些产品级特殊能力时，Gemini 更有存在感

下面分三块讲。

1. 日常对话：为什么很多人还是先打开 `ChatGPT`

对大多数普通使用场景来说，ChatGPT 仍然很像“默认入口”。

这里说的不是某一个 benchmark，而是整体体验：
你临时想问一个问题、整理一个思路、写一段文案、做一份初稿、总结一篇资料，ChatGPT 通常给人的感觉会比较均衡。

它的优势往往体现在几个地方：

回答风格比较稳定
普通用户上手门槛低
多数综合型任务不需要太多额外调教
产品完成度高，适合高频日常使用

所以如果你的任务是下面这种：

帮我整理一个主题
把一段想法写成结构化内容
总结一篇长文
头脑风暴几个方案
把表达润色得更清楚

那 ChatGPT 往往是个很自然的起点。

这并不代表它在所有专业任务里都一定最强，而是它在“广谱通用”这件事上，通常更像一个默认工作台。

2. 命令行编程和长任务：为什么很多人更偏向 `Claude`

一旦任务从“聊一聊”切换成“把事情持续做完”，很多人的偏好就会开始转向 Claude。

尤其是这些场景：

命令行编程
大项目上下文理解
多文件协作修改
长链路调试
边读代码边推进任务

这类任务的关键，往往不是一轮回答有多惊艳，而是模型能不能在更长的任务链里保持稳定。

Claude 经常被偏爱的原因，通常不是“它一句话比别人更会说”，而是：

对长上下文任务更耐用
连续读文件、读日志、读规则时体验更稳定
更适合逐步推进复杂编码任务
在命令行和 agent 工作流里更常被当成主力模型

如果你是在做 vibe coding、命令行修 bug、项目结构理解、跨多个文件改功能，Claude 的优势会更容易体现出来。

简单说，Claude 比较像那种适合一起“干活”的模型，而不只是适合问一句答一句。

3. `Gemini` 的优势往往不在“和别人正面拼一切”

很多人讨论 Gemini 时，容易把问题问成：它到底是不是三家里最强。

但从实际使用体验看，更有用的问题通常不是这个，而是：它在哪些场景里特别值得单独拿出来用。

Gemini 的价值，往往更容易体现在这些方向：

Google 生态结合
搜索与资料获取
多模态入口
某些产品侧功能联动

如果你的工作流本来就和 Google 的工具链很近，比如：

搜索
文档
邮件
浏览器侧使用
手机端入口

那 Gemini 的实际便利性可能会高于单纯的模型分数对比。

也就是说，Gemini 的可用性很多时候来自“它在哪里更顺手接入你的工作流”，而不只是“它单轮回答是不是赢了谁”。

4. 真正有用的选法，不是问谁最强，而是问任务类型

把三家模型放在一起比较时，最容易踩的坑就是试图找一个“唯一最强”。

但现实里的任务差异太大了：

有的是一次性问答
有的是长对话陪跑
有的是代码工程
有的是信息检索
有的是多模态处理
有的是工具链协作

所以更有效的选法，通常是按任务类型来分：

需要一个综合型、日常高频、打开就能用的助手：先看 ChatGPT
需要长上下文、命令行、编程协作、持续推进复杂任务：优先试 Claude
需要借力 Google 生态、搜索、多模态入口或某些产品联动能力：重点看 Gemini

这样分工，比强行争一个总冠军更接近真实使用。

5. 为什么很多重度用户会同时订三家

从轻度用户视角看，同时订三家模型服务很容易显得“重复”。
但从重度用户视角看，这更像是在给不同任务配不同工具。

原因很简单：
如果三家的长处已经开始明显分化，那么同时使用它们，本质上就不是重复付费，而是在减少任务切换成本和试错成本。

比如：

日常整理和综合问答，用 ChatGPT
编程主任务，用 Claude
某些检索、多模态或 Google 相关链路，用 Gemini

这种组合方式的逻辑，和设计师同时装多个软件、开发者同时用多个 IDE，并没有本质区别。

6. 什么时候不要来回切太多模型

当然，模型多也不一定总是更好。

如果你本身还在建立稳定工作流，过早在三个模型之间频繁横跳，反而可能让自己更乱。常见问题包括：

同一个任务来回重复讲三遍
不同模型给出不同建议，自己更难判断
上下文断裂，协作成本反而更高
还没形成自己的使用边界，就先被工具选择拖住

所以更稳的方式通常是：

先给每个模型一个主场景
在主场景里连续用一段时间
再逐步形成自己的分工习惯

这样你会更容易得到真正可复用的经验，而不是永远停留在“今天换这个试试”的阶段。

7. 可以先这样记住

如果只想先记一个够用的版本，可以直接记这张口语化分工表：

ChatGPT：更像通用型默认助手
Claude：更像长任务和编程协作主力
Gemini：更像在搜索、多模态和 Google 生态里更有优势的工具

这不是绝对规则，也不是说三者彼此不能替代，而是一个更接近真实使用体验的起点。

真正重要的不是选出“宇宙最强模型”，而是尽快知道：
你手上的这类任务，用哪个模型最省时间、最省心、最容易做出结果。

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 作为工作执行层”的方向。

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 显然希望把图像生成从灵感型工具，往可执行、可排版、可沟通、可交付的生产工具推进。文字控制、多语言、版式、风格跨度、长页面内容组织，这些原本最容易暴露短板的地方，现在反而成了它主动展示的卖点。

这不代表图像生成已经完全解决了设计工作里的所有问题，但至少从这次发布页可以看出，竞争重心正在变化。未来谁更强，可能不只是看谁能出一张更惊艳的图，而是看谁能更稳定地做出一份真的能拿去用的视觉内容。

ChatGPT Codex 配额使用情况查询面板：codex-quota的使用方法

Thu, 16 Apr 2026 18:13:04 +0800

这个项目做什么

codex-quota 是一个轻量工具，能查询 ChatGPT Codex 配额使用情况，数据来源是 https://chatgpt.com/backend-api/wham/usage。

主要功能：

支持单账号或多账号（account/*.auth.json）查询。
输出 five_hour%、weekly%、weekly_reset，并标记来源（network 或 cache）。
对临时失败（408、429、5xx）做指数退避重试。
内置本地缓存，减少已耗尽配额时的重复请求。
提供 Web Dashboard、JSON API、auth 文件管理页面。

优点：

轻量：单脚本可跑，依赖简单。
实用：CLI 和 Web 两种入口都能用。
可部署：支持 Docker 和 Docker Compose。
易运维：支持重试、缓存和定时刷新。

先准备好账号凭证

在 account/<name>.auth.json 创建凭证文件，例如：

{
  "tokens": {
    "access_token": "eyJ...",
    "account_id": "user-xxxxxxxx"
  }
}

解释：

access_token 和 account_id 是查询接口所需字段。
文件名里的 <name> 会作为账号名显示在结果中。

本地 CLI 用法（保留原命令）

安装依赖：

`1`	`pip install -r requirements.txt`

解释：安装项目运行依赖。

查询全部账号：

`1`	`python codex_quota.py`

解释：读取 account/*.auth.json，汇总输出所有账号配额。

查询单个账号：

`1`	`python codex_quota.py your_account_name`

解释：只查询 account/your_account_name.auth.json。

强制刷新（跳过缓存）：

`1`	`python codex_quota.py --refresh`

解释：忽略本地缓存，直接请求最新接口数据。

CLI 参数说明（README 对齐）

account_name：可选账号名（不带 .auth.json）。
--account-dir：凭证目录，默认 account。
--chatgpt-url：配额接口地址。
--raw-json：输出完整 JSON 响应体。
--raw-headers：输出响应头。
--refresh：忽略缓存。
--retries：重试次数，默认 3。
--retry-delay：基础重试间隔秒数，默认 2.0。

Web Dashboard 用法（保留原命令）

启动服务：

`1`	`python codex_quota_service.py --host 0.0.0.0 --port 8081`

解释：启动 HTTP 服务并监听 8081 端口。

访问地址：http://localhost:8081

Service 参数：

--host：监听地址，默认 0.0.0.0。
--port：端口，默认 8081。
--interval-seconds：调度刷新间隔，默认 3600。
--account-dir：凭证目录，默认 account。
--state-file：状态文件路径，默认 <account-dir>/codex_quota_web_results.json。
--account-name：可选，单账号模式。
--chatgpt-url：配额接口地址。
--retries：重试次数。
--retry-delay：基础重试延迟。
--refresh：调度刷新时忽略 CLI 缓存。

HTTP 接口（方便接自动化）

GET /：Dashboard 页面。
GET /api/results：最新结果 JSON。
GET /refresh：立即刷新并跳回 /。
GET /auth：列出 auth 文件。
GET /auth/new：新建 auth 文件表单。
GET /auth/edit?name=<account>：编辑 auth 文件表单。
POST /auth/save：创建/更新 auth 文件。
POST /auth/delete：删除 auth 文件。

Docker 用法（保留原命令）

构建镜像：

`1`	`docker build -t codex-quota .`

解释：把当前项目打包成 codex-quota 镜像。

运行容器（映射 8081）：

`1`	`docker run --rm -p 8081:8081 -v ./account:/app/account codex-quota`

解释：

--rm：容器退出自动删除。
-p 8081:8081：主机端口映射到容器端口。
-v ./account:/app/account：把本地凭证目录挂载进容器。

访问地址：http://localhost:8081

Docker Compose 用法（保留原命令）

启动：

`1`	`docker compose up --build`

解释：按 docker-compose.yml 构建并启动服务。

访问地址：http://localhost:8081

使用建议

多账号场景优先走 Dashboard，便于统一查看和管理 auth 文件。
告警或自动化集成优先用 GET /api/results。
公开仓库不要提交真实 access_token。
如果你看到大量临时错误，可调大 --retries 与 --retry-delay。

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 额度现象。

Codex 额度用量统计

Sun, 12 Apr 2026 00:01:33 +0800

如果你想查看 Codex 当前账号的额度剩余情况，可以直接写一个小脚本去请求 ChatGPT 的 /backend-api/wham/usage 接口。

这类脚本的思路很简单：

从 auth.json 里读取 tokens.access_token 和 tokens.account_id
请求 https://chatgpt.com/backend-api/wham/usage
在请求头里带上 Authorization: Bearer ... 和 ChatGPT-Account-Id
解析返回结果里的五小时窗口和周窗口额度

适合做什么

这个方法适合你在本地快速确认：

五小时额度还剩多少
周额度还剩多少
额度会在什么时候重置

如果你有多个账号，也可以让脚本批量读取 account/*.auth.json，统一输出一张摘要表。 auth.json文件可以从 ~/.codex/ 目录下找到, 对应你当前登录的chatgpt账户。

最关键的输入

脚本通常只依赖两项凭证：

access_token
account_id

它们一般都可以从本地 auth.json 中拿到。只要这两个值有效，请求头就能按下面的形式组织：

headers = {
    "Authorization": f"Bearer {auth_token}",
    "Accept": "application/json",
    "ChatGPT-Account-Id": auth_account_id,
    "Origin": "https://chatgpt.com",
    "Referer": "https://chatgpt.com/",
    "User-Agent": "Mozilla/5.0",
}

返回结果怎么看

接口返回后，重点看的是两类窗口：

five_hour
weekly

脚本可以把它们统一整理成下面几项：

剩余额度百分比
重置时间
对应的时间窗口长度

如果接口字段名有差异，也可以顺手兼容 primary_window、secondary_window、five_hour_limit、weekly_limit 这些变体。

常见问题

如果脚本返回 401，通常说明 access_token 已过期或无效。

如果返回 403，通常说明当前账号没有权限访问这个接口，或者账号状态异常。

如果你看到同一个响应里字段命名不一致，也不用太意外。实际处理时最好把不同命名方式统一映射后再输出。

参考链接

codex-auth-manager：https://github.com/RioArisk/codex-auth-manager

代码

import argparse
import base64
import json
import os
import sys
from datetime import datetime, timedelta, timezone
from pathlib import Path
from typing import Any

import requests


UTC = timezone.utc
CST = timezone(timedelta(hours=8), name="CST")
JSONDict = dict[str, Any]


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description="Query ChatGPT Codex usage from /backend-api/wham/usage."
    )
    parser.add_argument(
        "account_name",
        nargs="?",
        help="Account name used to load account/<account_name>.auth.json. If omitted, load all *.auth.json files in account/.",
    )
    parser.add_argument(
        "--account-dir",
        default="account",
        help="Directory containing <account_name>.auth.json files.",
    )
    parser.add_argument(
        "--chatgpt-url",
        default="https://chatgpt.com/backend-api/wham/usage",
        help="ChatGPT usage endpoint.",
    )
    parser.add_argument(
        "--raw-json",
        action="store_true",
        help="Print the full JSON response body.",
    )
    parser.add_argument(
        "--raw-headers",
        action="store_true",
        help="Print response headers.",
    )
    return parser.parse_args()


def print_json(data: Any) -> None:
    print(json.dumps(data, indent=2, ensure_ascii=False))


def load_auth_json(path_str: str | Path | None) -> JSONDict | None:
    if not path_str:
        return None
    path = Path(path_str).expanduser()
    if not path.is_file():
        return None
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except (OSError, json.JSONDecodeError):
        return None


def get_nested_string(data: JSONDict | None, *keys: str) -> str | None:
    current: Any = data
    for key in keys:
        if not isinstance(current, dict):
            return None
        current = current.get(key)
    return current if isinstance(current, str) and current else None


def format_dt(dt: datetime | None) -> str:
    if dt is None:
        return "-"
    return dt.astimezone(CST).strftime("%Y-%m-%d %H:%M:%S %Z")


def format_cst(dt: datetime | None) -> str:
    return format_dt(dt)


def epoch_ms_to_dt(value: Any) -> datetime | None:
    if value is None:
        return None
    try:
        raw = int(value)
    except (TypeError, ValueError):
        return None
    # Newer responses sometimes use epoch seconds, older ones use epoch milliseconds.
    timestamp = raw / 1000 if raw > 10**11 else raw
    return datetime.fromtimestamp(timestamp, tz=UTC)


def first_dict(data: Any, *keys: str) -> JSONDict | None:
    for key in keys:
        value = data.get(key) if isinstance(data, dict) else None
        if isinstance(value, dict):
            return value
    return None


def decode_jwt_exp(token: str) -> datetime | None:
    parts = token.split(".")
    if len(parts) != 3:
        return None
    try:
        payload = parts[1]
        payload += "=" * (-len(payload) % 4)
        data = json.loads(base64.urlsafe_b64decode(payload.encode("ascii")))
        exp = data.get("exp")
        if exp is None:
            return None
        return datetime.fromtimestamp(int(exp), tz=UTC)
    except (ValueError, TypeError, json.JSONDecodeError):
        return None


def get_percent_left(value: JSONDict) -> float | int | None:
    percent_left = value.get("percent_left")
    if percent_left is None:
        percent_left = value.get("remaining_percent")
    if percent_left is not None:
        return percent_left

    used_percent = value.get("used_percent")
    try:
        if used_percent is not None:
            return max(0, 100 - float(used_percent))
    except (TypeError, ValueError):
        return None
    return None


def resolve_limit_window(value: JSONDict) -> JSONDict:
    if (
        "reset_at" not in value
        and "reset_time_ms" not in value
        and isinstance(value.get("primary_window"), dict)
    ):
        return value["primary_window"]
    return value


def parse_limit_entry(name: str, value: Any) -> JSONDict | None:
    if not isinstance(value, dict):
        return None

    value = resolve_limit_window(value)

    percent_left = get_percent_left(value)
    reset_time_ms = value.get("reset_time_ms")
    if reset_time_ms is None:
        reset_time_ms = value.get("reset_at")

    window_seconds = value.get("limit_window_seconds")

    return {
        "name": name,
        "percent_left": percent_left,
        "reset_time_ms": reset_time_ms,
        "reset_at": epoch_ms_to_dt(reset_time_ms),
        "limit_window_seconds": window_seconds,
    }


def infer_limit_name(window_seconds: Any) -> str | None:
    if not isinstance(window_seconds, (int, float)):
        return None
    if window_seconds <= 6 * 3600:
        return "five_hour"
    if window_seconds >= 6 * 24 * 3600:
        return "weekly"
    return None


def relabel_rate_limits(primary: JSONDict | None, secondary: JSONDict | None) -> tuple[JSONDict | None, JSONDict | None]:
    for entry in (primary, secondary):
        if not entry:
            continue
        inferred_name = infer_limit_name(entry.get("limit_window_seconds"))
        if inferred_name:
            entry["name"] = inferred_name

    if primary and secondary and primary.get("name") == secondary.get("name"):
        if primary.get("name") == "weekly":
            primary["name"] = "five_hour"
        else:
            secondary["name"] = "weekly"

    if primary and primary.get("name") == "weekly" and secondary is None:
        return None, primary

    if secondary and secondary.get("name") == "five_hour" and primary is None:
        return secondary, None

    return primary, secondary


def parse_rate_limits(data: JSONDict) -> tuple[JSONDict | None, JSONDict | None]:
    primary = None
    secondary = None

    for primary_key in ("five_hour", "five_hour_limit", "five_hour_rate_limit", "primary"):
        if primary_key in data:
            primary = parse_limit_entry("five_hour", data.get(primary_key))
            if primary:
                break

    for secondary_key in ("weekly", "weekly_limit", "weekly_rate_limit", "secondary"):
        if secondary_key in data:
            secondary = parse_limit_entry("weekly", data.get(secondary_key))
            if secondary:
                break

    if primary is None:
        primary = parse_limit_entry("five_hour", data.get("primary_window"))
    if secondary is None:
        secondary = parse_limit_entry("weekly", data.get("secondary_window"))

    return relabel_rate_limits(primary, secondary)


def format_percent(value: Any) -> str:
    return f"{value:g}" if isinstance(value, (int, float)) else str(value if value is not None else "-")


def percent_sort_value(value: Any, descending: bool) -> tuple[int, float]:
    if isinstance(value, (int, float)):
        numeric_value = float(value)
        return (0, -numeric_value if descending else numeric_value)
    return (1, 0.0)


def get_auth_paths(account_dir: str, account_name: str | None) -> list[Path]:
    base_dir = Path(account_dir)
    if account_name:
        return [base_dir / f"{account_name}.auth.json"]
    return sorted(base_dir.glob("*.auth.json"))


def get_account_name_from_path(path: Path) -> str:
    suffix = ".auth.json"
    return path.name[: -len(suffix)] if path.name.endswith(suffix) else path.stem


def build_summary_row(account_name: str, five_hour: JSONDict | None, weekly: JSONDict | None) -> JSONDict:
    return {
        "account": account_name,
        "five_hour_percent": five_hour["percent_left"] if five_hour else None,
        "weekly_percent": weekly["percent_left"] if weekly else None,
        "weekly_reset_at": weekly["reset_at"] if weekly else None,
    }


def print_summary_rows(rows: list[JSONDict]) -> None:
    if not rows:
        return

    sorted_rows = sorted(
        rows,
        key=lambda row: (
            percent_sort_value(row.get("five_hour_percent"), descending=True),
            percent_sort_value(row.get("weekly_percent"), descending=True),
            format_cst(row.get("weekly_reset_at")),
            row["account"],
        ),
    )

    display_rows = []
    for row in sorted_rows:
        display_rows.append(
            {
                "account": str(row["account"]),
                "five_hour": format_percent(row.get("five_hour_percent")),
                "weekly": format_percent(row.get("weekly_percent")),
                "weekly_reset": format_cst(row.get("weekly_reset_at")),
            }
        )

    headers = {
        "account": "account",
        "five_hour": "five_hour%",
        "weekly": "weekly%",
        "weekly_reset": "weekly_reset",
    }
    widths = {
        key: max(len(headers[key]), max(len(item[key]) for item in display_rows))
        for key in headers
    }

    print(
        f"{headers['account']:<{widths['account']}}  "
        f"{headers['five_hour']:>{widths['five_hour']}}  "
        f"{headers['weekly']:>{widths['weekly']}}  "
        f"{headers['weekly_reset']:<{widths['weekly_reset']}}"
    )
    for item in display_rows:
        print(
            f"{item['account']:<{widths['account']}}  "
            f"{item['five_hour']:>{widths['five_hour']}}  "
            f"{item['weekly']:>{widths['weekly']}}  "
            f"{item['weekly_reset']:<{widths['weekly_reset']}}"
        )


def validate_token_inputs(
    token: str,
    account_id: str,
    auth_token: str | None,
    auth_account_id: str | None,
) -> int | None:
    if token.startswith("sess-"):
        print("status: invalid_token_type", file=sys.stderr)
        print(
            "message: --chatgpt-token looks like a session token (sess-...). Use the JWT access_token instead.",
            file=sys.stderr,
        )
        if auth_token:
            print(
                "hint: Found tokens.access_token in auth.json; omit --chatgpt-token or pass that value instead.",
                file=sys.stderr,
            )
        return 1

    token_exp = decode_jwt_exp(token)
    if token_exp is not None and token_exp <= datetime.now(UTC):
        print("status: expired", file=sys.stderr)
        print(f"message: access_token expired at {format_dt(token_exp)}", file=sys.stderr)
        if auth_token and auth_token != token:
            auth_token_exp = decode_jwt_exp(auth_token)
            hint = format_dt(auth_token_exp) if auth_token_exp else "unknown time"
            print(f"hint: auth.json contains a different access_token expiring at {hint}", file=sys.stderr)
        return 1

    if auth_account_id and account_id != auth_account_id:
        print("warning: supplied --account-id does not match auth.json tokens.account_id", file=sys.stderr)

    return None


def handle_error_response(response: requests.Response, data: Any, raw_json: bool) -> int | None:
    if response.status_code == 401:
        print("status: expired", file=sys.stderr)
        print("message: Token 已过期或无效", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code == 403:
        print("status: forbidden", file=sys.stderr)
        print("message: 账号已被封禁或无权访问", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code >= 400:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print_json(data)
        return 3

    return None


def fetch_chatgpt_usage(auth_path: Path, args: argparse.Namespace) -> tuple[int, JSONDict | None]:
    auth_data = load_auth_json(auth_path)
    account_name = get_account_name_from_path(auth_path)
    auth_token = get_nested_string(auth_data, "tokens", "access_token")
    auth_account_id = get_nested_string(auth_data, "tokens", "account_id")

    if not auth_data:
        print(f"{account_name}: auth file not found or invalid", file=sys.stderr)
        return 1, None

    if not auth_token:
        print(f"{account_name}: missing access_token", file=sys.stderr)
        return 1, None

    if not auth_account_id:
        print(f"{account_name}: missing account_id", file=sys.stderr)
        return 1, None

    validation_error = validate_token_inputs(
        auth_token,
        auth_account_id,
        auth_token,
        auth_account_id,
    )
    if validation_error is not None:
        return validation_error, None

    headers = {
        "Authorization": f"Bearer {auth_token}",
        "Accept": "application/json",
        "ChatGPT-Account-Id": auth_account_id,
        "Origin": "https://chatgpt.com",
        "Referer": "https://chatgpt.com/",
        "User-Agent": "Mozilla/5.0",
    }

    try:
        response = requests.get(args.chatgpt_url, headers=headers, timeout=60)
    except requests.RequestException as exc:
        print(f"Request failed: {exc}", file=sys.stderr)
        return 2, None

    if args.raw_headers:
        print("=== Headers ===")
        print_json(dict(response.headers))
        print()

    try:
        data = response.json()
    except ValueError:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print(response.text, file=sys.stderr)
        return 3, None

    error_response = handle_error_response(response, data, args.raw_json)
    if error_response is not None:
        return error_response, None

    if args.raw_json:
        print("=== Raw JSON ===")
        print_json(data)
        print()

    rate_limits = first_dict(data, "rate_limit", "rate_limits")

    if rate_limits is None:
        return 0, build_summary_row(account_name, None, None)

    five_hour, weekly = parse_rate_limits(rate_limits)
    return 0, build_summary_row(account_name, five_hour, weekly)


def main() -> None:
    args = parse_args()
    auth_paths = get_auth_paths(args.account_dir, args.account_name)
    if not auth_paths:
        print("No auth files found.", file=sys.stderr)
        sys.exit(1)

    exit_code = 0
    summary_rows: list[JSONDict] = []
    for auth_path in auth_paths:
        current_exit_code, summary_row = fetch_chatgpt_usage(auth_path, args)
        exit_code = max(exit_code, current_exit_code)
        if summary_row is not None and not args.raw_json:
            summary_rows.append(summary_row)

    if summary_rows:
        print_summary_rows(summary_rows)
    sys.exit(exit_code)


if __name__ == "__main__":
    main()

ChatGPT on KnightLi的博客

Google I/O 之后，GPT 和 Gemini 订阅怎么选？普通用户与开发者对比

先说结论

Google I/O 之后，Gemini 发生了什么变化

ChatGPT / GPT 订阅现在适合谁

Gemini / Google AI 订阅现在适合谁

普通用户怎么选

开发者怎么选

内容创作者怎么选

企业和团队怎么选

什么时候需要 Pro / Ultra

最省钱的订阅策略

订阅前检查清单

小结

AI Agent 到底怎么进化的？2022-2026 五代演进完整梳理

总览：五代 Agent 时间线

2022 年末：第零代，ChatGPT 对话框时代

2023 年中：第一代，工具调用觉醒

2023 年末到 2024 年：第二代，工程化工作流

2024 到 2025 年：第三代，Computer Use 进入真实界面

2025 到 2026 年：第四代，MCP、Skills 和常驻数字员工

2026 之后：第五代前瞻，闭环、内在记忆和世界模型

这条时间线背后的六条规律

真正的护城河

最后

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

它能做什么

使用前需要什么

Codex 手机远程访问的限制

怎么连接

手机端适合干什么

常见问题

适合哪些场景

我的判断

参考资料

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

最新可用范围

它会保存哪些文件

怎么把文件加入新对话

怎么查找和管理

各计划容量

单文件限制

删除和下载

Temporary Chat 不会保存文件

数据和训练设置

适合怎么用

我的判断

参考资料

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

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

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

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

价格与可用性

对开发者意味着什么

也要注意安全和告知

总结

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

快速对比

GPT-5.5 是什么

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

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

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

工具支持有什么不同

上下文窗口有什么区别

怎么选

日常问答

写文章、总结、改邮件

写代码和调试

研究和资料分析

需要图像生成、Canvas、Memory

简短结论

相关链接

ChatGPT、Claude Code 和 Gemini 的记忆机制有什么不同？

ChatGPT：围绕人的长期偏好

Memory Sources：让个性化来源更可见

Claude Code：围绕代码库和工程规则

Claude Code Auto Memory：自动积累项目经验

Gemini：围绕 Google 生态上下文

三者核心差异

该怎么选择和使用

1. 日常对话：为什么很多人还是先打开 `ChatGPT`

2. 命令行编程和长任务：为什么很多人更偏向 `Claude`

3. `Gemini` 的优势往往不在“和别人正面拼一切”