判断功能成熟度
说明 Codex feature maturity label 的含义，以及如何判断实验功能是否适合生产流程。
部分 Codex features 会带有 maturity label。这个 label 用来说明该 feature 的可靠程度、可能变化的范围，以及你可以期待的 support level。
Maturity label 本身也会变化。团队文档里不要只写“官方支持”，要记录核验日期、官方链接、入口范围、回退路径和本团队验证结果。
不要把所有“官方出现过的功能”都当成生产能力。对新手来说，feature maturity 的价值是帮助你判断：这个功能能不能写进团队默认流程，还是只适合个人试验。
| Maturity | 含义 | 使用建议 |
|---|---|---|
| Under development | 尚未准备好投入使用。 | 不要使用。 |
| Experimental | 不稳定，OpenAI 可能移除或变更。 | 自行承担使用风险。 |
| Beta | 已可进行 broad testing；大部分能力完整，但部分细节可能根据 user feedback 调整。 | 适合大多数 evaluation 和 pilots；预期会有小变化。 |
| Stable | 完整支持，有正式文档，适合 broad use；behavior 和 configuration 会保持长期一致。 | 可以用于 production；移除通常会经过 deprecation process。 |
怎么判断能不能用于团队流程
可以按四个问题判断：
- 官方文档是否给了清晰入口和行为说明。
- 失败时是否有可诊断的错误信息。
- 是否能在你的项目里重复验证。
- 功能变化会不会影响安全、成本或发布流程。
如果某个功能仍是 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。某个能力在一个入口可用，不代表另一个入口同样成熟。
试验记录模板
评估一个新功能时，建议记录：
功能：
官方 label：
官方链接：
核验日期：
适用入口：
本地版本或账号计划：
成功路径：
失败路径：
权限影响：
成本影响：
回退方式：
是否进入默认流程：
下一次复查日期：尤其要写“失败路径”。一个功能跑通一次只能证明它可用，不能证明它适合进入团队默认流程。只有失败时能诊断、能回退、能避免扩大权限，才有生产采用价值。
新手常见误判
- 看到 release notes 提到某功能，就默认它已经适合生产。
- 把“能跑通一次”当成“可以让团队长期依赖”。
- 忽略功能所在入口：App、CLI、IDE、Cloud 的成熟度和可用范围可能不同。
- 忽略配额、定价、权限和数据边界这些非功能因素。
推荐记录方式
团队可以为关键能力维护一份简短清单：
- 功能名称。
- 当前 maturity label。
- 官方资料链接。
- 本团队验证日期。
- 适用入口：App、CLI、IDE、Cloud 或 API。
- 是否进入默认流程。
- 回退路径。
这能避免团队成员各自根据印象判断“能不能用”。当官方说明或本地验证结果变化时，只更新这份清单。