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

月之暗面在近期推出了定位於長上下文與複雜編碼任務的 AI 程式設計模型 Kimi K2.7 Code。過去一年，AI 編程工具已經從單純的程式碼補助手，進化成能夠承擔完整開發流程的協作夥伴，Cursor 和 Claude Code 等產品將模型整合進整合開發環境與命令列，國內廠商也紛紛加速跟進。在這樣的競爭邏輯下，模型能否跟隨開發者跑完整個專案，而非僅僅生成幾段程式碼，已成為新的能力門檻。K2.7 Code 正是在這個背景下登場，官方特別強調其在 Agent 工作流與長上下文任務上的表現。從官方公布的基準測試結果來看，K2.7 Code 相比前代 K2.

6 在所有任務上均有提升，長程任務的平均 Token 消耗減少了約 30%。然而更值得關注的是它與頭部模型的相對位置：在三項編碼類基準（Kimi Code Bench v2、Program Bench、MLS Bench Lite）上，K2.7 Code 仍落後於 GPT-5.5 和 Opus 4.8；但在三項 Agent 類基準上，它與 Opus 4.8 的差距明顯縮小，甚至在 MCP Mark Verified 測試中以 81.1 分反超了 Opus 4.8 的 76.4 分。這個成績分布清楚顯示，Kimi 團隊的策略重點是將 Agent 工作流作為追平頭部模型的突破口。

不過，基準分數終究無法完全反映模型在真實工程任務中的實用性。因此實際評測圍繞三個具體場景展開：在一千餘行的 MiniDB 專案中修復隱蔽的邏輯錯誤；生成一個可直接運行的單 HTML 3D 滾球闖關遊戲；以及在不改變功能的前提下，重構一個兩千多行的 Flask 遺留專案。三個任務分別對應程式碼理解與缺陷定位、端到端應用生成、以及遺留系統重構三項關鍵能力。本次測試以 Claude Code 作為 Agent 執行環境，底層模型接入 Kimi K2.7 Code，由前者負責檔案讀寫、命令執行與測試反饋等工程操作，後者則專注於程式碼理解、方案生成與修改決策。

第一個測試任務要求模型在一個包含十大模組、總計 1032 行程式碼的記憶體 SQL 資料庫引擎 MiniDB 中，定位並修復三個刻意埋入的隱蔽 Bug。這三個 Bug 的特點是不會導致程式崩潰，常規執行也不會報錯，唯有在特定查詢時結果與預期不符。測試條件同時規定不得修改公開 API 與測試案例，模型必須在理解既有邏輯的前提下於方法內部完成修復。最終 Kimi K2.7 Code 成功找出三個 Bug，所有測試指示燈從紅轉綠。

其中一個 Bug 的修復路徑尤其值得關注：問題根源在於 is_visible() 方法為空，但真正繞過它的邏輯存在於另一個模組的 _exec_select() 方法中；模型並沒有只修其中一處，而是完整找出了因果關係。另兩個 Bug 則涉及對 SQL 語義的深層理解，包括 NULL 與 0 不應混排、以及 != 遇到 NULL 時不該返回 True 等標準規範。這次修復方案一次通過，沒有反覆試錯與誤判，顯示出模型在陌生程式碼庫中的閱讀與局部修復能力。第二個任務是生成 3D 滾球闖關遊戲，這不僅考驗程式碼寫作，更涉及前端工程組織、3D 渲染、物理反饋、互動控制與遊戲狀態管理等多項能力的整合。

評測團隊分別使用 Kimi K2.7 Code 與 DeepSeek V4 Pro，基於相同提示詞生成單一 HTML 檔案的完整遊戲。遊戲玩法要求玩家透過方向鍵控制平台傾斜，讓球體在 20×20 的方形平台上滾動，繞過障礙物抵達終點，並包含至少三個難度遞增的關卡、重力與摩擦力影響、碰撞反饋，以及關卡與計時資訊的 HUD。Kimi K2.7 Code 生成的版本可直接運行，球體能隨平台傾斜方向順利移動，所有核心功能皆已實現，最終順利通關；雖然畫面仍有穿模等不完美之處。對照組 DeepSeek V4 Pro 生成的版本乍看畫面更精緻，但實際操作中球體幾乎無法正常滾動，也出現類似渲染重疊問題。

這項對比顯示，在此特定提示詞與測試條件下，Kimi K2.7 Code 在物理反饋、互動穩定性與功能閉環上表現更完整。第三項測試則聚焦於遺留系統重構。一個以 Flask 框架撰寫的小型電商後台專案，包含 18 個檔案、共 2,374 行程式碼，存在大量結構性混亂：不同分類的路由各自獨立寫一套、資料庫呼叫與日期格式化函數多處重複、13 個 HTML 模板全部使用行內樣式且沒有任何公用結構。重構的關鍵在於判斷哪些重複可以安全合併，哪些看似相同但因為 URL 或業務邏輯差異而不能動。模型被賦予三項硬約束：所有現有 URL 必須保留、頁面視覺效果不能明顯改變、不能引入新的外部依賴。

結果顯示，Kimi K2.7 Code 在重構過程中展現出跨檔案模式識別、抽象邊界判斷與約束下交付的能力。專案最終從 2,374 行壓縮至 1,064 行，減少約 55%，同時保留了路由參數、業務狀態、頁面入口與統計邏輯，沒有破壞既有功能。從這次評測的三項任務來看，Kimi K2.7 Code 在受控場景中完成了預設目標，顯露出一定的工程協作潛力。但要達到真正穩定的交付，還有一段路要走。真實工程環境中，AI 必須理解舊系統的隱含邏輯、在修復一個錯誤時不引發新的錯誤、能夠處理測試與日誌、並在多人協作與複雜依賴中維持可追蹤性與可回滾。

這也呼應了目前 AI 編程工具競爭的整體轉向：過去各家較量的是底層模型能力，如今隨著 AI 編程進入真實開發場景，競爭焦點正在向 IDE 插件、命令列 Agent、自動化任務執行與協作環境等工具層轉移。本次評測的三個任務儘管精準對應了編碼閉環的核心環節，卻遠未觸及數百萬行歷史遺留代碼、跨團隊版本分支、頻繁變動的產品需求，以及嚴苛延遲與安全合規等工業生產的全貌。這不單是對 Kimi 的考驗，也是所有國產 Coding 模型必須面對的真正勝負局。