聊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的代码能力绝对值得更多关注。