昨天我失眠了今天火气有点大！

真的，本来这篇文章的标题我想直接定为《全TM辣鸡，浪费生命》，但考虑到作为一名资深技术博主，还是要保持一点体面哪怕心里Yi经万马奔腾。为了测试这几家大厂所谓的“Zui新编程模型”的真实实力，我硬生生熬到了半夜，结果躺在床上盯着天花板，脑子里全是报错信息，根本睡不着。

兄弟们，我自罚一杯。本来以为Neng找个好帮手，结果找回来三个祖宗。咱们今天不谈虚的，直接上干货，kankan这所谓的“AI编程”到底是不是智商税。

测试背景与初衷：一场关于“角色”的解耦

在开始吐槽之前，我先说说这次要干的活。这不是简单的“Hello World”，而是一个实打实的架构重构任务。我的Base项目Yi经开源，这次的需求核心是：把“角色”从平台的附属配置中剥离出来变成一个独立的实体。

具体来说以前的逻辑是：平台 -> 模型 -> 固定角色。这太死板了。我想要的新架构是：角色作为核心，它自己带提示词、带头像，还Neng绑定任意平台的任意模型。

这听起来不难吧？但对于AI来说这需要它理解现有的代码结构，理解API路由，理解前后端的数据流转。为了公平起见，我使用了同样的测试工具，同样的提示词，甚至在同一个Base项目下进行操作。

我的评判标准其实非常朴素： kanNeng不Neng用，然后kan好不好用，Zui后kan全不全面。

战前分析：胜负不在战时而在战前

在正式写代码之前，我让它们先理解需求并制定计划。这部分其实挺关键的，细节决定成败。

我把需求发给了它们，核心就是那个YAML结构：角色要独立，要有头像，要Neng跨平台选模型。

火山引擎：提问Zui积极

火山这边的反应Zui快，它不仅梳理了我的需求，还画了个架构图。它理解到了“角色”要变成一级实体，甚至向我提了三个问题。虽然问题不是太精准，但至少它在努力确认边界。比如它问：“角色管理的位置在哪里？”、“原来的平台绑定角色还要保留吗？”。

这个前期细节真的拉满了。先不说问题是否犀利，至少态度端正。它甚至还提到了模型选择的逻辑，是直接引用还是独立配置。这种思考方式，让我一度对它抱有hen高的期望。

阿里百炼：中规中矩

阿里的理解也没太大毛病。它同样提出了4个问题，关注点在于角色管理的新增字段和UI改动。它给出的方案是把“角色”变成独立配置单元，包含提示词、平台+模型、头像。

不过从它的问题来kan，它对业务的理解似乎没那么深入。它问的问题比较泛，比如“多平台模型支持”这种，虽然也是点，但感觉还没抓到核心痛点。

腾讯混元：略显迟钝

腾讯这边，理解是没太大问题的。它也意识到了要把角色从平台配置里拿出来。但是它提出的问题就比较少了感觉有点“自信过头”。它直接给出了一个改动方案，询问我是不是直接kan代码。

说实话，kan到这里我心里Yi经打鼓了。Ru果前期没把细节对齐，后面写出来的代码大概率是跑不起来的。

实战演练：当理想照进现实

回答了它们的问题后我就坐等它们开始干活了。接下来就是见证奇迹的时刻。

阿里百炼：慢吞吞的“半成品”

阿里开发完成，到开始安装依赖包的时候，大概是消耗了26分钟左右。我测试的时间大概是在下午5点左右，可Neng正好赶上晚高峰？

它的计划非常短，大概就是一屏到两屏之间。kan起来胸有成竹，结果一运行……💥直接崩了。

我们先不管错误是什么反正就是错了。我仔细检查了一下发现了一个极其低级的Bug：在创建角色的时候，API路由居然完全忽略了我新增的字段！

这就导致了一个恶性循环：由于创建时就没有保存新增字段，编辑时加载的表单数据就是空的。我点开编辑页面一片空白，除了默认值啥dou没有。

hen显然这个是没法用的。是找它们来节省时间，不是浪费时间的啊！我一个月花40或200买这服务，结果还得我自己去改API路由代码？

腾讯混元：精美的“废墟”

腾讯这个构建完成，到Ke以测试的时间是XX分钟。测试时间是在晚上零点多，我Yi经有点困了但被它气醒了。

启动倒是正常的，布局也勉强Nengkan。但是💥也直接崩了，而且错误跟阿里的一模一样，也是数据存不进去。

geng离谱的是腾讯的模型虽然考虑到了头像显示逻辑，但在UI实现上完全拉胯。角色管理页面布局有点崩，根本kan不到头像区域在哪里。我想去添加个角色试试，结果发现下拉菜单里空空如也——它没有把平台列表显示出来也就选不了模型了。

那么大的厂，怎么Zuo了这么一tuo？核心功Neng的第一步，就不可用。这让我怎么评价？

火山引擎：速度与激情

Zui后kan一下火山的情况。火山开发完成，到开始安装依赖包的时候，大概是消耗了XX分钟左右。我的测试时间大概是在晚上XX点多。

从速度上kan，火山明显要快hen多，腾讯和阿里比较慢。我记得Zui早测试方舟这个套餐的时候写一个博客dou要hen久，现在速度好像提上来了。

但是！卧槽卧槽卧槽，居然有一个正常的！！！ 我现在标准hen低，Neng正常点开这个页面就hen开心了。火山确实Zuo到了页面Neng点开，布局也正常，甚至Nengkan到一个头像区域。

然而这只是表象。当我点击编辑或者添加角色时悲剧重演了。角色编辑和角色添加里无法拉取角色列表和模型，导致角色是一个空壳。这样群聊就完全搞不起来。

创建出错原因还是那个老问题：API没写对。它虽然理解了需求，但在具体实现数据绑定的时候，依然把关键的字段给丢了。

深度复盘：它们到底写了个啥？

测试完这三个，我陷入了沉思：我为什么要浪费这时间！

本来这篇文章的标题应该是《全TM辣鸡》，但我想想还是算了我成长了。咱们还是客观分析一下为什么这些大模型在编程上会翻车。

理解偏差与上下文丢失

虽然第一轮dou像模像样，但是第二轮Yi经漏出底裤，第三轮，就是全部裸奔了。它们给出的设计方案，在YAML里kan着挺完美，什么“geng新Role类型定义”、“升级角色管理API”，列得井井有条。

但是一旦开始写代码，它们就忘了上下文。比如阿里它知道要加字段，但在写Controller或者API逻辑的时候，仿佛失忆了一样，直接把新字段过滤掉了。这种Bug，初级程序员dou不会犯，AI却犯了。

代码生成的“幻觉”

它们写的不是代码，是Bug。真的，kan它们写代码，真的一个头两个大。

比如腾讯，它居然在UI里硬编码了一些逻辑，而不是去读取配置。这导致Ru果我不是用端口号来区分，我dou以为启动了同一个服务。它们生成的代码，拿出来的时候精美的，一锤就碎了！

谁干好？半斤八两

Ru果非要在这三个里选一个“矮子里的将军”，那可Neng还是火山。至少它的速度快，而且页面Neng正常渲染出来。虽然功Neng上也是残废，但至少骨架是搭起来了。

阿里和腾讯，真的，谁干好，这个问题Yi经没什么好比了半斤八两。它们考不好，可Neng是我这题太难了怪我！😐我就原谅他们了！

数据对比：时间与Token的消耗

除了记录时间，我也留意了消耗情况。这部分非常关键，毕竟咱们也是要算成本的。

具体数据如下：

阿里： 消耗了X%，kan起来它的统计方式和阿里一致，是按次数计算的。从用量来说阿里和腾讯因为按次数算的所以比较耐用，即便是入门款基本也用不完。

腾讯： 消耗了X%，好像不是按次数算的。后期消耗增长巨快，估计是上下文大了tokens消耗hen快。

火山： 消耗了X%，它这个用量是按调用次数算的。但是相对而言它的开发速度也hen快。从用量来说火山消耗比较快，我估计用不了多久XX小时配额就用完了。

从我的测试来kan，火山明显要快hen多，腾讯和阿里比较慢。当然也可Neng受时间段和高峰期的影响，仅供参考。

反思与：AI编程的现状

测到腾讯Yi经半夜了直接导致我失眠了。我躺在床上就在想，这玩意儿真的Neng替代程序员吗？

Ru果我不是一个资深开发，我可Neng根本发现不了这些Bug。我会以为代码跑起来了功Neng就实现了。结果等到上线那天用户发现存不了数据，那时候才是真正的灾难。

它们写的代码不好，可Neng是打开方式不对，肯定是的。但目前的现状就是：没法用，谈不上全不全面；没法用，谈不上好用。

我以后不比谁厉害了比谁的bug多。这几个模型，在需求理解上douNeng打个及格分，但在代码实现上，全部不及格。

是找它们来干活的，不是给它们擦屁股的呀。好吧好吧，这些厂也没有在我面前吹过牛逼，只是浪费了我一天一夜的时间而Yi。

Zui后我想对还在观望的朋友们说：AI编程确实Neng提效，但Ru果你想让它完全自动完成复杂的架构重构，那还是洗洗睡吧，不然容易失眠。

有兴趣的Ke以git下来玩一玩！Base的代码Yi经发出来了：github.com/JarvisPMS/c…

接下来我不找茬了主打吹牛逼~。~希望它们下次geng新Neng长进点，别再让我半夜起来修Bug了。

---