現在屬於窮人模式的我使用的 AI Coding 方式就是使用 gemini-cli 搭配 gemini-3-flash-preview 模型，基本上我是有 4 個帳號輪流用，一整天下來 Tokens 很夠用，這次展示了一個 conductor extension 來開發踩地雷遊戲的成果，遊戲網址如下 :
https://egz-game.pigo.idv.tw/minesweeper/
這遊戲我本來想說 E-Ink 閱讀器放鬆時玩一下才設計的。
遊戲特色與技術棧
- PWA , 離線可遊玩
- VUE3 + FlyonUI V2.4(Tailwind V4 Base)
- 支援三種佈景，桌機 light , 電子紙彩色，電子紙黑白
- 支援觸控與滑鼠模式
- 猜測裝置類型是否是電子紙/滑鼠，透過 Browser 能提供的有限資訊猜測，如觸控點數量，css media query。
上述的架構，可不是隨隨便便 viber coding 能搞定的事情，AI 會混亂到不行，而之前流行過規格驅動開發，後來有 spec kit , conductor 的工具，我本次就是利用 conductor 這個 gemini-cli extension 來引導建立規格與計畫，但也沒那麼容易就是了，因為 AI 未必真的照規格來，而且有很多錯誤的操作導致我必須重新叫 AI 恢復 GIT 狀態，例如 :
- AI 可能會於開發中期，修改原始 TDD 寫好的測試，如果不注意會被誤刪，你以為程式沒問題嗎，真的會出問題。
- AI 會逃避測試，甚麼叫逃避測試 ? AI 會為了能通過測試，可能會採取了對資料造假試圖通過，而非實際去測試功能。
- AI 會為了逃避測試，索性刪除該測試，試圖跳過計畫標示完成。
所以 ! 當前的 AI 即便進步的快速又強大，也絕對要人工監控 AI 幹了甚麼好事，自己的技術底子一定要有，就算沒有強大的程式設計能力，但至少要有能力來分辨上述的偷懶，欺騙的行為，適時給予嚴厲的糾正。
所以對於 TDD 的部分，我自己是有加強補充 conductor 流程啦，很簡單，就是每次實作 TDD 時，還要針對 TDD 建立詳細任務，除了要完整列舉原始的測試項目與斷言，也要列舉要新增/修改的測試項目，最後就是 TDD 測試也會有一個計劃檔案，這樣你就會知道 AI 到底想做甚麼，然後你可以回頭檢查以下事情 :
- AI 是否修改或刪除原始測試項目。
- AI 是否沒有按照規劃實作測試項目。
- AI 造假測試內容則需要你的技術底子才能分辨。
做這個遊戲只是為了證明一件事情，在E-Ink閱讀器越來越多人使用下，網頁設計者要如何設計出桌機看漂亮，閱讀器上看不閃的網站 ? 我覺得我有抓到關鍵點了。
