影片筆記：[中配]Kimi K3 + Claude Code 演示 - Data Science in your pocket

一句話總結

本段影片為 Data Science in a Bucket 頻道對最新發布的 AI 模型 KIMI-K3 進行實時編碼測試，主持人使用 Cloud Code 環境要求模型開發一款基於 Pygame 的雙人遊戲，過程中觀察到該模型思考時間長、Token 消耗高且費用昂貴，但被視為目前性能最佳的語言模型之一。

核心重點

• 模型發布與定位：KIMI 發布了 KIMI-K3，聲稱其性能優於 GPT-5、6-Sogalofable、GN5.2 及 B-1 等模型，被描述為兼具開源特性與優異性能的「最好的人工智能模型」，顯示開源與閉源模型間的差距正在縮小。
• 測試目標與環境：在 Cloud Code 環境下，測試 KIMI-K3 開發一款「設計器遊戲」（Designers Game），技術選型為 Python + Pygame，遊戲模式為雙人熱桌模式（Hotseat）或單人對抗電腦。
• 性能與成本觀察：
• 速度：比前代 KIMI-K2.7 稍慢，思考時間約需 5 分鐘。
• 成本：價格較高，約與 Cloud Sunnit 相當；參數量約 2.8 萬億。
• Token 消耗：前期構思階段消耗約 10 萬 K tokens，編碼階段尚未寫入代碼已消耗約 2 萬 Token，主持人擔憂製作影片的成本過高。
• 執行過程：模型自動處理前置條件（安裝相關庫），並詢問是否繼續；主持人多次點擊「繼續」與「接受」以允許模型寫入文件與代碼。

詳細大綱

1. 模型發布與評價

• KIMI 發布了 KIMI-K3。
• 該模型聲稱能擊敗以下模型：
• GPT-5
• 6-Sogalofable
• GN5.2
• B-1 模型
• 被描述為「最好的人工智能模型」，兼具開源特性且性能優異。
• 觀點指出：開源與閉源模型之間的差距正在消失。

2. 測試環境與目標設定

• 使用工具：Cloud Code。
• 測試對象：KIMI-K3。
• 任務目標：開發一款「設計器遊戲」（Designers Game）。
• 參考依據：文檔指出 KIMI-K3 在遊戲開發方面表現出色。
• 技術選型：
• 平台選擇：Web 或 Python 控制台 + Pygame。
• 最終選擇：Python + Pygame（Pygame 為 Python 遊戲庫）。
• 遊戲規則與模式：
• 遊戲模式：雙人熱桌模式（Hotseat）或單人對抗電腦經典模式。
• 規則設定：使用拿到規則（疑點）、經典規則、標準 Milton Bradley 規則。
• 假設條件：超時算輪功（疑點）。

3. 性能與成本觀察

• 速度比較：比 KIMI-K2.7 稍慢，思考時間約 5 分鐘。
• 成本評估：價格較貴，約與 Cloud Sunnit 相當。
• 參數量：約 2.8 萬億參數。
• Token 消耗細節：
• 前期構思階段消耗約 10 萬 K tokens。
• 編碼階段已消耗約 2 萬 Token（尚未寫入代碼）。
• 主持人擔心製作影片成本過高。

4. 執行過程

• 模型自動處理前置條件。
• 安裝 BiGami 2.61（疑點）及 Biton 3.13（疑點）。
• 模型詢問是否繼續，主持人確認繼續。
• 模型嘗試寫入文件與代碼，主持人多次點擊「繼續」與「接受」以允許編輯。

工具 / 模型 / 名詞整理

• 頻道名稱：Data Science in a Bucket
• AI 模型：
• KIMI-K3
• KIMI-K2.7
• GPT-5
• 6-Sogalofable（疑點）
• GN5.2
• B-1 模型
• Kimiki3 / Kimiki2.7Go（疑點，可能為 KIMI 系列變體或聽誤）
• 開發工具/環境：
• Cloud Code
• Cloud Sunnit（疑點）
• Web
• Python 控制台
• Pygame（Python 遊戲庫）
• 遊戲相關/其他名稱：
• 設計器遊戲（Designers Game）
• Milton Bradley
• BiGami 2.61（疑點）
• Biton 3.13（疑點）

操作流程整理

1. 環境準備：主持人打開 Cloud Code 環境，選擇 KIMI-K3 模型。
2. 任務定義：要求模型開發一款基於 Python 和 Pygame 的「設計器遊戲」（Designers Game）。
3. 技術確認：確認遊戲模式為雙人熱桌（Hotseat）或單人對抗電腦，並設定相關規則（如拿到規則、經典規則、Milton Bradley 規則）。
4. 模型執行：

• 模型開始思考（耗時約 5 分鐘）。
• 模型自動安裝依賴庫（BiGami 2.61, Biton 3.13）。
• 模型詢問是否繼續執行。

1. 人工干預：

• 主持人確認繼續。
• 模型嘗試寫入文件與代碼。
• 主持人多次點擊「繼續」與「接受」按鈕，允許模型進行編輯操作。

1. 成本監控：主持人觀察 Token 消耗情況（前期 10 萬 K tokens，編碼階段 2 萬 Token），並評估費用是否過高。

值得注意的限制或風險

• 高成本風險：KIMI-K3 的 Token 消耗量大（前期構思即達 10 萬 K tokens），費用約與 Cloud Sunnit 相當，對於製作影片或長期使用而言成本較高。
• 響應速度較慢：相比前代 KIMI-K2.7，KIMI-K3 的思考時間較長（約 5 分鐘），影響開發迭代效率。
• 代碼寫入效率：在編碼階段尚未寫入代碼前已消耗大量 Token，顯示模型在規劃與實際編碼之間的資源分配可能存在效率問題。

逐字稿辨識疑點

以下詞彙根據逐字稿原文記錄，可能存在聽寫錯誤、口誤或特定專有名詞，未做更正版：

• 6-Sogalofable：疑似模型名稱或比較對象，聽感不尋常。
• GN5.2：疑似模型或產品版本號。
• 拿到規則：遊戲規則相關詞彙，語意不明，疑為特定遊戲術語或聽誤。
• 輪功：遊戲機制相關詞彙（如「輪功」或「輪次」？），語意不明。
• Kimiki3 / Kimiki2.7Go：與前文提到的 KIMI-K3/K2.7 拼寫不一致，疑為口誤或聽誤。
• Cloud Sunnit：疑似雲端服務或模型比較對象，名稱不常見。
• BiGami 2.61：疑似軟體、庫或遊戲名稱，與前文 Pygame 或 Biton 關係不明。
• Biton 3.13：疑似軟體、庫或遊戲名稱。

可延伸追問

• KIMI-K3 的 2.8 萬億參數具體架構為何？
• 「拿到規則」與「輪功」在該遊戲設計中的具體定義是什麼？
• Cloud Sunnit 具體指代哪種雲端服務或模型？
• BiGami 2.61 與 Biton 3.13 是什麼樣的庫或工具，為何需要安裝？
• KIMI-K3 在開源與閉源模型對比中的具體優勢數據為何？