kimi k2.5实际需求体验分享

在实际需求从0到1使用kimi k2.5的体验分享

前言

我一直在关注国产的模型，基本上是尝鲜使用过几次，主要之前有稳定的kiro claude，现在还可以白嫖gpt。最近openai的封号行为频繁，所以决定购买fireworks的编程套餐来尝试一下，同时我也拥有glm的编程套餐。fireworks这个套餐应该没有过度量化的问题，如果是超级量化导致的降智，以下当我没说。

每次有新模型推出，我都会简单测试一下，印象中kimi还挺好用的，天气卡和风扇svg都表现得不错。

现在的国产模型两极分化严重，kimik2.5在论坛里有的人说已经超越sonnet4.6，有的说还不如gpt4，glm5也差不多，有点像安卓新机发布后和苹果对比的网友评论的感觉。

我的体验

购买fireworks的套餐主要是为了速度，200tps带来了窜稀的快感。我打算进行一个简单的mes系统demo开发，集成手机端报工与中控发单流程监控端，数据库因为是demo使用sqlite，前端为了方便使用vue3。因为主要是测试模型性能，所以没用已有的项目测试。

拆分需求部分就遇到了困难，这是一个实际与工厂对接的需求，我把工厂方提出的需求发给kimi，结果架构md里出现了很多理解偏差，还自己加了很多不存在的细节。比如报工流程工厂方还没进一步交接，kimi在没和我确认的前提下擅自决定采用扫码报工，即使我在发送前强调未确认的细节与我讨论后决定，kimi还是毅然决然地自己决定了一切，只是象征性地问了下前端后端用什么框架。

解决完架构基本满意后，执行阶段就是快，推荐一下fireworks这个套餐比窜稀还快。运行出现问题，几个小的变量名错误，修复后初见端倪了，前端网页基本三步一个坑，列表显示错位，一点点组件显示不全，很多页面压根就是空文件一个占位。我已红温，重新强调修复后还是修复一个bug引入新的bug的循环。并且在vibe过程中发现mcp调用根本没有，我在claude.md里有简单的约束使用auggie和exa之类的，从头到尾他一个mcp也没调用，换成glm或者opus4.6就完全没问题，在初始阶段就会调用auggie索引确认相关代码然后exa搜索文档之类的。

而且在对话中kimi很喜欢不了解上下文直接开写，开新对话后如果不强调用auggie理解一下现有代码他会直接开个新文件把旧的已经实现的需求再写一遍，到这我感觉已经是我提示词约束太差导致的了。

vibe了3个小时才终于把能看见的bug修完初步能跑。

结局

还没测试glm，但是体感这kimik2.5也太差了，难道是我提示词太精简的原因？因为opus太贵了，我把提示词精简得很极限，但是opus用起来没问题，sonnet4.6也没问题。

这模型让我回到了青春，和gemini2.0p青涩的对话写项目，尝试浑身解数让她理解我(误。

总而言之我体感不如sonnet4.6，甚至有没有sonnet4.5强都是问题，明天我优化一下提示词再试试，如果让我改观我再发个帖子夸一次。