判斷功能成熟度
說明 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。
- 是否進入預設流程。
- 回退路徑。
這能避免團隊成員各自根據印象判斷“能不能用”。當官方說明或本地驗證結果變化時，只更新這份清單。