這是我第二款與 AI 協作，專門給電子紙設備玩的五子棋遊戲
網址在這
https://egz-game.pigo.idv.tw/gomoku/
重要技術特色如下
- 根據用戶設定提供不同的佈景，其中針對電子紙有優化增加體驗
- 單機跟CPU對戰的演算法，部分採用 Rust 撰寫的 wasm 提高算力
- 雙打部分利用 CSS 旋轉特效，達成可面對面對奕的佈局
這款遊戲我打磨了好久才完成，也來談一談辛酸
AI 不懂面對面對奕該怎麼做網頁佈局
本遊戲在雙打模式提供面對面對奕的方式，也就是雙方對坐會看到自己的資訊，文字/計時器都經過旋轉面向自己。
即便我使用了 pencil.dev 這套跟 Figma 相同功能的工具試圖讓 AI 知道我要的結構，但是 AI 會設計的亂七八糟，大概是沒碰過這類案例吧，這部分我花了很多時間重作，最後乾脆直接指導要旋轉的正確角度 ...
棋型判斷的問題
本來想說要不要用別人開發好的，但是我找了許久，完全沒有針對黑方禁手規則開發好的演算法，所以還是跟 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 的能力還不足，看別人好像都做的很輕鬆似的，隨便幾天就搞出一個大專案。
