---
title: 三大国产编程模型（glm/kimi/minimax）全栈项目对比
date: 2026-02-14 12:00:00
tags:
- AI
- 编程
categories:
- AI测评
---
昨天晚上突发奇想，想实际测一下GLM-5、Kimi K2.5、MiniMax M2.5这几个新出的国产编程模型到底怎么样，毕竟跑分一个比一个强。其次，网上大多测评都是基于Web前端，而我的开发场景多为全栈，也想看看这些模型在全栈项目上表现如何。
本次测评环境：
- 系统：Windows 11 专业版 25H2
- 客户端：OpenCode+oh-my-opencode（sisyphus模式）
- API来源：硅基流动(GLM5)、OpenCode Zen(Kimi K2.5、MiniMax M2.5)
- 项目：[https://github.com/ravizhan/MWU](https://github.com/ravizhan/MWU)
- 提示词：为本项目集成mirrorchyan更新渠道，包括从interface读取mirrorchyan_rid，在前端添加cdk设置，获取更新接口改为mirrorchyan，更新器也要添加相应支持，可以参考https://github.com/MistEO/MXU这个项目中的写法，文档https://github.com/MirrorChyan/doc
> 我忘记之前已经给更新器写过增量更新的兼容了，所以更新器其实不用改
- MCPs：github、context7、deepwiki、其他OpenCode内置工具
- AGENTS.md：[https://github.com/ravizhan/MWU/blob/cce84a26c624cac4493eebf6c49f33832f874cef/AGENTS.md](https://github.com/ravizhan/MWU/blob/cce84a26c624cac4493eebf6c49f33832f874cef/AGENTS.md)
背景信息：本次测评基于真实全栈项目MWU，前端Vue、后端Python、更新器GO。三个模型均在 [Commit cce84a2](https://github.com/ravizhan/MWU/commit/cce84a26c624cac4493eebf6c49f33832f874cef) 的基础上进行修改，分别在三个分支独立开发。该项目目前已集成Github更新渠道，现在需要新加一个Mirror酱渠道。由于MistEO/MXU和Mirror酱这两个项目都比较新，可以避免几个模型提前学到了相关知识，从而强迫他们使用工具。
该任务考验模型对整体项目架构的理解、对未知项目/API信息的搜集能力、前后端协同开发能力、Agent能力以及最重要的代码能力。
## 各模型Token消耗及价格对比
| 模型 | 输入/Tokens | 输出/Tokens | 缓存输入/Tokens | 价格/￥ |
|------|-------------|--------------|----------------|---------|
| GLM-5 | 10231 | 10148 | 4029 | 25.18 |
| Kimi K2.5 | 14879 | 7120 | 7814 | 1.888 |
| MiniMax M2.5 | 19006 | 8983 | 6248 | 1.003 |
## 各模型轨迹记录
- GLM-5：[https://gist.github.com/ravizhan/dfb9de68fa4aae57a91c6a63448094ae](https://gist.github.com/ravizhan/dfb9de68fa4aae57a91c6a63448094ae)
- Kimi K2.5：[https://gist.github.com/ravizhan/a65dd17fc7323a33cacbada680b78c23](https://gist.github.com/ravizhan/a65dd17fc7323a33cacbada680b78c23)
- MiniMax M2.5：[https://gist.github.com/ravizhan/fc900b5204f3d87aba4e926936003dac](https://gist.github.com/ravizhan/fc900b5204f3d87aba4e926936003dac)
以下评估报告由Github Copilot+Claude Opus 4.6独立生成
**省流：GLM-5写得最好但也最贵**
# MirrorChyan 集成方案对比评估报告
## 一、变更规模概览
| 维度 | Kimi K2.5 | MiniMax M2.5 | GLM5 |
|------|------------|--------------|------|
| 修改文件数 | 7 | 7 | 9 |
| 新增行数 | +131 | +109 | +349 |
| 删除行数 | -1 | -18 | -9 |
| 后端改动 (main.py) | +98 | +92 | +238 |
| 前端改动 | 4 文件 | 4 文件 | 6 文件 |
| 更新器改动 (updater/) | 无 | 无 | 无 |
| config 默认值修改 | 无 | 有 | 有 |
| store 默认值修改 | 有 | 无 | 无 |
## 二、功能完整度
| 功能点 | Kimi K2.5 | MiniMax M2.5 | GLM5 |
|--------|------------|--------------|------|
| 读取 interface.json 的 mirrorchyan_rid | ✅ | ✅ | ✅ |
| 前端 CDK 设置输入 | ✅ | ✅ | ✅ |
| CDK 密码遮蔽显示 | ✅ (type="password") | ❌ 明文 | ✅ (type="password") |
| "获取 CDK" 链接 | ✅ (input suffix) | ❌ 无 | ✅ (n-input-group) |
| MirrorChyan API 调用 | ✅ | ✅ | ✅ |
| GitHub 回退逻辑 | ✅ (拆分为独立函数) | ✅ (try/except 回退) | ✅ (独立函数 + 回退) |
| multiplatform 支持 | ✅ (条件判断) | ❌ 未使用 | ❌ 未使用 |
| CDK 错误码处理 | ✅ (60001-60003) | ❌ 无 | ✅ (7001-7005，与 MXU 参考一致) |
| 前端 CDK 错误展示 | ❌ 无 | ❌ 无 | ✅ (UpdateDialog 中展示) |
| 更新源选择 (mirrorchyan/github) | ❌ 无 | ❌ 无 | ✅ (下拉选择) |
| i18n 国际化覆盖 | ✅ 3 条 | ✅ 2 条 | ✅ 16 条（含错误码） |
| API 备用域名 | ❌ 仅主站 | ❌ 仅主站 | ✅ (mirrorchyan.com + .net) |
| 增量更新类型标记 | ❌ 无 | ❌ 无 | ✅ (update_type) |
| UpdateInfo 类型扩展 | ❌ 无 | ❌ 无 | ✅ (api.ts 扩展) |
| 哈希校验兼容 | ❌ 未处理 | ✅ (条件跳过) | ❌ 未处理 |
| 更新器 (Go) 改动 | ❌ 无 | ❌ 无 | ❌ 无 |
| CDK 条件显示 (仅有 rid 时展示) | ❌ 始终展示 | ✅ (v-if 判断) | ❌ 始终展示 |
| update_info source 标记 | ❌ 无 | ✅ ("mirrorchyan"/"github") | ✅ ("mirrorchyan"/"github") |
## 三、代码质量分析
### 3-1 Kimi K2.5
**优点：**
- 代码结构清晰，将 MirrorChyan 和 GitHub 检查拆分为独立函数 `check_update_mirrorchyan()` / `check_update_github()`
- 正确使用了 `interface.mirrorchyan_multiplatform` 字段做条件判断，是唯一正确利用此字段的方案
- CDK 输入使用 `type="password"` + `show-password-on="click"`，用户体验好
- 在 input 的 suffix slot 中嵌入 "获取 CDK" 链接，布局紧凑
**缺点：**
- CDK 错误码使用 60001-60003，与 MirrorChyan 官方文档（7001-7005）不一致，说明对参考文档理解有误
- `os_arch` 参数格式拼接（如 `win-x86_64`）与 MirrorChyan API 期望的分别传 `os` 和 `arch` 不同
- 没有修改 `config/settings.json` 默认值，使用 Pydantic 默认值兜底，可能导致首次加载 JSON 不含新字段
- 没有修改 `perform_update` 中的哈希校验逻辑，MirrorChyan 下载的文件可能因缺少 hash 而校验失败
- `check_update_github()` 中增加了 `if not interface.github` 判断但原始代码没有这层保护（算是一个改进）
- 前端没有条件化 CDK 输入框显示（即使 interface 没有配置 `mirrorchyan_rid`，CDK 输入框也会展示）
**代码风格问题：**
- `update_info` 类型注解从 `None` 改为 `dict | None`，这是一个合理的改进
- 总体符合项目代码规范
### 3-2 MiniMax M2.5
**优点：**
- 使用 `v-if="interfaceStore.interface?.mirrorchyan_rid"` 条件显示 CDK 输入框，是三者中唯一做了此优化的
- 引入了 `useInterfaceStore` 获取 interface 数据，前后端数据流正确
- `perform_update` 中增加了条件哈希校验，仅在 `file_hash` 非空时才校验，避免了 MirrorChyan 下载后校验失败
- 修改了 `config/settings.json` 添加默认值，确保 JSON 和 Model 同步
- 添加了 `source` 字段标记更新来源，方便后续逻辑区分
- `asset.get("digest")` 的 defensive coding，修复了原始代码中潜在的 `KeyError`
**缺点：**
- 误删代码：删除了 `localeOptions` 和 `handleLocaleChange` 函数，这与 MirrorChyan 功能完全无关，是一个严重错误
- CDK 输入框没有密码遮蔽，安全体验差
- 没有 "获取 CDK" 链接，用户体验不完整
- MirrorChyan API 参数中传了 `"os": plat` 和 `"arch": arch`，但 `plat` 值使用 `"windows"` 而非 MirrorChyan 可能期望的格式
- 缺少 CDK 错误码处理，用户无法理解 CDK 为何无效
- `mirrorchyanCdk: Optional[str] = ""` 使用了 `Optional[str]`，在 Python 3.12+ 项目中应使用 `str | None`（项目规范要求）
- 没有为 CDK 提供备用 API 域名
- MirrorChyan 无下载链接时的回退逻辑使用 `raise Exception` 然后 `except` 捕获，控制流不清晰
- Store 的 `defaultSettings` 未添加 `mirrorchyanCdk` 字段，可能导致首次使用时 store 数据不完整
**代码风格问题：**
- `Optional[str]` 不符合项目 Python 3.12+ 风格约定（应使用 `str | None`）
- 误删不相关代码属于重大风格/质量问题
### 3-3 GLM5
**优点：**
- 功能最全面：增加了更新源选择、CDK 错误码处理、备用 API 域名、增量更新类型、UpdateInfo 类型扩展等
- CDK 错误码 7001-7005 与 MXU 参考项目完全一致，说明正确参考了文档
- 前端 UpdateDialog 中展示了 CDK 错误原因，并根据 `download_url` 控制更新按钮可用性
- 实现了 `MIRRORCHYAN_API_BASES` 备用域名数组，与 MXU 参考项目一致
- 添加了 `updateSource` 下拉选择，让用户手动切换更新源
- 自定义 `compare_versions()` 函数做语义化版本比较，比简单字符串比较更可靠
- 修改了 `api.ts` 中的 `UpdateInfo` 接口，添加了 `source`、`update_type`、`error_code`、`error_message` 等字段
- 设置了 User-Agent 请求头
- CDK 使用 `n-input-group` + 外部按钮链接的布局，结构清晰
**缺点：**
- 代码量过大（+349 行），引入了较多复杂逻辑，增加维护成本
- 自实现的 `compare_versions()` 和 `get_os()`/`get_arch()` 等辅助函数，增加了代码与测试负担
- `proxies` 变量定义后未使用（dead code）：`proxies = {"http://": proxy, "https://": proxy} if proxy else null`
- `check_update_from_github` 中返回格式不一致——有时返回 `dict`（正常结果），有时返回 `{"status": "failed", ...}`，混合了两种语义
- 文件名生成逻辑有冗余分支，当没有 URL 但有 filesize 时通过平台信息生成文件名，逻辑复杂且可能不被触发
- `updateSource` 默认值为 `"mirrorchyan"` 而非 `"github"`，对于未配置 `mirrorchyan_rid` 的项目可能产生困惑
- `check_update_from_mirrorchyan` 中 `data.get("code") != 0` 但有 `version_name` 时用 `pass` 继续执行，控制流不够清晰
- Store 的 `defaultSettings` 未添加 `updateSource` 和 `cdk` 字段
**代码风格问题：**
- 总体代码风格与项目一致，但函数粒度过细（如 `get_os()` / `get_arch()` 在 Python 中只需几行）
- 注释充分，可读性好
## 四、API 正确性
对照 MXU 参考项目和 MirrorChyan API 规范：
| API 细节 | Kimi K2.5 | MiniMax M2.5 | GLM5 | 正确做法 (参考 MXU) |
|----------|------------|--------------|------|------------------|
| API 端点 `/api/resources/{rid}/latest` | 同 | 同 | 同 | ✅ 三者均正确 |
| `current_version` 参数 | ✅ | ✅ | ✅ | ✅ |
| `user_agent` 参数 | ✅ "MWU" | ✅ "MWU" | ✅ "MWU" | ✅ |
| `cdk` 参数 | ✅ 可选 | ✅ 可选 | ✅ 可选 | ✅ 可选 |
| `channel` 参数 | ❌ 未传 | ✅ | ✅ | 应传递 |
| `os / arch` 参数 | ❌ 用 `os_arch` 拼接 | ✅ 分开传 | ✅ 分开传 | 应分开传 |
| 备用域名 | ❌ 仅 .com | ❌ 仅 .com | ✅ .com + .net | 应支持备用 |
| 错误码范围 | 60001-60003（错误） | 无 | 7001-7005（正确） | 7001-7005 |
| 响应字段 `version_name` | ✅ | ✅ | ✅ | ✅ |
| 响应字段 `url` | ✅ | ✅ | ✅ | ✅ |
| 响应字段 `release_note` | ✅ | ✅ | ✅ | ✅ |
| 响应字段 `update_type` | ❌ | ❌ | ✅ | 应处理 |
| 响应字段 `sha256` | ❌ | ❌ | ✅ | 应处理 |
## 五、前端实现对比
| 前端细节 | Kimi K2.5 | MiniMax M2.5 | GLM5 |
|----------|------------|--------------|------|
| CDK 输入位置 | 代理地址上方 | 代理地址下方 | 更新渠道下方 |
| CDK 密码模式 | ✅ password + click 显示 | ❌ 明文 | ✅ password + click 显示 |
| 获取 CDK 链接 | ✅ input 内嵌按钮 | ❌ 无 | ✅ input-group 外部按钮 |
| 条件显示 CDK | ❌ 始终显示 | ✅ v-if mirrorchyan_rid | ❌ 始终显示 |
| 更新源选择 | ❌ 自动判断 | ❌ 自动判断 | ✅ 下拉选择 |
| CDK 错误前端展示 | ❌ | ❌ | ✅ UpdateDialog 告警 |
| UpdateInfo 类型扩展 | ❌ | ❌ | ✅ api.ts |
| i18n 条目数 | 3 | 2 | 16 |
| 误删代码 | ❌ 无 | ⚠️ 删除了 localeOptions | ❌ 无 |
## 六、健壮性与错误处理
| 健壮性维度