kimi k3 能力确实有所下降

前提：我在抱怨kimi k3 蠢爆了，可能所有降智

不想说了。对kimi 有点失望。万恶的资本都一个鸟样！
[image]
[image]
[image]
[image]
不想贴了。后面越聊越蠢。
作为一个大模型，竟然问我在终端里使用还是在桌面
问我在mac还是window。
反正我不能驾驭它了，它自说自话去安装opencode了。。。。
我开不开tun模式，agent自己判断好了。
反正就是感觉不思考了。不思考了。这是不思考…

大伙的反应不一：

1，有小伙伴说我的提示词模糊（ps:是很模糊，但这类小伙伴不认为降智了）

2，有小伙伴说 kimi的推理优化爆掉了。（ps: 这类小伙伴承认降智了）

巧不巧，我刚刚正好在玩类似磁力伪装dht节点，收集种子的小玩意。再一次体会了kimi的蠢

首先，我在我的腾讯云轻量服务器上 搭建了dhtsearch，让ai在github上找的。

（ps:这是一个用go写的，伪装dht节点，响应最小必要数据，获取种子后，只请求种子数据，文件列表，也就是一个吸血鬼程序）

因为是私用，所以我让kimi k3 帮忙写了node的小前端。在经过一段时间后。前端fetch后端api的时候卡死了。

然后让kimi k3 （官方订阅199套餐）去寻找原因了。

然后kimi k3找啊找原因，无非就是几点

1，说我电脑上的clash tun内核有问题。

2，kimi k3在测试的时候 curl 127.0.0.1 8ms，认为后端没问题。

（ps：这里要说下，kimi 没直接curl请求我的公网ip后端，直接拿node.js前端配置文件里转发的127.0.0.1测试了，这里就是蠢笨的表现）

之前我问过他，假设几万条数据，服务器能否顶得住

好，这个是前提，上下文中已经说明了查询不会造成大的延迟，也不会fetch失败

哎，反正服务器上超时15秒，没有任何怀疑，却怀疑，网络抖动，本身api查询15秒以上就是个异常（之前上下文中阐述了当前体量数据是秒回的）

也就是说敏感的人都会首先想到服务器上的api响应这么慢，从服务器上找原因，kimi 认为 超时了，只要能访问到。哪怕15秒以上，都是我自己网络抖动问题。

好吧。最后pi ctrl+p有请 deepseek v4 flash正式版出场，opencode go套餐里的

最后判定，爬虫把实例的公网带宽和 CPU 吃满了，HTTP API 被饿死。

对，作为一个有经验，经常debug的工程师，这种敏感是本能的先去服务器上找。而不是kimi降智后这种甩锅网络抖动。。。。。。

这就是蹩脚工程师 体会到的降智体感，竟然打不过ds flash v4正式版！