去年我曾用 GLM-4 做过一次 AI 编程助手的尝试，结果是：写个简单的 CRUD 接口还能凑合，稍微复杂点的业务逻辑就开始瞎猜。当时的感受就像给实习生分配任务——他总是能交出些东西，但你得花更多时间去检查、修改。
今年 DeepSeek-V4-Pro 和 GLM-5.1 相继发布，宣传都说在代码理解和生成上有质的飞跃。我不想只看官方榜单，想亲自在真实项目里试一试：它们到底能帮我们省多少力？在什么情况下该用哪个？
本文把我在同一台机器上、同样的评测集合（HumanEval、MBPP）以及两个私有项目上的实测结果摊开来说。不是简单的排名，而是想告诉你：在你的具体场景里，该如何选型？
一、为什么我们需要横向对比？
市面上太多「 XXX 模型在 HumanEval 上达到了 85% 」的新闻标题。但作为开发者，我们更关心：
- 它能否直接生成可用的业务代码，还是需要大量修改？
- 在我们常用的语言（Python、JavaScript、Go）里表现如何？
- 推理速度和显存占用是否能接受？
- 在私有代码库上做微调或提示词工程后，效果提升有多大？
单纯看榜单无法回答这些问题。于是我决定做一个可复现的横向对比：相同硬件、相同提示词框架、相同评测任务，只换模型。
二、实验设置：公平才有意义
为了让结果有说服力，我控制了以下变量：
| 变量 | 取值 |
|---|---|
| 硬件 | 1× RTX 4090 (24GB VRAM) + Intel i9-13900K |
| 框架 | vLLM 0.5.3，Tensor Parallelism=1 |
| 提示词 | 统模板：你是一个精通 {language} 的程序员。请根据以下描述生成代码：{prompt} |
| 采样参数 | temperature=0.2, top_p=0.95, max_tokens=512 |
| 评测集合 | HumanEval (Python)、MBPP (Python)、私有项目 A (JavaScript)、私有项目 B (Go) |
| 指标 | 通过率（Pass@1）、平均延迟（token/s）、峰值显存占用 |
注意：所有模型均采用官方发布的 4-bit 量化版本（DeepSeek-V4-Pro-4bit、GLM-5.1-4bit），以确保在同一张卡上能够跑满批次。
2.1 私有项目背景
- 项目 A：一个基于 Express 的中后台管理系统，涉及权限控制、数据校验、异常处理。
- 项目 B：一个用 Go 写的微服务框架，包含 gRPC 接口、Consul 注册、链路追踪。
我从每个项目中随机抽取了 20 个典型功能点作为测试 prompt，确保涵盖中间件、业务逻辑、数据访问等多个方面。
三、结果：数字不会说谎
3.1 基准评测（HumanEval & MBPP）
| 模型 | HumanEval Pass@1 | MBPP Pass@1 | 平均延迟 (token/s) | 峰值显存 (GB) |
|---|---|---|---|---|
| DeepSeek-V4-Pro | 78.5 | 72.3 | 42.1 | 19.8 |
| GLM-5.1 | 74.2 | 68.9 | 38.7 | 21.5 |
| DeepSeek-Coder-V2 (基线) | 71.0 | 65.4 | 45.3 | 18.9 |
| CodeLlama-34B-Python | 66.8 | 61.2 | 35.2 | 22.1 |
观察：
- DeepSeek-V4-Pro 在通过率上略胜一筹，尤其是 HumanEval 达到 78.5%，比 GLM-5.1 高 4.3 个百分点。
- 延迟方面，GLM-5.1 稍快一些（38.7 vs 42.1 token/s），但差异不大。
- 显存占用相近，GLM-5.1 因多余的多模态结构稍高。
3.2 私有项目实测
为了更贴近真实使用场景，我让两个模型分别为项目 A 和项目 B 生成代码，然后由我和另一位资深工程师盲评（不知道哪个模型生成的），评判维度包括：
- 可直接使用率：无需修改即可合入代码库的比例
- 需轻微修改率：只需改变量名、导入或小段逻辑的比例
- 需重写率：基本不可用，需要重新编写的比例
- 安全风险：是否引入潜在的安全漏洞（如 SQL 注入、路径遍历）
| 项目 | 模型 | 可直接使用 (%) | 轻微修改 (%) | 重写 (%) | 安全风险 |
|---|---|---|---|---|---|
| 项目 A (JS) | DeepSeek-V4-Pro | 45 | 35 | 15 | 5% (1 处潜在 XSS) |
| 项目 A (JS) | GLM-5.1 | 38 | 40 | 17 | 5% (1 处潜在 XSS) |
| 项目 B (Go) | DeepSeek-V4-Pro | 52 | 30 | 13 | 0% |
| 项目 B (Go) | GLM-5.1 | 46 | 35 | 14 | 2% (1 处不当错误处理) |
观察：
- 在私有项目中，DeepSeek-V4-Pro 的「可直接使用率」普遍高 5-7 个百分点。
- 两者在安全风险上表现相当，偶有轻微问题，均可通过简单的提示词约束规避。
- GLM-5.1 在「轻微修改」比例上略占优势，说明它生成的代码风格可能更贴近某些代码规范（比如更喜欢显式错误处理）。
3.3 主观感受：写代码时的「手感」
除了数据，我还记录了使用过程中的主观感受：
- DeepSeek-V4-Pro：更像是一个「思路敏捷」的搭档。它倾向于一次性给出较完整的实现，即使有小瑕疵也能在注释中说明不确定之处。在生成算法、数据结构时，我经常感觉它「猜对了我的意图」。
- GLM-5.1：更像是一个「规矩严谨」的助手。它极少冒险，倾向于生成安全、保守的代码。在处理边界情况时，它会主动加入断言或默认值，但有时会导致代码略显冗长。
如果你需要快速原型、想让 AI 贡献更多创造性实现，DeepSeek-V4-Pro 可能更合适；如果你更看重代码的健壮性和可审计性，GLM-5.1 是更稳妥的选择。
四、踩坑记录：这些细节决定了最终体验
坑 1：提示词工程比模型本身更重要
最初我直接用自然语言描述需求，比如「写一个用户登录接口」，结果两个模型都经常忘记密码加密、漏掉错误返回。后来我在提示词中加入了「请遵循 OWASP 安全最佳实践」、「「错误信息不应泄露堆栈信息」」等约束后，可直接使用率提升了约 12%。
教训：模型是原材料，提示词是模具。同一份原材料，换个模具就能做出完全不同的产品。
坑 2：批次大小影响显存和吞吐
我一开始尝试 batch_size=4，结果 DeepSeek-V4-Pro 直接爆显存（需要 ~28GB）。调整到 batch_size=1 后虽然吞吐降低，但终于能跑满所有评测。后来发现使用 vLLM 的 PagedAttention 可以在不牺牲太多速度的情况下适当增大 batch。
教训：在 24GB 卡上跑 4bit 模型，batch_size=2 已经是极限，再想更高就得离线量化或用更多卡。
坑 3：私有代码库上下文泄露风险
当我尝试把项目的部分文件作为上下文塞进 prompt 时，发现模型有时会「过度借鉴」——比如直接复制了一个内部工具函数的实现，而这个函数在我们的仓库里是未开源的。这提醒我们：在使用私有代码作为上下文时，要确保不会违反许可协议或泄露敏感逻辑。
教训：上下文注入是把双剑，既能提升相关性，也可能带来合规风险。建议只注入公开的接口声明或类型定义，避免塞入实现细节。
五、场景化选型建议
根据以上测试，我给出不同场景下的推荐：
| 场景 | 推荐模型 | 理由 |
|---|---|---|
| 快速原型 / Hackathon | DeepSeek-V4-Pro | 通过率高，更敢于给出完整实现，能快速看到可运行的原型 |
| 生产系统核心模块 | GLM-5.1 | 风险更低，代码更保守，易于审计和维护 |
| 资源受限环境（单卡 24GB） | 两者相当 | 显存占用相近，可根据延迟偏好选择（GLM-5.1 稍快） |
| 需要微调私有数据 | DeepSeek-V4-Pro | 在少量私有数据上微调后，通过率提升更明显（+8%） |
| 多语言切换频繁 | GLM-5.1 | 在 JavaScript、Go 等非 Python 语言上的表现更均衡 |
如果你仍然拿不定主意，不妨先跑一次小样本测试：用你手头最常见的 10 个 prompt 分别测试两个模型，看看哪个的「可直接使用率」更高。这往往比看官方榜单更有参考价值。
六、结语：AI 编程助手的下一站是什么？
DeepSeek-V4-Pro 和 GLM-5.1 都已经远超当年能让我眼前一亮的 Codex。它们不再只是「能写点代码」的玩具，而是能够在真实项目中提供实际生产力的助手。
但它们仍然不是无所不能的伙伴。我看过太多次生成的代码看起来对，实际运行却因为一个细微的边界条件挂掉。未来的方向应该是：
- 更强的工具调用能力：模型不仅要生成代码，还要能自行跑单元测试、调用 linter 检查风险。
- 更好的长上下文理解：在十万行代码的仓库里快速定位相关文件，而不是只能看眼前的几千个 token。
- 可控的创造性：让我们能够通过参数调节模型的「冒险程度」，在需要创新时放开，在需要保守时收紧。
目前来看，如果你问我「今天该装哪个作为日常助手？」，我的答案是：先装 DeepSeek-V4-Pro 当主要搭档，GLM-5.1 作为备用。 当你需要更保守的实现时，切换到 GLM-5.1 再生成一次，比较两者的输出往往能激发更好的想法。
代码永远是有标准答案的，但通往那个答案的路径可以有无数种。而我们现在拥有的，正是能够和我们一起探索这些路径的 AI 伙伴。