8月26日 o3 从 ChatGPT 下线：别急着改 API，你真正要检查的是这 6 类使用习惯

文章摘要

OpenAI 已确认：o3 将在 2026 年 8 月 26 日从 ChatGPT 退役。这次变化只影响 ChatGPT 中的模型选择，OpenAI 官方同时明确说明，API 不受此次退役影响。

所以如果你只是后端通过 API 调用 o3，不需要因为 8 月 26 日这个日期立刻改代码。真正容易出问题的，是团队把 ChatGPT 中的 o3 当成固定工作流的一部分：长期项目依赖某个模型风格、内部 SOP 截图指定模型、培训材料要求员工选择 o3、提示词只在 o3 上验证、自动化流程默认人工从 ChatGPT 复制结果。

这篇不讨论“o3 和新模型谁更强”，只做一件事：把 8 月 26 日之前值得检查的地方列清楚。

先把最重要的一句放前面：

ChatGPT 中的 o3：2026-08-26 退役
OpenAI API：此次公告明确说不受影响

这是两个完全不同的问题。

很多文章会把“ChatGPT 模型下线”写成“API 马上不可用”，这是不准确的。

1. 团队 SOP 里直接写了“选择 o3”

很多内部操作文档会这样写：

1. 打开 ChatGPT
2. 模型选择 o3
3. 上传合同
4. 输入以下提示词
5. 导出结果

这类 SOP 到 8 月 26 日以后就会失效。

真正应该改的是：

从“指定某个模型名字”
改为
“指定任务所需能力和验证标准”

例如：

旧：请选择 o3

新：请选择当前可用的高推理模型，
要求支持文件分析，并完成以下核验步骤……

这样下一次模型变化时不用再次重写整套 SOP。

2. 只在 o3 上测过的 Prompt

提示词的迁移风险经常被低估。

同一段 Prompt 换模型后可能出现：输出更短、更主动调用工具、不再遵循某个隐含格式、推理程度变化、拒绝策略不同、长上下文处理不同。

别只做：

o3 → 新模型

然后肉眼看两三个结果。

最少应该建立一个 30—50 条的小型回归集：

case_id,input,expected_points,forbidden_errors
001,...,...,...
002,...,...,...

每个 Prompt 至少检查：

必须包含的信息
不能出现的错误
结构
数字
引用
长度

3. 长期项目依赖了 o3 的“回答手感”

一个研究项目持续三个月，团队一直用同一模型生成市场分析、周报、研究摘要和风险清单。突然换模型后，内容风格和判断边界可能变。

这不一定是质量下降，但会破坏：

前后可比性

建议从现在开始保存：

Prompt Version
Model
任务日期
输入文档版本
输出
人工修改

下一次模型切换，至少知道差异来自哪里。

4. 培训材料和录屏

这是最容易忘的一类。

检查：内部知识库、培训 PPT、新员工教程、FAQ、视频、操作截图、客服话术、公众号教程。

如果页面里直接显示“点击 o3”，用户在 8 月 26 日后会找不到。

这类内容最好提前更新，而不是等模型真的消失以后再处理。

5. 人工把 ChatGPT 当成生产链路的一部分

有些所谓“自动化”其实是：

系统导出数据
→员工打开 ChatGPT
→选择 o3
→粘贴
→复制结果
→回填系统

严格说这不是 API 集成，但已经是一条生产流程。

这类流程要评估：数据是否允许上传、模型变化是否影响结果、输出是否有人工核验、是否需要迁到 API、是否记录版本。

如果每天几十次以上，我会优先把它正规化，而不是继续依赖人工选模型。

6. 把 ChatGPT 下线和 API 生命周期混在一起

这一点值得单独强调。

OpenAI 官方公告明确写了：此次变化适用于 ChatGPT，不涉及 API。

所以后端工程师最不该做的，是因为看到“o3 8 月 26 日退役”，当天紧急修改所有 API 调用。

正确理解是：

ChatGPT 产品退役公告
≠
API 模型弃用公告

API 是否需要迁移，要看 API 官方模型生命周期和 deprecation 通知。

我建议今天就建一张迁移表

* 这里只表示这次 ChatGPT 公告没有宣布 API 同步下线，不代表 API 永久不会变化。

Prompt 迁移别只比“像不像旧模型”

更有用的是比较：

任务是否仍然完成？
关键事实是否保留？
错误率是否变化？
成本是否变化？
人工修改量是否变化？

迁移记录可以这么做：

{
  "case_id": "contract-017",
  "old_model": "o3",
  "candidate_model": "new-model",
  "required_points_passed": 8,
  "required_points_total": 9,
  "critical_error": false,
  "human_edit_minutes": 4.5
}

我很建议加 human_edit_minutes。很多模型自动评分差不多，但真正交给人以后，修改成本差很多。

8 月 26 日当天不要做什么

不要临时才通知团队，不要只换模型名不回归，不要把 API 和 ChatGPT 混为一谈，也不要为了保持“旧风格”加入大量复杂 Prompt。

真正需要保留的是业务结果，不是某个模型的语言习惯。

模型产品正在变得越来越像浏览器或云服务：版本会更新、旧版本会退出、能力会迁移、价格会变化。

如果企业流程把某个模型名字写死在 SOP、Prompt、培训、测试和人工操作里，迟早还会再经历一次同样的迁移。

这次 o3 从 ChatGPT 退役，更值得做的不是“换成谁”，而是把流程从：

依赖模型名字

改成：

依赖能力契约＋回归测试

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/