如果你對AI寫代碼的印象還停留在“程序員要失業(yè)了”，那么一組來自真實Game Jam的數(shù)據(jù)可能會讓你重新理解這個問題：有人做了一款游戲，代碼行數(shù)從去年同期的4000行暴增到31000行，足足翻了近8倍，但實際投入的時間居然也翻了一番，達(dá)到了100小時。看到這個數(shù)字，你的第一感受可能是——“效率明明高了，怎么人反而更忙了？”

這就是我們今天想拆解的一個“反直覺數(shù)據(jù)沖擊”。它來自一位參加了三次BOOOM Jam的開發(fā)者。BOOOM Jam是機(jī)核網(wǎng)舉辦的一個游戲創(chuàng)作馬拉松，參與者需要在三周內(nèi)圍繞一個主題開發(fā)出一款游戲小品。在最近這一次Jam里，這位開發(fā)者和藝術(shù)家搭檔Frank制作了一款俯視角射擊游戲《茫室》。游戲的核心機(jī)制很有意思：敵人在光照下無敵，玩家只能在陰影中擊殺它們。不過，更吸引我們注意的并不是游戲玩法，而是它背后的生產(chǎn)方式——這可能是他們第一次完全依靠vibe coding來制作一款Unity游戲。

什么是vibe coding？說人話就是：你不再一行一行敲代碼，而是用一種靠感覺、用自然語言描述需求的方式，指揮AI助手來生成代碼、整理文件、填寫配置，甚至幫你讀聊天記錄、打印待辦清單。整個過程中，人更像一個“指揮家”，而具體的編碼、資源整理、格式轉(zhuǎn)譯這些體力活，都交給了Cursor和Codex這樣的AI代理。音樂音效靠ElevenLabs AI生成，美術(shù)和關(guān)卡由Frank手工制作。就是在這種人機(jī)協(xié)作模式下，那組看似矛盾的效率數(shù)字出現(xiàn)了。

這些數(shù)字之所以值得拎出來單獨說，是因為它揭示了一個被很多人忽略的事實：AI提升效率的方式，并不是簡單地讓我們“做同樣的事花更少時間”，而是徹底改變了我們花時間的方式本身。下面我們就用幾個關(guān)鍵數(shù)據(jù)來逐條拆解這種變化。

第一條：代碼膨脹了，但“膨脹”本身就是一種效率。

在這次項目里，只算Asset/Scripts下的代碼——也就是排除第三方插件后的純項目代碼——總行數(shù)達(dá)到了31000行。去年同一個比賽的項目只有4000行，再往前一年甚至更少。如果單純看代碼行數(shù)，這幾乎是一次接近8～10倍的飛躍。有人可能會質(zhì)疑：“代碼量變大不是壞事嗎？說明寫得啰嗦。”但是在game jam這種極限開發(fā)場景下，代碼量變大的真正原因恰恰是：你終于敢拋棄那些省事但臃腫的第三方插件了。

去年的項目大量依賴了Top Down Engine這類插件，很多邏輯是現(xiàn)成的。而今年，人物控制器、敵人行為樹這些最核心的游戲邏輯，全是靠AI代理一行行堆出來的。這意味著什么？意味著你不再被“有沒有合適的插件”這個條件卡脖子。想實現(xiàn)什么功能，直接描述給AI，它幫你搭出來。代碼量當(dāng)然會漲，但漲出來的這些代碼，恰恰是你過去想加卻不敢加、只能妥協(xié)掉的那些設(shè)計細(xì)節(jié)。而且一個很反直覺的現(xiàn)象是：項目后期的代碼量增長曲線一點都沒有放緩。因為開發(fā)者全程都在“邊造車邊開車邊修車”，倒數(shù)第二天還能一邊修bug一邊加新細(xì)節(jié)，甚至讓Codex跑一遍profiling來分析性能。這在過去幾乎不可想象——對game jam來說，花時間解決性能優(yōu)化問題簡直是奢侈品。

第二條：提交次數(shù)從400跳到1000次，AI幫你養(yǎng)成了更“原子化”的工作習(xí)慣。

用Git管理過代碼的人都知道，commit提交記錄就像工程的“成長腳印”。2022年和2025年的兩次Jam，這位開發(fā)者的提交次數(shù)都在400次左右。而今年，這個數(shù)字直接飆升到了大約1000次。原因不是他忽然變勤奮了，而是AI代理幫他寫了commit message。有了自動生成提交說明的能力，開發(fā)者養(yǎng)成了一種更頻繁、更細(xì)粒度的提交習(xí)慣。每一次小的改動、每完成一個微小功能，都可以立刻提交，而不必等到湊出一大段再統(tǒng)一寫說明。

這種變化看似只是工具層面的小優(yōu)化，但它的連鎖反應(yīng)很深。更原子化的commit意味著項目歷史更清晰，AI代理在理解整個項目、維護(hù)后續(xù)功能時能獲得更準(zhǔn)確的上下文。換句話說，你每一次對AI的“喂養(yǎng)”都變得更干凈了，反過來又進(jìn)一步提升了AI輔助的質(zhì)量。這是一個典型的“好習(xí)慣被工具放大”的正循環(huán)。

第三條：投入100小時，是去年的兩倍——但這是“主動忙”，不是“被動忙”。

番茄時鐘數(shù)據(jù)顯示，這一年game jam的實際投入時間在100個小時左右，是去年同期投入的兩倍。這個數(shù)字也許是最違背常識的：明明AI幫我們寫了那么多代碼，為什么人反而花的時間更多了？背后的解釋其實非常鮮活：去年還在忙另一個項目CATO的工作，精力被分散，而今年AI代理給的正反饋實在太強(qiáng)了。強(qiáng)到什么程度？最后幾天開發(fā)者亢奮到睡不著，一路干到凌晨五點，并且坦言“也算是AI讓我更忙的證明”。

這種“忙”和過去加班改bug、重復(fù)搬磚的“忙”有本質(zhì)區(qū)別。它是一種被創(chuàng)造力正反饋推動的“主動忙”——因為你每提一個想法，AI都能快速實現(xiàn)，迭代的飛輪就轉(zhuǎn)起來了。人的興奮被點燃，于是更愿意投入時間打磨細(xì)節(jié)、反復(fù)嘗試。這恰恰解釋了為什么效率工具并沒有讓人躺平，而是讓人爆發(fā)出更多的想法和投入。效率提升并沒有把你從工作中解放出來，而是把你推向了更前端、更需要判斷和創(chuàng)意的部分。

單看這三組數(shù)字，我們就能還原出一條清晰的邏輯鏈：AI并沒有憑空減少產(chǎn)品的復(fù)雜度，相反，它讓人有能力去處理更大的工程體量、更密集的版本迭代、更細(xì)膩的打磨。而人在這種能力擴(kuò)展之后，自愿地、甚至興奮地把更多的時間填了進(jìn)去。如果你只盯著“代碼生成速度”這一項指標(biāo)，很容易得出“AI讓開發(fā)變簡單了”的片面結(jié)論；但如果你看到代碼量、提交次數(shù)、總工時這三個數(shù)據(jù)同步暴增，你就會明白：AI真正做的，是把“有想法但不敢做、沒精力做”的那堵墻推倒了。

當(dāng)然，這些數(shù)字都源自一個21天沖刺項目的個案統(tǒng)計，它的經(jīng)驗不能簡單外推到所有開發(fā)場景中。但這位開發(fā)者半年多來積累的vibe coding直覺和手感，以及他分享的種種工作流細(xì)節(jié)，確實提供了一些可以被復(fù)用到日常開發(fā)中的思路。接下來我們跳出數(shù)字本身，看看在整個開發(fā)過程中，AI代理到底承擔(dān)了哪些具體的“體力活”，以及為什么這些活兒恰恰是團(tuán)隊協(xié)作里最容易被忽視、卻又最消耗人的部分。

在很多人的想象里，AI編程就是“告訴它需求然后出代碼”，但在實際的團(tuán)隊協(xié)作中，最耗費心力的往往不是寫功能代碼，而是各種瑣碎的轉(zhuǎn)譯和搬運。比如，美術(shù)同事Frank來了一堆素材，文件命名可能是“Reload GUI 指示物開啟.png”“收集探測器成功的聲音.wav”這樣自然甚至有點啰嗦的名字。過去你要一個個改成規(guī)范英文名、手動拖進(jìn)對應(yīng)文件夾、然后在Unity里重新拖拽引用。這些事單獨看都不難，但它們會高頻次、低強(qiáng)度地反復(fù)中斷你的開發(fā)心流。現(xiàn)在，這位開發(fā)者直接把所有美術(shù)資產(chǎn)丟給AI代理，AI能一次性完成導(dǎo)入工程、重命名、替換場景中的UI、修復(fù)關(guān)聯(lián)錯誤，甚至打包上傳到手機(jī)做真機(jī)驗證，整個過程不到半小時。

他們把這種工作稱為“模糊轉(zhuǎn)譯”——把人類隨手弄出來的、不太規(guī)范的產(chǎn)物，轉(zhuǎn)譯成機(jī)器能順暢讀寫的結(jié)構(gòu)化數(shù)據(jù)。游戲開發(fā)里填配置簡直太典型了：劇情對白一開始可能只是Frank寫在Notion文檔里的幾段話，附帶人物注釋和立繪文件的附圖。AI代理可以直接讀取Notion，把對白轉(zhuǎn)成游戲里可讀取的配置表格，同時自動把對應(yīng)的立繪扒進(jìn)工程，并根據(jù)人物注釋決定顯示哪張圖。整個流程可以完全不用打開Unity，也不用手動填寫哪怕一行配置。更妙的是，到了翻譯階段，AI代理還能把游戲里所有分散的對白和提示語收集起來，翻譯成英文，生成一個Notion對照表格，方便朋友YangMann直接校對。校對完后，再讓AI把修改后的內(nèi)容從Notion倒回游戲配置。整個過程沒有引入任何第三方本地化插件，也不用修改原本的數(shù)據(jù)格式。這就是一種純粹靠著AI代理轉(zhuǎn)譯能力實現(xiàn)的、輕量級團(tuán)隊協(xié)作流。

這些工作流的建立，依賴一個非常樸素但很容易被忽略的前提：你的文檔、素材、甚至聊天記錄，最好都放在AI能夠讀到的開放工具里。否則，AI的能力再強(qiáng)也只能被困在你手動復(fù)制給它的幾段上下文里。這次項目中，Notion和Dropbox幾乎承擔(dān)了所有信息中轉(zhuǎn)的職能。而在更極端的情況——比如沖刺期Bug和打磨細(xì)節(jié)激增時，大量口頭需求根本沒有被結(jié)構(gòu)化，全散落在Discord聊天記錄里，根本來不及整理進(jìn)todo。這時他們用了一個叫Discrawl的skill，讓AI代理直接讀取Discord聊天記錄，從弗蘭克的閑聊里扒出那些隨口一提的優(yōu)化建議，避免漏掉任何一個需要修改的細(xì)節(jié)。更夸張的是，他們甚至讓AI接通了一臺小票打印機(jī)，寫好了專門的skill，把todo list直接打印成紙質(zhì)小條。對開發(fā)者來說，看一眼實體紙條的待辦，比盯著電子屏幕更能降低腦負(fù)荷，也算是一種被迫“離線”換來的效率回升。

這樣梳理下來你會發(fā)現(xiàn)，AI代理在這場Game Jam里真正發(fā)力的地方，并不是在某個驚天動地的功能難點上，而是悄悄解決了一連串“說起來不值一提，但做起來持續(xù)消耗人”的摩擦力。這些摩擦力包括：文件命名整理、配置填寫、工具間的數(shù)據(jù)搬運、聊天記錄到待辦任務(wù)的轉(zhuǎn)換、多語言內(nèi)容的流轉(zhuǎn)——它們都不是創(chuàng)造性的核心工作，但恰恰是維持團(tuán)隊協(xié)作不散架的默默無聞的環(huán)節(jié)。過去，我們往往默認(rèn)這些事只能由人去消化，但一個很犀利的現(xiàn)實是：人消化它們的方式往往是忍受，而AI消化它們的方式是自動化。

這也許就是vibe coding之于團(tuán)隊協(xié)作最根本的啟示：當(dāng)AI幫你接手了那些需要“一點注意力、但毫無成就感”的轉(zhuǎn)譯和搬運類工作時，省出來的遠(yuǎn)不止是操作時間，而是一種被持續(xù)打斷的注意力恢復(fù)權(quán)。你可能并沒有變閑，甚至更忙了，但那份忙碌里包含的被動消耗在減少，主動創(chuàng)造的比例在變高。這組來自個體實踐的數(shù)據(jù)和案例目前還遠(yuǎn)談不上“行業(yè)趨勢”或“已被證實”，但如果它代表了一種方向，那么這個方向也許不是AI讓我們少干活，而是AI讓我們終于可以把自己的精力，從那些早就該被自動化掉的瑣碎里打撈出來——哪怕打撈出來后，我們只是心甘情愿地忙到凌晨五點。