2026 年中国 AI 模型名单：DeepSeek、Qwen、Kimi 之外还该怎么选
编辑标准与来源政策: 编辑标准, 团队. 内容均链至原始来源，见 方法论.
中国 AI 模型名单如果只列名字，很快就会过期。对产品经理和开发者更有用的做法，是按任务建立候选池：谁适合 API 快速接入，谁适合开源部署，谁适合 coding agent，谁适合多模态，谁适合长期观察。
| 模型/路线 | 适合任务 | 先查什么 | 官方核验入口 |
|---|---|---|---|
| DeepSeek API | 成本敏感的通用推理和 OpenAI 兼容接入 | 模型列表、价格、限流、错误处理 | DeepSeek API docs、DeepSeek models and pricing |
| Qwen 系列 | 开源模型、多语言、多模态、部署候选 | 模型尺寸、license、部署平台 | Qwen3 release notes、Qwen GitHub repository |
| Kimi / Moonshot | 长上下文、coding、多模态和中文工作流 | 上下文、模型名称、价格、工具支持 | Kimi API docs、Kimi model pricing docs |
| Kimi K2.7 Code | coding agent 和 IDE/CLI 工作流 | Cline/RooCode/Claude Code 兼容方式 | Kimi K2.7 Code guide |
| Llama | 国际开源基座和本地生态 | license、模型获取、推理工具链 | Meta Llama downloads、Meta Llama on Hugging Face |
| GLM / MiniMax / 阶跃等 | 垂直任务和国内生态候选 | 官方文档、API、模型卡、案例 | 官方页面和模型卡 |
不要把名单当排行榜
模型选型不是选“最强”，而是选“任务最匹配”。一个客服知识库需要稳定引用和成本控制；一个 coding agent 需要长程代码能力和工具兼容；一个多模态应用需要图像、视频或语音输入；一个企业内网项目还要看部署、合规和日志。
四步建立候选池
- 写清任务：客服、代码、文档问答、数据分析、多模态、Agent 编排。
- 列 2-3 个候选模型，不超过 5 个。
- 用同一组输入跑样本，记录质量、延迟、成本和失败样本。
- 回到官方文档确认价格、上下文、license 和 API 兼容性。
任务到模型的判断表
| 任务 | 优先看 | 不建议只看 |
|---|---|---|
| 中文长文档问答 | Kimi、Qwen、DeepSeek + RAG | 单次主观体验 |
| Coding Agent | Kimi K2.7 Code、Codex、Claude Code | 只看代码 benchmark |
| 本地部署 | Qwen、Llama、DeepSeek 开源生态 | 只看 API 价格 |
| 企业客服 | 成本、引用、限流、稳定性 | 只看模型热度 |
| 多模态应用 | 是否支持视觉/视频输入 | 只看文本能力 |
FAQ
DeepSeek、Qwen、Kimi 之外还要看谁？
可以关注 GLM、MiniMax、阶跃星辰等路线，但前提是回到官方文档、模型卡和 API 页面核验。没有来源的参数、排名和价格不要进入选型表。
中国模型适合直接替换海外模型吗？
需要按任务测试。API 兼容不等于输出质量、限流、价格、上下文和工具调用行为完全一致。
模型名单多久更新一次？
高价值团队不需要天天改名单。每月更新候选池，每次重大 API、价格、模型或 license 变化后再做专项复盘。
用 RadarAI 把关注变成固定节奏
如果只靠社交平台刷热度，很容易在同一天看到十几个互相矛盾的结论。更稳的做法是把关注动作拆成三步：先看官方发布和仓库变化，再看开发者是否真的能复现，最后决定是加入 watchlist、做小样本测试，还是暂时忽略。RadarAI 适合作为第一层过滤器：先从每日更新里发现变化，再回到官方文档、GitHub 仓库和产品页面核验。
适合继续阅读：
具体任务场景：为一个中文客服产品选模型
假设团队要给中文客服产品选模型。任务不是“找最强模型”，而是找一个能稳定回答产品问题、成本可控、支持引用或工具调用、出现不确定时不会虚构的候选。可以让 DeepSeek、Qwen、Kimi 和一个备用模型跑同一组 40 个问题。
| 问题类型 | 样例 | 验收标准 |
|---|---|---|
| 简单事实 | 套餐包含什么功能 | 回答准确，不扩展承诺 |
| 多轮上下文 | 用户连续追问同一问题 | 能保留上下文，不混淆对象 |
| 无答案 | 资料里没有的功能 | 明确说资料不足 |
| 格式要求 | 输出 JSON 或表格 | 格式稳定可解析 |
| 成本压力 | 批量 1000 问 | 延迟和费用可估算 |
每个模型都要记录失败样本，而不是只保留平均分。比如某模型中文语气好但格式不稳，另一个模型成本低但容易补事实，第三个模型长上下文强但延迟高。最终选型应该写成“主模型 + 备用模型 + 不适用场景”，而不是一句“某模型最好”。
候选池更新规则
| 触发条件 | 是否更新候选池 |
|---|---|
| 官方发布新模型 | 是，先读文档再测试 |
| 价格变化 | 是，重算成本样本 |
| 社交平台爆火 | 否，先放 watchlist |
| API 错误率变化 | 是，检查生产影响 |
| 新增工具调用或上下文能力 | 是，跑相关任务样本 |
这样处理后，中国 AI 模型名单就不是一篇静态目录，而是一套持续选型方法。读者可以在 DeepSeek、Qwen、Kimi 之外继续加入新候选，但不会因为热度变化就推翻整个判断框架。
不同角色怎么使用选型结果
产品经理看任务适配和用户体验，研发看 API、部署和故障处理，财务或负责人看成本曲线，安全或合规看数据路径和 license。模型选型页面需要同时服务这些角色，所以不能只写技术评价，也不能只写商业结论。把不同角色关心的问题拆开，页面才更容易承接搜索流量和后续阅读。
决策记录模板
把一次关注记录写下来，比临时争论更有用。可以用下面这张表作为团队内部记录格式：
| 字段 | 写法 | 示例 |
|---|---|---|
| 触发信号 | 从哪里看到这个变化 | 官方文档、GitHub release、RadarAI 更新 |
| 相关任务 | 它可能影响哪个现有流程 | 代码审查、客服问答、知识库、模型选型 |
| 验证动作 | 准备用什么小样本测试 | 30 分钟 quickstart、20 个固定问题、一个低风险 bug |
| 通过标准 | 什么结果才算值得继续 | 能复现、可审查、成本可估算、失败可回滚 |
| 当前决定 | watch / test / adopt / skip | 先 watch，两周后复查 |
| 复盘日期 | 什么时候再看 | 7 天、14 天或 28 天 |
这个记录不需要复杂，但必须可追溯。很多低参与内容的问题，是读者看完没有下一步；很多团队内部讨论的问题，是每次看到新工具都从零开始争。把信号、任务、验证和决定写成一行，既能减少重复讨论，也能让后续复盘有依据。
发布后如何复盘这个页面
内容刷新后，不只看排名。更应该看四类指标：第一，engagement_rate 是否比刷新前提升；第二，engaged_sessions 是否随 sessions 增长；第三，页面里的相关链接是否有人点击；第四，是否带来订阅、收藏或继续阅读。若 sessions 高但参与仍低，优先检查首屏结论是否清楚、表格是否太靠后、内链是否像“更多文章”而不是下一步动作。
如果 7 天后仍然低参与，可以先小修标题和开头；如果 14 天后仍然没有改善，检查页面是否与相邻主题重复；如果 28 天后仍然没有点击和停留，就考虑把它并入更强的主题页，保留原 URL 的流量入口和解释价值。