Kimi K2.7 Code 有多能打？找 Bug，寫 3D 游戲，2000 行代碼砍掉 55％

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 v2、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 模型真正的勝負局。

雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。