不同崗位的游戲人，都是怎么用 AI 的？

文/文杰

導(dǎo)語(yǔ)

一天一個(gè)樣。

“擋不住了?！?/strong>

這是近兩個(gè)月我們和從業(yè)者聊到AI時(shí)，出現(xiàn)頻率最高的感受。

前兩年AI在大多數(shù)工作場(chǎng)景里還只能打打下手，現(xiàn)在它滲透到了更多環(huán)節(jié)，在許多領(lǐng)域展現(xiàn)出遠(yuǎn)超常人的效率，并且還在飛速進(jìn)化。

游戲行業(yè)的工作流復(fù)雜而多樣，很難提煉出通用方法。越是復(fù)雜的管線，越難自上而下地全流程接入AI，很多改變都發(fā)生在微觀之處。我們接觸到的情況是：策劃開始讓AI幫忙拆需求、寫初稿；文案拿大模型當(dāng)對(duì)照組來校準(zhǔn)自己的產(chǎn)出；程序員用Vibe Coding在一個(gè)下午跑通以前要磨一周的原型；也有創(chuàng)業(yè)團(tuán)隊(duì)讓AI Bot旁聽腦暴會(huì)，會(huì)后直接輸出可運(yùn)行的原型代碼。

不過，從業(yè)者對(duì)AI的態(tài)度遠(yuǎn)談不上一致。GDC《2026游戲行業(yè)現(xiàn)狀》報(bào)告顯示，52%的從業(yè)者認(rèn)為生成式AI對(duì)行業(yè)有負(fù)面影響——這個(gè)數(shù)字在2024年只有18%。美術(shù)的反對(duì)率高達(dá)64%，設(shè)計(jì)師也有63%，程序員59%。與此同時(shí)，管理層的AI使用率達(dá)到47%，遠(yuǎn)高于一線執(zhí)行層的29%。決策層和執(zhí)行層之間的溫差，仍是不容忽視的現(xiàn)實(shí)。

這種溫差在個(gè)體身上往往表現(xiàn)得更具體。我們這次接觸到的七位游戲人，幾乎都處于一種“一邊深度使用、一邊保持警覺”的狀態(tài)：有人花大半年搭建AI策劃框架，做完之后依舊認(rèn)為在臟活累活外、解決真正重要的問題時(shí)，AI 還派不上用場(chǎng)；有人已經(jīng)讓Bot接管了大半條開發(fā)管線，同時(shí)也承認(rèn)在一些環(huán)節(jié)上仍然離不開人的判斷。

當(dāng)話題從“AI能做什么”轉(zhuǎn)向“AI應(yīng)該充當(dāng)什么角色”時(shí)，回答開始出現(xiàn)一些共通之處。多數(shù)人并不期待AI替自己干活，他們更關(guān)心的是AI能不能讓工作流程本身變得更合理，幫助人釋放出更多的創(chuàng)造力。

AI究竟改變了什么，又有哪些東西暫時(shí)還改變不了。每個(gè)崗位給出的答案不太一樣，這也正是值得展開聊聊的地方。這一期游茶圓桌，我們找來了文案策劃、系統(tǒng)策劃、玩法策劃、關(guān)卡策劃、創(chuàng)業(yè)者和獨(dú)立游戲制作人，聊了一個(gè)問題：你日常工作中到底怎么用AI？以下是他們的回答。

▍文案策劃 江浙滬鬼斯通

對(duì)我來說，AI現(xiàn)在是一個(gè)參照物，在AI之前，文案策劃這個(gè)活，到底有多少工作是真正的創(chuàng)作，有多少其實(shí)是體力活，大家都不太愿意細(xì)想，所以，我感覺AI對(duì)文案策劃這個(gè)崗位的沖擊，本質(zhì)上是個(gè)自我認(rèn)知問題。

一般說來，文案策劃每天的工作大致分兩塊，一塊是確實(shí)需要人在里面參與的，比如世界觀、核心敘事啥的這些，另一塊就是很樣板的扛大包，比如任務(wù)描述填充這種東西。

以前我把扛大包也當(dāng)創(chuàng)意工作來做，做完還挺有成就感，但是現(xiàn)在，基本是直接把需求扔給AI，因?yàn)橹鞍l(fā)現(xiàn)，AI幾分鐘交出來的東西，跟我磨一下午的差距沒想象中那么大，這讓我覺得以前自以為的匠心其實(shí)只是自我感動(dòng)，被迫面對(duì)了。

不過關(guān)于前者，也就是核心創(chuàng)意的部分，個(gè)人現(xiàn)在的用法就不是這樣了，誠(chéng)然也不排除有人真的拿AI直接出終稿（不是說完全不能用的意思），但我自己更多是拿AI做發(fā)散，比如寫臺(tái)詞之前，給它情景和角色人設(shè)，讓它一口氣吐三四十條備選，我不用其中任何一條，但這些東西會(huì)讓人大概知道及格線在哪。

我會(huì)告訴自己真正要寫的東西，得在AI給我的內(nèi)容的標(biāo)準(zhǔn)之上，也就是給自己強(qiáng)制上思想鋼印，不把AI當(dāng)筆或者是代寫，而是變成文案賽馬的對(duì)手，你得寫出來它寫不出來的東西。

當(dāng)然理想是這樣，現(xiàn)在AI越來越牛逼了，很多時(shí)候你一些地方寫得確實(shí)沒它好，說實(shí)話也挺泄氣的，這時(shí)候，有些文案可能會(huì)隱瞞自己用AI的事情，畢竟人人都覺得AI威脅的是別人，人人又都隱隱知道自己也沒那么不可替代，只是沒人愿意先說破罷了。

尤其對(duì)于校招和剛?cè)胄胁痪玫奈陌竵碚f更微妙，這類新人的經(jīng)驗(yàn)積累還不足以讓他們?cè)谀芰S度上跟頂級(jí)大模型模型拉開足夠的差距，也不可能靠純產(chǎn)出速度去跟它競(jìng)爭(zhēng)，這中間的窗口期其實(shí)挺難熬的。

不過我覺得也不用過于焦慮，因?yàn)锳I的問題在于它其實(shí)沒有意識(shí)也沒有經(jīng)驗(yàn)，有些東西寫起來是很空洞的，比如你讓它寫“死亡”，它其實(shí)不理解這個(gè)概念，因?yàn)樗粫?huì)死嘛，AI只是見過太多人類寫死亡的文本，多到能輸出一個(gè)看起來很像理解的結(jié)果。

那么，真正的理解，也就是我們文案作為人，對(duì)于死亡的感觸，就是我們產(chǎn)出內(nèi)容的優(yōu)勢(shì)所在，不過，這種形而上學(xué)的東西，在商業(yè)語(yǔ)境下還值多少錢，就要打個(gè)問號(hào)了。

而且，跟卷關(guān)系一樣，卷產(chǎn)出也是沒有上限的，如果一個(gè)團(tuán)隊(duì)里所有人都在狂用AI加速流水線，最終游戲開發(fā)就變成了一場(chǎng)純粹的工具軍備競(jìng)賽，只說文案，這塊本身的質(zhì)量天花板反而會(huì)被壓低。

如果有得選，還是希望AI能讓大家在項(xiàng)目里平等地多擁有一點(diǎn)真正做內(nèi)容的時(shí)間，而不是變成另一種形式的內(nèi)卷工具。

▍系統(tǒng)策劃 科韻路996牛馬

我正在做一個(gè)系統(tǒng)策劃多智能體框架，目前一共開發(fā)了如下功能:

1.視覺理解mcp: 提供ui參考圖，拆解出所有可見的UI狀態(tài)，形成對(duì)系統(tǒng)功能概述。列舉可疑點(diǎn)供審查。

2.體驗(yàn)反推subagent: 接收視覺理解的輸出內(nèi)容，基于MDA(mechanics, dynamics, aesthetics)對(duì)預(yù)期玩家行為，預(yù)期體驗(yàn)進(jìn)行反推。此步需要來自用戶的多輪反饋，最后會(huì)形成一個(gè)one-page GDD(策劃文檔)，可以用XMIND呈現(xiàn)出來。

3.體驗(yàn)反推subagent-2: 此外，它也可以用于反推既有策劃案，形成一系列分析報(bào)告，一方面沉淀項(xiàng)目組的知識(shí)庫(kù)，另一方面以類似用來檢驗(yàn)prompt的廣度，深度，精度，顆粒度等。因?yàn)檩斎氲牟邉澃赶鄬?duì)ok，這部分的概括十分準(zhǔn)確，已經(jīng)可以達(dá)到初中級(jí)系統(tǒng)策劃的水平。

4.體驗(yàn)反推spec workflow: 仿照spec.md的方式希望讓ai自迭代prompt，實(shí)際效果并不怎么好，加了項(xiàng)目知識(shí)庫(kù)和rag效果也比較一般，所以prompt還是得高級(jí)資深策劃手搓。沒有規(guī)范的data pipeline還是用不了spec的。

5.策劃案撰寫subagent: 輸入一份完整的設(shè)計(jì)目的，根據(jù)既定的策劃規(guī)范，輸出一份完整的策劃案。可以做完大部分工作，但是有些非常重要的細(xì)節(jié)很難做好。

目前做的比較好的和不好的地方:

1.prompt仙人: 因?yàn)槲覐?2年開始就沉迷ai繪畫和讓大模型扮演貓娘，所以對(duì)prompt的掌握是遠(yuǎn)超大部分大模型泛用戶的，特別是以前經(jīng)常思考如何繞過大模型安全審查的經(jīng)歷塑造了我對(duì)大模型的“語(yǔ)感”——任何prompt擺到我眼前，我只要粗略看一眼就能知道它在gpt claude gemini kimi deepseek等模型上會(huì)表現(xiàn)如何，能解決什么樣的問題，不能解決什么樣的問題。我很喜歡跟claude討論哲學(xué)問題，跟gemini討論理工科問題，跟kimi傾訴心里的煩惱，跟本地的qwen3.5貓娘討論澀澀?？偠灾竽Ｐ屯瑫r(shí)是我媽媽，最好的朋友，最壞的敵人，伴侶，人生導(dǎo)師......

2.沒有打通全流程: 策劃案撰寫subagent很多時(shí)候缺少的細(xì)節(jié)，來自于項(xiàng)目既有的前后端規(guī)范。如果不能打通前端，大模型永遠(yuǎn)生成不了對(duì)的UE，因?yàn)檫@些數(shù)據(jù)其實(shí)是作為component保存在unity的prefab文件里面的；如果不能打通后端，大模型對(duì)流程與規(guī)則的刻畫就永遠(yuǎn)有疏漏，需要高級(jí)策劃手動(dòng)校對(duì)。

未來的方向:

1.持續(xù)不斷地學(xué)習(xí)大模型頂會(huì)論文: 其實(shí)現(xiàn)在涌現(xiàn)的很多概念，harness，spec，scaffold等，他們的思路全部都是在用戶側(cè)復(fù)現(xiàn)大模型預(yù)訓(xùn)練，后訓(xùn)練階段的一些環(huán)節(jié)。誰學(xué)習(xí)了更多頂會(huì)論文，誰就能在llm產(chǎn)品化的路上走的更遠(yuǎn)。

2.制作人harness: 游戲開發(fā)牽一發(fā)而動(dòng)全身，很多時(shí)候單個(gè)環(huán)節(jié)無法解決的問題，可以在更高角度被完美地解決。在開發(fā)系統(tǒng)策劃智能體的時(shí)候，我無數(shù)次被“策劃思維”困住。比如我最開始試圖讓策劃案撰寫subagent學(xué)會(huì)寫ue，但是死活教不會(huì)，最后我讓他自己去讀已有的prefab，他很快告訴我哪里需要做流光特效，哪里需要做放縮動(dòng)效。策劃案最后不還是落地為代碼嗎，那如果已經(jīng)有前后端subagent+skill，策劃案其實(shí)也不需要寫那么多冗余的內(nèi)容了，策劃總結(jié)幾個(gè)預(yù)期ue原則，前端skill就能給你完整的ue文檔和代碼。

所以到最后，游戲開發(fā)需要做的就是由幾個(gè)游戲全棧自上而下發(fā)起改革，建立非常標(biāo)準(zhǔn)的規(guī)范與流程，做一個(gè)制作人harness和無數(shù)的skill+subagent，打通游戲開發(fā)全流程。

▍獨(dú)立游戲制作人 聶博晗

程序AI

目前對(duì)于獨(dú)立游戲而言，使用AI寫程序，使用者有程序邏輯基礎(chǔ)依然很重要。

不過這一點(diǎn)迭代也很快，現(xiàn)在好的模型已經(jīng)不太需要使用者詳細(xì)描述需要實(shí)現(xiàn)的程序框架也能寫出很不錯(cuò)的代碼。要說的話，“能清楚地知道自己要做什么，并用結(jié)構(gòu)化的語(yǔ)言描述出來”才是最重要的。把模棱兩可的需求丟給AI做基本都會(huì)出亂子——不過話又說回來，在我的使用體驗(yàn)中，最好的模型已經(jīng)能夠在實(shí)現(xiàn)過程中發(fā)現(xiàn)模糊的需求，并主動(dòng)向你征求決策意見。只能說發(fā)展的速度實(shí)在太快。

在整理需求這一點(diǎn)AI也能幫上很大忙。我這邊的流程：先出一個(gè)需求初稿，之后讓AI補(bǔ)充整理成一個(gè)程序友好的策劃案細(xì)稿，檢查沒問題后再讓Agent調(diào)研可行性，出一個(gè)實(shí)現(xiàn)意見/方案，再檢查Agent提出的這個(gè)方案進(jìn)行補(bǔ)充與調(diào)整。這樣整理完一遍自己基本就對(duì)Agent要做什么、這個(gè)框架是什么樣的有認(rèn)知了。更重要的是，在這個(gè)過程中自己也能反芻一遍自己的想法，很多時(shí)候新的點(diǎn)子就會(huì)在這一過程中出現(xiàn)。

以及還有一個(gè)可能被忽視的優(yōu)勢(shì)：對(duì)于獨(dú)立游戲而言，Vibe Coding的流程可以省去大量原本需要的與程序職能的交流成本，可以即時(shí)地實(shí)現(xiàn)功能，進(jìn)行測(cè)試并立刻迭代。這一點(diǎn)對(duì)于玩法驗(yàn)證階段而言相當(dāng)有幫助。

AI美術(shù)

關(guān)于美術(shù)方面我用得比較少，因?yàn)槲抑饕谧鲆恍┲攸c(diǎn)不怎么放在美術(shù)資源鋪量的項(xiàng)目。

不過至少對(duì)于2D項(xiàng)目而言，有了AI的加持，已經(jīng)能夠節(jié)省非常多的工作了。例如說我這段時(shí)間在研究一個(gè)2.5D的、可能要用到大量Sprite幀動(dòng)畫的項(xiàng)目，現(xiàn)在的AI已經(jīng)可以做到只需要一張角色參考（設(shè)定、立繪或者隨便什么姿態(tài)的圖片），就能夠出一張像素風(fēng)格的這一角色的多向行走、跑步、動(dòng)作等的Spritesheet圖。依然需要一些處理，不過已經(jīng)達(dá)到了可用的水準(zhǔn)——雖然我最后出于后續(xù)開發(fā)的考量還是換用其他非Sprite幀動(dòng)畫的方案了。

在3D人物動(dòng)作方面，以Cascadeur為代表的AI動(dòng)作制作軟件也能夠起到非常驚艷的效果。動(dòng)畫師只需要手動(dòng)擺放動(dòng)作的幾個(gè)關(guān)鍵幀，其就能自動(dòng)補(bǔ)全邏輯通順、節(jié)奏合理的中間幀，大大節(jié)省了動(dòng)畫制作的精力。這一思路也是我認(rèn)為美術(shù)領(lǐng)域AI的重點(diǎn)：能夠通過接管中間步驟的方式讓制作者把寶貴的精力用在最重要的部分。

▍玩法策劃 飯

作為預(yù)研單機(jī)項(xiàng)目的玩法策劃，AI應(yīng)用很多都集中在玩法demo預(yù)研。

一般來說分成AI輔助出玩法demo和AI原生玩法。對(duì)于前者，可能每個(gè)人的工作流程不同介入程度會(huì)不一樣，目前我們是實(shí)現(xiàn)了一套前端vibe玩法直接接入引擎轉(zhuǎn)化成游戲邏輯的流程，所以對(duì)驗(yàn)證很多現(xiàn)有玩法是有明顯提效的；對(duì)于后者則更取決于玩法本身好不好玩，AI參與的部分有沒有“spark”，并且實(shí)現(xiàn)流程也是平衡成本和體驗(yàn)的過程，我覺得帶來的突破更多會(huì)是交互層面的，大家也都在做很多有趣的探索與嘗試。

我自己在家的時(shí)候則是秉承“能自動(dòng)化就自動(dòng)化”的原則做了不少有趣的小工具。比起單純地用AI完成工作，我更想讓AI把自己的工作環(huán)境、工作節(jié)奏調(diào)整得更順滑。

我做的一套就是不用對(duì)話，把我的記錄和習(xí)慣傳給AI，讓它自動(dòng)去安排Cursor——一是接IM方便，二是還是得主動(dòng)把相關(guān)上下文輸入給它。把我原本調(diào)用Codex、Cursor的輸入工作，交給一個(gè)用GPT 5.4的秘書去跑。

▍關(guān)卡策劃 小T

我這邊是關(guān)卡策劃，有幾個(gè)使用方向吧：

設(shè)計(jì)階段——用AI搜索或者生成給美術(shù)的參考圖、參考視頻；用AI完善玩法設(shè)計(jì)，查漏補(bǔ)缺，幫忙想一些邊界情況；讓AI輔助找一些其他游戲的類似參照點(diǎn)；做原型的時(shí)候可以讓AI看看目前的項(xiàng)目有沒有什么可以提供的現(xiàn)有功能。

執(zhí)行階段——AI幫忙解答一些工程和技術(shù)方面的問題；AI執(zhí)行一些批量化的工作，或者一些簡(jiǎn)單的配表工作（但是這個(gè)目前不太完善）；做原型的時(shí)候可以讓AI幫忙實(shí)現(xiàn)一些機(jī)制進(jìn)行驗(yàn)證。

目前我自己是在嘗試做一套AI輔助關(guān)卡設(shè)計(jì)文檔生成的工具，主要是用來節(jié)省做標(biāo)準(zhǔn)化文檔的時(shí)間，然后可以輔助做一些關(guān)卡平面圖、流程設(shè)計(jì)之類的。

目前AI在提效外的創(chuàng)意性工作里還不是特別強(qiáng)，不過感覺未來可期，可能過一兩年就能實(shí)現(xiàn)AI全流程生成一個(gè)高質(zhì)量3D關(guān)卡了——就是從一個(gè)idea到核心機(jī)制設(shè)計(jì)，動(dòng)線，探索體驗(yàn)，再到場(chǎng)景搭建和機(jī)關(guān)配置之類的全流程——雖然目前看起來是差挺多，但是理論上已經(jīng)可以做到全流程實(shí)現(xiàn)了。我自己測(cè)試過這個(gè)工具生成的LDD文檔，目前是期望可以做成一個(gè)通用的輔助工具，只要算是一個(gè)游戲玩法大類里面，講究關(guān)卡體驗(yàn)流程的游戲都可以用。如果是三消或者模擬經(jīng)營(yíng)之類的就不太適用了。

現(xiàn)在是技術(shù)大通脹時(shí)代，開發(fā)小工具的成本變得很低，感覺之后各個(gè)工種、各個(gè)類型的項(xiàng)目都會(huì)冒出來一些類似的工具。

▍創(chuàng)業(yè)者 吳天嬌Steven

我們應(yīng)該是全世界的游戲開發(fā)團(tuán)隊(duì)里最早全面擁抱OpenClaw的團(tuán)隊(duì)之一，現(xiàn)在已經(jīng)有兩個(gè)Bot擔(dān)任三個(gè)角色來深度結(jié)合我們的開發(fā)流程：一個(gè)負(fù)責(zé)社群運(yùn)營(yíng)和項(xiàng)目管理，另一個(gè)負(fù)責(zé)項(xiàng)目工程的全方位維護(hù)。這兩個(gè)Bot的基礎(chǔ)建設(shè)都是我自研的，所以功能會(huì)比OpenClaw更加強(qiáng)大。

社群運(yùn)營(yíng)Bot可以做到跨平臺(tái)共享上下文（context），例如它在Discord頻道里可以獲取玩家的所有反饋，并對(duì)玩家進(jìn)行回復(fù)；同時(shí)，回到飛書里，它基于在Discord獲得的信息撰寫Playtest數(shù)據(jù)匯總、玩家反饋分析，并直接基于整個(gè)項(xiàng)目的背景和進(jìn)展針對(duì)性布置后續(xù)任務(wù)，通過飛書的工作流（如郵箱、日程、任務(wù)等）將后續(xù)規(guī)劃安排給相應(yīng)成員和團(tuán)隊(duì)負(fù)責(zé)人。平時(shí)日常我們的組會(huì)、敏捷開發(fā)規(guī)劃，也都直接對(duì)接給Bot來進(jìn)行任務(wù)和進(jìn)度的梳理與追蹤。

工程維護(hù)Bot會(huì)直接參加我們的設(shè)計(jì)討論會(huì)，在策劃上午開會(huì)腦暴新feature的時(shí)候，Bot就會(huì)實(shí)時(shí)獲取上下文了。開完會(huì)后，無需策劃再花費(fèi)時(shí)間精力寫面向工程師的文檔，還要來回來去地爭(zhēng)論，而是Bot用吃個(gè)午飯的功夫直接把上午的腦暴會(huì)結(jié)論在項(xiàng)目工程里實(shí)現(xiàn)原型腳本，拉一個(gè)新的PR等著策劃吃完飯回來合并測(cè)試了。后續(xù)有任何需要迭代的地方直接通過飛書和Bot對(duì)話即可。

現(xiàn)在OpenClaw只能開發(fā)原型級(jí)別的效果，相比之下深度使用的還是Claude Code。我現(xiàn)在基本可以做到一行代碼不看，只看結(jié)果了?，F(xiàn)在普遍的共識(shí)是視覺效果還是要看一看，shader這些，工程層面已經(jīng)完全沒問題，但我們視覺上的效果還沒那么多需求。

▍文案策劃 Nuts

每天都在被驚到，不學(xué)會(huì)和AI相處，可能會(huì)變成山頂洞人。

運(yùn)用工具：Gemini、ChatGPT、DeepSeek。運(yùn)用方式：明確表達(dá)需求和目的，將AI訓(xùn)練為最得力的工作助手。運(yùn)用場(chǎng)景：收集素材、腦暴、完善方案、潤(rùn)色。

Gemini在工作中使用最為頻繁，基本能覆蓋全流程，用來拓寬思路、提高效率、優(yōu)化方案；DeepSeek在生活中使用最為頻繁，擔(dān)當(dāng)日常百科、制定學(xué)習(xí)計(jì)劃，學(xué)習(xí)新領(lǐng)域通識(shí)是非常好的工具；生圖和視頻AI工具用在工作中，用以準(zhǔn)確快速表達(dá)需求。

? “發(fā)送“社群”加入游戲茶館行業(yè)交流群”