換工作第一天，面前是幾十萬行 code。你的直覺是從 main.ts 開始讀。恭喜，你選了最慢的方式。
先講結論
不要逐行讀 code——你不知道什麼重要、什麼不重要。先建立全景，再深入細節，就像看地圖不會從左上角一個像素一個像素看。三天就能從「完全陌生」到「能自信做小改動」。
Day 1：建立全景
目標：能在白板上畫出系統的粗略架構圖。
先看「外面」，不看 code
README.md → 專案目的、怎麼跑
package.json → 什麼框架、什麼套件
docker-compose → 幾個組件
.env.example → 連了哪些外部服務
CI/CD config → 怎麼部署
從這些檔案你能知道：前端/後端/全端、什麼框架、monolith 還是 microservice、依賴哪些外部系統。
看目錄結構
tree -L 2 -d目錄結構反映架構：controllers/models/routes/ 是 MVC、users/orders/payments/ 是 domain-driven、packages/api/web/shared/ 是 monorepo。
畫架構圖
不用完美。30 分鐘畫出主要組件、怎麼連接、資料流向：
[使用者] → [前端 Next.js] → [API Express] → [PostgreSQL]
↓
[Redis Cache]
↓
[Stripe 支付]
這張圖接下來三天會反覆修正。第一版不對很正常。
把系統跑起來
Day 1 結束前一定要讓系統跑起來，不管用多髒的方式。跑起來之後用瀏覽器走一遍主要功能的 happy path。
跑不起來卡在哪？那些坑本身就是很有價值的資訊。
Day 2：追蹤一條關鍵路徑
目標：理解一個核心功能從 request 到 response 的完整流程。
選對路徑
選系統最核心的功能。電商 → 下訂單、SaaS → 登入看 Dashboard、API 服務 → 收 webhook 處理。不要選最簡單的（太淺）也不要選最複雜的（太深）。
從入口往內追
路由定義 → Controller → Service → Repository → Database。
大量使用 IDE 的「跳到定義」和「查找引用」。在重要的地方加書籤或註解。
搭配測試理解
測試是可執行的文件。 如果有測試，先看測試再看實作——測試告訴你預期輸入輸出、邊界條件、商業規則。
更新架構圖
Day 2 結束後你的架構圖應該豐富很多了，從「粗略的方塊」變成「有具體的 Controller、Service、Repo」。
Day 3：擴展理解 + 記錄盲點
目標：理解 2-3 條路徑，能自信做小改動。
再追 1-2 個重要功能，第二條通常快很多。
識別地雷區
每個 codebase 都有：
- God Class：一個檔案 2000+ 行，用
wc -l排序找到 - 無人敢動區：git log 很久沒改、或只有特定人改
- 高 churn 區：經常被修改，不穩定或設計不好
- workaround 集中地：
grep -r "TODO\|HACK\|FIXME" src/
記錄你的發現
給自己（也給未來的新人）寫筆記：架構概覽、核心流程、關鍵檔案、地雷區、還不懂的東西。那些「還不懂的」就是你接下來要問原作者的。
AI 在這裡能幫什麼
AI 可以加速資訊收集：理解目錄結構、解釋 function 做什麼、追蹤呼叫鏈、理解 if-else 的商業意義。
AI 不能幫你的：判斷架構設計的「為什麼」（要問原作者或看 ADR）、理解不在 code 裡的商業規則、判斷哪裡是地雷（需要 git history + 經驗）。
用 AI 加速資訊收集，但自己做判斷和整合。不要盲信 AI 對 code 的解讀——它可能漏掉 side effect 或誤解商業邏輯。
常見錯誤
- 從第一行逐行讀：沒有全景，不知道什麼重要 → 先看結構再看細節
- 試圖一次理解所有東西：會資訊過載 → 一次只追一條路徑
- 只看 code 不跑起來：行為可能跟你想的不同 → Day 1 一定要跑起來
- 不敢問問題：最快的文件是人 → 記下問題集中問
- 不做筆記：三天後你會忘記 Day 1 的發現
延伸閱讀
你能在 10 分鐘內畫出目前專案的架構圖嗎？如果不能——你已經在這個專案工作多久了？也許是時候退一步看看全景了。