1. 十年Unity老兵的那句“AI已經(jīng)超過(guò)很多程序員了”到底在說(shuō)什么先把場(chǎng)景還原一下。一個(gè)做了十年Unity的開(kāi)發(fā)者大概率經(jīng)歷過(guò)端游時(shí)代、手游爆發(fā)期、小游戲紅利期也踩過(guò)渲染管線升級(jí)、資源熱更、包體壓縮、多平臺(tái)適配這些坑。他說(shuō)“AI已經(jīng)超過(guò)很多程序員了”不是在說(shuō)AI能獨(dú)立做完一款商業(yè)游戲而是在說(shuō)一件更具體的事在大量標(biāo)準(zhǔn)化、模式化、可被清晰描述的編碼任務(wù)上AI的產(chǎn)出速度、覆蓋面和穩(wěn)定性已經(jīng)超過(guò)了一部分只會(huì)“照葫蘆畫(huà)瓢”的從業(yè)者。這句話聽(tīng)起來(lái)刺耳但如果你真的在游戲開(kāi)發(fā)一線待過(guò)就知道它指向的是真實(shí)存在的分層。Unity這個(gè)引擎的生態(tài)太成熟了成熟到大量工作已經(jīng)變成了“查文檔、拼API、調(diào)參數(shù)、改Bug”的循環(huán)。一個(gè)初級(jí)程序員每天做的事可能有六成以上是寫(xiě)一個(gè)對(duì)象池、接一個(gè)UI事件、做一個(gè)角色移動(dòng)、處理一次資源加載、修一個(gè)空引用報(bào)錯(cuò)。這些事有標(biāo)準(zhǔn)答案有大量公開(kāi)示例有固定的代碼結(jié)構(gòu)。AI最擅長(zhǎng)的恰恰就是這種“有明確輸入、有明確輸出、有大量先例”的任務(wù)。所以這篇內(nèi)容我想聊的不是“AI會(huì)不會(huì)取代程序員”這種大而空的話題而是從一個(gè)Unity從業(yè)者的視角拆解清楚三件事AI在游戲開(kāi)發(fā)里到底強(qiáng)在哪、弱在哪一個(gè)Unity開(kāi)發(fā)者應(yīng)該怎么把AI變成自己的杠桿以及那些AI暫時(shí)碰不了的能力到底長(zhǎng)什么樣。適合正在做Unity開(kāi)發(fā)、準(zhǔn)備入行游戲行業(yè)、或者已經(jīng)在帶團(tuán)隊(duì)但想搞清楚AI邊界的人看。不管你是剛裝完Unity的新手還是寫(xiě)了幾年C#的老手都能從下面這些拆解里找到能直接用的東西。2. AI在Unity開(kāi)發(fā)中的真實(shí)能力邊界拆解2.1 為什么標(biāo)準(zhǔn)化編碼任務(wù)最先被沖擊Unity的API設(shè)計(jì)有一個(gè)特點(diǎn)高度一致、命名規(guī)范、文檔齊全。Transform.Translate、Rigidbody.AddForce、Instantiate、Destroy這些方法的語(yǔ)義非常清晰參數(shù)也相對(duì)固定。這意味著什么意味著一個(gè)任務(wù)只要能被準(zhǔn)確描述AI就能給出可運(yùn)行的代碼。我拿一個(gè)具體例子來(lái)說(shuō)明。假設(shè)你要實(shí)現(xiàn)一個(gè)“物體在鼠標(biāo)點(diǎn)擊位置生成并且?guī)б粋€(gè)簡(jiǎn)單的彈出動(dòng)畫(huà)”。這個(gè)需求在Unity里太常見(jiàn)了AI拿到這句話能直接給出射線檢測(cè)獲取點(diǎn)擊位置、實(shí)例化預(yù)制體、用協(xié)程或DOTween做縮放動(dòng)畫(huà)、最后銷(xiāo)毀或回收。代碼結(jié)構(gòu)完整命名合理甚至還會(huì)提醒你注意Canvas的Raycast Target和物理層的Layer設(shè)置。這件事放在五年前一個(gè)新手可能要查半天文檔拼湊出能跑的代碼中間還會(huì)遇到“為什么點(diǎn)擊沒(méi)反應(yīng)”“為什么動(dòng)畫(huà)不播放”“為什么物體生成在相機(jī)后面”這些問(wèn)題。現(xiàn)在AI幾秒鐘就能給出一個(gè)可用的起點(diǎn)。差距不在于最終代碼有多優(yōu)雅而在于從零到可運(yùn)行的時(shí)間被壓縮了。但這里有個(gè)關(guān)鍵前提需求必須能被清晰描述。如果你說(shuō)“做一個(gè)好玩的戰(zhàn)斗系統(tǒng)”AI給不出有用的東西。如果你說(shuō)“做一個(gè)基于狀態(tài)機(jī)的近戰(zhàn)攻擊系統(tǒng)包含前搖、判定、后搖三個(gè)階段用Animator的StateMachineBehaviour驅(qū)動(dòng)”AI就能給出相當(dāng)靠譜的框架。所以AI沖擊的不是“會(huì)寫(xiě)代碼的人”而是“只會(huì)把模糊需求翻譯成代碼、但自己不理解需求本質(zhì)的人”。2.2 AI在Unity里最擅長(zhǎng)的五類(lèi)任務(wù)我把實(shí)際用下來(lái)AI表現(xiàn)最好的任務(wù)類(lèi)型整理成了一張表你可以對(duì)照自己的日常工作看看占比任務(wù)類(lèi)型典型場(chǎng)景AI表現(xiàn)注意事項(xiàng)API調(diào)用與樣板代碼對(duì)象池、事件系統(tǒng)、單例、協(xié)程封裝極強(qiáng)需要檢查是否用了過(guò)時(shí)APIBug定位與修復(fù)空引用、數(shù)組越界、協(xié)程不執(zhí)行強(qiáng)需要提供完整報(bào)錯(cuò)和上下文代碼解釋與注釋接手他人代碼、理解第三方插件極強(qiáng)對(duì)混淆代碼效果差簡(jiǎn)單算法實(shí)現(xiàn)尋路、排序、對(duì)象篩選、狀態(tài)機(jī)強(qiáng)復(fù)雜算法需要人工驗(yàn)證配置與工具腳本編輯器擴(kuò)展、批量處理、數(shù)據(jù)導(dǎo)入強(qiáng)涉及Editor API需注意版本這五類(lèi)任務(wù)有一個(gè)共同點(diǎn)輸入和輸出之間的映射關(guān)系是確定的且存在大量公開(kāi)的先例。AI本質(zhì)上是在做高維度的模式匹配和概率生成它見(jiàn)過(guò)足夠多的Unity代碼所以能生成“看起來(lái)對(duì)、跑起來(lái)也對(duì)”的結(jié)果。但注意表格里“注意事項(xiàng)”那一列。AI生成的代碼有一個(gè)通病它可能用了Unity 2018的寫(xiě)法而你的項(xiàng)目是Unity 2022它可能用了某個(gè)已經(jīng)廢棄的API它可能忽略了你的項(xiàng)目用的是URP而不是內(nèi)置管線。這些不是AI的錯(cuò)是它不知道你的上下文。所以用AI寫(xiě)代碼審查環(huán)節(jié)不能省尤其是版本相關(guān)和管線相關(guān)的部分。2.3 那些AI暫時(shí)碰不了的能力說(shuō)AI強(qiáng)不代表它全能。在Unity開(kāi)發(fā)里有幾類(lèi)能力AI目前表現(xiàn)很差甚至完全幫不上忙。第一類(lèi)是性能直覺(jué)。一個(gè)做了十年Unity的人看到一段代碼就能大致判斷出它在移動(dòng)端會(huì)不會(huì)掉幀、GC會(huì)不會(huì)爆、Draw Call會(huì)不會(huì)超標(biāo)。這種直覺(jué)來(lái)自大量真機(jī)測(cè)試和優(yōu)化經(jīng)驗(yàn)AI沒(méi)有。你問(wèn)AI“這段代碼在驍龍865上能跑多少幀”它給不出可信答案。你問(wèn)它“這個(gè)粒子效果在低端機(jī)上會(huì)不會(huì)成為瓶頸”它也只能給通用建議。第二類(lèi)是架構(gòu)決策。一個(gè)項(xiàng)目該用ECS還是傳統(tǒng)GameObject、該用Addressable還是自己寫(xiě)資源管理、該用狀態(tài)機(jī)還是行為樹(shù)這些決策依賴(lài)對(duì)項(xiàng)目規(guī)模、團(tuán)隊(duì)能力、上線時(shí)間、維護(hù)周期的綜合判斷。AI可以列出優(yōu)缺點(diǎn)但做不了取舍。取舍需要承擔(dān)后果AI不承擔(dān)后果。第三類(lèi)是跨模塊的隱性知識(shí)。比如你們項(xiàng)目的UI框架有一個(gè)隱藏的初始化順序比如某個(gè)第三方插件在特定平臺(tái)上有已知問(wèn)題比如美術(shù)資源的命名規(guī)范會(huì)影響打包邏輯。這些知識(shí)不在公開(kāi)語(yǔ)料里只存在于團(tuán)隊(duì)成員的腦子里和項(xiàng)目的歷史提交記錄里。AI不知道也學(xué)不到。第四類(lèi)是創(chuàng)意和體驗(yàn)設(shè)計(jì)。一個(gè)關(guān)卡怎么設(shè)計(jì)才有節(jié)奏感一個(gè)技能的手感怎么調(diào)才爽一個(gè)UI的動(dòng)效怎么做出高級(jí)感這些是審美和經(jīng)驗(yàn)的產(chǎn)物。AI可以生成“能用的”方案但生成不了“讓人記住的”方案。提示把AI當(dāng)成一個(gè)知識(shí)面極廣、手速極快、但完全沒(méi)有項(xiàng)目上下文、也不承擔(dān)任何責(zé)任的初級(jí)助手。這個(gè)定位最接近實(shí)際。3. 把AI變成杠桿Unity開(kāi)發(fā)者的實(shí)操工作流3.1 從需求到代碼我實(shí)際用的提示詞結(jié)構(gòu)很多人用AI寫(xiě)代碼效果不好問(wèn)題往往出在提示詞太模糊。我自己的習(xí)慣是把一個(gè)任務(wù)拆成四段來(lái)描述環(huán)境、目標(biāo)、約束、驗(yàn)收標(biāo)準(zhǔn)。舉個(gè)例子。我要做一個(gè)“敵人受擊后閃白并擊退”的效果。我不會(huì)直接說(shuō)“幫我寫(xiě)個(gè)受擊效果”而是這樣組織環(huán)境Unity 2022.3URP管線2D項(xiàng)目使用Sprite Renderer。 目標(biāo)敵人受到傷害時(shí)精靈閃白0.1秒同時(shí)向受擊反方向擊退0.5個(gè)單位擊退用DOTween實(shí)現(xiàn)。 約束不能修改原有材質(zhì)閃白用MaterialPropertyBlock實(shí)現(xiàn)擊退期間敵人AI暫停擊退結(jié)束后恢復(fù)。 驗(yàn)收標(biāo)準(zhǔn)連續(xù)受擊時(shí)閃白不疊加、擊退方向正確、AI暫停和恢復(fù)無(wú)延遲。這樣一段描述AI給出的代碼基本可以直接用我只需要檢查MaterialPropertyBlock的用法和DOTween的API版本。關(guān)鍵不在于提示詞寫(xiě)得多長(zhǎng)而在于把“我腦子里的隱性約束”顯性化。你腦子里的約束越多、越清晰AI的輸出就越接近可用。這里有個(gè)反直覺(jué)的點(diǎn)提示詞寫(xiě)得好本身就是一種能力。能把需求拆解清楚的人往往自己也能寫(xiě)代碼而寫(xiě)不清楚需求的人AI也救不了。所以AI沒(méi)有降低門(mén)檻它只是把門(mén)檻從“會(huì)寫(xiě)代碼”轉(zhuǎn)移到了“會(huì)描述問(wèn)題”。3.2 用AI做代碼審查和重構(gòu)的實(shí)戰(zhàn)方法AI不只是寫(xiě)新代碼用它來(lái)審查和重構(gòu)老代碼收益可能更大。我常用的做法是把一段自己寫(xiě)的、能跑但感覺(jué)不夠好的代碼丟給AI讓它從三個(gè)角度分析——可讀性、性能、擴(kuò)展性。比如我之前寫(xiě)了一個(gè)對(duì)象池功能沒(méi)問(wèn)題但代碼有點(diǎn)亂。我讓AI分析后它指出了幾個(gè)點(diǎn)池的容量沒(méi)有上限可能導(dǎo)致內(nèi)存泄漏獲取對(duì)象時(shí)沒(méi)有做空引用檢查回收時(shí)沒(méi)有重置Transform可能導(dǎo)致下次使用時(shí)位置錯(cuò)誤。這些都是我寫(xiě)的時(shí)候沒(méi)意識(shí)到的。但這里有個(gè)坑AI的重構(gòu)建議不一定適合你的項(xiàng)目。它可能建議你用對(duì)象池模式但你的項(xiàng)目已經(jīng)有了一套池管理它可能建議你用事件解耦但你的團(tuán)隊(duì)約定就是直接引用。所以我的做法是讓AI列問(wèn)題我自己決定改不改。AI負(fù)責(zé)發(fā)現(xiàn)我負(fù)責(zé)決策。還有一個(gè)實(shí)用技巧讓AI把你的代碼翻譯成“人話”。我接手過(guò)一個(gè)前同事的項(xiàng)目里面有一段協(xié)程嵌套協(xié)程的代碼邏輯繞得不行。我把它丟給AI讓它用自然語(yǔ)言描述這段代碼在做什么。AI的描述幫我快速理解了意圖然后我才決定是重構(gòu)還是保留。這個(gè)用法在接手遺留項(xiàng)目時(shí)特別省時(shí)間。3.3 用AI加速學(xué)習(xí)Unity的路徑設(shè)計(jì)如果你是新手AI最大的價(jià)值不是幫你寫(xiě)代碼而是幫你設(shè)計(jì)學(xué)習(xí)路徑和解釋概念。Unity的學(xué)習(xí)曲線有一個(gè)特點(diǎn)入門(mén)容易但知識(shí)面極廣。渲染、物理、動(dòng)畫(huà)、UI、音頻、網(wǎng)絡(luò)、資源管理、平臺(tái)適配每個(gè)方向都能深挖。新手最容易犯的錯(cuò)是東學(xué)一點(diǎn)西學(xué)一點(diǎn)最后什么都不精。這時(shí)候你可以讓AI幫你做一件事根據(jù)你的目標(biāo)倒推需要掌握的知識(shí)點(diǎn)并排出優(yōu)先級(jí)。比如你說(shuō)“我想做微信小游戲用Unity”AI可以幫你列出Unity基礎(chǔ)、C#基礎(chǔ)、UGUI、2D物理、資源加載、微信小游戲適配、包體優(yōu)化、性能優(yōu)化。然后你可以讓它把每個(gè)知識(shí)點(diǎn)再拆成具體的學(xué)習(xí)任務(wù)和練習(xí)項(xiàng)目。這比你自己在網(wǎng)上亂翻教程效率高得多。但注意AI給的學(xué)習(xí)路徑是通用的你需要根據(jù)自己的情況調(diào)整。它的價(jià)值在于幫你建立全局視圖而不是替你決定學(xué)什么。我見(jiàn)過(guò)有人完全按AI的路徑學(xué)結(jié)果學(xué)了一堆用不上的東西。正確的做法是AI給框架你根據(jù)項(xiàng)目需求裁剪。4. 一個(gè)完整案例用AI輔助做一個(gè)Unity小游戲原型4.1 項(xiàng)目設(shè)定與需求拆解為了把上面的方法串起來(lái)我拿一個(gè)實(shí)際做過(guò)的小項(xiàng)目來(lái)拆解。項(xiàng)目目標(biāo)做一個(gè)2D俯視角的生存小游戲原型玩家控制角色移動(dòng)敵人從四周生成并追蹤玩家玩家自動(dòng)攻擊最近的敵人擊殺敵人獲得分?jǐn)?shù)玩家有生命值歸零則游戲結(jié)束。這個(gè)原型不大但覆蓋了Unity開(kāi)發(fā)的幾個(gè)核心模塊輸入、移動(dòng)、AI追蹤、戰(zhàn)斗、UI、游戲狀態(tài)管理。我給自己定的時(shí)間是一個(gè)下午用AI輔助完成。下面是我實(shí)際的流程。第一步不是寫(xiě)代碼而是讓AI幫我把需求拆成模塊。我給出的描述是“2D俯視角生存游戲原型玩家移動(dòng)、敵人追蹤、自動(dòng)攻擊、分?jǐn)?shù)和生命值UI、游戲結(jié)束重開(kāi)?！盇I返回的模塊劃分是玩家控制器、敵人AI、戰(zhàn)斗系統(tǒng)、生成器、UI管理器、游戲管理器。這個(gè)劃分和我預(yù)想的一致說(shuō)明需求描述是清晰的。第二步是確定技術(shù)選型。我讓AI對(duì)比了“用Rigidbody2D做移動(dòng)”和“直接改Transform”兩種方案。AI給出的結(jié)論是如果不需要物理碰撞和力反饋直接改Transform更簡(jiǎn)單、性能更好如果需要碰撞檢測(cè)用Rigidbody2D配合Kinematic更合適。我選擇了Rigidbody2D因?yàn)閿橙俗粉櫺枰鲎矙z測(cè)來(lái)觸發(fā)攻擊。這個(gè)決策AI幫了忙但最終是我拍的板。4.2 核心模塊的AI輔助實(shí)現(xiàn)過(guò)程玩家控制器是最簡(jiǎn)單的部分。我給AI的描述是“2D角色WASD移動(dòng)速度5用Rigidbody2D移動(dòng)在FixedUpdate里處理朝向跟隨移動(dòng)方向?！盇I給出的代碼基本可用我改了一個(gè)地方它用了Input.GetAxisRaw我改成了新輸入系統(tǒng)的InputAction因?yàn)轫?xiàng)目模板用的是新輸入系統(tǒng)。這個(gè)改動(dòng)AI不知道因?yàn)槲覜](méi)有在提示詞里說(shuō)明輸入系統(tǒng)版本。敵人AI稍微復(fù)雜一點(diǎn)。需求是“追蹤玩家接近到一定距離后停止攻擊有冷卻”。AI給出的方案是用Vector2.Distance判斷距離用協(xié)程做攻擊冷卻。我檢查后發(fā)現(xiàn)一個(gè)問(wèn)題如果敵人在冷卻期間死亡協(xié)程還在跑可能導(dǎo)致空引用。我讓AI修改它給出了加if (this null) yield break;的方案。這個(gè)方案能用但更規(guī)范的做法是在OnDestroy里停止協(xié)程。AI給的是“能跑”的方案不是“最規(guī)范”的方案這個(gè)區(qū)別要心里有數(shù)。戰(zhàn)斗系統(tǒng)我讓AI實(shí)現(xiàn)了“自動(dòng)攻擊最近的敵人”。AI用了Physics2D.OverlapCircleAll獲取范圍內(nèi)敵人然后遍歷找最近的。這個(gè)實(shí)現(xiàn)沒(méi)問(wèn)題但我提醒它加上“攻擊間隔”和“目標(biāo)丟失后重新索敵”的邏輯。加上之后代碼量翻了一倍但功能完整了。這里體現(xiàn)了一個(gè)原則AI給骨架你補(bǔ)細(xì)節(jié)。骨架是通用的細(xì)節(jié)是項(xiàng)目特有的。生成器和UI管理器都是標(biāo)準(zhǔn)任務(wù)AI完成得很快。游戲管理器涉及狀態(tài)切換我讓AI用簡(jiǎn)單的枚舉狀態(tài)機(jī)實(shí)現(xiàn)它給出的代碼結(jié)構(gòu)清晰我直接用了。4.3 實(shí)測(cè)結(jié)果與效率對(duì)比整個(gè)原型從零到可玩我花了大約四個(gè)小時(shí)。其中寫(xiě)代碼的時(shí)間不到兩小時(shí)剩下兩小時(shí)在調(diào)試和調(diào)整手感。如果不用AI我估計(jì)需要六到八小時(shí)差距主要在中途查文檔和寫(xiě)樣板代碼上。但有幾個(gè)地方AI沒(méi)幫上忙。一是手感調(diào)整敵人的移動(dòng)速度、攻擊范圍、生成頻率這些參數(shù)需要反復(fù)試玩才能確定AI給不了建議。二是視覺(jué)反饋受擊閃白、傷害數(shù)字、屏幕震動(dòng)這些效果我知道怎么做但AI給的實(shí)現(xiàn)方式不夠好我最后自己重寫(xiě)了。三是性能問(wèn)題敵人數(shù)量到五十個(gè)以上時(shí)OverlapCircleAll每幀調(diào)用導(dǎo)致幀率下降我改成了用觸發(fā)器加列表維護(hù)這個(gè)優(yōu)化AI沒(méi)有主動(dòng)提出。所以效率提升是真實(shí)的但集中在“寫(xiě)”的環(huán)節(jié)“調(diào)”和“優(yōu)”的環(huán)節(jié)還是靠人。AI壓縮的是從想法到可運(yùn)行的距離但沒(méi)有壓縮從可運(yùn)行到好玩的距離。5. 常見(jiàn)問(wèn)題與避坑指南5.1 AI生成代碼的典型問(wèn)題速查用AI寫(xiě)Unity代碼下面這些問(wèn)題我?guī)缀趺看味加龅秸沓杀矸奖隳銓?duì)照排查問(wèn)題現(xiàn)象根本原因解決方法代碼報(bào)錯(cuò)找不到APIAI用了舊版本或不同管線的API在提示詞里寫(xiě)明Unity版本和渲染管線運(yùn)行時(shí)報(bào)空引用AI假設(shè)了某些對(duì)象一定存在手動(dòng)加空引用檢查和默認(rèn)值性能不達(dá)標(biāo)AI用了每幀調(diào)用的昂貴API用Profiler定位改成事件驅(qū)動(dòng)或緩存邏輯不符合預(yù)期需求描述有歧義補(bǔ)充邊界條件和異常情況代碼風(fēng)格不統(tǒng)一AI不知道你的團(tuán)隊(duì)規(guī)范提供一段現(xiàn)有代碼作為風(fēng)格參考這張表里最值得說(shuō)的是“性能不達(dá)標(biāo)”。AI生成的代碼有一個(gè)傾向用最直觀的方式實(shí)現(xiàn)功能而不是最優(yōu)的方式。比如查找對(duì)象用Find、每幀用GetComponent、頻繁用Instantiate和Destroy。這些寫(xiě)法在原型階段沒(méi)問(wèn)題但上線前必須優(yōu)化。我的習(xí)慣是AI寫(xiě)完功能代碼后自己過(guò)一遍把明顯的性能問(wèn)題標(biāo)出來(lái)等原型驗(yàn)證通過(guò)后再統(tǒng)一優(yōu)化。5.2 新手最容易踩的三個(gè)坑第一個(gè)坑是過(guò)度依賴(lài)AI導(dǎo)致基礎(chǔ)不牢。我見(jiàn)過(guò)有人用AI寫(xiě)了半年代碼但問(wèn)他“協(xié)程和異步的區(qū)別”說(shuō)不清楚問(wèn)他“為什么用對(duì)象池”也說(shuō)不清楚。這種狀態(tài)很危險(xiǎn)因?yàn)橐坏〢I給不出答案或者項(xiàng)目需要深度優(yōu)化他就卡住了。AI可以幫你跳過(guò)重復(fù)勞動(dòng)但不能幫你跳過(guò)理解。我的建議是AI給的每一段代碼你都要能解釋清楚它在做什么、為什么這么做。解釋不了就去查、去問(wèn)、去搞懂。第二個(gè)坑是把AI的答案當(dāng)唯一答案。AI給出的方案往往是“常見(jiàn)方案”不是“最優(yōu)方案”。比如實(shí)現(xiàn)一個(gè)冷卻計(jì)時(shí)AI可能用Time.time做減法但你的項(xiàng)目如果涉及暫停功能用Time.deltaTime累加更合適。AI不知道你的項(xiàng)目有沒(méi)有暫停、有沒(méi)有時(shí)間縮放、有沒(méi)有網(wǎng)絡(luò)同步。所以永遠(yuǎn)要問(wèn)自己這個(gè)方案在我的項(xiàng)目里適用嗎第三個(gè)坑是忽略版本和平臺(tái)差異。Unity的版本迭代很快不同版本之間API有差異不同平臺(tái)之間行為也有差異。AI的訓(xùn)練數(shù)據(jù)有滯后性它可能不知道Unity 6的新特性也可能不知道某個(gè)API在WebGL上不可用。涉及版本和平臺(tái)的部分一定要以官方文檔為準(zhǔn)。5.3 團(tuán)隊(duì)協(xié)作中引入AI的注意事項(xiàng)如果你在團(tuán)隊(duì)里推廣AI輔助開(kāi)發(fā)有幾件事需要提前約定。第一是代碼審查不能省。AI生成的代碼必須經(jīng)過(guò)人工審查才能合入主分支。審查的重點(diǎn)不是“能不能跑”而是“符不符合項(xiàng)目規(guī)范”“有沒(méi)有性能隱患”“有沒(méi)有安全風(fēng)險(xiǎn)”。第二是提示詞和生成結(jié)果要留痕。我建議團(tuán)隊(duì)維護(hù)一個(gè)共享的提示詞庫(kù)把好用的提示詞沉淀下來(lái)。同時(shí)AI生成的關(guān)鍵代碼要在提交信息里注明方便后續(xù)追溯。這不是不信任AI而是為了在出問(wèn)題時(shí)能快速定位。第三是不要用AI處理敏感信息。項(xiàng)目里的賬號(hào)密碼、私有算法、未公開(kāi)的設(shè)計(jì)文檔不要貼給AI。這不是技術(shù)問(wèn)題是職業(yè)操守問(wèn)題。第四是給AI設(shè)定明確的角色。在團(tuán)隊(duì)里AI的定位應(yīng)該是“輔助工具”不是“決策者”。架構(gòu)選型、技術(shù)方案、上線標(biāo)準(zhǔn)這些必須由人拍板。AI可以參與討論但不能承擔(dān)責(zé)任。6. 那些AI替代不了的東西才是你的護(hù)城河回到開(kāi)頭那句話。做了十年Unity的人說(shuō)“AI已經(jīng)超過(guò)很多程序員了”我理解他的意思不是“程序員沒(méi)用了”而是“只會(huì)做標(biāo)準(zhǔn)化任務(wù)的那部分能力不再稀缺了”。這其實(shí)是一件好事因?yàn)樗浦鴱臉I(yè)者往上游走。上游是什么是定義問(wèn)題的能力。AI能解決問(wèn)題但定義不了問(wèn)題。一個(gè)游戲好不好玩、一個(gè)系統(tǒng)該不該做、一個(gè)技術(shù)債該不該還這些判斷需要經(jīng)驗(yàn)、審美和責(zé)任感。AI沒(méi)有這些。是跨領(lǐng)域整合的能力。Unity開(kāi)發(fā)從來(lái)不是只寫(xiě)代碼你要懂一點(diǎn)美術(shù)、一點(diǎn)策劃、一點(diǎn)項(xiàng)目管理。你要能和美術(shù)溝通資源規(guī)范能和策劃溝通數(shù)值邏輯能和測(cè)試溝通復(fù)現(xiàn)步驟。這些溝通和整合AI做不了。是在約束下做取舍的能力。項(xiàng)目永遠(yuǎn)有約束時(shí)間不夠、人手不夠、性能不夠、預(yù)算不夠。在約束下找到可行解這是工程師的核心價(jià)值。AI可以在無(wú)約束的情況下給出“理論上最優(yōu)”的方案但現(xiàn)實(shí)里沒(méi)有無(wú)約束的項(xiàng)目。所以我的結(jié)論是AI沒(méi)有讓Unity開(kāi)發(fā)者貶值它讓“只會(huì)寫(xiě)代碼”這件事貶值了。如果你把AI用起來(lái)把自己從重復(fù)勞動(dòng)里解放出來(lái)去積累那些AI學(xué)不會(huì)的能力你的價(jià)值反而會(huì)上升。如果你把AI當(dāng)敵人拒絕用它那你可能真的會(huì)被那些用AI的人超過(guò)。最后分享一個(gè)我自己的習(xí)慣每次用AI解決一個(gè)問(wèn)題后我會(huì)花五分鐘問(wèn)自己——這個(gè)問(wèn)題AI為什么能解決它的解決方式和我自己想的有什么不同如果下次遇到類(lèi)似問(wèn)題我能不能不靠AI也做得更好把AI當(dāng)成一面鏡子照出自己能力的邊界然后去拓展它。這比單純用AI省時(shí)間有價(jià)值得多。