作者 ｜ 董道力
郵箱 ｜ dongdaoli@pingwest.com

同樣的模型，為什么你和大佬做出來的項目天差地別？原因很簡單，他是大佬，你不是。

那么有沒有什么辦法快速彌補你和大佬之間的鴻溝呢？

這也許就是 2026 年，Agent 要做的事情。

AI 能力競賽走到今天，基礎(chǔ)模型能力趨于同質(zhì)，新出的工具也會被快速模仿。在這個前提下，決定 AI 生產(chǎn)出的項目好壞的，究竟是什么？

數(shù)據(jù)。

不是從公開互聯(lián)網(wǎng)上爬來的、泛化的那種，而是在某個垂直領(lǐng)域里沉淀多年、有密度、有結(jié)構(gòu)、經(jīng)過真實用戶驗證的專業(yè)數(shù)據(jù)。

對游戲開發(fā) agent 而言，這意味著：誰擁有的游戲數(shù)據(jù)越多，誰的 agent 就越接近真正懂游戲的開發(fā)者，而不只是一個"會寫代碼的工具"。

而 TapTap 制造（后續(xù)稱 TTM）就是一個游戲領(lǐng)域的 agent，幫助你快速接近游戲大佬。

1

實測 TapTap 制造，游戲公司推出的游戲制作 Agent 是什么樣？

進(jìn)入首頁，是經(jīng)典的 NoCode 界面：最大塊的是一個對話框，輸入想法，可以附上示意圖，左側(cè)是項目目錄。

界面形式上，目前 AI 產(chǎn)品大同小異。關(guān)鍵在于制作過程，我們具體來看。

prompts：做一個橫版平臺跳躍，3 個關(guān)卡，有雙跳和沖刺，參考惡魔

收到指令后，由 TapTap 看板娘嗒啦啦化身的游戲開發(fā) Agent 開始拆解需求。TTM 的思考方式是一個經(jīng)典的任務(wù)分解流程：探索代碼庫，了解項目結(jié)構(gòu)、可用模板、示例和文檔。

和其他 AI Coding 工具不同的是，通用工具完成 plan 之后，面對復(fù)雜任務(wù)會搭框架，面對簡單任務(wù)庫庫寫代碼。

而 TTM 會先執(zhí)行一個文檔研究步驟，它默認(rèn)選擇 UrhoX 引擎和 Lua 語言，然后從相關(guān)文檔里提取所需知識，比如如何用 Box2D 物理引擎搭建 2D 游戲、如何創(chuàng)建平臺和碰撞檢測等。

在這次項目中，TTM 從文檔里學(xué)到了如何繞開 Lua 語言的常見坑、如何建立合理的文件結(jié)構(gòu)、UrhoX 的 API 該怎么用。

這個環(huán)節(jié)通常由用戶按需配置。比如想用 Cursor 開發(fā)微信小程序，可以在 doc 中加入小程序開發(fā)文檔。想讓 AI 搭一個周易網(wǎng)站，就把相關(guān)學(xué)術(shù)資料喂給它。

在通用 AI Coding 工具里，這些專業(yè)知識基本沒有，就算有，也只是通過 web_fetch 臨時搜一點公開信息。小眾引擎的細(xì)節(jié)、公司內(nèi)部文檔，AI 不靠用戶輸入根本觸達(dá)不到。

而這些專業(yè)知識，恰恰是在底層模型能力趨同的今天，決定 AI 好不好用的關(guān)鍵一步，也是垂類 Agent 之所以能"垂"的核心原因。

這就是你和大佬的差距所在。

不過有點可惜，TTM 在后續(xù)更新中把這部分思考過程隱藏了，也可能是我網(wǎng)絡(luò)加載的問題？

文檔研究只是 TTM 學(xué)習(xí)的冰山一角。整個對話流程中，TTM 幾乎一直在學(xué)習(xí)。知識庫里還有一些經(jīng)典游戲的案例切片，比如橫版平臺游戲的教科書，馬里奧。

完成學(xué)習(xí)準(zhǔn)備后，TTM 正式進(jìn)入開發(fā)階段。這部分說白了就是 Agent 自主編程：拆任務(wù)、寫代碼、跑檢查、發(fā)現(xiàn) bug、自己修，整個流程一氣呵成。

值得一提的是，TTM 在處理問題時相當(dāng)"軸"。用 AI 編程常會遇到大模型裝死敷衍了事，而 TTM 會持續(xù)嘗試像 Tokens 不要錢一樣，進(jìn)入一種擬人化的偵探模式。

舉個例子，當(dāng) agent 環(huán)境初始化遇到了 BUG。TTM 先后寫了 4 版 Python 檢查腳本，每一版都比上一版更精確：第一版正則匹配太粗糙，第二版沒處理 elseif，第三版漏掉了字符串嵌套……發(fā)現(xiàn)問題，推翻，重來，直到解決。

更絕的是找構(gòu)建工具那一段。系統(tǒng)里有個叫"UrhoX MCP build tool"的東西，但就是找不到入口。TTM 開始一頓找，查配置文件、扒隱藏目錄、讀環(huán)境變量、看進(jìn)程列表、翻系統(tǒng)日志，甚至直接猜命令硬試。它還從，gitignore 里推斷出了一個隱藏目錄的存在，這個細(xì)節(jié)，很多人類程序員都不會注意到。

當(dāng)然，遇到真正繞不過去的問題，TTM 也會報錯不會假裝已完成。第一輪對話中，它發(fā)現(xiàn)某個工具不存在，任務(wù)以系統(tǒng)錯誤終止。它卡在了一個外部依賴缺失的問題上，至于這個缺失是怎么來的，也得問它自己。

我作為不懂開發(fā)的小白，遇到這種情況只能讓 Agent 繼續(xù)嘗試。還算幸運，TTM 最終完成了任務(wù)，推測是 MCP 工具或服務(wù)器臨時失效的問題。

項目完成后，TTM 會主動復(fù)盤，總結(jié)代碼里存在的問題。這次它發(fā)現(xiàn)某個文件代碼量太大，建議拆成獨立模塊便于維護(hù)。這種機(jī)制也在一定程度上緩解了大模型長上下文"腐敗"的問題。

游戲免不了反復(fù)修改。每次提出改動，TTM 還是會先翻代碼、再查文檔，而且相當(dāng)有針對性，讓它給主角加遠(yuǎn)程攻擊，它先看玩家機(jī)制和攻擊系統(tǒng)。讓它設(shè)計一些陰間關(guān)卡，它去讀地圖文檔。

TTM 內(nèi)置的文檔庫和自主性，幫小白拉近了和游戲開發(fā)大佬的距離。

與此同時，TTM 也支持上傳自定義的游戲文檔和素材，讓大佬也有發(fā)揮空間。比如，右圖中的披風(fēng)小人是 TTM 根據(jù) prompts 自動生成，左圖中的看板娘是用戶上傳素材。

游戲制作之外，TTM 更深的護(hù)城河在于平臺本身。TapTap 是一個成熟的游戲分發(fā)平臺，在 TTM 上做好的游戲可以直接發(fā)布上去，無縫銜接。

點擊發(fā)布后，填寫游戲信息、上傳截圖等材料即可。這些繁瑣的物料準(zhǔn)備，AI 也可以幫你搞定，右圖那張精美照片，就是 AI 生成的。

當(dāng)所有人都在用同一批基礎(chǔ)模型，"模型比拼"這個維度正在迅速失去意義。GPT、Claude、Gemini 的能力差距肉眼可見地在收窄，下一個版本可能又會拉平。

真正開始拉開差距的，是模型之上那一層，誰沉淀了更深的領(lǐng)域數(shù)據(jù)，誰提煉出了更準(zhǔn)確的專業(yè)經(jīng)驗，誰把這些東西以 Agent 能真正用好的方式組織起來。

這不是一夜之間能復(fù)制的東西。TapTap 多年積累的游戲數(shù)據(jù)和開發(fā)者生態(tài)，Salesforce 對企業(yè)銷售流程的深度理解，醫(yī)療、法律、教育領(lǐng)域里那些還沒被充分挖掘的專業(yè)知識，未來真正有價值的 AI 產(chǎn)品，大概率都藏在這些地方。

通用工具解決的是"能不能做"的問題，垂類 Agent 解決的是"做得好不好"的問題。而在大多數(shù)真實場景里，后者才是用戶真正愿意付錢的那個。

帶著這些觀察和疑問，我們與 TapTap 制造負(fù)責(zé)人姜黎聊了聊，看看他們是怎么想的，又是怎么做的。

1

對話 TapTap 制造負(fù)責(zé)人姜黎

GUI 是人類的習(xí)慣，不是 AI 的

硅星人：TapTap 制造沒有延續(xù)上一款星火編輯器 GUI 形式，轉(zhuǎn)向了純代碼 AI 引擎架構(gòu)，這個決定背后的判斷是什么？是認(rèn)為 GUI 從根本上不適合 AI 時代的游戲開發(fā)，還是現(xiàn)階段的務(wù)實選擇？

姜黎：這里其實是兩個層面。第一，過去說的 GUI 是人類設(shè)計給人用的，即使多模態(tài) AI 未來理解能力越來越強(qiáng)，它操作 GUI 的價值也只是兼容人類積累下來的大量工具，但這不代表 GUI 就是 AI 的最佳交互方式。對大模型來說，提供準(zhǔn)確的輸入輸出接口讓它直接調(diào)用，肯定比讓它識別圖形界面再去操作要準(zhǔn)確得多。

第二，GUI 是否還存在，取決于要不要給人類提供人機(jī)交互的界面。現(xiàn)在 TapTap 制造里還是有大量 GUI 的，比如資產(chǎn)庫。所以 GUI 的意義在于，只要服務(wù)人，它就會存在。但面向 AI agent，我們優(yōu)先提供的一定不是 GUI。以前星火是一個純面向人的工具，而現(xiàn)在 TapTap 制造的使用者，從以前單一的"人"，變成了"agent + 人"雙端。

硅星人：你們在發(fā)布會上提到一個很有意思的表述，"注入專業(yè)技能而非知識"。能展開講講，技能和知識的區(qū)別在哪里？技術(shù)上具體是怎么落地的？

姜黎：首先是對各種游戲類型開發(fā)流程的深度理解和抽象。這是游戲開發(fā)領(lǐng)域的專有知識，比如做 MOBA 怎么做、卡牌怎么做、MMO 應(yīng)該怎么做，只有真正做過某個游戲類型的人才能理解這些流程。

對我們做這款產(chǎn)品而言，要做的就是把這些領(lǐng)域知識，通過 API 設(shè)計、組件設(shè)計、知識庫、面向 agent 的工具和 skill，綜合起來讓 TapTap 制造適應(yīng)各種類型的游戲。今天可能還不能涵蓋所有類型，但隨著持續(xù)深入，能覆蓋的類型會越來越多。我們說的"專業(yè)技能"，主要就是通過這套綜合手段來實現(xiàn)的。

上下文濫用、隱藏代碼、30 萬行，AI游戲邊界在哪里

硅星人：目前這套"專業(yè)技能"的技能庫和文檔庫規(guī)模有多大？引入新技能的篩選標(biāo)準(zhǔn)是什么？

姜黎：具體數(shù)量不方便透露，但從上次直播到現(xiàn)在已經(jīng)快翻倍了，速度還會越來越快。不過未來不會無限增長，只有在確定引入不會讓 agent 性能變差的情況下，我們才會謹(jǐn)慎引入，會越來越注重數(shù)據(jù)質(zhì)量。

篩選上，完整游戲示例更多從品類入手，但我們更傾向于以組件方式提供。比如馬里奧由哪些組件構(gòu)成，先確保引擎基建足夠完善，再提供最經(jīng)典的示例，不會無限堆各種類型的 demo。

硅星人：AI 輔助開發(fā)中有一個很常見的痛點：多輪對話后容易出現(xiàn)"改 A 壞 B"的漂移問題，上下文越長越容易失控。TapTap 制造是怎么應(yīng)對的？

姜黎：比較常見的原因還是上下文濫用，不節(jié)制地在同一對話里持續(xù)追加需求，舊內(nèi)容被窗口擠出，失憶不可避免。這不是 TapTap 制造專有的問題，今天最頂級的 coding agent 也一樣。

我們能做的，一是引導(dǎo)用戶將獨立需求拆成多會話處理，二是通過良好的組件設(shè)計幫用戶解耦，從架構(gòu)層面降低問題概率，三是隨著記憶系統(tǒng)升級、模型能力提升和上下文窗口擴(kuò)展，這個問題也會逐步緩解。

硅星人：目前 TapTap 制造對用戶隱藏了完整代碼，這個決策爭議不小。有沒有考慮過對有編程能力的進(jìn)階用戶分層開放？

姜黎：肯定能找到一些 case，比如 AI 犯了個很傻的錯誤，剛好用戶懂代碼，一行就能改掉。但這類 case 不足以支撐給所有用戶開放代碼，因為更多情況下，用戶因為不需要關(guān)心代碼，省掉了大量 review 和手動修改的時間。

隨著大模型能力提升，即使是專業(yè)程序員也在逐漸減少逐行看代碼的頻率，更何況 UGC 開發(fā)者，絕大多數(shù)人的編程能力實際上不如 AI。

我們的判斷是：看不了代碼，一定不是做好游戲的瓶頸，反而可以把更多精力放在創(chuàng)作者真正應(yīng)該關(guān)心的事上，玩法、美術(shù)、體驗。未來不排除提供優(yōu)雅的代碼查看工具，但目前優(yōu)先級不高。

硅星人：隨著項目推進(jìn)，代碼量必然越來越大。目前 TapTap 制造能支撐的項目規(guī)模天花板在哪里？

姜黎：現(xiàn)在已有超過 30 萬行代碼的項目，對游戲來說已經(jīng)是中型規(guī)模了。但代碼庫規(guī)模和所需上下文長度并非線性關(guān)系，agent 本身具備代碼搜索能力，可以支撐大型項目，就像程序員不需要把所有代碼裝進(jìn)腦子一樣，代碼行數(shù)本身不是瓶頸。

關(guān)鍵在于設(shè)計模式，遵循 AI 的架構(gòu)建議、按需重構(gòu)、多會話拆分任務(wù)，幾十萬行代碼完全沒問題。但如果不遵循建議、自由發(fā)揮到很混亂的狀態(tài)，遲早 AI 會維護(hù)不了，這是設(shè)計問題，不是代碼行數(shù)問題。

叫它噠啦啦，不叫"助手"

硅星人：TapTap 制造給 AI agent 做了擬人化設(shè)計，有一個叫"噠啦啦"的角色形象。為什么覺得游戲創(chuàng)作工具需要擬人化？

姜黎：游戲創(chuàng)作本來就應(yīng)該是件快樂的事，我們想讓體驗更輕松、更有代入感。噠啦啦本來就是 TapTap 的看板娘，有一貫的人設(shè)。我們發(fā)現(xiàn)開發(fā)者會直接叫它名字，會說"今天讓噠啦啦做了什么"，這種感覺很符合我們想象中用戶和 AI 一起成長的狀態(tài)，比面對冷冰冰的工具界面更有創(chuàng)作愉悅感。

硅星人：對游戲來說，好不好玩才是核心。TapTap 制造目前有沒有對游戲可玩性做自動評估的能力？

姜黎：目前沒有專門的可玩性評估模塊。TapTap 制造是一個響應(yīng)創(chuàng)作者指令的工具，不是自動造游戲的系統(tǒng)，它遵從你的創(chuàng)意和指令來執(zhí)行。

不過很多開發(fā)者已經(jīng)在用一種"共創(chuàng)討論"的方式來輔助決策，先跟 AI 討論設(shè)計思路，AI 給出選項 A 和 B，由你來選擇執(zhí)行。這種人機(jī)共創(chuàng)的工作方式，其實是非常重要的使用范式。

同質(zhì)化游戲早就存在，AI 不會加劇這件事

硅星人： 降低了創(chuàng)作門檻之后，會不會擔(dān)心 TapTap 制造批量產(chǎn)出一批玩法雷同、長得很像的游戲？

姜黎：不擔(dān)心。有沒有 TapTap 制造，同質(zhì)化的游戲都會大量出現(xiàn)，TapTap 本來就是一個什么游戲都能發(fā)的平臺。算法推薦在這個時代是能解決這件事的，低質(zhì)同質(zhì)化的游戲用戶不買單，自然就分發(fā)不出去。

硅星人：那平臺會給 AI 生成的游戲單獨設(shè)立一套分發(fā)標(biāo)準(zhǔn)嗎？還是和人工開發(fā)的游戲一視同仁？

姜黎：取決于 AI 游戲在目前的算法推薦體系下能不能正常工作。就目前來看，還是跟其他游戲一樣的分發(fā)標(biāo)準(zhǔn)，不做區(qū)分。

通用工具做不了復(fù)雜游戲，Unity 轉(zhuǎn)型包袱太重

硅星人：Unity 最近也在布局 AI+游戲，Cursor、Claude Code 這類通用 AI 編程工具進(jìn)化也很快。TapTap 制造的護(hù)城河在哪里？

姜黎：Cursor 和 Claude Code 這類通用編程 agent 不依賴專業(yè)引擎，做不了復(fù)雜游戲，不會和 TapTap 制造形成直接競爭。游戲研發(fā)是非常垂直的領(lǐng)域，需要專業(yè)引擎和工具鏈。TapTap 制造不只是一個編程 agent，還有自研引擎、領(lǐng)域知識庫，以及平臺分發(fā)和云端運維的一體化閉環(huán)，用戶一鍵發(fā)布到 TapTap，后端部署和運維全部托管。這是通用工具無法提供的。

對于 Unity，它有大量歷史包袱和 SaaS 收入結(jié)構(gòu)，愿不愿意徹底轉(zhuǎn)型是個問號。我們沒有歷史包袱，引擎可以完全面向 AI agent 重新設(shè)計，團(tuán)隊極度精簡且投入，產(chǎn)品已經(jīng)走在前面。

免費是主動選擇

硅星人：TapTap 制造現(xiàn)階段完全免費，這在 AI 產(chǎn)品中不太常見。為什么選擇免費？商業(yè)化怎么考慮的？

姜黎：免費是主動決定的。我們長期看好算力成本的下降趨勢，TOKEN 成本大概每年有 10 倍左右的降幅。TapTap 制造能為平臺帶來獨家的高質(zhì)量游戲內(nèi)容，這個價值極大，目前這個投入是值得的。

積分體系已經(jīng)在運轉(zhuǎn)，主要是為了防止濫用，比如有用戶拿它批量生成圖片。有了積分體系之后，很多用戶主動反饋想直接買積分充值，說明付費意愿是真實存在的。但商業(yè)化并不是我們目前最高優(yōu)的事情，具體商業(yè)模式還在摸索中。

硅星人：做 TapTap 制造的過程中，團(tuán)隊自己也在大量使用 AI 嗎？你覺得 AI 持續(xù)變強(qiáng)，對整個游戲開發(fā)行業(yè)會產(chǎn)生什么樣的沖擊？

姜黎：是的，我們自己就是一個大量使用 AI 工具的團(tuán)隊。不大量用 AI 的團(tuán)隊在未來一兩年會非常難過，當(dāng)大家都在用 AI 降本提效，開發(fā)速度越來越快、成本越來越低的時候，你的效率優(yōu)勢和定價優(yōu)勢都會消失。

三五年周期的重資產(chǎn)大型項目也需要謹(jǐn)慎，AI 帶來的工作流變革可能讓原有競爭優(yōu)勢快速失效。

當(dāng)然也會有新機(jī)會，AI 原生游戲會催生全新的游戲類型，這個速度應(yīng)該會比很多人想象的快。

點個“愛心”，再走 吧