最近，讓 Agent 持續進化，成了 AI 頂尖大廠共同探索的方向。Anthropic 已經讓 Claude 參與 AI 研發，OpenAI 也在推進自動化研究員。它們正在嘗試把研發過程自動化，讓 AI 參與改進下一代 AI。
豆包從模型這一層給出了另一種路徑：持續升級 Seed-Evolving，讓接入它的 Agent 也能用上更強的 Coding 和多模態能力。開發者沿用同一個 Model ID，就能獲得後續更新。
Doubao-Seed-Evolving，是一個無限進步的模型。
前幾天，豆包將這段時間迭代中表現最佳的版本，正式發佈為 Seed-2.1-pro-0915。
我們通過 Doubao-Seed-Evolving 介面實測這一最新版本。把它接進 Coding Agent 後，我們用 Blender 做了一段白模運鏡，試了四個遊戲，還把一個去年留下的全端項目交給它改造。
01 Seed-2.1-pro-0915 多維度實測
1. 多模態實測：通過程式碼跑齣電影級鏡頭
先看這輪測試裡最有視覺衝擊力的一段成片。它不是直接靠一段提示詞生成的。在交給 Seedance 2.5 轉繪之前，Seed-Evolving 先用 Blender 指令碼做了一版白模運鏡。
這段成片的鏡頭，完整沿用了白模預演的運鏡和畫面構圖。
它把 3D 場景寫成 Blender Python 指令碼（bpy），程序化搭出素體汽車、素體人、街道佈景，運鏡設計成三段式：低角度側面跟拍、4.8 米半徑圓弧環繞、車頭 45 度斜前推近特寫，全程 8 秒 192 幀。中途它還自己修了 Blender 5.2 的 API 變更問題（Action 改為分槽結構後舊寫法報錯），修完重跑成片。
白模把整段鏡頭都提前演了一遍。確認運鏡沒有問題後，我再把視訊和提示詞一起交給 Seedance。下面是當時使用的提示詞：
嚴格復刻參考視訊的運鏡軌跡與節奏。第一段（0-3 秒）攝影機在車身側面低機位平行跟拍，由車尾緩慢橫移至車頭；第二段（3-6 秒）攝影機以車輛為中心緩慢環繞半圈，從右側繞至左前方並逐漸抬升；第三段（6-8 秒）攝影機推近至車頭 45 度斜前方，定格在格柵與車燈特寫。鏡頭運動平緩流暢，不得改變運鏡方向與速度。主體：畫面中央是一台真實存在的量產賽道級超跑，低趴寬體車身，符合現實空氣動力學的碳纖維前唇與固定式尾翼，啞光深灰金屬漆車身搭配簡潔的橙色賽車拉花，大尺寸鍛造多輻輪轂配紅色剎車卡鉗與打孔剎車盤，真實的輪胎紋理，車身表面掛著細密水珠與濕潤反光，輪胎處有淡淡的真實剎車熱煙。移除畫面中所有站立人物。環境：夜晚真實城市街道賽道，雨後濕滑的深色柏油路面自然反射路燈與霓虹燈光，兩側是真實的高層樓宇與護欄後虛化的觀眾人群，暖色路燈與冷色店舖招牌交錯，賽道邊緣有真實的發光指示燈帶，空氣中漂浮淡淡霧氣，整體為真實街景而非概念佈景。光影：真實電影級自然光，以街燈與店舖招牌等實際光源照明，車身呈現真實金屬漆反射與柔和輪廓光，地面為濕潤路面的自然漫反射而非鏡面反射，背景曝光自然偏暗。畫質：照片級真實感，真實攝影機穩定器拍攝質感，35mm 電影鏡頭自然景深與輕微鏡頭眩光，細微自然的膠片顆粒，真實動態模糊，無 CG 感、無概念車塑料感，寫實汽車廣告大片。
只用文字描述運鏡，生成結果常常和腦海裡的畫面差一點。現在程式碼先給出可調整的鏡頭參照，視訊模型再完成最終畫面。偏差少了，反覆生成的測試成本也低了一些。
最終，這個在 X 上爆火的“白模預演＋AI 轉繪”，Doubao-Seed-Evolving 交出了不錯的效果：白模把機位和運動軌跡定了下來，最終成片能夠充分理解其中的視訊資訊，並精準傳遞給Seedance 2.5，讓運鏡有了具體的控制依據，電影級的畫面可控性大大增強。
2. Coding 實測：四個3D遊戲，效果全面
接下來是四個 3D 遊戲。說實話，開始之前，我不太確定它能否全部做出來。3D遊戲很適合驗收模型的產出效果。因為有時程式碼即使跑通了，畫面和操作仍可能有問題，上手之後一下就能發現。
每項任務中，我只提供一份PRD。模型需要在 Coding Agent 的單次 prompt 限制下完成開發循環，並自行判斷何時結束。遊戲完成後，我再上手試玩。下面的視訊都是實際產物，我們一起來看看吧。
坦克大戰
第一個任務是用 Three.js 做坦克對戰。除了玩家控制，還要有能正常交戰的敵方坦克。子彈和碰撞自然不能出錯。在這個 case 裡面，豆包的發揮我感覺是幾個 case 裡面最好的，整個遊戲的體驗度還是比較絲滑的。
我之前也拿過這個 case 測試其他的模型，但是都會有一些問題：1. 要麼是過於模擬模擬真實的坦克，導致方向盤轉動會有一些控制上的難點，互動不是非常友好。2. 有的 AI 跑這個 case 的時候，甚至會出現開火打不中敵對坦克的情況，也就是碰撞檢測有問題。
這一局它在遊戲的真實感和玩家的體驗之間做了不錯的平衡把握。另外需要補充的是，豆包的這個障礙物是可以打掉的，有部分障礙物是可以破壞的，也有部分是不可以破壞的。不管是使用者的體驗還是遊戲邏輯的設計，我覺得都非常符合正常遊戲的標準。
Roguelike 地牢
地牢的要求複雜一些。地圖要隨機生成，角色還得在裡面探索和戰鬥，尋路與掉落也要正常工作。
在這個 case 裡面，還是能夠感受到，豆包在空間計算上的能力發揮得還是比較讓人滿意的，至少沒有出現穿牆或者與怪物對打的時候攻擊失效。
而且這個 roguelike 豆包版本的通道設計得會稍微寬一些，沒有那麼艱難地控制角色通過這個區域邊界通道，這是一個優勢。我之前測試其他模型的時候，在這個 case 上面設計的通道就很窄，導致實際體驗這個遊戲的時候很難穿過通道，互動體驗就會下降。
不過豆包的這個畫面太暗了，而且遊戲主角的面向方向不太正確，當我往前走，他的面向是往後的，有點奇怪了。另外一點就是，對手和武器的複雜度還有提升空間，因為它似乎只是一把劍，對手也都是一個丸子類似的怪物。
3D 塔防
塔防要圍繞敵人的進攻波次安排整局節奏，同時處理建塔、經濟和升級。
豆包的塔防是全自動刷新怪物的出現，打完一輪後自動出現下一輪。之前測試這個 case 的時候，有的模型它的設計就是要我手動點選下一波，它才會刷新下一輪的怪物出現，就感覺有點奇怪。雖然這是刷新機制上的設計，但是我還是感覺豆包的設計會更符合直覺一些，一定程度上體現出豆包在塔防遊戲設計方面還是比較有認知的。
不過豆包的建築都過於簡略了，算不上酷炫精緻。
地鐵跑酷
跑酷參考 Subway Surfers。玩家在三條跑道向前奔跑，左右變道、跳躍、滑鏟躲避障礙、收集金幣道具，越遠分越高。
但這裡沒有一輪寫好。第一版的跳躍動作很怪，按下去不像真的跳了起來。我把問題回報給它，第二輪才修到視訊裡的效果。豆包這個跑的速度還可以，不是很快，也不是很慢，屬於中等的難度。而且豆包的這個 case 裡面它還會隨機刷新道具，感覺這部分的設計做的是比較不錯的。
不過豆包還有一個問題，就是它第一版有一個跳躍的 bug，當我點選跳躍的時候，它的動作一點都不像跳躍，有一點怪異。所以相當於沒有一輪就寫好，我讓它第二次修復才修好。
另外主角似乎是沒法跳到車上去的，也沒有那種斜向上的車能讓我上車，感覺模擬的還是不到位，有點奇怪。
3. 生產級項目實測：多模態圖片搜尋與管理項目
最後，我拿出了 Smartlmager。它是我去年寫的多模態圖片搜尋與管理項目。這個項目沒有為測試重新整理過，程式碼裡的歷史問題和不滿意的前端都還在。
當時本來是想要做成一個多模態圖片搜尋引擎&管理系統的項目來著，可惜當時前端實力還是差點意思，做的感覺互動設計的不是很好。現在趁著豆包新模型發佈，剛好讓它來收拾一下，發現它做的還是挺不錯的。
我不僅僅讓它幫我改了一下前端，順手還把後端也最佳化掉了。原來的後端是基於 Python 做的，因為需要有 AI 部分的推理，所以只能基於 Python 的生態來做。後來我就和豆包說，讓它幫我把 AI 推理的部分另外起一個後端，非 AI 部分就用 Next.js 全端去做就好了。下面可以給大家看看它的一個全端改造效果。
它把我整個項目都梳理了一下，並且完成了遷移。我驗收之後，發現基本上沒有什麼問題，而且前端改得也比較符合我的審美。總體來說，還是比較滿意的一個狀態。
02 寫在最後
測試之前，我其實沒把握豆包能把這幾個遊戲做成什麼樣。
豆包作為國內的模型代表，在上面的四個 case 上表現到這樣的程度，已經大大刷新了我對國產模型的刻板印象。
過去看多了「最直接、最不繞彎子地告訴你」這些梗，我對豆包的印象一直停在聊天上，做開發時很少想到它。這輪用下來，它絕對能接進日常使用的 Coding Agent 裡了。
這次測的還只是 0915，Seed-Evolving 在短短兩個半月裡就更新了五次。
下一次再打開它，模型可能又一次進化了。(Datawhale)