README 说「50+ 预设」，八个预设文件里数出来 448 条
想知道 CC Switch 里到底内置了多少个供应商预设，你会在同一个仓库里拿到三个互不相同的答案：README 说「50+」，用户手册的预设表格每张只有几行到三十几行，而 src/config/ 下八个应用预设数组逐条数出来是 448 条。
这三个数出现在三个不同位置：README、用户手册、src/config/ 下的预设数组。这篇不去猜哪个「才是对的」——按我们的纪律，说完差异就停。真正有用的是：你自己怎么在两分钟内把这个数重新数一遍，以及 448 这个数到底在数什么、不在数什么。
以下全部基于我们本地 clone 的 cc-switch 仓库快照 c39c903（提交日期 2026-08-10），仓库内版本号 3.19.2。我们只读源码文本，没有安装也没有运行过这个桌面应用。
三层口径，各自在哪一行
第一层是 README。英文 README.md 有三处写到「50+」这个量级：README.md:202 写的是 “50+ built-in provider presets”，:205 与 :224 两处同样落在「50+ 预设」这个说法上，其中 :224 那行还把它和支持的工具数并列成一条卖点；中文 README_ZH.md 对应三处同义（README_ZH.md:203、:206、:225）。这三处都出现在功能特性与卖点的位置上。
第二层是用户手册。docs/user-manual/zh/2-providers/2.1-add.md 里按应用分别给了预设表格，我们用 Python 逐行统计以 | 开头且不是分隔行的行数：Claude 表 27 行、Codex 表 24 行、Gemini 表 7 行、OpenCode 表 26 行、OpenClaw 表 31 行（分别位于该文件 :25、:69、:109、:121、:154）。手册自己在表旁加了一句免责：预设列表可能随版本更新，以应用内实际显示为准。
第三层是代码。src/config/ 下八个应用的预设数组，逐个数条目：
| 数组 | 条目数 | 定义位置 |
|---|---|---|
providerPresets（Claude Code） | 72 | src/config/claudeProviderPresets.ts:76 |
codexProviderPresets | 67 | src/config/codexProviderPresets.ts:112 |
claudeDesktopProviderPresets | 69 | src/config/claudeDesktopProviderPresets.ts:140 |
hermesProviderPresets | 61 | src/config/hermesProviderPresets.ts:131 |
openclawProviderPresets | 60 | src/config/openclawProviderPresets.ts:101 |
opencodeProviderPresets | 60 | src/config/opencodeProviderPresets.ts:288 |
grokBuildProviderPresets | 37 | src/config/grokBuildProviderPresets.ts:79 |
geminiProviderPresets | 22 | src/config/geminiProviderPresets.ts:35 |
| 合计 | 448 | — |
这张表的读法是：每一行对应一个「应用」的预设列表，也就是你在 CC Switch 里选中某个工具之后，那个工具能挑的预设集合。八个加起来 448。作为体量参照，src/config/ 全目录 15 个文件用 wc -l 数出来是 12049 行，其中最大的 openclawProviderPresets.ts 一个文件就 2554 行。
这 448 是怎么数出来的，以及一个会数错的坑
条目数不能直接 grep 花括号，因为预设文件里嵌套结构很深（settingsConfig、theme、templateValues 里全是对象）。我们的做法是写一个花括号深度解析器：先剥掉 // 与 /* */ 注释和字符串字面量，再从 export const <数组名> ... = [ 开始扫描，只统计深度为 0 的 { 个数，也就是数组的顶层对象字面量。
交叉校验用的是另一条完全独立的路径：
grep -c '^ name: ' src/config/claudeProviderPresets.ts
四空格缩进的 name: 恰好只出现在顶层条目上，两种方法结果一致，才敢把这个数写出来。
坑在这里：早期没有剥注释的版本会把注释行当成字段。src/config/codexProviderPresets.ts:1440 有一行形如 // store:false / ... 的注释，未剥注释时会被误判成一个 store 字段，字段统计随之虚高；剥掉注释后它就消失了。本文所有数字都取剥注释之后的口径。你要自己复现，这一步别省——至少 src/config/codexProviderPresets.ts:1440 这一行注释就长得像个配置字段，未剥注释就会把它数进去。
还有一个数值得顺手确认：grep -c 'hidden: true' src/config/*.ts 在八个预设文件里全部为 0。ProviderPreset 接口里确实有 hidden 这个字段（src/config/claudeProviderPresets.ts:69-70，语义是预设仍存在但不在列表显示），但当前一条都没用上。也就是说，448 不需要再减去任何「定义了但被藏起来」的条目。
448 在数什么，不在数什么
想把这个数用对，得先框定它的边界，这三条容易被忽略：
第一，448 只统计八个「应用预设数组」。 src/config/ 下还有若干别的数组，它们不属于供应商预设，也没被计进去：universalProviderPresets 2 条（src/config/universalProviderPresets.ts:61）、mcpPresets 5 条（src/config/mcpPresets.ts:31）、CODING_PLAN_PROVIDERS 6 条（src/config/codingPlanProviders.ts:21）、USER_AGENT_PRESETS 5 条字符串（src/config/userAgentPresets.ts:14）、opencodeNpmPackages 5 条、openclawApiProtocols 5 条。它们各有各的用途，和「你能一键导入哪个供应商」不是一回事。
第二，有一条预设根本不在数组里。 Grok Build 的官方条目是数组之外的一个单独常量 grokBuildOfficialPreset（src/config/grokBuildProviderPresets.ts:46），数组本身是 37 条。所以按「预设定义总数」（数组 37 条 + 数组外那个官方常量 1 条）去数是 38，按「数组长度」去数是 37。我们表里取的是数组口径，这也是 448 的口径。这类边界差一条的情况，正是不同的人数出不同结果的来源。
第三，也是最要紧的一条：448 是「条目数」，不是「供应商家数」。 八个数组是按应用各自维护的，同一个上游完全可能在多个应用的预设文件里各有一条。去重之后还剩多少家？我们没有依据，不比。 采集这批事实时我们刻意没有逐条读取预设条目的具体内容（名称、域名、模型 id 都没采），所以给不出去重后的家数，也无法把它和 README 里赞助商板块的条目数对上。谁要是拿 448 去说「支持 448 家供应商」，那是把两件事混成一件了。
顺带一提，README 里有独立的赞助商板块，这是该项目商业模式的一部分。本文只统计结构与数量，不涉及其中任何一家的名字、链接与文案——那些是广告，不是我们核实过的事实，也不在本文的讨论范围内。
手册那一层，还漏了两个应用
回到第二层。手册表格行数与代码条目数的差距是逐个应用都存在的：Claude 27 行对 72 条，Codex 24 行对 67 条，Gemini 7 行对 22 条，OpenCode 26 行对 60 条，OpenClaw 31 行对 60 条。
更值得注意的是手册里压根没有 Hermes 与 Grok Build 的预设表。我们在 docs/user-manual/zh/2-providers/2.1-add.md 里 grep “Hermes” 只有 2 次命中，且都不是预设表；在整个 docs/user-manual/zh/2-providers/ 目录下 grep “Grok” 是零命中。而代码里 Hermes 有 61 条、Grok Build 有 37 条。
同一目录里还有一处相关的口径差：手册 2.1 开头把「仅用于当前选中的应用」的清单写成 7 个（docs/user-manual/zh/2-providers/2.1-add.md:8），而 README 与代码都是 8 个（README.md:224；src/types.ts 的 VisibleApps 含 grokbuild）。工具清单这件事本身另有一篇专门在讲，这里只说它和预设表的缺失是同一个方向上的差异。
所以你该怎么用这几个数
如果你的问题是「我用的那个上游在不在预设里」，那么 README 的「50+」和手册的表都不是可靠入口——直接去对应应用的预设数组里搜。你用 Claude Code 就打开 src/config/claudeProviderPresets.ts，用 Codex 就打开 codexProviderPresets.ts，八个应用各是各的文件，一个应用里有的预设，另一个应用里未必有。这也是为什么 448 是八个数字相加而不是一个全局列表的长度。
如果你的问题是「这个仓库的预设体量有多大」，448 加上 12049 行的 src/config/ 大概能给你一个量级感。但请把时间锚点带上：这是 2026-08-10 我们读到的 c39c903 快照的数字。预设条目数是随版本变动的内容，手册自己也在表旁写了「预设列表可能随版本更新，以应用内实际显示为准」（docs/user-manual/zh/2-providers/2.1-add.md），你重新 clone 之后要以自己数出来的为准。能复用的不是这个数，是上面那套数法。
最后重复一遍分寸：这三层口径不一致是可核实的事实，我们把每一处的文件与行号都标了出来，你可以自己去核。至于哪一处「才算数」、为什么会这样，本文不做推断，也不拿它去评价这个项目——数完就停。
本文依据 CC Switch 官方仓库（github.com/farion1231/cc-switch）的 README、docs/ 下的用户手册与发布说明、
src/config/ 的预设定义与 src-tauri/src/ 的后端源码整理，核对日 2026-08-10，对应仓库快照 c39c903。
本文内容为仓库源码与文档口径，我们没有安装或运行过这个桌面应用，
因此不涉及界面外观、操作手感与切换速度的任何描述。
文中出现的阈值与默认值均为源码中的默认配置，不构成对实际运行结果的保证。
该项目仍在快速迭代，版本与默认值随时可能变动，请以仓库最新内容为准。