对 claude code 中的 kimi-k2 表现有些失望。

[javalaw2010]

由于最近在 claude code 中使用 kimi-k2 比较火，我尝试这种方法来完成一个中等强度的需求。

这是一个 PHP 项目，在生产实际运行的商业项目，基于 laravel 框架，经过本人多年坚持不懈的奋斗，终于变成了一个略微合格的小型屎山。这个屎山项目里面包含了一个 VIP 模块，包含了订单处理，订阅处理，会员权益等相关逻辑，其中涉及支付宝、微信、googleplay 内购等 API 、SDK 对接，规模说大也不大，说小也不小。

本次的任务就是尝试重构这个模块，目的是优化面条代码，拆分逻辑，不涉及 API 变动和数据库变动。

首次交代完成任务之后，由于 k2 的 API 比较慢，大约 1 个小时左右，完成了第一个版本。说实话，第一眼看上去还是满惊喜的，代码架构上的变更确实不错，值得学习。但是当我开始人工 review 代码时，这种美好的光景瞬间被打破，整个代码里充斥着相当多的显而易见的问题，比如导入了不存在的类，比如调用的方法传递了错误的参数，甚至参数数量都不对，比如调用了不存在的方法，整体而言，幻觉相当严重。

此时我还是不死心的，告知了他可能存在的错误，尝试让他修复这些问题，随着一番屏幕滚动，任务完成，然而那些问题依旧存在。

我当然不会就此罢手，心想着也许是 k2 上下文太短或者智力太低，那试试一次处理一个问题呢？

我新开了一个 session ，首先让他修复了导入了不存在的类的问题，果然，效果立竿见影，至少表面上看所有的文件中的导入是正确的了。

此时我感觉有了转机，趁热打铁，依葫芦画瓢，让他修复调用方法签名错误的问题，幻想着可以给同事安利这个组合了，然而这次打脸了，并没有能够取得很好的效果。

此时后台显示已经花费了 15 元人民币了，但 k2 写出来的代码甚至无法进入逻辑验证的阶段。

最后我想了一下，k2 的效果不好，可能是多方面的原因：

1. 模型对 php 项目的支持不好，php 近年来没落的很快，可能没有足够高质量的代码供给大模型训练，再加上弱类型动态脚本语言，难以通过工具直接发现语法/代码错误，也许整体大模型对 php 支持都偏弱。

2. claude code ，这玩意儿本身还是针对 claude 自家模型优化的，使用其他模型需要针对优化。也许使用其他的 agent 工具效果会不一样。

3. 上下文过短，频繁压缩上下文导致关键的代码片段丢失。

又尝试了 gemini-cli/和 roocode+kimi2 的方案来解决相同的问题。

gemini-cli 生成的代码乍看起来有模有样，但是 review 过发现很奇怪，忘记导入类，改了类成员变量的名称，使用的地方有的改了有的又没改，对接支付渠道的代码有的写了有的留空没写。有点像上学时班上粗心大意的中等生。

roocode+kimi2 生成了将近 2 个小时，给我整了一个巨复杂的方案，六边形+DDD ，原本 2000 行左右的逻辑，硬生生给我干出来了整整 80 个文件，添加了很多我不需要的逻辑，看起来有点过度设计，最关键的对接支付渠道的代码全给扔了，留了几行 mock 代码。。。

[yibie]

我觉得这未必是 Kimi2 一家 LLM 的问题，如果你能横向对比 Claude 和 Gemini 还有 ChatGPT 之间的表现，也许结论会更准确一些。

[javalaw2010]

@yibie 尝试 Gemini-cli 在同样的项目中完成需求，模型是 2.5pro ，修改的是相同模块，虽然不是相同的需求，但也未能够完成需求，就完成度上来说，甚至体感上来讲比 kimi 还差一些。我晚些尝试下使用 gemini-cli 来完成相同的任务。
基于满血 claude 模型的 cc 我还没试过，太贵了，找中转的话又不知道会不会被换模型，不过 jetbrians 的 Junie Pro 试过，体感上会比 gemini 强一些，不过后来我发现 Junie 其实可以改模型，之前用的 sonnet 3.7 ，晚些可以改 sonnet 4 再试下。

[illl]

可以试试 dpubao1.6 效果还可以

[SiWXie]

kimi2 营销占大头，实测吐字很慢，性能也比 deepseek 差很多，可能连 qwen3 都不如，qwen3 日常使用挺流畅的，中小编程问题也没问题，kimi2 无论是官网版本还是 api 版本，编程没法用（吐字慢+幻觉，老是导入不存在东西）

[he1293024908]

我觉得根源在于模型对话长度，加上这类 ai 编辑器本身就很吃 token ，加剧了健忘症以及对话长度导致的性能衰减，我 augment 也有这个问题，之前项目只有 2 个 py 脚本，加起来 100k 不到，augment 表现非常亮眼，然后我让 augment 重构这个项目，把各个功能拆分出来，结果折腾了整整一下午还没搞定，项目本身其实不复杂，但依然是各种 bug 和冲突，甚至我已经强调 xx 功能使用原项目的实现方式，依然给我瞎编

[micean]

别用 cc ，用 cline/roocode 会好一点
我也在探索后端现存项目介入 videcoding 来规范化开发，好处是显而易见的，注释多了很多，方便生产文档。效率上尽量想取得平衡，因为实际上人脑效率高很多，ai 写的我还得做 review ，但是人会累机器不会。。。

[iorilu]

对 AI 来说, 用于是从头写是最简单的, 老项目重构加功能等都很难

[Kelan]

其实回答质量还可以，但是经常工具调用出问题，找不到文件、修改时报错之类的

[zenghaojim33]

有试过 gemini cli 吗？

[yh7gdiaYW]

正常，触及 AI 的能力上限了，现在完全由 AI 编程只适合新起一个脚手架项目，或者改几个功能比较独立的函数

[tt67wq]

改屎山目前的 AI 模型都不咋样

[javalaw2010]

@zenghaojim33 刚试完，也是一坨。。。

[nakun233]

gemini 写规划和优化提示，然后塞给 claude

[yulon]

K2 上下限差别太大了，可能是 MoE 的通病

[Envov]

首先。你用 claude code 就坑了。哈哈。这个真不好用。。。对比下 cursor

[oudioppa]

@micean 别用 cc ，用 cline/roocode 会好一点，是因为 cline 可以自己选模型吗？

[micean]

@oudioppa 体感上任务成功率高点

[tickingMachine]

一方面 cc / gemini-cli (CLI), cursor / vscode+copilot (IDE) 这些产品外壳在实现 AI coding Agent 的时候的工程有差异，另一方面就是模型自身能力（侧重 code/上下文窗口更大..)，所以不太容易客观得出谁好谁差的结论。

民间的风评就是目前 CC 是 CLI 里面最好的，cursor 是 IDE 里面最好的

[081957lF01y265H5]

我也试了 Kimi‑K2 ，确实在真实 GitHub issue 的 SWE‑bench 上表现还行…不过用 Claude Code 呼它出来总感觉会慢，好像是平台那边为了控制成本而限速？

而且甭管多强的模型，GPU 资源和调用成本都是真金白银赔，特别是测试期／调试期经常要临时拉机器。AWS Trainium 能省点训练算力，但短时实测、注重灵活性时，GPU ／ AI 专用算力开销也不少。

我自己常用的方案是：临时在 GCP/AWS 甚至 Azure 上拉按量 GPU ，配合 Spot / 边缘算力，用 NiceCloud 做多平台充值和代理代付，自助开通，不绑卡也不折腾账单，比官网价格更实惠，跑完随时删实例—省成本也省心。

[bunny189]

kimi 就是傻 X 啊，还死贵，效果甚至还比不上豆包

[yibie]

@javalaw2010 Gemini CLI 对 Tools 的使用是很奇怪的，往往因为它没能顺利写入，就会重新自己输出一份完整的文件，再进行覆盖。往往这个时候，Gemini 很容易出现幻觉，而且会消耗大量的 Token 。

我的做法是这样的，让它不要直接修改文件，把需要修改的代码，用 diff 的方式输出在对话。然后把修改好的部分，贴到 Cursor ，让 Cursor 的 Auto 模式下来进行修改。这样子非常精确，不敢说 100% 没有幻觉，但真的比之前精确多了。

[huc2]

cc 有一个问题，我一般是不放心全部交给 AI 的，所以我都是手动 accept ，但是 cc 不是一次性生成完整的代码询问我是否接受，是一部分一部分问我，有时候就 import 了一个包都先问我要不要接受，他再生成接下来的，太麻烦了