blog-website

背景

这两天 DeepSeek V4 Pro 刚上线，小米那边也送了一个月的 Mimo Token plan。我本来就在试着用 AI 做一个完整工具，正好顺手把几个国产大语言模型都拉进来跑了一轮：GLM 5.1、Kimi K2.6、Mimo v2.5 Pro 和 DeepSeek V4 Pro。

测试样本是我手头正在做的一个工具项目，后面只保留和模型表现有关的数据，不展开它自己的功能设计。

测试方式

流程比较简单：

1. 用 GPT 5.5 + xhigh 思考强度做工程设计、执行计划和 Agent 提示词。
2. 按阶段交给国产模型实现。
3. 每轮实现之后，再用 GPT 5.5 + xhigh 做 Code Review，修问题并补测试。
4. 全部完成后，用 Claude Opus 4.7 做了一次复核。

国产模型的执行顺序如下：

• Mimo v2.5 Pro + High 思考强度，第一轮；
• GLM 5.1 + High 思考强度，第一轮；
• Kimi K2.6 + Max 思考强度，第一轮；
• DeepSeek V4 Pro + Max 思考强度，第一轮；
• Mimo v2.5 Pro + High 思考强度，第二轮；
• GLM 5.1 + High 思考强度，第二轮；
• Kimi K2.6 + Max 思考强度，第二轮；
• DeepSeek V4 Pro + Max 思考强度，第二轮。

Code Review 的提示词大意是让模型看这一阶段的代码实现，修问题，尽可能补单元测试，并按致命、严重、一般、优化几个级别统计修复量。后面的数据都来自每轮 Review 报告。

全部完成以后，我又用Claude Opus 4.7 最后复核了一轮，只额外修了一处一般性 BUG，占参与分析实现代码约 0.4%；单元测试补了 3 个，占参与分析测试代码约 3.6%。说明前面的 GPT 5.5 + xhigh Review 已经比较充分，这个量级和我之前测试Claude Opus和GPT互相Code Review的时候互相修订的问题量差不多了。

总体结果

八轮下来，实现侧大约修了 50 项问题。测试侧按每轮报告粗略加总，大约补齐或修正了 95 项左右，测试代码补充量在 2600 行级别。

按实现侧问题看，四个模型的量级大致如下：

模型与配置	两轮实现侧修复	致命 / 严重 / 一般 / 优化	约修复代码量	测试侧补齐 / 修正	这两轮最明显的问题
Mimo v2.5 Pro + High	9 项	2 / 5 / 2 / 0	~640 行	~18 项，~517 行	队列并发、Redis/BullMQ 原子领取、压缩预算与上下文裁剪
GLM 5.1 + High	11 项	1 / 6 / 3 / 1	~663 行	32 项，~847 行	真实发布链路、sandbox 命令白名单、多输出 dispatcher 和模板覆盖
Kimi K2.6 + Max	16 项	0 / 9 / 4 / 3	~499 行	21 项，~508 行	LLM fallback 语义、输出路由、模板二次包裹、summary scrub 与 mention
DeepSeek V4 Pro + Max	14 项	1 / 7 / 4 / 2	~720 行	24 项，~738 行	Agent/sandbox 接入、ModelSpec 字段传播、env-file 安全边界、CLI lint

整体看下来，早期阶段的问题量不大，后面项目变大后，各个模型都开始明显漏东西。尤其是代码流程变长、配置要一层层传下去、还涉及并发、安全和真正发布的时候，遗漏会一下子变多。

这次没有出现“完全不能写”的模型。真正的问题是：它们都能把局部代码写出来，但不一定一直记得复杂工程里那些不能错的要求。

各模型表现

Mimo

Mimo 第一轮表现比较稳，实现侧只修了 3 项，约 69 行，占比约 1.89%。当时工程规模还不大，任务也比较集中，它基本能按计划推进。

第二轮我猜测是工程量大了以后触发了上下文压缩，幻觉变严重了，问题也就更多了：2 个致命、3 个严重，实现侧修复约 571 行，占比约 19.19%。其中最值得注意的是 worker 限流导致任务丢失，以及 Redis/BullMQ 队列领取和完成语义的问题。

Mimo 第一轮

Cost：消耗 Token 约 17M（Kilo 统计为 8.7M，模型倍率 x2）

耗时：除命令行执行外，模型响应耗时约 29 分钟

类型	数量	修复点	修复代码量	代码量占比
致命	0	未发现当前阶段致命链路中断	0	0%
严重	2	未发布却返回 published；Git 浅克隆缺少受控 deepen 重试	约 61 行	约 1.67%
一般	1	toolCalls 非数组时此前会被静默忽略	约 8 行	约 0.22%
优化	0	本轮未单独做优化型代码改动	0	0%
合计	3	本轮实现侧修复总量	约 69 行	约 1.89%

类型	数量	覆盖内容	测试修复代码量	测试代码量占比
单元测试遗漏补全	5	Git deepen enable/disable/diff retry/deepenBy 校验；Gitea 非 hex 签名	约 136 行	约 1.99%
错误修复	1	无 publisher 时期望从 published 改为 skipped	约 4 行	约 0.06%
测试意图未覆盖	2	非数组 toolCalls；summary-only 无可发布 finding 状态	约 41 行	约 0.60%
合计	7	本轮测试侧补齐/修正总量	181 行	约 2.65%

Mimo 第二轮

Cost：消耗 Token 约 24.5M（Kilo 统计为 12.3M，模型倍率 x2）

类型	数量	主要修复	估算修复代码量	占参与分析源代码比例
致命	2	修复 worker workspace 限流时误 complete() 丢任务；修复 Redis/BullMQ 队列非原子领取与无 lock token 完成/失败	~430 行	~14.45%
严重	3	压缩触发纳入 contextWindow * maxInputRatio；context_lines 真正生效；压缩后继续裁剪到预算内	~107 行	~3.60%
一般	1	in-memory queue 失败重试改为非阻塞可用时间调度，避免 backoff 占住 worker slot	~34 行	~1.14%
优化	0	本轮优先修正确性与数据安全问题，未单独做纯优化型代码改动	0 行	0%
合计	6	M3 长链路正确性修复	~571 行	~19.19%

类型	数量	覆盖内容	估算测试代码量	占参与分析测试代码比例
单元测试遗漏补全	8	Compression 模型窗口/context_lines/预算；queue workspace 排除；非阻塞 retry；Redis mock claim/complete/fail/DLQ	~267 行	~8.17%
错误修复	1	修正 queue-worker 全局并发测试被默认 workspace 并发错误串行化的问题	~3 行	~0.09%
测试意图未覆盖	2	强化 per-workspace 并发“任务不丢失”断言；补 LLM → scrub → markdown fix → publish 集成测试	~66 行	~2.02%
合计	11	M3 关键边界与长链路测试补强	~336 行	~10.28%

GLM

GLM 两轮总共修了 11 项实现问题，严重问题占比不低。第一轮有 1 个致命问题：webhook 链路跑起来了，但真实发布路径仍然被固定成 dry-run。这个问题很典型，看上去主流程通了，实际上该发出去的内容并没有发出去。

第二轮的问题集中在多输出和模板链路，4 个严重问题，约 478 行修复，占比约 19.2%。主要是缺 dispatcher、模板覆盖没有真正生效、行评论锚点失败时没有降级。

我的感觉是，GLM 局部实现能力没什么大问题，但对“这个配置最后有没有真的接到运行链路上”不够敏感。只看单个模块会觉得完成度不错，连起来看就会露出缺口。

GLM 第一轮

Cost：消耗 Token 约 11.7M（Pro 订阅 5 小时的 19%，高峰期倍率 x3

耗时：除命令行执行外，模型响应耗时约 33 分钟

类型	数量	修复点	约修复代码量	代码量占比
致命	1	bootstrapServerApp() 原先会把 webhook 编排固定为 dryRun: true，且无法按每个 Gitea PR payload 动态解析 PR 号与输出发布器，导致真实 Gitea e2e 即使跑通也不会发 line comment	约 78 行	约 4.92%
严重	2	Docker/Podman sandbox 实际总是调用 docker；容器 sandbox 未在启动容器前执行命令白名单校验	约 76 行	约 4.79%
一般	2	native sandbox 在无 stdin 时不主动关闭 stdin；OpenAI 兼容模型翻译器在仅配置 options.apiKeyEnv 时会生成错误的 ${} 占位	约 14 行	约 0.88%
优化	1	抽出 parseAllowedCommand() 让 native/docker sandbox 共用白名单校验逻辑，并在 AGENTS.md 记录新坑位	约 17 行	约 1.07%
合计	6	本轮实现侧修复总量	约 185 行	约 11.67%

类型	数量	覆盖内容	约测试代码量	测试代码量占比
单元测试遗漏补全	9	Podman CLI 选择、docker→podman auto fallback、显式 podman preflight、容器命令白名单、factory 传递 allowlist、native stdin EOF、translator apiKeyEnv fallback、Plan 风格 Gitea publisher 配置解析、workspace route publisher resolver	约 214 行	约 9.52%
错误修复	2	bootstrapServerApp 从期望 dryRun: true 改为可发布；“required fields missing” 用例调整为真正缺 trigger/workspace repo 的场景	约 10 行	约 0.44%
测试意图未覆盖	3	编排器 per-event outputPublisherResolver dispatch；缺 PR number 时 resolver 返回 undefined；sandbox package name 测试改为真实导出断言	约 62 行	约 2.76%
合计	14	本轮测试侧补齐/修正总量	约 286 行	约 12.73%

GLM 第二轮

Cost：消耗 Token 约 8.8M（高峰期倍率 x3）

类型	数量	主要修复点	估算修复代码量	占参与分析实现代码比例
致命	0	未发现会导致当前仓库无法构建/启动或主链路完全崩溃的问题	0 行	0%
严重	4	GitHub PR dispatcher 缺失；GitLab MR dispatcher 缺失；workspace 覆盖模板参数被忽略；行评论锚点无效会导致发布失败且无降级	约 470 行	约 18.9%
一般	1	computeFindingFingerprint 由弱 32-bit 风格哈希升级为 SHA-256 截断，降低幂等指纹碰撞风险	约 8 行	约 0.3%
优化	0	本轮优先修复 M4 验收缺口，未单独做纯优化改动	0 行	0%
合计	5	M4 输出链路正确性与可配置性修复	约 478 行	约 19.2%

类型	数量	覆盖内容	估算测试代码量	占参与分析测试代码比例
单元测试遗漏补全	10	新增 GitHub PR dispatcher 5 例；新增 GitLab MR dispatcher 5 例	约 284 行	约 9.2%
错误修复	0	未修改既有错误断言；本轮以新增缺失覆盖为主	0 行	0%
测试意图未覆盖	8	Gitea 422/general fallback 2 例；workspace template 覆盖/回退 3 例；bootstrap GitHub/GitLab factory 2 例；orchestrator diff 外行号标记 1 例	约 277 行	约 8.9%
合计	18	M4 输出链路、模板覆盖、降级策略与配置 wiring	约 561 行	约 18.1%

Kimi

Kimi 第一轮修复量不大，实现侧约 82 行，占比约 4.69%。问题主要集中在 LLM fallback 和 retry 语义上，比如普通 4xx 不该 fallback、maxAttempts 计数偏移、预算超限后不应继续 fallback。

这些问题没有导致主流程直接不可用，但属于容易埋坑的控制逻辑。模型写出了大体结构，但边界条件没收紧。

第二轮进入输出路由和消息聚合后，问题数量上来了：5 个严重、3 个一般、2 个优化，约 417 行修复，占比约 13.6%。比较明显的是 summary 路由被忽略、只取首个 line channel、模板被二次包裹，以及聚合时可能使用未 scrub 的数据。

本次测试 Kimi 比较顺。第二轮第一次触发编写时，Token 消耗和改动代码量都不多。为了让结果更有意义一点，所以又触发了一次编写。不清楚这对质量有没有影响。

Kimi 第一轮

Cost：消耗 Token 约 5.2M（Allegretto 订阅 5 小时的 8%）

耗时：除命令行执行外，模型响应耗时约 45 分钟

类型	数量	修复点	约修复代码量	占参与分析实现代码比例
致命	0	未发现当前阶段必然导致 webhook → review 主链路完全中断的问题	0 行	0%
严重	4	非 429/5xx/超时/context-overflow 的 4xx 不应 fallback；maxAttempts 计数偏移并会在最后一次失败后多等；预算超限后不应继续 fallback；bootstrap 默认模型不应被 provider 数组顺序误导	约 67 行	约 3.83%
一般	1	Gateway 返回结果补齐显式 LlmGatewayChatClient 类型，避免调用侧只能看到基础 ChatCompletionResult	约 7 行	约 0.40%
优化	1	Retry-After 解析更严格，并对直接调用 gateway API 的异常 retry 配置做防御性兜底	约 8 行	约 0.46%
合计	6	本轮实现侧修复总量	约 82 行	约 4.69%

类型	数量	覆盖内容	约测试代码量	占参与分析测试代码比例
单元测试遗漏补全	5	普通 400 不 fallback；context-overflow 400 允许 fallback；maxAttempts=1 不重试也不多 sleep；默认模型使用 fallback_chain 首项；fallback provider 缺失时报错	约 125 行	约 3.79%
错误修复	3	旧测试中“400 会 fallback”的错误意图改为 5xx；retry attempts 语义从“重试次数”修正为“总调用次数”；provider override 下 maxAttempts=1 不再期望 retry	约 15 行	约 0.45%
测试意图未覆盖	2	预算超限不触发 fallback 的断言；fallback callback 只在可恢复错误切换模型时触发	约 20 行	约 0.61%
合计	10	本轮测试侧补齐/修正总量	约 160 行	约 4.85%

Kimi 第二轮

Cost：未单独记录完整 Token 数；（消耗了 Allegretto 订阅的11%）

耗时：未单独记录模型响应耗时

类型	数量	主要修复点	估算修复代码量	占参与分析实现代码比例
致命	0	未发现会导致当前本地构建/主流程完全不可运行的问题	0 行	0%
严重	5	outputs.routes.summary 被忽略；只取首个 line channel；bootstrap 使用首个通道模板渲染所有输出；finding 模板被二次包裹；summary 聚合链路可能使用未 scrub 的原始 finding，且 summary-only 通道在模型无 summary 时不真实发布	~315 行	~10.3%
一般	3	mention_author 未实际消费；mention_fallback 未落地；outputs.author_resolution 配置缺失	~75 行	~2.5%
优化	2	邮箱映射/黑名单大小写无关；WeCom 聚合消息支持 mention 文本拼接	~27 行	~0.9%
合计	10	M4 输出链路正确性、配置可用性、安全后处理与模板一致性修复	~417 行	~13.6%

类型	数量	覆盖内容	估算测试代码量	占参与分析测试代码比例
单元测试遗漏补全	7	outputs.author_resolution schema；Feishu email mapping mention；Feishu fallback all；mention_author: false；line/summary 分通道路由；renderedMarkdown 不二次包裹；WeCom mention 文本	~231 行	~5.6%
错误修复	1	发布器返回值扩展为单结果或多结果后，既有测试断言适配首个结果	~4 行	~0.1%
测试意图未覆盖	3	summary-only 通道在无模型 summary 时仍发布；summary 聚合使用 scrub 后 finding；黑名单优先于 fallback	~113 行	~2.8%
合计	11	M4 输出配置、模板、mention、安全后处理和聚合发布链路测试增强	~348 行	~8.5%

DeepSeek

DeepSeek 第一轮有个额外背景：当时 Kilo Code 和 Roo Code 对 reasoning_content 的适配还不完整，所以实际是 Kilo Code 先改了一小部分，后面切到 Claude Code 完成。这只是工具适配原因，不代表模型本身必须依赖 Claude Code。

第一轮实现侧修复 7 项，约 450 行，占比约 9.97%。主要问题在 agent/sandbox 接入、ModelSpec 字段传递、Docker mount 等链路。整体看是“写了模块，但没完全接入或字段传丢”的问题。

第二轮 Kilo Code 更新后直接跑 DeepSeek。这个阶段修了 1 个致命、4 个严重，约 270 行，占比约 15.92%。最严重的是容器 sandbox 的 --env-file 可能落在已挂载目录里，agent 能读到注入凭据。这个问题量不算最大，但风险级别很高。

DeepSeek 的成本表现比较有意思：两轮 Token 都在千万级，但因为缓存命中率高，当时 Super 折扣下实际费用只有几块钱。单看成本很香，不过安全边界还是必须人工复核。

DeepSeek 第一轮

Cost：消耗 Token 约 17M（缓存命中率约 97%，当时 Super 折扣活动下约 2.9 元）

AI Agent：Kilo Code 先改一小部分后，改用 Claude Code 完成

类型	数量	主要内容	约实现代码量	占参与分析实现代码比例
致命	0	未发现会导致当前仓库无法启动/构建的致命缺陷	0 行	0.00%
严重	3	M2 agent+sandbox 未接入真实编排链路；ModelSpec/provider 字段在配置/fallback/adapter 间丢失；Docker sandbox 忽略 materialized mounts	约 410 行	约 9.08%
一般	3	Kilo provider config/env 映射不完整；lint 阻断项；fallback ModelSpec 额外字段清理	约 35 行	约 0.78%
优化	1	将外部 CLI 探测相关行为改为确定性路径，降低本地/CI 偶发失败概率	约 5 行	约 0.11%
合计	7	本轮实现侧修复总量	约 450 行	约 9.97%

类型	数量	覆盖内容	约测试代码量	占参与分析测试代码比例
单元测试遗漏补全	5	agent+sandbox orchestration；bootstrap 注入 sandbox/agent；Plan ModelSpec 字段映射；Docker materialized mounts；真实 system prompt placeholder 装配	约 220 行	约 6.22%
错误修复	1	Kilo detect 测试不再依赖真实 kilo binary，改用 process.execPath	约 6 行	约 0.17%
测试意图未覆盖	2	agent stdin/env/teardown 断言；Kilo providers.json 和 provider-specific env 断言	约 34 行	约 0.96%
合计	8	本轮测试侧补齐/修正总量	约 260 行	约 7.35%

DeepSeek 第二轮

Cost：消耗 Token 约 13.6M（缓存命中率约 96%，当时 Super 折扣活动下约 2.3 元）

AI Agent：Kilo Code 更新后，第二轮直接使用 Kilo Code

类型	数量	主要修复	估算修复代码量	占参与分析实现代码比例
致命	1	容器 sandbox 的 --env-file 原先可能落在已挂载 agent 工作目录内，agent 可读到注入凭据；已改为系统临时目录，并在正常/异常路径清理	~34 行	~2.00%
严重	4	aicr lint 从占位命令变为真实 config/template 校验；GitLab MR 优先使用 diff_refs/last_commit SHA；Claude Code adapter 透传 Anthropic version/beta/thinking/max_tokens；新增独立 Podman backend 工厂入口	~225 行	~13.27%
一般	1	Webhook review preparation provider 类型从 Gitea-only cast 扩展为 ReviewProvider，避免 GitHub/GitLab 回调上下文语义错误	~11 行	~0.65%
优化	1	新增 podman.md 与 AGENTS.md sandbox env-file 坑位记录，强化后续维护约束（文档不计入实现代码占比）	0 行实现代码	0%
合计	7	M5 本地长链路正确性、安全边界与可维护性修复	~270 行	~15.92%

类型	数量	覆盖内容	估算测试代码量	占参与分析测试代码比例
单元测试遗漏补全	12	CLI lint config/template/错误输入；GitHub webhook HMAC；GitLab webhook token/MR 归一化；Claude Code advanced Anthropic 字段；Podman 专用 factory export	~383 行	~14.20%
错误修复	0	未发现需修改既有错误断言的测试	0 行	0%
测试意图未覆盖	4	sandbox env-file 不在挂载目录、runner 抛错仍清理、shell-wrapped escape 被拒绝、默认禁网且不挂载 Docker/Podman socket	~95 行	~3.52%
合计	16	M5 本地长链路和安全边界测试增强	~478 行	~17.72%

问题类型

上下文和长链路

项目早期，几个模型都还不错。后面代码变多、模块变多、历史约束变多，错误率明显上升。

我感觉这也是国产模型和顶尖模型差距的地方：短代码片段都还可以，逻辑关系长了、代码量变大、上下文变大以后，幻觉和退化比 GPT 和 Claude 都严重得多。

比如 dispatcher 写了但没有接到 bootstrap，配置字段存在但运行时没消费，某个发布路径看起来成功但实际没有产生期望输出。这类问题很适合骗过单元测试，因为单测经常只测函数，不测完整行为。

这也是后期修复代码量突然上升的主要原因。局部修补不难，难的是把前后流程重新串起来。

测试

测试补了很多，但问题不在数量，而在有没有测到点上。有些测试覆盖了 happy path，却没有覆盖无发布器、异常 fallback、模板覆盖、并发重试、secret 挂载目录这类真正危险的路径。

这个问题我之前也碰到过很多次。即便是 Claude Opus 写的测试代码，也会有很多靠“巧合”让测试通过的情况：case 看起来过了，其实逻辑根本不对。

所以我现在会更在意测试有没有覆盖坏路径，以及跨模块跑起来之后是不是真的符合预期，而不是覆盖率数字本身。AI 很容易把测试写得像样，但不一定真的测到了产品逻辑。

安全

并发和安全问题的数量不一定最多，但优先级最高。队列领取、任务完成、重试、容器挂载、环境变量、命令白名单、输出 scrub，这些地方只要漏一个，后果就可能比普通业务 bug 严重得多。

这也是我不太敢让模型自己去改高风险模块的原因。它可以先写，但后面必须好好 Review，并且专门补测试。

使用建议

测完之后，个人感觉国产模型在足够便宜的时候，作为一个便宜替代品勉强算是可用了。

但别放开了随便用：

• 任务包要小，边界要清楚；
• 哪些地方绝对不能错，要写进计划和测试；
• 高风险模块要交叉 Review；
• 测试要重点补坏路径和完整流程；
• 每次踩坑都记回仓库规则里。

但是无论是国产模型，还是最新的 GPT 或者 Claude Opus，都不能全信，更不能无脑接受。特别是重要代码，还是要人工 Review。否则万一它哪里的代码删库跑路了，或者 Crash 了，业务就 GG 了。

总结

这次测下来，国产模型不是不能写代码。短链路、边界清楚、代码量不大的任务，它们都能推进不少内容。便宜、量大的时候，不用考虑合规问题，还是挺香的。

但复杂工程里它们的问题也很明显：上下文一长，幻觉和退化就上来了。很多问题不是语法错误，而是流程没接上、配置没传到、测试没测准、安全边界漏了。这种问题一开始不一定显眼，真进了业务一样会出事故。

所以我的结论还是比较保守：可以用，但别全信；可以让它写，但别省 Review。尤其是重要代码，最后还是要人兜底。

有一个和我自己之前日常使用感觉相悖的一点，我之前的体感体验GLM 5.1是要强于Kimi K2.6和DeepSeek v4 pro的，特别是终端里让它分析问题的时候。 Mimo v2.5 pro，还没有用得特别多，不太好评价，但是初步的体感也强于Kimi K2.6，之前排查我家里软路由的问题的时候，甚至帮我找出了一个GPT 5.4都没分析对的问题。但是这次测试K2.6的错误最少，mimo也“泯然众人矣”。不知道是不是场景差异，mimo是不是测着测着，用量大了降智了😂。

欢迎有兴趣的小伙伴们互相交流探讨。