作者：筱可，Datawhale成員
一、讓Kimi K3 和 GPT-5.6 Sol來一場全面對比
上週，AI 圈迎來了一位新的硬核開源玩家——Kimi K3，一發布就登頂 Frontend Code Arena 榜首。我們 Datawhale 第一時間對該模型與另一個頂級模型進行了橫向對比測試。我們一直在思考：如何才能讓所有讀者也直觀感受到兩個模型之間的差異？最後想到一個辦法——讓它們重現我們小時候玩過的遊戲。
Kimi K3 是 Moonshot 最新開源的大參數模型，規模達到 2.8 兆級別。官方原文提到，其整體表現仍落後於 Claude Fable 5 和 GPT-5.6 Sol 等最強閉源模型。這次僅選擇 GPT-5.6 Sol 進行橫向對照，並未測試 Claude Fable 5：一是太貴，二是我們的帳號被封了，無法穩定覆測。我們這次主要評估它在 3D 遊戲開發上的能力。許多模型編寫普通前端已經做得不錯了，但 3D 遊戲涉及算繪、碰撞、狀態管理及即時互動，屬於更困難的場景，也更容易看出能力邊界。
於是，我們讓它製作了 5 款童年經典遊戲，並與 GPT-5.6 Sol 使用相同的提示詞進行對照。我們錄製了影片、審查了程式碼、比較了成品的完成度，最後發現：有些遊戲可以直接玩，有些已經接近完成品，有些則還差一截。
二、評價模型：從「能跑」到「能玩」
判斷模型撰寫程式碼的能力，常見的做法是讓它生成單一檔案的前端網頁。這種方式成本低，但看不出在複雜工程中的真實水準。
3D 遊戲開發是更好的試金石：它涉及算繪、碰撞、狀態管理、即時互動，模型不僅要寫程式碼，還要根據頁面的視覺回饋反覆除錯。於是，我們讓兩個模型使用完全相同的提示詞和視覺限制，各自重現 5 款童年經典遊戲，看誰更能跑出好玩的成品。
但遊戲只能比較「誰更強」，無法回答「K3 自己能否獨立交付真實工程」。因此，我們另外給 K3 加了一個非遊戲類的全端後端專案：從零開始搭建資料庫、編寫 REST 介面、跑通前端算繪，全程無人工介入。
Kimi K3 採用 Kimi Code + WebBridge，GPT-5.6 Sol 採用 Codex。唯一的變數是模型本身及其對應的 Agent 工具鏈。
三、Kimi K3 和 GPT-5.6 Sol：5 款童年經典遊戲逐一對比
1. 植物大戰殭屍
打開 Kimi K3 的版本，可以看到綠色草坪、殭屍推進和土豆地雷爆炸等畫面。但在遊玩時會發現，它只有無盡波次，沒有選關、暫停、星星評分，也沒有勝場統計。而 GPT-5.6 Sol 的版本除了核心的對戰機制外，還製作了選關介面、星星評分和勝負統計。
從程式碼結構來看，Kimi K3 將所有系統內聯在單一檔案中，存檔直接進行讀寫。GPT-5.6 Sol 則拆分為多個模組，額外加入了預設存檔邏輯和資料驗證。
Kimi K3 打開就能玩，但玩個幾局後會覺得缺乏目標感和進度回饋。GPT-5.6 Sol 的流程較長，有明確的關卡與評價體系。
Kimi K3 - 植物大戰殭屍
GPT-5.6 Sol - 植物大戰殭屍
2. 合金彈頭
Kimi K3 的版本可以看到自訂角色的算繪，但敵人種類比 GPT-5.6 Sol 少了兩種。遊玩時最明顯的差異是，死亡後遊戲直接結束，無法續關。GPT-5.6 Sol 則設有檢查點，死亡後可以從中斷點繼續。
從程式碼結構來看，Kimi K3 使用圓形碰撞判斷，檔案組織偏緊湊。GPT-5.6 Sol 使用矩形碰撞箱，結構上更接近標準遊戲架構。
Kimi K3 的畫面有自己的風格，但容錯率較低，死亡成本高。GPT-5.6 Sol 的敵人更豐富，容錯率更高，更接近街機原版體驗。
Kimi K3 - 合金彈頭
GPT-5.6 Sol - 合金彈頭
3. 拳皇 97
K3 版本有角色選擇和難度選擇，必殺技回饋密集，人物算繪細節優於 GPT-5.6 Sol 的方塊人。但缺少舞台選擇、血量/時間/傷害倍率等規則調整，設定項也沒有進行持久化（非永久保存）。
GPT-5.6 Sol 則將這些選項全部做齊，規則可以保存，更像是一款能反覆調整著玩的格鬥遊戲。
Kimi K3 - 拳皇 97
GPT-5.6 Sol - 拳皇 97
4. 魂斗羅
K3 版本一打開就能玩，射擊和移動都很正常，但缺少標題畫面、選關、暫停和接關功能；懸浮的陸地僅有視覺效果，角色無法站立其上。
GPT-5.6 Sol 製作了完整的街機流程，平台碰撞機制生效，更接近完整的街機體驗。
Kimi K3 - 魂斗羅
GPT-5.6 Sol - 魂斗羅
5. 戰車大決戰
K3 版本的核心機制如基地保護、升級、地雷等一應俱全，但缺少選單、暫停、關卡返回和關卡管理等功能。
GPT-5.6 Sol 具備完整的選單系統、暫停選單、結算介面和關卡配置驗證，更像是一款能長期開啟遊玩的遊戲。
Kimi K3 - 戰車大決戰
GPT-5.6 Sol - 戰車大決戰
四、從 5 款遊戲看 Kimi K3
判斷維度共有五個：能不能直接玩、畫面完成度、操作手感、規則完整性、聰明程度。
K3 的優勢：5 款遊戲都能直接打開玩，核心機制成立；植物大戰殭屍與拳皇 97 的視覺氛圍濃厚，高光回饋密集；能在提示詞之外主動加入星星升級、武器切換等內容；在某些特定點（如角色算繪）上甚至優於 GPT-5.6 Sol。
K3 的短板：規則完整性普遍不足。大多數遊戲缺少選單、暫停、選關、存檔驗證等外圍流程；部分遊戲死亡懲罰過重、容錯率低；單款遊戲的 UI 精緻度參差不齊。
GPT-5.6 Sol 的成品感更強，因為它將運算資源花費在玩家不會稱讚、但缺少就會出戲的地方：選單層級、規則持久化、邊界驗證、螢幕特效。
效率上也存在差距。GPT-5.6 Sol 在 Codex 上合理利用了子 Agent 的併發處理，完成時間約為 K3 的 25%，token 消耗也更節省。但 GPT-5.6 Sol 的 API 定價較高，加上跨境存取與支付門檻，台灣本土個人開發者的實際使用成本反而更高。K3 雖然單次任務消耗的 token 較多，但在國內可以直接存取，進入門檻較低。
五、橫向對比之外：純 K3 製作一個帶資料庫的全端專案
遊戲對比能直觀展示兩個模型的差異，但也有一個侷限：場景相對單一，主要測試前端表現力；而且前面 5 款遊戲無論有沒有後端，我們都沒有將資料庫部分作為呈現重點。我們還想知道，當任務從「寫一個好玩的頁面」切換到「非遊戲類的真實全端工程」，需要資料庫設計、REST 介面、前端聯調一起跑通時，Kimi K3 能不能獨立完成。
於是，我們單獨給 K3 佈置了一個全端專案：基於開源專案 https://github.com/li-xiu-qi/paper-graph-manager（論文引用關係圖譜管理系統），讓它自己從零開始跑通後端、補齊介面、驗證前端算繪。整個過程沒有手動介入除錯，全部由 K3 獨立完成。
1. 環境啟動與相依套件修復
K3 的第一步是安裝相依套件並啟動服務。它正確識別了 FastAPI 後端需要的所有相依套件並完成安裝，隨後執行 uvicorn main:app --host 0.0.0.0 --port 8001 啟動服務。
啟動過程中，它連續遇到三個 ModuleNotFoundError：dotenv、pyvis、kimi_agent_sdk。K3 判斷這些都是環境相依性问题，而非程式碼 bug，於是逐個安裝後，服務成功在 http://localhost:8001 上運行，健康檢查返回 ok。
2. 後端功能實作與介面驗證
核心需求是為論文引用關係增加完整的後端能力。K3 改動了三個檔案：
• database.py：新增 paper_references 資料表，包含複合主鍵、外來鍵、索引；
• graph.py：新增 build_reference_graph() 和 export_reference_html()；
• main.py：新增 4 個引用端點 + 2 個圖譜端點。
為了驗證交付品質，K3 在全新連接埠 8002 上進行了 8 步端到端測試，全部通過：入庫論文、新增引用、查詢 outgoing/incoming、取得 graph、匯出 HTML、刪除引用、刪除後驗證為空。新增測試 36 個全部通過；全量測試 134 個 passed、2 個 failed，K3 使用 git stash 撤回自己的改動後，這 2 個失敗依然存在，證明這是專案預存的 legacy 問題，與本次功能無關。
3. 前端聯調與真實頁面算繪
後端跑通後，K3 繼續處理前端。啟動 Vite 時遇到路徑別名報錯：Failed to resolve import "@/lib/utils" from "src/components/ui/dialog.tsx"。這是一個典型的工程化問題：前端能跑得起來，但程式碼中殘留了未正確配置的別名引用。
K3 並沒有卡住，而是透過 Kimi Code 的 WebBridge 直接控制瀏覽器驗證頁面狀態：注入 JS 偵測 rootLen，確認頁面從 0 增長到 30081，這說明前端確實已經完成算繪。
最終頁面成功算繪。Paper Graph Manager 儀表板首頁展示了總論文數、已標註數、筆記覆蓋率、最近入庫論文列表（如 Mistral 7B、Verifiable Fully Homomorphic Encryption），以及論文管理、知識圖譜、智慧聊天、筆記管理等模組入口。
六、寫在最後
Kimi K3 在呈現效果、遊戲邏輯和操作流暢度上表現優異。作為開源模型，能達到這種完成度已然是少數能打的佼佼者，可說是中國開源模型參數的里程碑。
不過就在昨天，K3 因為算力不足，已經整體關閉了購買管道，這也說明 Kimi 相當在意老使用者的體驗。有興趣的朋友們，可以等他們算力充足後再購買體驗。
但若把標準拉高至「能直接發給玩家反覆開啟遊玩」，K3 在系統完整度、規則嚴謹性和包裝層面上還存在顯著落差。它更適合用於快速產出可玩的原型，而不是一步到位的完整產品。
除了橫向對比之外，全端專案補上了另一層面的檢驗：K3 能看懂既有專案結構，區分環境問題與程式碼問題，獨立完成資料庫設計、REST 介面和前端聯調，並透過瀏覽器自動化驗證真實算繪。這說明它的能力邊界不僅限於前端頁面，真實的後端工程也能端到端跑通。
如果你正在考慮是否採用 K3：它在核心玩法實作上已具備可玩性，在真實後端工程中能獨立跑通，在角色算繪、視覺表現等特定點上還具備優勢。但如果你需要的是開箱即用的完整產品體驗，它在系統完整度和工程規範上還有追趕的空間。從遊戲案例的完成度來看，K3 已經接近頂級閉源模型 90% 以上的水準。你搶到 Kimi 會員了嗎～