今年 AI 能力大躍進，不斷地在社群或網路看到別人說大部分的 Code 都是由 AI 產生，讓我不禁開始懷疑自己的開發方式。去年我還只是拿著 Github Copilot 當作更智能自動補完工具，完全沒有感覺這東西是能有大改變，覺得 AI 終究只是從上下文來預測結果，終究是有其極限。
在三月的時候，剛好在 Flutter Taipei Meetup 聽了有兩個關於 AI 的主題，這才發現或許 AI 已經進步到超乎我想像的地步了，是時候改變思維，擁抱變化了。至今大約 Vibe Coding 了半年多，剛好最近想法上有轉變（最後會提到），所以先來回顧一下這半年的 AI 使用心得了。
三月那會兒，最流行的 AI 工具大概也就是 Cursor 或 Winsurf，有鑒於之前買了一年的 Github Copilot 的教訓，這次就來一個月、一個月的買 Cursor。那買了 Cursor 要用在什麼地方呢？首先在除了在工作中的產品嘗試之外，當時有個朋友找我弄個小小的自動化工具，想想這也是個挺好的機會，就來用 Vibe Coding 的方式來建立這個小工具吧。
開始 Vibe Coding
在開始這個 Side Project 時，我刻意選擇了自己幾乎不太懂的語言加框架，用 Electron + React + Playwright 來做一個自動化的爬蟲工具，希望自己能在開發的過程中學會這些技能（雖然事後看起來效果並不算太好）。
一開始就像坊間常見的 Vibe Coding 分享一樣，直接開始跟 AI 對話，說明我想要什麼功能，要用什麼技術，從最基礎的畫面，一點一點的增加新功能。由於我對 Electron 也不熟，加上人的惰性，所以大多時候，只要功能正常，且我看的懂它在寫什麼，生成的 Code 我大多都直接接受，不太會進一步修改。
失去動手改的能力
但是這樣有個缺點，那就是我只看得懂，要自己動手改就比較難。變成任何小改動，我都是請AI 來做，而不是自己做。熟悉使用 AI 工具的人也都知道，AI 一跑起來快一點也要三四十秒、一分鐘的，甚至還有更久的。但是如果知道怎麼改而且熟悉工具的話，自己改可能也不到 AI 一半時間。
我在自己的工作中也會使用 AI，常常會在內心評估每個改動到底是自己改比較快，還是 AI 改比較快。但是在不熟悉的技術中，這個評估幾乎變得沒有意義，因為幾乎都是 AI 改比較快。越常讓 AI 來改，就越加不可能出現自己改比較快的情況。
或許看起來有一些負面影響，但我想這應該就是趨勢，單一任務或許 AI 做起來比較慢，但是 AI 可以同步執行多個任務，理論上來說應該會增加生產力（前提是任務沒有相依）。
AI 削弱了開發人員自己實作的能力，但是也開啟工作同步執行的能力。就像手工製作與工廠生產，單一機器的效率中難以跟真人匹敵，但是大量機器 24 小時同時運轉就不是人類可以比較的。
只有一個 AI 不夠
在開發的過程中，碰到一個問題：打包 macOS 應用程式失敗。在本地端打包都沒什麼問題，但是上 CI 打包建置卻一直出錯。由於 Cursor 並無法直接讀到 Github Action 的結果，所以只好手動貼錯誤給 Cursor（或許現在有 MCP 能做到了？），請 Cursor 修復 Github Workflow 腳本。
但即便如此，Cursor 還是一直鬼打牆，無法真正的解決問題。最後只好把 Github Workflow 腳本、Github Action 錯誤，再加上我想做的事情的 Context 通通整理貼到 Claude 與 Gemini 去問，而且兩者的回答還都不同，只好自己交叉比對結果與實驗，最後才讓打包工作能在 CI 上完成。
讓 AI 自動改 Code 非常方便，但也意味著她也只選擇一種方向來處理，方向是對是錯，是好還是壞，還是得要依靠人的判斷。
免不了，也快不了的學習
本想靠著 AI 實際做個東西，藉此在開發的過程中快速學一門新技術，但事後看起來還是有一定的極限，沒有想像中的這麼美好。
Electron 線程的坑
最初是這個工具只有使用 Electron，而沒有 React，程式也是在 Electron 中啟動 Playwright 腳本。後來加入 React 之後，想把啟動 Playwright 腳本的工作也搬到 React 中，卻怎麼一直都無法正常運作。幾過一番折騰才了解 Playwright 只能由 Node.js 啟動，所以只能放在 Electron 中，讓 React 跟 Electron 溝通呼叫腳本，無法放在 React 中。
這件工作也是來來回回請 AI 改了好幾次，每一次改就壞，過程中也出現奇奇怪怪的改法，看著都不太對勁。最後也是直接問了 AI 是否這個任務其實是有問題的，AI 才說了上面提到的問題（但也很有可能這結論也是錯的XD）。
AI 會盡全力滿足你的要求，即便這的要求不合理。如果沒有了人的判斷，可以想像如果開發時間一長，技術債會快速累積。
測試的難處
同樣的問題也發生在測試，自己對測試的概念還算熟悉，本來想模仿工作中測試方式，用比較大粒度的方式來測試這個工具。與常見小粒度的測試方式不同，可能訓練資料比較缺乏，所以無論我怎麼跟 AI 溝通，都得不到理想的結果。
原因可能是自己對技術的理解不夠，無法有效用該技術常見的用語與 AI 溝通，導致 AI 無法完成我想要的結果。另外一種可能是，這根本就是做不到的，但對這個語言與框架理解有限的我，也無法知道這件事。
即便使用了 AI ，我們還是得學習相關技術，否則既限制了上限，也會浪費許多時間。
下一步
最後，我已經對這個 Side Project 失去了興趣，暫時不會在這個 Side Project 上繼續 Vibe Coding。同時最近也從 Cursor 跳槽到 Claude Code，所以就趁這些轉變，回顧一下這半年的過程，總結一下 Vibe Coding 不熟悉技術的體驗。
但這終究不是現實的常態，現在對於大部分開發人員來說，工作中使用的還是自己比較熟悉的技術，只是需要摸索與 AI 如何共生。自己也打算開始另外一個 Side Project，這次會使用自己熟悉的技能模仿實際工作中的流程來 Vibe Coding，看看能否帶來開發上的改變。
小結
透過這次 Vibe Coding 的過程，感受到動口不動手的快感，但也更清楚感受到 AI 的限制。無論如何，AI 已經開始改變了開發人員的工作方式，既要放下成見，接受 AI 的結果，也要持續學習，不斷反思與改善這個過程。