這是我第二款與 AI 協作，專門給電子紙設備玩的五子棋遊戲
網址在這
https://egz-game.pigo.idv.tw/gomoku/
重要技術特色如下
- 根據用戶設定提供不同的佈景，其中針對電子紙有優化增加體驗
- 單機跟CPU對戰的演算法，部分採用 Rust 撰寫的 wasm 提高算力
- 雙打部分利用 CSS 旋轉特效，達成可面對面對奕的佈局
這款遊戲我打磨了好久才完成，也來談一談辛酸
AI 不懂面對面對奕該怎麼做網頁佈局
本遊戲在雙打模式提供面對面對奕的方式，也就是雙方對坐會看到自己的資訊，文字/計時器都經過旋轉面向自己。
即便我使用了 pencil.dev 這套跟 Figma 相同功能的工具試圖讓 AI 知道我要的結構，但是 AI 會設計的亂七八糟，大概是 GPT 模型沒碰過這類案例吧，這部分 codex 重做了很多次，它做的方向是每個 UI 旋轉修正，後來我把 DOM 結構複製到 Claude 網頁版看，想不到 Claude 一次就做好，沒付費耶 ...，而且 Claude 設計的方式是一整個區塊旋轉就夠了，根本沒有必要每個元素旋轉修正。原來 codex 一開始做的方向就錯了。
最後我還是罵了 codex ，叫他用 Claude 設計的方式。
棋型判斷的問題
本來想說要不要用別人開發好的演算法，但是我找了許久，完全沒有針對黑方禁手規則開發好的演算法，所以還是跟 AI 打交道好久，目前採用極大極小+Alpha-Beta 剪枝，還有一些優化性能的方式，有很多時間都是跟性能打交道，尤其是棋型判斷(判活三/活四等等)吃很重，最後我是將棋型判斷獨立出來交給 Rust WASM 處理，收到很大成效，WASM 在棋型判斷會比 JS 快至少 4 倍，目前設定兩秒在我的 i7-1260P 筆電，演算法做到 depth=6 的深度搜尋是沒問題的。
另外 AI 不太理解真正的棋型規則定義，我一開始也搞不懂，活三在黑方禁手規則下要額外判斷，活三的嚴格定義是下一手可以做成活四，所以這判斷方式不只是這一手活三，下一手也要是活四還不能禁手才是真活三啊 !!!
所以光棋型判斷就重做了好多次了。
那為何目前找的到的無禁手演算法不適合呢 ? 因為我就是有提供黑方禁手與無禁手的玩法。
那這對演算法有甚麼差別 ?
差別可大了，如果在禁手規則下採用無禁手的評分方式，電腦只會給出無禁手的候選落子點，這會有相當大的誤判，電腦以為下一手選的落子點可能形成雙活三可贏(黑方禁手)，結果最後被裁判攔截阻擋，改由較低分的落子點來下，那麼電腦等於下了一步無用的棋。
測試的問題
這裡講的是真正的對奕測試，這無法 AI 代勞
那會讓 Token 吃爆，我有大半時間在查驗演算法問題，棋型判斷的問題 , 還有落子合不合理問題。
小手機至大尺寸的佈局
大概是我太龜毛了吧，其實這遊戲已經做到小到連我的手機 Galaxy S23 都能玩，為了想怎麼佈局，我嘗試了很多種方式，小手機目前的佈局如下，左側有選單，中間有棋盤。
而在螢幕較大的裝置，則選單都在上側，這 AI 也是被我搞的一團亂不知所措就是了
我後來定調 Tailwind CSS 的設計方式
- DOM 層級必須直接用 utility 設定佈局，如怎麼排列，橫向直向，幾欄幾列 , 直接由 DOM 能理解大骨架
- 元件使用 DaisyUI 塞進骨架沒問題
- 牽扯到顏色，陰影，特效等等，則可移至外部 css 或 vue scoped css，不影響骨架的部分都外部定義。
這樣不僅人類容易理解，AI 也只管骨架是否正確，接著做響應式編排就順利多了。
後記
身為免費仔的我，這次是使用 codex-cli 來設計，Model 選 gpt-5.3-codex，現在有 gpt-5.5 了耶，我也試過，但一下就把免費額度用光了，半個功能可能都設計不出來。
雖然我有好幾個帳號可切換，可是切帳號不等於能重複用到 cached , 也等於是重新計算 token，所以免費仔大概永遠都碰不得 gpt-5.5 吧.
這遊戲其實我花了快兩個月打磨才完成的。但也許我駕馭 AI 的能力還不足，看別人好像都做的很輕鬆似的，隨便幾天就搞出一個大專案。
