Junior Developers 在 Vibe Coding 時的問題與挑戰

作者： DD - 8月 31, 2025

最近有個發生在我們專案上的真實案例。

一位初階開發人員用 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 才會真正成為戰力的加速器，而不是在關鍵時刻變成風險與與問題的擴大機。

搜尋此網誌

.NET Walker