背景
这两天 DeepSeek V4 Pro 刚上线，小米那边也送了一个月的 Mimo Token plan。我本来就在试着用 AI 做一个完整工具，正好顺手把几个国产大语言模型都拉进来跑了一轮：GLM 5.1、Kimi K2.6、Mimo v2.5 Pro 和 DeepSeek V4 Pro。
测试样本是我手头正在做的一个工具项目，后面只保留和模型表现有关的数据，不展开它自己的功能设计。
测试方式
流程比较简单：
- 用 GPT 5.5 + xhigh 思考强度做工程设计、执行计划和 Agent 提示词。
- 按阶段交给国产模型实现。
- 每轮实现之后，再用 GPT 5.5 + xhigh 做 Code Review，修问题并补测试。
- 全部完成后，用 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%）
耗时：除命令行执行外，模型响应耗时约 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
| 类型 | 数量 | 主要修复点 | 估算修复代码量 | 占参与分析实现代码比例 |
|---|---|---|---|---|
| 致命 | 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%，高峰期倍率 x3）
耗时：除命令行执行外，模型响应耗时约 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 订阅窗口内，高峰期倍率 x3
耗时：未单独记录模型响应耗时
| 类型 | 数量 | 主要修复点 | 估算修复代码量 | 占参与分析实现代码比例 |
|---|---|---|---|---|
| 致命 | 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。尤其是重要代码，最后还是要人兜底。
欢迎有兴趣的小伙伴们互相交流探讨。