前言

最近常被問到一個問題：在 AI 時代，舊系統到底要怎麼重構？乾脆就把這陣子的思考和做法整理成一篇文章。

一、AI 加速開發，也加速風險

Vibe Coding／AI Pair Programming 確實可以把軟體生產力放大好幾倍，但同時也可能把 Bug、技術債和系統複雜度（多出來的程式碼、過度設計）一起放大。如果發生重大系統錯誤，最後還是得回到工程師來接手，因為許多程式碼不是自己一行一行敲出來的，出問題時也沒這麼容易一眼看出到底哪裡壞掉。

因此，在 AI 時代談重構，更需要的是「讓系統變得可理解」，而不是單純追求「產生更多程式碼」。

二、改寫之前：先確保有「餘裕」

以過去一次重寫系統的經驗來說，前後其實都是同一組人在開發，舊系統的核心功能一邊持續出問題、一邊又不斷有新需求進來，導致開發資源被來回拉扯，結果整整花了將近一年半的時間，只是在讓舊系統的需求收斂與穩定，把需求邊界畫清楚，團隊才真正有餘裕開始談改寫。

P.S. 以下是我整理一些做法，應依實際資源狀況與任務優先順序彈性調整

三、需求整理：先釐清再動手

在這樣的背景下，需求整理本身就變成一個關鍵工程，而不只是「寫寫規格」而已：

1. 全面盤點
   包含沒在用的功能、已知問題與潛在漏洞、業務端長期沒被滿足的清單、實際存在的使用場景、資源配額，以及各部門目前的權責範圍與角色邊界。

2. 重新設計，而不是照單全收
   針對盤點出來的項目，重新思考哪些值得留下、哪些需要調整，甚至哪些本來就不該存在，或是功能太大、必須延後滿足。

3. 讓不確定性浮出水面
   把原本處於 known unknowns 的事情主動攤開來討論，逐步轉換成已知、可掌控的風險與決策依據。例如:繪製出流程圖

4. 必要時重新定義流程
   有些問題的根源其實不在系統，而在工作流程本身，這時就需要有勇氣重新定義，而不是只靠技術硬撐。

P.S. 此部分感謝104的雷N 大大提供的觀點與提醒。

四、用 API Gateway 分離新舊系統

從技術角度來看，如果舊系統本身已有 API，可以先建立一層統一入口（API Gateway）：

所有請求不再直接打進舊系統 IP，而是先經過 API Gateway：

/api/v1/orders  -> 舊系統（Old System）
/api/v2/orders  -> 新微服務（New Microservice）

透過版本區分，把新舊系統藏在 Gateway 後面， 就能一個 API、一個 API 地遷移，而不是一次全部重寫。這樣可以逐步替代掉舊的 API，未來有新舊版本管理時，也會比較容易。

五、整理出讓 AI 看得懂的架構指引

重點不是文件寫多厚，而是邏輯與結構的一致性：

• 系統架構
• 資料庫結構
• 程式碼規範及風格
• 檔名命名與資料夾的放置規則
• 模組間的關係
• 資料流程圖 (Mermaid 就很適合讓 AI 了解)
• 單元測試怎麼寫

這些不只是寫給人看的，也是在幫 AI 建立「上下文」，在建構階段可以搭配工具強制約束：

• 前端透過 ESLint 把程式碼風格與統一。
• .NET 透過 Roslyn Analyzer 搭配 .editorconfig 把規範控管在建置流程裡。

這樣 AI 才不會「每次都幫你寫一種風格」，也比較能理解你真正想要的架構。

另外，關鍵的商業邏輯最好都有測試，範例要先由人把情境、input / output 整理好，再請 AI 協助產生或補齊測試，確保「同一組 input 永遠得到預期的 output」，風險才會相對最低。

六、盤點重構功能，決定 AI 介入程度

先把需要重構的功能列出來， 再依容錯率決定 AI 能走多遠：

• 高容錯：AI 可自動產生，人工抽查或大概的驗過。
• 低容錯：一定要人工審查、AI 只當輔助工具，即便上線也需要人去觀察幾天，或用監控工具來告警。

不是所有地方都適合全自動，有些地方就是要工程師一行一行看，或自己實際去測試。

七、把 AI 當 Code Reviewer

可以透過 AI 來進行 Code Review，讓 AI 先幫忙找問題、看風險、提建議，但最後的決策與取捨還是要由人來做，例如搭配 GitHub + Copilot 等工具，就可以在 PR 流程中自動觸發 AI Review，先幫你掃過一次潛在風險。
P.S. Cursor 也有類似的機制

八、真的出問題時，要能快速看見

當大多數程式碼是由 AI 產生時，團隊對系統細節的熟悉度通常不會太高。這時就得靠錯誤狀態碼和埋好的 log當成定位的錨點，來快速縮小問題範圍。

• 主動監控（定期發送 request或監控網站服務）：uptime-kuma
• 被動監控（有人使用，發現壞了或慢了）：Prometheus + Grafana 或利用Jaeger來監控自定義指標

至少要有幾個即時觀測指標：

• API error rate
• latency
• 一些自訂的關鍵流程的商業觀測指標

九、短時間查不出來，要能安全回退

重構的過程中一定會犯錯，所以退路一定要先想好、先準備好，你會犯的錯，別人其實也很可能會犯；當真的出問題時，就把它當成機會，去優化既有的重構與部署流程，讓整個系統一步一步持續迭代、越來越成熟。

常見的回退手段包括：

• Git 直接退版，重新建構容器或應用容器
• 在 API Gateway 上切回舊系統
• k8s rollback

十、從 WinForm 到 Web：操作體驗的遷移

WinForm 轉 Web，最大的挑戰不是技術，而是「使用者原本的操作習慣」，以前大家在 WinForm 上用 combo、快捷鍵，動作都很快、很直覺；改成 Web 之後，就要重新思考怎麼設計互動，才能讓使用起來一樣順、甚至更快。

• 快速選擇：使用 autocomplete，完整支援鍵盤操作（hot key）與焦點移動。
• 低延遲回饋：避免全頁刷新，採用一些前端框架，可以輕易到到不用整整刷新的體驗。
• 批次與快捷鍵：保留常用快捷鍵與批次操作能力，縮短操作路徑。
• 一致語意：沿用舊系統用語與流程映射，降低學習成本。

十一、響應式設計：Mobile-first 與 Tailwind CSS

現在多數人以手機瀏覽網站，設計通常從 Mobile First 出發，推薦使用 Tailwind；它以 Mobile First 為設計概念，且針對不同裝置與尺寸的情境，響應式 variants 與 utility classes 都設計完善，擴充也容易。

• 前台公開網站：以手機版為出發點，再往桌面版加強。
• 後台系統：後台功能往往很多，全部都做 RWD 成本會很高，除非是必要功能，否則可以只挑需要的部分做 RWD。
• 桌面系統：專注在密集操作的效率，貼近使用者日常的操作習慣。

感想

重構的本質，是降低系統的不確定性，如果結構複雜又缺乏一致性，那麼原本就很亂的系統，在 AI 的加持下只會被放大好幾倍地「變得更亂」，不是期待 AI 幫你重寫好一切，而是透過 AI 來協助處理定義清楚、邏輯明確的部分；當系統變得「可被理解」，不管是對工程師，還是對 AI 來說，才是真的有幫助的重構跟重寫。