**系列主題：**30 天實戰企業 Legacy System × AI 協作開發
**技術範圍：**Delphi × SQL Server × ChatGPT／Codex

接手一套運作十幾年的企業系統，最可怕的通常不是程式語言太舊，而是你不知道改下去會發生什麼事。

畫面看起來只是多一個按鈕，背後卻可能連動三張資料表、兩支預存程序與另一套簽核系統；使用者說「這裡的金額算錯了」，真正的問題可能藏在某個 AfterScroll、某段資料集篩選，甚至是十年前留下、沒有人敢刪的判斷式裡。

偏偏這類系統不能停，也不能因為程式舊就全部重寫。每天仍有人登入、開單、送簽、列印與結帳。維護者只能一邊理解，一邊修改，還要確保今天改好的功能不會在月底結算時突然爆炸。

這就是我每天面對的 Legacy System。

也是我想用 30 天回答的一個問題：

AI 真的能幫助工程師維護企業祖傳系統，還是只會很有自信地產生另一批更難維護的程式碼？

我維護的，不只是「舊程式」

我目前接觸的系統以 Delphi 與 SQL Server 為主，包含 ERP、採購、工程變更、簽核及列印等功能。它們有幾個很典型的特徵：

• 程式規模大，而且缺少完整文件。
• 商業規則散落在 Delphi、SQL、預存程序與 Trigger 中。
• 畫面事件彼此牽動，很難只讀單一函式就理解完整流程。
• 系統必須持續使用，無法停機後慢慢重寫。
• 很多「奇怪寫法」其實是在保護某個沒被記錄下來的歷史需求。

因此，維護舊系統真正困難的地方並不是語法。

看到一段 Delphi 程式碼，我可以查到 Locate、Filter 或 ApplyUpdates 怎麼使用；真正困難的是判斷：這段程式為什麼存在？資料從哪裡來？修改後會影響誰？如果第二次存檔失敗，第一次已經寫入的資料怎麼辦？

這些問題，光靠「幫我解釋這段程式」通常不夠。

為什麼要讓 AI 參與？

生成式 AI 出現後，寫程式的門檻似乎突然降低了。只要貼上需求，就能得到一段看起來完整的程式碼。

但在 Legacy System 裡，「能產生程式碼」可能反而是最不重要的能力。

如果 AI 不知道資料表關係、不理解既有交易邊界，也看不到呼叫端與後續流程，它產生的答案即使能編譯，也不代表能安全上線。最危險的程式往往不是明顯錯誤，而是平常看似正常，只有在多人同時操作、資料量變大或其中一步失敗時才出問題。

所以這次實驗中，我不打算把 AI 當成一位「自動寫完所有功能的工程師」，而會把它放在幾個更實際的位置：

1. 閱讀助手：整理事件流程、追蹤變數與資料集的來源。
2. 除錯夥伴：根據現象提出假設，再用程式與資料逐一驗證。
3. 風險檢查員：尋找交易不一致、例外處理、效能與多人操作問題。
4. 重構顧問：在不破壞既有功能的前提下，提出可逐步落地的改善方式。
5. 文件協作者：把散落在程式裡的商業規則，整理成人能閱讀的說明。

換句話說，我要測試的不是「AI 會不會寫 Delphi」，而是：

AI 能不能幫助一位維護者，更快建立正確的系統模型，並做出風險較低的修改。

這 30 天會怎麼進行？

整個系列會沿著一條實際的維護路徑前進：

理解 → 保護 → 小改 → 驗證 → 重構

第一階段：理解系統

我會從接手陌生專案開始，討論如何找入口、追事件、辨認資料流，以及怎麼提供足夠的上下文，避免 AI 只根據局部程式碼亂猜。

第二階段：除錯實戰

例如畫面卡住、金額沒有重算、資料集游標跑掉、刪除後發生 Access Violation，以及輸入一個字就重新查詢等問題。我會把 AI 提出的推論與真正原因放在一起比較，不只展示最後答案。

第三階段：資料與商業邏輯

這個階段將處理 SQL、資料一致性與商業邏輯。企業系統最棘手的 Bug，常常不是某一行寫錯，而是兩次更新之間沒有共同的交易保護，或前端與資料庫各自認為自己才是規則的主人。

第四階段：驗證與重構

最後回到工程方法：哪些舊程式適合小幅重構、哪些應先補測試與紀錄、哪些問題應移到資料庫處理，以及 AI 產生的修改該如何審查，才能避免「修好一個 Bug，又生出兩個新 Bug」。

每篇文章都會盡量聚焦一個具體問題，包含：

• 問題發生的情境
• 我如何拆解與提供上下文
• AI 給出的判斷與可能盲點
• 實際驗證方式
• 最後採用的修改
• 可以帶走的檢查清單

關於真實案例與程式碼

系列中的案例來自實際維護經驗，但不會直接公開公司原始碼、帳號、客戶資料、資料庫連線資訊或可識別的業務內容。

畫面名稱、資料表、欄位與部分流程會視需要改名或簡化；程式碼只保留足以說明問題的最小片段。這樣做不只是資訊安全考量，也能讓文章把焦點放在可重複使用的解題方法，而不是某一套系統的特殊細節。

我也不打算為了讓文章看起來厲害，就硬塞一個龐大、實際上沒有人會執行的範例專案。能用小型範例重現的問題，我會提供範例；無法完整公開的案例，則會清楚交代前因後果、判斷依據與驗證方式。

畢竟 Legacy System 的價值從來不在程式碼有多漂亮，而在於它承載了多少真實流程，以及我們能不能在理解不完整的情況下，仍然做出負責任的修改。

我希望 30 天後得到什麼？

我不期待用 30 天證明 AI 可以取代維護工程師。剛好相反，我更想找出人必須負責的部分。

AI 可以快速閱讀、整理、比較與提出假設，但需求是否理解正確、修改範圍是否安全、資料是否一致，以及結果能不能上線，最後仍需要工程師判斷。

如果這個系列順利完成，我希望能留下的不只是一份「如何用 AI 寫程式」的紀錄，而是一套面對陌生舊系統時可重複使用的方法：知道怎麼問、怎麼查、怎麼驗證，也知道什麼時候不能相信 AI 那個過度自信的笑容。

下一篇，我會從最現實的起點開始：

面對一個沒有文件、檔案又多到像迷宮的 Delphi 專案，第一步到底該看哪裡？

今日重點

• Legacy System 的難點不是舊語法，而是隱藏的系統關係與商業規則。
• AI 最適合先協助理解、除錯、風險檢查與文件整理，而不是直接接管修改。
• 所有 AI 建議都必須經過程式追蹤、資料驗證與影響範圍確認。
• 接下來 30 天，將用實際案例驗證 AI 在企業舊系統維護中的能力與界線。