17 个宿主列，只有 11 份独立证据

17 个宿主列，只有 11 份独立证据

兼容性表的常见读法是横向看：哪个宿主 pass 多就用哪个。这个读法有一个前提——每一列都是独立观测。本站这次 full 采集恰好证明这个前提不成立：17 列逐格比对下来，只有 11 种不同的列形态。

口径先行。数据是子站 2026-10-29T09:48:50Z 生成的一次 mode=full 快照，161 个 server × 17 个宿主 = 2737 格，每格带 install 与 usable 两个判定字段。本文数字均为 2026-10-31 在原始 JSON 上重算，不引用任何汇编结论。要按宿主看能力约束，走宿主能力对照页。

先去重：17 列里只有 11 种形态

把每一列按「该宿主在 161 个 server 上的 install 与 usable 序列」做整体比对，相同即视为同形。

| 同形组 | 宿主 | 该组 install pass | 该组 usable pass |

|---|---|---|---|

| 7 列一组 | trae、vscode-copilot、codex-cli、cline、roo-code、continue、workbuddy | 116 | 112 |

| 单列 | claude-code | 115 | 108 |

| 单列 | opencode | 112 | 107 |

| 单列 | claude-desktop | 105 | 102 |

| 单列 | lingma | 105 | 102 |

| 单列 | cursor | 116 | 96 |

| 单列 | windsurf | 116 | 106 |

| 单列 | zed | 116 | 74 |

| 单列 | gemini-cli | 41 | 37 |

| 单列 | codebuddy | 38 | 36 |

| 单列 | qoder | 34 | 31 |

17 列去重后实测只有 11 种形态，其中 7 个列完全同形。也就是说，17 这个数字是列数，不是样本数。

这个差别不是学术问题。如果你按「17 个宿主里 10 个通过率过 70%」来下结论，实际支撑它的是 11 份证据里的若干份，而那 7 个同形列只贡献一份。分母从 17 变成 11 之后，「多数宿主都能装」这句话的说服力要打折。

同形的原因不该过度推断。可能是同一套客户端实现、同一套判据、或同一批同源配置模板。采集端没有记录客户端实现来源，所以这里只能说「同形」，不能说「同源」。

install 同数的 10 个宿主，usable 只有 7 个同值

真正容易踩的坑在这里。install 列的通过/失败/无法判定计数正好是 116/42/3 的宿主，实测有 10 个：上表那个 7 列组，加上 cursor、windsurf、zed。

按 install 看，这 10 家一模一样。按 usable 看，实测只有 7 家同值：

| 宿主 | install pass | usable pass | 与 7 列组的差 |

|---|---|---|---|

| 7 列组 | 116 | 112 | — |

| cursor | 116 | 96 | −16 |

| windsurf | 116 | 106 | −6 |

| zed | 116 | 74 | −38 |

三家的差距合起来是 60 格，正好等于「install=pass 而 usable=limited」的全部格数。换句话说，如果你只看 install 列，你会认为这 10 个宿主可以互换；只看 usable 列，其中 3 个明显掉队。同一批数据，两列给出相反的选型建议。

这也是本站主张「选宿主先看 usable」的直接依据：install 列在这 10 家身上没有区分度，usable 列才有。具体的 127 格落差与拆分方式见另一篇数据稿，本篇只讨论列能不能互相替代。

差的 60 格，落在三条写在配置里的边界

那 60 格不是随机波动。三家各踩一条自己的边界：

| 宿主 | limited 格数 | 边界 | 依据强度 |

|---|---|---|---|

| zed | 38 | 不支持 resources 原语 | 官方文档明确列出仅 Tools 与 Prompts |

| cursor | 16 | 工具数约 40 个上限 | 第三方实测记录，站点记 toolCap=40 |

| windsurf | 6 | 工具数 100 个上限 | 第三方实测记录，站点记 toolCap=100 |

zed 的 38 格实测恰好等于有资源项的 server 数（38 个）；cursor 的 16 格全部来自工具数超过 40 的 server，最小值 41；windsurf 的 6 格覆盖工具数 108 到 628 的 server。三条边界都在宿主能力表里能查到——zed 的 resources 是不支持，cursor 与 windsurf 各有 toolCap 数值。所以这 60 格属于「规则可推导」，不是「偶发故障」。

这条推论的价值在于可预测：知道边界在哪，就能在装之前算出某个 server 在某个宿主上会不会被限，不必等采完再看。

宿主能力表自己也承认证据不齐

再往下挖一层会发现，连「宿主能力」这个基准都不齐。17 条宿主记录里实测 11 条标 documented（官方文档明确写出）、5 条标 reported（第三方实测记录，未回官方交叉验证）、1 条标 conflicting（资料互相矛盾，通义灵码的远程支持就是这一条）。

同时，采集只对 5 个宿主记录了 CLI 版本快照（claude-code 2.1.311、gemini-cli 0.66.0、qoder 1.1.80、codebuddy 2.177.1、opencode 1.19.4）。这意味着「版本」这一维没有横向可比性——同一列里混着不同版本的结果，而另外 12 列根本没有版本信息。

两个限制叠加，得到一条使用纪律：这张表适合做「可行性预筛」，不适合做「横向排名」。预筛看单格结论是够的；排名需要每一列都同源、同版本、同判据，这里三条都不满足。

该看哪一列，怎么复核

给出可执行的三条：

1. 先给列去重。把 install 与 usable 序列相同的宿主并成一组，组内选一个代表去试装即可，不必逐个实测。
2. 用 usable 列做选择，用 install 列做排除。install 失败说明连启动都没过，可以直接排除；但 install 通过不能证明可用，尤其在工具数多或带资源项的 server 上。
3. 引用任何通过率都带上分母。分母是 161 个 server 还是 11 种列、证据是真机还是文档，写法不同结论就不同。上一段那三个 98.4% / 43.0% / 0% 就是同一张表里三种证据的通过率，混用会得出完全相反的结论。

复核方法是可复现的：把采集 JSON 的 servers[].checks[] 按 hostId 聚成 17 个序列，做序列级相等判断即可，无需任何统计工具。站内已经把这件事做成页面，宿主能力对照按宿主列出约束，判定方法给出顺序，坑点清单按组归档成因。想验证某个具体 server 的形状，看它的详情页，例如官方协议参考实现——它有 13 个工具、7 个资源项，正好同时踩到工具数与资源项两条边界，是检验自己读表方法的合适样本。

一句话收口

17 列不是 17 份证据，是 11 种观测加 6 次重复。先把列去重，再用 usable 列做选择，最后带上分母与证据档位——三步做完，这张表才能用来决定装什么。