前言
最近常被問到一個問題：在 AI 時代，舊系統到底要怎麼重構？乾脆就把這陣子的思考和做法整理成一篇文章+。
一、AI 加速開發，也加速風險
Vibe Coding／AI Pair Programming 確實可以把軟體生產力放大好幾倍，但同時也可能把 Bug、技術債和系統複雜度（多出來的程式碼、過度設計）一起放大。如果發生重大系統錯誤，最後還是得回到工程師來接手，因為許多程式碼不是自己一行一行敲出來的，出問題時也沒這麼容易一眼看出到底哪裡壞掉。
因此，在 AI 時代談重構，更需要的是「讓系統變得可理解」，而不是單純追求「產生更多程式碼」。
二、改寫之前：先確保有「餘裕」
以過去一次重寫系統的經驗來說，前後其實都是同一組人在開發，舊系統的核心功能一邊持續出問題、一邊又不斷有新需求進來，導致開發資源被來回拉扯，結果整整花了將近一年半的時間，只是在讓舊系統的需求收斂與穩定，把需求邊界畫清楚，團隊才真正有餘裕開始談改寫。
P.S. 以下是我整理一些做法，應依實際資源狀況與任務優先順序彈性調整
三、需求整理：先釐清再動手
在這樣的背景下，需求整理本身就變成一個關鍵工程，而不只是「寫寫規格」而已：
-
全面盤點
包含沒在用的功能、已知問題與潛在漏洞、業務端長期沒被滿足的清單、實際存在的使用場景、資源配額，以及各部門目前的權責範圍與角色邊界。 -
重新設計，而不是照單全收
針對盤點出來的項目，重新思考哪些值得留下、哪些需要調整，甚至哪些本來就不該存在，或是功能太大、必須延後滿足。 -
讓不確定性浮出水面
把原本處於 known unknowns 的事情主動攤開來討論，逐步轉換成已知、可掌控的風險與決策依據。例如:繪製出流程圖 -
必要時重新定義流程
有些問題的根源其實不在系統，而在工作流程本身，這時就需要有勇氣重新定義，而不是只靠技術硬撐。
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 來說，才是真的有幫助的重構跟重寫。
留言