Junior Developers 在 Vibe Coding 時的問題與挑戰
最近有個發生在我們專案上的真實案例。
一位初階開發人員用 AI 一口氣生出前端註冊表單 以及 後端驗證與寫入資料庫的程式碼。建置沒錯、可以運行、AI 自我檢查後也說了聲沒問題，但是一跑，前端的資料就是進不到後端模型，驗證當然也就永遠失敗。
這位 Junior Developer 卡在這邊三小時(生成這段程式碼的時間其實只有5分鐘)，直到下班前，一票老傢伙看不下去，在旁邊盯著把前後端程式碼一一對起來後才發現，問題居然只需要改一個字母而已。
現場重現：前端 AJAX 送這個
劇情其實很簡單，前端把使用者輸入後的資料，包裹成類似底下這樣的 JSON，透過 AJAX 丟到後端 Controller：
{
"UserName": "Rick",
"Email": "rick@example.com",
"Password": "P@ssw0rd!",
"PhoneNumber": "0987123456"
}
產出上面的這段 JSON 的程式碼是 AI 寫的。
而接著 ASP.NET Core 的 Controller 大概長底下這樣：
[ApiController]
[Route("api/[controller]")]
public class AuthController : ControllerBase
{
[HttpPost("register")]
public IActionResult Register([FromBody] RegisterRequest input)
{
// input 的屬性全是 null -> 驗證失敗
if (input is null || string.IsNullOrWhiteSpace(input.username))
return BadRequest("payload invalid.");
// 其餘省略...
// 其餘省略...
// 其餘省略...
return Ok();
}
}
輸入時使用的 Model 長底下這樣：
public class RegisterRequest
{
public string username { get; set; }
public string email { get; set; }
public string password { get; set; }
public string phonenumber { get; set; }
}
結果當然：username/email/... 全部是 null。
為什麼？因為反序列化時，JSON 的屬性 UserName/Email/...（大寫），但 C# 屬性是 username/email/...（小寫）。在大多數情境下，System.Text.Json 的預設行為是 大小寫敏感，名字沒有100%對起來就直接給你 null。
好玩的是，這位 Junior 說，他不是沒有注意到這個大小寫不同，但是，他記得在其他專案中這麼做的時候，大小寫不同是可以的! 因此他這三小時都在測其他的東西。
而且，這段程式碼不管是前端還是後端，都是AI生的，所以他認為這部分應該是OK的才對。
結果這麼一個單純的問題卡了三小時，比AI生出這段程式碼的時間(五分鐘)，足足多了 36 倍。
為何老傢伙一眼就看的出來的問題，許多初階開發人員會注意不到?
因為資深工程師在腦中早就有一套訓練好的 經驗模型：
- 他們看過各種前後端對不起來的狀況，對「屬性名稱大小寫不一致」這種 bug 幾乎有直覺反應。
- 他們知道 程式碼不是單獨存在的，而是有「前端 JSON ↔ 後端 DTO ↔ 資料庫 schema」的鏈條，鏈條斷在任何一環都可能出錯。
- 他們習慣先驗證輸入輸出資料，再檢查模型，而不會只是盯著程式碼死看。
相反地，許多初階開發人員 完全靠 AI 生成程式碼，跳過了「自己手刻」的過程，欠缺累積這種「錯誤模式記憶」。對他們來說，程式碼片段就像是個黑盒子，跑得動那是最好、跑不動時就一頭霧水。
這就是為什麼「老傢伙」能憑直覺馬上定位問題，而新人常常要卡幾個小時還找不到頭緒。
那為什麼這位 Junior 說，他在其他專案中這麼做的時候，大小寫不同是可以的?
這是因為在 ASP.NET Core 的序列化/反序列化設定裡，有個設定叫做 PropertyNameCaseInsensitive。
在那些 可以的 專案裡，這個選項被全域的設定成 true，所以即便前端傳來的 JSON 是大寫 UserName，後端類別寫成小寫 username，框架也會自動忽略大小寫，把值對應進去。
但沒寫過也沒學過的 Junior 哪裡會知道呢?
為什麼 AI 會踩雷？
因為 AI 很擅長「把能運作的片段拼出來」，但不會自動確保跨層命名策略一致。初階工程師如果沒建立 JSON 命名策略、模型繫結、序列化選項的心智模型，就很難從症狀一路推回「大小寫對不起來」這件事。
這是 AI 讓你很快抵達 80% 的典型副作用：最後 20% 的基本功與除錯能力，仍然要靠人。
就像之前曾說的，除非刻意練習，否則隨著我們實作的比例愈來愈低（因為現在大部分都交給 AI 生成），新人累積這類經驗的時間就會愈來愈長。
長遠下來，這會造成一種落差：資深工程師的直覺與判斷力來自於過去數十次、數百次的踩坑經驗，而新人卻可能連一次完整的「踩坑->找原因->解決」循環都經歷不到。結果就是，AI 幫忙快速鋪路，但也同時把「學會走路」的時間無限延後。
怎麼辦?
團隊需要有意識地設計「刻意練習」的場景，例如 Code Review、Bug Hunt、Pair Programming，甚至在培訓環節暫時拿掉 AI 輔助，讓新人必須獨立完成。唯有這樣，AI 才能真的成為助力，而不是讓開發者在關鍵時刻手足無措的「拐杖」。
順帶一題：AI 確實很強，但「把 bug 指給你看」目前還不算是它的強項
AI 能讓初學者一天完成原本要三天的事，但也會讓人忽略那些你本來該在第一週就理解的基本功。
做為一個開發團隊，我們要設計的是一個 結構化的學習路徑與安全網，而不能像過去一樣把新人丟進去專案裡直接單打獨鬥。
- 要有文件化的 最佳實務（例如 API 命名規範、DTO 命名策略），避免同樣的坑一再發生。
- 要有 自動化測試與保護機制，讓錯誤可以在 CI 階段就被攔下，而不是總是在新人的電腦上爆出來。
- 團隊要有 知識傳承的設計，透過 Code Review、Pair Programming，讓「老傢伙的直覺」能被年輕人學到，而不是只能靠卡關時的臨時救火。
AI 可以加速產出，但判斷、驗證、與歸納經驗仍然是人類工程師必須承擔的部分。只有當團隊願意把這些「最後 20%」設計進日常流程，AI 才會真正成為戰力的加速器，而不是在關鍵時刻變成風險與與問題的擴大機。
留言