为什么选择国产大模型
我的国产大模型使用历程
从 Qoder 上线那天起，我就一直在用国产大模型。
不是买不起国外的，而是我认为：一个产品如果依赖不可控的外部服务，就不可能真正为企业所用。 本地化部署、数据不出网、零 Token 费用——这些是 Growth AIOS 的核心卖点，也是我必须深度使用国产模型的根本原因。
2025 年 5 月，我开始了国产大模型的一路追随：
每次最新的大模型发布，我都是第一时间试用，直接在 Growth AIOS 的百万行代码上验证。
为什么不用 Claude
我也用过国外模型。
当时 Trae 国际版送了 100 美金，我用它做 Growth Basedata 产品——一个抽象数据查询引擎。
这里要补充一个背景：MBQL（Metabase Query Language），是开源 BI 工具 Metabase 自研的抽象查询描述语言。它不是 SQL 字符串，而是 JSON 嵌套的结构化语法（抽象语法树 AST）。Metabase 可视化查询编辑器拖出来的所有报表、图表，底层全部存储为 MBQL；执行时 Metabase 会把 MBQL 自动翻译成对应数据库方言 SQL（MySQL/PG/BigQuery 等）。
我的需求就是用 C# 和 TypeScript 实现一套类似的抽象查询层，支持浏览器端数据库和本地 SQLite 两种实现。
我用的是当时 ChatGPT 发布的 GPT-5 Pro。
结果发现问题也很多——和国产模型遇到的问题一模一样：代码引用不对、多轮改不好、前端样式需要大量手动调整。
国外模型不是神话。 你亲自上手做一遍就知道了。
那为什么很多人觉得 Claude 效果好？
有两个客观原因：
- Claude 是最先一批支持 100 万 token 长上下文 + 万亿参数级别的模型，而且它运行时是"满血"运行的——我的猜测是它的上下文压缩策略比较保守，很少触发压缩，所以长上下文场景下表现稳定
- 初始印象形成了路径依赖——第一个让你觉得"好用"的模型，你会不自觉地宽容它的问题，苛责后来者
但 Claude 的秘密武器不是模型本身——它只是比其他人更早解决了工程化问题。
Qoder 模型配置的秘密
很多人不知道，Qoder 默认上下文配置是 200K，不是模型的上限。
你需要手动编辑模型配置，才能把上下文拉到 1000K（1M）。大多数用户根本不知道这个设置在哪。
这就是为什么同样的模型，在不同人手里效果截然不同——不是你选的模型不对，是你的配置没到位。
模型模式的选择 — 这是大多数人踩的坑
Qoder 提供了五个模式：极致、性能、经济、轻量、Auto。
Auto 是默认模式。 这就是最关键的问题——如果你不主动设置，Qoder 就会用 Auto。
永远不要用 Auto。 它消耗得最快，底层很可能调的是国外模型，成本完全不可控。很多人在网上评论说"Qoder 积分消耗太快"，99% 的原因就是没有在设置里指定模型，一直在用默认的 Auto 模式。
使用 Qoder 的第一件事：打开模型设置，关掉 Auto，指定一个你了解成本上限的模型。 不要直接问问题，因为默认就是 Auto。
我自己的实践：
上个月积分快过期，就用了一次"极致"模式测试。改了 2 个小时的前端 Tailwind 重构任务，消耗了 800 积分。
结果改出来的也是一堆问题。
最终是谁修好的？国产模型——DeepSeek V4 Flash。
但那不是因为国产模型更强——而是因为我在国产模型上沉淀了 Rule 和 Skill，用 Flash 模式跑了同样的任务，不到 100 积分就搞定了。 换任何一个模型来，只要绑上同一套 Rule 和 Skill，效果不会有本质差异。
这个案例最有价值的地方在于：真正决定代码质量的，是工程规范（Rule + Skill），不是模型参数。 当你的项目没有规范、没有文档的时候，任何大模型都没用。
国产 vs 国外：已经没有代差
现在很多人还迷信国外的 Claude Opus 和 GPT Codex。
我直接说结论：国产大模型和国外顶尖模型之间，已经没有实质性代差。
2026 年权威评测数据也印证了这一点：
| 评测维度 | 国产代表 | 国外代表 | 差距 |
|---|---|---|---|
| SWE-Bench Verified | DeepSeek-V4-Pro: 76% | Claude Opus 4.7: 78% | ~2% |
| 代码生成质量 | GLM-5.1: 77.8% | GPT-5.3-Codex: 80% | ~2% |
| 多语言编程 | Qwen3.7-Max | Gemini 3.1 Pro | 持平 |
| 前端生成 | 各有优劣 | 各有优劣 | — |
2% 的差距在实际使用中根本感知不到。 国产模型在中文理解、本地化部署、成本控制上反而有显著优势。
核心观点：不是模型的问题，是你的问题
代码写得不好，不是模型的问题，是你使用模型的方式有问题。
这是我最想说的话。
为什么很多人用 Claude 和 Codex 觉得好，用国产模型觉得差？最根本的原因是——
他们把 AI 当大脑，而不是当工具。
这就是所谓的 vibe coding 现象：完全让 AI 干活，自己只看结果。AI 变成了决策者，而不是执行者。
在这种模式下：
- 你给 Claude 一个需求，它生成了代码，你试了能跑，就觉得"好"
- 你给国产模型同样的需求，它也生成了代码，但有细微差异，你就觉得"差"
问题根本不在模型，而在你放弃了人的判断力。
因为无论什么 AI，其工作原理和上下文长度限制都决定了：
- 没有模型能记住整个代码库——上下文窗口再大也是有限的
- AI 永远在做熵增操作——没有人工约束，代码会逐步碎片化
- 大型项目不做外部控制，最终一定会崩溃——这不是模型的能力问题，是信息论的基本规律
模型的差异在边际，而使用方法的差异在根本。
我的选型经验
经过近一年的反复对比，我目前的使用策略如下：
DeepSeek V4 Flash — 日常主力
适合场景：
- 简单的阅读代码、理解逻辑
- 修改 Bug、小的功能调整
- 创建模板类的 Skill（比如简单的 CRUD）
- 日常对话、快速验证想法
性价比最高，大部分日常任务它都能搞定。
DeepSeek V4 Pro + Qwen 3.7 Max — 中等复杂度
适合场景：
- 模块级别的设计，局部范围的重构
- 涉及多个文件的协同修改
- 需要在现有架构上新增功能模块
两者各有优势：DeepSeek V4 Pro 在代码严谨性上更好，Qwen 3.7 Max 在 Agent 任务和多模态理解上更强。
DeepSeek V4 Pro + Qwen 3.7 Max — 复杂重构
适合场景：
- 大型重构，跨越多端（Web 端、PC 端、服务端、组件端）
- 多工作区、多模块、多组件的系统性重构
- 架构级别的调整和迁移
这类任务的关键不是模型，而是你的工程规范是否到位。Rule 有没有覆盖编码规范？Skill 有没有沉淀重构流程？Memory 有没有记录架构决策？这些比模型选哪个重要十倍。
GLM 5.1 — 疑难杂症
适合场景：
- 多轮会话无法解决的复杂问题
- 推理密集型任务
- 需要长时间持续工作（GLM 5.1 可连续工作 8 小时）
当其他模型都搞不定的时候，换 GLM 5.1 试试，它在长程推理和任务闭环上确实有独到之处。
总结
经过近一年的国产大模型深度使用，我的结论是：
- 选国产还是国外，不是技术问题，是工程决策问题。 本地化部署、数据合规、成本控制这些因素远比模型间的 2% 差异重要。
- Rule + Skill 比模型更重要。 同样的模型，有规范没规范，效果天差地别。
- 后端开发可以放心用任何模型。 国产模型在后端代码生成上已经完全够用。
- 前端调试是人机协作的关键战场。 这条路没有捷径——你需要懂布局、懂 CSS、懂框架，才能让 AI 真正帮你提效。
- 真正决定代码质量的，是你的架构能力，不是模型参数。
国产大模型已经够好了。如果你觉得不好用，先问问自己：是不是用错了方式？