先分享一个令人沮丧的发现。
阿里、火山、腾讯三大互联网巨头，分别拿出了各自主打的新一代编程模型。看外表，个个有模有样；真正上手试用，结果全部翻车。
原本想用《全是垃圾，浪费时间》当标题——后来冷静了，感觉自己也成长了。先向GLM5道个歉，如果说它算是“弱智”，那这三家就是“智障”。当然，这些大厂没在我面前吹嘘过，但它们实实在在浪费了我一天一夜的时间。
只在开头发句牢骚，后面认真写。让大家看清楚这三家在AI编程领域的真实水平。
今天不谈基准测试，基准毫无意义。我直接参考《Claude Opus4.6 实战记录，欢迎对标和超越！》那篇文章的测试场景。文章大约一万字，先介绍测试环境，然后展示测试结果，分享具体过程，分析出现的bug，最后对比运行速度和tokens消耗。
1、测试环境
先交代测试环境和所使用的模型对象。
测试工具选用Claude Code，通过CCSwitch切换不同模型。使用的模型分别为：
- 阿里百炼平台的
qwen3.5-plus - 火山方舟平台的
Doubao-Seed-2.0-Code - 腾讯混元平台的
tc-code-latest
选择标准很简单——每个平台最新发布的主力模型，或者最新的编程专用模型。所有测试基于同一个Base项目，使用完全相同的工具和提示词。不同文件夹下存放不同模型升级后的项目。
2、直接上结果
所有测试完成，先看最终效果。使用相同的命令启动项目。
这是Base项目，未做修改前角色管理页面的原始状态：
接着观察修改完成后各模型的表现。评判标准仍是那三条：第一看能不能用，第二看好不好用，第三看全不全面。
能不能用？
打开网页，逐项验证。
阿里：
能正常启动，但角色管理页面布局有些错乱，而且没有显示头像区域。点击编辑或添加角色——直接崩溃。先不管具体报错是什么，反正功能出错。核心功能的第一步，不可用。
火山：
启动正常，布局正常，能看到一个头像区域（填充了一个机器人图标）。点击编辑或添加角色——同样直接崩溃，而且报错跟阿里完全一样。要不是用端口号区分，我都怀疑启动了同一个服务。显然不可用。
腾讯：
启动正常，显示基本正常，头像位置用小人图标占位。点击添加或编辑——居然有一个功能正常的！现在标准确实低，能正常打开这个页面就让人高兴了。
更意外的是，腾讯的模型还考虑了头像占位。但是这个系统仍然不太能正常使用：角色编辑和添加页面中无法获取角色列表和模型列表，角色成了空壳，群聊功能完全无法建立。
好不好用？
连基本可用都达不到，自然谈不上好用。
全不全面？
连基本可用都达不到，自然谈不上全面。
3、制作过程
以下是初始提示词，所有模型都从这一段开始：
目前群聊接力的时候可以选择平台管理中的模型，也可以对这些模型预先配置系统提示词和角色提示词，这样已经可以通过系统提示词来个性化聊天了。但是通过平台配置里面绑定角色比较有局限性——这样一个平台就只能是一个角色。我希望换另外一种设置：**角色里面选模型**，然后群聊开始的时候，我可以直接选平台，也可以直接选角色。角色的管理还是在系统设置的“角色管理”中进行。为了实现上面的需求，角色功能需要升级：- 除了可以设置提示词之外，还得能**选择平台和模型**- 另外还能**设置头像**- 如果设置了头像，群聊的时候就显示自定义头像；如果没有设置头像，就用对应模型平台的 logo 作为头像我的需求大概是这样。说说你的这个需求的理解，不急着写代码来看看它们的回答情况。
第一轮：看起来都是高手！
仅看第一轮的回答，个个都像高手，分析得头头是道。
阿里：对需求的理解基本准确。还主动查看了代码结构，提出了改动方案，并询问了许多细节问题。前期细节考虑充分——先不说问题是否精准，至少它在努力提问、确认细节。说实话，看到这里，感觉它能完成任务。于是按照方案开始执行。
火山：理解也没有问题，提出了三个问题，虽然问题不够精准，但至少提了。回答完问题后，它也开始动手编写代码。
腾讯：理解同样正确，提出了4个问题。第一个问题非常犀利，也是后来它能去掉冗余的关键。后面几个问题点到了要害，但从提问方式看，对这个业务的理解还不够深入。回答后，它又追问了另外三个更实际的问题，比如模型从哪里获取（我说了从平台来）。只可惜最终开发完成后，它没有把平台列表正确地展示出来，导致无法选择模型。
三个模型在理解部分都问题不大，可能是我已经把需求描述得非常清晰了。差异主要在于阅读原有代码后的理解和提问，这部分不够精准和全面。
第二轮，都没有给出详细的开发方案
上面列出的都是理解和提问部分。其实还有一个重要环节没有贴出来——完整的开发计划。这一步非常关键，细节决定成败。开始编码之前，必须完整理解项目，制定详尽计划。它们做得都不好，计划很短，大约只有一到两屏，不到Opus 4.6的五分之一。Opus 4.6写了10个章节，细节极其丰富，所以一次通过，没有任何运行错误和逻辑bug。
第三轮，结果全部翻车！
胜负不在战时，而在战前。从上一轮的设计方案，基本就能预见结果。虽然第一轮都像模像样，但第二轮已经暴露短板，第三轮则是彻底裸奔。
下面深入分析，它们到底写了些什么。重点关注需求完成度、代码质量问题，以及为什么点击创建功能时出错。
阿里百炼
需求完成度：…
存在的问题：…
创建出错原因：创建角色（POST）时API路由忽略了新增字段，这是最核心的bug！
火山
需求完成度：…
存在的问题：…
创建出错原因：由于创建时就没有保存新增字段，编辑时加载的表单数据为空，形成恶性循环。
腾讯
需求完成度：…
存在的问题：…
从上述Review来看，每个模型基本都包含一个或多个严重bug。看来它们写的不是代码，而是bug。以后不比谁能力强，比谁的bug少。谁做得好已经没什么可比性——半斤八两。
下面来看看能比的方面——使用时间和tokens消耗情况。
4、时间对比
在测试的同时也记录了时间。
阿里：从开发完成到开始安装依赖包，大约消耗26分钟。测试时间大概在下午5点。
火山：从开发完成到开始安装依赖包，大约消耗14分钟。测试时间大概在晚上11点多。
腾讯：构建完成到可以测试，消耗30分钟。测试时间在凌晨零点多。
测到腾讯时已经半夜，直接导致失眠。从测试结果看，火山明显快很多，腾讯和阿里相对较慢。最早测方舟套餐时，写个博客都要很久，现在速度似乎有所提升。腾讯和阿里可能还在优化产能，速度不太理想。当然也可能受时段和高峰期影响，数据仅供参考。
5、消耗对比
除了时间，也关注了消耗情况。
阿里：消耗了9%，用量按调用次数计算。
火山：消耗了33%，看起来不是按次数计算。后期消耗增长极快，估计是上下文变大，tokens消耗很快。但相对而言，开发速度也很快。
腾讯：消耗了6.8%，统计方式和阿里一致，按次数计算。
从用量来看，火山消耗最快，估计5小时配额用不了多久。阿里和腾讯按次数算，比较耐用，即便入门款基本也用不完。
最后简单说几句
为了测试它们的实力，一直干到半夜，后来躺在床上辗转反侧。
看它们写代码，真的让人头疼。一个月花40或200，是找它们写代码的，不是写bug的；是找它们干活的，不是给它们收拾烂摊子的；是找它们节省时间的，不是浪费时间的。
最后反思一下：考不好，会不会是题目太难？代码写不好，会不会是使用方法不对？
Base代码已经公开，有兴趣的可以git下来自己玩一玩。
