---
title: "查看版本更新脉络"
description: "用 Codex changelog 核验版本、模型、入口、集成和安全能力的当前状态，而不是复制静态更新表。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

Codex changelog 适合用来确认功能何时上线、哪些入口受影响、CLI / App 行为是否变化，以及模型、MCP、skills、plugins、GitHub / Slack / Linear 等能力的演进边界。

本页不复制完整更新表。Changelog 是高波动信息，静态搬运很快会过期。

> [!IMPORTANT]
> 任何“最新版”“当前模型”“某功能是否可用”的判断，都必须回到官方 changelog、当前客户端和对应官方文档核验。不要用旧教程里的版本表做最终依据。

<Cards>
  <Card title="Codex Changelog" href="https://developers.openai.com/codex/changelog">
    查看 Codex 全量更新记录和官方筛选入口。
  </Card>
  <Card title="Models" href="https://developers.openai.com/codex/models">
    核验模型可用性、入口和能力说明。
  </Card>
  <Card title="Feature Maturity" href="https://developers.openai.com/codex/feature-maturity">
    理解 Stable、Beta、Experimental 等成熟度标签。
  </Card>
</Cards>

## Changelog 适合解决什么问题

```mermaid
flowchart TB
    Question["你要确认的问题"]
    Version["版本行为<br/>CLI / App / IDE"]
    Model["模型可用性"]
    Feature["功能上线和成熟度"]
    Integration["GitHub / Slack / Linear / MCP"]
    Security["sandbox / approval / governance"]
    Official["官方 changelog + 对应文档"]

    Question --> Version
    Question --> Model
    Question --> Feature
    Question --> Integration
    Question --> Security
    Version --> Official
    Model --> Official
    Feature --> Official
    Integration --> Official
    Security --> Official
```

常见用途：

- 判断某个 CLI 行为是否来自版本更新。
- 判断 App、IDE、Cloud 的某个入口是否支持某功能。
- 核验模型上线、下线、默认值或入口差异。
- 查找 security、sandbox、approval、MCP、skills、plugins 的变更背景。
- 为教程更新提供事实来源。

不要把 changelog 当入门教程。它是事实核验入口。

## 怎么读

第一步：先确定问题属于哪一类。

- CLI 命令或 TUI 行为。
- App 桌面功能。
- IDE extension。
- Cloud / Web。
- 模型和推理。
- 集成和自动化。
- 安全、治理、权限。

第二步：在 changelog 中按类型或关键词筛选。

第三步：找到更新项后，不要停在 changelog 摘要，继续打开对应正式文档。

第四步：在本机或当前入口验证。

例如 CLI 行为，应同时看：

```bash
codex --version
codex --help
codex <subcommand> --help
```

如果是 App 或 IDE 功能，应检查当前客户端版本和设置页。

## 不要复制静态版本表

教程中不建议长期保存：

- 每月 changelog 表。
- 每个 CLI release 的完整安装命令。
- 旧模型切换命令。
- 入口上线日期。
- 临时灰度说明。
- 短期活动、计划、额度变化。

这些信息应该链接官方页面，而不是成为教程正文的稳定内容。

更好的写法是：

- 说明如何查。
- 说明怎么判断是否影响自己。
- 说明如何在当前客户端验证。
- 给出官方入口。

## 版本核验流程

```mermaid
flowchart LR
    Need["需要确认某功能"] --> Changelog["查官方 Changelog"]
    Changelog --> Docs["打开对应正式文档"]
    Docs --> Local["检查当前客户端或配置"]
    Local --> Decision["形成结论"]
```

示例：

```text
我要确认某个 CLI 参数是否存在。
1. 查 changelog 看是否有相关变更。
2. 查 CLI features 或 command line options。
3. 本机运行 codex --help 或子命令 --help。
4. 只在三者一致时写进教程。
```

## 写教程时如何引用 changelog

推荐写法：

```text
这类能力更新较快，具体可用性以官方 changelog 和当前客户端为准。
如果你需要确认某个入口是否支持该功能，先查 changelog，再查对应产品页。
```

不推荐写法：

```text
某年某月某日之后，所有用户都应该使用 X。
```

除非这是官方长期稳定政策，否则不要把时间点写成永久判断。

## 与本站文档的关系

Changelog 用来核验事实，本站文档用来解释怎么用。

优先级：

1. 官方 changelog：确认变化发生过。
2. 官方产品文档：确认当前正式行为。
3. 当前客户端：确认你账号和环境可用。
4. 本站教程：解释如何理解和落地。

如果四者冲突，以官方当前文档和当前客户端为准，再更新本站教程。

## 更新本站教程的检查清单

当 changelog 出现相关变化时，检查：

- 是否影响模型选择页。
- 是否影响 pricing / usage 页。
- 是否影响 CLI 参数或 slash commands。
- 是否影响 sandbox、approval、security。
- 是否影响 MCP、skills、hooks、plugins。
- 是否影响 App、IDE、Cloud 的入口说明。
- 是否需要更新工作流和审计规则。

Changelog 的价值不是让读者背版本，而是让教程维护者知道哪些事实需要重新核验。

## 团队维护建议

商业团队可以把 changelog 审查放进月度文档维护，而不是每次看到新功能就立刻改教程。先判断变化是否影响当前教学路径，再决定更新哪一页。只影响少数高级用户的实验能力，可以先记录在维护清单；影响安装、权限、默认模型、计费、安全边界或主要入口的变化，才应该优先更新正文。

每次更新教程时，保留判断过程比复制更新条目更有价值。维护者应写清楚变化影响哪个入口、是否已经在当前客户端验证、是否需要改截图、是否会改变推荐工作流。这样下一次再看 changelog 时，不会重复判断同一个问题。
