[codex] refresh integration and settings docs for current UI and provider coverage (#398)

* docs: refresh integration and settings guides

* docs: address review follow-up

docs/faq.md

@@ -6,35 +6,51 @@
 
 <a id="account-auth-guide"></a>
 
-## 账号认证方式与兼容性（Access Token / Cookie）
+## 账号认证方式与兼容性（Session / API Key / OAuth）
 
-### Q: Access Token 和 Cookie 有什么区别？优先用哪个？
+### Q: Access Token、Cookie、API Key、OAuth 应该选哪个？
 
-**A:** Metapi 支持两种 Session 凭证来源（都用于管理接口，如余额、签到等）：
+**A:** 现在最稳妥的判断方式不是只看“有没有 Token”，而是先看你接的是哪一类上游：
 
-| 凭证 | 特点 | 适用场景 |
+| 方式 | 特点 | 适用场景 |
 |------|------|----------|
-| **Access Token（系统访问令牌）** | 支持多账号、通常更稳定、更适合长期使用 | 标准 NewAPI / OneAPI / OneHub / DoneHub / Veloera 等站点 |
-| **Cookie（浏览器登录态）** | 兼容性强，但可能过期，且多账号体验较差 | 访问令牌不可用、魔改站点、特殊兼容场景 |
+| **Access Token（系统访问令牌）** | 稳定、适合长期使用、适合多账号 | 标准 New API / One API / OneHub / DoneHub / Veloera 等面板站 |
+| **Cookie（浏览器登录态）** | 兼容性强，但更容易过期 | Access Token 不可用、AnyRouter 一类魔改站点、特殊兜底场景 |
+| **API Key** | 最简单，适合代理调用 | OpenAI / Claude / Gemini 兼容入口、CPA、各类官方预设 |
+| **OAuth** | 不手填普通凭证，走浏览器授权 | Codex、Claude、Gemini CLI、Antigravity |
 
-> 结论：优先使用 **Access Token**。仅在站点不支持或令牌不可用时使用 Cookie。
+结论：
+
+1. 面板型站点优先 **Access Token**
+2. Access Token 拿不到时再考虑 **Cookie**
+3. 兼容接口、CPA、官方预设优先 **API Key**
+4. Provider 原生授权优先 **OAuth**
 
 ### Q: 在 Metapi 里怎么切换认证方式？
 
-**A:** 在「账号管理 → 添加账号 → Cookie / Token 导入」中：
+**A:** 入口已经分成两条：
 
-1. 选择站点
-2. 在「凭证模式」下拉选择：
-   - 自动识别（推荐）
-   - Session 模式（Access Token / Cookie）
-   - API Key 模式（仅代理）
-3. 粘贴凭证并点击「验证 Token」
+1. **普通站点**：在「账号管理 / API Key 管理」里选择 Session 或 API Key
+2. **OAuth provider**：在左侧「OAuth 管理」里完成授权
+
+如果你不确定该去哪一页，先看 [上游接入](/upstream-integration)。
 
 ### Q: 以 NewAPI 为例，Access Token 在哪里生成？
 
 **A:** 通常路径是：**控制台 → 个人设置 → 安全设置 → 系统访问令牌**。  
 如果你确实需要 Cookie 兜底，可在浏览器 `F12 → Application → Cookie` 获取对应登录态。
 
+### Q: 什么情况下应该直接走 OAuth？
+
+**A:** 当你接的不是一个普通面板站，而是 provider 自己的账号授权时：
+
+- Codex
+- Claude
+- Gemini CLI
+- Antigravity
+
+这时不要再把它当成“账号管理里的一条普通 Session”去处理，直接看 [OAuth 管理](/oauth)。
+
 ### Q: AnyRouter 这类魔改站点为什么更容易报错？
 
 **A:** AnyRouter 在 Metapi 中按 NewAPI 兼容站点处理，但不少实例会隐藏 Access Token 入口，或额外加登录盾。建议：
@@ -43,6 +59,10 @@
 2. 如果没有 Access Token 入口，或验证时被盾/认证页拦截，再改用 Cookie 导入
 3. 若返回 HTML 盾页错误，先在浏览器完成验证后再重新绑定
 
+### Q: CPA / CLIProxyAPI 应该怎么接？
+
+**A:** 这类站点现在走 `cliproxyapi` 平台类型，推荐直接加 API Key，不建议把它当成可签到、可登录的面板站。详细步骤见 [上游接入](/upstream-integration)。
+
 ### Q: Sub2API 站点怎么处理？
 
 **A:** Sub2API 常见 JWT 短期会话机制，和传统 NewAPI 站点差异较大。当前建议：
@@ -52,7 +72,7 @@
 3. Sub2API 通常为订阅制使用，不支持签到；如果你只关心代理调用，也可以直接改用 API Key 模式
 4. 若 `GET /v1/models` 为空，先确认该账号下已有可用用户 API Key，Metapi 会再尝试用它发现模型
 
-详细操作截图见 [上游接入 → Sub2API](./upstream-integration.md#sub2api)。
+详细操作说明见 [上游接入](/upstream-integration)。
 
 ## 部署相关