Hi~ 我是 Eric。
從上禮拜到這禮拜，對我來說是一個很特別的轉換期。
我正式到林口康橋報到，開始接觸校內既有的校務系統。這種時候最真實的感覺，不是「我要開始寫新功能了」，而是「我得先知道這座城市的地下管線怎麼走」。
因為舊系統通常不會乖乖站在門口跟你自我介紹。
它可能有很多年前留下來的資料表、WebForm 頁面、共用函式、DLL、排程、報表、寄信流程、後台工具，甚至還有一些只有實際業務跑過才知道的規則。你看到的是一個按鈕，但背後可能牽動三張表、兩支 stored procedure、一段共用函式，最後再寄一封信給某個角色。
如果一開始就急著重寫，那很容易寫出一套看起來很漂亮、但接不上現場脈絡的新系統。
所以我這一週的核心任務不是馬上開發，而是先把舊系統完整爬出來。
重點來了：這次我不是靠自己一個人慢慢翻檔案，而是把 Codex App 放進這個工作流程裡，讓 AI 幫我把混亂的舊系統整理成可判斷、可討論、可延續的工程資料。
報到後第一個感覺：舊系統不是爛，是有歷史
剛進一個新環境時，很容易對 Legacy System 產生一種直覺反應：
這怎麼那麼亂？
但老實說，這個想法通常只對一半。
舊系統之所以長成這樣，背後一定有原因。可能是當年的需求很急，可能是學校流程一直變，可能是某個模組一開始只服務一個單位，後來慢慢變成全校都在用，也可能是那時候的技術選型本來就不同。
講白一點，Legacy System 不是單純的技術債，它也是一段組織記憶。
如果我只把它看成「要被淘汰的舊程式」，那我會漏掉很多重要資訊：
- 哪些資料真的還在被使用
- 哪些欄位是歷史包袱
- 哪些流程其實藏著校務規則
- 哪些功能看起來不起眼，卻是行政現場每天會用的關鍵節點
- 哪些命名不漂亮，但背後代表一個真實部門或業務情境
所以我給自己的第一個原則是：
先不要急著批判，先把它看懂。
這也是 AI 最適合介入的地方。不是請它直接重寫，而是先請它協助我建立地圖。
我用 Codex App 做的第一件事：把黑盒子變成地圖
Codex App 對我最大的幫助，不是「幫我寫幾段程式碼」而已。
真正有價值的是它可以進到專案脈絡裡，讀檔案、搜尋引用、追呼叫鏈、比對資料表命名，然後把零散資訊整理成我可以判斷的形式。
我大概把工作拆成幾個方向：
- 先掃描舊專案的目錄結構，找出主要模組與入口點。
- 追 Web 頁面、Code-behind、共用函式、DLL 呼叫與資料庫存取。
- 把 SQL、資料表名稱、欄位名稱與功能頁面串起來。
- 整理哪些資料表屬於同一個業務領域。
- 釐清哪些功能只是畫面操作，哪些其實是核心校務流程。
- 把結果逐步沉澱成
LegacyDBSchema，作為未來新系統開發前的地圖。
這裡的關鍵不是一次產生完美文件。
關鍵是讓 AI 先幫我把「我不知道自己不知道什麼」挖出來。
以前我可能要一個檔案一個檔案翻，看到 SQL 再手動記錄，看到共用方法再回頭搜尋誰呼叫它。現在我可以讓 Codex App 幫我先做初步盤點，再由我去審查、修正、補上判斷。
這種差異非常大。
以前是人在迷宮裡走；現在比較像 AI 先幫我畫出迷宮草圖，我再拿著草圖去確認哪條路真的通。
LegacyDBSchema 的價值：不是資料表清單，而是開發共識
我現在建立 LegacyDBSchema，不是為了做一份漂亮文件放著。
它的真正用途，是讓未來的開發更順。
在舊系統轉新系統的過程裡，最怕的不是寫不出 API，也不是前端畫面做不出來。最怕的是我們以為自己理解了需求，結果資料關係完全看錯。
例如：
- 這張表到底是主資料，還是暫存資料？
- 這個欄位是狀態，還是某個流程階段的副產品？
- 這兩張表的關係是正式關聯，還是歷史上某次功能新增後留下的連動？
- 這個功能要搬到新系統時，是應該照搬資料結構，還是重新定義 domain model？
如果沒有先整理，這些問題會在開發中途爆炸。
而 LegacyDBSchema 就像是新舊系統之間的翻譯層。它先承認舊系統的真實樣貌，再幫我們判斷哪些東西要保留、哪些東西要轉換、哪些東西應該趁重構時切乾淨。
這對 C# API、Vue 後台、未來可能的 App 流程都很重要。
因為只要資料邏輯沒有釐清，前後端都會變成猜謎遊戲。
AI 加速的不是「打字」，而是整個工作流程
很多人談 AI 開發，會把焦點放在「AI 幫我寫了多少程式碼」。
但我這次感受更深的是：AI 真正加速的是整個工作流程。
它加速了這幾件事：
| 工作階段 | 以前的方式 | 有 Codex App 之後 |
|---|---|---|
| 專案探索 | 手動翻目錄、找入口點 | 先讓 AI 掃描結構並提出模組地圖 |
| 呼叫鏈追蹤 | 一個方法一個方法搜尋 | 讓 AI 協助整理頁面、函式、資料表關係 |
| DB 盤點 | 手動記錄 SQL 與欄位 | 讓 AI 初步彙整後再人工審核 |
| 文件建立 | 開發後才補文件 | 探索過程中同步沉澱成文件 |
| 決策討論 | 靠口頭記憶與零散截圖 | 用整理後的 schema 與流程圖討論 |
| 新系統規劃 | 邊做邊猜 | 先建立舊系統基準，再設計新架構 |
老實說，這不是省下幾分鐘而已。
它把我從「低階搜尋與複製貼上」拉到「判斷、驗證與設計」的位置。
我仍然需要看結果。AI 盤點出來的東西不可能全信，尤其是舊系統常常會有命名不一致、未使用檔案、歷史資料表、或看起來相關但其實已停用的流程。
但是差別在於，我不再需要把大量時間花在第一輪粗掃。
AI 先把材料搬到桌上，我再判斷哪些是證據，哪些只是噪音。
這就是我覺得 AI 對工程師最實際的加速方式。
這也改變了我對「新工作前幾週」的看法
以前進到一個新環境，前幾週通常會有一段很長的適應期。
你要認人、認系統、認資料庫、認部署方式、認那些「文件沒有寫但大家都知道」的規則。
AI 不會讓這些事情消失。
但它可以把適應期壓縮得更有效率。
我可以更快整理出問題清單：
- 哪些系統需要優先理解？
- 哪些資料表是核心？
- 哪些流程會影響未來 API 設計？
- 哪些舊邏輯需要保留相容？
- 哪些地方適合直接重構？
- 哪些地方要先保持敬畏，不能亂動？
這最關鍵。
工程師剛進一個新環境，最需要的不是馬上展現自己多會寫 code，而是快速建立正確的系統感。
Codex App 幫我加速的，就是這種系統感。
Eric 的碎碎唸：AI 讓人變快，但也讓基本功更重要
這幾天用下來，我反而更確定一件事：
AI 不是讓工程師不用懂系統，而是讓工程師更需要懂系統。
因為 AI 可以很快給你一份看起來合理的整理，但它不知道學校現場真正的優先順序，也不知道某個欄位背後是不是行政流程的關鍵判斷。它可以找到線索，但最後要不要採信，仍然要靠人。
所以我現在比較喜歡把 AI 當成一個很強的協作隊友，而不是自動駕駛。
它負責加速探索、整理脈絡、產出初稿、幫我追引用。
我負責判斷風險、確認語意、設計邊界、決定新系統該怎麼長。
這樣的分工才健康。
結語：先把舊世界看懂，才有資格建立新世界
從上禮拜到這禮拜，我在林口康橋最大的收穫，不是馬上完成了什麼新功能，而是開始建立一套面對 Legacy System 的工作方法。
先爬出舊系統。
先建立 LegacyDBSchema。
先讓資料、流程、頁面與業務規則有一張可以討論的地圖。
然後，才開始設計新的 C# API、新的 Vue 後台、新的 App 流程。
講白一點，AI 讓我更快動手，但也提醒我不要急著動手。
因為真正好的系統改造，不是把舊東西全部推倒重來，而是先理解它為什麼存在，再決定哪些要保留、哪些要轉換、哪些要勇敢淘汰。
這一週，我覺得自己不是在跟 AI 比誰寫 code 比較快。
我比較像是在用 AI 幫自己多長一雙眼睛。
而在一個剛開始接手的校務系統裡，這雙眼睛，真的很有用。