new-provider

# 新增 Provider 工作流 ## 这个 skill 在做什么 cc-router 的 Provider 抽象 = 「YAML 描述符」。把一个新厂商接入路由层不需要写 Rust——只需要一份遵循 `providers/_schema.json` 的 YAML，加上 4 处机械同步改动（bundle resources / 测试白名单 / README / 可选图标）。 这份 skill 的价值在于： 1. **决策清单**：哪些字段是「研究上游文档才能填对」的关键字段（auth、base_url、/models 端点） 2. **同步检查清单**：5 处改动一处不漏（漏一处会导致 release 包加载失败 / 测试断言失败 / 文档失同步） 3. **常见陷阱**：哪些上游 API 设计会让默认假设崩塌（无 /models、key 被忽略、messages 与 /models 不同域） ## 触发条件 走本 skill 当且仅当用户在 cc-router 仓库内做「新增 provider」类工作。如果只是改既有 YAML 字段（如调 endpoint 顺序、改 description）则不必走完整流程，直接编辑即可。 ## 五步工作流（顺序执行） ### Step 1：研究上游文档，决定 YAML 字段 **先查清楚 6 件事**（用 WebFetch 或问用户）： | 字段 | 关键问题 | |---|---| | `endpoints[].base_url` + `messages_path` | Anthropic 兼容端点完整 URL？是否多区域/多 endpoint？ | | `auth.header_format` | `x-api-key` raw（仅 Anthropic 系）还是 `Authorization: Bearer`？ | | `auth.header_name` | 多数家是 `Authorization`，少数是 `x-api-key`/自定义 | | `required_headers` | 是否要 `anthropic-version`？是否要其他厂商专属 header？ | | `model_discovery` | 是否有 Anthropic 风格 `/v1/models` 端点？路径？是否与 messages **同域**？需要独立 URL 时用 `model_discovery.url` 字段（完整 URL 覆盖，不走 base_url 拼接） | | 是否需 API Key | 极少数厂商（如 Ollama 本地）不校验 key——仍要保留字段，文档里说明 | **判断 `compatibility` 字段**： - `verified`：自己跑通过实际请求 + SSE 流式 - `partial`：有限制（如无 /models、流式有兼容 quirks） - `untested`：仅按文档接入未实测 ### Step 2：写 YAML 文件 **位置**：`src-tauri/providers/<id>.yaml` **id 命名**：小写英文/数字/下划线（schema 强制 `^[a-z0-9_]+$`）。优先用厂商英文短名（`anthropic`、`deepseek`、`zhipu`），不要带版本号或地域后缀。 **模板骨架**： ```yaml id: <provider_id> display_name: "<厂商展示名>" icon: "" #...