聊DeepSeek的时候，大家通常关注的是它的推理速度和性价比。但我一直觉得，它的代码能力被严重低估了。在我看来，DeepSeek-V2在编程相关任务上的表现，已经可以跟专门训练的代码模型掰手腕了。

先说数据。代码能力哪里来？首先是训练数据里代码的比例。DeepSeek-V2的8.1T训练token里，代码占比明显高于一般通用模型。我没有确切的数字，但从它处理各种编程语言的熟练程度来看，这个比例应该不低。

更重要的是代码数据的质量。GitHub上扒下来的代码良莠不齐，有优雅的工业级代码，也有大一新生的课程作业。怎么筛？DeepSeek的团队显然下了功夫。一个很好的信号是，它在Python类型注解的使用上非常规范。类型注解本身是判断代码质量的一个代理指标——习惯写类型注解的代码库，整体质量往往更高。

另一个细节：DeepSeek生成的代码在边界条件处理上很靠谱。让它写一个文件读取函数，它会记得处理文件不存在的情况、权限不够的情况、编码问题的情况。这些细节在低质量训练数据中经常被省略，模型能学会说明训练数据里有大量考虑周全的代码。

在编程语言覆盖面上，DeepSeek做得也很全面。主流的Python、JavaScript、Java、C++不用说，比较小众的Rust、Go、Kotlin也能写出像样的代码。甚至在一些已经不那么流行的语言上——比如我试着让它写了一段Perl的文本处理脚本——竟然也能跑通，虽然代码风格明显是自动学习了各种Perl风格的混合体。

语法准确性方面，DeepSeek的表现相当稳定。我测过的模型里，有些写Python会混入JavaScript语法，有些写Rust时生命周期标注错误百出。DeepSeek在这方面的错误率明显更低。我猜这跟他们的多语言数据配比和质量控制有关，每种语言都有足够的代表性数据，模型学会了在不同语言的语法空间之间做清晰的切换。

如果说语法是代码能力的及格线，那逻辑推理就是区分好坏的分水岭。让我印象深刻的是，DeepSeek在处理需要多步推理的算法题时展现出的“思维链”能力。

比如我让它实现一个带权重约束的最短路径算法，它不光是扔给你一段代码，而是在生成代码之前先做了合理的分析：先判断这属于哪类问题，讨论可行的算法选择，说明为什么选这个不选那个，然后才写代码。这种先思考再编码的模式，说明模型在代码生成时激活了与推理相关的内部路径，而不是简单地从记忆中检索相似代码。

当然也不是完美的。在一些比较tricky的边界条件上，它还是会犯错。比如处理循环依赖、处理并发竞争条件、处理浮点数精度问题时，偶尔会给出看似正确实则存在隐患的代码。这些场景在训练数据中占比相对低，模型自然学得不够扎实。

DeepSeek的代码能力还有一个容易被忽视的应用场景：代码审查。比起让它从头写代码，我更常用它来review代码。把一段代码贴给它，让它找出潜在的问题和改进建议。在这个任务上它的表现出奇地好，尤其是能发现一些人类容易忽略的逻辑漏洞和安全问题。

我试过把一个有SQL注入风险的数据库查询函数发给它，它不但指出了注入风险，还给出了使用参数化查询的修改建议，顺便提醒了连接管理和异常处理的最佳实践。这种程度的代码理解，已经不是简单的模式匹配能做到的了。

为什么DeepSeek的代码能力这么强？除了训练数据的原因，我怀疑它的MoE架构也起了作用。代码任务可以细分为很多子类型：语法分析、类型推导、算法设计、模式实现等等。MoE架构天然适合这种多子任务场景，不同的子任务可以激活不同的专家组合。一个专门擅长语法的专家加上一个擅长算法的专家，协同处理一个编程请求，效果可能好于一个通用的稠密模型。

如果这个猜想是对的，那意味着MoE在代码能力上的优势不是偶然的，而是结构性的。未来随着专家粒度进一步细化，代码能力的上限可能还会更高。

让我有点期待的是，DeepSeek未来会不会像一些专门的代码模型那样，支持代码库级别的理解和修改。不只是给你写一个函数，而是能理解整个项目的结构，做跨文件的修改和重构。这需要模型对代码有更抽象的表示能力，以及更长的上下文窗口来容纳整个项目。从DeepSeek-V2的128K上下文窗口和MLA的效率优化来看，这个方向在技术上是可行的。

代码能力这东西，评价标准其实挺主观的。有人看重生成速度，有人看重语法正确性，有人看重算法效率。DeepSeek可能不是每一个单项都是第一，但综合来看，它是我用过的通用模型里代码能力最均衡的一个。既能写脚本也能写系统，既能写应用也能写测试，而且很少出现那种一眼就能看出是AI写的“机器味”。

对于搞技术的人来说，一个好用的代码助手比一个好用的聊天机器人有价值得多。从这个角度讲，DeepSeek的代码能力绝对值得更多关注。