---
title: "判断功能成熟度"
description: "说明 Codex feature maturity label 的含义，以及如何判断实验功能是否适合生产流程。"
verifiedAt: "2026-05-07"
---

部分 Codex features 会带有 maturity label。这个 label 用来说明该 feature 的可靠程度、可能变化的范围，以及你可以期待的 support level。

> [!WARNING]
> Maturity label 本身也会变化。团队文档里不要只写“官方支持”，要记录核验日期、官方链接、入口范围、回退路径和本团队验证结果。

不要把所有“官方出现过的功能”都当成生产能力。对新手来说，feature maturity 的价值是帮助你判断：这个功能能不能写进团队默认流程，还是只适合个人试验。

| Maturity | 含义 | 使用建议 |
|---|---|---|
| Under development | 尚未准备好投入使用。 | 不要使用。 |
| Experimental | 不稳定，OpenAI 可能移除或变更。 | 自行承担使用风险。 |
| Beta | 已可进行 broad testing；大部分能力完整，但部分细节可能根据 user feedback 调整。 | 适合大多数 evaluation 和 pilots；预期会有小变化。 |
| Stable | 完整支持，有正式文档，适合 broad use；behavior 和 configuration 会保持长期一致。 | 可以用于 production；移除通常会经过 deprecation process。 |

## 怎么判断能不能用于团队流程

可以按四个问题判断：

1. 官方文档是否给了清晰入口和行为说明。
2. 失败时是否有可诊断的错误信息。
3. 是否能在你的项目里重复验证。
4. 功能变化会不会影响安全、成本或发布流程。

如果某个功能仍是 Experimental，就不要把它写成团队默认 SOP。可以建一个小范围试验：只在个人项目、非关键任务或 dry-run 流程里使用，并把失败条件记录下来。

Beta 功能可以进入 pilot，但要保留替代路径。比如某个集成能提高效率，但一旦失败仍然能退回 CLI、IDE 或手动流程。

Stable 功能才适合写入团队文档、培训材料和默认配置。即便如此，涉及权限、联网、自动审批、CI/CD 或生产环境的能力，也要先经过安全和回滚检查。

## 生产采用分级

团队内部可以把官方 label 再映射成自己的采用级别：

| 官方 label | 团队默认动作 | 是否写进 SOP |
|---|---|---|
| Under development | 禁止默认使用，只能跟踪文档变化。 | 不写。 |
| Experimental | 个人试验或隔离 sandbox，必须有回退。 | 只写“试验记录”。 |
| Beta | 小范围 pilot，有 owner 和复盘日期。 | 可写 pilot SOP。 |
| Stable | 可进入默认流程，但仍需权限和成本审查。 | 可写正式 SOP。 |

这个映射的重点是避免“官方文档里有”直接等于“团队必须采用”。Codex 的入口很多：CLI、IDE extension、Codex app、Cloud、remote connections、plugins、subagents、automations。某个能力在一个入口可用，不代表另一个入口同样成熟。

## 试验记录模板

评估一个新功能时，建议记录：

```text
功能：
官方 label：
官方链接：
核验日期：
适用入口：
本地版本或账号计划：
成功路径：
失败路径：
权限影响：
成本影响：
回退方式：
是否进入默认流程：
下一次复查日期：
```

尤其要写“失败路径”。一个功能跑通一次只能证明它可用，不能证明它适合进入团队默认流程。只有失败时能诊断、能回退、能避免扩大权限，才有生产采用价值。

## 新手常见误判

- 看到 release notes 提到某功能，就默认它已经适合生产。
- 把“能跑通一次”当成“可以让团队长期依赖”。
- 忽略功能所在入口：App、CLI、IDE、Cloud 的成熟度和可用范围可能不同。
- 忽略配额、定价、权限和数据边界这些非功能因素。

## 推荐记录方式

团队可以为关键能力维护一份简短清单：

- 功能名称。
- 当前 maturity label。
- 官方资料链接。
- 本团队验证日期。
- 适用入口：App、CLI、IDE、Cloud 或 API。
- 是否进入默认流程。
- 回退路径。

这能避免团队成员各自根据印象判断“能不能用”。当官方说明或本地验证结果变化时，只更新这份清单。

## 官方资料

- [Feature Maturity](https://developers.openai.com/codex/feature-maturity)
- [OpenAI Codex release notes](https://developers.openai.com/codex/changelog)
- [OpenAI Codex overview](https://developers.openai.com/codex)

## 接下来去哪

<Cards>
  <Card title="版本与迁移" description="maturity 或功能状态变化时，回 changelog 判断影响范围。" href="/docs/codex/official/09-versions" />
  <Card title="模型与用量" description="模型、价格、用量和功能可用性都要回官方核验。" href="/docs/codex/official/04-model-pricing/15-pricing-usage" />
  <Card title="团队生产落地" description="进入默认团队流程前，先设计安全、审查和回退路径。" href="/docs/codex/understanding/team-production" />
  <Card title="官方 Changelog" description="功能状态和迁移说明以官方 changelog 为准。" href="https://developers.openai.com/codex/changelog" />
</Cards>
