会写Python和JavaScript的代码助手已经不稀奇。真正麻烦的是那些没人维护的老系统：内部DSL、几十年前的脚本、银行业务里还在跑的ABAP。这些"长尾"语言，恰恰是大模型最容易被问住的地方。
2024年中，深度求索（DeepSeek）发布了DeepSeek-Coder-V2，一个基于混合专家（MoE）架构的开源代码模型。它的数字看起来不花哨，却很实用：支持338种编程语言，上下文窗口长到128,000个token（约12.8万字）。
一、338种语言到底意味着什么
多数编程助手只调优了最流行的十几种语言。DeepSeek-Coder-V2把覆盖范围从初代DeepSeek Coder的86种直接拉到338种，意义正在于此：企业代码不全是Python和JavaScript。内部查询语言、老牌银行系统、小众嵌入式工具链，都活在长尾里。一个覆盖它们的模型，能减少大量"抱歉，我不懂这套技术栈"的尴尬时刻。对一个还在维护几十年前COBOL或ABAP系统的公司来说，这种广度，决定了助手是真有用，还是只会耸肩。
这个数字来自DeepSeek的论文（arXiv:2406.11931），其中报告了相较上一代Coder从86种到338种的跃升。
二、MoE架构省下的都是真金白银
和DeepSeek其他模型一样，Coder-V2也是混合专家（MoE）系统：2360亿参数的版本，每处理一个token只激活210亿参数。正是这种稀疏性，让一个超大的模型也能便宜地跑起来。160亿参数的版本激活仅24亿，瞄准本地和对成本敏感的部署。对大规模推理的团队来说，真正体现在账单上的，是激活参数量，不是纸面上的总参数。
三、128K上下文能装下一整个代码库
代码很少只在一个文件里。一次调试往往需要你正在改的文件、它的依赖，以及测试它的那部分代码——轻松就是几万token。窗口从16K扩到128K，模型就能一次性把仓库里有意义的一大块放进上下文。DeepSeek说这来自在6万亿额外token上的持续预训练，其中约60%是源代码，其余由数学和自然语言补足。
四、6万亿token换来了什么
Coder-V2不是从零训练的。它从DeepSeek-V2的中间检查点起步，又在6万亿额外token上做了继续预训练——约60%源代码、10%数学、30%自然语言。这正是它一边大幅提升代码和数学能力、一边保住通用语言能力的配方：底座模型本来就会说流利的自然语言，额外的token把它推上编码曲线，却没让它忘记怎么写句子。128K上下文正是这次继续预训练的直接产物，不是事后另加的补丁。
五、它处在什么位置
DeepSeek自己的基准测试把Coder-V2放在代码专项评测上追平或超过GPT-4-Turbo，在编码和数学上超过Claude 3 Opus与Gemini 1.5 Pro。这些是公司自己报的数字；独立用户大体认可这个排序，但精确分数会随设置浮动。对个人开发者，160亿版本能塞进一台内存够的工作站；2360亿版本则是数据中心级别，最好通过API调用。模型在MIT许可下可免费下载、微调、商用（许可证费用约0元），这一点，才是真正改变小团队采用意愿的地方。
代码模型的实用主义
写代码是 AI 最早被验证能省真钱的场景之一。代码模型的价值不在炫技补全，而在能不能理解整个仓库的上下文、遵守团队规范、把报错改成能跑的改动。开发者愿意长期用，靠的是稳定可预期，而不是偶尔惊艳一次。
诚实的局限
本文所有量化结论都可追溯到DeepSeek的技术报告（arXiv:2406.11931）和模型卡；与GPT-4-Turbo、Claude、Gemini的对比是DeepSeek自家的，我们并未重跑。所谓"追平GPT-4-Turbo"描述的是2024年中的基准，此后早已变化。Coder-V2后来被并入DeepSeek-V2.5，专用的Coder接口在API上已经下线，所以今天实际走的路是通用模型，而非独立的Coder版本。请把它当作2024年中那次发布的快照来读。
普通人现在能做什么
- 如果你在维护冷门语言的代码，直接去测Coder-V2的338种语言覆盖，别先入为主地认为你的技术栈不被支持。
- 处理大文件或多文件任务时，刻意用好128K上下文——把相关的依赖关系图一起贴进去，而不只是当前那个函数。
- 在意成本，就优先选160亿（激活24亿）版本本地跑；把2360亿版本留给困难的多文件推理。