前言

這整個系列的目的，是幫助你真正理解 Roblox 的系統架構，而不只是學會把需求丟給 AI。

現在，你只要給 Assistant 一段 prompt，它就可能在很短的時間內生成一個看起來可以玩的遊戲。但如果你從一開始就把所有開發工作都交給它，卻不知道它建立了哪些物件、把 Script 放在哪裡，也不理解 client、server 與 DataModel 之間的關係，那麼當你想加入新功能或修改既有設計時，很快就會遇到問題：不知道該從哪裡改、改了一個地方卻壞了另一個地方，最後整個專案越改越亂。

所以，這個系列不會只教你「用一段 prompt 生成一個遊戲」。我們會把 AI 生成的結果當成學習起點，一步一步觀察它建立了什麼、理解每個元件為什麼存在，並學會如何測試、修改與整理專案。

當你理解 Roblox 的整體架構之後，Assistant 才會真正成為提高開發效率的工具。即使第一版遊戲是由 AI 協助生成，你仍然知道它如何運作，也有能力繼續把它改成自己真正想做的遊戲。

本章目標

這一章先建立本書的工作方式。

你不會從 Part、Script、RemoteEvent、DataStoreService 這些名詞開始背起。你會先學一件更貼近現在 Roblox Studio 的事：如何把一個遊戲想法說給 Assistant 聽，讓它先在 Studio 裡產生可觀察的東西，然後再回頭拆解它產生了哪些元件、哪些程式、哪些設定，以及哪些地方需要你檢查。

本章完成後，你應該理解三件事：

• Roblox Studio 是建立、撰寫、測試、發布 Roblox experience 的主要工作環境。
• Assistant 不是單純聊天工具，它可以直接協助修改 Studio 裡的 DataModel。
• AI 生成不是結束，而是開發循環的開始。

本書後面的每一章，都會反覆使用同一個節奏：

Prompt -> Assistant 生成 -> 觀察 Explorer/DataModel -> 拆解元件 -> Playtest -> 修正 Prompt -> 工程整理

圖 1-1　Roblox Studio 首頁。進入既有體驗或建立新體驗後，才會開始本書的 Assistant 開發流程。

Context Pack

本章依據以下 Roblox 官方文件撰寫：

• Assistant for Studio
• Assistant prompt guide and examples
• AI on Roblox
• Roblox Studio

本章不深入 API。你現在需要的不是先背完所有 class，而是先知道 Assistant 能進入哪些工作範圍，以及你該怎麼看待它產生的結果。

開場情境

假設你想做一個 Roblox 小遊戲：

玩家出生在一座冒險島上，沿著路徑探索，收集發光水晶，和 NPC 對話，完成第一個任務，最後用獎勵升級能力。

傳統教學通常會這樣安排：

• 先介紹 Roblox Studio 介面。
• 再介紹 Part、Model、Workspace。
• 接著介紹 Script 和 Luau。
• 然後才慢慢進入 UI、RemoteEvent、DataStore。

這樣的順序有它的價值，但問題是讀者常常學了很多元件，卻還不知道這些元件怎麼組成一個遊戲系統。

本書採用另一種順序。

我們先把目標說出來，讓 Assistant 協助生成第一版，再從它產生的結果回頭學 Roblox 架構。換句話說，你不是先背零件，再想像機器；你是先讓機器的雛形出現，再拆開看每個零件為什麼存在。

Assistant 在 Studio 裡能做什麼

Roblox 官方文件把 Assistant 定位成 Studio 裡的 AI helper。它可以回答 Roblox 開發問題，也可以生成內容，更重要的是，它能直接在 Studio 裡執行動作。

圖 1-2　Assistant 不只回覆文字，也能呼叫 Studio 工具修改目前的 place；送出 prompt 前要先確認任務範圍。

在本書的範圍裡，你會反覆用到 Assistant 的幾種能力：

• 回答 Roblox Studio、Luau、UI、發布流程相關問題。
• 建立或修改 DataModel 裡的物件。
• 新增、修改、解釋 Script。
• 插入 Creator Store asset。
• 生成材質，讓物件快速具有視覺風格。
• 生成 textured 3D mesh。
• 生成 procedural model，讓模型可以用屬性調整。
• 協助你根據畫面、錯誤訊息或程式碼進行下一輪修改。

這些能力會改變學習順序。

以前你可能要先知道 SpawnLocation 是什麼，才能放玩家出生點。現在你可以先請 Assistant 建立一個出生區域，再打開 Explorer 觀察它產生了什麼。以前你可能要先學 Touched 事件，才能做收集物。現在你可以先請 Assistant 做「玩家碰到水晶後加 1 分」，再回頭看它用了什麼事件、把 Script 放在哪裡、資料存在 client 還是 server。

這不是省略基礎。這是把基礎放在更有脈絡的位置學。

第一個 Prompt

這一章先不要求你真的建立完整遊戲。我們先看一個代表本書風格的 prompt：

【Ch01 主任務｜建立 Assistant 工作流】
我想建立一個 Roblox 冒險島原型。

請先幫我規劃第一個可玩的版本，不要急著做完整遊戲。
這個版本需要：
1. 一個玩家出生點
2. 一條可以走的探索路徑
3. 三個發光水晶，玩家之後可以收集
4. 一個 NPC 位置，之後會給任務
5. 一個終點平台，代表第一段探索完成

請先列出你打算在 Workspace 裡建立哪些物件、每個物件的用途、以及哪些功能需要 Script。

這個 prompt 有幾個刻意設計：

• 它先說明遊戲類型：冒險島原型。
• 它限制範圍：第一個可玩的版本，不是完整遊戲。
• 它列出具體元素：出生點、路徑、水晶、NPC 位置、終點平台。
• 它要求 Assistant 先說明計畫，而不是立刻亂做。
• 它要求區分物件和 Script，方便後面拆解。

這就是本書的基本態度：不要把 Assistant 當成魔法按鈕，而是把它當成可以執行任務的開發同伴。你給它清楚的任務，它產生第一版；你檢查第一版，再要求它修正。

Assistant 可能產生的結果

如果你把類似 prompt 輸入 Assistant，它可能會提出這樣的計畫：

• 在 Workspace 建立 SpawnLocation。
• 建立數個 Part 作為路徑平台。
• 建立三個命名為 Crystal_01、Crystal_02、Crystal_03 的水晶物件。
• 建立一個 NPCPlaceholder，暫時用簡單模型或 Part 表示 NPC。
• 建立一個 GoalPlatform。
• 稍後需要 Script 來處理水晶收集、任務狀態、終點判定。

如果你要求它直接建立物件，它也可能在 Studio 裡新增這些 Instance。這時候真正的學習不是看它回覆了什麼漂亮文字，而是打開 Explorer，觀察 DataModel 變成什麼樣子。

你要問自己：

• 新增的物件在哪裡？
• 名稱是否清楚？
• 物件是 Part、Model、SpawnLocation，還是其他類型？
• 有沒有 Script 被建立？
• Script 放在物件底下，還是放在 ServerScriptService？
• 這些物件是在編輯時就存在，還是遊戲執行時才會產生？

這些問題會帶你自然進入 Roblox Studio 的核心。

元件拆解

先理解 DataModel

Roblox experience 不是一堆孤立檔案。它是一棵 DataModel。

你在 Studio 裡看到的 Workspace、ReplicatedStorage、ServerScriptService、StarterGui，都是 DataModel 裡的節點。遊戲引擎會根據這棵樹來渲染世界、模擬物理、執行程式、同步 client/server 狀態。

Assistant 的特別之處在於：它不是只告訴你「你應該建立一個 Part」。它可以直接幫你在這棵 DataModel 裡建立或修改 Instance。

所以你接下來要養成一個習慣：

每次 Assistant 做完事，不要只看聊天視窗。

你要看三個地方：

1. Explorer
   檢查哪些 Instance 被新增、刪除或移動。

2. Properties
   檢查尺寸、位置、材質、碰撞、是否 Anchored、是否可見。

3. Script Editor / Output
   檢查新增的程式碼、錯誤訊息、警告與執行結果。

這三個地方會成為本書最常出現的觀察點。

Edit Time 和 Run Time

使用 Assistant 時，第一個容易混淆的概念是 edit time 和 run time。

如果你說：

把時間設成早上 8 點。

Assistant 可能會直接修改 Studio 場景目前的 Lighting 設定。這是 edit time 的改動。

但如果你的真正需求是「遊戲開始後，每次玩家進入都自動變成早上 8 點」，你應該說：

請新增一段在遊戲執行時生效的 Script，讓伺服器啟動後把 Lighting 的時間設為早上 8 點。

這就是 run time 的行為。

這個差異很重要。Roblox 遊戲裡很多錯誤，不是因為程式語法錯，而是因為你以為自己在設定遊戲執行時的行為，實際上只改到了編輯器中的靜態狀態。

本書後面每次下 prompt，都會刻意說清楚：

• 這是要在 Studio 裡直接建立的物件嗎？
• 這是要玩家進入遊戲後才發生的行為嗎？
• 這需要 Script 嗎？
• 這段 Script 應該在 server 還是 client 執行？

現在你不必完全理解 server/client，但你要先知道：這些問題會決定 Assistant 生成的東西是否放對位置。

Playtest

不要相信看起來完成

Assistant 生成一個場景，看起來完成，不代表它真的能玩。

你至少要檢查：

• 玩家是否真的出生在正確位置。
• 路徑是否能走，平台是否會掉落。
• 物件是否有碰撞。
• 水晶是否只是裝飾，還是真的能收集。
• Script 是否有錯誤。
• Output 是否有警告。

這就是 Playtest 的價值。

本書不會把 Playtest 放到最後幾章才談。從第一個原型開始，我們就把 Playtest 當成每輪 prompt 的一部分。你要習慣把測試結果變成下一輪 prompt 的材料。

例如：

剛才生成的冒險島原型可以看到水晶，但玩家碰到水晶時沒有任何反應。
請不要重做整個場景，只針對三個 Crystal 物件新增收集行為：
1. 玩家碰到水晶後，水晶消失
2. 在 Output 印出玩家名稱和收集訊息
3. 先不要做 UI 和存檔
4. 請說明你新增的 Script 放在哪裡

這樣的修正 prompt 比「水晶不能收集，幫我修」更好，因為它提供了觀察結果、限制範圍和驗收條件。

修正 Prompt

第一章的修正 prompt 重點不是修某個完整功能，而是建立往後每章都會使用的回饋方式。

當 Assistant 產生的結果看起來不符合預期時，不要只說：

不對，重做。

比較好的說法是：

【Ch01 修正 1｜結果有三個問題】
剛才的結果有三個問題：
1. 玩家出生點離主要路徑太遠。
2. 水晶目前只是裝飾，沒有互動。
3. Explorer 裡有太多未命名的 Part。

請不要重做整個場景。
請只修正出生點位置、水晶互動，以及把主要物件整理到有意義的 Folder。
完成後請列出你修改了哪些物件。

這種修正 prompt 會成為全書的基本節奏：觀察結果、限制範圍、提出驗收條件，再要求 Assistant 說明修改內容。

工程整理

AI 生成後要做的事

AI 生成的第一版通常有兩種問題。

第一種是功能問題：不能跑、跑錯、漏掉需求。

第二種是工程問題：可以跑，但不好維護。

例如 Assistant 可能會建立這些名稱：

• Part
• Part2
• Script
• Script1
• Crystal
• Crystal
• Crystal

遊戲小的時候你還能猜，遊戲變大後就會失控。你需要把 AI 生成的結果整理成能被人理解的結構。

在本書中，每章都會至少做一次工程整理：

• 重新命名物件。
• 把同類物件放進 Folder 或 Model。
• 把 Script 放到合理的位置。
• 刪除重複或無用的物件。
• 加上基本註解或輸出訊息。
• 把 prompt、測試結果、修改原因記錄下來。

這些動作看起來沒有「生成一個新功能」那麼刺激，但它們決定你的專案能不能繼續長大。

本書如何使用 Assistant

你可以把本書想成一本 AI 時代的 Roblox Studio 開發工作手冊。

每章都會從一個可玩的需求開始，而不是從抽象名詞開始。Assistant 會幫我們產生第一版，但本書真正要教你的，是如何判斷第一版。

你會反覆練習：

• 怎麼把需求寫成清楚的 prompt。
• 怎麼要求 Assistant 先計畫再執行。
• 怎麼從 Explorer 看出它產生了什麼。
• 怎麼讀它生成的 Script。
• 怎麼把錯誤訊息餵回 Assistant。
• 怎麼把能跑的東西整理成可維護的系統。
• 怎麼知道什麼事情不能只靠 AI 猜。

這也是為什麼本書後面會逐步談到 UI、RemoteEvent、DataStore、安全、效能、發布和外部 AI 素材工具。這些不是額外知識，而是當你讓 AI 幫你快速生成功能後，必然會遇到的工程問題。

本章總結

這一章建立了本書的核心開發循環：

Prompt -> Assistant 生成 -> 觀察 Explorer/DataModel -> 拆解元件 -> Playtest -> 修正 Prompt -> 工程整理

Roblox Studio 是完整的開發環境，Assistant 則讓你能用自然語言啟動許多原本需要手動建立或撰寫的工作。但 Assistant 不是替你負責的開發者。它可以幫你產生物件、Script、材質、mesh 和計畫，但你仍然要檢查 DataModel、測試遊戲行為、理解生成的程式碼，並把結果整理成可維護的專案。

下一章，我們會正式準備 Studio 的 AI 開發環境：開啟 Assistant、檢查 Beta Features、理解 Data Sharing，並建立開始寫 prompt 前的安全檢查表。

關於 Wolke

嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。

我熱衷於研究 AI Agent、n8n 自動化工作流與全端開發架構，致力於將 AI 技術轉化為真正能落地的生產力工具。

如果你喜歡這篇文章，歡迎透過以下方式與我交流：

📚 技術著作
《實用的 Gemini API 開發點子書》：帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。

📝 技術部落格
歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。

🎤 技術講座與合作
我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。

我曾於 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。

如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊聯繫，洽談講座與工作坊合作！

🎁 免費贈送 OpenAI 或 Claude AI 額度

為了鼓勵大家實際動手打造自己的 Roblox 體驗，我每個月會開放：

• 10 個名額
• 每人 50 點 AI 額度
• 名額送完為止

參加方式：

1. 訂閱本系列文章。
2. 分享任一篇系列文章。
3. 私訊分享截圖及你的 AI 帳號 Email。

確認完成後，我會邀請你加入並設定 50 點額度。名額有限，歡迎把握機會！