前幾天的文章里說過，我用Claude Fable 5一天做出了想了很久Coding Agent容器：FanBox。那篇的末尾我留了句話：你那個擱置很久的項目，說不定也就差一個這樣的周末。

結果...周末還沒到，Kimi先來了。

昨天Kimi發布并開源了K2.7 Code。Kimi Code里已經全量切換，你現在打開用的就是它。

我想著正好趁這個機會測一波Kimi Code跑在我的產品里的效果，以及試一試K2.7 Code究竟怎么樣！

昨晚拿它干了兩件事：讓它設計一個動畫，再讓它修我FanBox里的三個bug。兩件事干完，我突然覺得我領悟了硅谷這兩周正在熱議的一個詞：loop engineering。這個放在文章后半說。

測試1：試試Skill和審美

我給Kimi Code的第一個任務，是用我自己的設計skill（Huashu Design）做一個介紹K2.7發布的動畫。

這里有個小插曲，事后復盤才發現。Kimi Code里調skill的正規姿勢，是輸入/skill后從下拉列表里選，它把我機器上裝的一百多個skill全索引了出來，看起來是直接認了我給Codex裝的那個skills目錄，不用重裝。記不住skill名字的人有福了。

但我當時是按Claude Code的肌肉記憶直接敲的斜杠命令，嚴格說沒真正觸發它的skill機制。結果Kimi讀懂了我的意圖，自己在文件夾里把那份SKILL.md翻出來，照著執行了。

流程跑成什么樣呢。它先彈了三個問題跟我確認需求：動畫給誰看、最想突出什么、用在哪。中間它調那個提問工具還報了一次參數錯誤（選項給多了），它自己讀了報錯信息，砍掉一個選項重試，沒用我管。

發完指令后的15秒，沒加速，你看下它的真實速度：

然后是我最喜歡的部分。我的skill里有一條要求：給用戶看真實的設計，而不是用文字描述風格。Kimi的做法是直接拉起三個并行agent，每個按一種設計流派做一版完整的HTML動畫樣稿，還自己截了圖。

這個并行agent的能力，Claude Code里叫subagent，Kimi Code里叫swarm。它調用得非常主動，不用你提。

從我按下回車到三個設計擺在面前，8分鐘。

三個我都挺喜歡的。最后選了中間這版：三角網格像活物一樣緩緩形變，珊瑚紅的幾何塊浮在上面，有種「代碼是活的」的感覺。

順便說一句，動畫的美感是超出我預期的。之前我用Claude Code做HTML動畫，出來的東西總有點像會動的PPT。這次不太一樣，你自己看：

它確實把HTML動畫這個能力用到了挺好的水平。

當然，你也完全可以讓它每次給你10個、20個設計來選（如果你token足夠多的話

測試2：讓它去修Fable 5搞出來的三個bug

做動畫的過程中我發現了幾個bug。不是Kimi的bug，是FanBox的：我在FanBox的內嵌終端里跑Kimi Code，預覽它生成的HTML時，頁面不自適應寬度；agent輸出的長路徑被截斷后點不了；文件區被我拖得太矮時點什么都看不見。

這里有個背景：FanBox是用Claude Code加Fable 5做的，這兩天連發了13個版本。也就是說，我現在是在一個Fable 5寫的App里跑Kimi，讓Kimi修Fable 5留下的毛邊（如果你沒被繞暈的話可以繼續看下去，哈哈哈

三個bug，我就發了三段截圖加描述，20分鐘修完，全程沒碰鍵盤改過一行。

過程里有兩個瞬間讓我對這個模型刮目相看。

第一個，FanBox的前端代碼里有幾個故意寫進字符串的特殊字節（Fable 5寫的），Kimi的文件讀取工具直接拒讀這個20萬字符的文件。它沒卡住，用Python做二進制定位，確認那幾個字節是有意為之，然后全程換用腳本讀寫這個文件。前沿模型挖的坑，它自己爬出來了。

第二個，它改完代碼起本地服務自測，curl返回502。它查了進程、查了環境變量，發現是我電腦上的全局代理劫持了localhost請求，加參數繞過。這個坑我自己踩過，我的Claude配置里專門記了一條。Kimi沒有這份記憶，自己踩出來又自己解了。

修完它還沒完事，跑了語法檢查，構造了三種邊界情況的測試頁面挨個驗證，確認沒問題才匯報。匯報里專門寫了一句：改動只影響預覽端點，「瀏覽器打開」功能不受影響。

這種邊界意識，還挺像個靠譜的老工程師的。

它為什么顯得這么快

兩件事干下來，最直接的體感是快。我差點誤以為我已經不小心用上了高速版本后來查了下發現并沒有...

琢磨了一下，這個快是兩個因素疊出來的。

一個是物理速度，K2.7標準版本吐token就挺快的。

另一個是心理速度：它全程展示思考過程。你能看著它在那想、在那試，等待的焦急感會少很多。這算是產品設計策略的功勞了。以及，也正好和K2.7 Code在模型層面的策略有些關系。他們是強制開啟thinking的（Claude Fable 5也是，我估計thinking這就是可能是保證模型能力的關鍵因素了），關了它API直接報錯。官方還專門優化了過度思考的毛病，比上一代少用30%的思考token。

benchmark這里我就不逐項解讀了，相比K2.6提升還挺多的。

部分編碼基準已經接近GPT-5.5和Opus 4.8。

然后是重點。Kimi官方說下周一，高速版上線：同一個模型，輸出速度5到6倍，常規編程場景180 token/s，短上下文能跑到260。

我忍不住開始狂想：這次做動畫8分鐘，修三個bug20分鐘，都是普速版跑的。除以6，那就是2分鐘做完動畫、4分鐘修完三個bug發個新版本？這速度不敢想。

冷靜講，吐字快6倍不等于端到端快6倍：讀文件、跑測試、還有我自己按回車的速度，都不會跟著變快。所以特么瓶頸在我咯？

人類跟不上了，怎么辦

接著這個「不敢想」往下想，就到了開頭埋的那個詞。

昨晚修bug那20分鐘里，真正閑著的人是我。

說實話，現在這個速度本身我還跟得上：多開兩個窗口，這邊在跑就去那邊派活，邊vibe coding邊想下一個需求，這大致就是人能消化的節奏。

但把它乘以6呢？幾個窗口同時在十分鐘內交活，我連驗收都排不過來。到那時候，喂不飽它的人就是我。agent越快，人想活、派活的速度就越是整條流水線上最慢的一環。

那怎么辦？順著推就是：既然人是瓶頸，那就把人挪出去。human in the loop，變成human out of the loop。

我推到這一步的時候突然發現：難道這就是所謂的loop engineering了么。

Claude Code的負責人Boris Cherny上周發了條X說他已經不prompt Claude了，他的工作是寫loop。你看，連造工具的人都不在loop里干活了。

然后我對著自己昨晚的兩個任務想了想，發現這事我其實已經在做了，只是之前沒意識到。

做動畫那次，我為什么只忙了開頭幾分鐘？因為那個設計skill本身就是我提前寫好的一個loop：先問需求、再出多版真實設計、最后等我挑。Kimi拉起三個swarm并行干活，是這個loop在自己轉；它開頭彈的那三個問題，是我設計進loop里的檢查點。

修bug那次，我為什么后半段徹底閑著？因為修bug這件事我還沒寫loop，我就是裸發三段截圖在那等。

這么一對比，答案自己冒出來了：人不是被趕出loop，是從loop里面挪到loop上面。你設計loop，agent跑loop，你驗收結果。我不會寫代碼，但我能寫SKILL.md（其實也是讓agent寫），寫loop這件事，從來不是工程師的特權。

這也是我現在看模型分工的方式。Claude Fable 5那種又慢又準又貴的，適合開荒：從零到一把loop本身設計對。K2.7這種又快又穩又便宜的，適合守家：在loop里日夜不停地轉。

這也許是Loop Engineering時代該開始出現的任務形態分工，昨晚兩件事它都是獨立從頭干到尾的。我用Fable 5兩天發了13個版本，已經覺得是極限了；高速版上線之后，loop轉起來可能還會再快一大截？

順便，Kimi Code這個CLI自己就是這么迭代的：5月發布到現在，幾乎日更，十幾個版本。工具在日更，用工具的人也在日更。

最后

給想上手的人幾個實用信息。

入口是kimi.com/code，會員49塊起，額度按5小時滾動窗口計，檔位越高次數越多，和Claude Code、Codex的限量邏輯類似，但是更便宜。開發者走API的話，每百萬token輸入6塊5、輸出27塊，緩存命中降到1塊3。

高速版的API定價有個記憶點：6倍速度，2倍價格。

高速版下周一上線，Kimi Code里切fast模式。

至于那個被修好的FanBox，凌晨已經發了個新版本，我給Kimi Code記了一筆。