“In the long run we’re all dead.” — John Maynard Keynes

聽說現在鐵人賽沒有 AI 不會出書，而且 Rive 這種又是 UI 又是前端的東西，不太可能不被問到一些 AI 的事情，所以也趁這個機會寫一下我們目前的認知。

當然現在 AI 進步太快了，而且長遠來看，AI 寫出所有程式碼都只是時間的問題，所以以下只是非常個人且非常受限於當下時空背景的說法，有任何錯誤一定都是我的問題，虛心接受一切批評與指教🙇‍♂️🙇‍♂️🙇‍♂️

Rive 的資料還不夠多

首先 Rive 畢竟是又新又冷門的東西，所以就我們目前的體驗來說，問 AI 出錯的機率還不低。而且 Rive 官方的文件一直以來都很，恩，混亂，大概有 87% 的機率也是用 AI 寫的。所以 AI 拿官方文件去訓練，garbage in garbage out，又更混亂了。

Rive 官方有用兩種 AI，一種是 Artificial Intelligence，另一種是 All Indian。印度人寫的文件就跟他們的民族一樣，充滿了生命力。

兩種用 AI 的方法

通常提到 AI，有兩種常見的想像，一種是 one shot 一鍵寫完程式碼，從 Jira 到 PROD 一鍵完成，PM 定義好需求 AI 就自動寫完。另一種是開發時還是要寫程式碼，但是用 AI 大幅度加速寫程式碼的速度，特別是有重複性或有 pattern 的部分。在 Rive 的世界裡，後者幾乎已經可以做到了，但通常設計師或 PM 想像的都是偏前者，只能說我們工程師真的很顧人怨，或是只有我這樣啦。

總之前端在接 Rive 檔有點像在接後端 API，只是 Rive 檔放在前端，後端原始碼放在伺服器上。假設有一包後端 API 的原始碼直接丟給 Claude，我們再叫他根據這包 API 原始碼，自動寫出前端可用的 function，再自動跟前端的 Vue 或是 React 對接。

理論上如果是常見的 API，例如註冊支付報表，而且這包原始碼寫的夠清楚的話，不是不可能。但就我們所知，通常越是成熟的產品越不敢這樣做。理論上可以、實務上可行、實際上正在做，這三個階段中間都會有不少的坑，需要慢慢踩慢慢填平，通常我們會預期說，填平這些坑的成本，會小於未來開發或維護時省下的工時以及 token 花費，這才是正收益。

後端 API 如此，Rive 檔也是如此，理論上燒夠多 token，花夠多時間做 harness，且有隨時要 oncall 幫 AI 救火的準備的話，一定可以做到前者。就跟買股票一樣，看對趨勢的話，就不太需要在意波動，本多終勝這樣。

六名刀本多

AI 沒那麼好瞄準 Canvas 內部的元素

另一個問題是，Rive 是用 Canvas 在畫圖，內部沒有 DOM 結構，所以前端測試用的那套 JSDOM 在這裡不適用。如果 Canvas 畫面結構比較簡單，例如畫面中間一兩個 button，那 AI 還是抓得到。

但只要稍微複雜一點點，例如請他點右上角的漢堡選單，他很容易鬼打牆給你看，至少就目前測試的結果來說是如此。更別說那種「噢回遊戲大廳再進遊戲然後馬上點一下左下角的按鈕」這種更複雜的操作，通常 87% 的 bug 都是發生在這種奇怪的情況。

更好笑的點在於，AI 點不到開始鬼打牆的時候，會開始找藉口（which 也是跟人學的），例如你可能是做一個營養或健身的 app，你只是要請他點右上角的漢堡選單，他會跟你說喔你觸發了我們的安全限制，所以不是我抓不到座標或轉譯問題，但你明明看到他截圖錯地方還點了好幾下。當然這只是目前 AI 暫時的技術性問題，等之後模型更進步了，應該相對很好解決。

被天罰是另一個問題