剛進專案時，AI 最有價值的事情，其實是幫新人建立「專案地圖」

前言

✨ AI 出現之後，新人工程師進入專案的方式，已經徹底改變了。

過去新人進入陌生系統時，通常只能：

• 查文件
• 問同事
• 追蹤程式碼
• 看提交歷史
• 自己慢慢拼湊系統

很多時候甚至像在考古。

因為：

• 文件不完整
• 命名不一致
• 服務關係複雜
• 歷史包袱很多
• 設計理由沒人記得

所以 Onboarding 很容易變成：

花幾個月理解系統

而且新人往往在真正理解系統之前，就已經開始：

• 修問題
• 改需求
• 補 Patch
• 修改生產程式碼

😅 這其實是很多工程團隊長期存在的問題。

新人真正缺少的，通常不是技術能力

很多人以為新人工程師最大的問題是：

技術不夠強

但其實更多時候是：

不知道系統是怎麼運作的

很多新人甚至會有一種感覺：

每個檔案我都看得懂，但整個系統我完全看不懂

這其實非常正常。

因為大型系統真正困難的地方，從來都不是語法。

而是：

• 專案脈絡
• 系統理解
• 模組責任邊界
• 資料流概念
• 依賴關係
• 歷史設計背景

也就是：

一張完整的「專案地圖」

而這剛好是 AI 很適合協助的地方。

資深工程師其實都在腦中建立了「專案地圖」

很多人會以為資深工程師厲害，是因為：

他知道所有答案

但其實通常不是。

真正的差別往往是：

他知道系統是怎麼運作的

例如：

• 請求怎麼流動
• 哪些服務彼此耦合
• 哪裡最容易出問題
• 哪些地方是歷史權宜之計
• 哪個模組修改風險最高

🔎 這些東西，通常不會完整寫在文件裡。

而是長期累積後形成的：

系統模型

也就是：

腦中的專案地圖

這其實才是 Onboarding 最困難的地方。

AI 最適合幫忙的，其實是建立「專案地圖」

很多人現在談 AI，都在談：

• 程式碼產生
• 提示詞技巧
• 開發效率
• 自動修問題

但我越來越覺得：

AI 對新人工程師最有價值的地方，其實不是幫你寫程式碼

而是：

幫你快速理解陌生系統

因為 AI 很適合協助新人快速建立：

• 系統全貌
• 架構理解
• 請求流程
• 依賴關係
• 服務責任
• 模組邊界

也就是：

一張「專案地圖」

AI 很適合做「系統逆向理解」

這其實是 AI 非常強的一件事。

例如新人看到一個服務時，不要只問：

這段程式碼在做什麼？

而可以問：

這個服務在整個系統中的角色是什麼？
它依賴哪些模組？
資料流怎麼走？

或者：

這個功能的請求流程是什麼？

甚至：

哪些地方最可能是過時程式碼？

💡 這些問題其實都很有價值。

因為新人最缺少的，通常不是：

怎麼寫

而是：

為什麼系統會長這樣

AI 可以幫新人更快建立「專案地圖」

我其實很推薦新人把 AI 當成一個「系統導覽員」。

剛進專案時，可以先問這幾類問題：

• 這個模組在整個系統中的角色是什麼？
• 它依賴哪些服務、資料或共用元件？
• 一個請求從入口到資料庫，中間會經過哪些層？
• 哪些設計看起來像歷史折衷，而不是理想解？
• 哪些地方修改風險最高，為什麼？

這些問題表面上不像在「解題」，但其實都在幫新人做同一件事：

建立對系統的整體理解

這也是資深工程師在腦中會自然形成的那張地圖。

AI 真正降低的，是新人的理解摩擦

以前大型系統最痛苦的地方，往往不是看不懂某一段程式碼。

而是：

不知道該從哪裡開始理解

💥 很多新人其實卡住的不是能力，而是缺少觀察方向。

所以他可能不知道：

• 該先看哪個入口
• 該追哪條資料流
• 該懷疑哪個模組
• 哪些現象只是表象

而 AI 的價值，就在於它可以幫你先整理出：

• 架構輪廓
• 服務關係
• 流程摘要
• 命名規則
• 高風險區域

換句話說，AI 不只是幫新人比較快拿到答案。

它更有價值的地方，是幫新人比較快知道：

下一步該往哪裡看

這會直接降低大型系統的 Onboarding Friction。

結語

對剛進專案的新人工程師來說，AI 的價值不該只是：

幫我修問題

而應該是：

幫我理解這個系統

這兩者的差別，會直接影響一個工程師未來的成長速度。

💥 如果 AI 只是幫助你快速得到答案，那你可能會越來越依賴 AI。

✨ 但如果 AI 是用來幫你建立專案脈絡、理解架構、看懂資料流、辨識高風險區域，那它其實是在幫你更快長出自己的工程判斷能力。

所以對新人來說，剛進專案時最值得問 AI 的，也許不是：

這段怎麼改

而是：

這個系統到底是怎麼運作的

當你開始有能力回答這個問題，AI 才真正發揮了它在 Onboarding 上的價值。