宿主兼容性不是并列：四个宿主其实是一组包含
四个宿主各测 161 个 server，装得上的却是 95、95、40、37。把四份都测过的 126 个抽出来做同分母比较，反向格几乎为零：claude-code 能过而 gemini-cli 与 qoder 过不了的各有 55 与 57 格，反过来一格都没有。宿主列不是并列评分，是一组包含。
宿主兼容性不是并列：四个宿主其实是一组包含
兼容表横着排五个宿主，看上去是五个独立的评分列。但把它们逐格对齐之后，会发现一件事：这些列并不是并列的，方向是单向的。
口径先说清楚。数据取自子站的五份分宿主采集文件，生成时间分别是 claude-code 2026-11-01T19:32Z、opencode 2026-10-29T09:48Z、gemini-cli 2026-11-01T20:25Z、qoder 2026-11-01T22:04Z、codebuddy 2026-11-01T04:41Z，五份都是 mode=full。五份文件合计 754 格。本文每个数字都是 2026-11-02 在原始 JSON 上现场重算的。想先看宿主能力字段本身，打开宿主能力对照页；想知道这些格子怎么被判定出来，见判定方法。
先把「同分母」做实
四份文件都写着 161 个 server，看着像同一批，实际不是。逐份求交集才看得出结构：claude-code 与 gemini-cli 的交集是 161，claude-code 与 qoder 也是 161，gemini-cli 与 qoder 同样是 161 —— 这三份是同一批 161 个。opencode 与它们只交集 126，另带 35 个自己独有的。codebuddy 更小，与 claude-code 只交集 89。
| 文件 | server 数 | 与四份交集的交集 | CLI 版本 |
|---|---|---|---|
| claude-code | 161 | 126 | 2.1.311 |
| opencode | 161 | 126 | 1.19.4 |
| gemini-cli | 161 | 126 | 0.66.0 |
| qoder | 161 | 126 | 1.1.80 |
| codebuddy | 110 | 89 | 2.177.1 |
所以能放心比的只有 126 个。codebuddy 因为只交集 89，本轮退出这个比较 —— 拿 110 个的分母去和 161 个的分母排名次，是把两个不同的样本硬拼在一起。
一个必须同时说明的事：这四份不是同一时刻采的。opencode 停在 10-29，其余三份在 11-01 到 11-02 之间，最长相隔四天。下面所有差异里都混着这个时间差，不能全部算到宿主头上。
装得上：95、95、40、37
在 126 个同分母 server 上，install 阶段判 pass 的数量是这样：
- claude-code 95
- opencode 95
- gemini-cli 40
- qoder 37
2026-11-02 在原始 JSON 上实测重算，这四个数对应 123 个有效格（另有 3 格是 na），通过率落在 77.2% 与 30.1% 之间。claude-code 与 opencode 恰好都是 95，一个不差。
这一步就能看出分层：两个宿主的安装通过数在 95，两个在 40 与 37。差距不是几个百分点，是两倍多。
用得了：93、91、38、36
再看 usable，也就是装完之后工具到底调不调得动：
| 宿主 | install pass | usable pass | usable fail | na |
|---|---|---|---|---|
| claude-code | 95 | 93 | 30 | 3 |
| opencode | 95 | 91 | 32 | 3 |
| gemini-cli | 40 | 38 | 85 | 3 |
| qoder | 37 | 36 | 87 | 3 |
同分母 126 个 server 上实测，usable 的通过数是 93、91、38、36，四个宿主合计失败 234 格。注意 install 到 usable 的损耗很小：claude-code 从 95 掉到 93，gemini-cli 从 40 掉到 38。真正拉开距离的是 install 那一步，不是装完之后的调用。
这条与直觉相反。多数人以为「装都装上了，用不了是另一回事」，数据说不是：卡在安装阶段的格子远多于装完调不动的格子。
反向格几乎为零，这才是关键
真正的发现在交叉表里。把两两之间「A 过、B 不过」与「A 不过、B 过」两种格子分别数出来。126 个同分母 server 上实测，六组比较里反向格最多的只有 2 格：
| 比较 | A 过 / B 不过 | A 不过 / B 过 |
|---|---|---|
| claude-code → gemini-cli | 55 | 0 |
| claude-code → qoder | 57 | 0 |
| opencode → gemini-cli | 55 | 2 |
| opencode → qoder | 56 | 1 |
| claude-code → opencode | 4 | 2 |
| gemini-cli → qoder | 3 | 1 |
claude-code 对 gemini-cli 是 55 比 0，对 qoder 是 57 比 0。install 层更干净：claude-code 对 gemini-cli 55 比 0，对 qoder 58 比 0，opencode 对这两个也都是 55 比 0 与 58 比 0。
零反向意味着包含。claude-code 能过的集合，把 gemini-cli 能过的整个装进去了，还多出 55 个。这不是「两个宿主各有所长」，是一个套着另一个。
只有同一级内部才有来回：claude-code 与 opencode 之间是 4 比 2，gemini-cli 与 qoder 之间是 3 比 1。两边都在个位数，方向可以互有胜负。
于是四个宿主不是一个梯队，是两级：claude-code 与 opencode 在一级，gemini-cli 与 qoder 在另一级，中间隔着 55 格以上。举个具体样本，server-everything 这个协议参考实现在前三个宿主是 install 与 usable 双 pass，在 gemini-cli 与 qoder 都是双 fail —— 它就是那 52 个台阶格里的一员。
52 个台阶格说明什么
126 个 server 按四宿主的通过形态归堆，只有十种组合：
| 形态（claude / opencode / gemini / qoder） | 个数 |
|---|---|
| 过、过、不过、不过 | 52 |
| 全过 | 34 |
| 全不过 | 28 |
| 未判定、未判定、未判定、未判定 | 3 |
| 其余六种零散形态 | 9 |
52 个格子落在「前两个过、后两个不过」这一种形态上，占 126 的 41%。加上全过的 34 与全不过的 28，三种形态已经覆盖 90%。剩下九格才是真正的零散。
这也解释了为什么「换一个宿主再试试」经常有效，而且效果可预测：如果你在 gemini-cli 上撞了墙，换到 claude-code 有相当概率能过；反过来从 claude-code 换到 gemini-cli，基本是把能跑的换成了不能跑的。方向是固定的，不是掷骰子。
这些话不能说
第一，不能据此给宿主排名次。方向是单向的，但原因没有取到。checks.note 在这个采集里是通用文案，上百个失败格共用同一句「这个平台用不了它，原因见上方说明」，它只说失败，不说是哪一步失败。没有错误码，就没有归因。
第二，不能把差异全算给宿主实现。四份文件跨了四天，中间宿主自己发过新版，采集机也可能换过环境。想坐实「是宿主 A 的实现更好」，需要同一天、同一台机器、同一 CLI 版本的对照，这份数据没有提供。
第三，不能把这 126 个当成全集。161 个里每个宿主都有自己没测到的部分，opencode 独有 35 个，codebuddy 少测 72 个（全是 stdio）。同分母是为了可比，不是为了完整。
三步用这张表
先看自己撞的是哪一级。在 gemini-cli 或 qoder 上失败的 server，先去 claude-code 或 opencode 的列上找同一行。那一行是 pass，说明大概率是宿主那一侧的问题，换宿主比改配置快；那一行也是 fail，才回去查 server 本身与命令行。
再分阶段。install 就是 fail 的，别去翻工具列表，问题在命令、包名、权限、本机运行时；install 是 pass 而 usable 是 fail 的，才轮到握手与工具注册。126 个里属于后者的只有十几格，前者是它的十倍量级。
最后核一遍分母。看到任何通过率，先确认它是在多少个 server 上算的、是不是同一个 mode、采集时间是不是同一天。任何一项对不上，比率之间的差就不能直接读成宿主差异。逐条读格子的入口在兼容矩阵，想看失败时最常撞的几类现象，见坑点清单。
一句话收口
五个宿主列看着是五个评分，对齐之后是一组包含关系：低的那一级能过的，高的那一级基本都过；高的能过的，低的有一半过不了。把它当排名读，会以为差距是程度问题；把它当包含读，才知道差距是方向问题 —— 这个方向决定了「换宿主」该往哪边换。
结论采集于 2026 年 11 月 2 日，实测方法见 数据怎么来的。