<mark id="oztn4"></mark>
0
作者丨鄭佳美
編輯丨馬曉寧
一條貪吃蛇在吃到第幾個蘋果時，會開始懷疑自己為什么只能向上下左右移動？
這聽起來像個冷笑話，但 Ethan Mollick 最近展示的 AI 實驗，差不多就是從這個問題開始的。
他讓 Fable 做了一個“有自我意識的貪吃蛇游戲”：蛇一開始只是經典 Snake 里的那條蛇，移動、吃東西、變長、撞墻死亡。
但隨著游戲推進，它逐漸意識到自己活在一個游戲里，意識到規則是人為設定的，意識到玩家正在控制它。然后，游戲開始變形，玩法也從 Snake 延展到 RTS、農場經營和敘事探索等不同形態。
更有意思的是，Mollick 并沒有像傳統游戲制作人那樣給出一份詳細策劃案。他沒有逐項規定 UI 怎么改、關卡怎么設計、機制怎么平衡。很多時候，他只是給出一句話：“Make it better.”
這句話在傳統軟件開發里幾乎不能算需求。它沒有說明改哪里，也沒有說明什么結果算合格。但對 AI Agent 來說，這正是難點所在：它必須把一個模糊反饋，翻譯成下一步可以執行的工程動作。
這也是 Fable 這個 demo 真正值得分析的地方。
如果只是生成一個 Snake，技術難度并不高。真正難的是：當第一版已經存在之后，AI 能不能在舊系統上持續修改，而不是每一輪都重新生成一套東西。
01
過去很多 AI 編程任務，更像一次性生成。人給出需求，模型返回代碼。這個模式里的關鍵是 prompt，也就是人如何把需求說清楚。
但 Fable 這個案例更接近 loop。所謂 loop，不是模型回答一次就結束，而是進入一個連續過程：先理解當前項目，再提出修改方案，然后改代碼、運行、檢查結果，再進入下一輪。
這個變化會讓技術難點發生轉移。
一次性生成時，AI 可以按照自己的方式組織代碼。只要最后能跑，結構是否適合長期維護，并不會馬上暴露。但連續修改時，每一輪新改動都要接在舊系統上，代碼結構、模塊邊界、狀態管理這些問題很快就會浮出來。
在一個游戲項目里，基礎玩法、狀態變化、敘事推進和畫面反饋往往會彼此影響。AI 如果沒有理解這些部分之間的關系，就可能為了加一個新效果，改亂原來的運行邏輯。短期看，內容確實變多了；但多輪之后，系統會越來越難繼續維護。
所以，Fable 在這個 demo 里被測試的，不只是會不會寫代碼，而是能不能在多輪修改中保持項目的連續性。
這種連續性大致落在幾個層面：它要記住游戲主線仍然是“蛇逐漸意識到自己在游戲中”；它要分清當前代碼中哪些部分負責基礎玩法，哪些部分負責狀態變化，哪些部分負責敘事推進；它還要控制每一輪的修改范圍，避免為了一個局部效果重寫過多舊邏輯。
這就是 agentic coding 和普通代碼生成的差別。普通代碼生成更像完成一道題；agentic coding 更像進入一個已經運行的項目，邊讀、邊改、邊驗證。雷峰網(公眾號：雷峰網)
也正因為它進入的是一個持續運行的項目，“Make it better” 這種模糊反饋才會變成一個工程問題。
02
更詳細的講，“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
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
大會報告全文
熱門論文解讀
學術新星訪談
掃描上方二維碼
或點擊「閱讀原文」關注專區。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
