把 K3、Fable5、GLM5.2、Hy3 這四款大模型放到同一個(gè)頁(yè)游開(kāi)發(fā)項(xiàng)目里做橫評(píng)是我最近半個(gè)月做得最多的一件事。很多人選大模型只看跑分和排行榜但真正動(dòng)手做頁(yè)面游戲時(shí)響應(yīng)速度、代碼質(zhì)量、上下文保持和多輪修改能力才是決定你能不能按時(shí)交付的關(guān)鍵。這篇橫評(píng)不做抽象能力排行而是圍繞一個(gè)具體目標(biāo)用同一套需求讓四款模型分別完成頁(yè)游開(kāi)發(fā)中的頁(yè)面生成、玩法邏輯、接口聯(lián)調(diào)和報(bào)錯(cuò)修復(fù)最后給出選型建議。如果你正準(zhǔn)備用大模型輔助做網(wǎng)頁(yè)游戲或者團(tuán)隊(duì)在糾結(jié)該把哪款模型接到內(nèi)部工具里這篇應(yīng)該能幫你省掉不少對(duì)比時(shí)間。先說(shuō)清楚這里所有結(jié)論都來(lái)自我自己的實(shí)測(cè)環(huán)境帶有明顯主觀判斷不代表官方能力聲明也不構(gòu)成絕對(duì)選型依據(jù)。1. 評(píng)測(cè)先定標(biāo)準(zhǔn)頁(yè)游開(kāi)發(fā)到底考模型哪些能力1.1 為什么選頁(yè)游做橫評(píng)場(chǎng)景網(wǎng)頁(yè)游戲是一個(gè)特別適合做大模型對(duì)比的測(cè)試場(chǎng)景。它不像普通管理系統(tǒng)那樣只有增刪改查也不像博客系統(tǒng)那樣以靜態(tài)展示為主。一個(gè)稍微完整的頁(yè)游至少要包含頁(yè)面結(jié)構(gòu)、交互事件、玩法邏輯、狀態(tài)管理、數(shù)據(jù)存儲(chǔ)和接口聯(lián)調(diào)。這些環(huán)節(jié)對(duì)模型的代碼生成能力、邏輯推理能力、上下文理解能力和多輪修改穩(wěn)定性都有不同要求。更關(guān)鍵的是頁(yè)游開(kāi)發(fā)是一個(gè)“高頻改動(dòng)”的過(guò)程。需求經(jīng)常會(huì)變數(shù)值要調(diào)、技能要改、界面要換、接口要對(duì)接。模型的真實(shí)價(jià)值不只是一次性生成多少代碼而是面對(duì)需求變更時(shí)能不能既快又不改壞其他功能。我用四款模型分別做了同一個(gè)頁(yè)游小項(xiàng)目的開(kāi)發(fā)測(cè)試項(xiàng)目復(fù)雜度控制在個(gè)人開(kāi)發(fā)者一周內(nèi)能完成的水平角色面板、技能系統(tǒng)、怪物區(qū)域、戰(zhàn)斗邏輯、戰(zhàn)斗日志、本地存儲(chǔ)和模擬接口。這個(gè)規(guī)模既不會(huì)因?yàn)樘?jiǎn)單而看不出差異也不會(huì)因?yàn)樘蠖y以控制變量。1.2 我用來(lái)判斷的四項(xiàng)核心指標(biāo)第一項(xiàng)是單次生成完整度。給模型一段需求描述看它第一次返回的代碼能不能直接打開(kāi)、直接跑還是需要反復(fù)追問(wèn)修正。這一項(xiàng)直接影響使用效率。第二項(xiàng)是多輪修改穩(wěn)定性。頁(yè)游開(kāi)發(fā)中需求必然變化我會(huì)在生成完第一版后連續(xù)提出幾個(gè)修改需求看模型能不能在已有代碼基礎(chǔ)上局部改動(dòng)而不是把整個(gè)文件重寫(xiě)一遍或者改著改著把原來(lái)的功能改沒(méi)了。第三項(xiàng)是邏輯正確性。頁(yè)面好看只是第一步戰(zhàn)斗計(jì)算、技能冷卻、勝負(fù)判定這些邏輯錯(cuò)了游戲根本沒(méi)法玩。我會(huì)重點(diǎn)檢查邊界條件、重復(fù)操作和異常輸入。第四項(xiàng)是代碼可維護(hù)性。變量命名、函數(shù)拆分、注釋習(xí)慣、代碼風(fēng)格是否一致決定你拿到代碼后能不能自己接手維護(hù)。這一點(diǎn)在長(zhǎng)期項(xiàng)目里比一次性生成速度更重要。1.3 測(cè)試環(huán)境和提示詞設(shè)計(jì)測(cè)試環(huán)境是同一臺(tái)開(kāi)發(fā)機(jī)瀏覽器用 Chrome沒(méi)有任何額外插件所有代碼都在本地運(yùn)行。四款模型使用同一個(gè)需求文檔提示詞模板完全一致只替換模型名稱(chēng)。所有生成結(jié)果我都單獨(dú)保存方便回來(lái)對(duì)比。提示詞模板是這樣的結(jié)構(gòu)先說(shuō)明項(xiàng)目目標(biāo)再列出功能清單然后給出界面布局要求最后指定技術(shù)棧和交付格式。我特別在提示詞里要求模型“先輸出代碼再簡(jiǎn)要說(shuō)明設(shè)計(jì)思路”這樣既能判斷代碼質(zhì)量也能看出模型對(duì)自己生成內(nèi)容的理解程度。注意評(píng)測(cè)結(jié)果和提示詞寫(xiě)法強(qiáng)相關(guān)。如果你直接用不同的提示詞模板四款模型的表現(xiàn)排序可能發(fā)生變化。這里的結(jié)論只對(duì)這套測(cè)試模板負(fù)責(zé)。2. 第一輪從零生成完整頁(yè)面四款模型的表現(xiàn)差異2.1 K3頁(yè)面骨架穩(wěn)但樣式細(xì)節(jié)需要追問(wèn)K3 在第一輪的表現(xiàn)是“穩(wěn)”。它生成的頁(yè)面結(jié)構(gòu)完整HTML 語(yǔ)義化不錯(cuò)CSS 基礎(chǔ)樣式也很規(guī)范區(qū)塊劃分清晰角色面板、技能欄、怪物區(qū)域、戰(zhàn)斗日志四個(gè)模塊都能按要求一次性給出來(lái)。但問(wèn)題也很明顯樣式偏樸素。如果不額外追加“美化、加動(dòng)效、調(diào)整布局”這類(lèi)需求第一版頁(yè)面看起來(lái)就是一個(gè)沒(méi)有裝飾的原型。游戲類(lèi)項(xiàng)目對(duì)視覺(jué)表現(xiàn)要求比管理后臺(tái)高這一項(xiàng)上 K3 需要多輪打磨才能到可展示狀態(tài)。從工程角度看K3 的代碼結(jié)構(gòu)最適合二次開(kāi)發(fā)。它會(huì)把腳本和數(shù)據(jù)定義拆開(kāi)函數(shù)命名也夠清楚你拿到的第一版不是一坨只能看的 HTML而是真的可以往上疊功能的骨架。2.2 Fable5前端結(jié)構(gòu)完整組件拆分思路清晰Fable5 給我印象最深的是組件拆分意識(shí)。同樣是一個(gè)頁(yè)游主界面它會(huì)自然地把角色信息、技能列表、戰(zhàn)斗區(qū)域拆成獨(dú)立函數(shù)或獨(dú)立模塊甚至在純 HTML 文件里也保留清晰的區(qū)域注釋。這種做法的好處是后面改需求時(shí)很舒服。你要改技能欄只需要定位到技能欄對(duì)應(yīng)的代碼塊不用在幾千行代碼里翻找。對(duì)想長(zhǎng)期維護(hù)頁(yè)游項(xiàng)目的人來(lái)說(shuō)這個(gè)優(yōu)勢(shì)比頁(yè)面“一眼好看”更重要。Fable5 第一版頁(yè)面同樣不算花哨但它對(duì) CSS 類(lèi)和 ID 的命名更統(tǒng)一整體代碼風(fēng)格偏工程化。如果你有代碼潔癖看到 Fable5 生成的代碼會(huì)舒服很多。2.3 GLM5.2單文件輸出能力強(qiáng)長(zhǎng)代碼連貫性好GLM5.2 在單次生成完整度上表現(xiàn)靠前。同樣一個(gè)頁(yè)游主界面它能一次性輸出一個(gè)相對(duì)完整、打開(kāi)就能看到效果的單文件。HTML、CSS、JavaScript 混在一個(gè)文件里但結(jié)構(gòu)不亂。它的長(zhǎng)代碼連貫性比較突出。很多模型在輸出超過(guò) 300 行代碼后后半段會(huì)出現(xiàn)組件缺失、狀態(tài)變量突然沒(méi)定義、函數(shù)名前后不一致這類(lèi)問(wèn)題。GLM5.2 在這輪測(cè)試中代碼前后一致性較好戰(zhàn)斗日志區(qū)域的動(dòng)態(tài)渲染邏輯和前面定義的變量能對(duì)得上。不過(guò)它也有一些小毛病生成的腳本注釋偏少個(gè)別地方用了比較隱晦的寫(xiě)法。如果你不是第一次接觸這份代碼理解起來(lái)需要花一點(diǎn)時(shí)間。2.4 Hy3代碼風(fēng)格更克制需要多輪修正Hy3 第一輪代碼的風(fēng)格是“克制”。它不會(huì)一上來(lái)就鋪一個(gè)大而全的頁(yè)面而是更傾向先把核心功能做得能用視覺(jué)和交互細(xì)節(jié)放在后面。這個(gè)特點(diǎn)有利有弊。如果你希望模型像美術(shù)一樣直接輸出炫酷頁(yè)面Hy3 很可能讓你失望。但如果你更重視功能正確性它會(huì)先把角色顯示、技能點(diǎn)擊、日志追加這類(lèi)核心流程寫(xiě)完整再讓你逐步追加視覺(jué)要求。我在測(cè)試中發(fā)現(xiàn)Hy3 對(duì)“逐步細(xì)化”的響應(yīng)不錯(cuò)。第一版樸素沒(méi)有關(guān)系你提出“增加技能冷卻進(jìn)度條”“怪物區(qū)域加血條動(dòng)畫(huà)”之后它能比較準(zhǔn)確地定位到對(duì)應(yīng)代碼修改而不是把整個(gè)頁(yè)面重寫(xiě)。這在實(shí)際開(kāi)發(fā)中反而是更珍貴的品質(zhì)。2.5 第一輪對(duì)比結(jié)果怎么看只看第一輪四款模型的差距沒(méi)有想象中大。除了 Hy3 明顯偏保守其他三款都能在給定需求下輸出一個(gè)可以運(yùn)行的頁(yè)面。真正的差異出現(xiàn)在兩個(gè)地方一是代碼結(jié)構(gòu)是否方便后續(xù)修改二是追加視覺(jué)需求時(shí)是局部改還是整體重寫(xiě)。我把代碼結(jié)構(gòu)質(zhì)量排了個(gè)序Fable5 最佳K3 次之GLM5.2 居中Hy3 第一版結(jié)構(gòu)最簡(jiǎn)單但容易擴(kuò)展。這個(gè)順序不是最終結(jié)論因?yàn)榈诙喖尤胪娣ㄟ壿嫼笈判驎?huì)發(fā)生明顯變化。我建議你在實(shí)際使用時(shí)不要只看第一版效果?？梢韵茸屇Ｐ洼敵鲆粋€(gè)你能跑通的最小版本然后連續(xù)提三個(gè)修改需求觀察它是局部修改還是全部重來(lái)。這個(gè)測(cè)試方法比一次性生成完整頁(yè)面更容易暴露真實(shí)能力。3. 第二輪核心玩法邏輯才是頁(yè)游開(kāi)發(fā)的真正分水嶺3.1 我用同一個(gè)需求驗(yàn)證邏輯能力第二輪我讓四款模型實(shí)現(xiàn)一套回合制戰(zhàn)斗邏輯玩家攻擊怪物、怪物反擊、技能有冷卻時(shí)間、血量到零后判定勝負(fù)最后把整場(chǎng)戰(zhàn)斗過(guò)程寫(xiě)入日志。這是一個(gè)典型的中間復(fù)雜度邏輯既要有數(shù)據(jù)計(jì)算也要有狀態(tài)流轉(zhuǎn)還要處理重復(fù)點(diǎn)擊和邊界情況。測(cè)試方法還是同一套需求模板只改模型名稱(chēng)。我會(huì)先讓模型生成完整戰(zhàn)斗系統(tǒng)然后連續(xù)提出幾個(gè)修改需求增加暴擊概率、加入技能消耗、調(diào)整怪物反擊規(guī)則、增加戰(zhàn)斗結(jié)束后的重新開(kāi)始按鈕。每一步都觀察模型能不能在原有代碼上精準(zhǔn)修改。3.2 狀態(tài)管理和事件循環(huán)的實(shí)現(xiàn)差異K3 在狀態(tài)管理上表現(xiàn)最穩(wěn)。它會(huì)用一個(gè)全局對(duì)象保存角色血量、技能冷卻、戰(zhàn)斗狀態(tài)所有函數(shù)都圍繞這個(gè)狀態(tài)對(duì)象操作。好處是邏輯清晰排查問(wèn)題方便。你給我一個(gè)報(bào)錯(cuò)我能很快定位到是哪個(gè)函數(shù)改了狀態(tài)。GLM5.2 傾向于把狀態(tài)變量分散在局部作用域這在小型邏輯里沒(méi)問(wèn)題但涉及多個(gè)技能、多個(gè)怪物時(shí)變量之間的相互影響會(huì)更復(fù)雜。它生成的邏輯能跑但代碼評(píng)審時(shí)需要更仔細(xì)。Hy3 對(duì)事件循環(huán)的處理比較注意。它會(huì)主動(dòng)避免按鈕重復(fù)點(diǎn)擊導(dǎo)致戰(zhàn)斗邏輯重復(fù)執(zhí)行在點(diǎn)擊事件入口加了狀態(tài)鎖。這個(gè)細(xì)節(jié)很多模型不會(huì)主動(dòng)處理但在頁(yè)游里非常關(guān)鍵——玩家連點(diǎn)技能按鈕不能讓?xiě)?zhàn)斗循環(huán)觸發(fā)十次。Fable5 的抽象能力最強(qiáng)。它會(huì)封裝一個(gè)戰(zhàn)斗流程函數(shù)把攻擊、傷害計(jì)算、勝負(fù)判斷拆成獨(dú)立方法。這種代碼在前期開(kāi)發(fā)時(shí)可能要寫(xiě)更多行但后續(xù)加新技能、新怪物時(shí)擴(kuò)展成本最低。3.3 數(shù)值計(jì)算和邊界條件誰(shuí)處理得更干凈這一輪我專(zhuān)門(mén)測(cè)了三個(gè)邊界條件角色血量降為負(fù)數(shù)時(shí)是否會(huì)被糾正為 0、技能冷卻時(shí)間在極端情況下是否會(huì)變成負(fù)數(shù)、怪物血量為 0 后是否還能繼續(xù)被攻擊。K3 在這三個(gè)測(cè)試點(diǎn)全部通過(guò)而且沒(méi)有出現(xiàn)邏輯沖突。它在每次傷害計(jì)算后都會(huì)主動(dòng)做邊界校驗(yàn)代碼里能看到明確的Math.max(0, currentHp)這類(lèi)保護(hù)寫(xiě)法。GLM5.2 主體邏輯正確但在“怪物死亡后仍然可以選中攻擊”這個(gè)場(chǎng)景上需要我追加一句“怪物死亡后需要置灰或移除點(diǎn)擊事件”才修復(fù)。第一版代碼里沒(méi)有主動(dòng)處理這個(gè)狀態(tài)。Fable5 對(duì)邊界條件的處理也不錯(cuò)尤其擅長(zhǎng)把“怪物是否存活”作為獨(dú)立判斷條件嵌入攻擊邏輯從設(shè)計(jì)上避免死掉怪物還能被攻擊的問(wèn)題。Hy3 在三項(xiàng)邊界測(cè)試中表現(xiàn)中等。它能正確處理血量歸零但技能冷卻的計(jì)時(shí)邏輯用了相對(duì)復(fù)雜的寫(xiě)法在小樣本測(cè)試中沒(méi)發(fā)現(xiàn)問(wèn)題放到更長(zhǎng)戰(zhàn)斗流程里是否穩(wěn)定還需要更多驗(yàn)證。3.4 邏輯復(fù)雜度上來(lái)后誰(shuí)的上下文保持更好這是整輪橫評(píng)中最能拉開(kāi)差距的一項(xiàng)。我會(huì)在完成第一版邏輯后連續(xù)追加 5 個(gè)修改需求每個(gè)需求之間不重新描述整個(gè)項(xiàng)目背景只說(shuō)明“在上一版基礎(chǔ)上修改”。K3 的上下文保持最好。五輪修改之后它沒(méi)有忘記前面定的技能規(guī)則也沒(méi)有把已經(jīng)寫(xiě)好的暴擊邏輯改亂。它的代碼結(jié)構(gòu)讓每一輪修改都落在明確的位置。GLM5.2 前四輪修改都很穩(wěn)定但第五輪讓它新增“戰(zhàn)斗中不能切換技能”的規(guī)則時(shí)把原有冷卻邏輯重寫(xiě)了一段產(chǎn)生了兩個(gè)計(jì)時(shí)器并存的隱患。我檢查后手動(dòng)清理了冗余代碼。Fable5 在這個(gè)環(huán)節(jié)最穩(wěn)定。因?yàn)樗婚_(kāi)始就把邏輯模塊化追加新規(guī)則只需要增加一個(gè)條件判斷不需要改動(dòng)核心戰(zhàn)斗流程。五輪修改后代碼的可讀性仍然很高。Hy3 的問(wèn)題在于它每輪都會(huì)把相關(guān)函數(shù)整體重寫(xiě)一遍。雖然邏輯正確但改動(dòng)范圍偏大容易引入回歸問(wèn)題。我在第五輪修改后特別做了回歸測(cè)試發(fā)現(xiàn)重新開(kāi)始按鈕的狀態(tài)重置邏輯被新代碼覆蓋掉了。建議如果你準(zhǔn)備用模型輔助開(kāi)發(fā)游戲邏輯盡量在初始提示詞里就要求“把核心狀態(tài)封裝成獨(dú)立結(jié)構(gòu)函數(shù)盡量拆分”。這個(gè)要求能顯著提升模型在多輪修改中的穩(wěn)定性。4. 第三輪接口聯(lián)調(diào)、數(shù)據(jù) Mock 和異步處理4.1 模擬后端接口時(shí)的代碼生成質(zhì)量頁(yè)游不可能只有前端玩家數(shù)據(jù)、排行榜、存檔這些功能都需要接口。為了控制測(cè)試變量我不實(shí)際搭建后端而是讓模型生成一個(gè)本地 Mock 接口來(lái)模擬網(wǎng)絡(luò)請(qǐng)求。這個(gè)環(huán)節(jié)重點(diǎn)看三件事模型能不能生成規(guī)范的異步代碼、能不能模擬延遲和異常、返回的數(shù)據(jù)結(jié)構(gòu)是否和前端邏輯匹配。Fable5 在接口封裝上最接近真實(shí)工程實(shí)踐。它會(huì)主動(dòng)用一個(gè)request函數(shù)封裝fetch統(tǒng)一處理錯(cuò)誤和超時(shí)前端調(diào)用時(shí)只需要傳入接口地址和參數(shù)。K3 生成的 Mock 代碼也很規(guī)范但更傾向于直接在組件內(nèi)寫(xiě)異步邏輯沒(méi)有單獨(dú)抽離請(qǐng)求層。在小型項(xiàng)目里沒(méi)關(guān)系但如果后續(xù)接口數(shù)量增多這種寫(xiě)法會(huì)變得臃腫。GLM5.2 對(duì)異步流程的理解扎實(shí)async/await用得很標(biāo)準(zhǔn)錯(cuò)誤捕獲也完整。不過(guò)它生成的 Mock 數(shù)據(jù)結(jié)構(gòu)相對(duì)簡(jiǎn)單對(duì)嵌套數(shù)據(jù)的模擬不夠充分。Hy3 生成的 Mock 代碼穩(wěn)定性不錯(cuò)但風(fēng)格偏保守使用了較傳統(tǒng)的Promise.then鏈?zhǔn)綄?xiě)法。代碼能跑但與周?chē)麓a風(fēng)格不太統(tǒng)一。4.2 異步錯(cuò)誤處理和超時(shí)機(jī)制這個(gè)維度直接考察模型對(duì)真實(shí)網(wǎng)絡(luò)環(huán)境的預(yù)判。一個(gè)成熟的接口層不能假設(shè)請(qǐng)求一定成功。K3 和 Fable5 都會(huì)主動(dòng)生成超時(shí)控制邏輯比如用AbortController或Promise.race處理請(qǐng)求超時(shí)。它們生成的錯(cuò)誤提示也更具體不只是console.log一下而是會(huì)在頁(yè)面上給用戶可見(jiàn)的提示。GLM5.2 的錯(cuò)誤處理集中在catch塊里代碼正確但沒(méi)有把錯(cuò)誤狀態(tài)同步到界面上的意識(shí)。你需要額外追加需求它才會(huì)把“接口失敗后頁(yè)面上顯示失敗提示”補(bǔ)上。Hy3 在錯(cuò)誤處理上最保守第一版代碼居然只用了alert提示錯(cuò)誤。對(duì)于演示項(xiàng)目來(lái)說(shuō)夠用但這是頁(yè)游頻繁alert會(huì)直接打斷玩家操作。4.3 數(shù)據(jù)結(jié)構(gòu)和命名一致性這一項(xiàng)決定了前端代碼和接口數(shù)據(jù)能不能順利對(duì)上。很多模型在生成前端時(shí)會(huì)假定某個(gè)字段名生成接口時(shí)又用了另一個(gè)字段名導(dǎo)致聯(lián)調(diào)階段才能發(fā)現(xiàn)問(wèn)題。K3 在前后端數(shù)據(jù)字段命名上保持了較高一致性。它會(huì)先用一個(gè)數(shù)據(jù)結(jié)構(gòu)定義文檔再基于這個(gè)結(jié)構(gòu)同時(shí)生成 Mock 數(shù)據(jù)和前端渲染邏輯。GLM5.2 在單份文件里一致性好但當(dāng)你要求它把接口拆成獨(dú)立模塊時(shí)字段命名偶爾會(huì)有出入。我在測(cè)試中遇到一個(gè)小問(wèn)題前端寫(xiě)成playerName接口返回的卻是name需要手動(dòng)修正。Fable5 的字段命名跟項(xiàng)目業(yè)務(wù)結(jié)合最緊它會(huì)根據(jù)實(shí)際含義命名比如playerHp、monsterId可讀性和一致性都很好。Hy3 的命名整體統(tǒng)一但存在精簡(jiǎn)過(guò)度的傾向比如用hp、mp、cd這類(lèi)縮寫(xiě)對(duì)熟悉業(yè)務(wù)的人來(lái)說(shuō)沒(méi)問(wèn)題但新接手的人需要額外理解成本。5. 第四輪報(bào)錯(cuò)修復(fù)和需求變更實(shí)戰(zhàn)中最耗時(shí)的環(huán)節(jié)5.1 給模型一段報(bào)錯(cuò)信息看它如何定位我故意在代碼里制造幾個(gè)典型錯(cuò)誤一個(gè)變量未定義、一個(gè)異步時(shí)序問(wèn)題、一個(gè) CSS 選擇器寫(xiě)錯(cuò)。然后分別把報(bào)錯(cuò)信息原樣丟給四款模型看它們能不能直接定位并修復(fù)。K3 的定位能力最直接。它會(huì)先復(fù)述一遍錯(cuò)誤信息里最關(guān)鍵的代碼行再給出修改后的代碼段不會(huì)東拉西扯。這種回答方式對(duì)使用者最友好。GLM5.2 在變量未定義這類(lèi)簡(jiǎn)單問(wèn)題上處理也很快但遇到異步時(shí)序問(wèn)題時(shí)它會(huì)給出多種可能性讓你自己判斷是哪個(gè)原因。這不算錯(cuò)但排查效率會(huì)低一些。Fable5 定位異步問(wèn)題時(shí)最準(zhǔn)。它會(huì)主動(dòng)分析事件觸發(fā)的先后順序指出是數(shù)據(jù)還沒(méi)返回就渲染導(dǎo)致的空值錯(cuò)誤給出的修復(fù)方案也不會(huì)影響原有邏輯。Hy3 在這個(gè)環(huán)節(jié)表現(xiàn)中規(guī)中矩。它能修復(fù)簡(jiǎn)單錯(cuò)誤但遇到跨函數(shù)調(diào)用的報(bào)錯(cuò)時(shí)偶爾會(huì)給出錯(cuò)誤定位需要我進(jìn)一步提供上下文。這個(gè)問(wèn)題可以通過(guò)把整個(gè)文件內(nèi)容貼給它來(lái)緩解。5.2 需求變更時(shí)誰(shuí)的改動(dòng)更局部化做頁(yè)游最怕的就是需求突然變了模型把整個(gè)邏輯全部重寫(xiě)結(jié)果你之前改好的視覺(jué)細(xì)節(jié)全沒(méi)了。我測(cè)試了一個(gè)典型的變更場(chǎng)景把原本的回合制戰(zhàn)斗改成可以手動(dòng)選擇技能目標(biāo)。這個(gè)需求會(huì)牽動(dòng)技能面板、戰(zhàn)斗流程、日志記錄三個(gè)模塊。Fable5 的改動(dòng)最符合預(yù)期。因?yàn)樗拇a從一開(kāi)始就模塊化變更只落在技能選擇函數(shù)和戰(zhàn)斗流程入口原有視覺(jué)布局和日志邏輯沒(méi)有被破壞。K3 也能控制改動(dòng)范圍但需要你在提示詞里明確說(shuō)明“只改技能選擇相關(guān)邏輯其他部分保持不變”。它的執(zhí)行準(zhǔn)確但比較依賴(lài)提示詞約束。GLM5.2 在增加功能時(shí)比較激進(jìn)。給同一個(gè)需求后它會(huì)從“優(yōu)化整體架構(gòu)”的角度重構(gòu)戰(zhàn)斗循環(huán)導(dǎo)致一些原本微調(diào)過(guò)的細(xì)節(jié)被新版本覆蓋。改動(dòng)完成后需要檢查一遍回歸。Hy3 對(duì)需求變更的反應(yīng)最保守。它傾向用追加新函數(shù)的方式滿足新需求而不是修改原有函數(shù)。這樣改動(dòng)風(fēng)險(xiǎn)小但可能導(dǎo)致代碼冗余——每次需求變更都新增一個(gè)函數(shù)五六輪后代碼量會(huì)明顯膨脹。5.3 多輪對(duì)話中改壞代碼的概率這是我最在意的一項(xiàng)。頁(yè)游開(kāi)發(fā)往往要在一個(gè)會(huì)話里連續(xù)對(duì)話幾十次模型一旦在前期積累了大量上下文后期修改時(shí)很容易出現(xiàn)“改 A 破壞 B”的問(wèn)題。K3 和 Fable5 在連續(xù) 10 輪修改后仍然保持較高的正確率。K3 勝在狀態(tài)管理清晰Fable5 勝在模塊邊界明確。GLM5.2 在 10 輪后會(huì)偶爾出現(xiàn)“新代碼調(diào)用了舊版本中已經(jīng)被刪除的函數(shù)”這類(lèi)問(wèn)題。這不是普遍現(xiàn)象但在我的測(cè)試中出現(xiàn)過(guò)一次。Hy3 的冗余代碼問(wèn)題在長(zhǎng)時(shí)間對(duì)話中會(huì)被放大。它會(huì)不斷追加新的實(shí)現(xiàn)導(dǎo)致函數(shù)功能重疊后期你需要花時(shí)間清理。實(shí)測(cè)經(jīng)驗(yàn)如果你計(jì)劃在一個(gè)會(huì)話里和模型聊很久建議每完成一個(gè)功能節(jié)點(diǎn)就讓模型輸出一次當(dāng)前完整代碼。這樣即使后面改錯(cuò)了你也可以手動(dòng)回退到最近的穩(wěn)定版本。6. 最終結(jié)論四款模型分別適合什么人和什么場(chǎng)景6.1 綜合評(píng)分表下表是我對(duì)四款模型在頁(yè)游開(kāi)發(fā)場(chǎng)景下的主觀評(píng)分滿分為 5 分。這個(gè)評(píng)分只代表我的測(cè)試環(huán)境不代表絕對(duì)能力。維度K3Fable5GLM5.2Hy3單次生成完整度4.04.04.53.5多輪修改穩(wěn)定性4.54.53.53.5邏輯正確性4.54.04.04.0代碼可維護(hù)性4.04.53.53.5接口聯(lián)調(diào)能力4.04.54.03.0報(bào)錯(cuò)修復(fù)效率4.54.54.03.0如果只算平均分K3 和 Fable5 在這套測(cè)試?yán)锊⒘锌壳癎LM5.2 緊隨其后Hy3 落后一些。但平均分沒(méi)有意義因?yàn)椴煌说拈_(kāi)發(fā)場(chǎng)景完全不同。6.2 如果只選一款做頁(yè)游開(kāi)發(fā)對(duì)剛?cè)腴T(mén)的前端開(kāi)發(fā)者我建議從 GLM5.2 開(kāi)始。它的單次生成能力強(qiáng)能讓你快速看到一個(gè)完整頁(yè)面減少早期受挫感。等你有經(jīng)驗(yàn)了再換到更工程化的方案。對(duì)要長(zhǎng)期維護(hù)頁(yè)游項(xiàng)目的個(gè)人開(kāi)發(fā)者K3 或 Fable5 更合適。K3 的狀態(tài)管理寫(xiě)得好適合邏輯復(fù)雜的游戲Fable5 的模塊化設(shè)計(jì)好適合需求頻繁變化的項(xiàng)目。兩者選哪個(gè)取決于你更看重邏輯穩(wěn)定性還是代碼結(jié)構(gòu)。對(duì)已經(jīng)在大規(guī)模代碼庫(kù)里工作的團(tuán)隊(duì)Fable5 更接近團(tuán)隊(duì)協(xié)作風(fēng)格。它的代碼可讀性強(qiáng)字段命名規(guī)范其他成員接手成本低。K3 和 GLM5.2 更適合作個(gè)人輔助工具而不是團(tuán)隊(duì)統(tǒng)一接入模型。對(duì)追求極致響應(yīng)速度的臨時(shí)原型驗(yàn)證GLM5.2 最省事。它一次生成的長(zhǎng)代碼能快速覆蓋大部分需求即使個(gè)別邊界處理不完美后續(xù)手動(dòng)修也不麻煩。Hy3 并不是不好它的風(fēng)格更適合謹(jǐn)慎型開(kāi)發(fā)者。你希望模型先把核心功能做扎實(shí)再逐步美化界面那 Hy3 會(huì)讓你滿意。如果你需要它直接給一個(gè)足夠酷炫的成品它可能要排到最后一名。6.3 我的幾條實(shí)戰(zhàn)建議第一不要用同一個(gè)提示詞跑一款模型就直接決定長(zhǎng)期用它。你應(yīng)該準(zhǔn)備一套固定需求讓所有候選模型都跑一遍再連續(xù)改三輪需求。這個(gè)測(cè)試方法比看任何排行榜都真實(shí)。第二把“代碼結(jié)構(gòu)要求”寫(xiě)進(jìn)提示詞。哪怕實(shí)際使用中你根本不在乎結(jié)構(gòu)也建議讓模型輸出規(guī)范代碼因?yàn)楹罄m(xù)排錯(cuò)時(shí)結(jié)構(gòu)好不好直接影響效率。第三重要功能節(jié)點(diǎn)保存一次完整代碼。大模型對(duì)話窗口是有長(zhǎng)度限制的聊得越久越容易出現(xiàn)代碼陳舊或變量遺漏。每完成一個(gè)功能都讓模型輸出當(dāng)前完整文件對(duì)你來(lái)說(shuō)只是復(fù)制一次卻能避免很多返工。第四接口聯(lián)調(diào)階段不要完全依賴(lài)模型生成的 Mock 數(shù)據(jù)。讓模型先定義數(shù)據(jù)字段和類(lèi)型你再手動(dòng)維護(hù)一份樣例數(shù)據(jù)兩邊對(duì)齊后再開(kāi)發(fā)前端邏輯這樣能避開(kāi)字段不一致的坑。第五也是最容易被忽略的大模型生成的游戲邏輯一定要做回歸測(cè)試。不要因?yàn)樾鹿δ芗映晒α司陀X(jué)得舊功能沒(méi)問(wèn)題。特別是狀態(tài)切換、冷卻計(jì)時(shí)、重復(fù)點(diǎn)擊這類(lèi)環(huán)節(jié)改一次需求就應(yīng)該回歸一遍。如果你只想記住一句話做頁(yè)游輔助開(kāi)發(fā)K3 和 Fable5 更適合長(zhǎng)期項(xiàng)目GLM5.2 更適合快速原型Hy3 更適合你愿意多輪打磨的場(chǎng)景。剩下的靠你的實(shí)際需求來(lái)定。