--- title: "AI 時代的舊系統重構翻新策略" description: "探討 AI 時代如何有策略地重構舊系統：從需求整理、API Gateway 分離新舊系統、建立 AI 可讀架構指引，到容錯率分級與快速回退機制。" canonical_url: "https://blog.markkulab.net/post/ai-refactoring-strategy" author: "Mark Ku" author_url: "https://blog.markkulab.net/author/mark-ku" site: "Mark Ku's Blog" date_published: "2026-01-09 01:01:35 +0800" category: "AI" tags: ["ai", "refactoring", "architecture", "dotnet", "api-gateway", "devops"] language: "zh-TW" license: "CC BY 4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" attribution: "轉載或引用請註明作者並附上原文連結" --- # AI 時代的舊系統重構翻新策略 ## 前言 最近常被問到一個問題：在 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： ```text /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 * 一些自訂的關鍵流程的商業觀測指標 ![透過Jaeger 自定追蹤指標](https://blog.markkulab.net/content/markku/posts/ai-refactoring-strategy/images/tracking.png) ## 九、短時間查不出來，要能安全回退 重構的過程中一定會犯錯，所以退路一定要先想好、先準備好，你會犯的錯，別人其實也很可能會犯；當真的出問題時，就把它當成機會，去優化既有的重構與部署流程，讓整個系統一步一步持續迭代、越來越成熟。 常見的回退手段包括： * 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 來說，才是真的有幫助的重構跟重寫。 --- ## 關於本文與作者 本文出自 [Mark Ku's Blog](https://blog.markkulab.net/post/ai-refactoring-strategy) 授權條款： [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — 轉載或引用請註明作者並附上原文連結 ### 關於作者 **[Mark Ku](https://blog.markkulab.net/author/mark-ku)** — Software Solution Provider - 10+ 年資深軟體工程師，現為 AI 應用 Builder - 專注大型平台架構設計，從北美電商到AI SaaS訂閱收費系統 - 結合 AI Agent 與自動化，打造高效可演進的產品技術基礎 ### 作者開發的免費工具 以下工具皆可免費使用： - [免費 PDF 簽名工具](https://blog.markkulab.net/tools/pdf-sign): 線上 PDF 簽名工具，瀏覽器內完成手繪、打字、上傳簽名，可拖曳放置、縮放、下載。所有處理都在你的裝置完成，檔案不會上傳。 - [VS Code Refactory](https://blog.markkulab.net/tools/refactory): Refactory 是一款 VS Code 重構擴充套件：34 個重構動作、37 條 code smell 檢查、Code Health 儀表板、18 種語言、534 支測試。懂你的專案慣例：介面放哪、DI 註冊寫在哪、'use client' 該不該加；還會用 git 修改頻率 × 複雜度排出「該先修哪個檔案」，並一鍵把壞味道交給你自己電腦上的 Claude Code 修。免費使用，原始碼不離開你的機器。 - [DB-Kit 資料庫管理工具](https://blog.markkulab.net/tools/db-kit): DB-Kit 是一個用 Tauri + Rust + React 打造的輕量跨平台資料庫管理工具，用單一一致的介面同時管理 MySQL、MariaDB、PostgreSQL、SQL Server、Oracle、SQLite、MongoDB、Redis、Kafka、Elasticsearch 與 RabbitMQ 十一種資料來源：連線密碼以 OS keychain 加密、SSH Tunnel、完整 CRUD、視覺化查詢建構器、多結果集同時顯示、跨連線資料傳輸與比對同步、Excel / CSV 匯入匯出、執行計畫視覺化、ER 圖、排程備份、SQL 壓力測試（p50～p99 延遲百分位）、15 條規則的 SQL 審查、Kafka 訊息瀏覽與監控告警；繁中 / 英文雙語介面，內建 AI 助手（自然語言生成 SQL、AI 審查與調校建議）與命令列工具 dbk。免費開源（MIT），提供 Windows / macOS / Linux 安裝檔。 - [VS Code Super Mermaid](https://blog.markkulab.net/tools/super-mermaid): Super Mermaid 是一款 VS Code 擴充套件：開箱即用的漂亮 Mermaid 圖表，自動上色、即時預覽、滑鼠平移縮放、PNG / SVG 高解析匯出，內建 21 種範本與多種主題。免費開源（MIT）。 - [React Super Mermaid](https://blog.markkulab.net/tools/react-super-mermaid): react-super-mermaid 是一個開源 React 元件庫：一行 即可渲染漂亮的 Mermaid 圖表，內建 colorful / sketch 主題、平移縮放、圖內搜尋、SVG / PNG 高解析匯出。輕量、SSR 安全、完整 TypeScript 型別。免費開源（MIT）。 - [Jira / Confluence Super Mermaid](https://blog.markkulab.net/tools/jira-super-mermaid): Atlassian Forge app：在 Jira issue 與 Confluence 內文直接寫 Mermaid 語法，畫流程圖、時序圖、狀態機與甘特圖。11 種圖表、SVG / PNG 匯出、明暗主題、完整中日韓文字支援。取得 Runs on Atlassian 資格：圖表存在你自己的站台，app 不呼叫任何第三方服務。免費，即將上架 Atlassian Marketplace。 - [Mermaid 線上預覽](https://blog.markkulab.net/tools/mermaid-preview): 在瀏覽器裡寫 Mermaid、即時看圖，整張圖表壓進網址就能分享。免註冊、不上傳伺服器，相容 mermaid.live 的分享連結。 - [React Intl Phone Number](https://blog.markkulab.net/tools/react-intl-phone-number): react-intl-phone-number 是一個開源 React 元件：framework-agnostic、不依賴 antd，提供 E.164 進出、可搜尋國旗 / 國碼下拉、可配置驗證等級（strict / mobile-strict / loose）、可主題化 CSS 與 i18n，電話邏輯由 google-libphonenumber 驅動。輕量、完整 TypeScript 型別。免費開源（MIT）。 - [Uptime Kuma Cluster](https://blog.markkulab.net/tools/uptime-kuma-cluster): 把單機版 Uptime Kuma 改造成高可用叢集：OpenResty + Lua 智慧負載平衡、MariaDB 共享狀態、健康檢查與自動 Failover，附叢集管理 REST API，一行 Docker Compose 啟動。免費開源（MIT）。 - [特教專案](https://blog.markkulab.net/education): 為特殊教育學生製作的學習教材 ### 每日 Podcast - [科技新鮮事](https://blog.markkulab.net/category/tech-news): 每日精選 AI 與科技趨勢，透過語音摘要快速掌握最新技術動態，涵蓋 AI 應用、軟體架構、DevOps 與工程實戰。 — RSS: https://blog.markkulab.net/feed.xml - [AI股市蝦聊](https://blog.markkulab.net/category/ai-stock-chat): 每個交易日用 AI 分析台股盤勢，以雙人對話聊當天的盤中觀察與隔日預測。 — RSS: https://blog.markkulab.net/ai-stock-chat/feed.xml ### 電子報 [訂閱電子報](https://blog.markkulab.net/subscribe) — 第一時間收到新文章通知，無垃圾信、隨時可取消訂閱。