遊戲開發? 每個愛玩遊戲的可能都想過、但不是每個人都做過

曾經高中的時候，愛玩遊戲的自己也曾想過自己從頭到尾都加入自己喜歡的材料，自己喜歡的元素來做出一款屬於自己的故事。
可能就跟剛想學做菜的人一樣，**好吃加好吃，不一定會好吃。**做出一款看起來能動，但完全沒內涵的遊戲，接著很快就放棄了。

輾輾轉轉十年也過去了，在工作領域上慢慢摸到AI & Vibe coding 驚覺到，是否我只要專注於結構開發，專注在我喜歡的事情上，剩下的麻煩事就讓AI 來接手。

長年品管工程的經驗看來要在AI上發揮其他用處了。
這篇文章，就是我如何開始「設計這個同事」的過程。

字面溝通的困難，AI 幻覺與溝通困境。

不知道大家有沒有這些經驗

• 這傢伙是不是聽不懂人話?
• 不要自作主張?
• 要我講幾次?
• 在學校沒人教是不是?
  跟AI 講話我的心裡一直重複以上的對話，彷彿我沒找到一個可以合理對話方法與途徑
  但其實實際的問題是
• 我自己也不知道自己在說什麼?
• 這樣做的目的是什麼?
• 我好像也不知道?
• 先要求在說，等成果出來再改?

"要求一開始是完美的" 這件事在AI 開發上基本上是不存在的，
人都沒辦法一版就給你完美的產出了，何況是根本不知道你需求，也只就跟你用幾句話溝通的AI。

在這個基準上一件重要的事情就浮現出來了，
我怎麼設計與AI 的對話

學會問對的問題，要先清楚自己要幹嘛

讓我們這篇文章回歸到一個最根本的問題
我想透過Vibe coding 做些什麼，這個對話就會慢慢產出一些項目

• 階段目標
• 階段作法
• 階段成果

讓我們從遊戲架構上來找出階段目標有哪些?

找出我們的產品目標

世界觀設定
遊戲類型
劇情機調

基於文章目的 這裡會專注於遊戲類型的討論，其餘的不會是要注重的項目

遊戲機制

遊戲視角
核心玩法
操作節奏
主要體驗

基於文章目的 這裡會專注於核心玩法的討論，其餘的不會是要注重的項目

工程實作

系統與模組規劃

到這個時候就是我們開始去與AI 協作生產的階段。

挑剔自己的同事?不，這叫因材施教!

當目標已明確定義後，下一階段即是將工作有效分派給具備執行能力的對象。

核心問題在於：如何進行工作拆解與作業流程安排？

首先，需要釐清各項工作的性質與所屬階段。一般可分為以下三種類型：

發想討論階段：強調創意延伸與多元探索，允許較高自由度
架構討論階段：聚焦邏輯嚴謹性與標準制定，產出可被記錄與傳承的架構內容
程式產出階段：依循既定規範與文件，完成具體且可驗證的實作

在 AI 工具的選擇上，我認為都可以。重點在於善用既有工具與經驗進行適配，這本身也是能力累積的一環。

基於實務經驗，可採取以下分工模式：

架構討論 → GPT：負責整理與輸出結構化架構文件
程式產出 → Codex：依據架構文件進行程式實作與專案生成
發想與創意 → GPT / Gemini：用於概念延伸與多角度思考
文件整理 → NotebookLM：進行文件歸納與架構重整

透過多工具分工協作，可以有效提升資訊結構的清晰度，並強化整體作業流程的可控性與可追蹤性。

建立正確的對話

知道話要對誰講了，對話的內容如何建立?
讓我們來明確清晰所有Prompt 的設計架構

腳色定位

定義出你想討論或規劃的內容是要與怎樣的人員做溝通
定義出此AI 的性格、做事風格是很重要的

任務範疇

定義出這個事件的輸入、輸出範圍
由此來讓此Task 過程是專心一致，不混亂的

輸出標準

https://agents.md/
是一個非常有用的工具，用以記錄專案內容的撰寫標準，使得後續產出有明確的規則與邏輯
方便維護的同時也提高自己的可讀性

學到了什麼? 原來對話可以如此清晰

當我們開始用固定的對話元素來讓 AI 產出後，與 AI 的互動流程，會從原本的「試產出 → Debug」，逐步演進為：
產出架構 → 檢視邏輯 → 試產出 → Debug → 優化架構
這個轉變的本質，不在於 AI 變強，而在於專案開始具備可控性。

過去常見的問題是：直接要求 AI 產出最終結果，導致產物結構不明、邏輯不一致，最終只能透過反覆試錯來修補。這種模式的成本極高，且不可累積。
而當架構清晰明確了以後，整體運作模式會出現兩個關鍵變化：

1. 從「黑箱產出」轉為「白箱控制」
   每一個輸出不再是不可預期的結果，而是來自明確定義的：
   輸入條件
   處理邏輯
   輸出格式
   AI 的行為被約束在可理解的範圍內，使問題能被定位，而不是只能被感知。

2. 將 AI 納入閉環流程（Closed Loop）
   當流程被設計為：
   產出 → 檢視 → 修正 → 再產出
   且每一步都有標準與依據時，AI 不再只是執行者，而是流程中的一個節點。
   進一步可演化為：

• 自產出（Generate）
• 自檢查（Validate）
• 自修正（Refine）
  這使得整個開發過程具備「內部迭代能力」，降低人工介入頻率。

不要再把自己定義為單純的設計者，而是規劃師

當整個流程建立起來之後，一個更根本的轉變會自然發生——你的角色不再只是「設計內容」，而是「規劃整個產出系統」。

設計者關注的是「做出什麼」，
而規劃師關注的是「如何穩定地做出來」。

當一個設計流程被規劃出來後，專案產出這件事情就開始有可複製性了。

這會帶來一個關鍵的轉化：
從「產出一個作品」變成「產出多個作品的能力」。

這時候問問你自己，當你有一套完整流程時，你想打造出什麼呢?
答案其實已經不再只是「一款遊戲」。

謝謝看到這邊，嚴格來說，這篇內容沒有什麼「立即可用」的答案。只是一些過程中的隨手筆記。
但是我發現提出一些想法交流的時候，架構規劃上才會有所成長，才會想要開始撰寫這一篇。
練習把話講清楚，練習把想法講清楚，並且嘗試接觸有相關經驗的人才能慢慢產生對我的修正的可能性。

開始讓自己的想法被檢視、被質疑、被補強時，我的下一個架構，我的下一篇文章才有更好更進步的可能。