用 Assistant 做 Roblox Studio 專案，很容易產生一種錯覺：只要功能能跑，遊戲就完成了。
但遊戲不是只在你的開發電腦上跑。它還要在手機、平板、低階筆電、不同網路狀況、多人 server 裡跑。AI 生成的場景和程式如果一路堆上去，最後常見問題不是「寫不出功能」，而是：
本章的主軸不是「看到什麼都最佳化」。過早最佳化會讓初學者迷失，也會讓 AI 生成的程式變複雜。這一章要建立的是一套更重要的習慣：
先測量，再最佳化。
完成本章後，你會得到：
這章會繼續使用 AI Adventure Island。目前遊戲已經有島嶼、裝飾、水晶、NPC、敵人、能力、商店、HUD、存檔與安全檢查。內容開始變多，所以現在正是建立效能檢查習慣的時候。
圖 21-1 效能問題要用實際指標定位；大型場景應同時觀察 client、server、裝置與版本差異。
請先把以下 context 給 Assistant：
【Ch21 Context｜稽核大型場景效能】
我們正在 Roblox Studio 中製作「AI Adventure Island」。
目前系統：
- Terrain 與島嶼裝飾。
- 可收集水晶。
- Guide NPC 與任務提示流程。
- 敵人巡邏 AI。
- WindDash 能力。
- 商店與升級。
- SaveService。
- HUD controllers。
目前架構：
- Server gameplay scripts 位於 ServerScriptService.Services。
- 共用 config modules 位於 ReplicatedStorage.Config。
- RemoteEvents 位於 ReplicatedStorage.Remotes。
- HUD LocalScripts 位於 StarterGui.AdventureHUD.Controllers。
效能目標：
- 不要盲目最佳化。
- 先找出可能的效能風險與可測量的訊號。
- 不要移除玩法功能。
- 不要將權威玩法結果移到 client。
- 優先使用集中式 services 與 CollectionService tags，不要建立大量重複 scripts。
- 除非確實必要，否則避免使用每 frame 執行的 RunService loops。
目前先不要修改任何內容。
請為這個專案建立一份效能稽核計畫。
現在的專案如果打開 Explorer，可能已經有很多東西：
Workspace
├── Terrain
├── Island
│ ├── Rocks
│ ├── Trees
│ ├── Ruins
│ └── Decorations
├── Collectibles
│ ├── Crystal_001
│ ├── Crystal_002
│ └── ...
├── NPCs
│ └── Guide
└── Enemies
├── IslandSentinel_01
└── IslandSentinel_02
ServerScriptService
└── Services
├── CrystalCollectionService
├── QuestService
├── EnemyAIService
├── AbilityService
├── ShopService
└── SaveService
這個架構比前面乾淨，但不代表效能一定好。
AI 生成內容常見的效能問題是「局部看起來合理，整體堆起來很重」。
例如你要求 Assistant 生成一顆水晶，它可能在水晶底下放一支 Script。你要求它再生成 30 顆水晶，它可能複製出 30 支幾乎一樣的 Script。每一支都不大，但加起來會變成維護與效能負擔。
再例如敵人 AI。Assistant 可能為每個敵人寫：
while true do
-- find player
-- move
-- check distance
task.wait(0.1)
end
一個敵人可以，二十個敵人就要檢查。這不是說絕對不能用 loop，而是你要知道它在做什麼、多久做一次、是否有更集中的管理方式。
先請 Assistant 做效能稽核，不要直接改。
【Ch21 主任務｜稽核大型場景效能】
稽核這個 Roblox Studio 專案的效能風險。
目前先不要修改 scripts 或 instances。
建立一份包含以下欄位的效能稽核表：
1. 區域
2. 可能由 AI 生成的效能風險
3. 如何在 Studio 中測量
4. 使用哪一項工具
5. 要觀察的症狀
6. 安全的最佳化方向
7. 最佳化後的回歸測試
至少涵蓋：
- collectibles 或 decorations 下的重複 scripts
- RunService.Heartbeat / RenderStepped / while true loops
- 敵人 AI 更新頻率
- HUD 更新頻率
- RemoteEvent traffic
- particles、lights、shadows
- MeshPart RenderFidelity and CollisionFidelity
- tables 或 event connections 造成的 memory growth
- StreamingEnabled 與大型 Workspace models
規則：
- 先測量，再最佳化。
- 不要移除玩法功能。
- 除非另有要求，否則不要更改玩法數值。
- 不要將玩法權威從 server 移到 client。
- 如果玩法結果仍由 server 決定，純視覺效果可以放在 client-side。
這個 Prompt 會把問題從「幫我變快」改成「列出可測量的風險」。這很重要，因為效能不是抽象感覺，而是觀察資料。
Assistant 可能產生類似這樣的表格。
Area: Collectibles
Risk:
- Each crystal may have its own duplicated Script.
Measure:
- Count Scripts under Workspace.Collectibles.
- Check Script Profiler server results.
Tool:
- Explorer search
- Script Profiler
Symptom:
- Many identical scripts.
- Script profiler shows repeated crystal handlers.
Safe direction:
- Use CollectionService tag "CollectibleCrystal".
- One CrystalCollectionService connects to tagged parts.
Regression:
- All crystals still collect.
- Gold / crystal count still updates.
- No duplicate reward from one crystal.
敵人 AI 可能是：
Area: Enemy AI
Risk:
- Each enemy runs its own frequent loop.
- Path or distance checks run too often.
Measure:
- Script Profiler server recording.
- MicroProfiler server frame spikes.
Tool:
- Script Profiler Server
- MicroProfiler Server
Symptom:
- EnemyAIService or enemy scripts consume high CPU.
- Server heartbeat dips.
Safe direction:
- Central EnemyAIService update loop.
- Lower update frequency for far enemies.
- Only activate enemies near players.
Regression:
- Enemies still patrol.
- Enemies still react when player enters danger zone.
- No Output errors.
場景可能是：
Area: Environment art
Risk:
- Too many unique MeshParts, lights, particles, or high-fidelity collisions.
Measure:
- Memory tool PlaceMemory categories.
- Render stats / MicroProfiler client.
- Explorer filters for MeshPart CollisionFidelity.
Tool:
- Developer Console Memory
- MicroProfiler Client
- Studio Explorer property filters
Symptom:
- GraphicsMeshParts, GraphicsTexture, GraphicsParticles, or PhysicsParts high.
- Client frame time spikes when looking at dense area.
Safe direction:
- Reuse meshes.
- Use Automatic render fidelity.
- Use Box/Hull collision for non-critical meshes.
- Disable unnecessary shadows.
- Reduce particle rates.
這樣的稽核表就是本章的基準。
效能修正前，先建立 baseline。baseline 不需要很精準，但要可重複。
你可以建立這張表：
Test device:
Test mode:
Players:
Graphics quality:
Area tested:
Session length:
Client FPS / frame time:
Server heartbeat:
Client memory:
Server memory:
Top Script Profiler entries:
Largest Memory categories:
Observed spikes:
Notes:
例如：
Test device: MacBook development machine
Test mode: Studio Play Solo
Players: 1
Graphics quality: Manual, high
Area tested: start area -> ruins -> enemy patrol
Session length: 5 minutes
Client frame time: mostly under 16.67 ms, spike near ruins
Server heartbeat: stable
Client memory: watch PlaceMemory / GraphicsMeshParts
Top Script Profiler entries: EnemyAIService, HUDController
Observed spikes: entering ruins, collecting multiple crystals
這不是正式效能報告，但足夠讓你知道修正前後是否有變化。
Script Profiler 用來看 Script CPU time。它在 Developer Console 裡，可以選 Client 或 Server。
圖 21-2 在 Developer Console 的工具選單開啟 Script Profiler，並分別錄製 Client 與 Server；兩側的 CPU 熱點通常不同。
本章建議先錄兩次：
Recording A: Client
- 操作 HUD
- 使用 WindDash
- 打開商店
- 接近 Guide
Recording B: Server
- 收集水晶
- 敵人巡邏
- 購買升級
- 觸發存檔相關流程
看結果時，不要只看「有沒有某個函式出現」。要看它是否長時間佔用、是否頻率太高、是否和你剛才的操作對應。
如果 HUDController 在沒有任何 UI 變化時仍然大量出現，可能代表它每 frame 更新文字。
如果 EnemyAIService 長時間佔用 server CPU，可能代表敵人距離檢查、路徑檢查或 loop 太頻繁。
如果很多 CrystalScript 重複出現，可能代表每顆水晶都有自己的 Script。
Memory tool 看的是整體記憶體分類。對本專案最有用的分類是：
PlaceMemory
PlaceScriptMemory
LuaHeap
GraphicsMeshParts
GraphicsTexture
GraphicsParticles
PhysicsParts
Sounds
Gui
如果你加入大量 Mesh 或外部 AI 生成素材，GraphicsMeshParts 和 GraphicsTexture 會變重要。
如果你加入很多音效與音樂，第七部會更常看 Sounds 與 streaming audio 相關項目。
如果玩家進出、敵人生成與水晶重生後，LuaHeap 或 InstanceCount 持續上升，就要懷疑 memory leak。
LuauHeap snapshot 可以幫你看：
這會直接影響 SaveService、RateLimiter、EnemyAIService、CrystalCollectionService 這類會記錄玩家或 Instance 狀態的服務。
MicroProfiler 看的是 frame time。
FPS 是結果，frame time 才是你要追的原因。大致換算：
16.67 ms -> 60 FPS
33.33 ms -> 30 FPS
但平均 FPS 不夠。玩家感覺到的卡頓常常是 spike：
10 ms, 11 ms, 10 ms, 80 ms, 11 ms
平均看起來可能還行，但那個 80 ms frame 會讓玩家感覺明顯卡住。
MicroProfiler 的基本用法：
1. 開啟 MicroProfiler。
2. 玩一段會造成卡頓的流程。
3. 找上方 frame time bar 裡特別高的 frame。
4. 點進 timeline。
5. 看是哪一類 task 變長。
6. 回到 Script Profiler、Memory 或場景設定做更具體修正。
如果偏橘色，常見方向是 script、physics、animation。
如果偏藍色，常見方向是 render、物件密度、lighting。
如果偏紅色，常見方向是 GPU wait、複雜 mesh、texture、visual effects。
這不是絕對分類，但能幫你決定下一步看哪裡。
RunService 很有用，也很容易被 AI 濫用。
Assistant 常會寫：
RunService.Heartbeat:Connect(function()
-- update something
end)
這不一定錯。問題是：這件事真的每 frame 都要做嗎？
HUD 金幣文字不需要每 frame 更新。Gold 改變時更新即可。
商店價格不需要每 frame 更新。打開 panel 或 config 改變時更新即可。
NPC 提示距離也未必每 frame 需要完整計算。可以降低頻率，或只在玩家接近區域時檢查。
Prompt 裡可以這樣要求 Assistant：
【Ch21 稽核｜檢查每幀更新】
檢查 RunService 的使用方式。
針對每一處 Heartbeat、PreRender、RenderStepped 或 BindToRenderStep：
- 說明為什麼需要每 frame 更新。
- 如果不需要每 frame 更新，建議 event-driven 或較低頻率的替代方案。
- 目前先不要更改玩法行為。
如果你看到很多重複 Script，優先考慮 CollectionService。
不好的方向：
Crystal_001
└── Script
Crystal_002
└── Script
Crystal_003
└── Script
比較好的方向：
Workspace.Collectibles
├── Crystal_001 [tag: CollectibleCrystal]
├── Crystal_002 [tag: CollectibleCrystal]
└── Crystal_003 [tag: CollectibleCrystal]
ServerScriptService.Services
└── CrystalCollectionService
CrystalCollectionService 用 tag 找到所有水晶，統一連接 Touched 或互動邏輯。
這樣做的好處：
使用 tag signal 時，要注意清理 connection。這也剛好連到 Memory / LuauHeap 的檢查。
大型場景不能只靠刪物件。Roblox 的 Instance Streaming 可以讓 Workspace 裡的 3D content 依玩家位置載入與卸載。
本章先建立幾個原則：
Workspace.StreamingEnabled 是 Studio property，不用 script 設定。Workspace descendants。ReplicatedStorage 裡的東西不會因為 Streaming 而分區載入。你可以請 Assistant 幫你做檢查表：
【Ch21 稽核｜檢查 Instance Streaming】
為「AI Adventure Island」建立一份 Streaming 稽核清單。
包含：
- Workspace.StreamingEnabled 的狀態。
- Workspace 下的大型 models。
- 應維持 Nonatomic 的 models。
- 少數可能需要 Atomic 的情況。
- 除非必要，否則避免使用 Persistent。
- 檢查重要的 client scripts 是否能處理 parts 被 stream out 的情況。
- 對 streamed content 謹慎使用 WaitForChild。
目前先不要更改 properties。
Streaming 是大型場景章節的基礎。第 22 章跨裝置測試時，手機會更明顯感受到它的價值。
AI 生成或外部工具匯入的美術素材，最常見問題不是「看起來不夠好」，而是「看起來太貴」。
MeshPart 要看：
RenderFidelity
CollisionFidelity
如果是裝飾小石頭，不需要精準碰撞。Box 或 Hull 可能足夠。
如果是玩家永遠碰不到的背景模型，可能不需要 CanCollide、CanTouch、CanQuery。
Light 要看：
ParticleEmitter 要看：
這些都很適合用 Assistant 產生 audit checklist，但修改仍要人工看畫面。效能修正不能把場景修到沒有辨識度。
第 21 章的 playtest 分成四輪。
1. 開始 Play Solo。
2. 打開 Developer Console。
3. 走過起始區、Guide、敵人巡邏區、商店。
4. 記錄明顯卡頓點。
5. 記錄 client memory 與 server memory。
6. 記錄 Output 是否有 red errors。
Client recording:
- 打開 HUD。
- 使用 WindDash。
- 打開商店。
- 關閉商店。
Server recording:
- 收集多顆水晶。
- 觸發 Guide。
- 讓敵人巡邏。
- 購買升級。
記下 top entries，不急著改。
1. 開 MicroProfiler。
2. 走進最密集的場景區域。
3. 使用 WindDash 快速穿越。
4. 觀察 frame time spike。
5. 找出 spike 偏 script、physics、render、GPU wait 還是 network。
這一步是用來定位，不是直接得到答案。
1. 看 Memory tool 的 Client。
2. 看 Memory tool 的 Server。
3. 記錄 PlaceMemory / PlaceScriptMemory / LuaHeap。
4. 特別看 GraphicsMeshParts、GraphicsTexture、GraphicsParticles、PhysicsParts、Sounds。
5. 如果可行，建立 LuauHeap snapshot。
6. 重複操作一段時間後再看是否持續上升。
如果 memory 持續上升，優先檢查：
如果發現每顆水晶都有一支 Script，使用：
【Ch21 修正 1｜重複 Script】
重構可收集水晶，改用 CollectionService。
目前問題：
- 多顆水晶包含重複的 scripts。
目標：
- 將 CollectibleCrystal tag 加到可收集的水晶 parts 或 models。
- 使用單一 server-side CrystalCollectionService 管理收集流程。
- 保留現有的獎勵行為與 UI updates。
- 防止同一顆水晶重複發放獎勵。
- 水晶被移除時，清理 event connections。
不要更改水晶獎勵或任務需求。
編輯後，列出回歸測試。
如果 HUD controller 每 frame 更新文字，使用：
【Ch21 修正 2｜不必要的每 frame UI 更新】
將 HUD updates 重構為 event-driven。
目前問題：
- HUD controller 每 frame 更新 labels。
目標：
- leaderstats.Gold 改變時才更新 Gold label。
- GuideQuestState 改變或 server 傳送 QuestUpdate 時才更新 quest label。
- 只有 cooldown 正在倒數時才更新 ability cooldown UI。
- 不要使用 RenderStepped 或 Heartbeat 更新靜態 labels。
不要更改 UI layout。
編輯後，列出回歸測試。
如果 EnemyAIService 佔用過高，使用：
【Ch21 修正 3｜敵人 AI 太頻繁】
檢查 EnemyAIService 的更新頻率。
目標：
- 保留現有巡邏行為。
- 避免每 frame 執行昂貴的檢查。
- 使用具有明確 interval 的集中式 update loop。
- 對遠離所有玩家的敵人，考慮降低更新頻率。
- 除非另有要求，否則不要更改敵人傷害、巡邏路線或偵測半徑。
- 玩法權威維持在 server。
編輯後，列出修改內容與重新測試方式。
如果發現 UI 或能力每 frame fire remote，使用：
【Ch21 修正 4｜Remote traffic 太高】
稽核 RemoteEvent 是否產生過量 traffic。
規則：
- 除非絕對必要，否則不要每 frame 傳送資料。
- 傳送狀態變更，不要重複傳送完整狀態。
- 如果只有一個欄位改變，不要傳送整份 inventory 或完整玩家資料。
- 玩法結果的權威維持在 server。
- 純視覺效果可以用小型、經過清理的 messages 觸發。
不要重新命名 RemoteEvents。
列出每一個 remote 及其建議頻率。
如果問題偏 rendering 或 memory，使用：
【Ch21 修正 5｜Mesh / 場景過重】
建立一份環境效能整理計畫。
目前先不要修改場景。
檢查或列出：
- 裝飾密集的區域。
- 使用高成本 CollisionFidelity 的 MeshParts。
- RenderFidelity 未設為 Automatic 或 Performance 的 MeshParts。
- 不需要 CanCollide／CanTouch／CanQuery 的 Parts。
- 啟用 shadows 的 Lights。
- Rate 過高或 Lifetime 過長的 ParticleEmitters。
- 不應設為 Persistent 的大型 models。
針對每一個問題，提出不明顯影響視覺的最佳化方式與回歸檢查。
本章完成後，專案應該有這份 checklist。
Script CPU:
- Run Script Profiler on Client.
- Run Script Profiler on Server.
- Check top entries.
- Check duplicate scripts.
- Check RunService usage.
Memory:
- Open Developer Console Memory.
- Record Client PlaceMemory and PlaceScriptMemory.
- Record Server memory.
- Check GraphicsMeshParts, GraphicsTexture, GraphicsParticles, PhysicsParts, Sounds.
- If memory grows over time, inspect LuauHeap.
Frame time:
- Open MicroProfiler.
- Walk through dense areas.
- Trigger ability, shop, enemy, collect flow.
- Record spikes.
- Identify whether spike is script, physics, render, GPU, or network related.
World:
- Confirm Workspace.StreamingEnabled.
- Avoid overusing Persistent models.
- Check large moving assemblies.
- Check dense decoration zones.
Meshes:
- Prefer reused mesh assets.
- Use Automatic or Performance render fidelity when appropriate.
- Avoid high collision fidelity for decoration.
- Disable collision/touch/query when not needed.
Networking:
- No RemoteEvent every frame unless justified.
- Send deltas or state changes, not full state repeatedly.
- Keep visual-only effects small and sanitized.
Regression:
- Crystal collection still works.
- Guide quest still works.
- WindDash still works.
- Enemies still patrol.
- Shop still purchases correctly.
- Save still loads and saves.
- Output has no red errors.
第 20 章說過 server 是 gameplay authority。第 21 章不能為了效能把這件事改掉。
可以搬到 client 的通常是：
不應該搬到 client 決定的是：
比較好的模式是：
client requests action
-> server validates and decides result
-> server sends small result event
-> client plays visual/audio feedback
這同時兼顧安全與效能。
效能不是最後一天才做的事情，也不是做一次就結束。
每次讓 Assistant 新增大型功能後，都要問：
這些問題會讓 AI 生成工作流更穩。
本章把專案從「功能能跑」推進到「知道如何觀察效能」。
你現在應該記住：
下一章會進入跨裝置 UI 與控制。效能讓遊戲跑得動；跨裝置檢查會確認玩家真的能在手機、桌機與手把環境中玩得順。
嗨！我是 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 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊聯繫，洽談講座與工作坊合作！
🎮 我的 Roblox 遊戲
🎁 免費贈送 OpenAI 或 Claude AI 額度
為了鼓勵大家實際動手打造自己的 Roblox 體驗，我每個月會開放：
參加方式：
確認完成後，我會邀請你加入並設定 50 點額度。名額有限，歡迎把握機會！
iThome鐵人賽
看影片追技術