本文定位與證據級別

證據級別：深度音訊轉錄整理。原影片沒有公開字幕；本文在取得使用者明確「深度」授權後，僅暫時下載公開音訊並以本機語音辨識轉錄。影片長約 3 分 17 秒，創作者為 MojoAI。專有名詞、數字及畫面操作可能受語音辨識誤差影響；本文另外以公開 GitHub README 核對「book-to-skill」概念與可見專案結構。影片作者或專案 README 的成效敘述均不等同獨立驗證。

影片展示了甚麼？

影片的主線很直接：先把一本遊戲設計相關電子書轉成可供 AI Agent 調用的技能，再讓 AI 按該技能協助零經驗使用者規劃並製作一款塔防小遊戲。這不是把全書原文塞進一次對話，而是把書中的框架、操作步驟、案例與注意事項整理為可重複使用的技能指引。

流程一：由書籍建立 Skill

  1. 安裝或建立技能：影片展示在 Agent 工具的設定／技能位置建立全域 Skill，並將 book-to-skill 相關技能放到指定位置。
  2. 交給 Agent 一份電子書路徑：使用者要求 AI 運用 book-to-skill 技能，並提供書籍檔案位置。
  3. 選擇提取策略：轉錄顯示 Agent 會先判斷書籍適合的提取方式；影片中的例子是遊戲設計基礎原理書，因此選擇偏技術／結構化的處理路徑。
  4. 先回報成本與範圍：影片展示 AI 會回報預計提取結果、token 消耗與時間估算，再讓使用者確認是否繼續。
  5. 命名與生成：確認技能名稱後，等待處理完成，得到由該書內容衍生的遊戲設計 Skill。

這個設計的重點不是自動化本身，而是把「讀過但用不上」的書籍內容，轉成 Agent 可以在對應情境中遵循的明確程序。

流程二：用遊戲設計 Skill 輔助做塔防遊戲

影片其後以「完全沒有程式經驗，如何由零讓 AI 生成一款遊戲」作為輸入。依轉錄，Agent 先調用遊戲設計 Skill，分析開發步驟並提出整體架構；使用者確認後，進入多輪需求澄清，而非一開始就要求 AI 直接產出成品。

需求澄清包含的層面

  • 遊戲類型與核心體驗；
  • 影片示例選擇塔防方向；
  • 防禦塔、升級系統、敵人與路線／關卡等設計；
  • 難度取向；
  • 金幣或資源系統、像素風視覺與背景設定。

當需求逐步確認後，影片展示 AI 依「需求 → 架構 → 開發」的次序製作遊戲。完成後還會要求測試；若瀏覽器載入失敗或出現錯誤，使用者可把錯誤訊息交回 Agent 進行修正。影片也提到操作問題、塔的選取及美術顯示等，可作為後續迭代項目。

真正可複用的工作法：不要只叫 AI「幫我做遊戲」

影片最有價值的地方，在於展示一個較可控的 Vibe Coding 流程：

  1. 知識先結構化：把遊戲設計書中的原則轉成 Skill，而非期望模型每次臨時想出完整方法。
  2. 先規格、後實作：先確定核心體驗與限制，再決定系統、內容與視覺。
  3. 分段確認：架構、需求、實作每一段均保留使用者確認點，減少做出錯誤方向後才大幅重工。
  4. 以可觀察錯誤作回饋：在瀏覽器測試，把實際報錯、無法操作的行為與預期結果一併交給 Agent。
  5. 把 Skill 視作活文件：若某類錯誤反覆出現，可將驗收清單、除錯規則或設計約束回寫到技能，使下一次協作更可靠。

公開資料核對：book-to-skill 類專案的設計

影片提到 book-to-skill。公開搜尋可找到 apple-ouyang/book-to-skill 專案，其 README 的定位是把書籍拆成 Claude Code 可執行 Skill，並示範把決策書籍中的 WRAP 框架拆成主 Skill 與子 Skill。該 README 列出的方法包括：先按頁數與上下文容量評估是否需要多 Agent、讀目錄建立框架骨架、按章節提取具體操作與案例、組裝成 SKILL.md，最後以真實場景測試。

這與影片「由書到技能，再由技能引導實作」的概念一致；但影片使用的具體插件、版本、安裝位置與 UI 操作，未能單靠轉錄完全獨立核實，因此不把它們寫成通用必然步驟。

如何把這方法用得更安全、更有用？

  • 注意版權與授權：擁有或獲授權閱讀書籍，不代表可以把全書內容公開再發布。Skill 應以自己的結構化流程、短摘錄與必要引用為主。
  • 建立可驗收規格：遊戲要列出啟動方式、主迴圈、勝敗條件、關卡規則、輸入操作、資源系統及最低可玩版本，不只列美術風格。
  • 讓 Agent 做小步提交：先做一個可玩的塔、防禦路徑與敵人生成，再加入升級、視覺與平衡，避免一次生成難以維護的巨型專案。
  • 保留測試證據：每個版本記錄可重現的啟動步驟、瀏覽器主控台錯誤、畫面或行為驗收結果。
  • 把敏感內容排除：不要把含私人資料、商業機密或未授權付費內容的原始檔直接放進雲端 Agent 工作流。

不宜直接採信的細節

影片開頭似乎提及某個 star 數，語音轉錄對該數字及部分工具名稱辨識不穩定，本文不引用。是否真的能「任何書籍」直接轉成高品質 Skill，也取決於原書結構、授權、提取品質、模型上下文、評估方式與人手審閱；不能當作保證。

結論

這支影片展示的不是「一本書自動做成遊戲」的魔法，而是一種把知識轉為工作程序的做法：先由來源萃取可執行規則，再以規格澄清和測試回饋約束 AI 的開發行為。對遊戲開發初學者而言，最實用的啟示是把遊戲設計知識、需求問卷、實作節奏及除錯清單變成可版本控制的 Skill；AI 才較可能由一次性生成器，變成可協作的開發助手。

來源