幾行就能寫完的方法，被 AI 加上了四層包裝

先從一個畫面看起。2026 年 9 月 18 日，掘金上出現一篇文章，討論一件工程師早就隱約感覺到、卻很少被認真拆解的事：請 AI 實作一個簡單方法，原本幾行就能結束，它卻遞回來一段加上空值判斷、參數校驗、異常捕獲、預設返回值，甚至重試邏輯的程式碼。畫面上密密麻麻的 if 與 catch，看起來周全，像一份被過度裝幀的說明書。

這個現象值得用設計的角度看。因為那些多出來的判斷，本質上是一種介面排版的選擇：AI 在沒有足夠脈絡的情況下，把「看起來負責任」的視覺語言，優先於「語義正確」的結構設計。

合理的防禦，與被包裝出來的防禦

防禦性編程本身有明確的設計意圖。計算平均值時檢查集合是否為空，並在違反契約時拋出例外，這是在替方法畫出一條清楚的邊界：呼叫方必須傳入非空集合。這種防禦有語義，像一扇貼了標籤的門，推不開的時候你知道原因。

但另一種寫法是：集合為空時，安靜地返回零。畫面上沒有錯誤，測試通過，日誌乾淨。可是「沒有資料」和「平均值為零」是兩種完全不同的狀態，前者是一個應該被看見的事實，後者是一個被捏造出來的答案。這種防禦沒有畫出邊界，它把邊界塗掉了。

原文用了一個準確的說法：防禦性編程的重點，是讓異常情況具有明確語義，而不是讓程式永遠不報錯。換成設計語言來說，好的防禦是一套清楚的錯誤訊息系統，壞的防禦是把所有錯誤訊息換成空白頁。

為什麼 AI 的第一反應是加包裝

文章給出的幾個解釋，都指向同一件事：脈絡的缺失，會被「可見的工作量」填補。

第一層是上下文。開發者知道某個參數已經在 Controller 層校驗過，也知道資料庫欄位不允許為空。AI 只看到一個 Service 方法，這些約束對它不存在。於是它補上一個 null 判斷，看似避免了一次例外，實際上沒有回答更重要的問題：非法參數為什麼應該返回 null？判斷可以補上，業務契約不能靠猜。

第二層是需求本身的模糊。「幫我優化一下，考慮邊界情況，保證程式穩定」，這句話沒有定義哪些邊界需要處理，也沒有說明失敗時應該長什麼樣子。AI 於是把任務轉譯成一組可見的動作：加判斷、捕例外、給預設值、加重試。這些動作容易展示「做了更多工作」，卻不一定提高正確性。這和簡報裡堆滿圖表卻沒有結論是同一種設計病：用密度代替判斷。

第三層是訓練材料的慣例。公開程式碼與教學示例裡，參數校驗和異常處理是高頻出現的模式。沒有專案約束時，AI 會採用這種通用寫法。但通用寫法不會自動適配專案架構。如果專案已經有統一的異常處理器，Service 層再包一層 try-catch 並返回 null，等於在主流程旁邊挖了一條暗渠，真正的故障從暗渠流走，統一處理器反而收不到任何東西。局部看起來保護得很好，整個系統卻失去了表達失敗的能力。

這種「局部周全、整體失語」的結構，在介面設計裡也有對應物：每個頁面都有自己的空狀態插圖和錯誤提示，使用者卻永遠不知道系統到底出了什麼事。這與我們先前討論過的5 小時限額被設計成無法規劃的時間介面有相似的邏輯，介面的每個局部都在回應你，合起來卻不構成可理解的答案。

顯眼的錯誤與安靜的錯誤

文章裡還有一個觀察值得單獨拿出來：空指標例外很顯眼，測試會失敗，日誌會報錯；錯誤地返回零、空集合或成功狀態，卻可能悄無聲息地通過一切檢查。

這是兩種完全不同的錯誤美學。前者醜，但誠實；後者乾淨，但說謊。AI 在生成程式碼時傾向避免前者，因為顯眼的錯誤在它的最佳化目標裡是扣分項。結果是它系統性地偏好安靜的錯誤，用預設值把問題吸收掉，讓畫面維持整潔。

這跟產品設計裡「不放任何報錯訊息就以為使用者體驗變好了」是同一種取捨。短期看，介面變順滑了；長期看，沒有人知道資料從哪裡開始就是錯的。

契約要被寫進需求，而不是被猜出來

文章的收尾方向很實際：把「穩定」落實為具體規則。使用者不存在時返回業務錯誤；資料庫不可用時保留失敗狀態；不要統一返回空物件。這些規則比「保證不報錯」更有指導意義。

換句話說，問題的解法不在於叫 AI 少寫判斷，而在於把業務契約從開發者的腦中搬到提示詞與文件裡。契約越清楚，AI 需要用包裝填補的空白就越少。當約束足夠具體時，那些通用模式的吸引力自然下降，因為已經有明確的答案可以遵循。

這也提醒了一件事：AI 生成的程式碼，應該被當成一份排版過的稿件來校對，而不是一份成品來驗收。校對的重點不是找它漏了什麼保護，而是找它多放了什麼、那些多出來的保護把哪些該被看見的失敗藏起來了。

回到最初那個畫面。幾行就能寫完的方法，被加上四層包裝之後，看起來像一個負責任的工程師寫的東西。但程式碼的責任感從來不由 if 的數量衡量，而由失敗時它說了什麼來衡量。一個會清楚告訴你「集合不能為空」的方法，比一個永遠返回零的方法誠實得多。AI 目前擅長製造前者的是外表、後者的實質，這中間的落差，就是使用它的人需要親手填上的部分。