舊系統不死，AI 讓它進化：不重寫也能持續成長

你的公司有一套跑了十年的系統。它能動，它撐起了整個業務，但沒有人敢碰它。文件不齊、邏輯散落在各處、原始開發者早就離職了。每次有人提議「重寫」，討論就會陷入沉默——因為大家心裡都知道，這條路走過很多次，沒幾次是成功的。

AI 的出現，讓這個困境有了新的解法。但不是你想像中的那種解法。

為什麼重寫這麼難？歷史給了殘酷的答案

軟體界有個著名的現象叫做 Second System Effect（第二系統效應），由《人月神話》作者 Fred Brooks 提出：工程師在重寫時，往往會把所有「本來想做卻沒做」的功能都塞進去，結果新系統比舊系統更複雜、更難維護。

但更根本的問題是：舊系統裡有隱藏的業務邏輯，它們沒有寫在文件裡，只存在於代碼的行為中——某個奇怪的判斷式、某個例外處理、某個只在特定情境才觸發的路徑。這些邏輯，是十年來無數個「為什麼這樣做？」的答案。

重寫計畫的典型失敗模式

• 兩個系統並行期拉太長：新舊系統同時維護，工程師精力分散，bug 在兩邊都出現
• 上線那天發現漏了邏輯：舊系統某個角落的行為，新系統根本沒有對應
• 商業壓力中斷重寫：計畫進行到一半，業務需求改變，只能把新舊系統黏在一起
• 重寫後反而更慢：新架構雖然「漂亮」，但少了十年累積的效能優化細節

這不是悲觀，這是現實。重寫不是不可能，但它的成功率遠低於大多數人的預期。在 AI 出現之前，面對舊系統，企業只有兩條路：硬撐，或者賭一把。

AI 帶來了第三條路：輔助成長

AI 最確定的價值，不是幫你重寫系統，而是讓「不重寫、持續演進」這件事變得可持續。

過去，舊系統的最大問題不是代碼本身，而是「沒有人理解它」。原始開發者離職了，知識沒有傳承；文件過時了，沒有人有時間更新；要改一個功能，必須花三天理解上下文，才敢動一行代碼。

AI 改變了這個方程式。

AI 能為舊系統做什麼？

挑戰	過去的困境	AI 輔助後
理解舊代碼	要花幾天甚至幾週閱讀	AI 幾分鐘內產出架構圖和流程說明
補充文件	沒時間寫、寫了也快過時	AI 根據現有代碼生成，每次修改後更新
補充測試	舊系統通常 0 測試，改動沒有安全網	AI 針對現有行為補寫測試，改動有保護
修復 bug	怕改了 A 壞了 B，只敢最小化改動	AI 追蹤影響範圍，降低連帶破壞風險
新人上手	要跟著老人學幾個月才敢動	AI 隨時解釋任何一段代碼的邏輯和背景
新增功能	不知道該插在哪裡，怕破壞現有邏輯	AI 建議最小侵入式的擴充點

實際做法：AI 如何輔助舊系統成長

第一步：讓 AI 讀懂系統，產出活的文件

不要急著改代碼。第一件事是讓 AI 理解現有系統，然後把理解結果固化成文件。

# 讓 AI 讀整個 codebase，產出架構說明
# 在 Claude Code 中，直接描述你的需求：

「請閱讀這個專案的所有代碼，並產出：
1. 系統架構圖（模組與模組之間的關係）
2. 核心業務流程說明（從使用者角度描述主要流程）
3. 高風險區域列表（邏輯最複雜、最不敢動的地方）
4. 技術債清單（有哪些地方明顯需要改善）」

這份文件不是給外部人看的，是給你的團隊每天使用的工作手冊。它會隨著系統改動而更新——這一點很重要，因為過去文件之所以沒用，是因為沒有人有時間維護它。AI 讓維護文件的成本降低了 90%。

第二步：為現有行為補測試，建立安全網

舊系統的問題不是「代碼爛」，而是「沒有測試保護」。任何一個修改都是在沒有安全網的情況下走鋼絲。

AI 可以閱讀現有代碼，理解它的行為，然後為這些行為寫測試——即使這些行為從來沒有文件。

# 範例：讓 AI 為現有函式補測試
「這個函式 calculateDiscount() 已經跑了八年，
請分析它的所有分支條件，為每個分支寫一個測試案例，
包括正常情況、邊界值和異常情況。
不要改動現有邏輯，只補充測試。」

有了測試，團隊才敢改動。改動有安全網，系統才能持續演進而不是不斷累積技術債。

第三步：最小侵入式地新增功能

新增功能不等於重構整個模組。AI 擅長找到「最小侵入式的擴充點」——在不動現有邏輯的前提下，把新功能插進去。

這個原則來自 Open/Closed Principle（開放封閉原則）：對擴充開放，對修改封閉。即使舊系統沒有遵循這個原則，AI 也可以建議如何在外圍包一層，讓新功能不影響舊邏輯。

第四步：漸進式現代化，而非大爆炸式重寫

如果真的有部分需要改善，AI 輔助的方式是：一次只動一個模組，改完之後讓它穩定跑一段時間，確認沒有問題再動下一個。

這不是「重寫」，這是「漸進式現代化」。兩者的關鍵差異：

	重寫	漸進式現代化
範圍	全部	一次一個模組
風險	集中在上線日	分散，每步都可以回滾
業務中斷	長期並行維護兩個系統	系統持續運作，局部更新
AI 的角色	「幫我重新實作這一切」	「幫我安全地改善這一塊」

那麼，「重寫」這條路呢？

這是一個需要誠實面對的問題。

過去的答案很清楚：重寫計畫成功率低，風險高，通常不是好選擇。大多數成功的案例，仔細看都是「漸進式替換」而不是「一次性重寫」。

AI 會改變這個答案嗎？

這是一個尚待驗證的命題。AI 確實讓理解舊系統更容易，讓知識遷移成本降低，理論上應該讓重寫的準備工作做得更完整。但「做得更完整的準備」不等於「執行時不會出問題」。隱藏的業務邏輯、時序問題、效能細節——這些在代碼裡只有在跑了幾百萬筆資料之後才會浮現。

更誠實的說法是：

• AI 讓「輔助成長」這條路變得可行——這是現在就可以驗證的事
• AI 讓「重寫」變得更安全——這是有可能的，但還需要更多實際案例來驗證
• AI 能取代「漸進式替換」的謹慎原則——不太可能，這個原則的價值在於限制風險暴露，而不是技術能力

所以，如果有人告訴你「有了 AI，重寫就不危險了」——保持懷疑。如果有人告訴你「AI 讓你不需要擔心舊系統的技術債了」——同樣保持懷疑。

如何判斷你的系統需要什麼？

面對舊系統，用這個框架來判斷方向：

優先考慮 AI 輔助成長，如果：

• 系統仍然在提供商業價值，只是難以維護
• 核心業務邏輯複雜，沒有人完整理解
• 團隊規模小，無法支撐兩個系統並行
• 業務需求變化頻繁，不能停下來等重寫完成

可以考慮漸進式替換（不是重寫），如果：

• 某個模組已經明顯成為瓶頸，且邊界清晰
• 有足夠的測試保護現有行為
• 可以部署影子流量，讓新舊模組並行驗證
• 有明確的回滾機制

謹慎考慮大規模重寫，只有當：

• 現有系統在技術上已經無法繼續擴充（不只是難，而是真的不可能）
• 有足夠的資源支撐至少 18 個月的並行期
• 有完整的行為規格文件（或 AI 幫你產出的等效文件）
• 組織願意接受在過渡期期間功能停滯

結語：舊系統不是問題，缺乏支援才是

回到最初的問題：那套跑了十年的系統，它的問題不是年齡，而是孤立。沒有人理解它，沒有測試保護它，沒有文件說明它，改動它需要承擔巨大的個人風險。

AI 能做的，是讓這個系統不再孤立。它可以成為每個工程師的「老前輩」——隨時解釋任何一段邏輯，隨時分析改動的影響，隨時生成測試保護現有行為。

這不是重寫的故事，這是陪伴成長的故事。

至於重寫——如果未來真的需要，AI 會讓你準備得更充分。但那是另一個故事，而且它的結局還沒有寫完。