一句「Make it better」，Fable 5 直接把貪吃蛇煉成「逆反人格」

一個小遊戲，藏著 AI Agent 的工程考題。 作者丨鄭佳美 編輯丨馬曉寧 一條貪吃蛇在吃到第幾個蘋果時，會開始懷疑自己為什麼只能向上下左右移動？這聽起來像個冷笑話，但 Ethan Mollick 最近展示的 AI 實驗，差不多就是從這個問題開始的。他讓 Fable 做了一個“有自我意識的貪吃蛇遊戲”：蛇一開始只是經典 Snake 裡的那條蛇，移動、吃東西、變長、撞牆死亡。但隨著遊戲推進，它逐漸意識到自己活在一個遊戲裡，意識到規則是人為設定的，意識到玩家正在控制它。然後，遊戲開始變形，玩法也從 Snake 延展到 RTS、農場經營和敘事探索等不同形態。更有意思的是，Mollick 並沒有像傳統遊戲製作人那樣給出一份詳細策劃案。他沒有逐項規定 UI 怎麼改、關卡怎麼設計、機制怎麼平衡。很多時候，他只是給出一句話：“Make it better.”這句話在傳統軟件開發裡幾乎不能算需求。它沒有說明改哪裡，也沒有說明什麼結果算合格。但對 AI Agent 來說，這正是難點所在：它必須把一個模糊反饋，翻譯成下一步可以執行的工程動作。這也是 Fable 這個 demo 真正值得分析的地方。如果只是生成一個 Snake，技術難度並不高。真正難的是：當第一版已經存在之後，AI 能不能在舊系統上持續修改，而不是每一輪都重新生成一套東西。01從 prompt 到 loop過去很多 AI 編程任務，更像一次性生成。人給出需求，模型返回代碼。這個模式裡的關鍵是 prompt，也就是人如何把需求說清楚。但 Fable 這個案例更接近 loop。所謂 loop，不是模型回答一次就結束，而是進入一個連續過程：先理解當前項目，再提出修改方案，然後改代碼、運行、檢查結果，再進入下一輪。這個變化會讓技術難點發生轉移。一次性生成時，AI 可以按照自己的方式組織代碼。只要最後能跑，結構是否適合長期維護，並不會馬上暴露。但連續修改時，每一輪新改動都要接在舊系統上，代碼結構、模塊邊界、狀態管理這些問題很快就會浮出來。在一個遊戲項目裡，基礎玩法、狀態變化、敘事推進和畫面反饋往往會彼此影響。AI 如果沒有理解這些部分之間的關係，就可能為了加一個新效果，改亂原來的運行邏輯。短期看，內容確實變多了；但多輪之後，系統會越來越難繼續維護。所以，Fable 在這個 demo 裡被測試的，不只是會不會寫代碼，而是能不能在多輪修改中保持項目的連續性。這種連續性大致落在幾個層面：它要記住遊戲主線仍然是“蛇逐漸意識到自己在遊戲中”；它要分清當前代碼中哪些部分負責基礎玩法，哪些部分負責狀態變化，哪些部分負責敘事推進；它還要控制每一輪的修改範圍，避免為了一個局部效果重寫過多舊邏輯。這就是 agentic coding 和普通代碼生成的差別。普通代碼生成更像完成一道題；agentic coding 更像進入一個已經運行的項目，邊讀、邊改、邊驗證。雷峰網也正因為它進入的是一個持續運行的項目，“Make it better” 這種模糊反饋才會變成一個工程問題。02「Make it better」難在哪更詳細的講，“Make it better” 不是一個明確指令，而是一個開放評價。明確指令比較容易處理。比如“增加一個開始按鈕”“修復碰撞錯誤”“把速度調慢”，這些都能直接對應到代碼修改。但“變得更好”沒有這麼清楚。它可能指玩法更順，也可能指敘事更自然，還可能指系統更穩定。AI 不能直接跳到寫代碼，而要先判斷當前版本的問題屬於哪一類。這一步看起來像產品判斷，但它會直接影響工程實現。如果問題出在交互層，改動可能會落到輸入響應和反饋節奏；如果問題出在狀態層，改動可能會落到階段切換和規則管理；如果問題出在結構層，繼續加功能反而可能讓系統更亂，先整理代碼會更穩。也就是說，模糊反饋進入代碼之前，需要經過一次任務分解：這輪要解決什麼問題，改動應該限制在哪個範圍，哪些舊邏輯不能被破壞，改完後用什麼方式確認它沒有引入新的問題。這裡比較考驗 Agent 的，是“規劃層”。普通代碼補全更關注下一段代碼怎麼寫；Agent 要多做一步，先決定這一輪到底該不該寫、該寫哪裡、寫到什麼程度。雷峰網如果少了這一步，“Make it better” 很容易被理解成“繼續加內容”。內容變多了，不一定代表系統變好了。對這個 demo 來說，更關鍵的是 Fable 能否把一句模糊反饋，收斂成一組可控的修改動作。這也會自然帶出下一個問題：項目改得越久，歷史信息越多，模型怎麼知道哪些東西需要繼續保留？之後到了多輪修改階段，上下文就會變得越來越長。項目做得越久，模型需要處理的信息就越多。代碼結構、歷史修改、當前目標、舊問題、臨時方案，都會進入上下文。長上下文當然有幫助，因為模型至少能看到更多歷史信息。如果模型只是把更多內容塞進上下文，卻分不清哪些信息仍然重要，項目仍然會失控。它可能記得上一輪加過什麼，卻忘了這個遊戲最初想表達什麼；也可能解決了眼前問題，卻讓後續修改變得更難。在這個 demo 裡，Fable 需要持續保留的不是所有細節，而是幾個穩定約束：遊戲仍然要保留 Snake 的基本識別度；“自我意識”不能只停留在臺詞裡，而要影響規則和交互；新增玩法不能破壞原來的基礎循環；多輪修改之後，代碼還要能繼續維護。這些約束不會每次都由用戶重新提醒。模型需要把歷史信息壓縮成一組工作規則，並在後續修改中持續使用。這就是長上下文和長程能力的區別。長上下文解決的是“模型能看到多少”；長程能力處理的是“模型能不能從這些信息裡抓住關鍵，並在後續修改裡一直遵守”。對連續開發來說，後者更接近實際難點。不過，就算模型能記住主線、控制結構，項目是否真的變好了，仍然需要另一層判斷。因為代碼層面的反饋和體驗層面的反饋並不是一回事。03代碼能跑，不代表迭代有效軟件開發裡，有一類反饋很明確：代碼有沒有報錯，構建能不能通過，頁面能不能打開。這些都可以通過工具檢查。但 Mollick 這個 demo 還有另一類反饋：體驗有沒有變好。這就沒那麼容易自動判斷。程序運行成功，只能說明它通過了工程層面的最低檢查。它不能說明節奏是否更自然，新增機制是否服務於主題，也不能說明多輪修改之後，系統有沒有變得更清楚。這也是 AI Agent 做創意型開發時比較難的一點：硬反饋清楚，軟反饋模糊。硬反饋來自代碼和工具，比如報錯、測試、構建日誌。軟反饋來自體驗和判斷，比如玩家是否理解規則變化，玩法是否和敘事互相支撐，複雜度是否還在可控範圍內。如果一個 Agent 只依賴硬反饋，它會傾向於做容易驗證的事，比如修錯、補界面、加功能。但 “Make it better” 很多時候並不只是加功能，而是讓已有部分之間的關係更順。所以，比較有效的迭代方式，是每一輪修改都能說清楚它解決了什麼問題。不是籠統地“增強體驗”，而是更具體地說明：這一輪是在調整交互反饋、狀態切換、敘事節奏，還是代碼結構。這類評估能力會直接影響 AI 改項目的質量。判斷越清楚，修改範圍越容易收住；判斷越模糊，代碼越容易變成堆料。到這裡，Fable 這個 demo 的技術信號也就比較清楚了：它不只是生成了第一版，而是在嘗試處理第 N 輪修改。04從生成第一版，到維護第 N 版Fable 這個案例的意義，不在於證明 AI 會做遊戲，而在於它把 AI 編程的關注點從“生成第一版”推到了“維護第 N 版”。第一版代碼通常不是最麻煩的。真實開發裡，更麻煩的是後續修改：需求變了怎麼改，功能多了怎麼不亂，修 bug 時怎麼不引入新 bug，迭代多輪以後怎麼還能保持清晰結構。Mollick 的 “Make it better” 正好把這個問題壓縮進了一個小 demo 裡。它讓 AI 面對的不是一份清楚需求，而是一個持續變化的目標。Fable 需要在每一輪裡判斷：目標有沒有偏，結構有沒有亂，改動是否值得保留，下一步應該推進哪裡。這條蛇最有意思的，或許並不是因為它會“懷疑人生”，而是因為它讓我們看到 AI Agent 正在接近一種更真實的開發場景：不是聽懂一句 prompt，然後交出一份代碼；而是在一個已經存在的系統裡，持續理解、修改、驗證，再繼續往下走。從這個角度看，Fable 的 demo 更像是一個小型壓力測試：當 AI 面對模糊反饋、長上下文、多輪修改和軟性體驗判斷時，它能不能把項目穩穩地往前推。這或許才是 “Make it better” 最重要的意義。參考鏈接：https://x.com/emollick/status/2069207757199200408上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。