為什麼這個問題現在會跑出來
最近你可能已經遇過這種畫面：叫 AI 幫你補一段後端業務邏輯，它 20 秒內寫出 if/else，簡單講就是條件成立走 A、不成立走 B 的分岔；本機跑幾個 happy path，也就是最順的正常情境，看起來都沒問題。結果一接到真實資料，0 被當成沒有值，null 沒擋住，空陣列被當成有資料，線上就開始出現很難追的錯。很煩。 我自己看過一段付款狀態判斷，AI 寫得很像資深工程師會寫的樣子：欄位有值就更新，沒有值就略過。問題是金額 0 在那個系統裡代表折抵後免費，不是缺資料。這種錯不會在畫面上大聲喊它錯，它只會讓報表、通知、狀態流在 3 天後慢慢歪掉。這才麻煩。 這篇的核心判斷很短：AI 寫的條件判斷在邊界值上常常出錯，不是因為它不會寫程式，而是它太容易照「最常見資料形狀」補邏輯。0、null、空陣列、負數、undefined 都是代表性 case；0 是合法數字但容易被誤判成沒值，null 代表刻意沒有資料，空陣列代表有容器但沒有項目，負數常牽涉退款或扣抵，undefined 則常見於欄位根本沒傳進來。這 5 個值，就是你 review AI 產物時最該先看的地方。先看這裡。
把 0、null、空陣列、負數、undefined 當成必要 review 點。
真正的原因不在表面
真正的原因不在表面：這通常不是「模型會不會寫 if」的問題，而是「任務規範有沒有把資料語意講清楚」。AI 看到 discount、amount、items、user、status 這些名字，會猜一個常見寫法；但它不知道你的產品裡，空陣列是「沒有商品」、還是「尚未載入完成」，也不知道 null 是「使用者未填」，還是「後端刻意清空」。同一個值，在不同系統裡意思會差很多。差在語意。 很多工程師會把這類錯歸成 hallucination，簡單講就是 AI 編出看似合理但其實不可靠的內容。這個詞有時候有幫助，但在條件判斷這件事上，光喊它亂編不夠精準。更常見的情況是：AI 寫出的程式語法正確、型別也可能過得去，甚至測試還綠，但它對業務規則的理解少了一個洞。那個洞通常就藏在邊界值。洞很小，影響很大。 你可以把 AI 想成一個會寫很多樣板的同事，但它目前多半不會主動追問每個欄位的商業含義。它會用訓練裡常見的模式處理「有值 / 沒值」、「成功 / 失敗」、「列表有資料 / 列表沒資料」。問題是後端邏輯最容易出事的地方，偏偏就是這些看似簡單的分流。例如 JavaScript 裡 0、空字串、null、undefined 在條件判斷裡很容易被混在一起；但在訂單、權限、庫存、點數系統裡，它們常常代表不同狀態。不能混。 所以判斷 AI 產物時，不要只問「這段有沒有 compile」，compile，簡單講就是程式能不能被編譯或執行環境接受；也不要只看它有沒有通過 2 個正常案例。你要問的是：這段邏輯有沒有把資料狀態拆清楚。典型情境只是入口，邊界值才是壓力測試。這是關鍵。
現在先做什麼
現在先做什麼？我會建議你先把 AI 寫出的條件判斷拿出來，停 15 分鐘，只做一件事：把每個分支旁邊補上「這個判斷到底在區分什麼」。不是急著叫 AI 重寫，也不是立刻加 20 個測試，而是先把語意拉回來。因為程式看起來像對，和業務規則真的對，中間差一層翻譯。先翻譯。 看到 AI 寫出的 if/else，你可以用 5 問掃過去：0 怎麼辦？null 呢？空陣列呢？負數呢？undefined 呢？這不是儀式感，而是把最常見的非典型資料拉上桌。舉例來說，if (amount) 在很多語言或框架裡看起來很順，但 amount = 0 時可能會走到「沒有金額」那邊；if (items) 也可能忽略空陣列其實仍然是合法回傳。這類問題不大聲，但很陰。 更實際的寫法，是在給 AI 任務時就順手補一句：「請明確區分 0、null、空陣列、負數與 undefined 的處理方式，並說明每個值在這段業務邏輯中的含義。」這句話比「幫我寫得嚴謹一點」有效，因為嚴謹太抽象，5 個值很具體。AI 比較容易照著檢查。可執行。 如果你已經有測試，別只讓 AI 補 happy path。請它針對那 5 類值各挑 1 個最可能出事的案例，然後你再刪掉不符合產品規則的。這樣做的好處是，你不是把判斷權交出去，而是讓 AI 幫你把可能漏看的狀態列出來。你仍然是決策的人。這點要守住。
常見的陷阱跟誤解
第一個陷阱，是把「有型別」誤以為「有語意」。TypeScript，簡單講就是替 JavaScript 加上型別檢查的工具，可以提醒你 amount 是 number，但它不會自動知道 0 在你的產品裡是免費、失敗、尚未付款，還是折扣後結果。型別只是底線。 第二個陷阱，是看到 AI 加了很多防呆就放心。防呆如果沒有對上業務規則，反而會把合法資料擋掉；例如把負數一律擋掉，可能會讓退款、沖銷、點數扣回全部壞掉。多擋不等於安全。要看語意。 第三個陷阱，是只在 controller，簡單講就是接收請求並決定要呼叫哪段邏輯的入口，檢查一次就收工。真正會出事的條件判斷常藏在 service、repository、queue worker 這些後面幾層；service 是放業務規則的地方，repository 是處理資料存取的地方，queue worker 則是背景排程工作。入口乾淨，裡面仍可能歪掉。要往下看。 還有一個常見誤解：把邊界值當成測試工程的責任。其實這件事在寫需求、請 AI 產生程式、review PR、補測試時都會出現；越晚處理，修正成本越高。早一點問，通常比較省。現在就問。
下次再遇到時可以怎麼判斷
下次再遇到 AI 幫你寫條件判斷，不用先把整段推翻。先看這段邏輯會不會影響 3 類東西：錢、權限、資料狀態。如果會，就把 0、null、空陣列、負數、undefined 拉出來逐一問；如果只是單純 UI 顯示或低風險格式整理，檢查可以輕一點。看風險。 這裡沒有單一正解，因為不同系統對同一個值的意思可能差很多。你要養成的不是背一份固定規則，而是看到 AI 寫 if/else 時，先問「這個分支在業務上到底代表什麼」。如果答不出來，就先別急著合併。下一次，就從這句開始。
讀者最常問的幾個問題
因為它常先補出最典型的資料流程，例如有使用者、有訂單、有金額、有列表。這種情境 demo 很順，但真實後端資料會有 0、null、空陣列、缺欄位、負值或狀態不一致。你要把 review 重點從「這段邏輯像不像」改成「這段邏輯遇到非典型資料會怎麼走」。
多數情況更像邏輯規範沒補齊，而不只是亂編。AI 沒有你的產品規則，也不知道 0 在這個欄位代表免費、未開始、失敗，還是合法數值。它會用常見寫法補洞，所以你要把業務語意說清楚，而不是只叫它「修 bug」。
不用把所有可能值都塞進測試，成本會失控。比較實際的做法是抓 5 類高風險值：0、null、空陣列、負數、undefined。只要這 5 類會改變金額、權限、庫存、狀態或對外回應，就值得補測試。
如果規則很局部、資料型別明確、既有測試涵蓋正常與空值情境，AI 改起來通常比較穩。反過來，如果這段邏輯會影響付款、權限、排程、通知或資料刪除，就要把 AI 當成草稿產生器，而不是最後裁判。
