這是我國小三年級時寫的，它是一個會出數學計算題的程式。在當時，我妹妹算數學花的時間我都能坐高鐵去台北了，反應非常慢。於是，作為一個好哥哥的我，幫妹妹寫了這麼一個程式，讓她練習。

某個下午，愛下象棋的我在電腦上以「電腦象棋軟體」為關鍵字進行搜尋，想找個功能多又好用的象棋軟體來玩，但找到的不是要錢的，就是掃描後有毒的。在我苦惱時，突然靈光一閃，想到：「現在AI那麼厲害，為何不試試叫AI幫我寫一個呢？」剛好，Google推出了Gemini CLI，能直接讀取本地的檔案進行修改，非常適合用來寫程式。安裝完後，我帶著躍躍欲試的心情，開始這個專案。

專案初期，我請 Gemini 快速生成了一個基於 HTML/JavaScript 的雙人對戰棋盤。在實現基本功能後，我希望能加入「人機對戰」模式。然而，最初由 JavaScript 實現的 AI 演算法面臨一個兩難的困境：若演算法簡單，則棋力不堪一擊；若演算法複雜，則運算時間過長，每一步棋甚至需要等待數分鐘。我遇到了第一個技術瓶頸：如何在棋力（演算法複雜度）與執行速度之間取得平衡。為了突破 JavaScript 的效能限制，我們嘗試了第一個優化方案：將運算核心從 JavaScript 轉向 C++，並透過 Emscripten 編譯成 WebAssembly (WASM) 在瀏覽器中執行。理論上，WASM 能帶來接近3倍甚至10倍的執行效率。然而，實際測試後發現效能提升有限，瓶頸依然存在。這次嘗試讓我意識到，對於象棋 AI 這種計算密集型任務，單純的語言轉換可能不足以解決問題，演算法和模型本身才是關鍵。

我想到可以尋找其他人訓練好開源的AI象棋引擎，來替代我的演算法。在 Google 搜尋輾轉多次後，我找到了「皮卡魚」引擎，它是目前棋力最強的開源象棋引擎，運用AI神經網絡權重，輸出輸入格式遵循 UCI （Universal Chess Interface）協定。但它並不是一個新手友善的應用程式，它是利用 C++ 編譯而成的執行檔，沒有GUI，需要透過介面才能較方便的使用。我的應用程式就會變成介面，用外部引擎替換原有的思維。AI覺得這是很好的一個主意，可以省略掉複雜難搞的電腦演算法，於是我們便著手開發。我們使用 WebSocket 和 Express 技術來與引擎溝通，發送與接收指令。遊戲啟動並成功連上引擎後，開始人機對戰時，引擎會莫名其妙的閃退，一直找不到問題出在哪裡。多次測試後，發現是因為我們的介面端送出去代表局面狀態的FEN記譜法格式錯誤，導致引擎錯亂而閃退。修復完後，程式終於可以正常運行。但我發覺，為了跟引擎溝通，讓這個應用程式的開啟方法變得複雜。原先只有一個html，可以放在 Github 網站的程式，卻因為引擎是執行檔的關係，沒有辦法直接在 Github 網站上執行。我問了AI：「有能夠在雲端運行，不用架站，只要點開連結就能玩，還免費的方法嗎？」AI表示，當然有。像 Heroku、 Vercel 和 Railway 等等的雲端平台，可以直接讀取在 Github 上的 Repository 並自動部署，非常方便。如果使用者要使用，直接點開連結就好了，是非常好的選擇。於是，我選擇以前有聽過的 Vercel 作為我應用程式的雲端平台。

花了很多時間把用於 Vercel 的程式寫好後，發現引擎會無聲無息、莫名其妙的斷線，導致無法遊玩。於是，AI決定在程式碼裡面添加在 Vercel 伺服器印出 Log 的功能，好得知程式錯在哪裡。怪的是，在 Vercel 伺服器的那些 Log 不知為何總是顯示不出來。於是，我們開始懷疑網頁端 WebSocket 的連線問題，也在網頁端印出 Log。結果，網頁端的 Log 其中一行顯示錯誤代碼1006：連線已中斷，無法建立連線。同時，我們發現 Vercel 的 Websocket 功能處於測試中的狀態，可能不穩定。這下水落石出，說明可能是 Vercel 的 WebSocket有問題。於是，我們轉戰到 WebSocket 較成熟的 Railway 雲端平台，繼續部署雲端平台的作業。寫完了 Railway 的程式碼，嘗試部署，沒想到在發布時居然 Crashed 了！我們繼續修改程式，還是難逃閃退的命運，一直失敗。AI提議可以改成用Heroku部署，但得知開發所需時間與失敗風險後，我決定轉型成我以前有經驗，發展成熟的 Electron 做為開發框架，建立成桌面版應用程式。這可以繞開所有因雲端平台不穩定而造成的不確定因素，是成功率極高的方法。程式改完後，至此，我的應用程式定型。