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

由于最近在 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. 上下文过短，频繁压缩上下文导致关键的代码片段丢失。