Kimi K2.7 Code 有多能打？找 Bug，写 3D 游戏，2000 行代码砍失 55％

“AI 编程的难题，正于从天生转向交付。 ”

作者丨宇景

编纂丨马晓宁 李娜(公家号：雷峰网(公家号：雷峰网))

已往一年里，AI 编程东西走出了 Copilot 时代的“代码补全”脚色，最先负担更完备的开发使命——Cursor、Claude Code 把模子嵌进 IDE 及号令行，海内厂商也于加快跟进。竞争的逻辑是以变了：模子写几段已经经不敷，能不克不及随着开发者跑完一个项目才是新的门坎。

Kimi K2.7 Code 就是于这个配景下发布的。月之暗面把它定位为面向长上下文、繁杂编码使命及 Agent 事情流的 Coding 模子。从官方宣布的基准成果看，K2.7 Code 比拟 K2.6 于所有使命上均有晋升，长程使命的平均 token 耗损削减约 30%。

但更值患上存眷的是它及头部模子的位置差异：于三个 Coding 类基准（Kimi Code Bench v二、Program Bench、MLS Bench Lite）上，K2.7 Code 仍掉队在 GPT-5.5 及 Opus 4.8；但于三个 Agent 类基准上，K2.7 Code 与 Opus 4.8 靠近，甚至于 MCP Mark Verified 上反超了 Opus 4.8（81.1 vs 76.4）。这个漫衍申明 Kimi 团队的资源投放重点很清晰——把 Agent 事情流这条线作为追平头部模子的基准线。

不外 Benchmark 其实不能回覆模子于真正的工程使命里是否可用，以是本次测评缭绕三个工程使命睁开：于 1032 行MiniDB项目中修复隐藏 Bug；天生单 HTML 文件的 3D 滚球闯关游戏；于功效稳定的条件下重构 2374 行 Flask 遗留项目。三个使命别离对于应代码理解与缺陷定位、端到端运用天生、遗留体系重构的能力。本次测评存眷的不是简朴代码补全，而是 Kimi K2.7 Code 于 Agent 事情流中可否介入更完备的开发流程。

需要申明的是，本次测试经由过程 Claude Code 作为 Agent 履行情况，接入 Kimi K2.7 Code 作为底层模子。Claude Code 卖力项目读取、号令履行、文件修改及测试反馈等工程操作；Kimi K2.7 Code 卖力代码理解、方案天生及修改决议计划。

01

接办生疏代码库，Kimi 能不克不及找到深层 Bug？

现实开发里，年夜部门时间花于读代码及改代码上，写新功效反而是少数。真正磨练一个编程模子的，是它能不克不及进入一个从没见过的代码库，找到藏于逻辑深处的问题。

测评1：于 1032 行数据库引擎中定位并修复 3 个隐藏 Bug

咱们随机拔取了一个MiniDB 数据库项目测试，这是一个纯 Python 实现的内存 SQL 数据库引擎，共 1032 行，笼罩词法阐发、递归降落解析、B-tree 索引、事件治理、查询履行等 10 个模块。

此次埋入的三个 Bug 都较为隐藏，其实不会致使步伐瓦解，通例运行也不报错，问题只表现于查询成果与预期纷歧致。以是于举行测评时同时约束——不克不及改公然 API及测试用例，模子必需于读懂现有逻辑的条件下，于要领内部完成修复。可以看到，Kimi K2.7 Code 乐成修复了三个bug，所有测试面板唆使灯从红色变为绿色。

于 1000 行生疏代码中定位隐藏逻辑缺陷，是对于模子代码理解深度的极限测试。及格的编程模子不该仅能天生代码，更需于无先验常识的前提下，穿透表层逻辑，正确辨认深层过错并给出准确修复。

这个成果的修复路径值患上存眷。

Bug 2 的底子问题是 is_visible() 是个空要领，而真正绕过它的逻辑于 _exec_select() 要领里—两个要领分属差别模块，很轻易只修复一个而漏了另外一个，模子此次把完备的因果瓜葛都找了出来。Bug 1 及 Bug 3 则依靠对于 SQL 规范的语义理解：NULL 及 0 不应混排、!= 碰到 NULL 不该返回 True，这些约束写于 SQL 尺度里，只靠纯真的语法阐发是揣度不出来的。修复方案一次经由过程，未呈现重复试错或者误判。

至少于这个界限清楚的受控使命中，Kimi K2.7 Code 体现出了较强的生疏代码浏览及局部逻辑修复能力。但它可否不变迁徙到更年夜范围、更繁杂依靠的出产项目，还有需要更多样本验证。

02

天生 3D 游戏：DeepSeek 及 Kimi 谁赢了？

写一个函数、补一个组件，大都模子都能胜任。但若要求模子于单个 HTML 文件中天生一个可直接运行的 3D 滚球闯关游戏，使命难度就不只是写代码，而要同时考查前端工程构造、3D 衬着、物理反馈、交互节制及游戏状况治理这些能力。

测评2：别离利用 Kimi K2.7 Code 及 DeepSeek V4 Pro 基在不异提醒词天生一个单 HTML 文件的完备 3D 滚球闯关游戏。

游戏焦点弄法是：玩家经由过程标的目的键节制平台歪斜，让球于平台上滚动，绕过障碍物，终极达到尽头。

详细的提醒词包括：

一块 20×20 的方形平台，平台边沿有围墙，球不克不及失出平台。 至少 3 个难度递增的关卡，每一关有明确出发点及尽头。 球体受重力及磨擦力影响，随平台歪斜标的目的滚动，遇到障碍物时有碰撞反馈。 标的目的键节制平台歪斜，松开按键后平台迟缓回正，歪斜角度不克不及跨越 90 度。 界面左上角需要显示当前关卡、历时及测验考试次数，过关后弹出“Level Clear!”提醒并进入下一关，全数通关后显示总历时及评级，撑持按R键从头最先当前关卡。

本次评测主重点存眷几个维度：游戏是否至少能正常经由过程三个关卡、画面是否能正常显示、球体的运动逻辑是否切合预期。

Kimi K2.7 Code 天生的版本可以或许直接运行，从视频中可以看到，于三个差别关卡中，球体均可以随平台歪斜标的目的滚动，Prompt 中列出的平台、围墙、障碍物、尽头标识及 HUD (关卡数、计时、测验考试次数)也都实现了，终极进入右下角的尽头圆环顺遂通关。可是画面其实不是彻底成熟，视频中段时球体及红色障碍物于视觉上堆叠。

比拟较来讲，DeepSeek V4 Pro 天生的版本乍一看给人的画面感甚至越发精美一些，可是于现实操作中，球于一最先就只逗留于画面左上方，跟着平台摆布歪斜，小球只呈现极小幅度的摆动，其实不切合物理纪律。值患上留意的是，该版本一样存于与 Kimi K2.7 Code 近似的穿模问题——黄色平台摆布歪斜时，边沿会与下方绿色地面呈现衬着堆叠。这并不是个体模子的缺陷，而是当前年夜模子天生 3D 场景的共性问题：模子于天生时没法看到运行成果，几何界限及物理碰撞体的邃密调解凡是需要运行后反馈才能完成，单次天生很难一次到位。

选择天生 3D 这个使命来测，是由于它把多个自力的工程能力压于了一路。3D 场景、物理、碰撞、关卡、HUD——单拎出来都不算难，但要于一个HTML文件里同时跑通，模子就不克不及挑食。哪一块没接对于，游戏就直接不克不及玩。这类 任何一环都不克不及塌 的特色，比让模子零丁写一个组件更靠近真实工程的样子。

是以，于本次单 HTML 3D 游戏天生使命中，Kimi K2.7 Code 的输出更切合预设要求。特别是于物理反馈、交互不变性及功效闭环上体现更完备。但这一结论仅限在本次 Prompt 及测试前提下的成果对于比，不克不及直接等同在更广泛的前端工程能力排名。

03

重构能力测试：2000+ 行 Flask 项目革新

遗留体系中最多见的困境并不是功效缺掉，而是代码债聚集到无人敢动。重构能力最磨练模子是否具有体系级的抽象思维。

它需要辨认功效界限、消弭反复逻辑、规范化布局，且于修自新程中不粉碎任何已经有功效。这经常比写新代码更难，由于它要求模子理解每一一行旧代码存于的缘故原由。

测评3：于包管所有功效稳定的条件下，将 2000+ 行遗留 Flask 项目重构为布局清楚、可维护的工程代码。

咱们选择了一个用 Python 的 Flask 框架写成的小型电商后台项目作为重构使命。项目共计 18 个文件、2,374 行代码。该项目存于布局性杂乱：卖电子产物、家具、配件的分类页各写了一套路由，逻辑彻底同样，可是并未整合；数据库挪用及日期格局化函数先后都写了多个版本，同时并存于页面中；13 个 HTML 模板全用行内样式，没有任何大众布局可以复用，具体环境以下图所示。

重构的难点于在判定哪些反复可以归并、哪些看起来同样但不克不及动——归并错了可能致使 URL 会掉效、营业逻辑丢掉等问题。是以咱们给模子设置了三个硬约束：所有现有 URL 必需保留，页面视觉效果不克不及较着转变，不克不及引入新的外部依靠。

重构完成后，项目从 2,374 行压缩到 1,064 行，削减约 55%。各文件的详细改动见下图。

测试成果显示，Kimi K2.7 Code 于重构使命中揭示出三个层面的能力：

第一，跨文件模式辨认。

模子没有逐文件做小修小补，而是于路由、数据库拜候、东西函数及模板层中辨认出反复模式。例如，10 个分类路由可以收敛为一个带参数路由，5 套数据库写法可以同一为一套拜候接口，13 个模板中的反复 UI 布局可以迁徙到基础模板及宏中。

第二，抽象界限判定。

重构真正伤害之处，是把“看起来反复但语义差别”的代码误归并。这个测评案例中，模子于削减反复的同时保留了路由参数、营业状况、页面进口及统计逻辑，申明它并不是只于做文本级删减，而是于辨认功效界限以后再做抽象。

第三，约束下交付。

于不改 URL、不改视觉、不加依靠的条件下完成布局收拾，比重写一个新项目更难。它要求模子既能理解旧代码，又能节制修改规模，还有要防止为了寻求看起来美丽的架构而粉碎原有举动。

04

年夜模子走进真实工程，才刚最先接管交付磨练

本次测评的三个使命，正好对于应了这个转向中的几个要害环节：

MiniDB 修 Bug ，考查的是模子可否读懂生疏代码并定位隐蔽问题；3D 游戏天生考查的是模子可否把需求构造成可运行运用；Flask 重构考查的是模子可否于约束下收拾遗留体系。

今朝看来，Kimi K2.7 Code 于这三个受控使命中都完成为了预设方针，显示出必然工程协作潜力。但这间隔真实的不变交付还有有一段间隔。

于真实工程里，能写出代码只是最轻易被瞥见的一环。更难的是后面的部门：它能不克不及理解旧体系里的隐含逻辑？能不克不及于修一个 Bug 时不引入新的 Bug？能不克不及跑测试、看日记、处置惩罚掉败？能不克不及于多人协作及繁杂依靠情况里连结可追踪、可回滚、可审查？

这也对于应着 AI 编程东西竞争的总体转向。已往，模子公司的焦点竞争重要集中于底层模子能力；但跟着AI编程进入真实开发场景，竞争核心正于向东西层及事情流层挪动：IDE 插件、号令行 Agent、主动化使命履行、文件体系及协作情况，正于成为模子公司争取开发者进口的新疆场。

本次测评的三个使命虽精准笼罩了编码闭环的焦点环节，但远未涉及真实工业出产场景的全貌。

于现实工程中，AI需要面临的是数百万行汗青遗留代码、跨团队协同的版天职支、频仍变更的产物需求，以和严苛的延迟、安全与合规约束；还有要处置惩罚残破不全的文档、非标的营业逻辑、线上紧迫妨碍的定位与快速止血，同时必需兼容老旧框架及异构部署情况——

这不仅是对于Kimi的磨练，也是对于所有国产 Coding 模子真实的胜败局。

雷峰网原创文章，未经授权禁止转载。详情见转载须知。