本人不是标题党因此先上图，心急的朋友可以直接看截屏中的总结部分：
故事是这样的，我在写完昨天的《顶极模型大比拼，到底谁才是真正的编程之王？》 一文后就说过一定要与Opus结对试试这个大模型在编程上的实力是不是与它做评测时说得那牛X，毕竟Opus对MindX给出的评测报告非常的忠恳，其实吧昨天没好意思将它对MindX评测的具体内容贴出来，是因为评分实在是太低了。Seed2.0, GLM5, Gemini 给出的都是8分(10分满）以上的高分只有Opus给出的分数根本就不及格，所以昨晚我就和Opus结对从晚上8点干到早上的5点左右，才硬生生地将MindX拉上了及格线。
| 维度 | 上次评分 | 当前评分 | 变化 |
|---|---|---|---|
| 架构设计 | 7 | 8 | ↑1 |
| 核心创新 | 9 | 9 | → |
| 领域建模 | 4 | 4 | → |
| 代码质量 | 6 | 7 | ↑1 |
| 测试覆盖 | 4 | 6 | ↑2 |
| 安全性 | 4 | 7 | ↑3 |
| 应用体验 | 5 | 7 | ↑2 |
| 技术深度 | 5 | 6 | ↑1 |
| 前端质量 | 5 | 7 | ↑2 |
| 构建/DevOps | 7 | 8 | ↑1 |
| 可扩展性 | 6 | 7 | ↑1 |
| 可观测性 | 3 | 6 | ↑3 |
综合评分：6.8 / 10（上次 5.4，↑1.4）
在重新做昨天的4项评估后，GLM5给的评分变化不大毕竟已经8.5/10了，所以我就让GLM5与Seed2给出了在新评估的基础上的重构意见。然后将它们的重构意见给Opus看，问它有什么看法就得到了上述的图。
这能看出了什么？其实并不是想证明谁强谁弱，首先GLM5是开发了MindX大量代码的主力模型之一，Opus只是碰巧有朋友支持暂时给我感受一下。我是想延续昨天的话题，从代码与架构本身上来研判两大模型的特性，这样也能给其它朋友带来一些实际使用的参考。
首先讲讲与Opus这充满燃烧的Tokens的一晚吧，感觉它最大的特点就是"慢、准、稳"。它属于我用过付费模型中最为龟速的，但Opus做结论是比较严谨与慎重，几乎没有怎么出过错，昨晚是对的MindX是属于大规模的重构，涉及的模块广度都几乎横跨整个项目了, 而且干的都是苦活累活，为的是要解决它昨天评测时的一句话：
bash
MindX 是一个有野心、有创意的项目。仿生大脑的认知分层架构是真正的差异化优势，
功能覆盖面（14 渠道、30+ 技能、训练系统）在同类开源项目中属于领先水平。
Go + 嵌入式数据库的技术选型使得部署极其简单（单二进制文件），这对个人助理产品是正确的选择。
但项目当前处于"功能先行、工程补课"的阶段。最突出的三个短板是：
1. **可靠性不足**：LLM 调用无重试、渠道无断路器、WebSocket 无重连，在真实使用场景中会频繁出现不可恢复的错误
2. **性能隐患**：向量搜索全表扫描 O(n)，随着记忆积累会成为明显瓶颈
3. **工程规范性**：分层违规、错误处理不一致、测试覆盖不均、安全漏洞，需要系统性补课如果我是用户看到这样的评价我不会使用这个项目，因为说得太可怕了，短板也太明显了！当然这已经是过去式了，MindX已经没有这个短板了，现在评分上不了8只是因为测试的配套不足导致的，代价是10多个小时的盯屏和100k+ tokens的燃烧。
先不管Opus和GLM的血统与出身，只从客观出发，我是站Opus这边的。因为我也发现国产编程大模型都有着一些共同的问题：
- 模式滥用 ------ 为了解决一些小问题会很热衷于使用设计模式来解决，导致代码量膨胀得很快当然Tokens也烧得疯狂。这一点千问是重灾，但它代码质量一直不行，就是垃圾生成器，所以我一直不提它。
- 测试水平低下 ------ 几乎没找到一个国内模型写测试是有水平的，是所有！全部都是小白水平，连设定，运行检查期望值这种标准三步走都不会，反正每次测试到最后除了让它们生成个方法名，其它的我都是手搓的，实在是太拉了！这可能跟国人从来不喜欢写测试很有关，这样大模型就没有什么高质量的源码参考？
- 速度高 ------ 国内模型的运行速度一定是全球最快的，没有之一。但质量是良莠不齐，理解力也得看具体场景，高级场景有点够呛。
而Opus除了速度几乎没有上述的这些问题，开篇的这个截图其实很是说明问题。方案一，是对复杂性的分解，GLM选择的是更为复杂的方案，Seed2.0选择附议，Opus却认为没有这个必要，因为成本与产出不正比。这波打的可是架构师基本功啊，只有初级水平时才会范为了模式而模式的低级错误的(有经验的老架构一定知道被现实毒打过都会偏向谨慎)。
这可能与中西方走了一条完全不同的发展方式，一个是以量盖面，一个是以质取胜
方案三又是一种在复杂算法的策略问题，GLM并没有评估实际情况，直接选最好的。Opus为这个问题烧了2K多的Tokens后选最适用的。这波选择就真是体现水平了，并且提出的理由字字珠玑，条条在理我也无法反驳。（毕竟，谁斗最大得益者都会是我嘛，嘻嘻）我是挺享受这种看代码"吃瓜"的过程的。
结论
今天可不是吃瓜贴，是有干货的。我的最终目的是找到一种，既快，又稳，而且最省的方式来与编程大模型结对。如果条件允许我会这样来分配，大家可以参详一下，更欢迎在评论区发表各自不同的看法，毕竟有效的讨论会有新思路。
- Doubao-Seed-2.0 - 可作为后端主力，中正，有速度代码质量尚可，出错几率低；
- GLM5 - 前端主力，审美与速度拉满；（后端与架构水平还有待提高）
- Opus - 最严格的老师，用于评估制定开发方案或者重构方案，编写测试。
补充：我今天会将全部新的评测照例push到源码库内，包括今天话题中的三份具体重构方案。有兴趣的朋友可以去源码里面扒一下。