评测对象 · 项目与技术栈

0一句话结论

三个模型接到完全相同的任务：把 claude_web 从"每台机器一个子域名"改造成"单域名多机聚合"。都从同一份原始代码（svn r102，server.py 10692 行 / index.html 9890 行）出发，可比。人类启动指令都是同一句「plan_X.md 按文档执行吧，我同意」。

排名基于统一口径评分（§4）+ 实测证据（§3、§6），不是先后顺序红利——已逐条核对 bug 根因归属，证实不存在"GLM 趟雷、后人乘凉"（§6）。AI 评分与 owner 反馈作为两条并行结论，互不覆盖（§4.4）。

2量化指标 确定性统计，非模型判断

2.1 代码规模（相对 r102 公共基线）

GLM 净增业务代码最多（+1992），且几乎全在后端——它从零建了 1882 行网关，前端只动 32 行（"前端零改"属实）。Kimi/Opus 的量压在前端（index.html 做到 10340 / 10235 行）。GLM 代码体量最大，是因为选了"服务端重型网关"这条最重的架构路线，非效率低。

2.2 对话 / 成本指标 仅任务相关会话 · GLM 已剔除树莓派

Kimi 效率最高（1.8h、30 万 token、6 个人类轮跑完 6 步）。GLM 成本最高（部分是重网关的天然复杂度，部分是 THINKING 冗长）。三者均未用子代理，单线程推进。Opus 的 input_tokens 被供应商记入 cache_read，跨模型只有 output_tokens 可比。

3代码与方案质量 统一口径 + 真实运行测试验证

以下"绿 / 崩"结论均经实际运行验证，非采信各自宣称。每条结论带可复现证据（文件:行 / 命令输出 / 转录行号）。

3.2 代码落地度 —— 方案承诺 vs 代码现实

3.1 方案质量 · 3.3 安全 · 3.4 测试（速览）

三者方案质量都很高（都先读代码、标行号、识别文档漂移、规避历史否决），差距主要在实施与验证环节。三者都诚实指出：集成/UI bug（brotli、工程重名、前端路由）单测覆盖不到，必须真机才暴露。

4综合评分与选型建议

4.1 分维度评分 0–10，评审口径统一

GLM 各项得分均基于核心双机任务证据，与树莓派无关；剔除树莓派不改变能力分，只改善"单位成本效率"（成本降 27%，但仍最贵，维持 6.0）。

4.1b 综合能力排名 三口径聚合

• ①② 极接近（纯能力并列 8.44），分水岭是"交付可信度"：Opus 唯一拿正面验收 + 自测最全；GLM 有"全新部署会崩"的活雷。
• ②③ 之间 Kimi 短板可修复：后端+代码质量不弱于任何一家（成本效率甚至第一），唯一致命伤是前端零真机自测。配一道真机 QA 可能反超。

4.3 面向选型的建议 换场景会翻盘

能力天花板 GLM≈Opus＞Kimi；交付可信度 Opus＞GLM＞Kimi；性价比 Kimi＞Opus＞GLM。

4.4人类反馈 owner 视角，与 AI 评分并行、互不覆盖

结论分两层，方向不同——这正是要并行列出的原因：

• GLM 的价值在"选对了方向"：网关聚合是三者里唯一为"未来 N 台机器"设计的架构，天花板最高；扣分（deploy 漏文件、成本高）都是可修的工程细节，不是路线错误。
• Opus 的价值在"这一版最靠谱"：交付即用、自测最全、唯一拿到验收；但轻量无状态路线在 owner 眼里扩展性上限不如网关。
• 两个结论并存不矛盾：押长期架构 → 认 GLM 网关；现在就上线少操心 → 用 Opus 交付物。综合到"这次交付谁最好"，owner 和 AI 都给 Opus。

5评测局限 客观性披露，必须知悉

• 顺序效应（最大混杂变量）：任务顺序执行 GLM(7/22)→Kimi(7/23)→Opus(7/24)。GLM 是"开荒者"，首次踩遍部署坑；后两者环境更成熟、人类驱动更老练。对 GLM 不利、对 Opus 有利，不能简单归因于模型能力（已在 §6 逐条核对）。
• 树莓派已剔除：GLM 会话里的树莓派接入系人类误操作，其成本（约 27% 输出 token）与产物已从 GLM 账上剔除。
• 架构复杂度不对等（非范围）：同为双机，GLM 选服务端重网关（自建 ~1882 行），Kimi/Opus 选前端扇出。GLM 高成本主要来自路线的天然复杂度——中性看待。
• 供应商 token 口径差异：Opus input_tokens 几乎全记为 cache_read，跨模型只有 output_tokens 严格可比。
• "完成度"是相对判断：Kimi 90% 是相对自身范围，横向不能直接比百分数，要看 §3.2 的具体缺口。

6bug 根因逐条归属 回应"先行者税"，全部带可复现证据

逐坑根因判定

• ① GLM 日锁 非能力问题 — 转录 GLM_0:3058 坐实：外部监控每 ~2min 用旧密码打 /healthz，10 次触发日锁。根因 = owner 环境已有监控 + 网关 cutover 换密码。GLM 还做了根本修复（/healthz 错凭证不计锁）。
• ② GLM brotli 网关路线自带 — worker 压 br、网关 httpx 解不开且剥了 content-encoding 头。前端扇出路线（Kimi/Opus）浏览器直连 worker，天生没有。
• ③ Opus 改错目录空转数小时 ⭐ 反向先行者税 — 转录 OPUS_0:1881 坐实："这是两个不同的目录！线上服务跑的是隔壁 claude_web"。评测环境给每模型分配隔离副本、线上跑主目录；GLM 第一个就在主目录 → 天然没这坑；后发 Opus 在隔离副本改 → 空转 + 误触发 3 次 rotate 踢 cookie。后发者反而独踩了先行者没有的坑。
• ④ Kimi 3 个前端 bug 验证缺口，与先后无关 — 不是偷懒（想测但没浏览器在线，转录:2174）；但暴露差距：同样没真环境，Opus 自建 mock-caddy、GLM 跑真公网，Kimi 只做静态检查就宣称"已验证"。