Game Design Portfolio

YEH KAI

遊戲設計師 / 開發人員 Game Designer & Developer

Scroll

Profile / 00

嘿，我是一名來自台灣的遊戲設計師，熱衷於創作各種有趣的遊戲！

15+ 年遊戲企劃與主企劃經驗。擅長在新鮮玩法、系統設計、數值與實作可行性之間取得平衡，把創意概念推進成可製作、可驗證的遊戲體驗。

我特別擅長在新鮮玩法與實作可行性之間取得平衡：讓點子保有創意，同時能被拆成明確規則、資料結構、開發流程與測試方式。

15+ 年遊戲設計資歷，橫跨 5 間遊戲公司

獨立遊戲開發者一人完成 Grey Verge，Steam Demo 已上線

AI 協作開發用 Claude Code、Codex 推進實際專案

My Backstory

我的經歷軌跡

Grey Verge

2026

獨立開發卡牌 Roguelite《Grey Verge》；Steam 商店頁與 Demo 已公開，已入選 G-EIGHT 2026。

遊戲橘子

2017 - 2025

開發策略類手遊，專注於戰鬥系統設計與企劃負責人。開發多款玩法原型協助內部進行概念試驗。

大宇資訊

2017

開發動作型 PC 遊戲，專注於戰鬥系統數值。

遊酷科技

2014 - 2016

開發多款手遊，專注於內容規劃與數值設計。

ZECKSA

2013

獨立以 Unity 開發拼裝型射擊遊戲，獲巴哈姆特遊戲創作競賽佳作。

三貝德

2012 - 2014

開發數位遊戲教育產品，專注於遊戲內容規劃。

耶克

2010 - 2011

開發社群網頁休閒遊戲，專注於 UI 原型設計與企劃。

求學期

2006 - 2007

藍海事業設計 CIS。獲 VR 盟主大中華區最佳技術獎、4C 數位創作競賽遊戲組大會銀獎與企劃組佳作。

Works / 01

作品入口

Works / 03

作品軌道

每個作品入口會逐步整理成獨立作品頁；目前 Grey Verge、ZECKSA 與 CT 已先補上案例內容，其餘作品會陸續整理。

Featured Case

Grey Verge

把壓不住的創作衝動，做成一款遊戲。

Grey Verge 是我獨立開發的原創卡牌 Roguelite，也是我將玩法創意推進成可公開試玩作品的主案例。Steam 商店頁與 Steam Demo 已公開，itch.io 另提供開發中瀏覽器試玩版，作品已入選 G-EIGHT 2026。

我的角色: 獨立開發（企劃、系統、數值、主視覺）
專案類型: 原創卡牌 Roguelite
開發背景: 個人獨立開發，Godot 4.6 + AI 工具
重點成果: Steam Demo 上線、入選 G-EIGHT 2026

Steam 商店頁（可下載 Demo）瀏覽器試玩版

Core Design

核心設計：湊牌爆發

Grey Verge 的核心挑戰，是如何把「等牌、成牌、爆發」這種桌遊式爽感，轉化成節奏更快、規則更輕的卡牌戰鬥。

一般卡牌遊戲常需要玩家閱讀大量卡牌效果才能做判斷；如果把這套邏輯放到麻將裡，就像每張牌都有獨立特殊能力，門檻會立刻變高。因此 Grey Verge 刻意降低卡牌閱讀負擔，將主要策略重心放在三種牌型與三位角色的直覺組合上，只讓少數卡牌承擔獨特效果與變化。

玩家能快速判斷「我現在缺什麼牌」，再根據敵人意圖、手牌狀態與 Roguelite 隨機性做取捨。當高倍率牌型終於成形時，會得到類似胡牌的爆發回饋。

Player Reactions

玩家如何回應「湊牌爆發」

這段實況剪輯收錄多位實況主試玩 Grey Verge 的即時反應。從選牌、累積傷害到挑戰高血量 Boss，可以看到玩法節奏與爆發回饋在實際遊玩時呈現的樣子。

Prototype to Godot

從原型驗證到正式開發

Grey Verge 的完整工程開發先從 Web 版 Prototype 驗證開始。我用 Gemini 製作可玩的核心原型，反覆確認「湊牌爆發」的節奏與策略有潛力後，才正式進入 Godot 開發。

從 Unity 轉向 Godot，則是另一個重要製作決策。相較於我熟悉多年的 Unity，Godot 的純文字場景與資源格式更適合與 AI coding 工具協作，也更方便快速檢查、修改與版本管理。這讓 Grey Verge 的後續開發能以更適合獨立製作的方式推進。

AI Coding

AI 協作與設計判斷分工

Claude Code / Codex 在 Grey Verge 中負責協助程式實作、重構與工具製作；設計判斷仍由我主導。我負責定義需求、拆解任務、判斷架構方向，並透過測試與實機檢查驗收結果。

這段經驗真正想證明的重點在於：我能把 AI coding 納入可控的開發流程，讓設計需求清楚、資料結構可管理、實作結果可驗收，最後回到遊戲體驗與版本目標。

Star Editor / Web Editor

為遊戲量身訂做內容編輯流程

為了讓卡牌、角色、敵人、商店與冒險內容能快速調整，我為 Grey Verge 建立了專用的 Star Editor / Web Editor。這讓遊戲內容脫離散落在程式碼裡的狀態，改以資料驅動方式管理、修改與驗證。

Simulation / Balance

卡牌平衡不能只靠直覺

卡牌遊戲的平衡不能只靠直覺。Grey Verge 透過模擬測試比較不同配置下的勝率、平均回合與平均傷害，讓神器、祝福與卡牌效果能被更具體地驗證與調整。

這個區塊對求職讀者的重點是讓對方看到：玩法、數值、資料與測試可以形成迭代閉環，讓點子描述進一步成為可觀察、可修正的設計流程。

Indie Case / 2013

ZECKSA

四方向拼裝，讓機體配置成為射擊遊戲的核心玩法。

ZECKSA 是我在 2013 年利用下班時間獨立製作的 Unity 射擊遊戲。當時沒有明確商業考量，主要動機是想驗證一個玩法概念：能不能讓玩家透過武器配置，自己組出不同戰鬥風格的機體。

我的角色: 一人製作（企劃、美術、3D、程式）
專案類型: Unity 射擊 / 機體拼裝
開發背景: 2013 年下班時間獨立製作
重點成果: 巴哈姆特 2013 ACG 創作大賽佳作

Core Rule

核心玩法：四方向機體拼裝

遊戲以四個方向的裝備配置為核心。玩家可以將不同模組安裝在機體前、後、左、右，形成不同攻擊角度、機動性與生存策略。

Design Trade-off

設計取捨：火力、速度與功能

ZECKSA 的配置核心是火力、速度與功能之間的取捨。武器與模組越多，火力與功能越完整，但速度會下降；裝備越少，機體越輕、移動越快。玩家需要在輸出、迴避、資源收集與生存能力之間做選擇。

Module Set

模組變化

遊戲中包含遠程武器、近距離高傷害光刃、可緩速敵方子彈的範圍力場、追蹤導彈、擴大資源拾取範圍的模組、加速用機翼，以及只能裝在後方的推進器。這些模組讓機體配置超越單純數值增減，進一步改變玩家的操作方式與戰鬥節奏。

Production

從概念到可遊玩成品

我在下班時間約半年內，獨立完成玩法構思、3D 模型、美術素材、UI 與 Unity 實作，使用 Unity、PlayMaker、NGUI、3ds Max 等工具，把四方向拼裝的玩法推進成約 20 個關卡、敵人波次與完整遊玩流程的小型獨立遊戲。作品最終獲得巴哈姆特 2013 ACG 創作大賽遊戲組佳作，是我早期獨立開發歷程中重要的一次外部肯定。

Commercial Work / 2018

Project CT

從組合塔防原型，推進成商業行動遊戲專案。

2018 年，公司正在尋找新的玩法方向。我以「防禦塔組合 × 塔防」為核心概念，使用 Unity 與 PlayMaker 製作了一個聚焦核心玩法驗證的 Prototype。

這個原型以最短路徑驗證核心問題：玩家是否能理解「把防禦塔組合成巨大戰力」的樂趣，以及這套概念是否有延伸成完整遊戲系統的可能。

我的角色: 原型開發 → 主企劃
專案類型: 行動塔防 / 組合策略
開發背景: 遊戲橘子 × 唯晶科技，約 20 人
重點成果: 自製原型提案通過，轉為商業專案

Core Gameplay

核心玩法：把防禦塔堆成移動要塞

Project CT 的核心概念是「可組合的塔防戰力」。玩家可以將不同防禦塔垂直堆疊，組成具備複合攻擊能力的超級巨塔。

當巨塔加裝「移動載具」後，原本固定防守的塔防單位會轉化為可推進、可侵略的移動要塞，讓防守策略轉變成主動進攻。

Project Detail

專案詳情

原型提案通過後，Project CT 轉為商業行動遊戲專案：由遊戲橘子開發、外包夥伴唯晶科技協作製作，團隊規模約 20 人，使用 Unity 開發。

查看 Project CT 商店資料

My Contribution

我的貢獻

提出「組合塔防」核心玩法，並以 Unity / PlayMaker 製作可驗證的 Prototype。
負責原型階段的程式實作與玩法驗證，美術素材不含在個人製作範圍內。
原型提案通過後，規劃完整遊戲機制與系統架構。
以主企劃角色與外包夥伴唯晶科技合作，推進商業版本開發。
設計防禦塔組件、組合規則與戰鬥節奏。
規劃數值系統、策略平衡與成長歷程。
設計新手教學、教學關卡與前期遊戲體驗。

Mobile Game / Unicube

PON PON Jelly

一指控制方向，讓同色果凍在混亂移動中合體收集。

《PON PON Jelly》是一款由 Unicube（遊酷科技）製作的休閒行動遊戲，主打低門檻操作、可愛角色與短關卡節奏。

這個案例的重點，是如何把簡單的方向控制做成一套容易理解、但具有即時判斷與關卡變化的動態消除玩法。

我的角色: 主企劃（帶領企劃組員）
專案類型: 休閒動態消除 / 行動裝置
開發背景: 遊酷科技 Unicube，7 人團隊
重點成果: 自製原型提案通過，進入正式製作

查看 AppMagic 詳情

Core Gameplay

核心玩法：同色合體，異色避錯

關卡會同時出現多種顏色的果凍生物，並在場上自由移動。玩家需要調整果凍方向，讓同色相撞合體完成收集；異色碰撞則會累積失敗。

通關目標是在混亂移動中收集指定顏色。河流、傳送門、變色道具等要素會改變路線判斷，讓玩法從簡單控制延伸成即時配對與避錯挑戰。

Prototype Evidence

先用低美術原型驗證核心手感

在正式美術導入前，我先以簡化方塊與數字完成可操作原型，確認多色移動、方向控制、同色合體、異色失敗、目標收集與關卡流程能成立。

這段原型的價值在於快速檢查場面是否可讀、操作是否直覺，以及動態碰撞規則是否能支撐後續關卡變化。

My Contribution

我的貢獻

我負責從玩法發想、原型驗證到正式製作的核心設計推進。

玩法發想 → 獨立原型開發（包含程式，不含美術素材）→ 提案通過
設計核心規則：同色合體、異色失敗、指定顏色收集
規劃關卡機關、節奏、學習曲線與難度曲線
帶領企劃組員與團隊協作，推進正式製作
數值系統、失敗容錯與平衡驗證
操作系統與玩家回饋規劃

Education Game / 2012 - 2014

智學王

把學習目標包進可探索的遊戲世界。

《智學王》是我在三貝德數位文創參與的數位教育遊戲專案。三貝德以數位幼教與學習產品為主，這段經驗讓我接觸到一種很特別的設計挑戰：如何透過遊戲世界提升兒童的學習意願與學習成效，同時維持教育目標與娛樂回饋的平衡。

產品架構以主世界串聯角色、任務、事件與多個子遊戲，讓學習從點選教材延伸為探索與互動推進。每個子遊戲或事件都需要回到明確的學習目標，讓遊戲行為能支撐學習動機與理解節奏。

這個案例放在作品集中，用來補足我早期將教育目標、任務流程、UI 回饋與可玩原型串在一起的設計經驗。

我的角色: 初階企劃（系統與內容設計）
專案類型: 數位教育遊戲
開發背景: 三貝德數位文創
重點成果: 主世界、事件與子遊戲系統

My Contribution

我的貢獻

主世界與子遊戲系統設計：參與設計主世界、任務與各類子遊戲規則，協助將學習內容轉化為可互動的遊戲流程。
事件與對話流程：編寫遊戲事件與對話系統，讓任務推進、角色互動與學習提示能自然串接。
戰鬥 UI 與操作回饋：設計戰鬥介面資訊層級，整理玩家在戰鬥中需要判斷的狀態、操作與即時回饋。
場景 NPC 動態遊走：設計場景 NPC 動態遊走系統，提升主世界的活動感與探索感。
Unity PlayMaker 原型驗證：製作可操作原型，快速檢查製作人提出的新玩法、UI 回饋與戰鬥流程是否成立。

Commercial Work / 2011

Dungeon viva

第一份商業專案中的 Unity Web 塔防內容，從資料表、UI 原型到可玩流程驗證。

《Dungeon viva》是我剛畢業後加入第一間遊戲公司時參與的早期商業專案。作品以 Dungeon viva 的角色與世界觀為基礎，做成一款快節奏的 Unity Web 塔防遊戲。

這個案例保留初階企劃開始接觸商業製作時的工作痕跡，展示我如何把塔防內容、UI 流程、資料表與測試驗證串成可執行的製作內容。

我的角色: 初階企劃
專案類型: Unity Web 塔防
開發背景: YECK / 耶克娛樂，第一份商業專案
重點成果: 全 UI 原型、資料表與流程測試

My Contribution

我的貢獻

我主要負責內容資料、敵我設定、UI 原型與測試驗證，協助團隊把塔防玩法整理成可以實作、檢查與調整的資料。

遊戲資料表維護：整理並維護防禦塔、敵人、波次與區域路線等資料，讓關卡與戰鬥內容能被團隊實作與測試。
敵人與英雄設定：協助設定敵我單位的角色定位、命名與基礎資料，讓塔防內容與 Dungeon viva 世界觀保持一致。
全 UI Prototype 製作：製作區域選擇、路線選擇、塔列表、戰鬥 HUD、塔屬性窗、升級 / 出售與手動攻擊模式等 UI 原型。
測試與流程驗證：檢查選關、建塔、開始戰鬥、暫停 / 恢復、升級 / 出售與手動攻擊等主要流程是否能被理解並順利操作。

Personal Prototype / 2014

無限怪物生成

用手繪部件與生成規則，試作一套小生物組合模擬器。

這是我約 2014 年左右，純粹因為興趣而做的小型 Unity 原型。起點來自個人興趣與系統好奇：如果把怪物拆成可以重組的頭、身體、眼睛、嘴巴、腳、觸手與配件，能不能用規則生成大量有個性的生物？

我先手繪多組生物部位，有些部件刻意做成多頭、多腳、觸手或奇怪輪廓，再用自己設計的計算機制決定部件抽取、位置連接與整體比例。每次按下生成，都會得到不同的小生物。

我的角色: 個人製作（手繪部件 + 程式）
專案類型: 隨機生成原型
開發背景: 2014 年個人興趣，Unity
重點成果: 手繪部件庫 + 生成規則

Part Library

先把怪物拆成可組合的部件語彙

這個原型的核心是建立一組可以被規則重新排列的素材庫。頭部、身體、眼睛、嘴巴、腳、觸手、尾巴與武器都被拆成獨立部件，讓生成結果可以在同一套風格裡變形。

我刻意加入一些不規則部位，例如多顆頭、多隻腳、長觸手、奇怪尾巴與配件，讓生成結果除了顏色變化，也能產生輪廓、性格與視覺重心都不同的小生物。

這個試驗讓我很早就開始思考「內容量」不一定只能靠一筆一筆製作，也可以透過部件化與規則設計擴張。當部件庫越豐富，可能組出的生物變化會呈指數增加。

它是一個用來驗證想法的小工具：如何讓隨機生成保留驚喜，同時又不失去基本可讀性與造型一致性。這種把素材、規則與結果回饋串起來的思考，也延伸到我後來做系統設計、原型驗證與內容工具時的工作方法。

逆轉引力

這是我在智慧型手機興起初期做的個人玩法原型。當時我想把常見橫向闖關遊戲的控制邏輯反過來：玩家放開對角色前進、跳躍或煞車的直接控制，改由整個關卡方向與重力變化推動角色。

在這個原型裡，角色會隨著場景角度自然滑行、墜落或停靠平台。尖刺、斜面與金幣共同形成一個需要預判的物理空間：玩家每次改變方向，都會連帶改變角色接下來的落點、速度與風險。

對我來說，逆轉引力的價值在於驗證一個很小但清楚的設計問題：當控制方式被極度簡化時，能不能靠場景結構、重力與風險配置，讓玩家仍然感覺自己正在做有意義的決策？

我的角色: 個人製作
專案類型: 重力操控 / 橫向闖關原型
開發背景: 智慧型手機初期，個人原型
重點成果: 用場景旋轉取代角色操作

Gameplay Prototype / Gamania

自走組塔

用橫向捲軸戰場，快速測試組塔、推兵與自走戰鬥的玩法變體。

這是我在遊戲橘子任職期間，基於創新嘗試獨立製作的玩法原型。我把橫向捲軸、組塔、推兵與自走戰鬥做成一套可以快速切換規則的測試台，用來探索多種玩法可能。

右側影片放的是回合制版本。這個模式把操作切成準備與結算兩段：玩家先用手上的卡牌或單位完成建蓋，回合開始後再觀察塔、兵與角色在橫向戰場中的推進結果。

回合制測法適合先檢查預判、陣型、建蓋順序與資源配置是否成立；如果玩家的決策能在下一輪戰鬥中產生可理解的差異，這套組塔語彙才有繼續延伸的價值。

我的角色: 獨立原型設計與實作
專案類型: 橫向捲軸 / 組塔 / 推兵
開發背景: 遊戲橘子創新玩法探索
重點成果: 可切換回合制、即時制、BOT、多人的測試台

Realtime Test

即時制：從回合制延伸出的另一種測試模式

即時制把同一套組塔與橫向推進規則轉成另一種測試模式。玩家需要直接建蓋、投入單位並觀察前線變化，節奏從等待回合結算轉成即時應對。

這個方向可以檢查回合制語彙在高壓節奏下是否仍然可讀：資源恢復速度、建蓋手感、兵線速度與畫面資訊量都會被放大。它讓我能比較同一套核心規則，在回合制與即時制兩種節奏中各自會產生什麼問題與潛力。

Conclusion

結論：把創新方向變成可比較的測試結果

設定截圖保留下這個 prototype 的真正重點：玩法模式、對戰規模、資源恢復、建蓋順序與場景條件，都能在同一套系統中被切換。這讓我能用低成本比較不同方向，減少每次重新製作新原型的成本。

自走組塔適合作為創新玩法探索案例來閱讀。它展示的是我如何把一個方向拆成多組可驗證假設，再用實作把假設放到玩家可操作、可觀察的環境裡。

這種做法能幫助團隊更早看見玩法問題：節奏太慢、資訊太亂、資源太鬆、BOT 壓力不足，或某個模式其實比原本想像更有潛力。對企劃工作來說，原型最重要的交付價值就是讓討論從概念偏好轉成測試觀察。

AR Gameplay Prototype / Unity PlayMaker

AR 機器人戰鬥

這是我在遊戲橘子期間，以 Unity / PlayMaker 製作的 AR 技術應用探索玩法原型。原型將實體桌面轉換成機器人格鬥場，玩家可先切換機器人零件，調整 HP、攻擊、速度與重量等特性，再進入 AR 場景進行對戰。

戰鬥中，機器人會受到碰撞、推擠與場地邊界影響；當角色被推出桌面時，會自然掉落並觸發爆炸與勝敗判定。這個原型重點在於驗證 AR 可以結合實體空間、物理反應與簡單規則，形成一個可操作、可觀察結果的桌上型對戰循環。

我的角色: 原型設計與實作
專案類型: AR 桌上機器人對戰
開發背景: 遊戲橘子 AR 技術探索，Unity / PlayMaker
重點成果: 零件改裝 + 物理推擠的對戰循環

Mobile Prototype / Unity

數字球

用單指點擊與數字大小，試作一個吞噬成長玩法。

這是我在智慧型手機剛興起時，基於個人興趣用 Unity 做的單指操作原型。玩家控制一顆會持續旋轉瞄準的數字球，抓準角度點擊後讓它衝出去；數字大的球可以吃掉數字小的球，吃到小球後自己的數字會增加。

前期重點是用最直覺的大小判斷教會玩家操作；後期加入更大的追逐威脅、球群排列與簡單障礙，讓玩家在被大球逼近時快速尋找可吃的小球，把自己養大後再回頭解決風險。這個原型的價值在於把手機單指操作、timing 瞄準、成長路線與風險判斷壓縮進一個很輕的規則循環。

我的角色: 個人製作
專案類型: 單指吞噬成長原型
開發背景: 智慧型手機初期，Unity
重點成果: 單指 timing 瞄準 + 數字吞噬規則

AI Collaboration Study / 2025 - 2026

LLM 合作模擬器

把類漢米頓路徑改成雙 AI 限字協作任務。

這個案例的起點，是我對 AI 合作行為的好奇。我想知道，當兩個 AI 需要在同一個規則空間裡協調行動，並且受到有限字數與次數限制時，它們會怎麼溝通？

我設計了一個 5x5 格子的紅藍路徑任務，讓兩個 LLM 分別扮演紅方與藍方。它們需要從指定起點走到終點，在有限的溝通次數與字數下協調路線，避免互相衝突，並盡可能覆蓋完整地圖。

如果用圖論語言回頭看，這個任務接近「類漢米頓路徑」：Hamiltonian path 指的是走過圖中每個節點剛好一次的路徑。不過我設計前並不知道這個名稱，題目設計來自我自己的合作任務想像，後來才發現概念與既有圖論問題相近。

這裡的變體把漢米頓路徑改造成雙代理合作測試。兩條路徑有固定起終點、共享地圖、限字溝通，還要避開彼此造成的衝突，所以對 AI 來說難點除了找路，也包含在極短訊息裡理解隊友意圖。

模擬器本身負責事後裁判與戰情回放：接收雙方提交的路徑，逐步播放移動過程，標記失誤，並統計團隊總失誤與任務達成率。

我的角色: 題目設計、工具製作、結果判讀
專案類型: 雙 LLM 協作實驗
開發背景: 個人研究，用 AI 協作做出模擬器
重點成果: Gemini 2.5 Pro 成功率約 75% → GPT 5.5 0 失誤

Earlier Test / Gemini 2.5 Pro

合作成功率不佳

2025 年，我用當時很強的 Gemini 2.5 Pro 進行測試。它能達到約 75% 成功率；但在高度壓縮的合作任務裡，仍然容易留下小失誤，穩定度還不夠好。

常見問題之一是誤解隊友：一方以為對方會避讓、補格或收尾，實際提交時卻產生路徑重疊，讓局部看似合理的方案在合併後出現衝突。

另一個問題是交代不清。模型有時會用含糊縮寫或不一致格式描述路線，導致最後輸出難以判讀；即使大方向接近正解，也可能因為撞格、漏格或格式失準被模擬器標記失誤。

Current Test / GPT 5.5

5 字內完成分工，0 失誤通關

近期我用 GPT 5.5 重新測試同一類任務，結果非常不同。過去需要把溝通限制放寬到 30 字以內，模型還是可能失誤；現在則能把關鍵協商壓到 5 字左右，準確率幾乎接近這個任務設計下的理論上限。

這次對話裡，AI 用「紅全藍避」先建立隊伍分工：紅方負責完整主路徑，藍方避開衝突並配合收尾；接著用「定案可」「確認」完成方案鎖定。短字串裡其實包含了策略、責任分配、風險邊界與承諾。

最後紅方提交主覆蓋路徑，藍方提交避讓路徑；模擬器回放判定團隊總失誤 0 次、任務達成率 100%。這讓它成為一次成功案例，也形成一個可以持續比較模型合作能力演進的測試框架。

Workflow

人類負責設計問題與驗證框架

在製作流程上，我把 AI 分成不同角色使用。主編 AI 協助整理規則與 GDD，Coding AI 協助生成可互動模擬器，而我負責決定測試問題、限制條件、驗證指標與案例判讀。

這個案例的重點在於建立一套 AI 可以反覆參與的設計流程：人類提出問題、定義規則、建立驗證方式；AI 參與文件整理、原型製作與任務解答；最後再用工具把結果轉回可比較的數據。

Worked In

曾任職於

Skills

技能

設計技能

遊戲系統
關卡設計
遊戲數值設計
使用者體驗設計
原型製作

技術技能

Unity 引擎 & PlayMaker 插件
Godot
Adobe Photoshop
Autodesk 3ds Max

AI / Agent 技能

Claude Code
Codex
Stable Diffusion & ComfyUI
Antigravity
Cursor
NotebookLM