AI 輔助遺留系統現代化的經驗分享

- 講者：James Wang
- 主題：AI 輔助遺留系統現代化
- 日期：2026/06/25
- 活動：DevOpsDays Taipei 2026
- 參考連結：https://devopsdays.tw/2026/session/4721

--

在 DevOps 的世界裡，我們總夢想著順暢的 CI/CD 與清晰的服務邊界。

然而現實中，多數團隊每天面對的是另一種處境：龐大、缺乏文件、牽一髮動全身的遺留系統。

不敢改、不敢推、不敢重構——不是能力問題，而是看不清楚。

這場演講來自第一線的實戰經驗。

我們發現 AI 在遺留系統現代化中真正的價值，不是幫你生成更多程式碼，而是大幅壓縮「從零到看懂」的成本——解讀沒有文件的業務邏輯、還原隱性依賴、找出真正的邊界。能見度有了，現代化才有起點。

我們會直接分享具體的使用場景與做法，也會誠實說 AI 在哪裡幫了我們、在哪裡讓我們踩了坑。

不談趨勢，分享經驗，只談你明天就能帶回去用的東西。

Transcript

1. 01 DevOpsDays Taipei 2026 / 25 min AI 輔助遺留系統現代化 經 驗 分 享 面對混沌不清的祖產，不是重寫系統，而是重建理解。 如何找回系統的 WHY？ James · Senior Engineering Lead · 2026
2. ! DISCLAIMER / 免責聲明 免責聲明 本次分享內容僅代表個人經驗與觀察，屬於個人的經驗談。 技術架構與情境各異，相關做法不一定完全適用於你們環境和場景 ，請斟酌參考。 James · Senior Engineering Lead · 2026
3. 0 PROLOGUE / 開場 先帶各位去一個地方 公司的對帳服務 公司開出一筆應收帳款 客戶匯款進來 財務在系統上把錢和帳「沖銷」掉 就這樣。 03 / 46
4. 0 PROLOGUE / 開場 但實際上呢 ? 少 付 要走催款流程 多 付 不退，自動折抵下一期 分 期 一筆帳，客戶分五次匯款 併 帳 一次匯一大筆，拆到多筆帳 十年下來，那個沖銷模組變成什麼樣子？ 04 / 46 我相信在座每一位都看過類似的東西。
6. 0 PROLOGUE / 開場 我們要重寫這個系統 第一步是什麼? 看懂它。 結果： 整個團隊，沒有一個工程師 看得懂那堆判斷路徑。 06 / 46
7. 0 PROLOGUE / 開場 程式看不懂，問人總可以吧？ 我們去找財務。 「前人有交辦一些特殊場景。 但我接手的時候就是這樣了， 我說不清楚。」 — 年輕的財務同仁 07 / 46
8. 那一刻我意識到—— 這個系統的知識， 已經不存在於 這間公司了。 程式碼裡有，但很難讀得懂。 人腦裡，已經沒有了。 08 / 46
9. 0 PROLOGUE / 開場 這個故事，有一個結局。 而且是我整場演講最想講的東西。 「但我把它留到最後。」 我們先回答一個問題： 為什麼會走到這一步 ? 09 / 46
10. ACT Ⅰ Ⅰ 不透明 才是失敗的根因 3 – 6 min 10 / 46
11. Ⅰ ACT Ⅰ / 不透明 遺留系統現代化的失敗率 高得嚇人。 不是 「不知道怎麼重構」 是 不 透 明 技術上我們都會 ─ strangler fig、ACL、抽象分支，書都寫得很清楚。 11 / 46
12. Ⅰ ACT Ⅰ / 不透明 不透明的三種樣貌 01 沒有文件 或者，文件停在五年前。 02 原作者離職 知識，跟著人一起離開。 03 沒人敢動 因為不知道動了會壞什麼。 12 / 46
13. Ⅰ ACT Ⅰ / 不透明 注意最後一句的結構 引用 「不知道會壞什麼」 核心 問題不是「會壞」，而是—— 不 知 道 。 看不清楚的時候，任何改動都是賭博。理性的工程師選擇不動。 於是，現代化計畫永遠停在簡報裡。 13 / 46
14. Ⅰ ACT Ⅰ / 不透明 程式碼還在，但組織對它的理解，已經蒸發。 AI 時代的殘酷事實 這筆債，正在加速累積。 14 / 46 業界給這個現象起了名字 Comprehension Debt 理 解 債 延伸參考資料 AI 寫得更快， 你真的懂嗎？ DDDTW Meetup James - 2026.04
15. ACT Ⅱ Ⅱ AI 改變的 是理解的成本 6 – 10:30 min 15 / 46
16. 整場核心命題(上半句) AI 的真正價值， 不是幫你現代化系統。 是讓你第一次看清楚， 你的服務，到底是什麼。 16 / 46
17. Ⅱ ACT Ⅱ / AI 改變理解 為什麼說「第一次」 ? 在 LLM 之前，「看懂十年陌生 codebase」這件事—— 成本高到等於不可行。 從前的選項 找原作者 (但通常早已離職，或是忘光了) 資深工程師硬 啃 往往需要 3 個月 以上的專注時間 現在 一個 AI agent  幾小時內掃完整個模組  產出可讀的行為清單 17 / 46
18. Ⅱ ACT Ⅱ / AI 改變理解 然而 AI 有一個關鍵限制 不然剛剛那句話就變成廠商話術。 AI 讀得出 what 這段程式在： 「多匯款時不退費、自動折抵下期」 AI 讀不出 why 背後動機： • 法務要求？財務習慣？ • 客訴後的補丁？ • 這個 AI 不知道 What 在程式碼裡。 Why 在已經離職的人腦裡。 18 / 46
19. Ⅱ ACT Ⅱ / AI 改變理解 理解迴圈 ─ 三步工作流 01 讓 agent 產出「行為清單」 用 domain 看得懂的語言，而非架構圖 02 把清單當「訪談議程」帶去找 domain expert 不是「請你回憶」，而是「請你確認與質疑」 03 寫成特徵測試 (Characterization tests) 舊系統行為的快照，從此可機械驗證 19 / 46
20. Ⅱ ACT Ⅱ / AI 改變理解 01 讓 Agent 產出「行為清單」 它不是工程師才看的架構圖， 而是用財務/業務看得懂 的語言所描述的規則與具體案例： 本系統目前處理以下沖銷情境： 少付 → 自動觸發催款通知 多付 → 不退費，自動折抵下一期帳單 一帳多匯 → 累計沖銷，差額仍依規則處理 一匯多帳 → 依備註拆分，無則由財務指派 20 / 46
21. Ⅱ ACT Ⅱ / AI 改變理解 01 如何實務產出「行為清單」？ 透過六大訊號源交叉定位（掃描），並將共識即刻流向驗證機制（沉澱） SIGNAL 01 對抗性對話 AI 掃描程式碼後，雙方互為對手、 展開嚴格質疑 。AI 必須指明具體 Code 行數，拒絕腦補，從中逼出精 確推測。 SIGNAL 02 動態驗證 在關鍵路徑埋設 Log，將 AI 的靜態 推測與真實執行路徑交叉比對 ，專 注排除自信而無流量的死分支。 SIGNAL 03-06 其餘多源定位 資料/Git考古：以真實資料與歷史 Git 補 足 Why 的背景。 多模型比對 ：抓出模型間的分歧點。 反向探針 ：故意餵錯，戳出隱性漏洞。 STEP 2 共識沉澱與分流落地 ─ 每一條共識，都帶著自動驗證的意圖記錄 決策類共識 ➔ 落地為 ADR 決策紀錄 探討 Why 層級的核心，並且強力追問：「此決策能否轉成 CI 中的 ArchUnit 測試或 lint rule 守護？」 需求類共識 ➔ 落地為 Given/When/Then 行為規格 轉化為高可讀性的規格書， 直接作為第三步「特徵測試 (Characterization tests)」的測試設計圖。 21 / 46
22. Ⅱ ACT Ⅱ / AI 改變理解 02 把清單當「訪談議程」 整個流程的靈魂——問題的形態被改變了: 從前 「請你回憶—— 前人交辦了什麼?」 (她沒經歷過, 答不出來) 現在 「請你確認 —— 這條規則, 現在還需要嗎 ? 為什麼?」 (看著清單做選擇, 容易多了) 程式碼記得所有事。AI 翻譯成人話。人負責質疑它。 22 / 46
23. Ⅱ ACT Ⅱ / AI 改變理解 03 固定成「特徵測試」 確認過的每一條規則 → 一條測試。 這份測試組合，就是舊系統的「行為快照」。 這一段最重要的觀念 這三步的產出，不是文件， 是驗證機制。 文件會再次過期，變成下一代的理解債。 測試，每天活在 CI 裡。 23 / 46
24. ACT Ⅲ Ⅲ 你敢放手 讓它跑嗎？ 10:30 – 17:30 min 24 / 46
25. 這個月有個爆紅的詞 Loop Engineering 別再手動 prompt，設計會自己跑的 loop。 行動 看回饋 修正 目標 上下文 達成目標 後離開 我們的現代化流程，本質上也是這樣：各種小 loop 串成大 loop。 但 legacy 場景，跟寫新功能有一個根本性的差異。 Ⅲ ACT Ⅲ / 授權邊界 25 / 46
26. Ⅲ ACT Ⅲ / 授權邊界 Loop 要能自己跑，前提是—— 環境會說真話。 實質的技術基礎 有測試、有 Compiler、有 Lint。 失敗了，訊號自己跳出來。 這個「會說真話的機制」，它叫 Oracle 驗證機制 — 它告訴 loop 對與錯， 讓 loop 知道何時該停。 遺留系統的定義，幾乎就是 —— Oracle 不存在。 26 / 46
27. Ⅲ ACT Ⅲ / 授權邊界 Legacy 現代化裡的兩種 loop 理解迴圈 Comprehension Loop 核心是對齊想法，產出 oracle 本身 • 人為介入很重 • Ground truth 只在人身上 人進到 in the loop ~ 不是在監督 AI 在「供給答案」 。 執行迴圈 Execution Loop 有 oracle 之後才開跑 • 重構 · 搬遷 · 換語言 • 每一步可自動驗證 人退到 on the loop ~ 看 sensor 有沒有攔到的就好。 千萬不要把兩種 loop 混為一談。 27 / 46 90% 10% 
28. Ⅲ ACT Ⅲ / 授權邊界 沒有 Oracle 的 AI 開發，只是在加速未知風險 AI 可以幫助我們動手，但我們要先定義什麼叫做安全地動手。 Architecture Gate 檢查方向對不對？邊界有沒有破？設計 有沒有走偏？ • 是否符合 Bounded Context？ • 是否引入新的耦合？ 是否需要 ADR / RFC？ • 業務規則的語義完整性？ Development Gate 實作有沒有完成？品質有沒有證據？能 不能安全合併？ • 測試是否覆蓋關鍵情境？ 既有行為是否被保護？ • 是否通過效能和資安基線檢核？ • 程式碼可維護性與複雜度 行為驗證與品質驗證缺一不可。若無「可自動化」的檢核，開發速度越快，災難越深。 28 / 46
29. 如果你今天只帶走一個原則—— Ⅲ ACT Ⅲ / 授權準則 檢核點密度， 與 Oracle 強度成反比。 ✘ 沒有機械可驗證的訊號 → 人必須在。 ✔ Oracle 蓋好的地方 → 才能放手。 這就是「能授權多遠」的可操作答案。 29 / 46
30. 不是... 「轉換了幾行 COBOL / Java」 (這個指標自欺欺人) 而是！ 人工檢核點 被機械 oracle 取代的速度。 Ⅲ ACT Ⅲ / 授權邊界 「現代化進度」也有了誠實的量法 你也在漸進式絞殺「人是唯一驗證者」這個角色。 30 / 46
31. Ⅲ ACT Ⅲ / 授權邊界 一定有人在想—— 「現在的轉換工具， COBOL → Java 的準確率 都標榜 93% 以上了 還需要搞這麼多前置理解嗎？」 我有兩個回答。 31 / 46
32. Ⅲ ACT Ⅲ / 授權邊界 回答一 轉換準確率 ≠ 行為等價 更尖銳的是—— 沒有 Oracle 你連那 93% 是哪 93% 都不知道。 剩下的 7%,藏在「多付不退、折抵下期」這種沒寫在任何文件的規則裡 32 / 46
33. Ⅲ ACT Ⅲ / 授權邊界 回答二 結構性的坑，不會被工具解掉。 事實 模型確實一直變強。自動轉換準確率確實一直上升。 觀望 「再等等，等模型夠強就能全自動」——可以理解。工具性的坑，每季都在被解。 關鍵 但 oracle 缺席是結構性的坑。 模型再強，也無法驗證一個沒有任何人定義「對」的系統。 33 / 46
34. Ⅲ ACT Ⅲ / 授權邊界 自動化的上限，永遠是—— 你還能為產出背書的那條線。 越過那條線，你得到的不是效率 — 業界給它取了個名字 Agent Slop 一堆你不敢上 production 的東西。 34 / 46
35. ACT Ⅳ Ⅳ 回到那個系統 結局推翻了一切的預設前提 17:30 – 22:00 min 35 / 46
36. Ⅳ ACT Ⅳ / 結局 我們照剛才的流程做了 • Agent 掃出行為清單 • 找財務一條一條確認 • 準備固定成特徵測試 • 接下來建 oracle、開執行迴圈、重寫 照劇本演下去，沒有意外。 但是—— 36 / 46
37. 在跟那位財務一條一條過清單的時候， 有人問了一個問題： 「等等—— 這些情境, 為什麼會存在 ?」 37 / 46
38. 我們把清單攤開來看 這幾十條 if-else, 全部指向同一個源頭。 這座 if-else 叢林, 不是業務邏輯。 是 補 償 邏 輯。 38 / 46
39. Ⅳ ACT Ⅳ / 結局 補償什麼？ 補償上游的「匯款訊號模糊」。錢進來那一刻，系統不知道是誰、要沖哪筆。 答案是 虛 擬 帳 戶 代價 付錢給銀行 收穫 見下一頁。 39 / 46
40. Ⅳ ACT Ⅳ / 結局 收穫—— 那幾十條 if-else 全 部 刪 除 不是重構。不是翻譯成新語言。 是 刪 除。 連同那一整套幫財務日常對帳的報表，全部不再需要存在。 40 / 46
41. Ⅳ ACT Ⅳ / 結局 一個思想實驗 如果我們把這個對帳系統, 丟給世界上最強的 coding agent 會發生什麼 ? 它會表現得無可挑剔—— • • 完美理解每一條 if-else • • 產出完整測試 • • 100% 行為等價地翻譯成乾淨的新架構 然後我們會得到 41 / 46
42. 一個用新架構新語言寫的、 測試覆蓋率 100% 的、 同樣不該存在的系統。 Agent 在框架內最佳化。 只有人能否定框架。 42 / 46
43. Ⅳ ACT Ⅳ / 結局 Keep It Simple 回到問題的本質去思考，而不是被既有的東西綁住 只重寫 20% 的核心高頻 罕用分支怎麼辦？ 先放著。等它真的出錯時，再去修補即 可。 我們在對抗什麼？ 對抗「偽需求」。那些從未被觸發的程式 碼，不該占著維護成本。 Simplification is the ultimate sophistication. 砍掉沒人用的功能，才是最好的重構。 43 / 46
44. ★ FINALE / 結尾 順帶一提 這個結局也回應了 Oracle。 虛擬帳戶之後 對帳變成一對一的確定性對應。 自動化驗證 連驗證，都變得簡單。 最好的 Oracle， 是你不再需要的 Oracle。 44 / 46
45. ★ FINALE / 結尾 明天回到公司，不用申請預算就能開始—— Step 1 挑你最不敢動的系統， 挑其中一個模組。 Step 2 讓 agent 產出一份「行 為清單」。 Step 3 帶著它，找 domain expert，一條一條 問—— 「這條規則，現在還需要嗎？為什麼？」 便宜、安全，不動任何生產程式碼。開始累積你的第一批 oracle 素材。 45 / 46
46. 看清楚之後 , 決策才能發生。 而最高級的決策 是 刪 除。 Thank you · James · 2026 ★ FINALE / 結尾 回顧今天：看不清楚的時候，沒人敢動，現代化停在簡報裡； AI 讓我們第一次看得清；看清之後沉澱成 Oracle，我們才敢授權 Loop 去跑； 而看得最清的那一刻，你會發現有些東西，最好的處置不是修好它。