作者在审查一份由Claude Sonnet 3.7重构的拉取请求（涉及一个TypeScript数据摄取服务，其中有三层异步调用链不当）时，看到了Hacker News上关于Kimi K2.6的讨论。该讨论声称Kimi K2.6在编码基准测试中超越了Claude和GPT-5.5，并提到了LiveCodeBench、SWE-bench等常见测试。
起初，作者对这类“模型在排行榜上获胜”的消息持怀疑态度，因为此类情况屡见不鲜，但模型最终很少投入生产使用。然而，这次讨论的技术深度促使他决定停止阅读观点，转而亲自进行测量。
实验结果出乎作者意料，其结论也并未在任何热门文章中出现。
Moonshot AI发布的公开数据显示，Kimi K2.6在LiveCodeBench中报告的得分接近65-68%，并在SWE-bench Verified中也取得了有竞争力的成绩。这些数字在Moonshot AI的参考数据集中是可重现的。作者指出，具体数字会随模型更新而变化，但重要的是其数量级。然而，所有这些排名榜的结构性问题在于它们缺乏项目上下文。HumanEval提供的是独立的函数；SWE-bench虽然包含GitHub issue及其仓库，但这些仓库很可能已包含在模型的训练数据中。这些基准测试都无法提供开发者在实际工作中面对的、包含特定约定和多年前架构决策的自有代码库，而这些决策可能已缺乏文档。
作者的论点简单明了，并得到了实验的支持：公开基准测试的数字并非虚假，而是因为真实的项目上下文才是真正的考验，而这种考验在任何排行榜中都未体现。一个模型可能在40秒内解决LeetCode中等难度问题，但却无法理解为何在我的代码库中，UserService继承自BaseRepository而非通过组合实现——而这第二个问题却能耗费我数小时。
作者选取了本周工作中的三个真实任务作为实验案例，这些任务均来自实际待办事项列表，并按其出现顺序选取，以避免偏向任何模型。
实验配置如下：Kimi K2.6通过Moonshot API访问，Claude Sonnet 3.7通过其直接API访问，GPT-5.5通过OpenAI API访问。所有模型均使用相同的提示和手动粘贴的相关文件上下文，且不使用任何代理工具，旨在测量模型纯粹的代码生成能力。
案例1：TypeScript异步服务重构。 该任务的背景是一个处理webhooks的服务，其中包含三层嵌套的Promise.all，但缺乏对部分错误的处理能力。