那些年我想重構卻動不了的專案，AI 只花幾個小時就幫我搞定了

這是一個我多年前在職訓局上課時寫的番茄鐘小專案。檔案裡藏著許多現在看來有些「青澀」、甚至讓人想扶額的程式碼。這幾年來，我心裡一直有個聲音想把它徹底重構，但每次打開專案、評估完那龐大的時間成本後，就又默默地把它埋回 GitHub 的角落。

大約半年前重構的念頭又冒了出來，起因是我常常收到 GitHub 的信，通知我這個專案的依賴太舊了要處理，這讓我覺得很煩。但說實話，半年前的 AI 工具（像是 Claude Code）對我來說比較像是在「輔助開發」，我還是需要掌握很多框架與配置的知識。

那時我評估，即便有 AI 幫忙，我也沒心力把 Vue 2 升級到 Vue 3。即便我具備一些 Vue 3 的知識，但不見得 AI 寫出來的東西不需要我 debug。我預期自己還是得進到程式碼裡去看他寫得如何，改完可能也要花上一整週，所以當時就作罷了。

直到最近，我換了 Codex 的 gpt-5.3 模型來嘗試重構看看，發現感覺完全不一樣。現在的 AI 不只是理解力變好了，連做事的準確度也提升許多。更重要的是， Skills 的設計真的解決了以前 LLM 常亂猜 Best Practice 的問題。

這一次，我幾乎沒碰到程式碼，只測試 AI 改完的東西，花了幾個小時就把整個專案遷移完了。因為這次重構的體驗太好了，想特地記錄下來我怎麼做到「一行程式碼都沒碰，就完成了 Vue2 升級 Vue3 的重構」。

重構第一步：別急著寫 code，先拉齊認知

每次開發最怕的就是 AI 沒搞清楚狀況就動手。以前的經驗是，如果直接叫它「幫我把專案改成 Vue 3」，它產出的計畫往往會太發散，甚至會預設一套企業級的複雜架構。

我認為要先讓 AI 徹底了解專案，我們才有足夠的 Context 繼續討論。我跟 Codex 協作的步驟大致如下：

• **先產出 spec.md**：我先請 Codex 掃一遍整個專案，把目前看到的所有功能、細節先寫成一份規格文件。我們要先把「AI 認為的功能」跟「實際上的功能」對齊。
• 明確技術棧：告訴它我要遷移到 Vue 3 + Tailwind CSS 4，並要求用輕量的 icon 庫取代原本的圖片以降低打包大小。
• 安裝對應的 Skills：我在 skills.sh 找了對應的工具，裝了 vue-best-practices、tailwind-design-system 等。安裝好這些 Skill 後，AI 就比我還像個經驗豐富的工程師。
• 產出遷移計劃：講完需求後請他做遷移計畫。中間他把計畫做得太大、太細節了（有很多多人協作的內容），我補了一句：「這只是我個人的小專案，不需要考慮協作。」他立即把計畫改成簡易版，甚至還自動幫我加了 Playwright 做 E2E 測試來當驗收標準。

等到計畫確認沒問題後，我就請他按照計畫開始重構，做完再叫我。 整個過程我就只是在旁邊看 Codex 表演，做完後試了一下，所有功能都完整遷移成功了。（如果你好奇這中間具體改了哪些程式碼，可以參考這份實測的 Pull Request）

讓 AI 幫我重新切版

專案遷移成功後，我看著這份五、六年前的 UI，覺得越看越醜。但我手上沒有設計稿，也不想自己慢慢調整 CSS。

於是我又去裝了 frontend-design 的 Skill，請它評估現有介面可以改進的地方，並直接調整樣式。結果非常理想，在沒有設計稿的情況下，我不需自己發想切版，它就自動優化了整體的視覺平衡與質感。

一行程式碼都沒碰，那前端工程師的價值在哪？

這次做完最讓我有興奮的是，我真的從頭到尾一行程式碼都沒碰，就把這份五六年前的舊專案翻新了。

我體驗到的是，現在我不一定要有 Vue 3 的開發經驗，只要我能把 Context 給清楚，並且知道怎麼引導 AI 去思考、安裝正確的 Skills 去輔助他。即便這是一個我好幾年沒碰的舊專案，一樣能在幾個小時內重構完。

這讓我開始思考，以前工程師的價值在於 程式設計（Coding）的能力 ，但經歷這次重構，我認為現在更重要的價值反而轉向了：

• 你對框架的了解：知道什麼技術適合專案，才能選對技術棧。
• 技術選型與 Skills 的組合：決定要遷移到哪裡、使用哪些工具與 Skills。
• 與 AI 的溝通能力（Context 管理）：如何把專案背景、開發限制精確地傳達給 AI。